Setting up an enterprise-scale agile department with 200 developers working towards the same vision will ensure you are invited to speak at all of the most prestigious conferences, but is there a simpler solution?
Just get Sam to do it
The simplest way to build software is to find one talented engineer and get them to devote all of their time to building the whole thing. Communication between the team is solid, there is no duplication of effort, and level of trust between those doing the work is usually very high.
Sometimes, constraints in the work to be done will mean we have to nudge up the complexity by one level. For example, there might not be a single individual available who has all of the required skills.
Alex pairs up with Sam
Sam is awesome at databases but couldn’t get the system working without Alex, who is a front-end specialist and even understands the company’s arcane domain-specific-language. They pair program all day until it’s done, with both engineers maintaining a clear understanding of their product and the technology behind it.
Quite often, somebody somewhere will then raise the question “Can’t we have it done quicker?”
Get a team together
A self-organising, cross-functional team will take the same work, and do it more quickly. It’s likely that the increased range of experiences will open up more options for how the work is done and what is finally produced. With a medium sized team, communication should still be good, although overheads will increase. It will take more effort for the team to plan and synchronise the work, and they will need time to understand and improve their process.
The CEO might then feel it is in everybody’s best interest to “challenge the team” by announcing to the market that they’ll be ready by November.
Multiple teams
No amount of motivational beer & pizza will bring this in by November, but market expectations have now been set. Adding additional teams will help if they start soon enough, but overheads will increase greatly. It is no longer the case that all engineers are tightly synchronised in each other’s work, so the likelihood of waste through misunderstanding increases. Each engineer now needs to spend a significant proportion of their time on co-ordination activities.
That said, a well disciplined and well co-ordinated group of teams can be highly effective. We need to add more complexity if we really want to challenge them:
That’s just how we do things round here
Memo from the head of development - as all teams are aware, it is company policy that:
Increasing variables in a system increases complexity, which in turn increases uncertainty in the behaviour and output of that system. Developing software is complex to begin with, so it is desirable to make the process of development as simple as possible. Start with the absolute minimum of process, and only ramp up the complexity levels in response to specific and irreconcilable constraints such as time, budget and available skills. Challenge prevailing policies that add unnecessary steps, and give some serious thought the question; why can’t we just get Sam to do it?
Just get Sam to do it
The simplest way to build software is to find one talented engineer and get them to devote all of their time to building the whole thing. Communication between the team is solid, there is no duplication of effort, and level of trust between those doing the work is usually very high.
Sometimes, constraints in the work to be done will mean we have to nudge up the complexity by one level. For example, there might not be a single individual available who has all of the required skills.
Alex pairs up with Sam
Sam is awesome at databases but couldn’t get the system working without Alex, who is a front-end specialist and even understands the company’s arcane domain-specific-language. They pair program all day until it’s done, with both engineers maintaining a clear understanding of their product and the technology behind it.
Quite often, somebody somewhere will then raise the question “Can’t we have it done quicker?”
Get a team together
A self-organising, cross-functional team will take the same work, and do it more quickly. It’s likely that the increased range of experiences will open up more options for how the work is done and what is finally produced. With a medium sized team, communication should still be good, although overheads will increase. It will take more effort for the team to plan and synchronise the work, and they will need time to understand and improve their process.
The CEO might then feel it is in everybody’s best interest to “challenge the team” by announcing to the market that they’ll be ready by November.
Multiple teams
No amount of motivational beer & pizza will bring this in by November, but market expectations have now been set. Adding additional teams will help if they start soon enough, but overheads will increase greatly. It is no longer the case that all engineers are tightly synchronised in each other’s work, so the likelihood of waste through misunderstanding increases. Each engineer now needs to spend a significant proportion of their time on co-ordination activities.
That said, a well disciplined and well co-ordinated group of teams can be highly effective. We need to add more complexity if we really want to challenge them:
That’s just how we do things round here
Memo from the head of development - as all teams are aware, it is company policy that:
- Engineers are required to respond to sales enquires immediately upon request
- Two week sprints may only be released in line with our three week marketing cycles
- Our top priority is meeting a billable utilisation rate of 85%
- New features must be regression tested and deployed to staging before the product owner will verify the work
- Project proposals must follow the financial directors recommended team composition of 60% off shore, 30% office based, 10% home workers
- All code must be reviewed by me as head of department, or in my absence, by Sam – our new “deputy assistant to the head of department”
Increasing variables in a system increases complexity, which in turn increases uncertainty in the behaviour and output of that system. Developing software is complex to begin with, so it is desirable to make the process of development as simple as possible. Start with the absolute minimum of process, and only ramp up the complexity levels in response to specific and irreconcilable constraints such as time, budget and available skills. Challenge prevailing policies that add unnecessary steps, and give some serious thought the question; why can’t we just get Sam to do it?