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 for a number of reasons:
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.
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 s...
(RSS generated with FetchRss)