Kickstart your career with best deals on top training courses NY10 Click to Copy

Search

Agile Transformation In Large Organizations

As agile readers, I am sure we all agree that LARGE is a relative term and may not be defined just by number. What does LARGE imply? Is it something that has employees above 5000 but completely structured  Or an organization that has <1000 employees but complex due to the silos, style, and technical limp.  My personal definition - Large organization can be defined as an organization that has fostered distance between employees with process, silos, hierarchy and complexities. Numbers don’t reflect the magnitude during the transformation, but the complexities and the mindset to change. Over the years I have realized, transformations of companies with 10K+ employees and slightly structured, will take same amount of effort as an organization with 1000 employees but unstructured !!! Similar to the two piles of books below. Where does one take more time to find a book? And the answer defines the magnitude of LARGENESS.  Let us assume, for the above pictures, if the problem statement is given as:  Find a book called “Why Agile?” Scenario 1: Considering the books are thrown and piled all around the room, one would take almost days together to get the above problem statement resolved, despite the fact that it is such a small collection of books.  Cause of Delay: Not structured  Chaos and redundancy Impact: Cost of delay Scenario 2: Books are arranged in an orderly fashion, could be alphabetical, year based, genre etc. !!!  Also, this is digitally transferred to make the search easy via computer seen in the picture. In this scenario, one may not take more than 30 mins to find the book stated in the problem statement Impact: Efficiency   In a software world, efficiency should be the measure of Largeness. Lower the efficiency higher the complexity and the magnitude of measure. As, despite the number, journey of transformation is the same. It has to go through the same cycle of form, storm, and norm and perform in order to successfully adopt agile transformation. Irrespective of the approach or magnitude it is always important to understand the organization prior to committing to transformation or adoption.  An analogy to Agile transformation is, similar to any long journey, it gets as pleasant as the people surrounding you; you get a grumpy passenger your trip gets grumpier. There are many articles and blogs that describe impacts of people and surroundings on health and mindset. Hence it is very critical to building safer and pleasant roadmap , that emphasizes and enables empowerment and self-organized organizations.    Few steps that can enable a pleasant travel are: Simple steps to a pleasant journey by Sushma   Leadership Buy in: This is very critical and I write about this all my blogs, as they could be the major inhibitors of change if not in sync. They need to be made aware of what this change could bring and how it would impact their organization. It is usually a myth among leaders that, Agile implies delivery in 2 weeks and a fast track tool to production, as suppose to the reality which includes complete mindset and organizational change. Hence it is important that they understand the impact during ideation than in the middle when their struggling direct report squeal up to them!! Coach management on enablement than heroism. As many Agile leaders define, it’s an attitude change to build enablement and empowerment within teams than building a dynasty of managers. Motivation is intrinsic and not something that can be driven by bonus or money. Recognize and Build optimal teams:  Team structures could vary between organizations; some work the best in a matrix wherein others may build Agile teams with single reporting structure. Organizations with open culture and fearless platforms are optimal for Agile teams. During initial transition, it is always advocated to have diverse reporting within the teams to enable health conflicts and feedbacks. Define Agile techniques and cadence: Build techniques that optimize the efficiency of transformation. During inception phase of transformation, it is always encouraged to have all ceremonies planned in accordance to the Agile framework. Many organizations prefer to have sprint planning of a 2-week sprint to be 1-2 hours and end up creating half-baked stories that do not sync with the definition of readiness. I have noticed teams that conduct 3-4 hours of sprint planning build stronger and optimal backlog for the team to build appropriate product that syncs with the vision. Coach your teams: And Practice what you coach, be an example. Be a leader to harvest leadership among employees. Build Fearless platform of speech. Retrospective: Identify key areas that need further iteration of change, build a plan and implement.    Agile Mindset: Enable teams to identify the Agile way!! Encourage an environment that seeds openness, transparency, and fearless speech. Build a collaborative mindset, a place where someone swims right in front of a shark to save their peer. Integrate Technology: It is always important to facilitate the behavioral change with technology that facilitates this change. Build stronger CI/CD, modularization, and automated testing. It is critical that the system and architecture promote the agility of the teams. The simplicity of tools also plays a vital role in encouraging agility among teams. Tools and Reports used to assess Agile maturity need to be transparent and manageable.   Going to @mcottmeyer 's On Leading Large Scale Agile Transformation. Not really sure if it will scale for our org at scale in the engerprise — mheusser (@mheusser) May 5, 2017 Complex tools can lead to frustrations and resistance towards the change  
Rated 3.0/5 based on 1 customer reviews

