Project Envisioning with Six Stickies

Reading time ~ 5 minutes

This is an approach I developed a couple of years ago whilst working with a team in a difficult (but quite common) situation at my previous company.

Bizarrely, about a week after I started drafting this article (a long while ago now), another blogger independently described an almost identical tool and approach, I just wish I could find it.

 The Context

The Product Manager for the team I was supporting was responsible for a small portfolio of products of varying age and quality and like many Product Managers I’ve met, he had insufficient budget, time or delivery capacity for “everything”.

One product in particular was causing pain. Commitments had already been made to at least one large customer that a “radically overhauled” version of the product would be delivered to address all their reported complaints.

(You know – the kind of commitment made when you’re on a customer site and they’re tearing you a new one over a multitude of frustrations and you just want to make them happy, right?)

This commitment had been made on the spot prior to any investigation and without consulting the development team.

Sound familiar?

Did I mention how much I now enjoy working for a company that only sells software that already actually exists?

This overhaul wasn’t just being developed for that one customer. They wanted to re-launch the product as an advanced graphical web-client with full multi-user query/read/write/print features. (The original was a read-only system)

When the team started to explore the “product”, they realized just how customized the customer’s version was and how unloved, limited and just plain sick the original was.

  • The UI sucked
  • The underlying code was the result of years of consulting engagements strapped together
  • Consultants has to wire the internals together to make it a running product (Out-of-the-box it didn’t work)

It was basically a collection of disparate tools in a very jumbled toolbox.

Despite all of its ugliness, many customers were actually using it. It was typically thrown in free with most enterprise licenses and was far easier and cheaper to roll out to the majority of users than the seriously advanced thick-client CAD-like system.

The team had their work cut out for them…

All they had to start from was the usual laundry list of features – 1-liners. Fortunately this was enough to be clear already that they were never going to deliver “everything” (or possibly anything) on time.

Fortunately their Product Manager was a great guy. Masses of domain and customer knowledge, supportive, collaborative, made time to be available regularly despite being on the far side of the world and experienced enough with software development to know when to listen to his technical team.

The team highlighted the impending scope & schedule disaster as soon as it reached their shores and within a week the Product Manager was in the UK ready to hit the reset button.

The Goal

We needed to re-frame the project, determine what scope could be cut or postponed, what could be delivered sooner, what was a priority and how the team would approach delivery.

The Process

We arranged 3 days of workshops with the product manager and full development team in the room together.


Before we dived into details, we worked with the product manager to give us the real story on why the product existed from our business perspective:

  • What revenue did it provide?
  • How else did it support our sales?
  • What was the longer term direction for the product?

This was restricted to 1 sticky per question.

We then captured (on 2 stickies) what the users normally did with it – what were the most commonly used functions and what was the frequency and duration of these activities?


To start things out with the best possible foundation, we spent the first morning on “Envisioning” (or perhaps “Re-Visioning”).

I’m not convinced the Product Manager was particularly sold on the value of the session but he was willing to play ball – he trusted the team and I to do the right thing. (and after all this was just 2 hours of warming up for 3 days of workshops).

As we started it became apparent from team conversations that they were struggling to establish exactly what the product they were working on was really expected to do, why and who for.  (pretty fundamental stuff)

I led the team through a series of facilitated discussions around 6 areas of the project/product. The order we approached these and the constraints used for documenting them were a critical part of the process. We constrained the documentation to the smallest, simplest thing that could possibly work. One sticky per conversation theme.envisioning with six stickies

  • Needs – What top priority business needs is the product/process addressing?
  • Wants – What do the end users want from the product/process , what specific tasks are they trying to achieve?
  • Business Process – What business process are we aiming to model, support or improve?
  • Scope – What’s the explicit planned scope (features & fixes)  for this release? (limiting scope to a single sticky is a great way of starting out small!)
  • Immediate Goals – What is the top priority single goal of this particular project/release?
  • First User – Who will be the first actual consumer of what we’re delivering and when do they need it?


We knew the product manager already had an idea of what scope he wanted and that we were going to need some kind of polite reset conversation.

