Tactile sprint planning
A good friend of mine, James Cooper shared with me this idea about tactile planning. What is it? I asked, he explains it below, but shortly: a great way to get the team to "love" sprint planning!
One of the mantra's I've always liked in Agile is that of continuous improvement. It might actually have been borrowed from Kaizen, but I try and avoid buzz words and the flavour of the month and instead adopt a pragmatic approach.
Like many approaches in life, everything seems to work fine in theory until you end up adding people. So whilst Agile and Lean are great examples of common sense and continuous improvement, they're still prone to the same failure's possessed by those implementing them. We're all prone to some form of short coming, its probably the one thing that unites us all!
Over the years an issue I've always faced is planning. Why? Well I simply just don't enjoy the process. If I look at myself critically, it has a lot to do with my personality. I like being right, I don't tolerate poor solutions and I seem to get easily frustrated by those who are not on the same page. I've only ever worked with a few people who didn't irritate me during planning sessions and then, I believe I was
the culprit driving them insane. So its fair to say, I've been looking at improving how I plan and how I can encourage others to do the same. In addition and as the folks in the military would say, “the plan is useless, but planning is essential”.
But before I go to before I get to tactile planning, I guess I need to explain about how we got there. The company in which I'm employed is basically a Scrum house. Sure we use elements of XP, but essentially we use Scrum. Now sadly one thing that we've gotten wrong is tooling. Some use Xplanner, other Scrum Works, others VersionOne and others the devils child....yes Excel. Excel ends up being used for both Product backlog management and the Sprint backlog. Apart from not being cross platform, being simply useless at collaboration, good old Excel is simply put a horrible tool to use. Maybe the folks in finance love it, but last time I checked I'd not done any accounting since first year in college.
So when the team was assembled it was made up of senior technical staff from throughout the company, each possessing at least 10-15 years experience. With that, came 10 years of poor practices and experiences from both inside and outside the company. We started off using Excel to track Sprint stories and corresponding tasks. No one liked it, no one used the spreadsheet, there was always version issues, deadlocks and that wasn't to mention some of our server side folks who preferred using
Linux. In the end only our team manager who was an excel wizard was in favour of continuing with excel. The worst side effect was we never had any good idea of our velocity or sprint burn down so we had no idea when to burn stories. During a retrospective I made a plea to try something else, some thing that supported real collaboration, was web enabled and that people did not have huge issues using.
So then came VersionOne. It was an improvement I'll certainly say that, such an improvement it began to uncover all sorts of stuff we had ignored for the past few months. Whilst this is not intended to be a review of the tool itself, like all other tool's like it, VersionOne expects you to bend to the tool rather than the other way around. Managers like data, graphs, in fact anything that they can give to their superiors. Engineers, well they like turning things green, seeing a general burndown and finding out what else is left for them to do. Many tools focus on the former rather than the later. So as a result VersionOne really was not focused on those who used the tool the most, the Engineers. Our Quality Engineers always seemed to go off the reservation and of all groups, no one knew what exactly they where doing in contributing to the sprint goal. In addition VersionOne was slow, had numerous usability problems and employed a mixture of popup windows and weird tabular data that would make most UX designers cry. The side effect was that about 50% of the team kept our Sprint backlog up to date and as a team we spent a great deal of time asking, cajoling and barking at people into updating our backlog. That's what most would call
a waste of energy.
At the same time I came across an article on Kanban and set about doing some research. After almost a year in our new team, after we had added some new resources, it was becoming apparent we needed to tweak our system somewhat. Firstly, dailies. We need them to keep on track and keep the status updates pertinent to our common sprint goal. Secondly we needed to ensure our QE's stopped mumbling and stayed focused. Thirdly we needed a way to ensure our Engineers kept up Sprint Backlog up to date.
Enter Kanban. The idea was we'd convert one of our walls into a huge Kanban board. The thing must be in excess of 5 meters in length. Unlike normal Kanban, ours has 4 states,"Task", "In Progress", "In Test", "Done". "Tasks" are those tasks associated with a story. "In Progress", well that's when a task belonging to a story is under development. When they're ready for testing, they're passed into the "In Test" stage.
Here, we try to test stories and not tasks. So we try and get all the tasks in the In Test phrase before testing the story. Of course we don't deadlock our system, integration tests and system tests can be scripted, but in the end the entire story is being unit tested, and system tested plus being accepted by our stakeholder that defines something as being done.
The rules for our daily then changed. Firstly everyone has to have a task. If you don't or if you've found a new task for your story, you must create it, estimate it and assign it to a story and yourself during the daily. This constrains the "What will you be doing?" during our daily. In addition if you've completed something, you can move your task to the appropriate section. If you've found upon further inspection, your original estimate does not hold, this is the time to update it. Kanban
allowed us to focus on actual work/tasks through the physical task cards, actual update. It did introduce some extra manual work for our ScrumMaster, he had to
calculate our burn down. The benefit was an always up-to-date system that was very visible and centered attention on the information rather than on the tool. Obviously to get to the initial sprint Kanban board, you need to have a planning session.
During our planning session, the first thing we asked was "what is the Sprint
goal?" The idea here being that this would allow us to focus our attention and prioritize stories according to the sprint goal. Unlike normal sprints, there is an extra facilitator to the normal ScrumMaster. The second facilitator's job is to act as scribe. We used over-sizes post-it notes to write down the tasks. Each story was colour
coded, I guess a limitation is we only have 4 story colours, but since each story normally gives us 4/6 tasks it didn't stop us from having enough to do. After quickly going through the backlog and answering questions, we split the team into groups of 2 each group getting a story to break down into tasks, write each task down on the
post it and assign an estimation. Groups can leave the room, find another room with a whiteboard, do some model-storming in an attempt to check if that story roughly contains the correct tasks. Groups are typically multidisciplinary, so testers are in groups and it is deemed a good thing that our testers are also happy with the design and tasks associated with each story. The team then reassembles with their stories
and associated tasks. At this stage the idea is to ask acceptance questions from our stakeholder if there are any, burn, re-prioritize, re-scope any stories that during our model storming-session we found to be larger than expected.
The result was something that got everyone involved, not only during planning, but also on a daily basis.
at
11:28
Tactile Sprint Planning explained
One of the mantra's I've always liked in Agile is that of continuous improvement. It might actually have been borrowed from Kaizen, but I try and avoid buzz words and the flavour of the month and instead adopt a pragmatic approach.
Like many approaches in life, everything seems to work fine in theory until you end up adding people. So whilst Agile and Lean are great examples of common sense and continuous improvement, they're still prone to the same failure's possessed by those implementing them. We're all prone to some form of short coming, its probably the one thing that unites us all!
Over the years an issue I've always faced is planning. Why? Well I simply just don't enjoy the process. If I look at myself critically, it has a lot to do with my personality. I like being right, I don't tolerate poor solutions and I seem to get easily frustrated by those who are not on the same page. I've only ever worked with a few people who didn't irritate me during planning sessions and then, I believe I was
the culprit driving them insane. So its fair to say, I've been looking at improving how I plan and how I can encourage others to do the same. In addition and as the folks in the military would say, “the plan is useless, but planning is essential”.
But before I go to before I get to tactile planning, I guess I need to explain about how we got there. The company in which I'm employed is basically a Scrum house. Sure we use elements of XP, but essentially we use Scrum. Now sadly one thing that we've gotten wrong is tooling. Some use Xplanner, other Scrum Works, others VersionOne and others the devils child....yes Excel. Excel ends up being used for both Product backlog management and the Sprint backlog. Apart from not being cross platform, being simply useless at collaboration, good old Excel is simply put a horrible tool to use. Maybe the folks in finance love it, but last time I checked I'd not done any accounting since first year in college.
So when the team was assembled it was made up of senior technical staff from throughout the company, each possessing at least 10-15 years experience. With that, came 10 years of poor practices and experiences from both inside and outside the company. We started off using Excel to track Sprint stories and corresponding tasks. No one liked it, no one used the spreadsheet, there was always version issues, deadlocks and that wasn't to mention some of our server side folks who preferred using
Linux. In the end only our team manager who was an excel wizard was in favour of continuing with excel. The worst side effect was we never had any good idea of our velocity or sprint burn down so we had no idea when to burn stories. During a retrospective I made a plea to try something else, some thing that supported real collaboration, was web enabled and that people did not have huge issues using.
So then came VersionOne. It was an improvement I'll certainly say that, such an improvement it began to uncover all sorts of stuff we had ignored for the past few months. Whilst this is not intended to be a review of the tool itself, like all other tool's like it, VersionOne expects you to bend to the tool rather than the other way around. Managers like data, graphs, in fact anything that they can give to their superiors. Engineers, well they like turning things green, seeing a general burndown and finding out what else is left for them to do. Many tools focus on the former rather than the later. So as a result VersionOne really was not focused on those who used the tool the most, the Engineers. Our Quality Engineers always seemed to go off the reservation and of all groups, no one knew what exactly they where doing in contributing to the sprint goal. In addition VersionOne was slow, had numerous usability problems and employed a mixture of popup windows and weird tabular data that would make most UX designers cry. The side effect was that about 50% of the team kept our Sprint backlog up to date and as a team we spent a great deal of time asking, cajoling and barking at people into updating our backlog. That's what most would call
a waste of energy.
At the same time I came across an article on Kanban and set about doing some research. After almost a year in our new team, after we had added some new resources, it was becoming apparent we needed to tweak our system somewhat. Firstly, dailies. We need them to keep on track and keep the status updates pertinent to our common sprint goal. Secondly we needed to ensure our QE's stopped mumbling and stayed focused. Thirdly we needed a way to ensure our Engineers kept up Sprint Backlog up to date.
Enter Kanban. The idea was we'd convert one of our walls into a huge Kanban board. The thing must be in excess of 5 meters in length. Unlike normal Kanban, ours has 4 states,"Task", "In Progress", "In Test", "Done". "Tasks" are those tasks associated with a story. "In Progress", well that's when a task belonging to a story is under development. When they're ready for testing, they're passed into the "In Test" stage.
Here, we try to test stories and not tasks. So we try and get all the tasks in the In Test phrase before testing the story. Of course we don't deadlock our system, integration tests and system tests can be scripted, but in the end the entire story is being unit tested, and system tested plus being accepted by our stakeholder that defines something as being done.
The rules for our daily then changed. Firstly everyone has to have a task. If you don't or if you've found a new task for your story, you must create it, estimate it and assign it to a story and yourself during the daily. This constrains the "What will you be doing?" during our daily. In addition if you've completed something, you can move your task to the appropriate section. If you've found upon further inspection, your original estimate does not hold, this is the time to update it. Kanban
allowed us to focus on actual work/tasks through the physical task cards, actual update. It did introduce some extra manual work for our ScrumMaster, he had to
calculate our burn down. The benefit was an always up-to-date system that was very visible and centered attention on the information rather than on the tool. Obviously to get to the initial sprint Kanban board, you need to have a planning session.
During our planning session, the first thing we asked was "what is the Sprint
goal?" The idea here being that this would allow us to focus our attention and prioritize stories according to the sprint goal. Unlike normal sprints, there is an extra facilitator to the normal ScrumMaster. The second facilitator's job is to act as scribe. We used over-sizes post-it notes to write down the tasks. Each story was colour
coded, I guess a limitation is we only have 4 story colours, but since each story normally gives us 4/6 tasks it didn't stop us from having enough to do. After quickly going through the backlog and answering questions, we split the team into groups of 2 each group getting a story to break down into tasks, write each task down on the
post it and assign an estimation. Groups can leave the room, find another room with a whiteboard, do some model-storming in an attempt to check if that story roughly contains the correct tasks. Groups are typically multidisciplinary, so testers are in groups and it is deemed a good thing that our testers are also happy with the design and tasks associated with each story. The team then reassembles with their stories
and associated tasks. At this stage the idea is to ask acceptance questions from our stakeholder if there are any, burn, re-prioritize, re-scope any stories that during our model storming-session we found to be larger than expected.
The result was something that got everyone involved, not only during planning, but also on a daily basis.
RSS link
0 Comments:
Post a Comment
<< Home