Announcing the Bay Area Lean Software Development Meetup

Hi folks, I’d like to announce the Bay Area Lean Software Development Meetup. The first meeting is scheduled for the end of the this month – on the 30th of April.

I’m going to present on the topic that I’m presenting at the Lean & Kanban 2009 conference – and the topic is Lean Software Development for Startups.

This is just the first meetup, so it will be general – exchanging ideas about what different folks in the valley are doing with their software processes… and things like that.

Join the group – and attend, it should be fun!

Adopting lean software development: What is a user story?

I recently got an email from a reader (Dmitry Lobanov) who had some questions about the process stuff I’ve written about here. With his permission, I’ve reproduced the contents of his email and have responded to his queries. It may help other folks that are in early stages of adopting lean/agile methods –

Hello Amit. You keep interesting blog with a lot of useful information about project management. To my opinion the most attractive idea in your blog is user stories decoupling.

Let me tell how I found it interesting and then I’ll ask a few questions, Ok?

In our project we use scrum with some XP techniques. I found link to your blog in an overview of Mingle at Thoughtworks website. While reading I found your idea of decoupling stories into 2 story points tasks very interesting. And I think, that it makes sense. We tried to compare two approaches (yours and card poker) while estimating amount of time required for 1 specific user story. Well, it is not 100% your approach in fact, because we still tried to use estimation and ideal days, but we took your idea concerning 2 story points tasks. But we are not ready to forget about estimation yet 🙂

First we estimated using card poker, and then repeated estimation using your approach. And we found the following advantages of your approach:
– your approach gave us complicated tree of concrete task. That means that we could just take them and start working on this user story, we know what and how should be done. In other words we have got a plan! Card poker didn’t force us to decouple user story into atomic tasks and just gave us list of generalized tasks (which themselves can be user stories).
– card poker estimation gave us some number of story points (we used ideal days according to scrum guidelines), let it be X ideal days. And then we used your approach for estimation: number of atomic tasks multiplied by 2 story points (we still use ideal days 🙂 ), let it be Y ideal days. And we have been amazed, that Y was 10 times greater than X! 10 times! That’s too much.

This experiment shows us that standard estimation lacks of accuracy a lot… well, we suspected it, but only after experiment we saw it clearly. And using card poker (i.e. bad decoupling) we constantly have problems with developers got stuck in development process, and as a result they do 5-days task for 2 weeks or even more. We have one user story, which had been estimated as 8 days, but two developers work on it for 2 sprints already. It’s no good at all.
So in the near sprint we’ll try decoupling user stories into 2 story points tasks and watch the result.

I have a couple of questions about decoupling and sprint planning, and it would be nice if you provide your point of view concerning them.

