Agile and software development training

Why We Do It

Our motto is "Success Through Alignment", because without alignment, no team, not even a team of so called“ninja”engineers will succeed. The title of Jeff Sutherland’s book “Scrum Twice the work in half time” gives all the explanation we need for why alignment is important. Scrum is not about getting people to work harder, or longer. Scrum is not about giving people new skills or even development tools to deliver work faster. Rather it is about how to organize a group of people such that they can get the job done. Methodology is how we agree to work together to get things done and it has real economic influence.

When we use the term “methodology” we are not talking about bureaucratic prescription of practices, roles and artifacts and then forcing everyone adapt their work practices to the methodology. We are not talking about heavy documentation driven processes and stage gates as seen in traditional methodologies. And we are certainly not talking about the puritanical enforcement of practices and narrow focus as often seen in so called agile methodologies. Rather we are talking about creating the shared clear understanding necessary for people to effectively work together and create value. We are talking about people knowing what they need to work on, who they need to work with, and how to get the job done. Most importantly we are talking about people taking ownership of their methodology and not forced to abdicate that responsibility to some obscure “center of excellence”.

Of course most sane practitioners are generally not interested in methodology because they just do not see how methodology is useful in helping them get the job done. They just want to get down to what they do best, working on cool projects with cool tools, languages and systems. As one of our founders says

“Working on cool projects with cool tools, languages and systems is exactly why I got into this field almost 35 years ago. Some of my best work experiences are from mastering the technology to create digital switches and railway signalling systems. It’s what got my blood pumping, it’s what got me up in the morning…working with great colleagues, learning new things, and creating cool stuff. Yet for the last 15 years I have built my career around understanding, developing, deploying, and evolving software methodologies. So why did I start devoting so much energy to a topic that makes me less popular than a project manager at nerd social gatherings?”

Why this change of attitude – why did we cross over to the “Dark Side” - because many of us began to understand how important methodology is to project success. When we compared more successful and more enjoyable projects to the ones we slogged through, and the projects that were outright disasters, the differentiator was not technical engineering talent, rather it was how well we worked together and how quickly we could learn and adapt. It didn’t matter if we assembled a team of superstars, if they could not work together to get the job done, then the job didn’t get done.

An interesting case study from my own personal experience, helps illustrate this point. I was part of a team parachuted in to a major industrial manufacturer to help recover a failing project. They were at the tail end of a long waterfall project and for a lack of better words, flailing badly. Defect opening rates were way higher than defect closing rates. People would work long hours on a critical defect, only to be interrupted and dragged off to a new higher priority crisis. The project deadline was looming and this was no mere presumed date on the calendar, failure to deliver by the deadline date, would mean total failure.

The project was shut down for two weeks to introduce a different methodology. During those two weeks the teams were re-organized and trained together. Then in a mass “release planning” event, work was prioritized and re-planned. With the restart of the project, people’s attitude changed from “we are all doomed” to “we may have a fighting chance”. The project was delivered. I will not claim any magic methodological silver bullet or personal brilliance for this. A lot of people worked massively hard and long hours to deliver. However, what I will claim is changing how people worked together – their methodology – enabled people to go from flailing to delivering.

This is why methodology matters, why we need to think about it, and this is why we create the products and services that we offer.