Let us be honest with each other; agile is illogical. Not the theory, but I refer to the illogical practice of agile. The certification factories have given us frameworks, generic approaches and examinations based on incomplete or specific scenarios. Then, as practitioners, we have tried to take these frameworks and apply them in every scenario or situation. It is the agile equivalent of The Emperor’s new clothes, illogical!

You cannot take, train and exclusively use one framework to produce high-quality solutions. Every framework needs additional practices. Take estimation, for example. What does Scrum or SAFe teach about estimating? Yet every team needs to calculate capacity and balance workload using measurement. The self-managed team is the foundation of agile. Ask yourself how these popular frameworks support team building or getting people to work together.

Look closely at Scrum; for over twenty-five years, the most widely used framework. But unfortunately, agile practitioners have worked with a “purposefully incomplete” and immutable framework that only defines the parts required to implement Scrum but not what a team needs to develop high-quality solutions. High-quality solutions demand quality and testing practices that are more than simply stating how we improve quality in the retrospective!

Look at the second most widely used framework, SAFe. SAFe provides structure, governance, and rules for mega and large teams, and it is essentially an agile programme management approach. I have been in and around technology departments for over forty years and rarely encountered functions that consistently and significantly only deliver mega programmes. The reality in most technical development shops is that there are a small number, one or two, large programmes at any one time, plus several smaller-sized developments using single teams. The Lean Portfolio process ensures that the investments are balanced, and no one bets the farm on a single initiative. So why would agile practitioners encourage organisations to adopt a structure and framework suited for programmes, not single teams? Unfortunately, SAFe also does not give guidance regarding the delivery practices needed to produce high-quality solutions.

Surely to be valuable, a framework should address the basic needs of teams. For example, how to; get started, work together, explore and define scope, inspect progress, control their work and continuously improve. These elements are at the core of a new framework, Agile Lineout, designed for business change activities.

Agile Lineout is also incomplete but designed for business change or novice software engineering teams. It provides pointers to the three elements of developing a solution. Namely, the strategies needed to create the required high-value outcome, the need to create an efficient delivery process, and the team behaviours needed to optimise delivery performance and provide employee satisfaction. Agile Lineout mixes guidance from Lean and XP with behavioural science from Amy Edmondson (Psychological Safety) and Richard Hackman (Leading Teams, Setting the Stage for Great Performances).

Agile Lineout is not Scrum or SAFe but a freshly defined alternative. Going back to foundational theories such as Dr Deming’s System of Profound Knowledge, Robert Dunbar’s research on team size, and Tom Gilb’s PLanalysis to get tighter requirements definitions, Agile Lineout covers the framework gaps I have mentioned previously in this paper, and it presents pragmatic advice for teams delivering business change and software solutions. Finally, Agile Lineout supports scaling and coaching agile teams with specific guidance.

The Agile Lineout guide can be found at www.agilelineout.com

For further information and training regarding Agile Lineout, don’t hesitate to contact us at info@b2econsulting.com

About the author, Jon Ward:

Jon Ward lives with his wife, Tatiana, in Westward Ho!, England. Jon is currently piloting Modern ways of working in a software solutions provider in the global financial services sector. Jon is recognised as a Thought Leader by the agile practitioner’s professional body, the Agile Business Consortium.

Jon has experience in agile transformations in large organisations, coaching lean-agile adoption in a six-thousand-employee division of a tier-one global bank, and being responsible for agile business transformation in a four thousand eight hundred employee infrastructure division of an international telecoms firm.