When transitioning to agile, the key is to shift your thinking. Here are three critical areas that you should consciously work on changing.
- Failing. No one wants to fail, but in agile, failing is necessary to learn. The team needs to be put into positions that allow them to learn even if it means failing. One example of this was a scrum master that I worked with who thought his role in the refinement sessions was to question every estimate. Talking to him, I found that he did not realize how this appeared to the team. He thought he was helping; the team thought he did not trust them. In addition the majority of the time in refinement was spent explaining to him the technical aspects of each story for the team to justify their estimate causing the team to constantly be on the defensive. When I talked with the scrum master, he seemed obsessed with not letting the team have an incorrect estimate. When the scrum master changed his approach and embraced the idea that the team could learn from incorrect estimates, the refinements became much more effective and the team’s confidence increased.
Don’t try to save the team. Encourage continuous learning by allowing your teams to work on their own. - Process. Process will kill your agile transition. Too much process will turn agile back into waterfall without the check points and oversight that waterfall possesses. Each team should have the flexibility to adapt based on their own needs. We develop processes to make ourselves comfortable; process is seldom a benefit to the team. I’ve seen managers attempt to “legislate” the standup ceremony to use the exact same process for multiple teams. Each of the teams was at different stages in their agile journey. The scrum master should be free to guide the team to use a method that works for them. Before implementing any process, think “What problem am I trying to solve? Is it really a problem, or am I falling back to my own comfort zone?” Processes keep us from innovating.
Encourage exploration by minimizing process. - Think incrementally. In waterfall we had huge projects that took years to do. They delivered less than what was originally promised and much of the functionality was outdated before it was available. In agile, we break the work down looking for the smallest amount of effort that will deliver value to our customers. As information is available, we iterate on the product. A stakeholder once told me that “everything” was important for their MVP (minimally viable product). This response caused the scope of the MVP to be very large and lengthened the time for the first delivery. I realized that waterfall methodology taught us to ask for the entire budget and the entire scope of functionality. After I explained that iterative development is expected since we are building dynamic products not working on time bound projects, we were able to work together and scope out a suitable MVP that delivered value quickly.
Take steps to think incrementally.
Transitioning to agile does require a major mind shift in several areas. If you focus you and your organization on shifting these 3 areas, you will see major improvements in your agile transition.
**Views expressed in this article or any other article written by me (Joanne) are my personal views based on direct experience, research, and networking within the industry. Views expressed are in no way the views of any employer past or present. It is solely my opinion. Likewise, examples given are not directly related to any specific employer.
In addition, this article represents my understanding and thoughts on this topic at the time it was written. My thoughts and opinions do change from time to time. My ideas evolve as I get more experience and encounter different circumstances. I have an agile approach to learning. Looking forward to hearing your thoughts on this article. I hope you find it helpful.
