August 12th, 2015
Solid business growth and momentum in H1 2015 for Computaris
July 20th, 2016 by Computaris Articles Blog Community Insights
The context for how we, Scrum Masters in Computaris, support our Agile teams in estimates is given by the specific challenges of the telecom industry. We activate in an industry where our software must be up 99.999% of the time, technology makes tremendous progress at a very fast pace and, at the same time, we need to comply with strict requirements for reliability, security and complex systems that require an adaptive change management system.
From the perspective of our telco operator customers, changes in technology come along with complex deployments, growing infrastructure and increasing number and variety of network elements. To support and transparently adapt to their changing requirements we need to integrate customer feedback early in the process through demos and presentations, and this is where Agile methodology comes into place.
How do we accomplish that?
Mainly by paying attention to quality assurance prevention techniques. We prefer to prevent rather than deal with bugs, and to shorten the bug fixing cycle, the testing and the customer acceptance phases, so we invest in requirements validation, in code review, automated tools for code coverage, in continuous integration, and in simulators whenever we don’t have real test systems.
Be it Agile or Waterfall, we still need to commit to timelines and build release schedules we can believe in and this is where estimation comes in. The funny thing about estimates is that developers see them as an ongoing process, whereas managers tend to regard them as definite values. Here are the steps we take, the questions we ask and the information we gather in order to set the same expectations and understanding and be able to plan a schedule.
We work in custom software development which means that every new project is a new challenge. Different projects can have similarities but they are essentially different and since it’s difficult to estimate things that we do for the first time, we have to use comparisons to potentially similar features – and some teams prefer to do that rather than start from scratch, although this can be misleading – or use expert judgement. In other cases it happened that velocity was different from one sprint to another so it was hard to predict how we will do in the next sprint.
For sure the classical bottom up or top down estimation didn’t work by itself and we can’t say that there is one estimation technique that has worked wonders for us, most of the times we used a mix of techniques.
Practice has taught us many useful lessons which I’ll share and detail below.
When we have to deal with new platforms, technologies or frameworks, during the first sprint we learn. Depending on the complexity and the team, during the next sprint we reserve time for learning.
Setup effort is smaller if one developer builds the project structure and then the whole team is brought on board. Specific work areas come with highly specialized expertise requirements.
When dealing with new technologies, we save time for rewriting, refactoring and redesigning where needed.
For complex products, we develop a regression suite that can grow with the project. We start by identifying the needs, evaluate the specifics and technologies and then make an automation plan. We don’t estimate only how much it would take us to build the tests, but also maintain the regression suite.
Some of the things we learnt the hard way was that after first Sprints, effort for bug fixing needs to be taken into account, as well as testing of bug fixes.
Having the QA team start one sprint after the development team allows them to focus on features that were considered “ready for testing”. (“Done” concept means developed and tested)
In sprint planning it’s important that the developers not only ask the product owner what they’re going to work on during that sprint but learn in advance what is planned for the next 1 or 2 sprints. This way we can put in balance effort and priorities and avoid returning to the same parts of the code.
Tips and tricks
Estimates are an ongoing experience and once we complete a task or a sprint retrospective, we look at the tasks we estimated and those we completed and take a look at the variations. If it’s a big variation, be it positive or negative, you want to know why and the first question is how accurate was the data reported.
If the effort was reported correctly, in order to identify the reason for variance, we must answer another round of questions like:
However, no matter if it’s Agile or Waterfall or a combination of more methodologies, we tailor and make the processes work for us. This is how we manage to deliver complex projects of more than 1,500 mandays with teams of 9+ people distributed in multiple locations, and how we manage to meet aggressive timelines while still putting quality first.
An example of solution we developed using purely Agile methodology is the configuration audit solution presented here.
This article is based on the live presentation delivered by Lucia Stoicescu, Computaris SCRUM Master and Project Manager, at the Agile Software Meetup Group in Bucharest. A 3-minute video summary of the presentation is available here.