Our approach was to collaboratively define what the “minimum marketable feature set” (MMF)** for this release would be.

**At this company, MMF was loosely defined as “the bare minimum set of functionality that would be added/improved in order to deliver incremental customer value and be worth announcing to the market.”

Through scope exploration, we established the team needed to deliver a lot to make the product viable. We were however able to trim a number of very high complexity/risk items in order to bring things in sooner. Better still we’d had a powerful scoping conversation with the product manager to set clear expectations on what would be highly unlikely to be delivered and had sequentially prioritized every other feature in his original release wish list.

Putting each item on a sticky, and having an explicit MMF marker was a great way of visually defining the backlog. (This also kept the number of items in the backlog small enough to summarise quickly)


The final piece of the puzzle…

Having defined context, scope and vision for the release, we defined what “acceptance” of a new release would entail for the end user. The power of this was that we could correlate current and later scoping conversations around the fundamental user acceptance expectations without our Product Manager getting emotionally attached to the scope we’d originally talked through. Once again, we constrained the acceptance to keep things small and simple. (one sticky was plenty) .

What next?

After this initial few hours, the team spend the remaining 2 and a half days working hard with the product manager to flesh out all the top priority features/epics in sufficient detail that they could start de-risking and developing by the end of the week. They didn’t need my help for those bits :)


Note, the quality of writing on this article may not be up to my usual standards.  This has been blocking my backlog for quite some time. I needed to get the story written from my rather hazy memory and move on more rapidly than normal. I hope however that it’s still valuable.

Why You Should Stick To Using Whiteboards & Stickies

Reading time ~ 4 minutes

If you aim to improve, inspect and adapt on a frequent basis in a highly unconstrained way, stick to a whiteboard (as large as possible) and stickies (and possibly scissors, tape, card, paper, pens – did I mention that many Agile coaches I’ve met have an addiction to stationary that stems back to their childhood :)). Your process will adapt to the project significantly faster with a manual board.

As an example, here’s the original board used on my current project (it’s now cleared down as we migrated to a better space) :

a blank scrum board
(Thanks to Andrzej for the rather disturbing portrait)

 The board was too small and constrained (much like many electronic tools) so we switched to something better. We reused the board layout and approach from a previous project (see 5S your Scrum board) as a kick-start but less than a week later we had already moved forward significantly from where we’d started. Our needs on this project were different enough that we had to adapt.

Here’s what the current board looks like this week:

a highly adapted scrum/kanban board
(Thanks to Ellie for the donated parrot)

 The mass of stickies across the bottom of the board is where we cut scope for this sprint as the result of an over-commitment. This was spotted as soon as we migrated to this board and I started plotting additional information for the team around the edges.

Admittedly what we have here could potentially be implemented electronically as a board and a series of “widgets” but that needs development skills and time – this would slow down our speed of adapting.

In our example, adding avatars was a 15 minute job with scissors & tape, adding a capacity planning check took 2 minutes and adding new charts and graphs took 10 minutes. Better still – an unplanned adjustment – when we have a success story from our users, one of the team will bring the evidence along and tag it to the board in whatever format they wish.

There’s some further changes needed to our process this week. One of the horizontal streams of work is a (roughly) repetitive series of activities so we’re going to start tracking cycle time on these and moving to a Kanban model as we need to start setting expectations to our users for these areas. In parallel, the less predictable work will be continuing Scrum-style for the development team. We’ll be ensuring the board captures these stats for us to see every day.

As soon as you start using electronic tools, there’s an immediate speed barrier to the changes you want to make plus there’s often the constraint of a small screen (or investment in a large one), how to add related information in meaningful ways without underlying data model support, user experience, data entry and the ability for non-technical team members (my current team is 50% sales & marketing staff) to make changes.

Don’t get me wrong, when you have a globally distributed team, you’ll almost certainly need an electronic tool as a single point of truth but it’s just not tactile or flexible enough to support the level of interaction and adjustment that a constantly evolving project and process needs. Many companies adopting electronic tools push for standardisation to keep processes consistent, costs under control and sustain support for reporting aggregation. This really stifles making adjustments to the process to suit project and environment context.

I’m not entirely down on electronic tools. I’m actually quite a fan of Trello at the moment and use this for sharing our bigger picture with the spectrum of stakeholders we have around the business that cannot be co-located. At least it’s a tool aimed at users, (rather than many commercial electronic boards whose capabilities tend to target management reporting instead) however for now Trello is limited to swimlanes, a constrained card format and the need for a screen. It’s not quite tactile or ubiquitous enough. Extending it requires time, technical skills and screen real estate rather than simply a process gap and a creative team member.

In my time at a very large US corporation we did a great job with the constraints we had. We used giant smart boards with virtual card walls, high-spec videoconferencing and large TV screens. At the time it really was state-of-the-art  stuff but it still limited our visual management capabilities. We only ever really had a shared basic card wall (the reporting and metrics weren’t particularly visible to the teams). All the other peripheral information you can get from a great board during your standups wasn’t visible.

The teams actually developed and maintained physical boards in each location and ended up using the electronic tools as a synchronization point.

Whilst we could virtually move cards around on a giant touch-screen, changing information on the cards themselves required reverting to a keyboard, detaching from ongoing conversations and manually editing within the tracking tool. It worked but it really was a compromise.

Contrast this to our current board – if something needs adding or updating, the active conversation continues whilst a team member grabs a pen and starts writing. If our process changes, we update the board format the same day.

I just had a passing chat with my colleague David (another of our DevOps team) about electronic vs physical boards. He summed it up brilliantly; “I don’t know why… …but it’s just not the same”.

We also tailed off into the value of an entirely co-located team. A rarity for many these days but a real game-changer in the performance of your teams – I’ll cover this another day.

So in summary, even where you have distributed teams, work with a physical board for as long as possible to allow your processes to adapt and develop to the context and project around you. When you start using electronic tools you’ll find the pace of process improvement will significantly decrease.

If you’re hunting for more whiteboard examples, you may also want to take a look at “A Year of Whiteboard Evolution” and “5S Your Scrum Board”.

Telling Vs Coaching

Reading time ~ 5 minutes

Before I start, a thanks to @fatherjack for being the first person to request a topic from the backlog. If any of you want more of the same, just shout!

The Story

Up to a certain point in my career, my success was defined largely due to my ability to find creative and often tangential solutions to difficult problems. For anyone that’s completed a Belbin assessment in the past, I’m mostly classified as a “plant“. My major strength has changed very little in 15 years although my complementary strengths and views have all shifted a lot (I might discuss this in more depth another time).

With this strength in mind, I found that when working with others I often jumped past a lot of the detail and rapidly offered solutions and alternatives. The sheer volume of options I can provide means many did stick and work. However, using this approach risked those seeking support or assistance becoming dependent on my problem-solving rather than developing knowledge and learning to solve problems themselves.

When I became responsible for other staff I recognised that many of the strengths that got me to that point were not appropriate to leading or coaching others.

I spent a little time learning basic coaching skills, the GROW model, coaching through questioning and other simple tips. Pat Kua also steered me toward the Dreyfus model of skill acquisition (which in hindsight for me is an important missing link for coaching) but I found that my instinct to solve and help often overrode my learned coaching practices. Coaching others is hard! (or at least it is when you’re normally a problem solver)

Having led a number of teams, managed a full spectrum of technical staff, implemented organizational change programs and most recently being responsible for a company-wide community of practitioners, my coaching skills have become more and more critical to my role. Coaching Dojos have helped significantly – using coaching tools repeatedly as a deliberate practice but there’s still something not quite right. I still have those problem-solving skills going to waste, there must be something I can do with them.

The Lesson

So here’s the thing. Just because you’re coaching doesn’t mean you should only ask questions, it doesn’t mean you shouldn’t direct or tell and it doesn’t mean you shouldn’t get to have the fun of solving problems for (or with) others. You just need to understand more clearly when it’s appropriate to do so and when it’s not.

Learn to spot when you’re “telling” when you should be “coaching” and vice-versa. This can be really tricky to achieve when you have all the answers and ideas.

Fortunately for me, my current employer really invests in their staff. All managers are trained and encouraged in doing just this…

