Good morning. We’re geared up for Day Two after an excellent night out on Broadway (i.e. Music City USA, Nash Vegas, whatever you want to call it, some great music to be heard).

We are excited for the new AST Board (Carol Brands, Kate Falanga, Maria Kedemo newly elected, Ilari Aegerter¬†and Eric Proegler re-elected, and Rob Sabourin and Justin Rohrman carrying over for another year… I think I got that right ūüôā ).

color photo of Mary Thirn presenting her talk at CAST 2017

Mary Thorn
Director of Agile Practices, Ipreo

Today’s keynote comes courtesy of¬†Mary Thorn, who is the¬†Director of Agile Practices at Ipreo. The key message¬†of her talk is the grow Agile practices in organizations that “can barely spell Agile and never had¬†invested in good testing”. This¬†is¬†a reality¬†in that¬†many teams¬†do not¬†invest in their¬†team members. We hope that they will¬†gain the¬†knowledge¬†to¬†do what they¬†need¬†or come in with¬†it¬†already in place. This is¬†unrealistic and¬†organizations¬†need¬†to¬†invest in their¬†people. Mary¬†talked about the¬†idea¬†of the¬†52-week boot camp. The goal was to¬†help develop¬†T shaped¬†people with a broad¬†set of skills. By¬†making a 52-week¬†boot camp, and¬†by¬†investing¬†in her team, Mary¬†said she was able to¬†keep 95% of her¬†team from¬†going to other¬†companies.

Another key part of the scaled Agile team is the idea that the whole team owns quality. Unit tests have to exist. Integration tests have to exist. The definition of done needs to be¬†shared among the¬†team. The¬†timeline¬†to¬†look at features¬†and bugs needs to¬†be realistic and¬†honest. Ultimately, it¬†doesn’t matter¬†if there are testing tasks or development¬†tasks, the team¬†is responsible for quality, and if¬†it¬†means that¬†someone on the team¬†may not be¬†the traditional¬†person to do that job, it doesn’t matter. Being effective¬†is¬†more¬†important than¬†observing a hierarchy.

There’s a phrase that gets used a lot called “Scrummerfall” and many of us have¬†been on Agile teams where this ended up being the operating environment. In short, it’s a mini¬†waterfall project¬†within¬†a sprint¬†timeline, and it is¬†highlighted¬†by¬†programmers¬†working on stories, throwing the completed¬†code to¬†the testers, and then the¬†game¬†of¬†feature ping pong happens. The sad fact is that, during the planning and during the structuring of the story, it’s common for the planning to happen, and then the programmer goes off to code, and then the tester gets to test several days later. Hence, Scrummerfall. Yeah, that’s annoying, but what can we do? Part of the option is to adapt the development environments so that testers can get in and start testing early. Pilot-Navigator pairing can be great, but it may not always be practical. Getting into the story kick off and describing/defining the testing areas can help, and getting a branch in sync with the development branch is also important, as it lets us test with them in real time as they develop the story. Granted, this may mean that we have fewer stories active at any given time, but it also means that we could do more stories overall. Scrummerfall happens with Agile transitions and it may be seen as a necessary transition aspect. It’s a common mistake, and frankly, it’s a good mistake, relatively speaking, because it shows an initial failure to adopt Agile. Why is this good? It’s good because we get to adapt and learn. Learning comes from failing, or at least more learning comes from failure. Scrummerfall helps to see how much work should be done, how much tension or areas exist where there is a struggle, and how we have chances to listen and to learn.

An approach as groups go through Agile transformations is to consider the “Start, Stop, Continue” model of review. What are the things we are doing that are negative and how do we stop doing them? What are some areas that we need/should start doing? What good things are we working on that we should continue doing?

Behavior Driven Development is an area that a lot of people talk a lot about, and have had a variety of experiences with, but there a learning curve exists and buy in is essential. developing that common language requires the entire team get involved and understand the language in a similar colloquial way. To be able to have a common vernacular between all teams helps to define the work, create the language rules, and also allows all members of the team to be able to write requirements, specs, docs, code, and tests in a shared way. Possible? Yes. Easy? Hardly.

Agile transformations are hard for any organization. For legacy and larger organizations, it’s learning a whole new language and transitioning everyone to speaking it. Be patient, follow through, work with the team, and determine where your skills are currently and where you want them/you need them to be. Invest in your teams. Grow your teams. Learn from your failures. Adapt. You will make it work, but it may take a lot more time and effort than you realize.