Set Piece Agile Will Sink You!

Introduction

Organizations are increasingly “Going Agile” in a very stepwise fashion. Don’t fall into the trap of believing you can plan your adoption and maturation of Agile principles, practices and tools as if you’re using a chessboard. A commitment to Agile implies you’re ready for evolutionary change and supportive of emergence from the team-level to the C-level. Anything less than this level of commitment will inhibit and potentially cripple your investment in Agile. You’ll blame Agile...but the real culprit is staring back at you in the mirror.

Set Piece Agile

It’s a natural tendency for leadership and middle management to plan for Agile adoption and maturity down to the team level, including who’s on which team, why and (all too often) for how long. These (seemingly) well-intentioned planning efforts are usually based on the current state and experience, perceived ability to adapt to changing conditions, previous Agile experience and optimism. I’ve seen detailed organizational redesign models developed by a handful of people (including consultants) which do not engage  those individuals (both employees and vendor partners) who will populate the Agile teams. This is a feel-good exercise (at best) that inhibits Agile and reinforces the feeling that people are “resources” and “talent” (and not people who need to be engaged.)

Emergent Agile

One of the positive affirmations I’ve adopted from the Scaled Agile Framework (SAFe) is: “The teams drive the Train.”  Substitute “sustainable outcomes” for “the Train” and this affirmation works for any Agile adoption and maturity effort. This waterfall image (yes, the dreaded waterfall...) exemplifies what healthy and sustainable Agile and maturity should look like and feel like:

1. Continuous Flow
2. Reusable Resources
3. Appreciable Risk
4. Known Unknowns

Continuous Flow

Foster evolutionary change versus “Big Bang” change: 

• Plan to combine Agile training (Scrum, Kanban, Scaling, etc.) with focused coaching at the team, leadership and organization levels.  Coaching at the team level is best accomplished with effective Scrum Masters (independent of team framework)
• Allow teams 6-10 Iterations (assuming Scrum or a commitment to timeboxes) to mature their ability to develop and deliver both incrementally and iteratively
• Most teams require a significant amount of time and autonomy to recognize that they own their work and their outcomes.  So keep your teams intact even when they struggle or fail to live up to expectations

Reusable Resources

Facilitate opportunities for teams to share experiences and outcomes:

• Don’t force Scrum of Scrums (for example) on your programs and organization. Allow your teams the opportunity to identify how to best collaborate and remediate impediments; experiments welcome
• Invest in knowledge management (including personal knowledge management) for teams, programs and your organization to precipitate a culture of (potential) continuous learning and continuous improvement. Don’t expect this to happen on its own; it never does
• Dedicate most of your mult-iteration planning time (across teams and programs) to “team time” and minimize the time allocated to executive briefings, planning guidance and direction setting. One of the SAFe practices I advise avoiding is using more than 50% of Day One of Program Increment (PI) Planning for non-team time. If your teams are coming to PI Planning without an awareness of the business context, the prerequisite architecture and how-to-plan, that’s a failure of stewardship (and pre-planning)

Appreciable Risk

Agile adoption should keep you up at night and worrisome during the day:

• Transformational change at the individual, team, program and (likely) organization levels is exceptionally nuanced and intricate (but not necessarily complex.) Expect the unexpected (and welcome it)
• Facilitating multi-dimensional change requires personal change, too. I often meet leadership and middle management staff who dictate transformational change as if they are ordering lunch. They expect an idealized outcome, then disengage once their plans are set. No one succeeds under these conditions
• Owning accountability for this scale of change is a weighty responsibility for leadership (at all levels.) It’s neither a one-and-done exercise nor a set of templates and prescriptive trainings appearing on a transformation checklist or in a statement of work 

Known Unknowns

Identifying and managing unknowns is a prerequisite skill set, without which you are likely to fail:

• Agile teams (including your programs and organization) are in a continuous state of evolution (or your Agile adoption is stale, stuck and sinking)
• Nimble and intuitive leadership is required at all levels to ensure that teams can adapt to unknowns so that your programs are increasingly predictive (and successful)
• Leaders and team members must develop foresight and servant-leadership to ensure that they’re anticipatory and in service to each other’s outcomes. (It’s very common for any team, Agile or not, to become increasingly focused on their own outcomes)

Recommendations

1. Plan but don’t expect that an elaborate organizational redesign model, team structure and set of milestones will suffice for more than 2 or 3 Iterations (before teams realize they’re in a new form of box and that they’re under a different microscope)
2. Constantly solicit feedback AND direction from your teams.  Those closest to the work have the best insight into how to best perform it. Additional training and coaching may be needed, but tailor it to team feedback (versus leadership experience and preferences)
3. Allow outcomes to emerge and resist the temptation to tinker with or redesign your teams and programs in mid-flight. Continuous learning, continuous improvement and continuous delivery are emergent properties of an increasingly Agile organization (and are not formulaic, prescriptive or scheduled outcomes)
4. Remind yourself regularly that you’re working with people whose emotions, instincts and experiences you’re solely dependent on for successful outcomes. Agile is all about people (and not frameworks, tools or metrics)

Thanks for getting this far! All comments welcome.