As teams begin to adopt agile in their organizations, one of the most typical (and costly) errors I see is the lack of an overall vision of the project. Now, I’m not talking about that vision of what a product might do, its benefits to customers or the markets it might create. This part is actually done pretty well (in my experience). Business people, product owners, etc are more than eager to tell us why their projects are critical and stand out. And many times these discussions go all the way through the teams. Nope, that’s not what I’m referring to…

The issue I see is a lack of clarity in large projects related to a Roadmap.
The following diagrams show a few different pictures of a basic Agile Project Roadmap. In my view, when we commit to large scale project with critical deadlines, we need to show a thumbnail sketch of our intentions. We need to see the universe of currently known Features, User Stories, Epics, etc and where they might land between today and project end. Not only that, we as a project team need to work hard to define critical stories (business and technical) and shuttle them toward the front of the project in the form of a “walking skeleton”. We do this so we can raise the probability of achieving a delivery that gives our customers value (Alas the complete point :))

The Roadmap is not a guarantee. Nor does a Roadmap commit to delivering Features. It commits to a DATE and VALUE. (Yes I said DATE) If you haven’t learned that we all live by deadlines, stop reading now. The rest of this won’t help you.

I’ve Traveled Thousands of Miles and Could Only See as Far as my Headlights

It also helps the team refer back to the something that describes the overall project and our destination. Think of it this way…If you leave on a long car trip, we start by referencing a MAP and beginning our journey. There are times where things seem clear and the daytime illuminates the road and the road signs as we make our way. As the miles pass (and hours) and day turns to night, we can still progress toward the goal. We can only see as far as the headlights, but we can travel for hours this way. However, we still need to reference the MAP. We might have strayed from the original vision (by circumstance or a personal decision) but we still need to find our bearings and proceed. This is indeed what an agile Roadmap will do. It gives us the destination and a thumbnail sketch that we can reference when things get “fuzzy”. It won’t tell us the detail, just gives us an idea and needed confidence.

Roadmap – Initial Outlook

Below are the examples. The first shows a basic Roadmap after a Blitz Planning Session where we’ve identified architecturally significant and business critical Stories and Features. You can see in the beginning, we elicit just enough requirements to get going and work ahead of the team (“Iteration Ready Stories”). You can also see that we pushed all starred “walking skeleton” stories to the front of the project to help us raise the probability of learning early, and delivering the MOST critical pieces (recall VALUE as a primary objective). We can then slot the stories, features, and epics into the Roadmap based on basic Relative Estimation techniques (ie User Story 47 looks exactly like User Story 3).

Roadmap – In Flight Project

Now, let’s imagine we’ve just finished Iteration 3. The next image shows what the Roadmap might look like. You can see that we’ve delivered most of the walking skeleton and we’re approaching that threshold where everything critical is delivered. This is HUGE! You can also see that, during the project, we undoubtedly had to ADD stories as we learned more (visualized in Green). Conversely, we’ve also had to REMOVE some stories that didn’t make sense any longer (Red X’s). We are still eliciting requirements just in front of the development team (visualized as Pink “Iteration Ready Stories”). Notice we have NOT moved the date. However, we HAVE added enough stories to push the entire universe of stories PAST the end date. How could this be? Well, these features represent our ability to say YES to any features that hits the team as long as the team and the Product Owner can see that new features might represent ADDITIONAL FUNDING. This is indeed what a Roadmap will help us discover. But no matter. If funding is frozen, we have delivered the critical pieces by Iteration 4. The remaining iterations are Gravy. (…mmmmm, gravy)

Please let me know your thoughts!

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.

Ground Rules

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!

Capabilities Backlog

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.

True North

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.

Quarterly Goals

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.

• Objective
• Reflective
• Interpretive
• Decisional

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.

Conclusion

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.

I have the distinct pleasure of helping people plan and build their careers. In my current organization, one of my primary goals is to recruit and hire talented software developers to add to an already talented and energetic team. In this role, there is something that has me baffled:

“Why is there an awkwardly high percentage of developers who aspire to be managers?”

A snippet from the great Paul Graham post (and book), “Hackers and Painters”
When I finished grad school in computer science I went to art school to study painting. A lot of people seemed surprised that someone interested in computers would also be interested in painting. They seemed to think that hacking and painting were very different kinds of work– that hacking was cold, precise, and methodical, and that painting was the frenzied expression of some primal urge.

Both of these images are wrong. Hacking and painting have a lot in common. In fact, of all the different types of people I’ve known, hackers and painters are among the most alike.

What hackers and painters have in common is that they’re both makers. Along with composers, architects, and writers, what hackers and painters are trying to do is make good things.

If this is true, then why aren’t composers putting on a resume, “Wish to expand my career toward Composer Management”? Why aren’t painters asking for more “Painter Leadership” courses from the market?

I truly feel that comparing developers and painters is apropos. What alarms me is the rate at which organizations, especially large organizations, bastardize the career aspirations of artistic and expressive craftspeople by giving them one narrow path to advance, management. Many organizations can’t fathom a career path that doesn’t include leading others and amassing direct reports. Now, as a result, many developers can’t fathom it either. Sad.

If we think long and hard about what we are doing by encouraging this mindset, I argue we would never do it. As organizations, we typically take the best and brightest producers and “elevate” them to a non-producing position. (This is typically followed by a giant sucking sound whereby these people’s souls are ripped from their bodies.)

Don’t get me wrong. Leadership and management IS a noble career aspiration. I’m arguing it is not the ONLY noble career aspiration, and if you’re the type of person who wants to build things and be expressive and creative, then it might not be the path for you.

With all this said, as organizations we should work at giving developers an alternate career path. One where they can be dynamic, brilliant, and celebrated artists.

If you haven’t already, do yourself a favor and go buy Tom Peters’ great book “Re-Imagine”. In it, Tom addresses powerful opportunities for our organizations (and our culture) to tackle. One of my favorites – Women.

In the book, some of Tom’s examples are subtle, but paint a picture of clueless organizations (typically run by men) trying to sell to women. Some examples are, well…not so subtle. And I’m slowly learning they’re everywhere.

Here is but ONE example of now dozens I see regularly.

My wife and I had a pretty funny conversation about this and we agreed this tag line HAD to be generated by a man (or all male) team.

Extra Responsive in “Emotional” Moments…. (*Releasing Sweat)

Ummm….yeah.

Does anyone else out there think this is one of the most ridiculous pieces of marketing you’ve ever seen? Come on deodorant marketing slaps…you can do better!