Is Agile the New "Normal"?

I was listening to the Agile for Humans podcast this week featuring Steve Denning, and he spoke about a topic that I’ve either heard or read about several times over the last several months. In all cases, it has been some form of “Is Agile Dead?” or “Is it time for the Agile Manifesto 2.0?”. It kind of triggered this idea in my head which is, has Agile become the new normal?

Humans go through change continually. What ultimately happens is that at first, the change makes you uncomfortable, but with time you adapt to that change and it slowly becomes comfortable, or the new normal (think weight lifting, a new diet, starting a running program, learning a new skill, etc.). Normal isn’t by itself a bad thing. However, throughout the history of mankind, we have a track record of revolutionary new changes that over time become distorted.

                        

In his book “1984”, George Orwell tells the story of a group of farm animals who are fed up with the farmers living off their hard work. At first, they overthrow the humans and begin to celebrate their new found freedom and all is great! Eventually, though, the pigs move into the house and slowly begin making small changes which the animals reluctantly accept. Before you know it the pigs have become indistinguishable from the humans they once fought against, and the rest of the farm animals fight to drive the pigs off. 

In colonial America, the colonists were fed up with the British and had a slogan of “No Taxation without Representation”. Eventually, in the American Revolution, they overthrew the British government and formed what we now know as the United States of America. Yet a little over 200 years later, most Americans do not feel the politicians in Washington have their best interest at heart and instead act in their own best interests. Those in Washington seem all for passing policies that help them stay career politicians that live lavish lifestyles compared to the average American. Both sides of the aisle advertise changing Washington for the average American, but rarely do we see that.

Now Agile is obviously not a political upheaval, but there are some parallel storylines. A group of individuals that were fed up with the waterfall way of doing things got together and said, “There must be a better way of doing things.” They wrote the Agile Manifesto and frameworks such as Scrum, XP, Kanban, etc. started to form. Software was developed more quickly, developers had more fun building the software, and everything seemed to be great in the world of Software Development. However, somewhere along the line, we once again started polluting Agile and in some cases, it became about checking things off a checklist to say we are Agile. It became “Doing Agile” instead of “Being Agile”.

I’m fortunate in that I have never worked in a formal Waterfall environment, and for the most part, the company I work for is pretty good at Agile (some teams better than others). However, I have still witnessed projects that although described and worked in the name of Agile, sure do resemble the waterfall projects of old. I will often hear comments from developers and business people alike made in the name of Agile, but that show they don’t seem to truly understand Agile. It’s as if they have taken the Agile buzz words and then started using them to describe old behaviors; as if calling the behavior by a new name will change it and make it more Agile and less Waterfall.

If you look up the definition of Agile, you’ll find something along the lines of “able to move quickly or easily.” The whole point of being able to move quickly or easily though is that it allows you to put software in front of a customer sooner, and LEARN from it. The key to doing Agile is that you should be continually trying something, inspecting it, and learning from it.

We hire knowledge workers [Software Engineers] that make salaries well above the national average, but in many cases, we don’t let them actually do what they are hired to do. We ask them to do more and more in terms of delivering new features, give them very little time to really think through a creative solution and learn from the software they are building, and we do this all in the name of Agile.

If you really want to be an Agile organization instead of just being an organization that does Agile, throw out all the checklists and buzz words and focus on becoming an organization that experiments and learns. Provide a real problem from your customers and allow your knowledge workers time to really think about the potential solutions and then iterate on those solutions. Try something, show it to your customer, learn from it, rinse and repeat.

So what do you think, has Agile become the new normal?

Be Agile, Don’t Do Agile

About 9 months ago, I transitioned out of IT Recruiting and into my current role as an Agile Project Manager. I was full of textbook knowledge and eager to start on my Agile journey, but mostly still uncertain of exactly what to expect or what the job entailed.

The past 9 months have flown by as I day by day begin to fully understand my job; mostly through trying things out, messing up, and hopefully learning from my mistakes. One thing I can tell you for certain is that at a minimum, the dev teams I support see that I try on a daily basis to help them out and to drive us towards continual improvement. I refuse to be the APM that merely facilitates meetings and enforces the “Agile process”; I want to be seen as a valuable member of the team, and what that requires to be seen as valuable means two different things to the two teams I support.

So back to the point of this topic. When I started out, I kind of assumed there was a “right way to do Agile” and the lens that I viewed my teams through was basically, is that the proper way to do things or are we doing it wrong? Nine months in and I can now tell you that it’s the wrong way to approach coaching an Agile team.

Through my self-studies (I’m prepping for the PMI-ACP and typically have 2-3 books I'm reading all at the same time) and even presentations from Agile Day Atlanta, I’m learning that it’s really more important to “Be Agile” rather than “Doing Agile”. What do I mean by that? I’m glad you asked. It's about developing an Agile Mindset rather than following a specific set of processes.

I started out wanting to make sure we were “Doing Agile” and following all of the ceremonies correctly and doing things a certain prescribed way. Certainly if we followed the recipe we would build better software right? Something funny happened though; it didn’t always work out that way and the team didn’t always respond to textbook Agile.

I attended Agile Day Atlanta this past Friday, and our keynote speaker was Doc Norton. He gave his talk on the “Experimentation Mindset” and the more I’ve learned about Agile, I’m starting to realize that it really comes down to two things: Experimentation & Learnings.

Why do we retro? To learn from our prior successes and failures. If your team hates to retro, it means one of two things. Either your ScrumMaster does a horrible job of facilitating meaningful discussions, or the team is approaching it with the wrong mindset and does not really come prepared to observe and learn.

Why do we work in iterations? To run quick experiments that we can put in front of users and learn from. Jeff Patton’s book on User Story Mapping had a great passage, which to summarize basically says, for every story you want in the backlog you should write three stories. The first has the story, the second says fix the first card, and the third says fix the second card. His point is that we should be going through iterative learning cycles and we will rarely build the feature “right” the first time. If you aren’t following this cycle, you likely aren’t learning from the software you build.

User Story Mapping is actually what kind of inspired this topic. As I’ve worked to coach my teams through writing better stories, we’ve struggled with trying to do it “the right way”. We’ve basically taken the old school documentation process from waterfall and just tried to repeat it with our Agile process. What I’ve learned from this is that I need to teach this in a way that isn’t so prescriptive, but rather focuses on the mindset of telling stories and gets the whole team to a shared understanding of WHAT we’re building. What gets written on the card is largely irrelevant after that as long as it helps trigger our memories to the meaningful conversations we are having around the card.

So what does Agile mean to me in my day to day for coaching Agile teams? It’s becoming more about fostering a safe environment where we are free to experiment and learn. I think if those two things happen, then we can say we are “Being Agile”

What do you think? Please leave any questions or comments you might have as this is a work in progress for me and I fully expect to get some things wrong and hopefully learn as I go along!