Introducing Agile in Government - part 1: Assessing current state

For the last 8 months I've been helping a development team in a government department improve their development capability. Part of this involved introducing various concepts normally found under the "Agile" and "Lean" umbrella terms. This blog post is the beginning of a series recounting my experiences during this work. I hope this is of use if you are introducing Agile in government teams.

Agile adoption is not one size fits all

We take a very pragmatic approach at Equinox IT and we absolutely don't believe in taking one purist Agile approach or methodology and applying it to all situations. All organisational contexts, capabilities, needs and challenges are different and so it follows the improvements required will also be different. So, my first challenge was to assess the current state of the development team.

Talking to everyone

Since I was coming in cold, I had no idea how the team currently worked, what the context was like in the organisation or what the challenges might be.

I started with interviewing all the team members. This gave me a reasonable picture of how they currently went about doing their work and it gave me a list of other people to talk to regarding how they interacted with the rest of the organisation.

I ended up talking to:

• Every team member
• Every team manager in the wider IT department
• Almost every senior manager
• Representatives of other teams that the team interacted with directly
• Almost every current stakeholder for the team.

The variety and breadth of opinions and views of the team gave me a very complete picture to work with. I found the most valuable were those members who were directly in the team's supply chain, i.e. consuming the team's outputs or providing inputs, and those that were dependent on the team, such as the business stakeholders.

Using a psychologist's approach of open questioning

Before the first interview I tried to put together a sensible set of questions I could ask everyone in order to form a coherent, measurable, objective view of the team. I discovered fairly quickly this wasn't really very sensible. Every organisational context is so different, and every team is so different, that one framework for assessing capability is inappropriate. Instead, I began to run every interview free form and the content was very dependent on the individual's role, work at the time and the people they interacted with.

In retrospect I imagine a lot of the same techniques I successfully use as a coach and mentor are also those used by councilors or psychologists. Open-ended questions are definitely the way to go.

Assessment findings

What I learnt from this assessment was that the team was not consistently viewed favourably by the rest of the IT department, the reason for which essentially boiled down to a combination of variability in the quality and reliability of their output. These were the main reasons the team often wasn't considered for significant development work and were therefore primarily undertaking support and developing point business solutions as needed instead.

Because of the perception of the team from the rest of the IT department, the team was nervous about external transparency of their work. It was also very difficult for them to assess their own productivity, quality or capability as this translated to poor visibility of work being done within the team. This resulted in a vicious cycle that made it very difficult for them to be able to correct the problem.

On the positive side, likely due to their situation and the characteristics of the individuals involved, the team itself communicated effectively, got on well and were very accommodating of each other.

The team had never introduced anything in the way of what traditional IT departments would call "due process". As such, they were actually in the habit of talking directly to their business stakeholders and being responsive to support needs rather than having too many documents in the form of contracts blocking the way. Interestingly, they were keen to introduce the typical traditional large requirements documents and sign-offs found in most IT departments, especially in government, because that's what they thought was expected of a competent software delivery team. I believe this would have been a death knell with respect to their interaction with the business so finding other ways of addressing this need would be something to look at further down the line.

Hopefully you've found this useful. To see what happened next, please check out the next posts in the series:

• Introducing Agile in Government - part 2: Implementing Kanban
• Introducing Agile in Government - part 3: Getting the Kanban board right

If you like this and want to see more then please hit "Like" on the post. I'd love to hear from you if you've had similar experiences or just want to talk about any of the content here. Please comment below to get in touch!

Ray Cooke is a Lean and Agile business transformation coach, based in Equinox IT’s Wellington, New Zealand office.