Agile Transformation In Large Organizations

254
Agile Transformation In Large Organizations

As agile readers, I am sure we all agree that LARGE is a relative term and may not be defined just by number. What does LARGE imply?

  • Is it something that has employees above 5000 but completely structured 
  • Or an organization that has <1000 employees but complex due to the silos, style, and technical limp.

 My personal definition - Large organization can be defined as an organization that has fostered distance between employees with process, silos, hierarchy and complexities. Numbers don’t reflect the magnitude during the transformation, but the complexities and the mindset to change.

Over the years I have realized, transformations of companies with 10K+ employees and slightly structured, will take same amount of effort as an organization with 1000 employees but unstructured !!!
Similar to the two piles of books below. Where does one take more time to find a book? And the answer defines the magnitude of LARGENESS. 

Let us assume, for the above pictures, if the problem statement is given as: 

Find a book called “Why Agile?”
Scenario 1: Considering the books are thrown and piled all around the room, one would take almost days together to get the above problem statement resolved, despite the fact that it is such a small collection of books. 
Cause of Delay:

  • Not structured 
  • Chaos and redundancy

Impact: Cost of delay

Scenario 2: Books are arranged in an orderly fashion, could be alphabetical, year based, genre etc. !!!  Also, this is digitally transferred to make the search easy via computer seen in the picture. In this scenario, one may not take more than 30 mins to find the book stated in the problem statement

Impact: Efficiency  

In a software world, efficiency should be the measure of Largeness. Lower the efficiency higher the complexity and the magnitude of measure. As, despite the number, journey of transformation is the same. It has to go through the same cycle of form, storm, and norm and perform in order to successfully adopt agile transformation.


Irrespective of the approach or magnitude it is always important to understand the organization prior to committing to transformation or adoption. 

An analogy to Agile transformation is, similar to any long journey, it gets as pleasant as the people surrounding you; you get a grumpy passenger your trip gets grumpier. There are many articles and blogs that describe impacts of people and surroundings on health and mindset. Hence it is very critical to building safer and pleasant roadmap , that emphasizes and enables empowerment and self-organized organizations. 
 
Few steps that can enable a pleasant travel are:

Simple steps to a pleasant journey by Sushma
 

  • Leadership Buy in: This is very critical and I write about this all my blogs, as they could be the major inhibitors of change if not in sync. They need to be made aware of what this change could bring and how it would impact their organization. It is usually a myth among leaders that, Agile implies delivery in 2 weeks and a fast track tool to production, as suppose to the reality which includes complete mindset and organizational change. Hence it is important that they understand the impact during ideation than in the middle when their struggling direct report squeal up to them!! Coach management on enablement than heroism. As many Agile leaders define, it’s an attitude change to build enablement and empowerment within teams than building a dynasty of managers. Motivation is intrinsic and not something that can be driven by bonus or money.
  • Recognize and Build optimal teams:  Team structures could vary between organizations; some work the best in a matrix wherein others may build Agile teams with single reporting structure. Organizations with open culture and fearless platforms are optimal for Agile teams. During initial transition, it is always advocated to have diverse reporting within the teams to enable health conflicts and feedbacks.

  • Define Agile techniques and cadence: Build techniques that optimize the efficiency of transformation. During inception phase of transformation, it is always encouraged to have all ceremonies planned in accordance to the Agile framework. Many organizations prefer to have sprint planning of a 2-week sprint to be 1-2 hours and end up creating half-baked stories that do not sync with the definition of readiness. I have noticed teams that conduct 3-4 hours of sprint planning build stronger and optimal backlog for the team to build appropriate product that syncs with the vision.
  • Coach your teams: And Practice what you coach, be an example. Be a leader to harvest leadership among employees. Build Fearless platform of speech.
  • Retrospective: Identify key areas that need further iteration of change, build a plan and implement.

  

  • Agile Mindset: Enable teams to identify the Agile way!! Encourage an environment that seeds openness, transparency, and fearless speech. Build a collaborative mindset, a place where someone swims right in front of a shark to save their peer.
  • Integrate Technology: It is always important to facilitate the behavioral change with technology that facilitates this change. Build stronger CI/CD, modularization, and automated testing. It is critical that the system and architecture promote the agility of the teams. The simplicity of tools also plays a vital role in encouraging agility among teams. Tools and Reports used to assess Agile maturity need to be transparent and manageable.

 

