A common problem in agile software development - is bottlenecks that hold up the team's progress during a Sprint or iteration...
In traditional waterfall projects, everything happens in sequence, so this bottleneck does not occur because it is planned in. For instance, the testing starts when all the development is complete.
However, in agile software development projects, the analysis, design, development, testing, etc are all happening in parallel during a Sprint, with the team's efforts converging on completed features in a short time period; perhaps as short as 1 or 2 weeks.
If you have specialist roles in your team, for instance designers, analysts or testers, this can inevitably create bottlenecks, where the developers are waiting for visuals from designers, or testers are waiting for completed code from developers, or the release is waiting for testers to complete their QA.
A common bottleneck, at least in my experience, is for teams to start (and maybe even complete coding) more features than can be tested properly by the end of the Sprint, meaning that testing is the bottleneck and the release is delayed.
So what's the solution?
The easy answer - of course - is to make sure you have enough resources, particularly in the more specialist roles, so there is always enough slack in the schedule to complete a Sprint without these bottlenecks occuring.
But in reality, the chances of the balance always being perfect (for every type of work you ever do) is low, so some bottlenecks are sometimes inevitable. And in these chellenging economic times, what do you do when adding resources simply isn't an option?
One solution, coming from Lean agile software development practices, is the concept of Work-In-Play limits; a concept borrowed from Toyota's practice of lean manufacturing.
This concept supports one of my 10 Key Principles of Agile Software Development, where I write about completing each feature before moving on to the next, making sure features are shippable at the end of a Sprint.
The idea of WIP limits is to try to ensure that you never start or complete a task that cannot be passed smoothly on to the next stage without blocking up the 'factory line'. To do this means having a 'pull system' rather than a 'push system' and is intended to create a smooth continuous flow of work down the line.
For example, if a classic (and simplified) software development lifecycle is develop and test, testers would pull features from development when they are ready and have capacity to test. Developers would not push completed features to testers whether the tester is ready or not.
This is a simple concept, but like many things in agile software development, it's different to what we've all been used to for so many years, so it takes a little thinking about!
So let's say you set a WIP limit that no more than 3 features can be in play at any one time. You have 3 slots on the board for development, and 3 slots for testing. What happens when the testing slots are all full and the developers have capacity to do more?
If they think the tester will be done before they complete the 4th feature, they can safely start it. But what if they think they can complete the 4th feature before the tester is done? What should they do? Should they sit idle?
Maybe they could complete it and not check it in to the central source code until a testing slot is available. That's okay, but you certainly don't want your developers racing ahead of the tester and creating a pile of backlogged features that aren't checked in.
Maybe they should do some other task? (for instance update documentation, or research a tricky feature coming up). Not a bad option if they need doing, but you really don't want to invent work that isn't necessary.
Personally, my preferred option is to help with the testing to clear a feature so the team can move on? Then the flow of work can continue, and the team is much more likely to reach a stage of completeness at the end of the Sprint, without the tester being overloaded and the release eventually being delayed.
If you do opt for this approach, make sure developers don't test their own work, if at all possible, and have your tester still play a QA role and guide any testing that's being done by others.
An interesting debate about WIP limits is currently occuring between two of the heavyweight thinkers of the agile community. Alistair Cockburn has been commenting on Twitter that WIP limits are for beginners, referring to them as 'training wheels'. Whilst David Anderson argues on his blog that WIP Limits are for Adults too!
What do I think about this debate?
Certainly many parts of agile development are common sense. But we all know that lots of people don't have common sense. And that in software development there are often many variables and keeping focus on something like this can be very difficult without some simple rules and guidelines for people to work to. That's why agile works. Because it's simple.
If Work-In-Play limits help some teams to keep focus on this key principle, help to start the right conversations when there are bottlenecks, and ultimately therefore help to ensure work is completed at the end of a Sprint, then I'm all for it.
Perhaps a more mature agile team might impose WIP limits temporarily on occassions when they can see that work is in danger of piling up at one stage of the lifecycle. In this case, WIP limits could be a useful tool to ensure the team has a complete feature set at the end of the Sprint, and not, for instance, a load of untested features.
Kelly.
P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...
Work-In-Play Limits in Agile Software Development
Using Scrum on Larger Projects: "Scrum of Scrums"
It is sometimes said that agile software development methods, such as Scrum, are ideal for small projects being delivered by small teams.
Personally I would certainly agree that Scrum is ideal for small, multi-disciplined, co-located teams, working on a common purpose.
However, these days we hear plenty of examples of larger companies using Scrum on a fairly large scale. I seem to recall Yahoo in particular once stated they were using Scrum on a project with 700 developers!
Of course it is relatively straightforward to scale Scrum up when the teams are basically a collection of small unrelated teams, each using Scrum but working on different projects. But what about when you need a very large team working on a single project, or on closely related projects in a large programme?
One technique for handling this - although I'm sure it's not enough on it's own by the way - is a technique called 'Scrum of Scrums'.
The concept is simple. Each team meets every day and holds their daily Scrum as usual. One or two representatives from each Scrum team attend a higher level Scrum to coordinate across teams. And on very large teams, one or two representatives from the higher level Scrum attends an even higher level Scrum, and so on.
It means some people need to attend two Scrums, but the Scrum of Scrums technique scales up very well and is easy to see how important information can be quickly cascaded all the way up the line on very large projects.
But the information that needs to be communicated, and the frequency of communication, shifts as you go up the line, and the process for a Scrum of Scrums needs to be slightly different from a usual Scrum.
Mike Cohn - popular author of Agile Estimating and Planning and User Stories Applied - has written a blog post giving his advice on how to apply the Scrum of Scrums technique...
Advice on conducting a Scrum of Scrums - by Mike Cohn
Kelly.
P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...
To Estimate or Not To Estimate? That is the Question!
Lean software development shares many of the key principles of agile software development.
Although one of the key aspects of lean development is all about identifying and eliminating waste from the development process...
One of the most hotly debated aspects of this is estimating. It clearly doesn't contribute to the end product itself, but is estimating really waste? Or does it really add value to the process?
This post on the LitheSpeed blog, 'To Estimate or Not To Estimate, That is the Question', asks exactly that.
The answer? I guess it really is a matter of opinion. My personal answer - Like most things in life, I think it depends!
I think I agree with Sanjiv. If you're working on high priority bugs, in severity order, and they must be fixed, estimating how long they will take provides little value, except to help manage expectations about when the bugs might be gone, which may or may not be useful depending on your circumstances.
On the other hand, if you need to create a business case in order to secure funding for a special project, or you need to commit to a deadline to fit in with other dependencies like a launch date, estimating is clearly necessary, whether it adds value to the end product or not.
I think actually that's really the wrong question though. Clearly there are many scenarios in business where you do need to estimate when something might be done. But you may not need to estimate the size of each feature or the effort of each task in order to predict a delivery date.
With a large enough sample size, keeping track of the average time per feature, or cycle time, could potentially be a reliable way of predicting how long something might take, without actually estimating it.
My concern about this approach is that, statistically, all items must be as near as possible to average to achieve any level of predictability on a single piece of work. I'm sure on a large project, everything averages out. By definition it must do!
But on smaller pieces of work, where you're working to short timescales, any feature that is higher than average gets delivered later than expected. And that can cause problems.
Kelly.
P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...
Photo by bushn
Kanban Applied to Software Development: From Agile to Lean
Most of my experience of agile software development has been with Scrum, and some aspects of eXtreme Programming (XP). However, for quite a while now, I've been reading quite a bit about Lean software development, and Kanban.
For those that don't really know much about Kanban, I found the following article on InfoQ quite an interesting insight:
http://www.infoq.com/articles/hiranabe-lean-agile-kanban
I haven't made the jump and tried Lean with any of my teams yet. To be honest, I've had such great success with Scrum, across so many teams now, it's almost a case of "if it's not broken, don't try to fix it".
Having said that, I do see that the overhead of Sprint planning in Scrum is often quite onerous. Although I really value the predictability teams can achieve by estimating in points and tracking Velocity and Burndown. I've seen this help so many teams to deliver on their commitments, meeting expectations and building strong business relationships as a result.
But I can't help being slightly fascinated by the idea of cycle time in Lean software development. This is the idea that a team's cycle time represents the average number of cards - or User Stories - a team can deliver in a fixed period of time (iteration). To work best, user stories would ideally be broken down until they are all a similar size. Although not necessarily, as what's important with cycle time is the average number of user stories that can be delivered in a Sprint. When you think about it statistically, the concept is actually very similar to Velocity.
What if a team could achieve the same level of reliability and predictability, without the need for any detailed estimating and planning? There would certainly be an increase in the team's productivity, due to the time saved on Sprint Planning.
My sense is that doing Lean - and using cycle time to predict when things can be delivered - may well be appropriate for business as usual. Ongoing development is, by nature, more routine. And therefore the team is more likely to get into a more predictable rhythm. But for bigger projects, where costs need to be estimated in order to secure funding, and the project team is not yet established, I'm not sure if cycle time would be predictable enough?
Kelly.
P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...
Scrum Video
Bruno Sbille and his team have made this video as a nice light-hearted way to show how they used Scrum agile software development on a real-world project... Scrum methodology from Soul' on Vimeo.
Kelly.
P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...
Forrester on Agile and Lean
Here's an interesting article about agile software development and lean development, written by a senior analyst at Forrester Research...
"Agile Processes Go Lean"
It's nice to see agile and lean getting such positive recognition from an organisation as credible as Forrester.
Kelly.
P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...
Photo by Antoine
The Downfall of Agile Hitler
Apologies to my regular readers. Things have been pretty busy at home and at work lately, so I haven't blogged for ages! To ease me back into the chair gently, here is a funny video about "Agile Hitler" that was posted on YouTube. Someone at work sent it on to me, and I must admit it made me laugh out loud! It starts slowly, but it's worth sticking with it...
Kelly.
P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...
Estimating in Agile Software Development
I've written quite a bit about various aspects of estimating in agile software development. I think it's about time I joined up the dots...
PRODUCT BACKLOG
The Product Backlog is a feature list. Or a list of User Stories if that's your approach. Either way, it is a simple list of things that are of value to a user - not technical tasks - and they are written in business language, so they can be prioritised by the Product Owner. There are no details about each feature until it is ready to be developed, just a basic description and maybe a few notes if applicable.
'POINTS MAKE SIZES'
Each item on the Product Backlog is given a points value to represent its size. Size is an intuitive mixture of effort and complexity. It's meant to represent 'how big it is'.
FIBONACCI
I like to use the Fibonacci number sequence for the points values. Fibonacci goes 1, 2, 3, 5, 8, 13 - where each number is the sum of the previous two. This builds a natural distribution curve into the estimates. The bigger something's size, the less precise the estimate can be, which is reflected in the widening range between the numbers as they get bigger.
RELATIVE ESTIMATING
Points are an abstract number. They do not convert to a unit of time. They are simply a *relative* indication of size. In other words, a 2 is about twice the size of a 1. A 5 is bigger than a 3, but smaller than an 8. Developers find it hard to estimate accurately in hours or days when they don't yet know the details of the requirements and what the solution involves. But it's easier to compare the size of two features relative to each other.
ESTIMATE AS A TEAM
The points should be assigned to each backog item as a team. The collective intelligence - or wisdom of crowds - is an important way to apply multiple people's experience to the estimate. If you have a very big team, you can split up so it's quicker to do this, but the estimating groups should ideally involve at least 3 people, so you dont just get two opposing opinions.
PLANNING POKER
Planning Poker is a fun technique to facilitate rapid estimating as a team. The team discusses a feature verbally to understand more about what it entails and how it might be done. Each team member writes what they think its size is (in points) on a card. All team members reveal their card at the same time. Differences in opinion are used to provoke further discussion. Maybe one person saw risks and complexity that others didn't. Maybe another persion saw a simpler solution. The team re-votes until there is a concensus, then moves on to the next item.
DONE MEANS DONE
During the Sprint, or iteration, the team only counts something as Done when it is completely done, i.e. tested and signed off by the Product Owner. At that time, and only at that time, the team scores the points for the item.
BURNDOWN
The team shows its commitment and daily progress on a graph, so it is measurable and visible at a glance. This is called a Burndown Chart. The burndown shows the total number of points committed to, depreciating over time to the end of the Sprint. This is the target line. It also shows the actual number of points scored each day - i.e. the sum of points for all items that are 100% done and signed off so far. The team plots this each day before their daily stand-up meeting. When the actual line is above the target line, the team is behind. When it's below, they're ahead.
VELOCITY
At the end of the Sprint, the team's score is called their Velocity. The team tracks its Velocity over time. This allows the team to see if it's improving. Of course at some point it will stabilise, if the team is stable. If not, this is an issue in itself. When Velocity is relatively stable - in my experience that will be after 3 or 4 Sprints - it can be reliably used to decide how much (i.e. how many points) the team should commit to in the next Sprint.
RELIABILITY / PREDICTABILITY
As a result, the team can measure how reliable - or how predictable - they are. The metric for this is Velocity (points scored) as a percentage of points planned. As Velocity stabilises, the team's Reliability will get better, and the team will be better at predicting what they can deliver. Ironically, the team doesn't need to get better at estimating to get better at delivering on their commitments. Even if they are terrible at estimating, as long as they are consistently terrible, with this method they will still get better at predicting what they can deliver.
POINTS VERSUS TIME
One of the benefits of points is that it does not relate to time. Resist the temptation to convert it. If a team plans on 100 points and delivers 50, can you imagine telling your stakeholders that you are only planning future Sprints for half the team's time. If a team commits to 100 points and delivers 150, imagine telling the team you're planning on doing 60 hours each per week. It just doesn't work. Points are not a measure of time. They are abstract, relative sizes, and a measure of how much can be delivered. That's why it works. It works because the team can adjust its commitment based on what its track record shows it can usually deliver.
PRODUCTIVITY
This does not measure a team's productivity. Velocity does tell you if a team is getting more or less productive. But you can't really use Velocity to compare the productivity of two teams, as their circumstances are different. And you can't use it to determine whether a team's Velocity is as high as it should be. For this, you still need to use your judgement, based on previous experience and taking into account many subjective factors.
PLAYING THE SYSTEM
Using these two metrics - Velocity and Reliability - it's hard to cheat the system. If a team commits low, they acheive Reliability but Velocity goes down. If a team commits too high, their Velocity goes up but their Reliability goes down. This is like the balanced scorecard concept. The metrics are deliberately measuring opposing things, so they can't easily be played.
Kelly.
P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...
Photo by Steve Kay
3 Reasons Why I Wouldn't Do Agile Software Development
Agile software development has been a revelation for me. It has brought me and my teams much success, and a very rewarding working environment.
Sometimes I hear people say that agile development isn't appropriate in all circumstances.
In fact, I used to say that myself; however now I'm not so sure.
There are some circumstances where an organisation's culture is possibly too different to successfully adopt agile. At the moment I can think of only 3 reasons why I wouldn't do agile software development:
1. If I was working for an organisation that believed it needed complete clarity about a solution before it could start a project. I believe this is a false positive, and it would be very hard to adopt agile in an environment where key stakeholders insist on this.
2. If I was working for an organisation where the relevant product owners couldn't - or wouldn't - commit to being actively involved throughout the project. I really do believe that active user involvement is the first principle of agile, and imperative for a project to succeed.
3. If I was working with a team that I didn't believe could cope with ambiguity, or didn't have sufficient communication skills to collaborate effectively with business colleagues or customers.
In these circumstances (particularly if combined), adopting agile could be very difficult indeed, because in my experience these 3 agile principles are critical success factors!
When writing this list, I did also wonder whether to add fixed price projects to my list? Working from a feature list, having no more detail about the features up-front, and allowing change throughout the project, could potentially be a complete disaster with some clients on a fixed price contract.
I think I would do agile on a fixed price, but I would be very careful to:
I would evaluate the above two issues - along with any other risks - very carefully before committing to a fixed price agile development project. Otherwise, whether accidentally or deliberately, you could quite easily get mugged :-(
On the other hand, I'd probably try to persuade the customer that T&M (Time & Materials) is not a problem with agile software development, because of the level of collaboration, visibility and transparency, and the frequent delivery of working software.
I'd love to know your thoughts on this: When wouldn't you do agile software development?
Kelly.
P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...
Photo by dominicmercier
'All About Agile' Seminar
I've spent the last 2 years or so reaching out via my blog and posting all sorts of comments and information about my experiences with agile software development. I am now thinking of running a seminar, in order to do the same thing on a face-to-face basis.
I think the area where I have most to offer is for people starting out with agile; people that might be interested in my explanation of the 10 key principles of agile, and my explanation and experience of how to implement Scrum.
I have seen significant benefits from implementing agile development using Scrum, having implemented it successfully in many teams now. I'm really keen - as I have done so far with my blog - to share my experiences with the community. Hopefully on a face-to-face basis I should be able to really bring some of this experience alive, and share some important information about what has worked for me in practice.
I haven't set a specific date yet. Or a definite price. My idea is to do this as a half-day session, in London and at a decent venue.
This is where I need your feedback. The purpose of this blog post is simply to sound out my blog readers and find out if there is sufficient interest to run the event? If you would be interested in attending, or have any feedback for me, I would love to hear from you. You can email me at allaboutagile@gmail.com.
Kelly.
P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...
The Power of a Whiteboard
Agile software development teams often use low-tech, manual methods for tracking their work. Post-it notes or cards on a whiteboard. Charts drawn by hand. Sketches for architecture and design.
But why, for such a high-tech industry like software development, would agile teams do this, when there are plenty of project management tools available; even tools that are purpose-built for agile software development?
Personally I can see why. I think a whiteboard offers loads of advantages over electronic tools. They're mainly soft factors, I admit, but I think a whiteboard is hard to beat.
First of all, a whiteboard is visual. And it's BIG. You can see at a glance how things are going.
When you're part way through a Sprint, and most of the cards are still on the left of the board, you know it's not going so well. Or you're coming towards the end of a sprint, and the cards are mostly - reassuringly - on the right of the board, you know it's going fine. The Burndown Chart shows you instantly whether the team is on track. And, if not, by how much. All at a glance as you walk past the board. Whether you made a special effort to look or not. The visibility is unbeatable.
When you see something in print, somehow it seems more real. I guess because it's physical. A large number of post-it notes on a whiteboard looks like a lot of work. Probably because it *is* a lot of work! Its sheer physical presence reflects the amount of work the team is actually doing. It feels busy. It feels like a place where alot is happening, which feels good. A long list of tasks on a project plan, or a long list of rows in a spreadsheet, simple doesn't have the same impact.
A whiteboard is also flexible. Infinitely flexible. You can put literally anything you like on it. Wherever you like. In any position, any size, any shape. Unlike an electronic system, there are never any constraints. No-one ever says you can't do something because the whiteboard won't let you.
It's fast and efficient to change. You could completely reoarganise a set of cards in just a few moments. Or sketch something important in seconds.
It's also more tactile. For people that like tactile, it feels good to move a card to done. You feel a sense of ownership when you pick up a card. A business owner feels a greater sense of responsibility - real acknowledgement - when they add something to the board and take something else off the board to take it out of scope. It feels like something was actually, physically removed from scope.
It's also novel. When a team starts doing agile - and they create great visibility using the whiteboard - it's remarkable how many people want to come and look. Senior people have a sudden interest in what the team is doing. And even in the process itself. That would never happen with spreadsheets and tools! I can't ever remember a Director asking to come and walk through my project plan, or walk through my product backlog. In fact the very thought of it fills most people with dread! It just doesn't happen. But the whiteboard is interesting. It's interesting to look at. And interesting to talk about. When someone walks you through it, it's actually enjoyable.
Because a whiteboard has no set structure, it suits the way many people think (not all). Many people think visually. Not in lists, but in shapes, sizes, colours, etc. The whiteboard's lack of structure allows the information to be organised and presented however suits.
Important information can be highlighted easily by putting it on the whiteboard. Important information is not buried with loads of other documents and files in a project folder somewhere, which few people would browse and certainly wouldn't notice in passing.
Its visible nature can prompt people to remember things when they see them, rather than relying on their memory to go and look somewhere else that's out of sight.
But above all else, the whiteboard is a place for collaboration. It's a focal point. Like a campfire in days gone by. Or a fireplace in your lounge. Most team discussions happen round the whiteboard. Discussions about progress. Discussions about issues. Discussions about design. All sorts, sometimes even when the whiteboard isn't even needed. It becomes the hub of information for the team. The hub for communication and collaboration.
And last but not least, the unstructured nature of the whiteboard allows it to be be personalised by the team. The team can express itself through the things it puts on its whiteboard. It starts to show the character of the team, and therefore helps to create a visible sense of team spirit.
Tools can certainly help to organise information more efficiently. But I would challenge any tool to do all of that! I'm not against tools. Not at all. But I think they should supplement the whiteboard, not replace it. Tools should be used for things they can do that a whiteboard can't. For instance, keeping track of longer lasting information, doing calculations, searching, etc. But personally I don't think I'd ever use tools instead of a whiteboard. There's simply too much to lose.
Kelly.
P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...
Photo by Fernando Meyer
Themes in Agile Software Development
Agile software development teams often use User Stories as a simple and concise way to express user requirements.
Ideally these User Stories are broken down as small as possible, whilst also trying to minimise dependencies.
Naturally, though, as you break User Stories down smaller, they become increasingly inter-dependent. Like most things in software development, it's a balancing act.
Break the User Stories down as small as possible. But stop breaking them down when it becomes onerous or pointless to do so. When a User Story can be delivered (done) in less than 1 day, I think there is little point breaking it down any further.
Use the concept of Themes to categorise these related User Stories under one label and keep them together.
You could physically keep the cards together by paper-clipping the cards together. Or you could put a card representing the Theme on the left side of your whiteboard, and keep all related User Stories on the same row as the Theme as they move across the board.
Equally important, try to make sure that any inter-dependency between User Stories is a soft dependency, rather than hard. By this, I mean that you might not want to ship any of the User Stories until the whole Theme is done. But try not to break them up in such a way that one User Story simply doesn't work without another.
For instance, a 'Login' Theme might include User Stories for Register, Log in, and Forgotten password. Although the stories are related, and somewhat dependent on each other, they can still be delivered in isolation, and can still work from a user perspective if you do them in the right order.
You can also use Themes to categorise loosely-related items on your Product Backlog. For example, on a web site, you might have a whole host of User Stories relating to SEO, performance, usability, a re-style, or sections that are made up of multiple User Stories.
Assigning Themes to the User Stories in your Product Backlog can help you to see emerging themes, which with a loose set of User Stories you may not have noticed. When you see emerging themes for your next Sprint or two, this can help to give extra clarity to the team and business about the Sprint Goals.
This is a useful thing to do. It gives you more of a message for the Sprint. It's actually *about* something, rather than a random collection of high value but unrelated stories. It could tell you that you're focusing a high percentage of your Sprint on features x and y, when at a macro level your priorities are really elsewhere, for example.
It also helps when priorities are set top-down. For example, let's say we make the commercial decision that for the next few sprints SEO will be a top priority. You can quickly grab all the User Stories with the SEO Theme and give them priority.
Of course it's fine for a sprint to include items that are not part of the overall Theme. The theme is simply the main area of focus, not necessarily the sole area of focus.
There is sometimes a danger with agile software development that everything is broken down so small and incremental that everything becomes a bit too tactical, and there is either no direction or at least the direction is not apparent.
It's important to keep a higher level Release Plan, or a Product Roadmap, so the Sprints do take the product in a certain direction, and so the team can see what that direction is. Because no Sprint is an island!
You can also use Themes as a simple way to sketch out broad priorities on the Product Roadmap, showing the key areas of focus over time.
Kelly.
P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...
Photo by *phototristan
Planning Poker - Agile Estimating
Planning Poker is an estimating technique used by many agile software development teams. Like many agile development techniques, Planning Poker is very simple. Simple, but effective.
First of all, agile teams should ideally estimate together. As a team. If the team is big, and people are working on different products, it's okay to split the team into smaller groups. But estimates should still be done in groups.
The logic behind this is simple. Each person in the team has different experience. When you get the input of multiple people, you multiply the experience applied to the problem.
The benefit of doing this is based on the wisdom of crowds. You get the benefit of the team's collective intelligence. 
In addition, you are likely to generate more ideas. Ideas about different ways of solving the problem. Ideas about how to design the solution. And ideas about obstacles that might be encountered.
All this leads to better estimating. And perhaps more importantly, better solutions.
Here's how it works...
First of all, agree an estimating approach. For instance, many agile teams estimate in points, perhaps using the Fibonacci numbering sequence. Others use T-shirt sizes or some other abstract numbering system. Estimating in an abstract form has several benefits. The key thing is to estimate each item's relative size, compared to other items.
Then, prepare cards with the numbers on. You can buy Fibonaci Planning Poker cards, or make your own. Alternatively you can just ask people to write the numbers you'll be using on post-it notes.
The actual process of Planning Poker is then to discuss each feature in turn, clarifying requirements and asking questions that help to understand how it might be designed. When questions about a feature have run out, or are no longer materially important to the size, each member of the team indicates they are ready to give their estimate.
Then, on the count of three, the whole team reveals their estimate by showing the appropriate card, all at the same time.
As I mentioned earlier, each member of the team has different experience. So it's very unlikely that everyone will come up with the same answer. Maybe someone saw issues and risks that others did not. Maybe someone else thought of an easier solution. The team uses this difference of opinion as the basis for discussion, sharing ideas and concerns.
Following the discussion, the whole team re-votes. This process continues until there's only a small difference, or ideally until the team has agreed on the size of the feature.
Then the team moves on to the next feature, doing the same again.
And that's it! Planning Poker is a very simple but powerful technique, designed to extract the collective wisdom of the team.
For those of you who haven't encountered estimating in points before, I guess there's one outstanding question: How do points make an estimate in time?
The team tracks how many points it can deliver in a Sprint (or iteration). That's effectively their Velocity. Estimating in an abstract form - e.g. points - combined with tracking Velocity, allows a team to understand how much it can usually deliver, enabling it to forecast delivery without the need for detailed planning.
Kelly.
P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...
Photo by Kevin Labianco
Is Your Team Cross-Functional Enough?
Agile software development methods encourage the use of cross-functional teams, in order to avoid too many specialists causing bottlenecks for the team. Henrik Kniberg has written an interesting blog post about how the team can quickly evaluate their status: 'is the team cross-functional enough?'.
Kelly.
Technical Debt in Agile Software Development
Martin Fower - agile software development guru, and CTO of Thoughtworks - has written an interesting blog post about Technical Debt.
I love this concept. It's so simple, and such a compelling way of explaining this classic commercial trade-off decision to business people.
Kelly.
The Role of Scrum Product Owner
Interesting thoughts about the role of Product Owner in Scrum agile software development teams.
Measuring Business Value in Agile Software Development
One of the elusive things in software development is how to measure business value.
For some projects it's fairly obvious. Maybe there's a clear revenue benefit. Or a tangible cost saving. Or a very specific risk avoidance.
But what about on BAU (Business As Usual)? How do you get some indication of the business value a team is delivering on bug fixes, enhancements and new features delivered as BAU?
One way - which is fairly rudimentary but an interesting indicator - is to use Fibonacci points in a similar way to Velocity.
The idea here is to put Fibonacci points for business value on every item (or User Story) on the Product Backlog, as well as the points for each feature's size.
The development team provides the points for size, because only they are qualified to judge how big a feature is, relative to another. Whereas the business value points should come from the Product Owner/Business Owner.
In the same way as the development team estimates in points, the Product Owner decides on a business value for each item, relative to each other. The key thing here is that the estimated business value is relative, i.e. a feature with a business value of 2 is twice as valuable as a feature worth 1; a 5 is worth 5 times a 1, etc.
When you have Fibonacci points for size and for business value, you can also do some interesting things to help prioritise your backlog. Firstly, if you have a long Product Backlog that is difficult to get your head around, you can simply enter business values individually and then sort the list by business value as a starter for ten.
Secondly, you could do a calculation of business value divided by size to give the feature a priority score. It's a bit rudimentary, but it's a simple way to sort the backlog so the high value/low effort features come out at the top.
You can also plot this on a scatter graph, which you can set up to put the high value/low effort features on the top right, and the high effort/low value features on the bottom left. This is a useful concept and can help to facilitate a good discussion about priorities.
But aside of prioritisation, putting a business value in points against every item on the backlog allows you to calculate 'Business Velocity', i.e. how much business value (in points) was delivered in each Sprint. You could plot this on a 'burn-up chart', showing the cumulative business value delivered over time - hopefully with an accelerating trend line.
And you could use this graph to see whether the business value for each sprint is increasing or decreasing. Naturally a team's business value might slow down as a product matures in its commercial lifecycle. Maybe in this case it's time to think about switching resources onto other priorities? Maybe it coincides with a lower velocity? Or maybe it's time to think of some more valuable ideas?
Either way, I guess it could be interesting to see...
Kelly.
P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...
Photo by eyeore2710
Handling Support On Agile Software Development Teams
Mike Cottmeyer from VersionOne has written an interesting blog post about the problem of handling support in agile software development teams. Mike highlights three potential approaches for handling this problem. Personally I think there is a fourth approach, as follows...
Of course if you are running a project across multiple sprints, this will still affect your release plan. But it should give you better predictability, and allow you to take action or manage expectations accordingly.
Kelly.
P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...
Twittering On About Agile Software Development
I've been twittering on about agile software development on my blog for quite a while now. And now I've joined Twitter...
I'm not sure I really get Twitter, to be honest. Think I must be getting old :-) Just thought I'd join in and see what all the fuss is about!
You can follow me here: http://twitter.com/allaboutagile
Kelly.
P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...
Image by jmiles
The Decline and Fall of Agilists
Jurgen Appelo has written a really interesting blog post called The Decline and Fall of Agilists. Well, it's more of rant really, and it's generated quite a debate!
Personally I like the agile engineering practices in eXtreme Programming (XP). They make a lot of sense to me.
But, in my last job, we implemented Scrum in a development group of over 100 people, without really implementing any XP practices until much later on. We saw phenominal success using Scrum without XP. A real transformation in our delivery. And a massive improvement in our business relationships.
One of the things I really like about Scrum is its simplicity. The fact you can implement it pretty quickly, straight over the top of whatever software engineering processes you already have in place.
That's because Scrum is an agile management methodology, and doesn't prescribe how you should approach the tasks.
Now you could certainly argue that we might have been even more successful if we had also implemented XP. Maybe that's true. eXtreme Programming evangelists joke that "Scrum is just XP without the technical practices that make it work".
Quite a funny statement, when said tongue in cheek. But in my experience it is simply wrong.
So thus far, I am with Jurgen.
I think that's because our situation in my last job was like Jurgen's example of chaos versus order. In our case we were moving from complete chaos. Scrum allowed us to put some lightweight, structured process (i.e. order) into place fairly quickly, and get things much more organised, more transparent, more collaborative, and therefore more successful.
But how do I feel about the argument (sorry, debate) about prescriptive processes versus adaptive ones? I've touched on this in my last blog post, Agile Processes Are Meant To Be Adaptive (But Only When You're Ready).
It's great that agile is meant to be adaptive. It's a fundamental principle and it's the very meaning of the word. It's great that continuous improvement is built into Scrum, making it a repeatable part of the process. And I love the fact that Scrum does not attempt to prescribe anything about how the product should be engineered.
In my view, there are clearly some agile engineering practices in XP that make it much more practical to work in short iterations without compromising quality. But that decision - the decision about what level of engineering is appropriate - does depend on the context, and a team or organisation's readiness to adopt.
I also love the fact that XP'ers are so enthusiastic about the method. I see a real sense of craft when I see the passion behind XP'ers comments. But it often comes across as a bit religious. Almost like the developers uprising against the establishment. "You must do this or you will fail". Technical perfection over commercial priority. Almost sneering at anyone who doesn't do XP and dares to call themselves agile. I really don't think that's good for the cause.
eXtreme Programming is just one agile methodology. A good one, I think, but just one. There are other methodologies that share the same agile principles. There are people doing Scrum and seeing great success from agile. There are people doing Scrum and XP combined, as they are very complementary, and seeing great success. There are people doing DSDM and seeing great success. There are even people following no process in particular, but working to the same agile principles, and seeing great success.
Come to think of it, there are even people doing waterfall using PRINCE2 and seeing great success :-)
The real trick, actually, is taking the best of all these methods and combining them in a unique way that fits your unique circumstances.
But that requires a great deal of skill and experience. And until a team has this experience, they may well be better off following a presribed process. Until you have this experience, and really understand *why* agile works, you're not really in a good position to adapt it.
Kelly.
P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...
