From the outside, development projects of a reasonable size look painfully slow. We fail to appreciate the hidden complexity, too comfortable with our simple vision that ignores the awkward details. Desperate to speed the team up to the pace we expect, we tighten the screws, telling them “there just isn’t time” to think about more design or reuse.
Applying pressure focuses teams on short term delivery at the expense of investing in design that will make future work simpler. Ignoring good design leaves us accumulating technical debt that soon reduces our capacity to deliver. Our attempt to speed up causes deceleration.
To effectively deliver an application we can’t fully comprehend we must prioritise learning. We then focus on building that learning into the team and the code so that it can be shared as the application grows. Our learning forms abstractions that help break down the complexity and convey our ideas in a clear way. It takes deliberate effort and often many minds working together in harmony.
Creating applications this way requires time to think interspersed with dialogue that tests and stimulates our ideas. When the whole team works this way, combining the different strengths of each member, our pace accelerates as the product grows. It’s never perfect, as we learn more we look critically at what we’ve done before and express our new learning with better abstractions.
Increasing our capability requires us to slow down and let the team learn as they build the application. As Scrummasters, managers and coaches, we contribute by encouraging curiosity and creativity. By sharing our observations, and providing different perspectives, we remind the team of the purpose of it all without influencing how that purpose is achieved. When we get it right we get better at delivering value each day and only then will the development rate accelerate.
Diary of a ScrumMaster 