Transforming to Agile – Stairway to Heaven – Part the First

“There’s a lady who’s sure all that glitters is gold

And she’s buying a stairway to heaven”

If you read my first article you will have some background to this article (along with a number of side musings). My last post promised to delve a little more deeply into my experiences and observations around transforming from waterfall to Agile. This is that article.

One of the things that has crossed my mind more than once is, if agile transformation is the answer, what was the question? I’ve asked a number of people this and I’m not sure I’ve ever got a convincing answer. I’ve got a lot of “dunno”. I ask this question, “what problem are we solving”,  quite a bit when someone presents a solution I’ve not been involved in. It’s not my invention, I’m not the first to use it, but seriously, it creates some puzzled looks at times. Those are the times where you realise someone has probably developed a solution based on their needs, possibly solving something that is not a problem for anyone else, possibly creating new roadblocks for other people. As I write this the phrase “best practice” pops in to my head. Left field sarcasm?

My first observation, if you don’t understand the problems presented by your current development approach then you can’t know if changing will help. Understand the questions that Agile must answer before engaging in the first step of transformation. Spend some time finding out if Agile is even capable of giving the required answers.

I remember in a meeting, early in the transformation, mentioning that it was highly likely not everybody was up for the transformation. How did I know this? Reading up on others that had gone through the transformation, I’d been involved in other companies that had undergone significant change (although not involving agile), I’ve spent some time studying people – as part of my undergraduate learning as a teacher (a long time ago) and some other courses since, and of course just getting to understand the people I worked with. I distinctly remember an uncomfortable feeling coming over the meeting, some muttering, a weak attempt to acknowledge I’d said something, and then, moving on.

Observation number 2. There can be (more than likely will be) significant levels of resistance and denial. This can be a damaging force. The transformation is challenging, people actively resisting just encourage others to stick with old habits rather than developing new ones. Be prepared and get people prepared early. Make it as gentle and gradual as you can. Stage the rollout so you can embed lessons learned and use success stories to generate enthusiasm about the change. You won’t kill all resistance but you can manage (encourage) it down.

The Transformation 

“There’s a sign on the wall but she wants to be sure
‘Cause you know sometimes words have two meanings”.

Tremendous opportunities will be presented. I expect that this will be true regardless of the level of agile coaching your company invests in. Commit to learning about agile, scrum, testing in general (if you are not already investing in this). Upscale your own education. Just doing this will place you above many others who will be part of the journey but only as a passenger. You will create opportunities for yourself, don’t waste them.

Not everyone is going to be OK with the transformation or even with the notion of having to change to agile. Learn to live with this. Bring them along as much as you can, use all their strengths. If they don’t want to fully participate in the agile ceremonies, don’t force it. Accept what they give, over time, with some successes on the board, they may slowly change. Success is a powerful force. There might also be a bit of “background politics” noise. Ignore this, focus on your team and yourself. Focus on what you can control.

It’s All In Your Mindset – 

“Ooh, it makes me wonder,
Ooh, it really makes me wonder”

Having people sitting in the same location does not make them a team. Calling the team agile does not make them so. It’s not difficult to put people together in a scrum team and have them operate in silos. I’ve seen it happen. When people lack direction, are confused by the changes, feel stress because of change, they go back to what is comfortable, what they knew before. You need to ensure there is support for the team, people who can help the team find direction and start using agile practices. This doesn’t have to be an external coach, it can be someone with good previous exposure to, experience in, (in this case) scrum.

Many people who have worked in waterfall have had some real horrible experiences with change. The churn and overload requirements changes can create can border on overwhelming. There is a mindset change required here. Change is a good thing, welcome it. The teams need to realise that change is, or should be, far more controllable within an agile setting and it helps to prevent spending lots of effort on developing something that does not solve the clients problem . Learn to understand, as a team, what is valuable to the client and what is the most valuable thing you can do to help deliver that value.

“Team think” is an important part of the transition. Give people a complex problem and empower (expect) them to find solutions. They are not my words but they resonate with importance. This is such a different approach to the usual waterfall method of development. I’ve been in a number of situations where, as a team, a problem has been solved quickly and produced a high value solution that was the result of using all the experience and abilities in the team. A team is comprised of capable people with different skill sets, different strengths and weaknesses. This is powerful stuff, use it. Personally I’m a fan of the “3 Amigos” approach and encourage this in any team I work in.

I think it is important for people to understand that a person in a silo isn’t the point of failure, finger pointing has no place (it didn’t in a waterfall environment either). If a project fails, the team fails,. not a person in the team but the team. Everyone in the team must own the project, own the decision making, own the commitment to quality. I’m tired of being told “if everyone owns it no one owns it”. That’s garbage and old world thinking. If everyone owns it, is accountable for it, then everyone owns it. If that is not happening then work out why and address (inspect and adapt).

“And it’s whispered that soon, if we all call the tune,
Then the piper will lead us to reason.
And a new day will dawn for those who stand long,
And the forests will echo with laughter.”

I had intended to cover my thoughts on transformation in a single article, but, I’m not convinced that is a value proposition for my stakeholders. I’m not a fan of massively long articles so I want to avoid doing the same myself (although massively long is soooo context based I might not even be close to that point yet for many). To make things a little easier I’m going to add another article covering other aspects such as agile ceremonies and other processes.






Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: