Wow, we are down to the last presentation of CAST 2017! These past two days have flown by.

The final session I chose to attend was Cathy Toth’s talk about her organization’s ten-year journey towards effective Agile practices.

color photo of Cathy Toth

Cathy Toth
Acato Information Management

Cathy described the day in 2007 when her executive sponsor said: “I’m a very demanding customer. I know what I want. I wanted it yesterday. And I reserve the right to change my mind.” Turns out that these were prophetic words, and it showed that their past ten years was not going to be an easy journey.

Relationships were key to the success of this group. Teams work well not just because they are smart or skilled, but because they trust each other. It was important to help make quality a central part of everyone’s reasoning and work reality. Because of this being a project with government involvement, there was a lot of pressure to make sure that everything was working, to some specification of working.
One change they felt was important was to step away from talking about “defects” or “bugs” and instead look at “issues”. It helped make for less confrontational language and allowed more people to communicate about issues. If programmers determined that an issue was not going to be fixed, they had to say why that was the case, in writing.
By 2013, Cathy says that they were practicing Agile at a release level, but they may not have been practicing it at a purely Scrum level all the time. They typically have three development sprints with a fourth sprint with a focus on testing and completion of release. Hey, it worked for them.
By 2014, they had to ramp up their custom solution to an Enterprise solution, and their mantra was “schedule is king”. Their team could not slip and that meant they had to rethink things like capacity planning and feature planning. That’s not to say that schedules didn’t slip, but it did mean that features that weren’t ready didn’t stop the entire train and adjustments had to be made. It also meant that QA Complete had to happen before deployment, and not coincide as closely. The first print focused on planning, the second sprint covered design and development, the third sprint had additional development and the fourth sprint focused on QA testing.
An additional area they knew they had to put emphasis was on tool support, and they realized that the tooling had to be applied where the bottleneck was, regardless o where that was. That meant they determined that there were a variety of testing steps they were performing that was overkill for the benefit they provided. That also meant that their tooling focused on the testing process and not so much on automation.
So here we are at today. The start point and the current point are night and day different, but those changes didn’t happen automatically, nor did they happen accidentally. There was a lot of deliberate focus and some growing pains to be sure, and it’s a nice reminder that Agile transformations are not necessarily easy or seamless, but often happen in fits and starts and the payoff may take years to see your goals achieved.