(Read part one of this Agile series here.)
Ah, the perennial Agile question: How do you get people to embrace change? (With the implied, “rather than resist it.”) It’s actually a great topic, and while often attached to change associated with Agile, the question applies to any new or uncharted territory.
The difficult part of change is people-change. Anything that touches personal territories, roles, and expectations becomes a minefield – and the single biggest risk to success.
The reason it’s difficult, is because it is. And takes time. But there are a few steps you can take to ease the real (or perceived) pressure of change.
Collaborate. A key tenet of Agile is to work across teams in an accepting, inclusive environment. So even the decision to apply Agile to which project and what teams requires an inclusive approach. Are the teams part of the discussion? Are they consulted for their expertise? Teams should be part of the identification and design process.
Define. Clearly outline what is expected of the teams, and each team member. Unclear or unknown expectations lead to frustration, and ultimately, longer cycle times. Part of this is also defining what Agile looks like in your organization. The Agile discipline (yes, I used the “D” word) involves finding the right ceremonies and timelines for your organization. Sprint (or iteration) length, identifying stakeholders, backlog grooming, and user story creation can all take on the unique personality that meets organizational culture, team, and project needs. Now, I’m not advocating that each team develop these independently but rather the application should be defined for the broader organization. And, make sure team members are conversant in Agile. Invest the time in internal or external training to accelerate not only learning, but buy-in. The more I know, the more I can engage.
Test. One of the great attributes Agile brings is the ability to experiment, apply, and learn throughout development (and other disciplines). Develop and test the teams’ hypotheses on sprint length, team size, meeting cadence, etc. and then reveal these findings during retrospectives and adapt for the next iteration. “We believe a three-week sprint allows us to create an MVP, including required testing.” Test within the teams too, rotating the ScrumMaster role is an interesting experiment, and draws everyone into flexing their roles a bit.
Measure. Include very specific acceptance criteria in the definition of done, including the test hypotheses. If we set out to measure our team velocity, did we? Have we established baselines for this? Are we better at creating and estimating our user stories? Did all team members feel their work was represented in the iteration tasks? Does everyone agree these represent what we can call complete?
See and share success. As my friend and Agile guru Ronica Roth says, “The single biggest factor in getting everyone on board is to show them early successes. With this, it might be tempting to pick a simple, small project as a starting place. But that can undermine the importance of the effort, and lead to the conclusion that Agile is only appropriate for lighter-weight projects.” Instead, with the teams, identify a key project that’s well suited for Agile. Those are projects with aggressive timelines, some degree of complexity, and are new. Simple, non-urgent existing projects need not apply.
Find and share those early successes. Delivering the demo to the stakeholder team. Feedback on the process. Team engagement. Learnings. The plus column from the retrospective. Any small or large win deserves exposure. Share those in your team meetings, stakeholder discussions, ALM tool, intranet sites, blog posts, etc.
Once the expectations are well understood and teams can see their path to success, that very success drives buy-in and additional engagement. Naysayers and fence-sitters become evangelists, and change can be what we accept and embrace.
• Change your team’s security mindset by watching this webinar: Create Agile confidence for better application security
• Change your software testing agility by reading this white paper: Static code analysis in an Agile world