Last Friday, I had a meeting with a boss of mine from long, long ago. Currently, he is one of the Directors of Test for Windows, which is a stronghold of waterfall. He wanted my opinion on how to use what I’ve learned in my recent job positions. These are teams that have deployed Agile techniques and have begun the march towards reducing headcount in Test Generalist positions. So he wanted me to bring him up to speed.
In retrospect, I wish I had done my best spooky voice and stated:
“Beware the JeDI”
Over the years, I have personally witnessed several teams struggle to rollout Agile. After doing my own analysis of common symptoms and behaviors, I have created a simple litmus test you can use to determine which your team is executing. You may be surprised. The first step to using it is to observe your team’s behaviors and ask: what is the question that these behaviors are trying to answer?
A Waterfall team asks: “Is the plan on track?”
An Agile team asks: “Is the plan correct?”
A JeDI team asks: “Plan? Just Do It!”
In Waterfall, the team is executing on a plan and getting the code out to market in accordance to the plan is pivotal for all of the synchronized machinations to work properly. (Marketing, Sales, Customer Service, Hot Fix Engineering, etc.)
In Agile, the team has a baseline plan, but focused on shipping small bits of the code to the customer with the intent of determining if the plan is the right direction. Based on observing the customer, the plan will change and a new direction set. (Note: I adore Elisabeth Hendrickson’s definition of Agile here)
A JeDI team believes they are Agile and each individual works 16 to 20 hr days in order to stay on track. They think this is just a reality of software engineering. Scaling way back on planning and documentation, they are heavily focused on “Code Velocity”, and their customer is someone they believe they will delight, but their view of the customer is theoretical for the most part. When they actually observe customer behavior though, the runway is too short for them to make changes. In these teams, Test Generalists are very often reactive to development. In a world where “Code Velocity” is king, partnering with Test is an afterthought. In some cases, I’ve even seen a total lack of documentation… If it were constructed, that might help Test solve its own problems. But no. There’s none. It’s not dissimilar to Cowboy Development.
In a previous post, I was asked to explain why I didn’t recommend the Agile Manifesto. It is simply this:
The Agile Manifesto creates JeDI teams.
On JeDI teams, there are 3 common characteristics I have noticed of the people driving the teams:
- They are all wicked smart. Often the best at what they do.
- They are good at making things efficient
- They are very focused on getting stuff done… and yesterday.
When combined with the Agile Manifesto, I’ve seen practices created that end up (ironically) being highly dysfunctional to the project overall.
- These folks like things simple. Black & white is better than shades of grey.
- They will tend to use only the Agile Manifesto to understand Agile. And there, only the 4 Values, not the 12 principles. (In fact, I’ve had conversations with strong admitted Manifesto supporters who did not even know of the principles.)
- These folks will take the 4 values and oversimplify to:
- Agile == Low Overhead AND/OR
- Agile == Flexibility
- They will roll out their new “Agile” program. Unchecked, Low Overhead and Flexibility quickly becomes: “I get to do what I want (flexibility) without being accountable to management (low overhead). “
Once that has taken hold in your team, it is really, really hard to fix it (perhaps, a blog for another day). In my experience, some key value gets subtracted from the Manifesto:
- The principle of Customer collaboration gets devalued. Working with the customer “hand-in-hand” is important to succeed with Agile. Learning your customer iteratively.
- “Responding to Change over following a plan” is, IMHO, intended to mean Fail Fast and change the plan based on what you have learned, not to execute without a plan.
Are you in a similar situation and trying to understand Agile?
Here’s my advice: (modified from a George Paci quote here)
“[Treat Agile] like an off-the-rack suit: it’s not likely to fit you perfectly, but you’d better try it on before you make alterations.”
The best way to avoid the JeDI is to prevent your team from becoming one in the first place. The Agile Manifesto does not tell you what to do. It tells you what to value. It’s a definition, not an implementation plan. Taking its values to excess will cause dysfunction on your team. Heed my warning.
Instead of starting with the Manifesto, implement the variant of Agile that most fits your teams skills, resources, and needs. I think Alan Shalloway and his team has a good resource you can use. (I’ve sent Alan a note asking. If I get it or find another resource for you, I’ll update this post). [Edit: And he did! (thanks, Alan) He recommends this link (Overview) and this one (additional resources) if you want to understand more] The three most widely used variants to my knowledge are XP, SCRUM, and Lean. My personal preference is Lean with Kanban.
Whichever you choose, implement it exactly as intended from the sources. Once you have experienced it firsthand, then feel free to make changes. Agile *is* about learning, after all.
Once you have tried it out, the Manifest will become clear and true to you and it is a thing of beauty.