Agile Development

Bad Assumptions and Agile Transformation

 Assumptions are everywhere; they are the foundation of everything we think, say and do. They save time by allowing us to take certain facts and situations for granted and let us get on with the business of forming and exchanging new ideas.
Sometimes we make assumptions when we don't fully understand a situation. It is a natural reaction to immediately fill in any missing information by making up our own assumption. Usually, at that time, we will fill out gaps with the assumptions that are most acceptable to us.
 
As an example, a functional manager, who has just lost a person due to not appreciating the role of that person, will make an assumption that a replacement is easy to find.    
Also, sometimes organizations will opt out to domain experts in order to validate their assumptions. However, what they often find are many experts with a range of opinions. At that time, an organization will usually choose to accept an opinion that is aligned with their own assumption. 
Here is another problem with assumptions that might be “surprising”-- they are often wrong.

Of course, right? If you make a decision based on little or no facts, your decision stands a good chance of being “wrong.”

Now, making the  “wrong” decision about what road to take during morning rush hour might not be a big problem. So what if you spend another 10-15min in your car?  However, what if we are talking about changing the way your company is developing an end product?  Then, stakes are certainly much higher. 
 
The following points are my take on the top 10 bad assumptions I see organizations make before starting with Agile Transformation.

1. “Once we implement Agile, our productivity will increase 10 times and quality will improve 5 times” – Some organizations might have seen these results, but it is certainly not the norm. As an example, I know many organizations that have improved time to market and user satisfaction by 20%-30% just by implementing Agile, and that is pretty damn good by my standards. However, I’m not able to recall any company that is producing their product 10 times faster just by switching to Agile.  
If you know one of these special cases, please let me know and we will do an in-depth study to learn their secret of success. 
 
2. “Based on our analysis, we can become Agile in 3-6 months or less” - I understand it might not be popular to say this to a CEO, but transition to Agile is a journey and not an event. I’m looking at it similar to my weight. I can go on a strict diet and lose weight fast, but if I continue with my old bad habits, eventually I will gain back those pounds. We should think the same way about Agile--as a lifestyle change for an organization.  
 
3. “Just by transitioning to Agile we will resolve our  _ _ _ (fill in the blank) organizational problems” –Agile will help you identify these problems, but it is not a tool for resolving them.  A dysfunctional organization will stay dysfunctional with or without Agile.
 
4. “Extreme Programing practices can be successfully implemented after a few days or weeks of training” – Changing how people perform their everyday work, such as writing a code in TDD, is one of the most difficult changes your team will go through during this transition, so be sure to think about long term.  
 
5. “We can successfully transition to agile without functional changes” – Agile is all about breaking down silos. Waterfall is based on silos where a particular group has complete ownership over a certain phase of a project. Organizations that are transitioning to Agile will eventually realize that some functional changes must be made to accommodate the new way of developing a product.
 
6. “With a proper training, our current staff will smoothly transition to a new role” - Agile is not for everyone, and some people will never fit in a new environment. Agile provides more freedom, but certainly expects much more from people. Just because someone was a good Product Manager, that does not mean he or she will be a good Product Owner. The same rules apply for the Scrum Master (old Project Manager) or Developer (old developer and testers).  In addition, there is always certain amount of people who are not willing to learn new skills.
 
7. “We can transition to Agile without an expert’s help” – There is so much information already published that you certainly have a good chance of succeeding in transitioning a small sized organization.  Where it becomes complex is in a mid-sized or large organization, where your transition will effect thousand or tens of thousands of people. The question of how to align a portfolio that includes hundreds of projects, how to restructure an organization to be optimized for delivering a product using new methodology, what to do with enterprise level reporting, or how to rollout Agile in large organizations is not available in any books. A good expert will help you craft and implement a transition plan by combining previous experience with the best practices, while also considering the current environment and culture. 
 
8. “We are transitioning to Agile, so we don’t need to think about a tool or product matrix” – Choosing a tool and knowing how you will measure team progress should not be the first priority, but it is certainly important information that needs to be ironed out during the first few weeks.  Management and stakeholders will want to know how your teams are performing, and it is very important during your transition to make information visible early on. Tools that will highlight the latest achievement of your newly converted Agile teams are especially important in large organizations where many stakeholders and executive management will not be able to attend team demos. 
 
9. “Our transition to Agile will not cost much at all” – Underestimating transition cost is one of the most common bad assumptions.  In addition to the more visible expenses such as team training, coaching and implementation of a new software tool(s), there are hidden costs of transition. 
Some of the hidden costs that organizations usually overlook are:
• Temporary drop in productivity – it usually takes 1-2 months before a team gets acclimated to new methodology. 
• Need for expanded training – Often, you will need to train different groups that are part of the product value stream in addition to training the core development team.  This is especially valid when software development is just one of the phases in the product value stream. 
 
10.  “We can find one person that will do it all” – The majority of Agile coaches are specialized in a certain area, so you will need different kind of coaches based on where your transition is.  As an example, initially you might want to find someone who will help you with coaching teams and someone for scaling.  Later on, you might want to focus your attention towards improving technical practices or providing advanced training to your product owners. All of these activities can require hiring an expert in each particular area.
 
 
Anyone planning to transition to Agile should carefully consider how many assumptions they are making.  Minimizing the number of assumptions will significantly increase the probability of successful transition.