Practice Makes Progress
Agile organizations tend to have small teams that are capable and empowered to meet the needs of their customers. Frameworks such as Extreme Programming and Scrum have small teams at their core. Scrum, in fact, defines two teams:
- Development Team — 3–9 people who does the work
- Scrum Team — Development Team, Product Owner, and Scrum Master
Part of adopting Agile is changing how the organization is organized. This is why Scrum is seen as an organizational design framework. Culture follows structure, and nothing changes if nothing changes.
However, I also realized that changing the structure also requires changing the process, and both must be considered when trying to become Agile.
Process follows structure
Organizations would have existing processes in place, no matter how formal or informal they are. These processes were designed within the current organizational structure, and changing this structure changes the organizational context of these processes.
Ten years ago I had a conversation on this, but I hadn’t realized the significance. We were an external Development Team building a new product for a new client, and the client saw it as an opportunity to see an Agile Team in action. We talked about 2-week sprints, and that quickly devolved into when requirements must be written, when development must be done, when testing should begin — existing processes, new structure.
Emerge the new process
How do you design a new process? The common approach is to let whoever designed the existing processes design the new ones: leaders or specialized groups. People are less likely to change things that are imposed on them, and this approach leads to a “new normal” that does not afford the agility the organization is aiming for.
A better approach is to simply let the teams decide and emerge the new process. Let the people directly affected by the change decide how they would change. This opens the team’s perspective that they can further change the process when the context changes again.
Key is to establish effective boundaries to guide the teams: in Scrum, these boundaries are the Sprint, a DONE product increment at the end of each sprint, and the roles of the Product Owner and the Development Team.
Interestingly, functional roles tend to influence process. This is why Scrum recognizes no titles for Development Team members — the Development Team must have all the skills necessary to do the work, not roles necessary.
Practice makes progress
I learned of the saying “practice makes progress” at a Today at Apple session in Singapore last November 2018. We are used to the saying “practice makes perfect”, but really each time we practice is an opportunity to progress further.
Teams designing their own processes is a new experience for most, and many struggle at this at the start. It is through owning and designing their processes that teams gain the experience and understanding of designing processes better.
Complex situations require small teams to constantly create and redesign processes to meet changing needs, and this is best accomplished by teams dealing with the complex situations itself.
Becoming Agile is more of an adoption rather than a transformation: organizations decide to become Agile at the start of the journey, and the journey continues, and continues forever.
