Development After Scrum
&tldr; You should probably be doing Kanban instead of Scrum and you might not need to spend as much time estimating things.
The Current State
Scrum seems to be the defacto standard of software development here in 2017. While it might be able to be credited with moving the industry away from the typical waterfall process, too often it is implemented poorly as simply a miniature waterfall. While that model might work well for some situations, there are more modern alternatives that work better with the way development is done in a continuous manner (delivery, deployment etc.).
Moving To Kanban
As your team begins to adopt continuous development practices and works towards continuous deployment techniques it might become obvious that sprints are no longer necessary and are simply arbitrary time periods often for reporting purposes. Focus shifts to keeping a prioritized list of work that needs to be accomplished and staffing appropriately to prevent that list from becoming too long. This may mean adding or removing people depending on the project needs.
Kanban can make developers much happier in many situations. Having essentially a task list of todos works very nicely to reduce operational complexity and still provide some insight into what everybody is working on and where they are in things.
#noestimates
Once you have moved further away from Scrum it might be time to look into the #noestimates movement.
You may not have heard much about #noestimates yet but I’m going to guess that you will in the near future. It is gaining ground as what I would consider an “alternative” agile method, at least compared to what seems to be the current standard. I have been looking into alternative agile practices for a bit now and found out about Programmer Anarchy a few years back and it struck a chord with me. I am a developer that is tired of the overhead of estimations and meetings and many of the other components typically found in Scrum or Kanban. And I don’t think I’m alone.
Programmer Anarchy didn’t seem to catch on widely though and in the meanwhile I tried to at least nudge the places I worked into adopting more of a Kanban style process.
The #noestimates trend pushes Kanban style development a bit further. It prompts the adopters to question what value estimation brings to the table and to consider if it can be scrapped all together. It would seem to some teams that simply counting the list of things to do can be equally effective in providing a chart to higher ups and yet reduce much of the need for planning meetings and other such time sinks.
Moving Forward
So how might a company transition to less reliance on estimation? Well XING has a couple nice discussions about their process. A first step to evaluate if estimating could be reduced would be to repoint all of the work you’ve recently done as ‘1’ and run the charts again to see the different. The result might surprise you. It really shouldn’t but let’s look at that further. Most of the places I’ve worked end up mapping story points back to time anyways and since two week sprints seem to fairly common, an ‘8’ ends up being a full sprints worth of work. But something that takes a full sprint is frowned upon so it typically gets broken up into smaller stories perhaps at a 2, 3, or 5 level. Averaging out those numbers you’ll come pretty close to a 3 so effectively everything could just be a 3 and mathematically speaking you’d probably be just as close if some are over and some are under. Taking this a step further, if it all boils down to “everything is a 3” then why not just make 3 a 1 since it’s all about ratios anyways. This is why I believe it shouldn’t be so surprising that simply counting the number of things we have to do after they get broken down to a manageable size is as effective as taking more time to decide if something is a 3 or a 5.
There are a couple of questions that become more difficult to answer using this style of development though. The answer to “when are we going to be done with X” or “how many people do we need” become a little bit trickier. It’s my believe that the answer to “when” should be reflected in the priority, so “next” or “after Y”. I understand this makes long term planning more difficult but I counter with the reality that deadlines in software are frequently missed and planning off of wrong information benefits a company less than one that can actually react to change. This is a fundamental shift though but I believe goes along with things like iterative development. If you’re counting things to be done, you might choose to run projections but I think this is often still a crutch to satisfy something that doesn’t actually need that answer.
Criticism of the #noestimates hashtag is that in some form estimation is still taking place. You might be “estimating” to decide if something is broken down to a reasonable size. This ends up being a bit nit picky on wording and while I am one of those folks that will point out incorrect word usage I suppose I could point out that the hashtag is no estimates and not no estimating as in you might use estimation as a tool but not provide estimates for outside use, but I also would have preferred Programmer Anarchy to be more popular.
Mileage May Vary
I would like to point out that I’m not sure I believe #noestimates is the right process for all projects but honestly I haven’t worked in enough massive NASA style projects to make any such claim. My work generally falls in the couple months to a year project type in which I definitely see the overhead of Scrum and “estimation” compared to other options. So maybe look into it and at least know that other things are out there and other teams are using them to be successful and perhaps try it out if you get the chance to.
Links
Originally published at Object Partners.
