The seeds of successful Agile change

The seeds of successful Agile change

on Jul 21, 15 • by Christine Bottagaro • with 2 Comments

Change is inevitable in the workplace, yet, there’s no clear-cut answer as to how people react to change. Read on to learn some key steps to help grow your chances for successful change...

Home » Agile Development » The seeds of successful Agile change

(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.

Learn more:
• 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

Related Posts

2 Responses to The seeds of successful Agile change

  1. Roy Morien says:

    I went to the supermarket last Saturday. I planned my visit. I spent time thinking about what we needed to buy, and we made a shopping list. I researched the marketplace by reading the advertising published by the supermarket, so i could buy the ‘specials’. I planned my route to the supermarket (not a huge problem as it was already very familiar to me). I knew my car had enough fuel and air in the tires, so my method transport was planned and ready. I left home at about the time planned, and I planned to return home by a certain time to watch the football match on TV.
    During my planned driving I observed my surroundings. I collaborated with other drivers on the road. I carefully watched for problems and for traffic signs and lights. On arrival at the supermarket I parked my car as planned, but a bit further from the main entrance than I had intended. In the supermarket I went through my list of necessary groceries. I did purchase a different brand than intended on one item because it was cheaper. I couldn’t find a couple of items, so I asked someone. One item was out of stock so I purchased another, similar one. I noted cooked chickens were on sale at a good price, so I bought two, even though chickens were not on my shopping list. Unfortunately, it took longer than I had planned, especially at the checkout, and then there had been an accident on the way home and I had to detour, so I was late back home and my football match had already started. But that didn’t matter because my son had started recording it when he realised I would not be home on time.

    So … I was being very agile, wasn’t I? I planned, I collaborated, I communicated, I modified and adapted my plan as necessary, according to circumstances in which I found myself. I adapted and overcame! I took opportunities to improve on my plan by carefully evaluating opportunities not foreseen, and overcoming risks in circumstances beyond my control, I welcomed change, which contributed to the success of my project (my wife was very happy with the cooked chickens, although we hadn’t factored that into the original plan).

    So why do we have such a problem in adopting an agile approach to those other activities that people who are systems developers also carry out on a regular basis? Normal people normally behave in this way in any purposeful activity that they carry out. Nobody in their right mind would just suddenly decide to jump in the car and zip off to the supermarket just in case they might need to buy something there. Nobody, that is, who expects that activity to have a useful and successful result. Agile is no ad hocery!

    • Great Agile story using an everyday activity. Perhaps some of the consternation caused by Agile is thinking that it is so vastly different from what we already do. If we apply the logic and consideration we apply to these tasks, it’s a short leap. (Speaking of leaps… my father used to volunteer a store run at the drop of a hat. After joining him once I realized it was so he could play the store’s Frogger game, rather than proactive procurement. No doubt his user story would have different acceptance criteria.)

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Scroll to top