Complex tools can lead to frustrations and resistance towards the change
 

Sushma

Sushma Arvind

Blog Author

Sushma has a history of turning break even projects into profitable projects through delivery of cost saving solutions via effective process &amp; tool management. With over 15 years of experience in delivery , she has been fortunate to work with multiple organizations that adapted different delivery framework. She has experience in leading large organization transformations and re - engineering delivery that mapped to success and cost . Her belief is "Agile is an attitude to get done with quality, adaptability and retrospective" and there is no single prescriptive process that can fit every problem.
 

Join the Discussion

Your email address will not be published. Required fields are marked *

Suggested Blogs

Agile and ITIL: Friends or Foes?

Today, many IT organizations are expanding their IT businesses using ITIL (Information Technology Infrastructure Library) and other valuable industry frameworks for ITSM (IT Service Management). They are focussing on improving their service quality. In addition to quality, companies are trying to build agility, with the emergence of new technology and methodology like Agile Software Development.  Recent reports from ITSM.tools emphasized upon the factors that organizations measure during work in IT industry. The following image shows the statistics of the aspects, as measured by the organizations. Even after the use of these methodologies and technologies to speed up delivery, IT operations were not able to get on with the fastest delivery rate of IT services. So industries carried out many discussions regarding the combination of ITIL and Agile- Is it possible that both can coexist within an organization? Can ITIL and Agile play major role after merging service quality with agility and speed? Will Agile and ITIL together becomes friends or foes? The article has tried to address this as precisely as possible.  ITIL provides a framework for the governance of IT from the business and customer outlook. ITIL is referred as the best practice framework for IT service management (ITSM). It focuses on continuous measurement and improvement in the quality of the IT services delivered to the customers. According to the ITIL Practitioner course, ITIL includes 9 guiding principles as follows: Focus on value Design for experience Start where you are Work holistically Progress iteratively Observe directly Be transparent Collaborate Keep it simple Agile is a set of processes for software development which fulfills customer requirements and solutions from the cross-functional teams. Companies need to adopt the key points from the Agile Manifesto to achieve Agile ITSM. The key points are as follows: Individuals and Interactions over processes and tools Working Software over comprehensive documentation Customer Collaboration over contract negotiation Responding to Change over following a plan. If these Agile practices are matched with the 9 principles of ITIL, you will find some striking similarities. ‘Working software’ is an equivalent to ‘Focus on value’- which means develop the right things, the valued software can be used by the customers. The ‘Keep it Simple’ principle clearly explains how close ITIL and Agile are! This principle suggests to act quickly and deliver quality, which is the same as ‘Responding to change’.    One of the main hurdles in the integration of Agile and ITIL is the truth that ITIL follows sequential framework, whereas Agile is an iterative approach where Minimum Viable Products (MVPs) are constructed and updated in a very short period cycle. This may create instability. However, businesses and their clients look for stable and agile IT services. DevOps can be the solution for it. It is a more endurable approach for bringing these two contrasting approaches to enable stability and agility (Development and Operations), together. DevOps is based on the combination and communication between Development (Dev) and IT Operations (Ops). DevOps provides technical practices to produce a software. The goal behind DevOps technology is to automate an application delivery and workflow of the processes (planning, design, implementation, testing).  In future, there will be a lean, fast and agile IT service management. According to Gene Kim, thought leader and co-author of The Phoenix Project- “Patterns and processes that emerge from DevOps are the inevitable outcome of applying Lean principles to the IT value stream […and] ITSM practitioners are uniquely equipped to help in DevOps initiatives, and create value for the business”. Essentially, considering the diverse perspectives, Agile and ITIL can exist without some major conflict. Agile and ITIL can very much go hand in hand, because this combination allows IT organizations to have a new culture called, Agile ITSM. ITIL will offer a framework for stable and quality-assured service rapid delivery, whereas DevOps will ensure to provide the continuous stream of improvements. Due to the alliance of Agile/DevOps and ITIL principles, Agile ITSM can provide guidelines for service and the speediest delivery in an Agile way!   
Rated 4.0/5 based on 20 customer reviews
2190
Agile and ITIL: Friends or Foes?

