A challenge faced by many SAFe organizations is creating an efficient PI planning process: one in which the in-person meeting advocated by SAFe generates high-impact, actionable results.

One of the reasons why this is hard is that the PI planning meeting is the first time the team is exposed to PI goals and requirements is when the team attends the in-person meeting. That’s too late. Members of the Agile Release Train are vastly more effective if you engage them before the release.

The key word? Engage. We don’t mean asking them to read a document. That quickly leads us down the slippery slope to document-centric, Waterfall processes.

Instead we mean: using collaborative frameworks in Weave so that teams can have the dialogs and discussions that increase understanding and lead to collective action.

This post presents a comprehensive toolkit for using Weave to improve your PI Planning and related project Kickoff or Liftoff events. You’re encouraged to mix and match the frameworks captured in this toolkit to meet your needs.

Phase 1: Pre-Meeting Engagement

Use these frameworks before the PI planning meeting to get the team engaged without asking or expecting them to make binding commitments. That’s key: the team is not yet ready to make “final” choices or thoughtful plans (that’s the purpose of the in-person meeting).

If multiple teams are involved then have each team engage in one or more forums. This gives you a comprehensive dataset (one forum result for each team), giving you the opportunity to analyze the data for insights and patterns both within and across teams.

The frameworks presented below are ready to go – just click on any image and you’ll start a Weave forum ready to go!

Agreeing on Priorities

SAFe advocates ensuring that your teams are aligned on business priorities but doesn’t provide a framework for this purpose.

Fortunately, the 20/20 Vision framework is specifically designed to help you build alignment on priorities. Capture your priorities and have your teams prioritize them.

Establishing a Vision

One of the most engaging ways to establish a compelling vision is to use the Product Box framework. Unfortunately, Product Box doesn’t work well with distributed teams, so use On the Cover instead.

This framework asks teams to imagine their release was featured as the cover story in a famous magazine. Capturing the big headlines and crafting a compelling story helps build excitement for your planning session.

Roadmapping / Strategic Planning

Traditional approaches to roadmapping promote overly rigid, linear thinking. We prefer to encourage the growth of your products and services through the Prune the Product Tree framework. Your Themes are represented by branches; candidates for features and capabilities that are represented as apples. And if you have tech debt? No worries – capture that as rotten apples!

Understanding Business Value

Agile teams produce better results when they understand which Product Backlog Items (PBIs) are associated with new customer revenue, up selling existing customers, retaining customers or improving operations. Our friends at Agile42 created Business Value Poker; helping leaders clarify desired outcomes in these dimensions. Learn more here.

Identifying Risks and Enablers

Sailboat is a framework designed to help you see risks in five dimensions and there are a lot of versions of this framework on the web, we like this version as it clearly articulates multiple dimensions of project insight.

Understanding Degrees of Control

Teams work better when they have a clear understanding of their scope of control. Accordingly, Certified Collaboration Instructor Joel Bancroft-Connors from Applied Frameworks recommends using Diana Larsen’s Circles and Soup.

Negotiating Initial Scope

We love the Impact-Effort Matrix for teams to simultaneously consider the important dimension of business value / impact and the orthogonal dimension of effort. Working together, they can identify and shape the highest value, lowest effort Product Backlog Items.

Phase 2: Analyzing Data

Once you’ve engaged your teams, you will want to leverage the data from Weave to further prepare for your in-person PI planning meeting. Weave makes this easy – just download the forum data, identify key patterns and adjust your in-person PI agenda to leverage the data. We find it helpful to download the completed images from the forums in SVG format and print posters of key artifacts to help the team leverage their own insights. More importantly, you can use the same frameworks both online in Weave and in-person during your PI meeting to create.

Now You’re Ready for Your PI Planning Meeting!

With a small amount of up front, online collaboration in Weave you’ll find that your PI Planning meeting is vastly more effective. Weave on!

A new method for planning architectural evolution, 4-square snapshot diagrams

Planning evolutionary change is hard, especially for software architecture. I’ve been developing and successfully working with a new visualization tool to help you identify the intermediate steps needed to create a solid architectural plan. After you read this post, you will have learned a concrete planning tool that will better support architectural evolution.

We need to know three things when we plan for the future of our systems. We need to understand:

1. where we are today
2. where we want to be in the future
3. what our next steps should be.

I’m going to demonstrate with two case studies how my new visualization tool, the 4-Square Snapshot Diagram, will cleanly and visually show the above three requirements in a single view.

Before I share my stories, let me give an overview. The 4-Square Snapshot Diagram works by first understanding what we have today and what’s really true. Then, the future vision of the architecture can be created. Finally, with backwards and forwards planning, we define the “steps” along the way towards that future. We will review:

• t=0, or now. What is our current architecture? (High-level logical systems diagram). • t=24, or the future. What do we want/need to be true in two years? • t=8, t=16. Working backwards, what intermediate states do we plan to create?

