Most of us don’t have the luxury of working on only greenfield projects that are not yet in production.
Most of us don’t get to work in an ivory tower separated far from the madding crowd.
Most of us have to do new development, support existing systems, get called in to help with quotes or other unplanned activities.
Working in Agile Sprints
In 2007 when I first started “doing Agile”, we all did Scrum. We planned a Sprint / Iteration / Timebox, worked exclusively on the items in the Sprint backlog and performed some ceremonies at the end of the week (review, retrospective, demo, measure velocity, deliver software etc). That was much better than the previous chaos and silos that existed, but as time went on we got greedy for more progress!
At McKenna Consultants today a small development team services a wide range of clients. Our team provides new software development, supports existing software, provides estimates for sales, writes technical documents for clients, consultants on creation of specs and plenty of other activities.
Having so many clients with live, mature systems means that things can change in a New York minute! We work in one week Sprints. So what do we do if a client phones up with an urgent change on Tuesday morning? Do we tell them that they have to wait until next week for their new feature? How long would we survive as a business with poor customer service like that???
Using a Kanban Board
We naturally evolved a Kanban approach. We didn’t know that it was Kanban at the time, it just seemed like the sensible thing to do. We would put our Sprint’s work on the board and if something changed mid-week we would simply add the new User Story to the Kanban board. Pretty simple really!
Our first board had columns on for:
- To Do
- In Progress
- Stuck
- Done
The next big change happened as our client-base grew. We worked out that whatever plan for the Sprint we created on a Monday was wrong by Tuesday as opportunities came along that we didn’t want to turn down. The whole concept of planning a Sprint was working against us! The solution was to spend £150 on a bigger board. I should also mention at this point that my preference is for magnetic white boards and index cards rather than standard white boards and post-its.
The bigger board enabled us to expand our “To Do” column to cover our entire team backlog, not just the work we were planning on doing in this Sprint. This changed our lives! Our Product Owner could now manipulate the entire backlog at the drop of a hat and was not limited to waiting a week to reprioritise work. The PO could introduce new User Stories, change the order and see the entire scope of the team’s work at a glance.
The golden rule we have observed since is that the PO can do whatever they like with the User Stories in “To Do”, but once a User Story has made it into “In Progress”, it cannot be reprioritised, removed etc.
There are some other pre-requisites for this system to work.
- First you have to have a good Product Owner with excellent backlog management skills. They need to have the time and ability to plan beyond the end of next week!
- Next you need to have small user stories so that you can react rapidly to change. In our team, we tend to do roughly two user stories per day per programmer. This isn’t a rule, it’s just how things fall out when your Product Owner is good and knows how to write small user stories that still make sense as features.
- You also need a lot of trust! You have to trust that your Product Owner will show good judgement when rearranging User Stories and will check with the technical team to ensure that he doesn’t create any technical problems with the reprioritisation.
I have a lot more to say about Sprints / Timeboxes / Iterations and what they are used for, but that will have to wait for another post…
In the meantime, don’t be constrained by your process. Don’t feel you have perform your process exactly as it is explained in the text book. Your process should set you free not be a cage! If it doesn’t respond to change rapidly enough, you need to change your process. A flexible process is a fundamental concept in Agile.
Get in touch with our team to learn about range of Agile Services and Workshops to kick start your transformation.