The Tools

The coaching and leadership model we use is “Situational Leadership” – in particular “SLII”. (here’s the explanation of  why it’s II)

I can’t cover the full depth of the model in a blog but here’s the basic conceptual framework – this should be plenty to help you recognise when to coach and when to “tell”.

There’s a direct correlation between the style of leadership you (as a coach/leader/mentor/manager/team member/person) use and the development level of the coachee/seeker/mentee/staff/team member/person/team.

Important note – this applies just as much when leading or coaching teams, not just individuals.

We model this as four “Development” levels (D1-D4) and 4 corresponding “Styles” (S1-S4) This might seem a bit jargon-y but putting this into practice really does work (see the diagram below).

The suggested style to use is based on a composite of the motivation of the individual and their competency level.

As an analogy, consider learning to drive a car. Most new drivers are really keen, think this is going to be easy and can’t wait to be out under their own steam (Level D1). As an instructor, you need to let this play out, give them the space to try and succeed (or more often fail) but you do need to be quite prescriptive in what they do for their own safety (and that of others) (Style S1). When things get hard and motivation wanes (Level D2), you continue to tell them what to do but in a coaching style (S2). As competency develops, the trainee becomes more competent (D3) and your style will need to follow. Eventually they will (hopefully) become self-sufficient (D4).

Our regular trainer actually talks us through a lot more than the textbook model. The diagram below is my interpretation of the model with the additional tips we’ve learned.

SLII on a page

Extended representation of Situational Leadership II

There’s a few really important points that help us use this as a thinking tool.

  1. The model applies to each specific task. If a person has never performed that specific task before, re-assess their development level. Some complementary skills may apply but don’t assume competence in one area translates directly to the task at hand.
  2. Watch for transitions in motivation as a guide to levels of support to offer. When individual motivation is low, the coach/leader must be more supportive – more guiding and questioning. When motivation is high, less support is needed.
  3. When individual competency in the specific task is low, the coach/leader should be making the decisions on the course of action (even if leading through questioning). When individual competency is high, the coachee makes the decisions but may still occasionally want to validate these with the coach.
  4. A mismatch between leadership style and development level can be harmful. The further apart the difference, the more dissonant the leadership style will be.


There are a couple of important extensions to the model that need consideration.

In many work environments, there are times when a person may have high expertise in an area but not be motivated to actually work in it. Similarly, someone who reached a high level of competence in an area but is ignored may lose motivation. In these instances, they have actually regressed around the model (from D4 to D3). Your leadership style needs to change!

In other situations, you may have someone with little or no motivation to work on a new task and little or no competency. Rather than starting at development level 1 (D1), you’re actually starting at D2. You need to work with the other person to build motivation and competence. At this point they either develop to “D3” or first to “D1” and then back through the cycle.

And Finally

Like all frameworks, this is a tool only. Use with caution. The more you understand how to use this, the better you’ll manage with it. If you’re interested, get trained properly, don’t just rely on what I’ve presented here.


Portrait Vs Landscape

Reading time ~ 2 minutes

I’ve been very busy for the last few months in my new job but will be presenting at a couple of conferences in the Summer. In the meantime, here’s a short thought to share…

When writing, people think in paper shape.

So why is it all our whiteboards are mounted in landscape?

Hang them up them portrait-style and panel them along a wall.

Just try it – portrait mounted whiteboards make a much better tool.

In my time working for a large multinational I led much of the design and layout work for redeveloping the office space at one of our sites to support agile teams. As part of this I reviewed and improved our available wall and whiteboard space.

As an experiment in one of the boardroom style rooms I arrange to have 3 large whiteboards mounted portrait style as 3 connected panels.  They proved significantly more effective than normal boards and became some of the most heavily-used whiteboards in the building. As a result I replicated the same setup across as many other rooms as would accommodate them.

I can’t tell you why others liked them but from my own experience I found working in multiple portrait-format significantly easier than landscape. It allowed focus areas and footnotes in a way that a pair of normal whiteboards in the same space didn’t. This helped me arrange thoughts more cohesively with a natural information flow that landscape boards didn’t offer. They also worked as natural extra-large swim lanes during workshops and allowed multiple team members to work side-by-side on related aspects of a workshop.

