Category Archives: Agile Software Development

Agile Software Development, Estimation

We are agile, we use story points… why?

One of the most shocking and at the same time obvious aspects of Scrum is the usage of Story Points to measure the effort to be done. It’s shocking because the teams usually are more familiar with time measures but, once one understands its nature, it’s one of the most obvious aspects of the Scrum methodology.

Time/Effort vs Time/Distance

In a classical fashion based on concepts like the Project Management Quality Triangle, the quality of a project has to be evaluated from three constraints:

PM Quality triangle

So, if we want to deliver the best quality on a project because the quality is not negotiable, as one can infer from the agile manifesto, we must control those three constraints. Even though the scope and the cost are usually determined by the needs of whoever asked the project and his/hers budget, the time is usually something estimated by the somebody who will perform the effort. This will be a problem as the sooner the later somebody will ask for time estimations to the team in charge, and the development team is usually good making software but quite bad in futurology ;-). That’s one of the reasons why Scrum proposes to measure the effort, and calculate the time in basis of the team speed (aka. how much effort can be delivered in a chunk of time).

Even though we have units for the time (seconds, hours, weeks, etc) and for the costs (euros, dollars, bitcoins, etc), there is no clear unit for the effort. For some projects the effort could be “number-of-houses-to-build” but in the case of software development ones it is strongly hard to have a good unit. Luckily, Scrum proposes a really useful unit to measure the effort, the story points. This unit is quite tricky, as one needs to work a few before it is clear, but once it is correctly defined, it solves problems that can be considered superficial and some deep problems associated with the measure of effort.

At the end, and as stated by Mike Cohn in The main benefits of story points, the story points must be seen as the meters/yards of effort, once we understand them in this fashion, we’ll start to be deeply agile.

Main problems of estimating using effort instead of time

Obviously, estimating in basis of effort it’s not easy and from my point of view there is a couple of disadvantages about using story points:

  • We need some background to have a way to measure story points. As stated in some articles (e.g.- Agile Estimation in 8 steps) it is really useful to do some iterations before we can measure Story Points properly this can impact the Product Owner plans, as initially the unit won’t be totally reliable.
  • It’s difficult for the Product Owner  to understand them. Even more difficult if the Product Owner does not have technical background. They are a totally abstract unit and it’s not easy to understand what a Story Point means and how to manage it (and the expectations it generates).

Why we should embrace and love story points

On the other hand, there are several benefits which encourage us to totally adopt them, or at least give them a try. Furthermore I’ll add a couple of interesting (and non-obvious) facts about using Story Points:

  • They drive the team to a better work analysis, as everybody in the team has to compare something deeply in order to give a clear proportion comparing with another piece of software.
  • The conduct to proper roles assigned, the Product Owner can be responsible of timing and to better manage the stakeholders expectation. Meanwhile, the team can take control of effort, not time (as they do not manage resources). Finally, the Scrum Master can mix up everything using the speed, and agile can flow smoothly.

 

 

Advertisement
Standard
Agile Software Development

When does agile fail?

Failure vs Success

The background

I’ve been working under the agile principles during the last 4-5 years. I was used to work under the waterfall principles and methodologies, so I must admit that at the beginning it wasn’t easy. It was quite hard to forget about long-term plans, detailed designs and organizational hierarchies, however after a few time I discovered some enlightening facts that made me love the four agile principles from the Agile Manifesto:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

In fact, during this time I’ve been in several situations in which I’ve been able to apply both side of every principle and undoubtedly I’d rather the agile way. However, I only have a narrow view of the world’s overall software development state. So I’ve thought that maybe the agile way is not the panacea, that’s why I decided to do some research on the agile success ratio.

The reality

Once I convinced myself that perhaps agile was not so cool and good as it seemed to be I started digging into the Internet looking for some references. After a few searches I reached some interesting articles like the following:

In fact, it’s a list of 20+ reasons why agile fail, and many of them come from some of the software market renowned sources like Thoughtworks, so I thought that maybe agile was not so great as I experienced. Moreover, if one does a deeper analysis it is easy to detect some common patterns on agile failure:

  • Fail by people: In this pattern agile fails because of the people. Perhaps our people is not properly trained to embrace agile or maybe we have some reluctant members in our teams, whatever the case may we are not ready to embrace agile and this is difficult to solve meanwhile we have a project in hands.
  • Fail by organization: This is the next level of failure. In this case our people is somehow prepared but, the company environment is not. Maybe the top management does not promote agile (or at least tolerate its existence) or perhaps our organization structure is not agile friendly (physically dispersed team members, non-agile company values, etc), in any of these cases we shall remove these obstacles before starting a real project with agile, or the success of the project will be affected.
  • Fail by communication: This is the third level of failure. Once we have removed the people and organization obstacles we are able to start being agile but, what happens if we are not ready to communicate with our team members in an adequate manner? On the other hand, what will happen if we or our customer is not prepared to work in a continuous flow of feedback? Both situations will negatively impact the success of our agile transformation.

By the way, I think there are a couple of situations that must be considered when we talk about agile failure:

  • Fail by contract: The first extra bonus level of the failure (and the more obscure). From my point of view, this failure mainly applies when agile is used to deliver a service instead of a product so, what will happen if everybody is ready to embrace agile, our organization is also prepared and all the stakeholders are willing to be agile but we haven’t checked our contracts? Maybe everything ends fine but if something goes wrong everybody will be checking the agreed contracts in order to decide who pays the bills and, arrived to this situation, we’ll have inherently failed as no value has been delivered.
  • Fail by concept: Has it sense to deliver a software in an agile manner when the specifications are clearly defined from the beginning? For instance, has it sense to be agile while developing an airbag controlling software? or a plane autopilot software? Maybe it has sense, but from my point of view we can deliver the same value without agile, so it’s up to us to decide whether to change or not.

My own conclusion

From my point of view agile solves the most of the problems in software development and frankly it does software development more human. However, we must take into account that it is not smooth and easy to embrace than one can initially imagine, so we must do a good analysis of how we’ll embrace it in order to be agile doing agile 🙂

 

Standard