The Agile Practice Guide – A Personal Journey

Agile Practice Guide
Betsy Kauffman is one of the seven authors of the Agile Practice Guide (above).

When the Agile Practice Guide writing team convened to begin our endeavor, we spent quite a bit of time discussing our target customer. We landed on our primary customer being project practitioners who support agile teams, who may be in the midst of an organizational agile transformation, or who are just curious and want a better understanding. Being a part of this team and writing this guide are near and dear to my heart because several years ago, I was our target customer. Here is my story…

I jumped directly from college into a project management role and worked my way through several plan-driven, waterfall projects as a certified Project Management Professional (PMP). I was really good at leading teams and delivering according to “the plan,” but it didn’t really feel right. I was always a bit untraditional—I just wanted to focus on pulling the teams together to do the “real” work instead of spending time on documentation, audits and stage gates. (Some of you may be shaking your heads and thinking about confessions of a bad project manager while others may be excited and can relate.)

Fortunately, someone noticed my agile inclinations and asked if I wanted to go to Scrum Master training and then lead a couple of scrum teams. Sure…why not? I was excited about the opportunity to learn something new. (FYI-I did not have a clue what I was signing up for!)

That first training was eye opening. It finally articulated and formalized several of my beliefs, but also challenged my definition of success. The concepts were easy to understand and they made sense, but applying them in my work with cross-functional, self-organizing teams was difficult. I really struggled.

The tools and techniques I used as a PM were not so transferable to the Scrum Master role. I had to “untrain” my brain and learn new behaviors. I had to change the way I supported my teams and redefine how I delivered value to my organization. The biggest challenge of all—Scrum Master training invited me to get comfortable with failure—to allow my teams to fail so they could learn and improve. This was extremely difficult for me because on “my watch,” as a PM, there was no room for failure, personally or within my teams. Sound familiar?

I needed to embrace the fact that I did not “own” the project. Instead, ownership and accountability shifted to the team. My new role was to facilitate and support the team as a servant leader, no longer as a manager. This took immense pressure off my shoulders, which had been unconsciously weighing me down as a project manager.

After several years of learning, failing, working, training, being coached and coaching others, I realize it was all part of the journey. I needed to go through it to evolve both personally and professionally.

The Agile Practice Guide offers the combined knowledge and wisdom of seven agile practitioners. Our motley crew of writers representing both Agile Alliance and PMI, laughed, cried, argued and at times wanted to kill each other in passionate support of you, our target customer.

As the guide launches this week, I’m left with deep respect for my fellow authors. The amount of collaboration between these two groups has been amazing. Several of us will be at upcoming regional, national and international conferences. Please approach us—we enjoy sharing our experience and welcome your feedback.

AATC 2016: Three Takeaways from Uncle Bob – Technical Agility

“Uncle Bob” Martin, co-founder of spoke at the Agile Alliance Technical Conference in Raleigh, NC on April 8. Informed by 40+ years of technical experience, his perspective on the past, present and future of our profession was obviously enlightening. Here’s what I left the conference thinking about:

Do developers need to be less “bean bag and foosball” and more “slide rule and graph paper”? Uncle Bob made a strong case for technical discipline and professional standards similar to the fields of science and engineering. He characterizes the “waterfall period” as a hazardous mix of risky methodology, a staggering increase in computing equipment, and droves of young, undisciplined developers. This combination of factors explains why the waterfall period significantly lacked the number of advancements of technology that the early period did and led to many massive failures and the complex “legacy” systems that many current practitioners complain about today.

Are developers sitting on the sidelines? Agile, according to Uncle Bob, is currently being led by project managers who are using agile principles to drive process improvements with various frameworks including Scrum. While these process improvements are a necessary step in agile transformation, they do not address technical agility. When technologists stand on the sidelines, no one advocates for technical quality and solutions suffer. Developers need to get in the game! (The leadership game not foosball!) This need for technical leadership is driving the Software Craftsmanship and DevOps movements, but we don’t want the pendulum to swing too far in the other direction either…

How can we reunite Technology and Process? When focus swings back and forth between technology and process, organizations and customers lose. Bob’s presentation reinvigorated my belief that Technology and Process must march forward hand-in-hand if we are to advance Agile principles and erase the technical debt created by generations of waterfall. This belief inspired Agile Pi to transform organizations using a balanced approach that strengthens process AND technology.