Posted September 12, 2012
A Scrum Team's Journey to High Quality: Day 1
In the last few years, I have been with different teams been on different journeys to "become agile"; that is to have the discipline, the tools, the communication, the management support and the environment to deliver high-quality software and services that our customers and end users love.
A few weeks ago, I joined a new journey, a caravan doing Scrum already, with some challenges - as with all development teams.
I've taken some time during these weeks to read, and re-read, some relevant books, for example:
I realized that what all these books tell us about are the stories - after the journey, when coming home.
When teaching agile methods, I also tell stories about things we're "done" with, or at least have figured out are quite organized, and (in real practice) agreed upon and a fit working process around. I show the good examples of visual backlogs, clear unambiguous test documentation, examples of working Kanban boards, and tell stories about when communication with businesses have floated smoothly and of the happy times when our team has been playing squash, eating together, and taking care of each other.
Reading all of these books, you come across a lot of success stories.
You don't often hear about the journey to get there: The chaotic sprint planning meetings, the never ending retrospectives, the more confusing than clear daily Scrum, the wobbling limited work-in-progress column, the ability to see thousands of improvement areas and the inability to deal with them, the frustration of not being where we want NOW, the excluding of people such as maintenance, QA, UX or other "non-coding" roles, the failures, the stumbling steps to get at least ONE automated test working, and the backlash to ad-hoc- or waterfall thinking.
So, I think it's time to tell that story.
A couple of weeks ago our team defined two goals for the process:
- In six months, all the "cogs" in the company should work together more smoothly (including dev, test, marketing, sales etc.)
- In six months we will have a quality process that’s a natural part of the overall work process and is agreed upon and respected by everyone in the team
A few days after the team agreed upon these goals our QA expert, Margaret Thomas, stated this in another way.
"We're going from quasi-agile to pure agile. It's gonna be messy on the way. AND we need to include Marketing (what!?) in the process if it's gonna be pure agile. And I'm learning a new toolkit". I'll add that every team member is learning a new toolkit, including me - ScrumMaster.
Even though some, or all, of us have worked in several agile teams before, I realized that this is a totally new journey for us, just as every mountain to climb is a new challenge with unexpected events even for an experienced climber. Every agile journey is unique. The tools and methodology our team will select to use will not be the same as in the other teams we've been on. The way forward is going to be different here. The things we meet on the road are going to be different. People are different. History is different.
I bring my bag of traveling gear and tools and will see if any of those will work together with the team's traveling gear and tools, and I look forward to seeing what will happen the next few weeks as well as the next six months.
The goal is a start! To know which mountain to climb will for sure make it easier for us to get there!
I have been developing software in different roles for 15 years. In 2005 I first started to work with Scrum, Extreme Programming, Kanban and other Agile methods. For me, that was something real to hold onto, usable guiding principles, practices and rules, something else than the abstract document-heavy project models I had learned before. The built-in practice of continuous learning in all these agile methods is something that I believe in and have seen work in different contexts. Today, I work as a ScrumMaster in one of SmartBear's product development teams.