Agile anti-patterns: Partial agile

Agile in name only

Agile in Name Only is understood to have been coined by Jurgen Appelo back in 2008 and is sometimes referred to as AINO and Agile Light.

This anti-pattern refers to an organisation that has neglected a cultural and value-stream change and have only adopted agile as a process framework within their technical teams.  It leans towards the doing agile, rather than being agile spectrum.

What does it look like?

There may be multiple Product Owners, ambiguity as to who is the Product Owner, or even an absence of the role.  If a Product Owner has been appointed, they are not empowered.

A Team Lead may have been relabelled as the Scrum Master.  The Scrum Master may also be the Product Owner, and may also be the Line Manager.

There may well be handoffs between silos, inter-teams, and even intra-team.

The majority of people are aligned to individual projects – i.e. people brought to the work rather than the work brought to the people/team.

Despite the partial nature to this anti-pattern, there may well be some benefits gained in terms of process improvements, collaboration and transparency – e.g. some Scrum events may have been adopted and there is a cadence introduced. 

So, this is a stepping stone state and be considered part of the journey – it is certainly not end/ideal state, however.  Like dangling off the cliff, half way up, from your security harness!

Other stand out observations may include:

• projects are the primary method for organising work
• the team’s composition is not sticky, with many members not 100% dedicated to the team – multi-tasking and/or non-sprint goal work prevalent
• the Scrum Master role is ambiguous and may include responsibilities beyond that of a process facilitator / Agile Coach
• getting change out to the customer is likely to be infrequent, difficult, and unpredictable in quality
• delivering/shipping change/value to the customer may require multiple sprints to achieve
• the focus is plan-driven rather than value-driven with adaptive planning

So, for those yet to embark on an agile transformation, read on… here are some preventative measures to avoid this partial agile adoption.

How can we prevent it?

It is important to breakdown intra-team silos through pairing – particularly cross-discipline pairing.  This will encourage a one team mentality and emphasise that we can help each other to hit the sprint goal.  This will help address knowledge gaps, increases the resilience of the team, and addresses knowledge hoarders and single points of failure.

Strive to create truely cross-functional, multi-disciplinary teams that can take an idea from concept to customer.  Encourage and foster T-shaped teams – i.e. individuals with a breadth of skills not just depth; we want individuals who are willing to help hit the sprint goal.

Revisit the underlying values and principles laid out in the agile manifesto – understand and digest the difference between ‘doing agile’ as opposed to ‘being agile’.  Values and principles will always trump practices and tools.  The appropriate mindset is fundamental to success.

Breakdown the ‘them and us’ mentality, particularly with the business, development, operations – consider BizDevOps with team composition.  Strive for representation of each within teams and breakdown those barriers.  Increase trust through the tighter, appropriate collaboration and openness.

Focus on technical excellence, not just the code quality of the desired feature, but how it get’s to your customer by adopting a continuous integration approach, test-driven development, and incrementally roll out a continuous delivery pipeline. Aim to mature the pipeline sprint-by-sprint.  Automate repetitive tasks, particularly testing.  Ultimately, this pipeline should become your primary vehicle of delivering value through your environments to production and your customers.

How do we cure it?

Roadmap to process improvement backlog of work, and incremental look to make improvements.

Re-ignite the agile transformation through adoption of an end-to-end product life cycle approach with a truly cross-functional team composing of members that can take the idea from concept to customer.

Get great at the basics, e.g. follow Scrum, set a cadence, and follow the recommended Scrum Meetings, and gain benefits from the higher collaboration and transparency.

Ask your Scrum Master / Agile Coach to host a value-stream mapping session focusing on creating a continuous flow of incremental value to your customers. Value stream mapping enables everyone across a development value stream to come together to visualise how work is done.

Collaborate across your value stream to incrementally reduce handoff through empowerment and face-to-face conversation, and automate manual steps.

Embrace modern practices, share and celebrate progress with your organisation.

Support a community of practice meet-up of similar skilled people to ensure alignment of improvements and to cut across new silos that can be formed when creating cross-functional value-stream squads/teams.

Hope you found the article on the Agile in Name Only anti-pattern insightful and I’ll look to deep dive into the other two Partial Agile anti-patterns, Water-Scrum-Fall and FrAgile, soon.

Shout out to Daniel John for his assistance ??