All About Agile

Using Scrum on Larger Projects: "Scrum of Scrums"

2009-06-10T07:06:00.014Z

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!

2009-06-01T19:53:00.017Z

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

2009-05-19T07:57:00.015Z

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...

Forrester on Agile and Lean

2009-05-12T20:55:00.013Z

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

2009-05-12T20:19:00.003Z

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

2009-04-02T21:46:00.017Z

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

2009-03-24T20:57:00.016Z

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:

Understand the client's attitude towards scope up-front, and be very clear about the fact it's fixed price, not fixed price and fixed scope. In other words, they can add or change features throughout development, giving them the benefits of flexibility, but will need to remove other features to do so.
Build in sufficient contingency and allow for a reasonable number of changes to happen without too much debate. You are taking the risk on a fixed price project. The client needs to pay a premium to offload that risk to you.

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

2009-03-16T17:52:00.015Z

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

2009-03-09T20:36:00.028Z

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

2009-03-03T22:30:00.009Z

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

2009-03-02T20:19:00.017Z

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?

2009-02-28T21:25:00.003Z

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

2009-02-26T20:52:00.006Z

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

2009-02-24T17:00:00.006Z

Interesting thoughts about the role of Product Owner in Scrum agile software development teams.

Measuring Business Value in Agile Software Development

2009-02-23T20:32:00.010Z

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

2009-02-11T20:43:00.007Z

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...

Make sure one person (probably a manager of some description) is responsible for triage - that is, deciding whether or not a support issue is really priority enough to interrupt the current sprint, or whether it should be deferred and scheduled in the next or a future sprint.
If it does have to be handled in this sprint, respond accordingly without estimating the work and without trying to break it into tasks.
Allow it to impact your team's velocity as naturally it will.
When you do your next round of Sprint Planning, plan based on the velocity you achieve, so an allowance for support is naturally incorporated into your level of commitment. Do not allocate any specific time for support.
If your velocity is unstable and fluctuates significantly, try calculating standard deviation on your average velocity. Standard deviation will give you an objective way to understand the level of risk you are taking if you plan on your average.
If your standard deviation is high, the risk of not delivering is high. In this case, commit to a lower velocity and prepare some stretch tasks to be included if you have time.

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

2009-02-11T20:31:00.005Z

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

2009-02-10T21:45:00.012Z

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...