Today, many IT organizations are expanding their I... Read More

The Role Of a Project Manager in an Agile Environment

Let us first understand the Project Manager’s role in a traditional/waterfall environment. The PMBOK (Project Management Body of Knowledge) Guide - 4th Edition states that a Project Manager is known to be responsible for successful implementation of a project through the five stages/processes of a project lifecycle: initiating, planning, executing, monitoring and controlling, and closing the project – see figure 1. Included in these phases is identifying requirements, management of stakeholders and balancing the competing project constraints arising during the project. The project constraints include the: Scope, Quality, Schedule, Budget, Resources, and Risk An effective Project Manager is required to be knowledgeable about Project Management, apply this project management knowledge in order to drive their performance and that of their team, and have positive personal attitude as it will be spread out to the project team. These are key characteristics of an effective Project Manager. The Role of the Project Manager in an Agile Business https://t.co/NNVUV0lT4C via @BrightTALK #projectmanagement #agile pic.twitter.com/DdMBYMIq2A — Capterra Project (@CapterraPM) March 1, 2017 PRINCE2 (PRojects IN a Controlled Environment version 2) is another waterfall methodology and states that the project management project lifecycle and processes are: starting a project, initiating a project, directing a project, managing a stage boundary, controlling a stage, managing product delivery and closing a project – see figure 2. A Project Manager is responsible for ensuring that the team performs and delivers the product accordingly as initially defined with Management ( the Project Board). The Project Manager also ensures that there is clear requirements communication between the project board and the project team to ensure quality delivery. The Agile methodology seems to be emerging very fast with most organisations requiring to do away with waterfall and utilize Agile rather. For some organisations, Agile has proven to work well in the sense that implementation happens timeously in small chunks of releases instead of a big-bang implementation that has a high probability of failure if other detailed risks and issues are missed. The stages of Agile product development life cycle include: requirements gathering, planning, design, development, release, and track and monitoring. Agile aims at releasing small chunks of the full product in sprints (popularly defined in a two week period) rather than a big bang full release. The cycle is iterated until the full product is developed and released. I have worked in a fully waterfall environment, as well as waterfall but being so-called Agile, and I am currently working in a seemingly fully Agile environment. There are different roles in this fully Agile environment of which they include: Project Manager, Product Manager, Product Owner, Scrum Master, and others. These roles are a combination of waterfall and Agile roles although we call ourselves fully Agile. We – as a team call our environment fully Agile, absorbing this information from our organisation’s Senior Management, who manage appointment of these roles.  A Project Manager works very closely with top management for strategic decision making. A Project Manager still maintains the role of being the sole responsible person for successful implementation of the quality defined product, and also supports the team throughout the iterations and shield them from distractions. Although there are different frameworks in Agile, the roles within Agile do not differ much, for example, the role of a Scrum Master. A Scrum Master works very closely with the Project Manager to close the communication gap between the project team and top management. A Project Manager manages project/product risks while the Scrum Master manages the team’s performance and impediments. In waterfall, a Project manager works very closely with the delivery team while in Agile, the Project Manager works with the team indirectly – managing team communication through the Scrum Master. Although the Project Manager is responsible for successful release of a quality product, the Scrum Master is the one that manages the delivery of this quality product while working with the delivery team, since the Project Manager does not communicate directly with the delivery team. The Project Manager manages time delivery more than quality. The Scrum Master manages quality delivery of the product. The Scrum Master also manages impediments as well as the development/delivery team while the Project Manager manages risks and address them with strategic management.  Then the question arises, do we still need Project Managers in Agile? Although there is no Project Manager role in any Agile methodology, in real work life environments, we still have Project Managers. To differentiate the two roles, both are responsible for delivery of a quality product. However, a Project Manager works strategically with the management team (project sponsor, project owner/requestor, etc.) to define the product’s epics, while the Scrum Master receives management defined epics from the Project Manager and work with the delivery/development team to break-down the epics into features, stories and tasks. A Scrum Master also manages impediments from at development team level and resolve what is possible in his capability. Impediments that are rated high are now channelled to a Project Manager to be managed strategically by the management team.   Although organisations that are going Agile see a need to diminish Project Managers’ roles in their organisation, it will be challenging as there is also still a need to understand roles like Product Manager – which is a strategic role as well and might at times overlap with the Project Manager role, if they work together in a team to deliver the same product. Are Project Managers still required in Agile? According to my opinion and how things are working out in my organisation, my answer is actually yes! Project Managers are still required and must work closely with the Product Managers and Scrum Masters. Although there can be a confusion which can cause conflict of responsibilities between a Project Manager and Scrum Master at times. Figure 3 illustrates clarity of the Project Manager and Scrum Master roles.
Rated 4.0/5 based on 2 customer reviews
1103
The Role Of a Project Manager in an Agile Environm...

