The Plan

We Are Agile, We Don’t Need A Plan

If you have ever said that, or heard someone else in your organization say it, you are so WRONG!

One of the most common misconceptions about agile is that you don’t plan, you are so “agile” that you can just wing it. This way of thinking hurts you, your project, your team and your future success. You want to know how to BE and do agile well? Make sure you make the time to put together a solid plan and communicate it to the entire project team, being open about the vision is the first step to being agile as a company.

Having a plan is good, having a good plan is better, having a good and flexible plan is best, but having a plan that makes no sense to the project or your team simply sets your team up for disaster. This poem, which I do not know the source of to credit with, is a silly yet great example of what happens if you build a plan without really hearing what your team members are saying:

The Plan

In the beginning was the Plan.
And then came the Assumptions.
And the Assumptions were without form.
And the Plan was without substance.
And darkness was on the face of the Workers.
And they spoke among themselves, saying,
“It is a crock of shit, and it stinketh.”
And the Worker went unto their Supervisors and said,
“It is a pail of dung, and we not may abide by the odor thereof.”
And the Supervisors went unto their Managers, saying,
“It is a container of excrement, and it is very strong, such that none may abide by it.”
And the Mangers went unto their Directors, saying,
“It is a vessel of fertilizer, and none may abide its strength.”
And the Directors spoke amongst themselves, saying one to another,
“It contains that which aids the plant growth, and it is very strong.”
And the Directors then went unto the Vice Presidents, saying,
“It promotes growth, and it is very powerful.”
And the Vice Presidents went unto the President, saying unto him,
“This new Plan will actively promote the growth and vigor of the company, with powerful effects.”
And the President looked upon the Plan, and saw that it was good.
And the Plan became Policy.

THIS is how Shit Happens!

Why Does It Matter?

The value of putting together a plan with comments from the team means that you will ALL understand the pros and cons of what that plan means. I am not talking about the business strategy, the initiatives here, I am talking about the nitty-gritty of what those items do to the folks doing the work everyday. Simply, a good plan is what allows you to be agile within a solid. known vision; it provides a guiding star that allows everyone, on a daily basis, to make small iterative adjustments toward it and helps make sure things stay on track! It may seem like overkill but having an entire project team with a solid understanding of not only the project’s currently release priorities, but the bigger picture, they all become co-navigators helping to keep both the project and you on track.

At the beginning of each release, as Product Owner, I would have a meeting with each of my teams to present my vision and priorities for the upcoming release. Mine, of course, included input from stakeholders up the line from me including our Chief Product Owner, other team Product Owners, our executives and Board of Directors, as well as the company that we were building the project for. This meeting allowed me set expectations for the team, including both what needs to be done and when it needs to be done by. Trust me, when you have a bunch of engineers and testers in a room reviewing your plan, you quickly know, not only if the boat is going to float, but if you forgot the oars or even an engine!

I truly loved these meetings because it meant that we all walked out knowing where we needed to be by the end of the release and each meeting leading up to it, whether Sprint Review, Planning, etc.; every attendee on my team knew what was behind every ask, each user story, and they could ask the right questions to make sure that missing pieces were identified before the release ended. This also allows you the flexibility to adjust your iteration planning quickly. With the release plan shared, the team now can help you figure out the best time to do specific work to ensure it is ready when other more complex features need them. Lastly, it helps your team keep you and themselves honest by helping to reduce feature creep. I remember regularly getting the question, “Why is that in the iteration backlog (or on the priority list), it is not part of the Release Flow.” Suddenly you have a lot of smart people thinking about how best to get things done by the deadline and that shared intelligence is one powerful tool to have in your corner!

How Do You Do It?

Every project is unique and you might need to try a few things before you find something that works for you. Some teams use visual flow diagrams, some use bar charts and stack-ranked features, there are a lot of options. The best thing I can suggest is see what best represents the needs of your project and your team(s) but do not get so attached you do not adjust it when you learn more. There are times that the most efficient thing you can do with a process is to ditch it!

A few years ago, I was working with a User Interface team to build the new UI for our project; it was a video game for kids which meant simplicity was the key yet the overall UI was very complex in what it needed to allow the user to do. Fitting all the elements together into a cohesive presentation that allowed for iteration-to-iteration planning was a challenge. Early on in the project we would do simple sketches using an agreed upon, prioritized “Must, Should, Would Like” style list of things we needed to get done but it just did not present the information in a way that worked for our diverse team which included engineers, artists, a designer, a tester and a producer/UX Designer. We had a plan, sort of, but it was not working or providing us the insight we needed to know we were on track.