Agile Practices Are Meant To Be Adaptive (But Only When You're Ready)

2009-02-06T11:48:00.013Z

Damon Poole has written an interesting piece about which agile practices he feels really define 'being agile'.

When Damon says that agile is more than a single set of practices, he's right. What's more important than the practices is the key agile principles behind them.

Whichever methodology you prefer, whichever practices you adopt, and whichever you don't, the most important thing is to understand these principles, and adapt your practices according to the needs of your team and the needs of your organisation.

That, for me, is really the essence of agile. It's adaptive. Not prescriptive.

The problem, however, is that people whose understanding of the principles is not necessarily that deep might adjust the practices and lose much of the value. I've certainly seen this.

Ken Schwaber raises this very point in his book 'Agile Software Development with Scrum'. Until you really understand the principles, and have practical experience of *why* the process works, you are in no position to adapt it.

That's where prescriptive works for teams in the early stages of adoption. And why methods such as Scrum, eXtreme Programming, and others, really do help teams to get started and find success.

Only once the key agile principles are truly embedded - not the processes, but in the mindset of the team - can the team really become truly agile, and adapt.

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 Seamus Murray

User Stories v Use Cases

2009-02-03T19:26:00.007Z

Scott Sehlhorst from Tyner Blain is one of my favourite bloggers. He's written an excellent post about User Stories versus Use Cases.

When I first used Use Cases, I loved them...

I loved the fact they gave such a clear description of a feature, and the fact that each Use Case could stand alone. They made it really easy to move cards representing the Use Cases around the whiteboard, as a way of managing progress.

But I also found Use Cases a little complicated. When you look closely, they're not that complicated really. But they tend to need a Business Analyst to write them. And they tend to be a bit off-putting for end users or business people.

I think this is partly because they use quite a bit of jargon. And particularly when faced with a lot of them, all up-front, to be signed off and used against them in a change control process later.

So when I came across User Stories, I loved them even more. They seemed to offer all the things I loved about Use Cases, but in a simpler, lighter and easier-to-use format. They're easier to write. And they're much easier for end users or business people to work with.

Scott is right though. User Stories leave out a lot of important details. They leave these details out deliberately, relying on a conversation with the product owner to clarify the details at the time of development. They rely on this collaboration. Developing small increments, getting feedback and iterating, rather than having more detailed documentation up-front. Without this collaboration, I agree, User Stories could be problematic.

Having said that, if the product owner won't collaborate on User Stories throughout development, why would they collaborate on Use Cases during the analysis? In the end, whichever approach you prefer, active user involvement is imperative!

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...

Agile Teams Need To Pull Together

2009-01-27T22:07:00.012Z

Sometimes, Agile Teams have to be literally just that...

Some agile methods - such as Scrum and eXtreme Programming - advocate multi-disciplinary teams. That is, teams of generalists; developers that can write code, and can also do whatever other tasks are required.

In principle, this is a good concept because:

* A multi-disciplinary team never suffers from any bottlenecks, where the team is waiting on someone with particular skills.

* As a manager of a multi-discplinary team, you don't have to try to work out the ideal profile of the team, anticipating in advance how many developers, testers, analysts, etc you'll need at any given stage of the product's development. This is challenging anyway, and changes over time.

However, in reality, setting up with multi-disciplinary teams is not always possible. And not necessarily ideal...

Many organisations already have specialists. For instance, designers, front-end developers, back-end developers, database administrators, business analysts, testers, project managers, product managers, etc. Unless you want to get rid of these specialists, and employ only developers, you need to put these people to work and you will definitely benefit from their specialist expertise.

And generalists that have all the required skills are rather hard to find!

You might find a developer that is really good at both front-end and back-end development. You might find a developer that can also do analysis. You might even find a developer that thinks like a tester. Although this one can be difficult, because we all know developers can't test for toffee! :-) And, if you are lucky enough to find someone who really is good at all of these things, what are the chances of them also being good at UI/graphic design?! Maybe. But in my experience, generally not.

So what do you do?

Personally, I think you need a team with all of these skills. It's a multi-disciplinary team by virtue of the fact that the *team* has all of these skills. Not because *everyone* in the team has all of these skills.

If you can find generalists, to minimise the number of specialists and reduce potential bottlenecks, great! Combining some roles can certainly help with this. For instance - in my experience of agile - the roles of analyst and tester can potentially be merged into the role of Test Analyst. And the more generalised role of Product Manager might combine the traditional roles of Project Manager and Business Analyst, as well as introducing some important product management discplines.

But in the end you will probably need some specialists.

In which case, it is very important for these specialists to be flexible. To be Agile. In the true meaning of the word.

You might be called a Tester, and might specialise in testing, but you should be prepared to help with analysis and any other tasks that you have the skills to do. You might be called a Developer, and specialise in development, but you should be prepared to test your colleagues' work if it's testing that the team really needs to get done. You might be called a Project Manager, and specialise in project management, but you should be prepared to help with analysis and testing if it helps the team to deliver.

This is, of course, a question of attitude. There's no place for "jobsworths" in an agile team. In an agile team, you never want to hear that "it's not in my jobspec". It's a question of team spirit. Completing your own tasks while the team fails to deliver is not success. Not for a team player. The team succeeds, or fails, as a team.

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...

Velocity and Project Approval

2009-01-26T21:16:00.008Z

Mike Cottmeyer from Version One has written an excellent blog post about Velocity, and the importance of management and teams taking a responsible attitude towards it...

Mike also describes the usual challenge in any business - where management need some sort of basis for funding a project, yet teams are really in no position to estimate the size of the project until they get into the work.

In some methodologies - for example RUP - there is an initial stage of the project ("inception") to do some high level scoping before seeking approval for full funding. It's also quite common in waterfall projects to complete the reuirements analysis before going on to request full funding. In these cases, only the initial stages need to be funded and then the team knows more by the time they ask for the rest of the money.

Effectively it's a two-step approval process. Approval 1 gets the money for analysis. Approval 2 gets the money for the rest of the project, when more is known about the requirements and scope.

But in agile projects, this two step approach often doesn't exist.

Although for large agile projects - especially those that require additional funding - this needn't necessarily be the case. For all the same reasons, it's entirely appropriate for an agile team to want some initial funding first, in order to learn more about the project before returning to request the full amount.

I wrote a little while back about how this could work, and the artefacts an agile team might produce with some seed money during the early stages of a project. In an ideal world, the team would at least secure enough funding to produce the Product Backlog, and complete a few Sprints to establish their Velocity.

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 Beat

Whole Teams and Colocation

2009-01-21T20:48:00.008Z

Damon Poole has written an interesting blog post about Whole Teams and Colocation, particularly in the context of self-organising teams...

Self-organisation and empowered teams is one of the key principles of agile software development.

For sustainable success - and for the team's personal growth - it is so important that teams become as self sufficient as possible, and rely as little as possible on managers to achieve their goals.

But this is also why agile development often has to be driven from the top down.

As Damon points out, *putting whole teams together* often requires changes to organisational structure, and relocating people. Neither of which is necessarily easy. And both are likely to require support from senior management.

In my opinion, this is a pre-requisite when implementing an agile methodology. It's a critical success factor. Put whole teams together, and implementing agile is significantly more likely to succeed.

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...

Agility Versus Predictability

2009-01-19T21:09:00.007Z

George Dinwiddie has written an excellent blog post about Agility Versus Predictability.

In this post, George challenges the idea that traditional (waterfall) software development projects are more predictable than agile projects.

He also give a very clear explanation about how to do Agile Release 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 bb matt

Where's the Documentation?

2009-01-19T20:38:00.007Z

Here is an interesting blog post from Dave Nicolette, about the absence of documentation in agile software development.

I'm not quite sure where the eggplant parmesan comes into it! I think Dave might have been drinking :-) Nevertheless it's an interesting and thought-provoking article.

In my opinion, some lightweight documentation helps to bring structure to people's thinking, and obviously helps to share important information between people in the team. But it becomes counter-productive when it goes over the top, which sadly is all too common in software development!

That's why I love User Stories for capturing requirements. They add structure to the process. But keep things lightweight and simple.

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...