Introduction
There are numerous articles and books about what agile looks like in practice, but there are very few resources that explain how to move from your existing process to a more agile framework. This white paper provides an overview of a practical, low-risk approach to moving to agile.
Understand the Principles
As an agile coach, I meet new clients every day and am amazed at the different perspectives on what agile is. I often hear agile perceived as:
- “A way to deliver stuff quicker”
- “A process for empowering developers so they do not have to wait for requirements.”
- “A way to stop the business from asking us when we will be done”
- “A method that does not require documentation”
- “It's that daily stand-up thing we do”
- “It's eliminating the need for project plans”
The perspectives are interesting and diverse. Why is there so much confusion? It is because when we first hear about agile, it is often from a colleague, and the colleague tells us about a specific practice or process he or she is using. Instead of telling us the value he or she is getting from agile, he or she gives us the details of the practice he or she is using, such as the daily stand-up, user stories, or his or her “self-organizing” team.
The confusion gets amplified by the telephone game. We often hear about agile from a friend of a friend, who knows someone who spoke to someone who uses agile. Something usually gets lost in translation, and we often get a distorted description of the practices being used and the value they provide.
To truly understand what agile is and the value it provides, we refer to The Agile Manifesto, which can be found at agilemanifesto.org, and read the 12 principles outlined by the group that started agile in 2001. In abstract, the 12 principles promote:
- Satisfying customers with timely and accurate delivery of software
- Recognizing that project discoveries cannot be eliminated with extensive planning
- Having the customer and project team collaborate and work together toward the goal
- Keeping the team motivated by providing a good work environment and a sustainable workload
- Removing waste and misunderstandings in communications by interacting face-to-face
- Being more effective through team self-organization
- Pursuing continuous improvement and reflecting frequently on how to be more effective
- Deliver code that is extensible
- Using numerous metrics but mainly focusing on how much software is working or complete
If you are considering a move to agile, or already using it, I suggest going to The Agile Manifesto website to make sure you are getting all of the value you can out of your implementation and that you are clear on the intended goals and benefits of agile.
Understand Your Needs
Once you understand what agile really is, you need to assess how agile can help you with your business problems. Agile will be most successful if you can tie it to your specific needs (Exhibit 1).
Some of the common reasons I see companies moving to agile are:
- The need to reduce cycle time. We have numerous project requests and our competitors are often beating us to market.
- The need to adapt mid-project. We cannot plan out all of the risks and potential issues in a project at the start. We have discoveries mid-project and we are often paralyzed by them.
- We struggle with transparency and status. If you ask two project team members where we are on a project, you are likely to get two unique answers.
- We do not deliver quality products. We rush to get to market and then spend many months fixing production bugs.
• Exhibit 1 - Agile tied to a specific business need.
- We are not efficient. It seems like we have a lot of waste in our life cycle. We do many steps that cannot be correlated to successfully
delivering a project or customer value.
These reasons are good ones for moving to agile. When I get a list such as the one above, I ask the company to prioritize the reasons, and we will start our agile rollout by addressing the most important reasons first.
You may be wondering if there are any reasons that do not justify the move to agile. There are quite a few. When I meet with a company requesting my services I often tell them that agile will not:
- Correct poor business strategy
- Fix issues with your legacy code
- Eliminate the need to make tough trade-off decisions
- Make a poor performer a great performer
- Improve your relationship with your significant other (but you may come home happier if you use agile)
Once you correlate your needs to the areas that agile helps in, you are ready to determine the level of agile you can digest effectively.
Understand Your Capabilities
To continue on your road to agile you need to determine how to roll out agile with minimal impact on productivity. Agile will slow you down initially and if you start by trying to move to a mature level of agile, across your entire organization, you may find that the chaos is overwhelming and the risk is great to your business.
We can mitigate this risk by assessing where you are today and the level of agile your company can digest without huge repercussions to project delivery.
The Virginia Satir Curve displayed in Exhibit 2 demonstrates what happens when an organization pursues a major process change. A major change results in a major hit to productivity. In many cases this may require you to ask your customers to accept no deliveries while you learn how to use your new process.
For most companies, this is not a viable option. Customers will find another place to get their needs met if you ask them to accept a huge delay on their requests while you roll out agile or any major change.
Exhibit 2 – A major change leads to a major loss in productivity.
This issue can be addressed by limiting the amount of change we pursue at a given time. We can choose a few agile practices to pursue and minimize the impact to productivity and customer satisfaction. Exhibit 3 demonstrates this concept in practice. A company has laid out five levels of agile practices to pursue, and the company is rolling out the changes
iteratively throughout the year. By using this process, the company can change and improve the process with reduced impact to productivity.
This approach has a secondary benefit. Rolling out agile is as much a cultural change as a process change. By rolling the process changes out iteratively, the organization is giving the culture time to acclimate to the agile principles and mindset.
Exhibit 3 - Rolling out agile iteratively to reduce impact to productivity.
We can pursue this iterative goal by assessing the organization. This can be done through in-person interviews, review of the existing process, and the use of numerous agile survey tools that are available. Once you have assessed your company you can determine which practices to roll out initially, with minimal risk and resistance, and then lay out a plan to increase agile maturity over time.
Pilot, Learn, and Scale
Once we understand the initial agile practices we want to pursue, we usually test our assessment work by running a pilot agile project.
Exhibit 4 - A core team designs a process.
A pilot project allows us to test our assumptions about the amount of agile we can absorb, and it will also initialize the cultural transformation to agile throughout the company. The pilot will be discussed in the break room by employees not working on the pilot and agile will move from theory to real-world application within your company.
An important part of the pilot, and also scaling agile, is the creation of a core team (Exhibit 4). A core team is a cross-functional group that usually includes representation from all of the functional areas. The core team works with your agile coach to design your custom life cycle, review pilot results, and evangelize agile throughout your company. The core team usually has a limited number of managers to avoid a political environment, and instead, there is a focus on collaboration to create the best process possible. The core team also understands the existing customers and processes better than an agile coach and can make a huge contribution regarding which practices will be effective within a company.
We usually choose a pilot that:
- Is short and can be completed in 8 to 12 weeks
- Has a medium to high business priority
- Touches most of the functional areas within a company
- Has an internal customer
We like to have a short pilot so we can get quick feedback on whether the practices we are attempting are working.
We like to have a medium to high business priority pilot so that there is a level of pressure and visibility on the project. If the pilot is low priority there will be less concern if milestones are missed or if planning sessions run over. Conversely, if a project is urgent, you may be putting your company at risk while you pilot agile, which is not recommended.
We like to have a project that touches most of our functional areas so we can learn as much as possible about our capabilities, and detect potential cross-functional issues.
Last, we like our pilot project to be driven by an internal customer, such as a product manager. The logic behind this approach is that “real” customer may not be tolerant while you work out the issues with using agile, and might start dictating that you use your old process so that they can get their product.
During the pilot, the project team will interact with the agile coach and core team and discuss issues they uncover while trying to apply agile classroom training to a real project. At the conclusion, all of the discoveries will be reviewed, and the core team, management, and the agile coach will decide the next level of scaling to do with agile. If the pilot discoveries were significant, another, single agile pilot may be pursued. If things went well, we can pursue using agile on several pilots and continue to scale out until agile is being used across the entire portfolio.
Summary
Your approach to becoming agile is as important as learning the agile practices. Use a practical approach to minimize risk to your organization as you increase agility. Involve employees from all areas of the company to increase buy-in and ownership. Create an agile framework that thrives in your situation, and most important of all, make sure you have a clear vision of why you are moving to agile and the business goals you will be addressing with the rollout.