A page from one of our Release Deliverable Flow diagrams.

Sample Release Deliverable Flow Page Detail

So what did we do? I started building a visual version of our release’s goals; goals that reflected the experiences of our user, how would they experience our game at the end of the release step-by-step from entering the game to signing out and closing the game when they were done. It was a visual, step-by-step mock-up each area listed in the game’s full release plan broken down into the features our team needed to focus on with notes and priorities on each page. (See the sample at right.) The images were simple, grabbed from images on the web, elements in the game, what we called “developer art” (also known as “usually ugly but you get the idea”), as place holders to represent what needed to create and built with call-outs for detail and status as well as simple bullet points for that sections priorities. It was not something we “knew” we needed but along the way we determined that it was required to make sure we, as a unit stayed, on track with all the priorities, game-wide, in the release. Having a beautiful game is one thing but if the user cannot interact with it the way they need to, why bother?

Building Your Own Release Deliverables Flow Diagram

This visual release planing process was originally created specific to the User Interface team’s needs, yet more and more, members of other teams would come into our team space to see it and use it as a reference for their work; it connected the work of all the other teams into one flow through the UI system perspective. Soon they requested a version for the entire game’s release plan – we called it a Release Deliverables Flow Diagram.

Creating the Release Deliverables Flow diagram process changed a bit once it became a project-wide planning tool. There was a lot more work up front to ensure it represented what the game should both look like and do by the end of the release. Click here for a Sample Release Deliverables Flow Diagram.

This is a sample of the steps we took to create a project-wise Release Deliverables Flow Diagram.

  • Step 1 – Chief Product Owner/Vision Holder would put together the initial flow elements to make sure it captured the big stuff – initiatives, priorities from stakeholders as well as required features and wishlist items.
  • Step 2 – One-on-one review for what was already done and “missing pieces” plus lots of discussions to make sure priorities were clear across the entire project and for each team’s feature area. What “Musts” really were “Musts” and not just passionate “Shoulds.” The MoSCoW method was used to clearly list the priorities of items, using “Must Have, Should Have, Could Have and Would Like” or the simpler “Must Have, Should Have, Nice to Have” variant, on each page alongside the visual plan for each area of the game.
  • Step 3 – Present the diagram, with priorities, at our Product Owner meeting. This was usually the first communication about the full release priorities and allowed the Product Owners to get started on the planning needed in their area for the upcoming release.
  • Step 4 – Put it on the wall for all to see. The entire Release Deliverables Flow was put on the wall to allow feedback from every part of our studio. This exposure revealed a lot of holes, issues and needed clarification but also allowed the team to see it as it evolved iteration-by-iteration.
  • Step 5 – Keep it up to date! Why have a long-term plan if you do not regularly revisit it as you move through your iterations? Review it, updated it, when something gets done, write “DONE” in big bold letters. If something gets cut, don’t just remove it, cross it out and mark “Cut”. This reduces the questions and the worry about it being forgotten or lost in the shuffle/last update.

Follow-Up, Follow Through, Getting It Done

Once the Release Deliverables Flow was complete it was put up on the wall next to our kitchen allowing every person in the studio to walk-by on a daily basis, review where things were, ask questions and make sure important elements were not forgotten. Based on feedback, this too evolved based on the needs of our entire team; they wanted colored text to denote status: Green for Done, Red for High Risk, etc., then we added a bin on the wall to hold post-it notes and pens so that anyone could walk-by, add a question, note or detail to the flow allowing all the Product Owners to come by, see questions and issues from a broad area of expertise thus allow use to fill in a lot of holes! It was one of these notes that made us aware at a big piece of infrastructure needed for the game that was not in the backlog!

For the first time everyone on the project could see what we were trying to get done and where things were. At the end of each iteration, I would update any of the relevant pieces of the flow to show what was completed during the iteration. In the early stages the Deliverables Flow was compromised of lots of black and white placeholder art, images from the web, samples, blank boxes, rough sketches, yet as the release progressed, you could see the flow change as it was updated to show each iteration’s work. I am not going to pretend that it always went as planned, things changed, but this too, even with its upfront cost, made release plans and priorities an everyday communication tool, not just something we did once a release or at meetings where most of the team members were not present.

A plan allows your team to understand where they need to be and when they need to be there EVEN when the Product Owner or Vision Holder is not available to “Be Sure.” Open communication means knowing the direction we are headed, and even if they get off course slightly, the correction will be a minor one and not a “titanic” one. Planning is truly your first and best step to Agile success.

Leave a Reply

%d bloggers like this: