Six months ago I had more questions than answers about Agile.
Five months ago I had serious reservations about Agile.
Today, I can say that I am a believer. With only one reservation.
It wasn’t the overwhelming positive press about Agile. In my experience, you can hear 100 things opposed to your point of view and cling to your beliefs even tighter. So the positive news didn’t hurt, but it didn’t change my mind.
The change was a result of a Scrummaster workshop and seeing it in action. The workshop dismantled three of my biggest misconceptions about Agile.
The First was that…
- Agile is lax on Technical Rigor
And the assumption is that where a process is lax in technical rigor, there’s poor quality. In nearly everything I’d read about Agile to that point, I’d seen the phrase “good enough.”
Unfortunately, in my mind, “good enough” doesn’t have a positive connotation.The workshop turned that concept on its head by explaining that Scrum is a process. What we bring to the process is up to us. Responsibility for technical rigor is put back squarely on the shoulders of the team who have to deliver working code and demo it to the customer at the end of the sprint.
The emphasis here should be on the phrase “working code”. In Waterfall, we have milestones where we deliver documents, but there is never a chance for the customer to see working functionality until the end; when we may have completely misunderstood what they wanted. Or the business environment has changed.
- I would hate the process
The role of Scrummaster did not sound appealing. I became a Project Manager in a Waterfall environment and that was what I was used to: working with teams to define detailed plans, then tracking those plans to completion. Would all that change?
What I discovered was that the scope had changed from 12 months to 2 weeks. The Scrummaster still works with the team to plan the sprint and holds Daily Scrums to track status, but the focus is reduced to the window of a sprint – not 9 -12 months.
What I viewed as a side benefit to being a Release Manager in a Waterfall environment (working with smart people, facilitating and watching as they solved problems) became the focus of my role as Scrummaster. The key question: How can I help you remove any obstacles?
- Agile can be used on any project
My final misconception was the idea, fixed in my head because of my familiarity with Waterfall, that Agile should probably only be used on projects with bleeding-edge technology or products with critical time to-market constraints. Those type of projects could benefit from the quick turnaround time and “good enough” quality would be delivered.
The workshop leader was adamant. Scrum could be used on any project. I had heebie jeebies in reaction because it seemed like an extreme answer (and I tend to distrust anyone who seems to have drunk the koolaid without considering the other side). I questioned whether Scrum would work on a project that required high reliability.
He reminded us that questions about reliability could be a part of the customer discussions about the functionality to be delivered in that sprint. The working code demoed to the customer must answer the question that the team asked when they made the sprint commitment: How do we know that it works? The answer should include input from the customer.
This would be a good place to draw this post to a close. It would be nice if I could say (as a former Scrum skeptic) that I have no more doubts.
Unfortunately, I still have my doubts about whether Scrum can be used on projects that require high reliability. The good news is that as a result of this workshop and my experiences, I am far more likely to consider its use when time to market is critical.
I know there must be some of you who have seen Scrum used on projects that require high reliability? Leave me a comment or send me a tweet, my id is jgodfrey.