In your post about requirements management (http://epistemologic.com/2007/04/08/requirements-management-user-stories-mind-maps-and-story-trees/) you touched only initial planing. But what to do with bugs and technical tasks? I’ll explain. Look, our project has been in development for 2 years, we develop payment acceptance system. And our system has been in use for a bit less than 2 years (it took approximately 3 moths to issue first release). So it changes constantly, we issue new release every 2-3 weeks. But when the development started, team suffers a lot from a lack of project management experience. I came to project few months ago (I’m not a project manager, just developer, who wants to improve project). Now situation seems to improve. But we have a LOT of bugs. As you understand, these bugs can’t be attached to specific user story, moreover we hadn’t user stories before, in fact we introduced scrum only 2-3 moths ago.

For example we need to fix one bug (one of many) concerning working with hardware. And we clearly understand, that we need to refactor part of our system, which works with hardware. It could take a lot of time, we understand that we need to add hardware manager, change hardware interfaces and so fouth in order to unify working with hardware. And it should be done, because if we just fix bug not changing anything, then literally tomorrow we’ll have to fix similar bug, and then another one, e.t.c. How this task should be registered? It is not a user story, because product owner (or stake-holders) wouldn’t see the result, they wouldn’t be able to “touch” it, it can’t be demonstrated to them. And it is not a defect for particular user story, because it is the behaivour of legacy code, we haven’t corresponding user story. What should we do?

I see only one solution. We should wait till stakeholders give us user story concerned this functionality. For example, stakeholders want us to add support for a new type of device. Hence we can include refactoring task to a bunch of tasks under this user story.

But our system has been in development for a long time, and we added support for a lot of devices already. So it can take a lot of time till suitable user story will appear. And we should just wait and fix bugs?

And how to register bugs if we don’t have corresponding user story?

Another one situation we faced yesterday. If we have user story, which involves a lot of changes in architecture. That is user story contains a lot of task, but these task can’t be accomplished separately, and they are not user stories themselves, because they are technical tasks (refactoring and researches). It’s clear that we can’t show them to stakeholders, but we can’t accomplish user story not accomplishing these tasks. And we think, that we won’t be able to accomplish all these tasks in one sprint. And I don’t know how we can decouple 1 user story intro several user stories. What should be done?

Correct me please if I am wrong in my interpretation of user stories. I think that user story is “something” useful to stakeholder. Stakeholders can “touch” user story, they can take a look at it, they can play with new functionality and so fourth. Hence anything that can’t be demonstrated to stakeholders is not a user story, is it so? Stakeholders are not interested in tasks, they want to know only 2 things: What and When, they don’t want to know How.

And I have another one question concerning terminology. What does “epic story” mean in terms of user stories? How does it compare to user stories?

Looking forward to your reply.

Best regards,
Dmitry Lobanov

OK – so here’s my take on the questions raised:

User stories: I’ve had to deal with the question of what a user story is quite a few times over the years. There are many theoretical definitions – and I don’t care about most of them. In my opinion, the only thing that matters is this – a user-story should add business value. That raises the obvious – shouldn’t everything you do while working on a project satisfy this criteria? Yes, it should – and this is usually something that business stake-holders understand quite well.

There are several kinds of stories. The first is the obvious “feature” stories that have a GUI etc. This is the category of stories that can be “touched” and is “tangible”. Justifying this one is easy – indeed, these are the ones most commonly requested by the business.

Then there are the “technical” stories that don’t have a UI – e.g. – “store the uploaded data in a compressed format because the space used up by the system right now is costing us too much money”. Again, the value is obvious.

The next category is bugs – fixing these delivers clear value and are no trouble to manage as such. See below for more information.

One other type of story is the spike. These are easy to deal with since it is obvious what value they deliver – namely an experiment to determine if an approach might work.

The final variation is stories that deal with paying down technical debt. These are harder to justify because the business is usually not technical enough to understand these. There is no easy answer to how to sell these – but there is usually a very tangible benefit that can be attained by playing these cards. Usually this benefit is deferred – allowing the team to build new features faster, or reduce the number of bugs being discovered in a subsystem. When put in these terms the business is usually quick to understand – and then it boils down to a question of ROI. The cost of implementing these cards should be less than the savings they represent. It is important for everyone on the team to see the whole – and make these decisions together. The key is to sell the business on the value these stories delivers as opposed to the technical details. And by the way, this should be done whenever the debt starts to weigh heavier than what it should. A clean code-base is a happy code-base.

How to deal with bugs: The short answer is I usually treat bugs as stories. They don’t need to be associated with a specific user story. A bug is a bug – it doesn’t matter how it came to be – (of course, it is often related to a story – and most often the same developer ends up fixing such bugs) – and I track them in the same system used for stories. I also let the same prioritization process determine which ones get fixed and when. Further, some bugs are so tiny that they may even get fixed without there being any record of them at all. Some are so large that they might actually result in multiple stories – especially if a redesign is required. Keeping in mind that it is cheaper to fix bugs sooner than later, bugs can be managed just like any other story.

So – to recap, I don’t care for the theoretical definition of user-stories – that they should be tangible and what not. Instead, I recommend that folks do what makes sense for their situation. If I had to give only one tip around stories, it would be this – keep them small. This mnemonic might help.

Finally – about epic stories. An epic is merely a feature (or some technical aspect of the system) that is way too large to be completed as a single user-story. It is epic, because it is a large story 🙂 I always keep playable stories down to less than 2 days in length – as far as possible. Epic stories, therefore, must be managed by breaking them down into incremental chunks of functionality. This is possible about 95% of the time – sometimes however when some spike is involved or some hairy technical refactoring is needed – longer stories can be played.

I hope these thoughts answer some of the questions. I’m sure other folks have different experiences and different solutions to these issues – and that’s fine too, since agile is all about adapting.

Lean Software Development For Startups

Here’s what I will be talking about at the Lean & Kanban 2009 conference in Miami this year.

Lean Software Development For Startups

(Or Why Agile Isnʼt Enough And How To Do More With Less)

Abstract:

If youʼre in a startup, then you know that statistically, the odds are heavily against you. Pretty much the only inherent characteristic of a startup that can be counted upon to help, is that of its small size. If the company can be nimble and agile, then it can hope to
gain some traction against its larger rivals.

In such an environment, using an Agile methodology is a given. Without some form of a hyper-iterative software process, it is impossible for a startup to create a successful product. Or even to determine what that product is!

In todayʼs climate, exacerbated as it is due to competition, lower capital requirements for software companies, the compression of Internet time, and the recessionary economic conditions, it is no longer enough to just use an Agile method. To stay
competitive, indeed to just survive, something more is required.

Lean Thinking provides just such an advantage.

A startup needs to ground its philosophy in Lean Thinking, Theory of Constraints, Critical Chain, Queueing Theory, Systems Thinking, and the like. It will obviously gain from the long-term focus, throughput-based accounting, and value-based constructs that these provide.

This presentation is about how Lean ideas when applied to standard Agile processes can make an organization super-productive even in the extreme short-term. Specifically, it draws on my experiences from having run multiple projects using this philosophy during my consulting career at ThoughtWorks, and more recently as a founding member of an Internet startup called Cinch.

—-

So, that’s what the talk will be about. I have a 45 minute slot – so I’m looking to finish speaking in about 20-25 minutes and the rest could be for a discussion. Hope to see you there!

What iteration-less agile really means

I’ve written about the idea of an iteration-less process before, and we’ve been using the spirit of the idea at the startup I work at (Cinch) for the past few weeks.

The idea is simple, and has two parts. First, eliminate the concept of formal iterations (use a pull-system to let work flow through the pipeline – use Kanban cards if you like). Second, replace the rhythmic heart-beat of iterations with actual releases to customers (internal or external).

These releases do not have to be spaced out by a week or two or any arbitrary span of time. They ought to be, in fact, the shortest amount of time that the software system can be re-stabilized after undergoing change (through adding features or fixing defects). Hence, if it takes 2 days to do a release, do it then. If, for some reason, it takes 6 days (instead of the old five), then so be it. However, the focus of the team should be on getting quality software into the hands of the final users. After all, everything else is inventory.

Pretty simple, eh? We have combined this with the idea of the estimation-less process, for even greater effect. I have been hearing from some people that I have worked with in the past, and they’ve reported excellent results through just such a process. So, anyway – that’s what iteration-less means. 🙂

P.S.

In a past life I had spoken about this with Jeff Sutherland when I attended Deep Lean (in 2007) – and he agreed that this made sense. He didn’t recommend it for any but the most experienced team – and I certainly agree with that. If your team is new to agile or is lacking in some other way, getting it going with the standard approach to agile is probably the best thing to do.

However – if your team can pull this off, you might want to give it a shot and see how much productivity increases over time.

You don’t need story-points either

Or an estimation-less approach to software development

I’ve had too many conversations (and overheard a few) about re-estimating stories or “re-baselining” the effort required for software projects. The latest one was about when it might be a good idea to do this re-estimation, and how, and what Mike Cohn says about it, and so on. The logic appears to be that as you gain more knowledge about the software being built, you can create better estimates and thereby have better predictability. This post talks about estimates, how they are just another form of muda (waste) and what might be a better way.

First things first

Lets start with fundamentals again. In order to stay profitable and prosperous, a software products company must be competitive. If you do enough root-cause analysis, the only thing that can ultimately ensure this is raw speed. Hence, the only metric that matters is cycle-time and organizations must always try to reduce it.

OK, so now, the issue simplifies itself – all we have to do is look for constraints, remove them, and repeat – all the while measuring cycle-time (and thereby throughput). Simple enough! And in the first few passes of doing so, I first realized that if you must estimate things, use story points. Then I realized that estimation in general is a form of muda – and converting from story-points to real-hours at the start of each iteration is a really stupid waste of time.

Even less muda

Now, having said all that, we can move on to the point of this post. I’ve come to realize there is a better way. One which achieves the goal of faster throughput, with less process and less waste. Eliminate estimation altogether. You don’t even need story points anymore. Here’s how it works –

Take a list of requirements. Ensure they always stay current – you know, by talking with the stakeholders and users and all the other involved parties. Ensure it is always in prioritized order – according to business value. Again, not hard to do – you just need to ensure that the stakeholders are as involved with the product development as the rest of the team is.

Next, pick a duration – say a couple of weeks. If in your business, two weeks is too short (you’re either a monopoly or you’re on your way out) then pick what makes sense. Pick up the first requirement and break it down into stories. Here’s the trick – each story should not be more than 1-3 days of work to implement. In other words, each story, on average, should be about 2 days of development time. Simple enough to do, if the developers on your team are as involved in the process of delivering value to your customers as the business is. Pick the next requirement and do the same thing, keep going until your two weeks seems full. Do a couple more if you like. Ensure that this list stays prioritized.

Then, start developing. There is no need for estimation. Sure, some stories will not really be 2 days worth – break them down when you realize it. Sure, you need good business-analysts and willing developers. You’ve hired the best, right? Next, as business functionality gets implemented to the point where releasing it makes sense, release it! Then, repeat.

What (re) estimation?

In this scenario, there really is no reason to do formal-estimation at all. Sure, super-high-level sizing is probably still needed to get the project off the ground, but beyond that, there is no need to do anything other than deliver quality software, gather real-user feedback, and repeat.

Now come the questions of how to say how much work is done, or when a certain feature will be delivered. The dreaded “how much more work is left” questions. The answer in this new world is simply = 2 days * number of stories in question. (Remember the average story size?) Many people like to track things, but measuring actuals is also muda.

The important thing is of course to not look too far ahead. In today’s business environment, the world changes at the speed of the Internet, so luckily this works to our advantage. Whenever something changes, you just re-prioritize the list of stories. This process is not only much leaner, it is also much simpler.

Let’s come back to the issue of re-estimation. People cite the fact that during the start of a project, there isn’t enough knowledge to truly estimate the high-level requirements. Then, as the project proceeds and they learn more, they seem to want to re-estimate things. I ask, why bother?

The key here is to recognize that “accurate” estimates don’t deliver any business value. It is only important that complex requirements are broken down into incremental stories and they are implemented and released quickly.

The real benefits

The fact that this saves time and effort is actually just a good side-effect. The real value comes from being able to truly stay in control of the development process. Tiny stories allow you to change them when required, pull them from the backlog when needed, or to add new ones whenever business demands it. It also lets you move faster because it’s easier to write code in small incremental chunks, testing is easier, and pushing small releases out to users is easier.

And finally, by imposing the discipline that each story be small, it ensures that people think about the requirement deeply enough before coding begins. It also forces the team to break down requirements into incremental pieces and totally avoids never-ending stories that always have a little bit left to complete.

So there

This allows the whole process to be streamlined. It allows the team to focus on just what the users cares about (working software at their fingertips), and not on all the meaningless artifacts mandated by many methodology books (and indeed unenlightened management). Also, in this manner we handle the issue of estimation and re-estimation. In a zen-line fashion, we do it by not doing it.