Let the Values Guide Your Agile Transformation

No organisation can control their competitors or customers; we need to remember this when we’re coaching people new to agile. Organisations can control what they produce and how they go about producing it. By looking at the values in the agile manifesto, we can see the lessons that need to be learned.

Individuals and interactions over processes and tools

When we hire new people, we choose the individuals who will make up our organisational culture. This is far more important to moving an organisation towards being more agile than changing project management to product management and raising Jira tickets.

I was interviewing for a senior developer for an organisation that had transformed to completely outsourced development and now wanted to transform to in-house agile development. When I asked the candidate what reading material they would recommend to a more junior developer who came to them for guidance about agile development, they informed me they hadn’t read any books, watched any videos, or looked at any websites. Not even the agile manifesto. Although this person was excellent at the obscure programming language required, they didn’t know anything about agile.

When hiring new people, the consideration must be about all of the organisational needs, not just the team’s. The choice here was to hire for the tools that were used rather than the interactions that were needed.

Working software over comprehensive documentation

The focus of the leaders in an organisation will have the greatest impact on what our developers choose to work on, and, therefore, what they output. If we want our developers to create great products that our customers love, then our leaders need to focus their attention on the quality of the software that is being written.

I was chatting with the development manager of a team who were struggling to understand the requirements they had been given. We were talking about the different strategies the team could take to start producing something the business could test so we could incorporate feedback into our process.

The manager casually explained that the team needed to start with TDD. Naturally, this was music to my ears. Making time to design for quality from the start is a great way to create products that people love. We went our separate ways, confident we were excited about the same thing.

A couple of days later, one of the developers came to me to ask how writing a Technical Design Document fits in with the descriptions of agile I had given the team. It took me longer than it should have, and my heart sank when I realised that this was the TDD the manager wanted the team to focus on. The team had a lot of work to do, and now their manager wanted them to stop working on creating something the business could use and start writing about what the final product will be able to do.

I’m sure some in the organisation would be excited to see what was imagined as an end product, but I knew plenty of people wanted to start using the most basic of features to make their jobs easier and faster. Our leaders need to focus on what delivers the most value to the rest of the organisation, so the developers can create what is really needed.

Customer collaboration over contract negotiation

I find it of more worth thinking about this value in an abstract way. Who are your key stakeholders, and how do you interact with them? If you only see them at sprint review (and hopefully not less!) and then do a show and tell without receiving feedback, then you’re in a transactional relationship with them that may as well be contractual. The best way to make the products that your users want and need is to talk with about how it is they currently work, how they would like to work, and what you can do to enable that change.

Our team was getting ready for a meeting with our key stakeholders to find out what they needed customising in our core software package. The developers wanted to acquire a scope of works from them and then leave them alone until we were ready to give them what they asked for.

I suggested that we run a user story mapping session instead, so we could understand the process used at the moment, how that touched the software we were working with, and where we could improve it. Although the developers thought they understood how our stakeholders worked, we were shocked by many of the realities we were ignorant of.

It turned out data were being outputted from the system and then manipulated within an excel book before being reimported into the system. There was no audit trail for this. Everyone had their own copy of the excel book, which needed to be updated daily. The hope of their manager was that the excel books remained consistent and whole between everyone. We asked our stakeholders which were their greatest pain points, and again the developers were surprised by how easy these were to fix and how great an impact it would have. It certainly wasn’t the development work they thought they were going to agree upon going into the workshop.

When the developers and the stakeholders stopped thinking of their relationship as transactional and started to work with each other in a mutually beneficial way, they could create great products that were not just wanted but really needed.

Responding to change over following a plan

Sometimes it is the process that needs to change to deliver what is required. It’s not always the developers or the business that needs to respond to the change in front of them, and it stands us agilists in good stead if we remember that our plans can be fallible too.

Before running my first workshop with a new team, I sat down with one of the managers and asked the standard questions I use to explore what is required from a meeting. They told me there was a vision in place, and that the team needed to come up with a potential candidate for a proof of concept. We agreed on what would be brought into the workshop, who would be attending, and what we wanted to get out by the end. I designed a plan of activities and how they would flow together to achieve the desired outcomes and output.

While designing the workshop, I decided to start by asking everyone to write down what they wanted to achieve from the session. I hadn’t met most of the people in the room, so I didn’t have a good feel for how people felt about this new project, the dynamics between the different disciplines, or how aligned the group was. When all the answers were read out, 85% were asking for a vision. All of a sudden, I had to throw my plan out and work on the fly.

The goals that had originally been set out for me couldn’t be reached because we didn’t have a shared understanding in the room of what we were doing, why we were doing it, or who we were doing it for. Thankfully I had my computer with me, so I was able to quickly look up some vision board formats and guide the group through populating it. There were moments when everyone in the room appeared to be pulling in different directions and I had to dive into my mental catalogue of facilitation techniques to help them have conversations that brought them together rather than tearing them apart.

If I hadn’t responded to the change in requirements then I would have lost the room. Without a vision, many of the questions that I was planning to ask them would have been near impossible to answer, and certainly wouldn’t have driven any real insight into the future of the project. By recognising that the plan is no longer valid, I managed to help them produce something valuable.

Change is always difficult and scary. Having the courage and commitment to pursue a different path to the one you planned can often lead to greater riches than those we could imagine.

What about the principles?

Given how relevant these values are 20 years later, I think it’s safe to say that we can expect the same validity from the principles. I would love to hear any stories you have that illustrate one of the principles guiding you through your agile transformation.