Life is shaped by decisions. Software development and quality too
How many dualities do we have in our lives? iPhone vs. Android, Republicans vs. Democrats, Coke vs. Pepsi…. Once and once again we see these dichotomies: a “digital” 0/1 view of life.
Try to think about an issue: whatever you like. The last discussion or conversation you had with a friend: it’s quite possible that it was in terms of something vs. somethingelse. No grays, no colors… just a never ending religion war between two ideas, which – very often – are not even that different!
Being interested in methodologies and measurement, I often step into this common comparison: Agile vs. Waterfall. I will generalize the waterfall concept, renaming it to “traditional PM” or “traditional development”
Agile vs. Traditional development
Which is better? It depends. The variety in size, complexity, team experience, types of project (product, maintenance etc…), customer commitment, is crucial to decide which methodology is better… but I don’t want to discuss all these matters in depth. What I’d like to underline is that they are both philosophies, different mindsets, much more than methodologies.
One of the most interesting characteristics of Agile methods is that you need a very well-experienced team, which can adapt to different technologies and projects, but most importantly, who can take design decisions, rewriting and refactoring on the go, adapting to change.
So, generally speaking, change is good: it means that the system converges to what the customer needs.
In a waterfall approach, you can have less experienced development teams, concentrating the analysis in the early phases. The analysis experts can share their time between more than one project, and so ideally that overall process is cheaper. Ideally.
In my experience “cheap” turns often into “more expensive”: the documentation is heavy, due to the level of detail in the design needed by the inexperienced teams. There is very little feedback, so that the development is a bit “blind”, and the result can be poor, in terms of fulfilling customers’ expectations…. and a good analysis not always solves the problem.
With this mindset, change is bad. It’s very difficult and expensive to go back, to rewrite, to rethink. But change is inevitable….
Within these two mindsets, QA approaches are very different, because the development phases are different. For example, testing and development teams are integrated, often being the same team.
Anyway, I don’t want to talk about QA or differences in the processes. I will focus only in the comparison of some metrics.
First of all, product software metrics can be used regardless of which methodology and processes you are using: SLOC, Comment density, Coupling, Cyclomatic complexity, Halstead Complexity, number of classes and interfaces, etc….
In the same way, it’s easy to imagine that is very difficult to apply the same process metrics and quality measures.
One example can be the Running Tested Feature metric. This metric is basically a counter of delivered functionality with positive acceptance test. Its historic chart allows identifying regressions, when there is suddenly a fall in the number of running tested features.
As Ron Jeffries points out in his article, it can be applied to a traditional (waterfall) process. This will inevitably take to a “flat” zones in the chart, identifying moments in the life cycle when the team is apparently not productive.
Other metrics commonly used in agile project management are:
|Remaining Story PointsThe estimate of the amount of work remaining that needs to be done in order to complete a Product Backlog.||It is impossible to apply “as is” in a traditional development process. It is somehow related to ETC (estimate to complete).Other|
|Defects per sprint/release||Defects per month / release|
|Team VelocityAn empirical observation of the team’s capacity to complete work per iteration, measured in story points, hours etc…||It’s a very controversial metric, it is not productivity, and many times misused (it is not productivity!). It could be used in not agile environments, but you have to redefine it.|
|Story Cycle TimeThe number of iterations it takes to complete a story.||N/A|
|Cycle TimeThe average time between delivery of completed work items.||N/A|
|Burn down charts||N/A|
On the other hand, these metrics are not relevant to agile methods:
- Percent complete. “Completion” is a concept which maybe deserves a whole post… let’s point here that while in traditional development there is a contractual concept of completion, in agile is much more difficult to know where is the end, the spirit is “You will know you are done when you are done”.
- Time per team member per task. Such important concepts as metrics about the team are not even possible in a pure Agile environment: the team is always moving, self-organizing, sharing tasks. You could, in principle, track every action of the team… but this activity would be useless and very time consuming. Moreover, this fine-grained control would be against the mere spirit of agile principles: control is frequent enough (usually with one iteration granularity) and always (should) concentrate on business perceived value.
- Actual time vs. estimated time. We could argue that burn down charts are precisely this… and they are. But all the traditional metrics measuring time should be re-tought.
I’ve noticed that Agile teams generally rely more on tools than documentation, while traditional project management is usually more document-oriented. This is obviously just my empirical observation, probably because these two mindset belong to different eras… there is nothing blocking traditional development from being “modern” and use tools to enforce its processes.
Anyway, an Agile mindset probably enforces the use of such tools… and is then probably a good starting point for achieving high maturity levels (for example, with CMMI 1.3)
With this short post I wanted to focus on some differences that make transition between the two worlds really difficult. More than what we think.
This two methodological families are based on different cores values. Different keywords:
|Agile – Lean||Traditional PM|
|no waste, business value, feedback, change is good, refactor, experience, automation||contract, commitment, tracking, change is bad, productivity, organization|
Meet the author Tomás Espeleta
I'm a software architect, lately I'm interested in algorithms, graph theory, processes and methodologies. Since I was a boy I wanted to change the world with a computer: now computers are everywhere, and they've changed us. I love mountains, skating and a sometimes, a good zinfandel. A geek with a wide range of interests ;)