People vs Roles, in Agile

The last 1.5 years developing Solar Smash (mostly working on the train in and out from my 9-5) have been, in a word, awesome. Not only do I feel like I have learned more about some of the technologies we used, JavaScript, NodeJS, etc then I would in any normal setting. I also feel like I have learned more about the software delivery process.

When we started this project most of our experience with Agile was of operating as a part of a large team. These large teams would have many people, each with a specialized interest area and role. How else could you function as a project without such a high degree of specialization?

The answer, for us, was to focus on people vs roles. We knew we had limited resources (two people.) Each person involved would need to take on different roles at different times. Walks to work became requirements/product vision sessions. Sitting on the train home after finishing up some new feature became testing time. Other times would be spent analyzing user data, creating art work or documenting new ideas to be discussed in the future.

While we found the experience of switching roles fulfilling on a personal level, in that we got exposure to and experience with all facets of a projects delivery, it also had other profound effects on how we assumed a project should be organized.

Suddenly a requirements/product vision session could be translated into stories and tasks needed to implement the new feature, all in the same conversation. As players of the game ourselves these product vision sessions could be conducted with open honesty and a deep level of understanding for what was needed to make the product a success. Rather then try and work through a set of high level requests to get to the root of what was needed, we could ask ourselves “What would I like to see added to the game”, while also using our data collected from Alpha users to verify our new ideas.

In short the focus on people over roles showed us how a project could be run, where everyone involved has a deep level of understanding of the different aspects of what goes on to actually create the product. Knowledge gained in one area could easily be transferred over and used in another. 1.5 years later the result is a more rounded team, who have experience of all aspects of delivering our product and feel comfortable jumping into any situation.

 

– Conor from http://www.railwaygames.mobi

 

Leave a comment