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
