#NoEstimates, Programmer Anarchy and Mob Programming

The Agile Manifesto has been written 13 years ago with the intention of changing the way software development projects were executed at the time. It prescribed the following:

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

Shortly after a few software development methodologies were fleshed out based on the agile manifesto mantras, probably the most notable are XP and SCRUM. While these two are massively adopted by almost all the software companies in the world (I swear I don’t remember seeing a IT job advertisement without mentioning SCRUM), some new trends that I consider interesting are starting to emerge like #NoEstimates, Programmer Anarchy and Mob Programming.

#NoEstimates

The NoEstimates movement does not claim (contrary to popular belief) that estimations are bad, but that they are just not as useful as one might think. Estimation in software projects is a very hard task to perform when the requirements are clear, let alone when they are vague, which happens often from my experience. Since estimates are often wrong they could also be used to take less-than optimal business decisions. Another problem is that some people often forget these are just estimates and treat them as deadlines, in other words something that is guess made based on (often vague) requirements is used to pin down developers resulting in bad programming practices and unhappy devs, managers and clients when the deadlines are not met.

The NoEstimates movement basically advocates for not using estimates as business driver but rather work in small batches and deliver value as often as possible so that risk taken is minimised.

More info: No Estimates: Let’s explore the possibilities by Roy Zuill

Programmer Anarchy

The idea behind programmer anarchy is that currently almost de-facto software development method standard (SCRUM) has to many unnecessary roles, those roles being the Business Analyst, Quality Assurance/Tester and the Project/Iteration Manager. In programmer anarchy the roles are narrowed down to only Costumer and Developer.

The reason why role X is not needed:

  • Business Analyst: they talk to costumers, the costumers tell them what they want and they basically relay the message to developers. If the developer has questions, the BA needs to back to the costumer and relay the questions. Why not cut the extra link and have developers talking directly with costumers?
  • Quality Assurance/Testing – testers need to understand coding and probably also system architecture in order to perform good tests, so they need to basically have the same skills as developers.
  • Manager – more often than not, manager might not be the most qualified person to answers questions related with the project, typically either the developers or the costumer can better decide on things like: determining the best team to be assigned to a project (developers); decide if a project can be rolled off (developers); deciding priorities on project tasks (costumer).

A number of other agile related activities (like stand ups, retrospectives, estimates, etc.) are also dropped. This approach believes that reducing waste and giving more responsibility to developers enables them to do their job in the best possible way,  yielding better results than the typical SCRUM process. If you want to more about it, I recommend the explanatory video on Implementing Programmer Anarchy by Fred George to get a better picture.

Mob programming

I as I understand Mob programming is sort of like an extreme pair programming exercise but it involves the whole team, as opposed to just a couple of developers. Of course mob programming shouldn’t be used on all tasks (that would be extremely inefficient) but on a task that is big enough, unclear enough and that might turn out to be the cornerstone of a system. Since the whole team is present while developing, there will more ideas, more discussion, more involvement, which in the end should yield a better end result. The knowledge of that important piece of software will also be quite spread since all the team participated in its development.

Conclusions

These are some of the emerging trends in agile that I consider interesting and would like to try some day. In the meanwhile, I hope to listen for other interesting trends in the panel talk Retake on the Agile Manifesto at GOTO Conferece Aarhus.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s