Lean Software Development 4
Scrum is fast and controllable, but sometimes such a speed is not enough…
As you know, until the software or set of requirements has been deployed to the production environment it passes several stages:
1. Analysis
2. Development
3. Testing, bug-fixing and integration
4. Deployment to production
It could take some time to analyze set of requirements, develop, test and deploy them to production. After that the product owner
can’t really be sure that the feature gives the same business value as it was originally planned.
Even in scrum with the very short sprints, like 1 week it still gives the concerns about the benefits…
Although, scrum is focused on delivering the highest priority business value as defined by the product owner, sometimes the
deliveries every sprint time is not enough. The world is changing very fast, so you need go live with your ideas as fast as possible.
What if (Let’s put several assumptions to your application)
1. Your system is already running on production.
2. You prefer to see feature by feature on production rather than having a weekly demo with all the features planned to be developed in the sprint. Generally, as soon as the feature is ready, you would like to see it on production.
May be after you see the feature on production you’ll come up with some more ideas that have much more business value than the user stories in your current sprint backlog.
3. Your developers are very talented and professional. You are sure that they will deliver at least 80% of your story. The last 20% – bugs and misunderstandings.
4. The business value of those 20% is 1-3% of the whole user story.
5. The value of the bug or mistake that your team can do is insignificant. If your team has deployed something to production that works only for 80% – that is fine for you.
6. You are sure that deploying new feature will not break down your system. The most terrible – it can lead you to some usability issues on your back-end which can be easily fixed withing one day.
7. Even if the feature has been deployed with several bugs, the business value it brings to your system is more than the price of the bug.
8. So, you are not afraid of deploying your functionality to production.
9. You care more about the delivery than about the complexity. You are sure that your team will always do their best to deliver your user story as fast as possible with the maximum possible quality. So you don’t care how precise did the team put the complexity. Anyway the story has been delivered as fast as possible (You will need the complexity only for making measures, to make your process even faster).
Than you probably can get more benefits from the approach called lean software development.
Examples of the systems which can be under those assumptions:
1. Web site with a backed, 3-5 workers working with the backed
2. eCommerce systems with not more than 50 requests/operator.
etc.
How to accomplish that? You can start from the most important things:
1. Stop working in parallel. If you have several features to be developed, let your developers on all the features together.
If your developers are good enough, than the development of the 3 features (even if is very small, like 5-6 man-hours) with 3 people when they work altogether on feature 1,2,3 sequentially, should be almost the same as if every developer will work on his own task.
But the benefit of seeing the feature live as soon as it ready is enormous, instead of seeing 3 feature together in some weeks. As soon as the feature is on production it starts to help you in earning money, which you can you for developing new feature. So you don’t need to have a big budget for your project.
2. Make your user stories as short as possible – (try to make them not more that 16 man-hours).
3. Install the continuous deployment process
You can get a very interesting explanation here: Reduce lead time
I think 80/20 principle is a bit misinterpreted. It suggests that 80% of features take 20% of development time. It does not say that you may deploy when 80% of feature works
Lean, just like any other agile methodology, starts with the definition of ‘Done’. It is usually an equivalent of ‘Shippable’, which suggests ‘Bug-free’. It is very essential, as all agile processes are based on assumption that dev team does not come back to re-fix features. It is true for Scrum, and it is true for Lean too.
I agree with you.
One of the ideas of the post was to give the examples of the projects where ‘done’ means at least 80%. (delivered means 100%).
I’m not the fan of the “‘done’ means at least 80%”, but in a real life such projects could take place.
Funny coincidence. I bumped into exact same words at OnStartups:
You’re misinterpreting the 80/20 rule
The typical 80/20 rule is: 80% of your customers use just 20% of your features.
The “release early” folks take this to mean: Just implement 20% of the features you think you need, because if that’s good enough to get 80% of your sales, this is a much simpler, efficient, and therefore profitable way to operate a software company.
But this interpretation is wrong! To spell out the 80/20 rule more accurately: 80% of your customers use just 20% of your features, but each customer uses a different 20%. That implies you need more features, not fewer, otherwise there won’t be enough for the various use-cases for your software.
Sorry for confusing – I didn’t mention anywhere 80/20 rule. 80 and 20 where just the examples…
I should have given an example with 90 and 10 or 95 and 5: “In general you are satisfied if the feature is released with 90% of the functions, and the other 10% are not working – it is ok for you, they will be fixed soon”.