If you’re fresh out of Certified Scrum Master training, you are likely invigorated to start applying the Agile and SCRUM based techniques to your next project. Based on the classroom exercises, you’re excited to try new concepts and apply the magic cure-all that will solve all waterfall-based project problems. After all, your two-day training class and one online test later makes you a certified Scrum Master!
(Well, that’s the way I felt when I left class.)
Then you get back to work and the real world hits you—implementing Agile isn’t going to be as easy as you thought. After a few discussions explaining Agile and working with teams to adopt Agile practices, you realize:
1. The business customer has no desire to write the user story.
They gave you the requirements months ago in a business requirements document. The development team should know what needs to be done, so just call the customer when it’s ready.
2. Everyone is already Agile, and they don’t need a formal process like stand-ups, backlog grooming, sprint reviews or retrospectives
Everyone is using Agile as the buzzword to hide their lack of processes and continue to implement in a waterfall manner just in two week chunks.
3. The teams follow sprints but extend the sprint end date to accommodate just one more feature.
Sprint start and finish dates adjust based on the product owner’s need to add one more feature into the sprint. The number of committed stories grows mid-sprint and impacts other planned work. The team also extends the sprint because of defects that require more time to finish the work.
4. The team doesn’t see the value in story points because they are too abstract.
The team tried to do story points but didn’t see the value in it because they couldn’t equate it to a unit of time. Hours worked just fine for them so they didn’t see a need to change.
Do any of these experiences sound familiar?
Adopting Agile is an Exercise in Change Management
Adopting agile is an exercise in change management for a number of reasons:
- Software isn’t an order by number model.
- Existing project teams have good practices.
- Agile techniques can threaten team members’ roles, contributions, and control within a project.
- Agile affects both the business partners, the IT organization, and any 3rd party vendor engaged in the project.
Working with project teams to adopt Agile practices requires awareness, training, and organizational change management. If you walk into your organization fresh from a CSM class, you likely find yourself hitting change management roadblocks. I could refer to Lewin’s organizational change model or Kotter’s 8 step change management model, but I think these words are better spent identifying the tactical steps you can take to implement Agile in your organization.
8 Practical Steps to Implement Agile Techniques in an Organization
1. Develop an Agile overview for business and development teams.
Yep. You’re going to create a presentation.
You’re fresh from CSM training, so the course materials will provide plenty of reference material to describe how Agile techniques with SCRUM practices can be implemented. Once the presentation is developed, share the ideas with the senior leaders in your organization, as well as the management level thought leaders. Generate an interest in trying something different.
I developed two presentations for my organization: Agile 101 and A Day In the Life of an Agile Team. One presentation provide an executive level overview of Agile techniques and the other provided a detail walkthrough with product backlogs, sprint plans, user stories, and burndown charts. I presented at a few executive leadership meetings and started to socialize the concepts with other directors and managers. Some managers took interest and others preferred to continue working their own way.
Slowly, the team started to engage and ask if I had any ideas on how Agile can help their project.
2. Get buy-in to try something different for two weeks.
Ask the team to operate differently for 2 weeks. Introduce the SCRUM concepts and sprint ceremonies and get buy-in to try another way of working. If the team dislikes this new way of working, there will be opportunities to improve upon it and change it.
3. Facilitate breaking down one large business requirements into a backlog of user stories.
BRD typically have an inventory of requirements. Ask for an important feature in the BRD and break it into user stories. Organize the most important stories or features into the first sprint and size them appropriately for a 2-week sprint. With Agile, you want to show how stories can be delivered in slices by thinking small and delivering frequently.
4. Don’t worry about story points.
Story point estimation always seems to confuse new teams learning about Agile. As a guideline, split the user stories into 3-day durations and simply rank them in order of complexity.
This gives enough flexibility to get started with a sprint without worrying about T-shirt sizes, Fibonacci sequences, or abstract estimation.
5. Execute the sprint using the daily stand-up, demonstration, and retrospectives.
Set the expectation that each team member move’s their card across the sprint board from To-Do, Doing, and Done. As teams get more experienced with SCRUM and Kanban, they can add other columns based on their development process.
At the end of the sprint, count all the completed cards, demonstrate the functionality delivered and conduct the retrospective. Compare the number of planned cards at the beginning of the sprint to the number of completed cards. Inquire about what could have been done differently to meet the original commitment.
6. Use the feedback and determine if the team wants to repeat the process again.
If the team sees success with Agile, they are likely to repeat it and gain the benefits. Within two weeks, you won’t deliver a major software release but you will get faster feedback on what’s working within the team as well as feedback from the business on the development.
The roles within the team can change gradually. Don’t walk in ready to throw out the project manager because SCRUM says there are only the Scrum Master, Product Owner, and Team roles. Use the feedback loop to improve the team’s delivery.
7. Hire a consulting team that delivers projects with Agile expertise.
I didn’t learn all this practical knowledge from being “book Agile”. Sure I read a lot of books on the topic but my real learning came when my company hired a development company to work on a new software launch. They delivered everything using a SCRUM framework with Agile techniques.
The team was comprised of the consulting company and the internal development team. The consulting company led the Agile practices and delivered the project. However, our development team worked alongside them and participated in the sprints. Consequently, the internal development team walks away with a better understanding of Agile practices and were able to repeat them on their own.
It is difficult hiring a consulting company to simply train. It is much easier if they can deliver a project and the internal team can learn by doing over months rather than a few weeks of a consulting engagement.
8. Take one Agile team and split into two.
Once you have one team working well with Agile, look for opportunities to split the team into two teams and partner them with new team members looking to implement Agile practices. One team becomes two, two becomes four, and four becomes eight fully functioning Agile teams. By spreading skilled Agile resources across the organizations, each team learns how to adopt Agile practices as well as provide new learning opportunities for each team member.
Change Isn’t Easy
Training classes provide a safe and simulated learning environment. The real challenge is applying the organizational change management to make Agile work in a real-world environment. Challenging and trying to change a team’s process can threaten a team and be met with resistance, despite the intention or benefit. By applying these eight steps and managing through the challenges identified earlier, you’ll have better success implementing Agile within your organization.