The case studies show how the architectural time frames were chosen to fit within the overall business content. The default is a two year technology plan to set up a three year business plan. Finally, we will discuss the options available to both the future vision and the intermediate steps. There are multiple viable future states, and for each one there are multiple viable paths to get there.

A Large Legacy System

While working with a client they were wrestling with a large legacy system and the future markets and products they could evolve to serve. It would take a year or two to get there though, and we used the 4-square sequence diagram to help visualize, understand, and align everyone on what direction we ought to go.

A Mobile-First Startup

The time horizon for this was much shorter, and that made sense for a startup. We were starting with the simplest thing that could work, and then adding capabilities (and the tech needed to support them) as we grew.

CONCLUSION

You can experiment with this tool immediately and see helpful results. If you want any help please reach out to Gist Labs – we love this kind of work!

The Three-Color Problem Solving Technique

Hide the Blue Markers: A tool you can use to analyze and fix complex problems

You have a problem. It’s a big problem and you’re not exactly sure what it is, much less how to fix it. When you start discussing the problem with your team, you find that some team members are jumping to conclusions and you haven’t even outlined the entire problem.

This is the simplest problem solving tool I’ve used to help a team completely define and analyze a problem before creating any solutions. I discovered this technique by accident, a happy accident. Here’s how it came about.

Hide the Blue Markers: How This Solution Came About

Several years ago, I was working with a team and one day, we started experiencing a production issue. The systems were behaving slowly everywhere: the process queues were backing up; the application servers were nearly idle: the databases were nearly idle; no thread locks or contention could be found. There were many different components and subsystems at play and it was not obvious what was going on. It was quite a mysterious problem.

The team organized into a meeting room to figure out what was going on, what they should do, and I was invited to join them.

Jumping to Solutions

As we dove into the conversation to understand things, I asked the group to step back a moment and draw a systems diagram to show and teach me what was going on – because I didn’t know what was present.

We used black markers to draw the systems diagram, showing the client components, the communication channels, the various server components and processes and databases and so on.

As we were drawing the systems diagram, we also agreed to use red markers to show the problem areas: where things were going wrong, or where we thought there were risks of failures. As certain risks were marked in red, some individuals would get an “aha” and then jump to leave the room and go fix it.

I literally watched people leap to solutions. I was fascinated.

As the meeting progressed, the team used blue markers to denote solutions. Although I cautioned the team to “not leap to conclusions,” they still did. It was amazing seeing individuals yet again try to jump up and go do something. Yet, we hadn’t even finished fully describing all of the system. And we hadn’t finished describing all of the possible problems, risks, or failures.

One Color at a Time

I began actively facilitating the meeting. I gathered all of the markers in the room and set a meeting rule: “We can’t move on to the next color until we’re finished with the color that we’re on.” That meant that we had to finish using the black marker to define the current systems diagrams and the things that we knew to be true. No more red or blue markers for a while.

Once we all agreed to this new rule, we moved on. We used black until everyone agreed, with a head nod, that we had captured the current system as we knew it. Then, we picked up the red markers and annotated the diagram focusing on the problem areas, where things were going wrong and potential risks. Whenever ideas or solutions came up, we politely deferred those to when we were ready for the final phase: the solutions phase where we would get to use the blue marker.

After the red marker annotations were completed and everyone nodded their heads that we had gotten everything, we moved to the blue marker. We noted ideas, suggestions, things we could try and investigate. And that went on for a short while.

The Full Picture

When we finished this process we had a pretty good view of the whole picture. We understood the components that were there, we understood what all of the possible things were that could be wrong and where they could go wrong, plus, we had a set of suggestions for what we could do about them. It was actually very easy to prioritize what we ought to do next. In fact, some of the suggestions made in blue were quite obvious choices.

At the end of the meeting, we had come to a good decision that worked well for us and we moved on.

Here is an actual first use of this technique (we used BLACK, RED, BLUE marker colors) that the team still talks about helping them not jump to conclusions.

Don’t Jump to Conclusions

So, now you know why I call the story “Hide the Blue Markers.” Drawing (literally) conclusions before you’ve really examined the problem is detrimental to your process. I highly recommend using the Three-Color Problem Solving tool when your team has a problem and you can’t figure out the entire problem, nor the entire solution.

How to Hold a Three-Color Problem Solving Session

1. Grab three colored markers: black, red and green.
2. Meet at the whiteboard (or use a large piece of paper).
3. Ask all team members to the join the meeting.

Pen Colors and Their Meaning

• The black pen is used for diagramming and identifying facts. • The red pen is used for identifying challenges or problems. • The green pen, however, is used for documenting potential solutions. This is the pen you need to hide. (In my story, “Hide the Blue Markers,” we were using blue rather than green).

The Rules:

1. Only one color may be used at a time.
2. You can not move on to the next color until everyone agrees that everything is covered by the first color.
3. You can return to a previous color if you discover you missed something.

The Process:

