Many of those, who are implementing enterprise software projects, regard Agile methodology as a modern way of developing software solutions for their needs and employ it for this purpose. It is well-known that Agile methodology provides a number of tools that allow one to perform tasks in a flexible way, while keeping projects highly responsive and sensitive to the dynamically changing modern-day market.
Being flexible is in no way synonymous to letting things slide, but many of those who are involved in implementing Agile projects fail to realize this and tend to underestimate the importance of such Project Management processes, as planning, estimation, and tracking of the project status.
At the kick-off of an enterprise-grade project, one can, often, hear harangues to the effect that an Agile project needs neither a Project Manager, nor Project Management as such. All the work is done by very highly motivated, strong and self-organized Scrum teams, and, if one’s team adheres, steadfastly enough, to the Agile principles, everything will be just sunshine and rainbows.
However, what if there is more than one team involved in the project? How can one predict whether some specific part of the functionality will be completed by a specific deadline? How can one determine if the team’s doing a great job, or there is still some room for improvement? How can one make sure that the team is really motivated and it is doing its best? Finally, how can one make sure one is delivering the completed functionality with the required quality and at the time, expected by the client business?
Certainly, Agile is a very flexible way of implementing projects, and Agile teams must be allowed to make both scope and functionality changes. However, this methodology cannot be applied without any rules or limitations, because this can, otherwise, result in a complete loss of control over the project: nobody will be able to understand what the current project status is, when the required functionality can be available for production use, and how much effort it really takes to produce some piece of the functionality.
For these hazards to be taken care of, the Agile process calls for some minimum timeframes, within which the scope is to be kept unchanged or only some minimum changes can be made. This is, of course, about sprints and releases, and, while a release is something larger-scale that can, potentially, allow some minimal changes to its scope, an iteration scope must stay precisely the same as planned. Nevertheless, professional opinions on this vary widely, giving rise to vehement discussions. Moreover, different teams take different approaches and this leads to the absolutely opposite results.
Some teams underestimate the importance of proper tasks estimation and planning, preferring not to “waste” too much time on these activities. Others, conversely, try to be extremely precise in their estimates. As a result, they, sometimes, go overboard and spend too much time on planning. Quite often, these efforts turn out to be a total waste of time because the requirements, eventually, get modified in a big way. Thus, unfortunately, both these approaches inevitably cause poor performance and yield unpredicted results toward the end of each sprint.
There is also quite a bit of discussion and argument taking place as to what units of measurement should be used. Should tasks be estimated in hours or should estimation points be used instead? And how can these kinds of units be gainfully combined?
Having delivered multiple Agile projects to different enterprise clients and being well-acquainted with the full variety of Agile approaches, we’ve defined several practices that allow us to keep track of things, run SCRUM teams in a controlled manner, and keep them productive.
Do what you plan and plan what you do!
In our opinion, this is one of the most important Agile approaches. Of course, this does not mean that we have to plan our activities a year in advance. However, this has to be a hard-and-fast rule for any upcoming release, and, definitely, a must for any upcoming sprint. On the other hand, to keep things flexible, we have posited that the most effective way of running an Agile project is to perform monthly releases and weekly sprints.
The key issue with planning is that when one tries to plan too much work it takes them a lot of time and effort and the result may not always be as precise as expected. In addition, the priorities may change and then the planning efforts will turn out to be in vain.
By contrast, it is not that hard to plan precisely some smaller things, such as, for instance, the scope of work for one week. However, in this case, it must be accepted organization-wide that on no condition can the weekly plan be modified as it is the minimum unchangeable unit of scope. In our view, one of the more fundamental agreements to be made between the project team and the business is that the scope of a sprint being currently underway cannot be subject to change.
Frankly speaking, in most cases, it would be quite acceptable for a business to wait for just another three or four days for some new function to clearly materialize. Moreover, taking this approach can be very beneficial for the team itself, as it will help them to stay highly motivated and retain high performance. Finally, it is extremely important for the Project Management folks to be able to track team performance and predict the team’s work results in case something really needs to be planned upfront (which is, actually, quite a frequent happening in Enterprise Project Management).
Every Agile team have their own experience with task estimates. As is shown by practice, it takes any team a spell to achieve, at least, some level of precision in their estimates. Usually, it takes a new team several months to stabilize their estimation practices, while implementing a new project.
We regard the estimation process as an iterative process that is based on some previous experience. That is why, it is vastly important to stick with the rule that the iteration scope can never be changed within a sprint.
In software development, many tasks are pretty similar to one another in their scope and essence, and this allows us to take a comparative approach to task estimates. This means that when we are looking at a new task, we can try to find similarities with something we have done in the past, and locate these tasks and the corresponding estimates.
If the team keeps proper track of things, they should also be able to find some stats on how precise the previous similar estimates have, actually, turned out to be. Given this approach, making an estimate for a new task can take just a couple of minutes and a near-zero effort, as well as giving you a good feeling about how easy things can be when they are well-taken care of on a regular basis. Certainly, in this case it would make sense to use some artificial units of measurement, such as, for example, points. Under the above approach, it does not really matter what numbers are used as a units of measure in your estimates, as long as you don’t change them as the project is underway.
A number of teams use Fibonacci numbers, - 1, 2, 3, 5, 8, 13, 21… etc., and, as we have observed, this approach can be very productive just as well. For example, the numbers 1, 2, and 3 can be assigned to the easier tasks, while 5, 8, and 13 to the more complex ones, while all the above should also be split into much smaller pieces. The key rule here is to be able to perform each task within one single sprint in order to support the Agile principle of always being ready for the production deployment by the end of each sprint.
Having estimates in points for each task and keeping track of the results of each and every sprint for all your scrum teams both give a Project Manager extremely powerful tools for controlling the team performance, planning future releases, predicting the project results, and exercising overall control over the project.
There are many estimation points- and sprint results-based tools, as well as many reports, which can help you keep track of a project’s implementation and control your development team’s work results.
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.
