The Agile methodology is getting bigger by the day. It abounds in a wide variety of techniques and practices, each of which can be a better fit for a specific project than the rest of them. While Kanban can be the thing for one project, another project may benefit lots more from the use of Scrum. However, in both cases there would inevitably be boisterous discussions as to how much time one should spend on task planning and how much planning is enough to be efficient and productive.
In our work we utilize both Kanban and Scrum practices. Usually, we favor Kanban over Scrum whenever it deals with maintenance and support projects. This happens because Kanban is a task-oriented approach. As you deal with production support and maintenance, you have to be task-oriented and the reasons for this are many. The first, and, probably, most important one is that tasks tend to arise in no particular order, and they can get re-prioritized just as chaotically. The Kanban approach allows an R&D team quite bit of free hand in dealing with this fickle and unpredictable environment.
In turn, Scrum is better suited to product-oriented projects, when the R&D team can have a bit more certainty in their expectations as to what can be required by the client’s business next, when tasks take longer to implement, or when there is a need to integrate the work results with those of other parties. Nevertheless, both the approaches require that some planning efforts be in place, aimed at delivering a well-designed and high-quality solution.
There are those, who say that any initial task analysis is more of a waste of time, as this work will be once again be done anyway during the implementation phase. At the end of the day, your engineer will spend the same or an even greater amount of time doing this work. As a team, your developers will spend even less without the otherwise unavoidable meetings and discussions. At first, it seems like these folks have a point. However, as is shown by practice, the absence of proper preliminary analysis and meticulous planning of each and every task can easily backlash with a bunch of missed deadlines, poorly thought-out solutions that entail performance issues, missing functionality, or poor overall quality of the product.
Here is a typical example of the above situation.
A development team needs to implement some relatively simple feature that, at first glance, looks pretty straightforward and unlikely to take too long to develop. So what do they do? They cram this piece of functionality into their next spring and expect the thing to be gotten over with within this upcoming sprint. But after the developer guy, who’s been given the task, takes a look at the existing code base, lots of interesting things start coming to surface.
For example, the requested functionality may entail code changes to several system modules, the piece of the code that needs to be modified requires some re-factoring for the required feature not to take even longer to develop, the system performance may be not as good, as expected, and there may be no way to implement the functionality as requested due to some limitations, imposed by the existing code.
The result of all these discoveries can be the need for the Project Manager to present themselves to the client’s business stakeholders and declare that the functionality he or she has been promising them to deliver next week can only be available in a month’s time. While the timeline still seems to be the same, the flip side is the client may change their idea about your ability to make good on your promises as a provider. This kind of situation can also impact the whole of the project very negatively.
How to avoid, or, rather, minimize the possibility of such situations happening?
Well, to us, the answer is pretty obvious: there should be some process involved that can help the team better manage their work and be more efficient. And this process is none other than proper sprint planning.
We have used the breadth of experience we have collected over the years to define a well-performing project planning approach that allows our teams to be precise about the sprint scope and enables us to develop well-thought-out software solutions, while ensuring a very good quality of the resulting product.
An Efficient and Effective Sprint-Planning Approach
A crucial factor that needs to be arranged and agreed upon before the start of any Agile software development project is the development team having enough time for planning efforts.
At first sight, this is every project stakeholder’s nightmare: the team will include less and less work in every next sprint.
Simultaneously, some 50%, or, even, 60% of the time, spanned by any upcoming sprint, should, in our view, be spent on planning, while only the remaining 40 or 50% should be spent on the so called “actual work”, or, in plain talk, on mere coding. Sounds terrible, doesn’t it? It sounds like the team will be producing 50% less product functionality, if this approach is adopted by them. But this is a fallacy.
In actuality, the absence of preliminary planning makes the team spend the same amount of time on code analysis and solution design, the difference being that whenever these activities are initiated and performed not as preliminary preparation work, but as a part of the current sprint, they result in much bigger time losses. This happens because the insights, captured by the team during this process, can change dramatically some of the initial fundamental ideas about the way the solution should be, and, thus, lead to some big-time re-engineering.
It is extremely important to understand that, if the Project Manager does not allow the team to spend, at least, 50% of the current sprint’s time on planning their work for the next sprint, this will lead to a loss of around 30% of the working time due to all kinds of unexpected issues the team will have to be solving on the fly.
The conclusion is (even if you hate the way it sounds), the commitment for the sprint should take into account a fair amount of time to be spent on the preparatory work. This will help rule out any unpleasant surprises during the next sprint.
How to do that in practice? Well, we’ve been doing a jumbo amount of enterprise software development, so we’ve gathered a lot of positive and negative experiences we’d be happy to share with you in our forthcoming articles.
Written by:
Sergey Bobyr
Account Director and Head of PMO at SYTOSS
Sergey’s career in the software development industry spans in excess of a quarter of a century. He has held a string of senior Technical Management positions (including Production Manager and Release Manager) with several international software vendors, engaged in the development of bespoke enterprise-grade software systems for major-league and mid-sized Western and Mid-Eastern Telcos and other businesses.