Let us first understand the Project Manager’s ro... Read More

Built Instability Fosters Innovation New Product Development

As funny as the Calvin and Hobbes comic is, it conveys an important message about how creativity and chaos almost always go together. In 1981, when Honda was developing Honda City – the innovative first-of-its-kind compact car – an executive in charge of its development remarked, “It’s like putting the team members on the second floor, removing the ladder, and telling them to jump or else. I believe creativity is born by pushing people against the wall and pressuring them almost to the extreme.” Haven’t most of us experienced this at some point in our lives? The idea of “built-in instability” was first published in a 1986 Harvard Business Review paper, which kicked off the Agile movement. The paper names built-in instability as a top quality of new product development at leading companies such as Honda, Fuji and Canon. Well, what does built-in instability mean? Why is it important? How does it help teams succeed? Let’s address these questions one by one. What built-in instability means When a company’s top leadership does the following: establishes a broad but extremely challenging goal, does not provide a product definition or a work breakdown structure, AND offers the project team ample room for experimentation and failure … this is called built-in instability. The leaders have basically created an environment of constructive chaos to serve as a catalyst for creative output. Why built-in instability matters Honda’s leaders instructed the Honda City project team to develop “the kind of car that the youth segment would like to drive.” Do we see a goal here? Yes. But is the goal well-defined? No. Do we see what kind of product is expected? Uh, maybe. But do we see the steps to get there? No. With a goal like that, the only way leaders can expect the team to succeed is by letting them fail – to fail early, fail often, and fail forward. When a team has the freedom to fail and knows there isn’t a firing squad waiting down the road, it begins to break traditional boundaries. And companies that thrive beyond decades or centuries with avant-garde products do not get there with traditional thinking. This is why built-in instability matters. How built-in instability fosters success Look at the Honda City team’s goal again: to develop “the kind of car that the youth segment would like to drive.” A broad goal like this naturally demands cross-disciplinary work across a broad spectrum of organizational functions – market research, finance, planning design, production, testing, sales and service. When the team wants to succeed while having the luxury to fail, the built-in instability fosters collaboration among individuals from various functions. In the words of a member of the Honda City team: “You then start thinking in terms of what’s best or second best for the group at large and not only about where you stand. If everyone understands the other person’s position, then each of us is more willing to give in, or at least to try to talk to each other. Initiatives emerge as a result.” In sum, what we today use as Agile/Scrum or other modern methodologies essentially relies on built-in instability. By giving teams the freedom to fail, the process encourages a DNA of experimentation, learning, innovation and continuous growth.
Rated 4.0/5 based on 20 customer reviews
1599
Built Instability Fosters Innovation New Product D...

As funny as the Calvin and Hobbes comic is, it con... Read More

other Blogs