Unresolved Forces - Copyright Richard Fabian 2024

Sequences, sprints, and smaller steps

Processes inspired by Agile principles are better than the methods we were using before, but only in the same sense that walking through puddles is better when wearing waterproof boots. The question remains: why are we walking through puddles at all?

Before Agile principles, the favoured production practice was to have big plans and continually refine them until they were ready for use in product development. Lots of documentation would be in constant flux, and no one could read it fast enough to stay up to date. Some chose to ignore the rules and work how they wished. They developed first and documented second, if at all.

Agile development arrived as a solution emphasising direction over destination. We needed this because we see better by noting connections than by seeking out the endpoint. You often know the right direction before you know precisely where you’re going, just as you seek the door and not the room. Moreover, you predict the best course of action before seeing the result, and you should know the need before the implementation.

Christopher Alexander’s building processes included this direction-over-destination principle. His developments were carried out by applying local, stage-appropriate changes. His team regularly held reviews with the client before committing to anything they would pay for. These reviews included everything from the overall design to the colour of the details on the tiles. The significant part here is not the customer or the feedback but the regularity of the review. Rather than following instructions, they were building according to a plan by adjusting its details in response to the data resulting from the ongoing process.

In Scrum, the iteration cycle invites people to set time limits or reduce the scope of their tasks. This ensures that everyone takes the time to look up and see where they are. Scrum requires the team to meet with those who can give feedback on their direction. Then, they can appraise the situation and decide if they need to course correct. They can also inspect long-running tasks and check whether they need a change of plan. Do they need to change? Should they stop? Or can more resources be assigned so that they can be completed quicker? In effect, at any review meeting, the team receives feedback on the observable status of the project and can decide how to prioritise the remaining work, whether this leads to a change or carrying on as before. Once these decisions have been made, they decide on the next meetup date.

As children, many of us played a game of find-the-object, in which we were told whether we were getting hotter or colder. The game was simple. If the hider saw us getting closer to the target, they would say the word ‘hotter’, and if we moved further away, they would call out ‘colder’. This is feedback. Satisfying the customer through regular delivery of working software is the first principle of the Agile Manifesto. Satisfying means more than delivering; it requires we receive feedback on what impact it had. Some organisations need to remember this critical step. Either that, or they prefer their developers to play find-the-object while wearing earplugs.

The iteration cycles of Scrum usually assume multiple days between meetups, which can create a disconnect between the stakeholder and the team working on the project. Scrum attempts to mitigate this problem by introducing the role of product-owner. They stand in for the stakeholders, and are available to answer questions at any given time. It’s not the same as having direct access to the stakeholders, but it has other benefits. Stakeholders can avoid dealing with the poor communication skills of the development team. Having a charismatic product owner is not deceitful. In fact, it only becomes a problem when they don’t understand the stakeholder’s values.

You must act on feedback. You have to change what you do and how you do it. The order in which you make decisions is also critical, which is reminiscent of Christopher Alexander’s generative sequences¹. Generative sequences is the name given to sequences of steps or refinements that produce healthy structures. A healthy structure is well-formed according to the stresses, strains, and forces surrounding it. Feedback must be timely, and a good sequence provides helpful feedback at the right time so that it can be acted upon efficiently. Consider how some building block construction toys, such as Lego^tm, have excellent instructions while others seem inferior. The main difference is not the printing quality but the concern with which the instructions treat the mental model of the builder. The builder must have guidance for the right thing at the right time, and each step has a context. Good design patterns and good instructions are generative sequences. Moreover, good sequences generate a form while not demanding stilted, robot-like following.

So, things created through a process of sequential decision-making steps are of a certain quality, not only due to the steps chosen but also the order in which they are taken. One sequence will have a better outcome than another sequence of the same actions. As a code-related example, consider what might happen if you build all the features first and then fix all the bugs at the end.

Some orderings will only be able to produce a disappointing and inflexible final design. An example would be developing software without considering security or performance and then trying to introduce those aspects afterwards. Other arrangements of the steps will require minimal back-tracking during the final stages.

If the order of steps affects the final design, all agile approaches help because very few lock you into a specific order of activities. None of the elements of the Agile Manifesto prescribes what to do, and few specify when. The essential point is to be aware you don’t know the proper sequence and must actively seek it out.