Course correction: What Agile really means

How practicing agile, scrum, and short sprints helps organizations keep on track and make course corrections.

Agile does not necessarily mean flexible

For a lot of people, when they say and hear the word Agile, they think it simple means being flexible.  We are an “agile” company, they say … “we are flexible.”  But, for most agile purists and true agile development professionals who practice scrum and sprints on a daily basis, we take issue with how lightly and easily that “agile” word is tossed around.

I’m not sure if you are old enough to remember the toy and cartoon character Gumby created in the 1950s and put into motion in the 1960s with reruns through the 1970s.

Gumby is a green clay humanoid character created and modeled by Art Clokey. Gumby has been the subject of a 233-episode series of American television as well as a feature-length film and other media. Since the original series’ run, he has become well known as an example of stop motion clay animation and an influential cultural icon, spawning many tributes and parodies, including a video game and toys.

Art Clokey created Gumby in the early 1950s after finishing film school at University of Southern California. Gumby was inspired by a suggestion from Clokey’s wife Ruth that he base his character on the Gingerbread man. Gumby was green because it was Clokey’s favorite color. Gumby’s legs and feet were made wide for pragmatic reasons: they ensured the clay character would stand up during stop-motion filming. The famous slanted shape of Gumby’s head was based on the hair style of Clokey’s father Charles Farrington in an old photograph.

So many people associate “agile” with “flexible” that there is actually something called a Gumby Framework, a responsive CSS framework powered by Sass.  But, that CSS framework has nothing to do with Agile, Scrum, or Sprint other than the fact that it can be used to accelerate development over shorter periods of time.

Agile’s strength is its short, well-defined sprints

On a recent sprint, we had decided to use WordPress as the tool for managing content and user profiles for a particular app we are building (SEO Quotient is an SEO analysis tool that helps website owners understand why their competitor’s websites rank higher than theirs for the same keyword phrase).

We have been practicing one week sprints where on Monday (Day one of the sprint), the product owner (me) explains to the scrum team what user stories are important to me and why.  On the second half of the two-hour sprint planning session, the team discusses how it will be implemented, breaks the story down into tasks, and estimates how long it will take to satisfy the requirements and deliver the user stories.

Then, at one particular sprint planning meeting…

I actually do love WordPress, but when it is the right tool!

While the product owner often steps out during the second half of the sprint planning meeting so the developers can discuss internally and at a technical level how they plan to accomplish something, I decided to stay in the room and participate.  During that meeting, we were discussing which tool to use for the profile management system.  It bothered me, somewhat, that we chose WordPress as the tool for managing the profiles.  While I am a huge fan of WordPress, I also am a huge fan of using the right tool for the job.  What I want to avoid is the “Hammer Principle” where a man with a hammer in his hands looks at every problem as a nail.

My concern with using WordPress to manage the profiles were that; (1) I wasn’t quite sure how efficiently WordPress would scale, (2) I thought that WordPress has a too basic and simplistic profile management system, and (3) most of the tool is built using a Python / Django framework and the profile came into use within the tool … so why leave Python / Django and jump out to WordPress when you are in the middle of something?  It just didn’t make sense to me.  But, since a scrum team is supposed to be non-hierarchical and I haven’t programmed since college, I went with the flow.

Well, by Tuesday night of that sprint (2 days into the 5 day sprint), the team had realized that they had been spending way more time than anticipated struggling with WordPress to do what they wanted to do.  That is when I decided that the scrum team was no longer a democracy and I had to interject my leadership and opinion.  I told them that my instinct was not to use WordPress but instead to stick with the Python / Django framework that we were already using to build the tool and we should immediately switch over so we don’t waste more time spinning our wheels.  That night, the team debated internally and made the decision to agree to the switch.

On Wednesday morning, the senior developer came in a couple hours early and did a lot of the heavy lifting to switch over and by 9 am most of the team was up and running on the new framework.  By about 7 pm on Wednesday (12 hours into the day), when I decided to call it quits for the day, I asked the lead developer how things were going with the switch and he said that the team made more progress in one day using the Python / Django framework than they have in two weeks.

Turns out that it was an excellent decision to make that switch even though it carried some risks.  But, the point here is that by practicing Agile and Scrum and scheduling one week sprints where we can clearly gauge our progress day by day, it was an easy call to make for the switch in technologies and it agile gave us the freedom and flexibility to pivot and make a crucial course correction that allowed us to get back on track and deliver our goals by the end of the week.

Had we been practicing web development the old fashioned way, with stovepipe developers working on stovepipe functionality, not working as a tightly knit team, not paying close attention to clear goals with measurable progress, and having a much longer development cycle; it might have taken us months to realize that we made a bad choice.  Then, it would have taken us weeks (instead of hours) to correct course.

When people use the word “agile” they think it simply means “flexible“.  And, while Agile make an organization and a web development project more flexible, it means a whole lot more than that.  People tend to misuse the word “agile” and throw it around like a buzz word. For the people who truly know and understand Agile, it can be a very powerful way of getting stuff done the right way. But, for it to work, there needs to be a procurement and contracting system that goes along with it, a true understanding of how it works throughout the organization, and a complete leap of faith to trust the principles of scrum and closely follow the Scrum Guide.

You can’t just throw on a Gumby dress and say that you are “agile”.  You have to live it.