The development team at DStv Labs, a division of DStv Online and MIH SWAT has recently been thrown together to look at some exciting projects in the New Media space. In keeping with the latest thinking around agile development frameworks, the DStv Labs team has adopted Scrum as the framework that will be used to deliver these projects.
For those not familiar with Scrum, let me summarise the key principles quickly:
1. A project team is setup usually consisting of between 5 and 9 resources.
2. The resources within the team have the set of skills needed to develop products.
3. There are defined roles within this setup, namely
- The Product Owner: Manages a list of product features that require development. These features are prioritized by the Product Owner.
- The Scrum Master: Ensures that the processes are followed and helps the team deliver the product features by removing any impediments that prevent them from delivering.
- The Team: Self organises around the product features and collectively work together to deliver these product features.
I’m simplifying the roles here of course – there are further responsibilities that are played by each role, but this is the essence.
4. The team produces working demonstrations of the product features at regular intervals (typically every two weeks).
5. These working demonstrations are visible to the business, allowing the business to get a view on where the product is going and whether it needs refinement or a complete change in direction.
6. The refinements or improvements are then fed back into the team, prioritised by the Product owner and driven through to demonstration once again.
The framework is agile in nature. Problems are quick to identify, and quick to change. Traditional project management methodologies would allow a project to proceed down a long and drawn-out development path and if the up-front analysis had not been 100% accurate, or if external factors had required a change to the project during development, this would be very difficult to accommodate. The Scrum process by contrast makes sense – it is a simple, logical way of delivering projects and caters for changing requirements.
That said, the question of how to setup the Scrum team and environment remains. As a new team, we are facing these questions and trying to figure out the best path to creating the esteemed “High Performance Team“. There are two schools of thought here. Let me deal with the first.
As competent and experienced team members, there is a sense of “doing things right, from the start”. This includes everything from ordering the right development hardware, deciding on what software is appropriate, defining the practices and principles the team is going to follow, which languages are best suited for the projects that need to be developed, and what the collaboration environments need to look like. All good stuff, and completely necessary. The planning also includes discussion and decisions around how to test the code that is developed, how it is documented, how much of this is automated versus manual, which tools are best suited for testing, how new issues get logged and fed back into the team, and how much test coverage is considered acceptable. Again, all good stuff, and all appropriate to the work that is being done within the team. It is also a good idea to get the overall context of the project defined up front so that broad architecture decisions can be made. Where the team needs to be careful however, and we are all sometimes guilty of this, is when it comes to over-engineering a solution up-front. Chances are that this picture is changing, or will eventually change. Nothing wrong with good architecture up-front, but trying to understand too much detail too soon is probably wasted effort.
Lets take a look at the second school of though for a moment. The principles of Scrum and Agile development methodologies and practices suggest that the value lies in delivering small, incremental features, regularly. Mistakes and changes to project scope are inevitable and it is the ability of the team to correct these mistakes, and accept the changes in scope that makes them “High Performance Teams”. Through continuous feedback and team “retrospectives”, the gaps get filled, and the holes get plugged. The team continues to improve as a result and the delivery continues to speed up – well, from the initial stages anyway. Its a situation in which the team adapts the principles of Agile software development to suit their unique environment, the individual strengths and weaknesses and their team characters.
The point that I am trying to make here, is that there are two ways to try and achieve the “High Performance Team”. There is the “Lets build the 6-foot armour-plated robot with Augmented Reality vision”, or, the “Lets build the stick man and determine what he needs next” approach. There is a fine line between setting up a team that does everything right from the start, and a team that is setup to learn how to do what is right for them.
I was recently made aware of an agile development team based in the UK that has been together for the past 60 months. They deliver code weekly, have a number of visible metrics for how many bugs are in their system and how quickly they are resolved, what the velocity (capacity for delivery) of the team is, converted into monetary value, and a number of other “reporting” metrics. Incredibly useful information, and a sign that they are a “High Performance Team”, but I wonder how much of that was setup from the start, and how much of it “evolved” as the team progressed through their 60 months of development together?
To take the analogy used above, whilst it is important to have a team vision in place and to follow best practices where ever possible, I firmly believe that it is best to create the stick-man from day one, and get him running in an agreed direction, rather than spend too much time thinking and planning the 6-foot robot that potentially is only capable of taking a few steps at a time, and hopefully, in the right direction.
That being said, our team is in a good place. We are positioned nicely and are moving forward as a unit. Hopefully the discussions that our team have had, and the conclusions drawn here, can help you position and setup your own team.
Related posts:
