Chad Gabriel

Working in the IT department of a 125-year-old industrial manufacturing company was both a blessing and a curse. There are a lot of “old-school” mentalities that can get in the way of how we choose to get better. Our owner once referred to this as “institutional inertia”. It’s hard to change the direction of a large moving object, let alone stopping it altogether. The company was one whose culture was centered around continuous improvement. It was based heavily on the Toyota Production System and Lean. For those of you not familiar with Lean, it is a Japanese philosophy that is rooted in eliminating waste in whatever form it comes in. Lean is about establishing processes with strict standard work instructions that illustrate, step-by-step, how to make something or how to complete a set of tasks so that opportunities can be discovered and improved upon… forever. In a culture like this, the phrase “best practice” is frowned upon because this would imply that we’re doing it the best way and are done improving it. As I dug deeper into how we could improve the traditional waterfall design mentality we’d inherited as a software engineering team, I discovered Agile and became very curious about how it might fit within our culture.

It didn’t take long to figure out why Agile, also known as Scrum, made sense for us. After all, it has become synonymous with Lean software development. We used to spend days designing our websites and applications using a four-phase design, build, test, implement planning framework. We’d get sign-off from the area requesting the work and off we’d go. It could sometimes be months before the requestors would be involved and we’d sometimes hear funny comments like “it’s exactly what I asked for, but not what I need”. Why? Because the solution wasn’t collaboratively created as it would be in Scrum. The metaphor I like to use when describing Scrum is that it’s like slapping a huge clump of clay on the table and molding it together to create a solution that everyone loves.

Here are some of the things I love most about Agile:

• It’s collaborative – everyone is involved including the business product owner, sponsors, developers, designers, ScrumMasters, users, etc. Daily stand-ups and an appointed ScrumMaster provide ample communication and help the team gel.
• It’s iterative – typical iteration phases, called sprints, last two weeks. Every two weeks you get feedback from all parties and get to re-calibrate where necessary
• It’s organized – features/stories are clearly written, prioritized, and agreed upon by all parties
• It’s quantifiable – as an engineering leader you’ll learn about the velocity of your team and the individuals on it
• It’s scalable – you can use Agile philosophies to manage any type of project and you can scale it from one small team to several teams working on a variety of functional areas
• It’s alive and well – agile is widely adopted and has a huge supporting community of practitioners. You can even get certified like I did back in the day at places like the ScrumAlliance. Getting help when you need it is easy peasy.

The business adopted Agile for our application development efforts and continues to use it to this day. On-time project completion reached well over 94% for projects run using the Agile framework and the satisfaction rate the business gave our IT department skyrocketed after being stuck at sub-par for several years. For a great one-page overview of how Agile works, check out this illustration called “Scrum Framework at a Glance” by the ScrumAlliance.