What I was looking at was nothing short than a monumental divergence of goals. The VP over the product group wanted to open up small satellite offices in several locations across the US. Granted, each location would be fully connected, high end telepresence rooms, live work space cameras all backed by a top-end online agile management tool. On the face of it, not the worst implementation for a distributed workforce using an agile development model.
Only it was in direct contrast to what Jake had been working towards. He’d been working with facilities and they had a plan all in place to gut the development floor and rebuild it as a fully integrated team workspace. Pods for each team, quiet spaces, team dedicated meeting rooms with floor to ceiling white boards, the works. The perfect co-location workspace.
Two wildly divergent plans. Yeah, they both were completely supportive of the company’s move to agile. The problem was they were pretty much diametrically opposite approaches.
“How on earth did I get here?”
“Well, you got in your car this morning, got on the 280, headed south…”
I looked up from my computer display to my unwanted visitor. Hogarth, my 800 pound imaginary gorilla and self-appointed conscience was leaning against the door to my office. He’d already reached over and stripped a branch from my latest fichus tree and was carefully plucking a leaf from it (Someday I’d figure out how an imaginary gorilla managed to cost me a fortune in real plants).
“Hogarth, I’m not in the mood for your beat around the bush word games. If you have something to say, just spit it out.” In retrospect, telling a gorilla, imaginary or not, to spit probably wasn’t the best choice of words.
Fortunately Hogarth didn’t take me up on the format of communication. Instead he quietly snacked on the fichus branch for a minute. “Well,” he said as he tossed the denuded branch to the side, “sounds to me like an alignment issue. The teams and management don’t have the same view on the why. The same order of values.”
I gaped at him as if he’d suddenly grown a second head and it was speaking in Latin. “Look, everyone from the CEO down to the front line coders can recite the agile values and if they don’t know the principles by heart, we’ve got them on posters around the whole office.” I pointed to an example of such on the wall of my office. “So we are plenty aligned on what agile means.”
Hogarth looked at the poster of the agile principles and cocked his head to the side, “Which one’s first?”
I shook my head forcefully. “Are you crazy? They are all equally important. The Manifesto drafters didn’t number them.”
“Oh, so they are all a P0 feature, I get it now.” Hogarth nodded with a satisfied smile.
“Wait? What!?… No… I mean… Umm….”
I really hate it when he does that.
The Agile Principles, they can’t all be Priority Zero
How many of you have seen a classic Product Requirements Document (PRD, MRD) where the majority of the feature requests are priority zero or one? Yep, me too. It’s the job of one of twelve principles of agile “maximizing the work not done” to address just this problem. It’s part of what drives the creation of a rank ordered backlog. The backlog is one of the overarching “artifacts” of agile (and lean). You can be running sprints, doing Kanban pull, DAD, SAFe, LeSS, XP, etc and you will have a backlog. Few if any other “artifacts” have that kind of span.
And yet, we’re expected to hold all four agile values and twelve agile principles as equal?
Okay, yes, that would be awesome. A truly transcendent self-organized working group that has moved beyond the material concerns of today’s world.
Reality though tends to point out that having more than one priority is nearly impossible. Peter Drucker said something to the effect of “an effective executive can focus on one thing really well. An exceptional executive can focus on two.”
We rank order our product backlog. We even rank order things coming out of our retrospectives. And yet we don’t spend time aligning on the principles of agile? We can’t do twelve things at once, so what do we focus on first?
Agile Principles 20 / 20 Exercise
This simple exercise can quickly let a team, of up to twenty, rank order the agile principles from highest priority to high priority (recognizing that all the principles are important). By conducting the exercise across the company, you can quickly get a sense of priorities and where alignment is lacking. For example, I’ve found development teams often put “welcome changing requirements” very low on their list, while a product management or sales team might place this very high.
Understanding where alignment is lacking, will then allow the conversation to bring about that alignment. At the end of the day, Sales could end up realizing that development’s goal of “delivery working software frequently” is better than getting to make changes weekly. You have to have the knowledge, to have the conversation, to gain the alignment.
Exercise In a Nutshell: The exercise in two hundred words or less (152 to be precise).
Print each principle on a single sheet of paper. Find a bare piece of wall. A neutral facilitator then randomly shuffles the cards, placing “Our highest Priority” principle at the bottom of the deck. The facilitator places the first random principle on the wall and invites discussion. Then the second principle is held up and the team is invited to decide if it is more or less important than the first. This proceeds through eleven principles, with discussion as each one is placed (trust me, there will be a lot as more cards get on the wall).
When you get to “Our Highest Priority” explain that while the signers of the manifesto did not rank order the principles in general, they did put this one at the top of the list on purpose, feeling it to be the most important of equals. Challenge the team on if they feel it is also the most important.
For a complete walk through of the exercise, you can download it from my Dropbox share: Agile Principles 20 /20 Exercise.
I’ve also created a Pecha Kucha format presentation, which I’ve shared on Slideshare , under the name “Agile Principles 20-20 The Gorilla Coach”
Credit where credit is due. I learned this technique from the dual powerhouses of Jason Tanner (@JasonBTanner) and Luke Hohmann (@lukehohmann). Jason is a Certified Scrum Trainer and CEO at Applied Frameworks, a company that specializes in helping your company get its product direction and strategy going in the right direction. Luke is the founder and CEO of Conteneo Inc., well known for their Innovation Games which is now part of their larger Collaboration Cloud. I took a Certified Scrum Product Owner class co-taught by these two gentlemen and learned this exercise in their class, which uses Conteneo’s 20/20 collaboration game as a the framework.