Scaling Agile - How to Screw It Up
SAFe and other frameworks offers significant benefits for the teams that can make the change. But there are also many pitfalls, most of which come from the organization's past behaviors. Based on my experience in transformational efforts in large organizations, we explore why scaling frameworks are useful, ways that an organization can screw up their transformation, and how to avoid those problems.
Outline/Structure of the Experience Report
Brief introduction of SAFe (now at version 4.6), with a focus on "Essential SAFe" -- the least complex implementation. Exploration of its benefits over non-scaled Agile, and over Waterfall.
Brief survey of other scaling frameworks (e.g. DAD, LeSS, Nexus) and their respective unique qualities and benefits
Introduction of four key ways to screw up a transformation effort:
- (Lack of) training and coaching
- Cultural inertia
- Environment and tooling
- Cheating the process
I then explore each -- how the "screw up" happens, its effect, and how to avoid them.
In the "Slides" link below, is a link to a deck I used for a similar presentation a couple of years ago. For this conference, I would cover other frameworks than just SAFe, and update the experience section (how to screw it up) to include my latest adventures.
Attendees interested in transforming their organizations toward a SAFe foundation -- or any scaled agile framework -- will learn danger signs, blockers, and ways to mitigate those problems.
Executives, Coaches, Transformation Leaders
Prerequisites for Attendees
Some familiarity with SAFe or other scaling framework helpful, but not required.
Experience in large development organizations also helpful, but not required.
schedule Submitted 2 weeks ago
People who liked this proposal, also liked:
Elijah Biggs - Team Culture and Revisiting Social Contracts Early and OftenElijah BiggsAgile ConsultantIBM
schedule 3 weeks agoSold Out!
Elevator Pitch: Change is inevitable – let’s exploit it. For Agile/team-based engagements, people learn about their preferred ways of working through a variety of changes: time, team structure, aptitude, experience, and introspection. Many teams use a social contract as an artifact to document a desired set of values, behaviors, and social norms at a project kickoff; but often forget to refine and modernize their social contract through time. Join me to discuss the elements of creating, revisiting, and revising social contracts and the value they provide individuals on a team.
Abstract: An Agile culture demands a high degree of collaboration, trust between individuals, and an electric focus on business objectives. Building this culture, unlike adopting a process or a tool, requires social engineering between people with unique experiences and interests. Teams can begin to carve out a team’s desired and agreed-upon characteristics, everything from meeting expectations to methods of communication, through their social contract. But what happens when things begin to change? During this session, we will discuss the relevance of a social contract to an Agile team, why to make this artifact a living document, and how to exploit it as a platform for continuous innovation and improvement.
I selected this presentation topic based on the research conducted and lessons learned on two of my government contract teams. The teams and contract frameworks were similar: both had one teaming partner, COTS integration and IT support services, same development environments, similar mission areas, good relationships with end customer. However; one of these teams experienced a level of attrition that was 6x higher than the other.
I investigated this churn by interviewing offboarded personnel on the high turnover team and using the five whys technique to arrive at a few root causes: belongingness, growth, and recognition. Interestingly enough, the team who experienced the high turnover was the same team who didn’t use a social contract. It had been created in 2017 and sat untouched since. Team members who joined later than the onset on the project didn’t know about its existence or contents.
Had there been enough time remaining before the period of performance end, I would have implemented the following set of changes: conduct a team building exercise for the current team to step outside of their roles and engage in a group challenge, construct a social contract after the team building exercise, revisit the social contract during retrospective sessions, and revise the social contract as needed through the duration of the contract. Putting the social contract at the foundation and forefront of the team enables a team to course correct through changes, discuss taboo elements of the engagement, and document their best practices and lessons learned regarding the team’s social inner-workings.
Although I was unable to implement these changes, I want to share my findings and perspective with the group. A social contract is a valuable and important tool to build and maintain team relationships. More importantly, it creates an intentional time for people to talk about what is and isn’t working on a team level. While this greatly impacts the delivery, it can go unnoticed when the attention is on the project and not the people executing the project.