Frameworks
Frameworks are containers for patterns of practice that help manage the execution of work. A framework can influence the formation of anAgileMind in the same way that adopting new practices can. The influence of a framework is likely to be superficial because the framework supports doing without understanding, doing without being. Frameworks are defined in different ways. High-level frameworks describe practice (what should be done) but not process (how it should be done). Low-level frameworks are prescriptive about process too.
Types of Framework
The term Framework is deliberately vague. We have observed many types of framework ranging from loosely defined (e.g. Kanban) through lightweight but well-defined structures (Scrum) through to heavy duty, detailed, process proscribed models.
The only meaningful judgement that can be applied to a framework is how well it supports the agile mindset in the context in which it is being used. Arguably, heavy duty models will always be deficient because they constrain the autonomy of at least some teams to decide how they should work.
Another caution with Frameworks is they encourage a focus on practice rather than mindset. Even where the framework positively advocates for the agile mindset - the Scrum Guide, for example - many adopters ignore this strong advice and opt for doing over being.
“...start with a capable leader. Without effective leadership, Scrum and Kanban can quickly devolve into form over purpose and fail to actually become Agile.”
Considerations
-
An important way of classifying frameworks is to consider whether they are driven by a cadence (schedule) or by occurrences (events). Scrum is an example of a cadence driven framework. Teams decide on the length of a Sprint and the scheduling of the key sprint events. Events occur because they appear in the team’s schedule.
-
Kanban is an example of an occurrence driven framework. The execution of the Kanban activity stopping the line is triggered by the occurrence of an escaped defect. As a team, we must be able to identify that there is an escaped defect. Then we must work out how to respond. Finally we must implement and evaluate our response.
-
There is a belief that occurrence driven frameworks are more effective for teams to adopt than cadence driven frameworks. We would argue that occurrence driven frameworks require greater rigour and discipline on the part of the team. Adhering to a cadence is relatively easy. The events are booked in the team’s calendar.
In contrast, to respond to an occurrence the team must have sufficient rigour and discipline. It must identify the occurrence, then define, perform and measure its response.
This appears to be a more capable level of rigour and discipline than following the schedule defined by a cadence. Using the idea of shu-ha-ri, we might suggest that teams new to agility start with a cadence-based approach. They can change to an occurrence-based approach as their capability increases and if the change would improve their work outcomes.
-
Scaling is a requirement for many organisations. Effective agile teams are typically small. To deliver capabilities at scale we will need multiple teams. Now we need to face into the challenge of coordinating the work of the teams.
The need to coordinate imposes constraints on the autonomy of teams. To the extent that a scaled approach requires teams to adopt shared practices, the ability of teams to choose their own practices is removed. Lightweight scaled frameworks will impose fewer constraints on autonomy because they impose fewer shared practices.
-
Teams grow in maturity and capability. As they grow they outgrow the constraints of their chosen framework. The process the team uses evolves beyond the definition of the framework. This is the concept of shu-ha-ri in practice.
Available Frameworks
SAFe
Scrum@Scale
Nexus
Disciplined Agile
SRE
Kanban is an occurrence driven framework that is widely applied in manufacturing industry. The ideas of Kanban have been adapted for use in software engineering. In contrast to cadence-based frameworks such as Scrum, Kanban focuses on the efficient continuous flow of work. To enable continuous flow, transparency of process and full visibility of all the work are two critical focuses for the team.
Team Health Checks are commonly used by the agile community to help teams assess their strengths and weaknesses and to take action to improve. As we move towards Product Thinking the context expands to include far more than a single team and many more activities too. The Product Health Check is designed to accommodate this broader range of concerns. It does not replace the Team Health Check, but is designed to supplement it so that the teams, together, gain a more holistic view of the health of their working context.
The increasing popularity of Product thinking and DevOps requires teams to take on more responsibilities than would traditionally have been the case. The Product Health Check focuses our concern not only on team health, but also on the health of the product context. Only by ensuring healthy teams and healthy product contexts can we sustain effective delivery.