It’s hard to remember all the benefits on a Friday afternoon. They just “felt” nicer, different, better.

Give this a try and share your experiences here.


Where’s My Tools?

Reading time ~ 4 minutes


The most effective tool in the box

Most of the really big successes and game-changers I’ve seen in my career have been initiated through individuals seeing a problem and fixing it themselves rather than waiting for others. 

If you need something done that isn’t already happening, nobody else is going do it for you.

Here’s 4 lessons learned from adopting TDD…

It takes time & effort to get TDD into place

You will have to sacrifice “new code” time in the short term. From my experience, time is probably the biggest barrier to successfully introducing TDD on most teams (closely followed by motivation & accountability). Seeing the pay-off on the other side is notoriously hard to when you’re not there – either starting out or sitting at the bottom of the change curve.

If you’re coaching teams, sometimes you might just need to say “Trust me, I know what I’m doing”

“It can’t be unit-tested”

When you or someone else makes this statement they probably mean one or more of the following:

  • “I don’t believe I have the time to make this testable”
  • “Nobody has provided the infrastructure/harness/test data for me”
  • “I don’t know how to unit test this” (and need some help to figure it out)
  • “We have some architectural impediment to resolve in order to achieve this”

From these statements, which do you think is least common?

Break this cycle by encouraging accountability for making code testable. 

This doesn’t just mean the product code it includes taking ownership of your testing tools and abilities as well.

If you’re struggling…

There’s 2 options for you; “abdicate” or “own”

Option 1 – Abdicate responsibility.

  •  You’ll set the tone for your whole team. The next time someone hits the same problem, the cycle will repeat.
  •  At best, someone better than you may eventually address the issue. (And I hope they make you feel mediocre or inferior).
  •  At worst you may find them saying that you didn’t provide the solution for them.

The “best” case is highly unlikely to happen during your current project – maybe even the one after.  Just think how much testing debt can build up over the life of a single project. We should be avoiding that, right?

Someone has to break the cycle.  If you’re facing pain, why aren’t you responsible for fixing it?

Option 2 – Take ownership of the problem yourself

Great! You’ve recognized that your accountability is part of the problem.

Nobody else will do this stuff for you!

  • Establish a Personal strategy for implementing TDD – how are YOU going to solve the problem?
  •  The teams and individuals I’ve seen that are successful with TDD have all got there by taking a personal responsibility to do so.

Just Do It

Here’s some suggested steps to get going – you can either do the first few alone or as part of a team.

(If there’s an accountability gap in your group you’ll probably need to start alone)

Round 1

1. Get a unit test harness and environment in place – there’s plenty online but write one yourself for starters if you have to!

2. If you have a database, break that dependency and channel it through something replaceable.

3. Write your first round of tests and see what hurts – now resolve those pains.

Limit the time spent on this first cycle and determine whether you should ask for time in advance or for forgiveness later – it’ll depend on your local context.

Round 2

4. Educate & support your team on what you’ve provided so far.

5. Get other team members to write their own round of unit tests (treat it “as  an experiment” if there’s concerns over the effort required). See what hurts and resolve those pains.

6. Encourage and develop shared long-term ownership of the test harness, test data, stubs and mocks (if used).

Remember you’re setting the tone. If someone needs something that isn’t available, pair up, help them provide it and share the results with the team. Don’t leave them alone but don’t do it for them either.

Round 3

7. Repeat round 2 during development until writing tests is fast, easy and natural. (Don’t give up too soon – this is hard work and takes time!)

8. Capture any “wins” and “losses” during this cycle – what benefits are you seeing and what new pains are coming through?

9. Review the wins & losses. Decide what to do about the losses and how to promote the wins up the management chain and across the team. For example either publicise as you go or use as fuel for your retrospectives.

Think about the positive impact that little bit of extra effort and ownership has on you and your team in leading by example – doing a great job that others will want to share, not just a good job.

Abdication or accountability is a personal choice but it affects everyone around you. What are you doing to help your team?