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 🙂 ).
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.
Recent Comments