After several year of watching/reviewing agile project, I’m wondering what make a project a success or a massive failure.
First, to clarify my definition of success is : the team has delivered what the product and/or the end user was expected in a timely way. With this definition, i removed the aspect of a product team not delivering what the end user expect 🙂 that’s occur … sometime … often … 🙂
So, assuming you have a group of 7-10 engineers, what make a project a success or a failure :

Success key :

  • team spirit : everyone is happy to help each team members
  • task sharing : everyone in the team can take every task
  • release : everyone can release the project
  • bugs : everyone works on bugs
  • refactoring : everyone re-factor the code, enhance it
  • Code quality is the first priority of the eng. team
  • Delivering backlog item is the second one.

Failure Keys :

  • each task can be take by only one or two guys
  • Delivering poor quality backlog item, requiring post sprint refactoring … never done in the real life … so increasing the technical debt.
  • Having several backlog : one for the product team, one for the technical stuff … We are delivering software, so technical issue is part of the product.
  • Team changing often … introducing a new person is the team, is not so easy, as the team is working as one guy, it’s may be difficult to be part of it.

That still a list under progress, but from my experience, the two keys for success are :

  • Good communication among engineer and product team
  • Good team work, and in this context, pair programming seems to me the best way to achieve most of the engineering requirement with one practice.

Indeed, by doing extreme pair programing, even team programming is a easy way to achieve all the success point.
Let me explain a bit. What i call extreme pair programming is a pair programing practice were :

  • you change the pair often (at least once a day)
  • as soon as you need an expert point of view, change the pair, to get the help you need
  • as soon as you are block, change the pair, explaining your problem to a new comer, often unblock you.
  • when you need to define a new team practice, take a projector, all the team looking at the screen, only one keyboard … and do an time boxes open discussion to present the benefits of the practice …
  • change keyboard often … may be one developer write the test, and the other one write the code ….
  • you wrote faster code : development is not writing text in a code source file … you have to think, analyze, design, test … So, two brain for one keyboard is not a waste of time
  • Do not interrupt the code writer too often, you have to think about design issue, code enhancement … you don’t have time to focus on typos.

So as a conclusion, may be one of the first development practices to put in place is pair programming for the success of your project.

Advertisements