How Suppliers Can Plan for Growth

DEV projects are about building prototypes, and we choose which prototypes to develop according to their potential. This means that a project will start small, but will have the potential to become big once the DEV prototyping phase is complete. Consequentially, suppliers need to field small teams during DEV, but they have to be ready for growth after DEV.

It’s all about project scaleability. Team expansion should happen easily and naturally without being constrained by inappropriate small-team thinking. The practices that make a project successful in the early days can be precisely the same ones that hamper expansion and productivity when the project needs to grow. Ironically, that early success can prejudice teams against making changes that are desperately needed.

Clearly then, it’s best to make sure your development practices are scaleable at the very beginning. But what actually is it that suppliers need to do?

• Expect knowledge to become localised. Agile development teams are famously – some might say infamously - non-hierarchical. This is most apparent in XP which mandates a common ownership of code within the team. That works fine when teams are small enough to be self-organising – as will typically be the case during DEV - but it is difficult to scale beyond a team size of a dozen people or so. With larger teams it becomes increasingly difficult to maintain the level of peer-to-peer communication that Agility depends on for knowledge dissemination. As a result knowledge will become localised, and people will become expert in certain areas. You must expect this to happen.
• Go with the grain. If a project is to succeed after DEV, then suppliers must plan for breaking up a growing team into Agile sub-teams. Simple tools are called for, and on DEV we build them in from the start. One of the “keystones” behind the DEV approach is the “component-expert allocation matrix”, which can be nothing more than a sheet of A3 tacked to the wall. The names of the developers are listed on one axis, with the components they are responsible for listed on the other. This isn’t meant to stop anyone from checking code out from someone else’s space and working on it, but it does mean that the assigned expert must be consulted before a change is implemented (a design review), and consulted again (a code review) before the change is checked in. This simple approach to managing team responsibilities gives suppliers a recipe for creating small, more Agile teams out of an increasingly clunky large one. The experts with responsibilities for components within the same architectural partition can be broken out into a new team. The principle of shared code can then be scaled to the partition each team is responsible for.
• 
• Be prepared for some resistance. All too often, Agile teams will stumble their way towards making these discoveries. Lessons are learned only reluctantly because developers, as a breed, enjoy coding and don’t want to have to consult with an “owner” before making any changes. Nor do they want to repartition their work and cede control of part of the codebase. The supplier team lead will need to exercise control over this...usually a combination of both soft skills and authority will be required. Without this control, inexpert changes will end up being made to both implementation and to any existing unit tests. The wheels of the project will start to spin as the quality suffers, and they’ll come off unless emergency action is taken.
• Don’t leave it too late. Sometimes emergency action does come too late. This is when responsibilities have not been managed, the damage has been done and nobody knows where, so reverting to an earlier cut of the code would be of uncertain value even if it was politically acceptable. For example, gnarly problems often happen with rapidly developed web apps that have become brittle through an overloaded session handling design, and with rapidly developed back-end systems that do not have container-managed threading. Simple systems can grow into these monsters quite easily, as early, unscaleable design decisions return to haunt the project.
• Apply the right lessons. Sometimes emergency action comes in time…but unfortunately the wrong action is taken. For example, I’ve seen architects and project managers try to allocate areas of expertise by use-case. It is easy to see the logic behind this, certainly when use-case driven development has been identified as a best practice. If the use-cases are elicited up front, what could be more natural than to allocate them to specialists before the system gets out of hand? The problem with this approach is that components are likely to span multiple use cases, so developers end up stomping over each other’s work and get into “merge hell” during check-in. Worse, it’s enormously impractical to repartition a system and allocate developers to new teams on a use-case basis.
• Componentise subsystems. It is much better to repartition a system and a team on a component or subsystem basis. The method of communication between teams should be through stable interfaces; it is the responsibility of the team leads to communicate those contracts (e.g. by maintaining JavaDoc and/or by frequently reviewing the architecture on a whiteboard). If there seems to be a need for developers on different teams to talk to each other directly, then this is an indication of interface instability and it should be handled as such.
• Keep it Agile. Respect the boundaries of iterative-incremental release cycles. At least one full scale, end-to-end internal review should be held per iteration. This would ideally be 24 to 48 hours before the increment is due for demonstration and release, allowing enough time to iron out any problems.
• Keep it Sensible. For example, SCRUM-type standup meetings should be held daily. But in my experience holding a standup first thing in the morning should be avoided, for the following reasons:

1. team members need time to gather their thoughts before they can participate in a constructive and pro-active manner. This is rarely possible first thing in the morning immediately upon arriving at work.
2. rushing for meetings is, alas, all too inevitable in a busy working day. Do not compound the problem by requiring team members to fight rush-hour traffic in order to arrive at a meeting on time. The 8 or 9 AM meeting is probably one of the greatest physical risks an employer can place upon a worker without incurring health and safety liabilities!

- Ian M

Ian Mitchell is a DEV Project Manager and has a special interest in process engineering