Estimates are among the most controversial topics in Agile world; Are they evil? Why shall we even bother to do that? What’s the point of it? etc.
Especially the developers question it so much because they are the ones who should create those numbers. To be perfectly honest, scrum world has been trying very hard to make estimates fashionable again by introducing cool poker cards and by shaping it like a game rather than a serious commitment.
Here is the problem; at some point the product owner or the business side forgets the real purpose of those estimates, attempts to treat them as a promise and even creates solid project plans based on those numbers. Hold on, it wasn’t meant to be like that! Somebody needs to warn these bad boys and girls that it is clearly a breach of trust, if not an agile crime. Developers were promised, before almost every estimation meeting, that the story points they will estimate is only useful for the team and nobody else. They were even told to guesstimate the complexity and not focus on how many days it would take them to complete that story.
Most often than not, some time midway through the project, product owner gets pressurised by the business to give them a deadline. Not knowing what else to use as a metric, the product owner sums up all story points yet to be delivered and looks at the past velocity of team to decide on a deadline. Once the product owner communicates this date back to the team, and justifies the decision by presenting that data, the team mostly nods knowing that they are not best suited for these discussions. But at the same time, they feel betrayed quite a lot of times and secretly promise not to do any estimation anymore. Obviously, they can only resist until the next estimation meeting since they are eventually told this is how the things should work!
I don’t think the estimates are completely wrong or useless for that matter. As long as you stick to the basic principles; story points could be a nice way of guesstimating how complex that story is compared to another baseline story. In other words, if the baseline story is as complex as 1 jelly bean (or martian coin), how complex the other story would be? I would even insist on each team creating their own unique currency system instead of “story points”, so that the business owners should never be encouraged to compare one team’s velocity or delivery capability with another team based on those arbitrary numbers. After all, you cannot really compare jelly beans to martian coins, can you?
During such estimation meetings, the team also have a chance to unify their understanding and possibly identify the unknowns so that the business analyst or the product owner will have enough time to find out those answers before the team starts implementing it. Also, if the story is too big (i.e. more than 5 jelly beans), it will be the ideal time to divide them into smaller chunks.
There are many reasons why organisations go about experimenting Kanban. Often, it is the Operation and Service Delivery teams who would like to be more Agile but find Scrum a bit too unsuitable to their taste due to ever changing priorities. One cannot ignore the difficulty in planning for a sprint when you have no idea what you might be working on tomorrow, let alone a week later. Even though retrospectives and standups are useful practices that can be applied by almost every team in any business, planning and sprint review type of activities from Scrum world may not be straightforward to follow by all.
Another reason of trialling Kanban is to be able to identify the bottlenecks in the flow and pay more attention to those areas to improve delivery speed and quality. Once the Kanban WIP limits are in place, the areas that we struggle as a team will be visible quite quickly, mostly within few weeks. Moreover, we have to focus on those problems and fix them as a team immediately otherwise we will not be able to pick new tasks. Having the sword of Damocles hanging over our head, the team realises the importance of collaboration better since the success and the failure are both measured as a team rather than as individuals. In software development teams, that would often means giving a sincere hand to QA and work together more in order to deliver a story or a task. In an operational team, it could cause the information or know-how to be distributed more generously between team members by additional training or pairing so that the team as a whole can deliver more.
Working in Agile world quite long years, I had a chance of using Kanban across various organisations. Relying on personal experience, I would say it is a crucial part of Agile practices even though not necessarily suitable to every single team. I think the development teams with a very good self discipline, the ones that digested Scrum principles so much so that they don’t need them anymore, can easily practice Kanban with if they have the means to be able release quickly. I personally don’t agree with the strong assertions that you should stop estimations in Kanban style of work, or that you don’t need retrospectives at all. I think you can still use them as and when required depending on the type of the business being conducted. The main benefit I can see is that it brings out a whole new scale of agility to the game, but only for the teams that mastered the Scrum and Agile principles.
The analogy I make is the Guitar vs. Oud. Guitar is traditionally a fretted instrument which gives the player a possibility to learn relatively quickly and still produce a nice music within its limits. Oud, on the other hand, is fretless meaning that the player needs to show a bit more effort and discipline to master it. However, once you master it, the possibilities it provide are incomparable. There is an Anatolian musician named Erkan Ogur, who makes a great music with a lot of different instruments, choose to call Oud as “million fretted” instrument rather than “fretless”.
The question of what should be the ideal sprint length is quite a popular discussion in the Scrum world. Scrum experts rightly avoid prescribing a “one size fits all” solution. Obviously the answer depends on lots of parameters like the nature of business or the formation of team etc.
In the past years, I have worked in 4-weeks, 2-weeks and recently with 1-week sprints with various on-site, offshore or mixed teams; across different software development and solutions delivery companies. For the sake of this article, I will just focus on the sprint length as the sole parameter. First of all, 4-weeks sprints were very difficult to manage and risky. The sprint review meetings are too complex, retrospectives turn to a full-day marathon if not worse, sprint planning becomes a much bigger responsibility. More importantly, if we are doing something wrong as a team, the amount of damage which may incur is much more than a shorter sprint. Equally, if we are doing something nice, it takes a long time until we are congratulated! Even the burn-down charts are so complex that people start to ignore them.
2-week sprint are obviously much more manageable compared to 4-weeks. Team members will have a chance of getting more frequent feedbacks from the relevant parties yet they will also have enough time to deliver some significant achievements. However, retrospectives are still relatively long meetings and people still find it difficult to remember which problems they had some 10 days ago. Planning meetings suffer from the same drawback and it is very easy for the team to misjudge the amount of work to commit to. After all, a lot of things might go wrong in two-weeks time which could prevent the team to complete all the stories they have committed to.
Finally, and possibly more controversially, 1-week sprints are by far the ones I found most practical. Wouldn’t it be great to get a feedback every week to make sure we are developing the right thing in a right way? Retrospectives are short and focused since many team members will remember the positive and negative highlights of the sprint; who wouldn’t remember what they were doing the other week, right(!)? Frequent releases are the other benefit you get for free with a week-long-sprint. Planning meetings are naturally the most accurate too because you will have a better chance of estimating the absence of team members or changing circumstances for the upcoming week, compared to upcoming month. One month is a long time in our world!
Some people might be concerned that the overhead of making the Scrum meetings (review, retrospective and planning) every week would be a bit too much. However, don’t forget that the amount of time you will spend for each of those meetings will reduce proportionally based on your sprint length. My most favourite justification for the 1-week sprint is (yeah you guessed it right!) that you can’t really go much wrong in one week time. Even though it is the team who eventually decides on their sprint length, I sometimes present them my views as summarised above so that they can make a more informed decision.
It might be the right time for Scrum Alliance to update their following diagram and make it “1-4 Week Sprint” to be slightly more inclusive 🙂
Probably an example would explain it better. A while ago, I felt the necessity of doing some kind of a sport since spending time in an office all day long is not really working out well for my bones. I started searching for some local Gym options, but I have been dragging my feet since I don’t really like Gyms. Then I thought of running in a local park close to either my home or office. I started doing that, however as expected in all kinds of sports, you need to make it part of your lifestyle or it won’t last long. The same happened in my case unfortunately, since I have not really been a sports person myself!
A very simple solution was actually just there all these times. I take tube everyday to commute to work. Why don’t I get off at the penultimate stop and walk the rest of it? The main problem was to do some sort of actions to stretch my bones, and the simplest (and most enjoyable) solution was to walk a bit everyday as part of my daily routine.
It is quite a common human behaviour to create some routines or just embrace the usual, and never actually question it later on. Especially in IT, the common motto of “if it ain’t broke, don’t fix it” is something we religiously follow at times. However, sometimes minor changes could result in huge improvements which in turn becomes like a “very good value for money”.
The very same principles valid for individuals can also be applied to the teams. Even in a very stable and productive team, there are magic touches which can improve the efficiency with a great deal. The main issue is to be able to identify such minor changes, and of course, the team itself is best suited to discover them. Remember empowering the teams is an important foundation in Scrum in order to achieve a self-organised team.
I have been using a flavour of “Tiny Retrospective” to identify such magic touches within the team. Before I distribute the post-its, I make a short & inspiring talk with couple of examples to clearly explain the sorts of thing we should be looking for. Almost every time, the team surprises me and even themselves by coming up with such simple and creative ideas! Of course, we apply the ideas immediately after the meeting and salute the achievement with cups of tea during the next retrospective.
I have set up our whiteboard to look like below just before the retrospective:
I came across a video of Belgian artist Stromae explaining how he has created his hit song “Alors on Danse” in a minute. Even though the video is slightly longer than what is promised in the title, it somehow managed to trigger my interest on electronic music.
What is more interesting is that it reminded me the power of iterations as he composes the track as layers of loops. He creates each layer of music, be it a drum or melody, and merges it the with main track whenever he is happy with that layer. With every iteration, he adds more features and delivers a “product increment” as we commonly name in the Scrum process. Furthermore, at the end of each iteration, there is a “releasable” product.