Why Modeling Agile Planning Behavior Is Critical for Team Success
During my tenure at a previous organization, I spent most of my days working to deliver and coach Agility in our software teams. By in large, it was an effective and well-adopted change and a complete team effort. That’s not to say there weren’t areas that continued to frustrate the teams, our business partners, and our management leadership team (of which I was a part).
Our organization was like many. Early in our change adoption, projects had spotty success in delivery. There were many causes for this including weak business involvement, massive “define and refine” efforts without any tangible delivery, thrashing about project process and the detail of “secondary deliverables” (think uber project artifact checklists).
Early on, the IT management staff knew we needed to help “script some of the critical moves” for the teams and Scrum / XP / Lean principles helped us deliver just that. The adoption of this cultural change was “hefty” to say the least, and understandably slow. After some grass roots experimentation in the early months, all 120 IT resources began using Agile as our primary project development process after my first year. We quickly began education and reorganization was soon to follow. In many ways this was outstanding because, as an IT leadership team, we all agreed that helping the projects teams (and projects) succeed was priority number one. We were all aligned behind a common purpose.
Predominantly we focused our energy on agile adoption, and team / project planning. This planning was precise, timely and valuable to our teams and business owners. Over time, the teams began to produce and we reaped the rewards of better quality, quicker delivery, and closer teams. However, we consistently had teams frustrated by the promise of agility, but were never able to achieve the results they (we) thought was possible. Even the best teams became mired in issues outside the projects, and slowly the shine of our new process began to fade.
As with any organization, we attributed these failures to a whole host of obvious shortcomings:
- Low adoption of XP practices
- Too much task switching and lurching on priorities
- Lack of proper estimation techniques
- Mostly manual quality assurance processes
- Little understanding of the “fuzzy front-end” of Agile project work
- Our iterations were too long
- Our iterations were too short
- We were “too Agile”
- We weren’t “Agile enough”
- Agile isn’t detailed enough
- Agile is WAY too detailed
- …and the beat goes on
As any good management team will do, we wanted to fix it. So much so, we all had independent ideas on how we might bolster our capabilities in support of our shiny new agile project process. Not only did we all have really good ideas on areas for improvement, we ALL launched headlong into training, teaching, and implementing these fixes whenever we determined we had a need. This was the start of an organization-wide misalignment.
(I think you can see the likely conclusion here)…We were out of control, yet every last one of us had the moral high ground to stand on.
“It’s frustrating. If you just give me a few months. I am going to teach the teams how to (x, y, z). That should help fix it. I really think this issue is causing the problem.”
In our haste and good intentions, we inadvertently caused considerable priority churn (and tumult) in our organization. As they say, “the road to ruin is paved with good intentions”. As a management team, we unwittingly were responsible for a large portion of the malaise our teams felt. This was largely due to our inability to “deliver” process and practice enhancements to our organization effectively and when needed.
We soon felt the frustration level of the management team rise. We all were perplexed that we hadn’t been able to adopt capabilities more quickly on our teams. After all, these teams, by any one’s measure, are outstanding! Not only that, I truly feel (and still do) that our management team was complete with high performing, intelligent leaders with all the best intentions. From my days playing basketball, we were pressing. We knew we could do better, we tried to do better, and nothing seemed to help…so we tried more, and then more…and a vicious cycle ensued. The more we tried, the worse it became. We – were – pressing.
So where do we go from here?
Enter Jean Tabaka, agile evangelist / fellow at Rally. I decided to attend a session given by Jean on determining and delivering organizational strategy and vision. It was terrific. So much so in fact, I had a “Tabaka-inspired” epiphany on the flight home:
“Why O’ Why are we not applying the agile planning and organizational principles in our senior leadership team and guiding the way we do long term planning and organizational goal setting? We consistently ask our teams to do this very thing, yet we are running the organization like we’ve never heard these principles. We are ineffectual for the very SAME reason we adopted agile delivery on project teams in the first place! ” …Eureka!
The Strategic Framework
My first step was to ping Jean and ask for some advice. She gladly obliged, and before I knew it, I was pouring through some of the work she and Ryan Martens had done at Rally and reading a few of the texts she referenced in our interactions. Over the next few months, I cobbled together a pretty cohesive strategy for how our senior leadership team might go about planning and adapting using a “Strategic Framework”. The framework followed the approach of Dr. Edward Demming and a repurposing of the PDCA process (the Demming cycle). What follows is the design of that framework and a little detail about how we Plan, Do, Check, and Adjust (just like our project teams). Most of this initial attempt was based on experimentation and lots of facilitation.
Strategic Theme “Keywords”: Vote Your Conscience. Vote With Meatballs
My first step was to fly our leadership team in for a 2-day offsite meeting that I would facilitate. The meeting would be broken into a couple of components. The first of which was a pre-meeting dinner the night before to build some connectedness, get to know one another even more than we might have before, and also deliver the first team exercise of the 2 days – prioritizing “Theme Keywords”. I enlisted the help of our CIO and our Director of Engineering. We distributed a sheet at dinner with 6 “theme keywords” outlined on it. These themes were ones we as a management team had spoken at length on in meetings past and our CIO was keenly interested in. The thought was to have the team discuss these themes at dinner and at the dessert, vote on our “top 3”…ones they felt our organization should be most focused on in 2011.
Why 3? BECAUSE — that’s why. (There truly was no rhyme or reason to this, but we needed to focus on a small, achievable number. 3 it is.)
We gave everyone 5 “points” and they could spread them over any number of keywords they wanted, or use all 5 points on one keyword. (BTW, “points” quickly became “meatballs”. We were eating at an Italian joint and it seemed more appropriate to vote with meatballs. The wine at dinner had nothing to do with this transition of voting style.)
After the voting, the 3 keywords with the most “meatballs” were selected and I prepared a sheet to hang in the meeting room with the themes. As you can see, these are extremely broad categories, but the goal was to start, however roughly, aligning our thinking.
As we arrived for the session, the room was prepped with a few sheets on the wall (including the prioritized themes) and we started off with the ground rules.
- Healthy Friction is OK
- Rank is NOT important
- Being polite IS important
- Listen First, Speak Second
- Be Energetic and own the outcome of this session
- Be patient
- HELP if you see a need!
We then began a review of our core capabilities, and one’s we need to develop. I brought a list of my own (to get the ball rolling) and added them to large sheets. We then generated a huge volume as a team (using sticky notes and time boxed brainstorming). A core capability for our team consisted of things like:
- Test Automation
- Relative Estimation
- Iteration Zero and -1
- Project and Portfolio Management
- Continuous Integration
- Data Architecture
- Etc. Etc.
We took the time to talk through each capability at a high level and determine which of the theme keywords might match, if any (Quality, Execution, and Communication). We then stopped the time box and called this our “Capabilities Backlog”.
This was (on the surface) straightforward. But as we found, the more you do this the more you understand the thinking of your peers about what a “capability” is, what it is not, and the level at which they think our teams “exhibit mastery” in these skills. This proved to be invaluable.
In Flight (Non-Project) Initiatives
We then began to discuss our current “In Flight” initiatives that were NOT related to projects. Essentially, we wanted to know what types of initiatives we’d started (together or individually) and what level of mastery we’d achieved (core strength, proficient, just starting, dormant). We wrote them all on sheets of paper and categorized each. Are you ready for the kicker…?
We had 46 initiatives that were in some state of delivery on the morning we walked through this process. FORTY-SIX!
We all immediately slumped in our chairs, took a drink of our sodas, and shook our heads. How could our teams possibly be effective delivering an enormous project portfolio, PLUS deliver all the “capability initiatives” we gave them throughout the year? We all knew the answer to this was…they can’t.
The Stop Doing List
Our next step in the process was to create a “Stop Doing List”. As Jim Collins says, sometimes the most important list of things you look after as a leader is the “Stop Doing” list. This process was tenuous at times, but through facilitation and collaboration, we all worked extremely hard determining which things, even the pet projects most near and dear to us, were going to go on this list.
In all, we whittled our list of “In Flight Initiatives” down from 46 to a manageable 16. I was shooting for 3 prior to the meeting, but what can I say, I’m naïve in this way. :) No matter how you slice it, this was a stunning victory for our leadership team, AND the project teams we lead. The focus was starting to emerge once again. Now we needed to define our framework for determining the strategies, goals, and what we might do to inspect and adapt.
We started by focusing first on our organizational “True North”. This essentially is described as the thing in our organization that will never change. It’s what we are and is in our fabric, and is the thing that we will look to consistently to make course corrections as we navigate. This is a critical first step because it would allow us to ask the question, “Does this support our True North?” if we ever got stuck without guidance in the remainder of the session.
Strategic Themes – And the All Important Sound Bite
We then used a cascaded model (starting with True North) to define 3 yearly “Strategic Themes”.
I decided to use the notion of a “Strategic Theme” so we could focus our energy on a few key areas derived from our Core Keywords. These will help us focus out in front as we move forward (and keep us from looking at our feet as we advance). The idea was to generate a “PR Sound Bite” for each strategic theme. It always seems much easier to get behind something that can be talked about in this way. As an example, we generated a strategic theme from the Execution keyword around our definition of DONE: “Delivering Done”. Sounds simple right? It is, and has meaning in OUR context, and is easy to talk about when people are in the throws of high pressure project work. Another example for Quality might be “Best Beats First”. You get the picture.
We then began to create the most tactical and concrete portion of our leadership planning exercise, “Quarterly Goals”. I guess you could call them “Rocks” as this is the terminology that Rally and Jean use, but we weren’t ready to use that terminology). We decided to execute 3 Quarterly Goals per quarter. Why 3? (Because – That’s why.)
The ORID Process
In order to truly follow a PDCA process, we need to plan in to the framework the “Check” and “Adjust” steps. We decided to use one of the models Rally has used in the past to make this work, the ORID Process.
It is similar to De Bono’s Six Thinking Hats and others, but was simple enough to use and gave us the feeling that it would be easy to implement. The ORID process will allow us to go through the “Check” phase and talk about how our Quarterly goals are coming, what data supports it, how we feel about the progress, and what we might need to do next.
We then put quarterly meetings on the calendar and ensured our entire leadership team was able to attend in person. This step cannot be understated or undervalued. “Signaling” the intent of management to bring people together, and the expectation of the team to make it to those sessions is critical. Putting these meetings on the calendar and booking travel is as much about signaling intent and delivering an expectation as anything.
As a leadership team, we chatted after the sessions and everyone involved felt this process and the new strategic planning mindset is crucial to our ongoing success. It was amazing to see some of the learning and breakthroughs we achieved during the process of 2 full days with one another, collaborating and engaging.
There were completely obvious breakthroughs:
- Prioritizing the work we need to help lead
- Aligning our leadership on a few “achievable” core strategies and goals
- More focus on “finishing” versus “starting”
- Eliminating the massive “churn” we created with 46 in flight initiatives (not to mention a huge portfolio of projects)
- Getting in-person, quarterly session on the calendar
- Discussing our ideas of what is critical and where are teams are in their learning
There were also many non-obvious wins that shouldn’t be overlooked:
- The camaraderie displayed by working closely with one another on a common purpose
- The human interactions and relationship building exercises that will be the foundation for better communication going forward
- A glimpse at the attitude necessary for Agility to thrive was witnessed by the management team
- Our ability to “eat our own dog food” (and have big successes) goes a long way to illustrate to our teams that the Agile / Lean mindset is not one that is lost on their leadership.
- Arguably the most important “non-obvious” outcome: The process of planning our organizational strategies is identical (and is the start to) agile project success.
As they say, “the proof is in the pudding”. Time will tell how these concepts will affect this organization overall. I feel this process gives us the best chance to make needed changes quickly, and empirically steer these groups forward. I’m hopeful that a renewed focus on running the organization empirically, but with rigor and discipline, will pay off over time. I think the leadership team has learned that we can advocate agility and USE agility at all levels to help our organization and our teams succeed. I’m nothing if not hopeful.
The good news: if it’s needs to be tweaked, the change scaffolding is already there and waiting to be used.