1. Draw in BLACK the things you know for sure. (Systems diagram, current measurements, list of assumptions, …) Keep adding to this until everyone agrees it’s accurate and reasonably complete. Keep asking, “What have we missed?” Get full consensus that all things are drawn in black.
2. Annotate this diagram with RED for challenges, concerns, or big questions. Keep adding RED until everyone agrees everything is captured. You MAY add more BLACK notes if missing information comes up. NO GREEN may be used at all!
3. Start annotating GREEN to mark ideas, solutions, and next steps. Do this until everyone agrees everything is captured.

When your diagram is done, you should have a full picture of facts, concerns and possible solutions. From here, you can use a method to sort which solutions should be addressed first. (I’ve used dot voting to great effect).

The Three-Color Problem Solving Tool is an effective technique for helping your team examine a large, complex problem. By hiding the green marker, the one meant for solutions, you will prevent your team members from jumping to conclusions, while helping them completely define and understand the problem before creating solutions.

Please let me know if this technique works for you, or if you’d like some help facilitating it’s use in your organization.

The Outbox

The outbox pattern, I believe, is missing from the Enterprise Integration Patterns book. This pattern is exactly like the local outbox that email clients have for disconnected operation.

How can producers reliably send messages when the broker/consumer is unavailable?

The producer of messages can durably store those messages in a local outbox before sending to a Message Endpoint. The durable local storage may be implemented in the Message Channel directly, especially when combined with Idempotent Messages.

This pattern is implied in the book inside the Guaranteed Messaging pattern. See the “Computer 1 Disk” inside the image.

This pattern avoids the following [The Lost Send]:

1. Producer sends a message.
2. The Message Channel is temporarily unavailable.
3. Messages will queue locally and periodically retry sending.

This pattern can be used to minimize [The Premature Send]:

1. Producer sends a message within the context of some local processing scope or transactional boundary.
2. After sending the message, but still within the same processing scope, the producer aborts and rolls back local changes.
3. The message may already have been sent and processed.
4. Either:
   1. The Producer can send another compensation message to undo actions,
   2. or the producer can first store messages in the Outbox and then at the end of the scope push or purge local messages.

After seeing several references to a blog post [1] attacking DevOps as the cause of harm. This morning I saw it again and quipped:

Nothing with a capital letter is the root cause of any problem: #Agile, #DevOps, … Look to lowercase words: trust, collab, purpose, people

— John Heintz (@jheintz) May 22, 2014

Examples of capital letter branded ideas/processes/frameworks that I’ve personally seen blamed for all manner of ills include Agile, Lean, DevOps, Six Sigma, DevOps, Flat and Hierarchical Org Structures, and Waterfall. However, all of these are simply “thinking tools” that can be used for good or evil. I reject that these tools can be the underlying cause of any of these ills.

(I don’t even blame Waterfall for many of the death marches in its wake. Waterfall is supposed to have feedback loops and we should collectively re-examine a plan that isn’t working. Waterfall isn’t ignoring those things, project leaders and management are!)

Instead, we should look towards essential aspects of human nature: trust, collaboration, purpose, autonomy, safety, thinking about the future, honesty, value, growth, learning, and any others that affect how we socially interact.

[1] The topic is DevOps and the post is here: https://www.jeffknupp.com/blog/2014/04/15/how-devops-is-killing-the-developer/ and I can certainly sympathize with some of the pains and failings written there.

Work visualizations from johnheintz

In this presentation I describe various techniques I’ve used that have been useful for helping individuals and teams see, manage, and accomplish work.

• Personal Kanban for individuals
• Team Kanban boards for team collaboration
• Multi-team coordination and Release Planning for streams of parallel work
• Program modeling to tie threads together
• Multi-Layer Roadmapping for long term collaborative planning

Please comment on other styles of visualization that have worked for you!

Agile User Stories have become the lingua franca of all agile requirements, and this simple construct is an incredibly effective way to encode and share requirements.

This one little sentence contains the answers to the most powerful questions of value creation and product management:

Who, What, Why

Here’s the story format again:

As a , I want , because .

Notice, crucially, we don’t have How. That is never part of a user story. The user doesn’t care how, and it’s premature to start specifying it in this requirement.

Finally, I want to comment that if you’ve written the Why and you haven’t rewritten the Who and the What… then I recommend you take another look.

I’m very happy to be joined by my friend Matt Roberts. Matt is a Senior Director of Software Engineering at CA Technologies and someone I respect as a true leader in addition to being a manager.

The topic for this cast is planning models, and how to arrange a plan either fundamentally in sequence or as a collaboration. This diagrams are essentially the same pictures I’ve drawn on dozens of white boards. Whether it’s work with teams struggling to get done-done within a sprint or programs struggling with cross-team dependencies, the picture is the same every time.

Please watch this short (less than 9 minute) video, share it with those who plan work for themselves or others, and comment on what you like or dislike about these ideas!

(Update: Different link… now with louder volume.)

This video explains why Agile is different and often better than a predictive or waterfall planning and execution model:

This video is Luke Hohmann and me being interviewed on the the selling and buying process for agile infrastructure and DevOps technology. The value proposition is based on speed and quality to production: