Category Archives: Project Management

Recovering The Ability to Self-Organize

Posted on by
Reply
Reading time ~ 9 minutes

At the beginning of this year the team I’ve been supporting hit a wall. After a deeply troubled project last year they’d started researching a “new” feature in December with a plan to get rolling in January.

After the holiday break, a couple of weeks into January we had a near-mutiny and hit the reset button.

Things are now back on track and working in a radically different way but here’s the story.

Timeline

Early August – Halfway through a deeply troubled “rewrite” project. One of the paired project managers left and I was asked to support the remaining PM.

Mid August – Working with the remaining PM we visualised the entire scope of the UI on the team’s whiteboard and immediately excluded all dialogs and rarely used parts of the UI from the project. Essentially halving the scope of work

Late August – The second PM moved back to a development role elsewhere and I joined the team full-time. I started digging deeper into the scope and data. After reconciling the stories the team had on the wall with those in the electronic backlog we discovered as much additional scope as had been removed 2 weeks earlier – literally “hiding in the walls”.

Early September – Having reviewed the state of the project I talked to our engineering manager and product owner and said “this project is f***ed, do you want to kill it?”  The response was “No, we believe this is the most important and valuable thing we can be doing right now.”

Late September – After the first attempts at recovery still hadn’t achieved enough I re-asked the same question – the reply was the same

Mid-October – And again. All the while the team are still working away trying to deliver.

Late October – Our Product Manager (not the Product Owner) finally decided the project needed a reset. The forecasts had finally tipped him over the edge and the total cost wasn’t acceptable. (This coincided with our push to get an Alpha release into the hands of users for concrete feedback.)

Mid-November – We shipped an alpha release to validate our new UI technology and started building plans and options for the finished product release.

Mid-November – We sought input from the team on options on how to exit the project gracefully. (there’s an entire article on this experience waiting to be written)

End November – We killed the project and I started on building a plan to move on – leaving the team with a new manager and have them successfully working on a new release by the end of January

December – A general lull. Recovery time. We had Down-tools week, holiday period, some bug fixing and a couple of the team started investigating the next feature. My replacement joined the team and we started on a gentle 2-3 month handover.

January – When the team returned from holidays we decided to start on the “new” feature (actually finishing a feature started 2 years earlier and never finished). One of my team had the task of reviewing current behaviour and delivering a demo to the team. This was eye-opening. The scope that had been implied from PO conversations didn’t address the fact that the feature was barely usable.

Mid-January – Over the 3 weeks this new feature had started (as a “3 month” project) scope had ballooned again to include rewriting a fundamental aspect of how data would be stored.

Mid-January – Team mutiny (During a retrospective). The feedback was honest and painful but most importantly it was actionable and had cemented the worries I already had – things were broken again and we needed to hit the reset button a second time. Although he was already on board, this was not the time to hand over to my replacement.

End January – Reset time. Feedback in hand, we had to act fast. I redesigned the entire way work flowed into and through the team, gave some direct and difficult feedback to our new product manager, engaged him in the reset and briefed the team on changes.

Mid February – With the reset well under way and team morale already on the increase I could safely hand ownership over without feeling guilty about the state of the project.

But what went wrong?

There were a catalogue of problems raised by the team. Here’ the points the team raised…

  • We talk about “quick wins” but never do them
  • Poor control of scope for the last 2 major projects
  • A team of 10 with 4 managers is consistently underperforming another team of 3 with no management – why is that?
  • The project backlog is only technical tasks, not user stories
  • We still don’t know what the focus of the next product version is
  • We’re deeply worried about the quality of the next feature (based on current scope)
  • We’re not bought into the new feature work – we’re repeatedly told users don’t need it and it’s just a checkbox
  • We want to be more reactive to support requests
  • We’re not delivering quickly to users or responding to their feedback
  • We want to feel proud of the product and what we’re delivering
  • The work isn’t structured to be delivered iteratively
  • There’s a complete lack of user perspective on upcoming work
  • Despite 4 managers, we have no leadership.

Brutal – but completely valid

For the last 6-12 months we’d been entirely focused on helping the team deliver what the business had been asking for. This was a good team. Sure they’d had a lot of technical problems on the previous project but the new one should have been different.

Both projects started with a technical requirement – rewrite X, finish Y.

This built some odd behaviour into the team. They were at the mercy of the backlog. They couldn’t self-organize, they couldn’t deliver iteratively, they couldn’t manage scope, they couldn’t even decide the best solution for our users. Everything was pre-defined.

I hadn’t spotted the problem for months. I’d been so focused on delivery of what we’d been given that I failed to identify the biggest issue was the incoming work itself!

After killing this second project, the next feature on the list was called “Implement Z” – where Z was a half-written product (again).

I now have two “stop” phrases added to my list of dangerous projects;

  • “it’s just…”
  • “3 months”

These are gross generalisation phrases much like “finish X” or “Implement Z”, they’re the smell of unbounded requirements. Taking them at face-value and accepting work into the team is a recipe for failure.  Both failed features started out on the same two flawed premises but beyond that, take another look at the list of issues raised by the team.

We’d let the team down. We were managing poorly, not leading and the features were not user-facing. They might once have been but not by the time they reached the team.

How do things look now?

First we clarified who in the management team was responsible for what. Who was “in charge” from the business, who was “supporting” and who was “managing”.

Then we restructured our view and approach to incoming work into 4 balanced streams with clear constraints, policies and ownership for each.
This is probably best explained using the presentation I ran with the team…

We asked the team during the presentation who would be willing to take on the role of “feature lead” for upcoming features. Every hand in the room went up!

We’re just reaching the 2 month checkpoint and things are significantly better.

  • The fixes and achievable streams are generally running smoothly and shipping frequent product updates.
  • The team have learned what sizes of work and level of understanding do/don’t work well as “achievable” items.
  • The feature lead role and relationship with the business is successfully flushing out real user needs.
  • The analysis/discovery stream took longer than the team were hoping for but development of the first major feature off the back of the research work has just started.
  • The team completed their first user story mapping session to plan a genuinely iterative set of potential releases.
  • The first iteration of a new major feature is (optimistically) planned to finish in 2 sprints.
  • At any point after the initial release we could stop and move on to something else.
  • After the first release the team will have the ability to run UX sessions, gather feedback and adjust plans based on real user responses.
  • The team’s new project manager has been able to take his sabbatical and leave the running of the project to the team for 6 weeks! (with occasional check-ins and support from me)

Better still, Nick (my successor) has been gathering measurable feedback from the team since we started the reset. Here’s the data.

team_happiness

From Architectural Decoupling to a Complete Rewrite

For a lesson in what not to do, here’s the gory detail on the first project that was killed.

The project goal was to “make it significantly easier to change the UI in future” – delivering value to internal stakeholders in the form of efficiency and quality savings.

This was conceived as “3 month” project back in April but ran into trouble over the summer. The PMs involved in the start of the project had assembled enough project data to establish “This could take anything up to another 1-2 years to complete”.

The project scope had changed from architectural decoupling to a an internal technology refresh and from a technology refresh to a pilot for a new (unfinished) product style guide, a complete UI replacement, implementing a set of untried technologies with a team that had little or no experience of using those technologies and improving the user experience of the UI along the way.

Essentially they were going for a complete unbounded UI rewrite.

The initial idea was to introduce the new UI as an MVP alongside the old UI with limited functionality and support for end-to-end workflows.

Somewhere in the course of time the “end-to-end” part of this had been lost.

By the time I joined, the implementation approach had become replacing whole tabs of the UI, developing multiple tabs in parallel to improve and validate code reuse and completing these widget-by-widget rather than by workflow.

On the surface, technically this seemed sensible. It reduced rework and kept architectural quality high.

I made things worse by pointing out that an MVP wasn’t viable for a product whose broad set of features were in daily use by over 1,000 customers. Thus it became a “like for like” replacement project – of which so many end up doomed by a big bang approach and repeated delays as scope is discovered!

Shipping a new release with significantly cut-down functionality is a big gamble and usually only one you can take if you have something else of significant value to offer to the customer.

We didn’t.

In fact, the most commonly requested feature from our customers – a rewrite of some particularly nasty functionality to support additional use cases and improve existing ones – wasn’t being worked on. We’d actually decided to remove the poorer version of that feature and not replace it until a future release.

In hindsight and from the outside this all seemed a bit nuts.

Before I joined the team, in my oversight role across all projects in the company I was aware of a nagging worry about the state of the project but I couldn’t put my finger on why. The reports and whiteboards seemed “ok” or “meh” but not fundamentally bad.

This is now another warning sign to us when reviewing project status. Month after month of “ok” (not “good”) status across an entire series of checks is a smell (see “Yellow is the new Green” )

I repeatedly asked about any deadlines, due dates and what was going on and received reassurance that everything was under control but there weren’t any real deadlines so everything was still “OK”.

As “Head of Project Management” I have to admit it’s pretty embarrassing to not have tackled this wave of trouble. I and others in the leadership teams saw it coming but trusted the feedback we were seeing. We continued to treat everyone as knowing what needed to be done and safe to be able to do so (“S4” in Situational Leadership terms) when actually they were in trouble and needed help. (“D2” level).

Things came to a head at the beginning of August with the project on the rocks, one PM left and another wanted to go back to a development role.

Determined not to face a “Netscape project” I joined the team to get things back on an even keel. Until now, I’d never had a project I couldn’t salvage quickly – usually in under a couple of weeks. This one was definitely much more of a challenge.

Fortunately the team had backlog and historic size & velocity data so we at least had a baseline to work from (the outgoing PM pointed out that the estimates were wildly inconsistent and hard to trust).

Step 1 – We visualised the entire scope of the UI and discovered some 30+ dialogues and little-used screens that could be postponed. We took a scythe to the scope listed in the backlog based on this visualisation and managed to improve the forecast delivery dates.

Step 2 – I was unhappy that the partial backlog on the wall didn’t offer easy traceability to the full digital backlog so I tagged up all the stories and reconciled the wall with the backlog in a spreadsheet and discovered another 50% of scope hiding in the walls.

At this point the project had ballooned beyond all recognition of the original. We’d dropped into sunk costs and the approach to delivery had removed our ability to deliver iteratively.

Every sprint that passed uncovered more technical problems and more missed scope. Some major performance issues with the new technology tripped the team up for weeks and even after shutting the project down, taking what was delivered as an Alpha in November, salvaging the most complete parts and getting it shippable involved 3 more months of stabilising the technology – insanity!

Fortunately, the salvaged tech finally paid off. After releasing the main work, the team were able to deliver a series of small enhancements near weekly for the next month.

They’re through the worst now and I’m moving onto another team.

The team did a great job staying sane in spite of the craziness around them and both they and “management” have learned a lot . What we have in place now goes beyond preventing a repeat of all these problems – it resets the whole way they work to focus on customer needs, customer problems and customer value. It gives them space and freedom to self-organise whilst balancing the needs of the business when necessary.

I’m sad it took nearly 9 months to get here but glad we’re finally on the right track.

We’re also using the lessons from here to ensure other projects that threaten a rewrite focus on incrementally delivering end user value by only rewriting areas that directly improve a team’s ability to deliver on the next customer-facing changes and features.

Update – 24th April 2015:

I had a chat with one of the team who reviewed this for me. Other than some tweaks to the early timeline he mentioned that as of a couple of weeks ago the team have now actually deleted about 2/3 of the UI code that was developed but never finished. That’s a really brave move given the effort they all put if but they found it was holding them back in adding new features (using the new UI technology in smaller increments).

He also mentioned that the first new feature to run through the updated team analysis process is flying – a way better start than the last!

They’re is still a great team and have really turned the corner by the looks of things now.

On Story Points and Distributions

Posted on by
Reply
Reading time ~ 5 minutes

If you’ve been reading my posts for a long while, you might remember this curve in relation to fixing bugs.right-skewed beta distribution

Today I’m resurrecting it for other reasons. First of all I’ll admit I used to be a bit of an estimation geek. I loved the subject. (really!)

Last summer I attended my first ever #noEstimates session at Agile 2014. What I heard made complete sense to me and there are a few teams here that have stopped estimating (they still measure and forecast throughput) but I still see value in trying to estimate. I’ve seen enough examples over the last decade where work is traded out because a team cannot estimate the effort of the previous.

I love Arlo Belshee’s concept of Naked Planning – in that if you remove all estimation information and focus purely on what the most valuable and important thing is, you’ll do the most valuable and important thing.

The trouble is, in many commercial product situations, it’s not actually that clear what the most valuable thing really is – and value generally has a trade-off of cost. (Or at least “how much am I willing to spend on this”).

I also like Chris Matt’s Options thinking alternative to estimates – “How much are you willing to spend to get a better understanding of this”. This ties in with a fundamental part of estimation theory in that there is a trade-off (and decreasing value) in spending additional time understanding a problem in order to better estimate the outcome.

Finally, whilst many teams I’ve worked with have used story point estimates for stories and hour estimates for tasks, we don’t go in blind. We have triangulation and reference points from prior work wherever possible.

I used to run half-day training courses on software estimation (and still see that course as valuable – primarily because the theory is transferrable). These days, if I have a team that have never had a real conversation about what estimates are, why do them and how I trim down that half-day content into about 15-30 minutes on the most important bits for story and task estimation.

I’ve been using the same explanations on estimation for about 7 years now and although some of my assertions on why we estimate are finally wavering, the information on how is still useful – and – as far as I know, nobody else has explained it this way.

Back in 2011 I wrote an article on Swimlane Sizing that was subsequently referenced and made popular by Alexey Krivitsky in his Scrum Simulation With Lego Bricks paper.

What I want to share today is how all this hangs together based on a very simple concept from the 1950’s.

The PERT technique came from the Polaris missile project and in my very simple terms is essentially a collection of tools and techniques based around probability distribution.

When examining the probability of completing any task there’s a great rule of thumb to start with:

There’s a limit to how well things can go but no limit to how bad they could get!

With this thinking in mind, essentially the completion time and/or effort for a given task can be represented by a probability distribution. A right-skewed beta distribution.

Furthermore, when adding a series of these together, you have a collection of averages. (cue a #noEstimates discussion).

If you ask someone to estimate how long a bug will take to fix, without historic data you’ll get a “how long is a piece of string” type answer. Everyone remembers the big statistical outliers but if you strip these away, you can forecast quite accurately with about 95% confidence. (This is one of the foundations behind using data for service level agreements in Kanban).

Some items will take longer than average, some will be faster but based on those averages, you can get a “good enough” idea on durations.

With PERT, this beta distribution is simplified further to 3 points – “optimistic”, “most likely” and “pessimistic”. The math is simple but at least for today’s point, not important.

Here’s the bits I care about.

PERT summary

Now here’s a neat thing (and the point of this post).

With the introduction of story points, we’ve moved away from the amazing power of  3-point range estimation back to single points.

Once you’re in the realm of single point estimates, people start seeing a falsely implied precision. Unless you’ve actually had training on use of story points (many senior managers probably won’t have done) then you’ll start building all those same human inferences that used to occur with estimates like “It’ll take about 2 weeks”.

When we hear “2 weeks”, we leap to a precise assumption and start making commitments based on that. In range estimation we’d say It’ll take 1 to 4 weeks and in PERT we’d say, “Optimistically it’ll take a week, most likely 2 and pessimistically, 4. Therefore we’ll plan on 2 but offer a contingency of up to a further 2 weeks.”

(Of course in reality, wishful hearing means you might still end up with a 1 or 2 week commitment but hopefully the theory is making sense).

It’s also worth examining the size of the gaps between optimistic -> most likely and most-likely -> pessimistic (in particular, the latter of these 2). These offer a powerful window into the relative levels of risk and uncertainty.

By moving back to single point estimates – at least at the single story level, this starts feeling a lot like precise and accurate commitments**. Our knee-jerk reaction may then be to avoid providing estimates again.

But here’s the missing link…

Every story point estimate is in fact a REPRESENTATION of a range estimate!

We can take this thinking even further…

The greater a story point estimate, the less precise it is.

Obvious right? Let’s take one more step…

 If a story point estimate is a representation of a range then a larger number implies a WIDER range.

Let’s take that back to the swimlane sizing diagram and (crudely) overlay some beta distributions…

swimlane-distributions

Look carefully at how those ranges fall.

  • Some 2 point stories take as long as a 3 point story.
  • Some 5 point stories may be the size of 3 point stories, in rare cases, others may end up being 13 or even 20 points.
  • And some 13 point stories may go off the scale.

And that’s all entirely acceptable!

On average a 5-point story will take X amount of effort.

That’s enough to forecast and that’s enough to start building commitments and service level agreements around (should you need to).

So…

Time to start thinking about what distributions your story point estimates are.

If you’re getting wild variation, how might you capture some useful (but lightweight) data to help you, your team and your management understand and improve?

You might be in a fortunate place where you simply don’t need to produce estimates at all. That’s great. I’d assert there’s a lot to learn by simply trying to estimate even if you don’t use the results for anything but for the majority of us that need to do at least some sane forecasting, this thinking might just make estimation a bit safer and a bit more scientific again.

If you’re interested in more on this, take a look at the human side of estimation in “Seeing the Value in Task Estimates”.

**As an aside, a while ago, the SCRUM guide was updated and replaced “commitment” with “forecast”. That’s a big change and tricky to retrain into those that saw SCRUM as the answer to their predictability problems. (Many managers needed guarantees!) For those of you facing continuing problems here, it’s worth gathering and reviewing story data so you can build service level agreements with known levels of confidence as an alternative.

200 Questions to help bridge the Product Owner divide

Posted on by
1
Reading time ~ 5 minutes

A year or two before I first started writing publicly, I read an interesting, varied and quite long essay by Jeff Patton on the Product Owner role in Agile development (particularly Scrum)
http://www.agileproductdesign.com/blog/2009/product_owner_and_problem_shaped_hole.html

Whilst there are some areas I agreed with, the discussion on “heroics” was an area that left me cold. In my opinion, great software teams don’t have space for individual heroics and (in my opinion again) the sustainable pace ethos generally also plays down team heroics (but that’s a debate for another time).

There was a comment in Jeff’s article that resonated with me that I made a note of at the time. Years later it’s still highly relevant and I wanted to re-raise it this week in the context of recent challenges I’ve been facing.

“For the product you’re working on right now, how will your company benefit after the product has shipped? If you understand how, do others?”

Although this question was aimed at Product Owners it’s something I’d ask all development team members to really think hard about.

Now go further. Are you solving technical problems and a series of requirements to ship a product release or do you really understand the value of the release you’re working on, its reason for being developed and its impact on specific customers, the market or the company?

How many times have you or your team examined the reason for delivering a release with a specific set of features and understood their aim, questioned the backlog and vision and better still, properly understood what you’re trying to deliver in terms of solving the needs of the user?

When I say “understood”, I mean really understood – not just prettied up to follow one or another user story format.

Consider this an opportunity to pause for thought.

Back in 2013 I attended a Retrospective Facilitators Gathering and was introduced to an amazing concept over lunch by Willem Larsen that he described as “200 Questions”. He explained an idea that comes from animal tracking.

When tracking an animal you explore the environment in a way that an every day person doesn’t even consider. You look at every twig, leaf and blade of grass and ask questions of how it came to be in its given state (and why) in order to determine if you’re on the right path.

My translation of this to my own work is to try and develop a genuine and deep curiosity for every item you look at. (Even if you don’t have time to answer all your questions)

At the same lunch, we tried it with a salt cellar

How many people have handled it since it was made?

Who designed it?

What inspired the design?

What’s it made of?

Where did the salt come from?

What process did the salt go through?

…

(we lost count of how many questions we asked)

Applying this same healthy curiosity to incoming product features or requests is incredibly powerful.

You know things are wrong when every request coming in is essentially a specific solution being proposed.

And you know how translating feature requests back to user stories in anything except a shopping cart or finance trading application seems to be really poorly explained in the agile community?

Try this as an experiment for getting unstuck…

  • Set yourself a target of asking 200 questions about the next big item coming in to your team.
  • Try different “lenses” for asking the questions (much like 6 thinking hats)
    • The “User” lens
    • The “Investment” lens
    • The “Functional” lens
    • The “Market” lens
  • What questions logically follow from those first “level 0” questions?
  • Decide which of those are important and valuable to actually answer in order to further your understanding towards your goal.
  • Work on answering them – collaboratively.

In no particular order (but with some logical grouping around lenses) and in the very rough form I’ve been actively using in my current team, here’s over 50 of the “level 0” questions I’ve started experimenting with.

Feature Info

  • Name – what do we call it?
  • What is it? (2-3 sentence user-facing description *and* 2-3 sentence product description)

User info

  • Describe how a user would do this now? (without new code)
  • What types of users does this help?
  • How does it help them? (what does it enable, unblock, simplify etc.)
  • What is a user trying to actually achieve when they do this?
  • Why?
  • What constraints are they facing at that moment?
  • Who can we talk to about their goals and needs for this? (a selection of people willing to talk to us more)
  • How complex/accessible (to the user) is it?
  • How many/what proportion of users will benefit from this?
  • How frequently might we expect different types of users to use this?
  • How might this detract from the product for other users?

Investment/Product/goal alignment

  • How does this improve the product?
  • How big/expensive is it?
  • How much time do we want to invest in initial investigation?
  • If an initial investigation is inconclusive, what next?
  • How much are we willing to invest in this? (and how flexible is that decision)
  • Is there anything obviously more important/valuable/beneficial to do before this?
  • Would we be fools not to do this in the next 90 days? – why/why not?
  • If this were the only thing we did in the next 30-90 days, is this the right thing to do?
  • Why is this valuable to the team/company?
  • How does it align to current product/company goals?
  • How does it further our journey toward those goals?
  • Would you describe this as a tactical or strategic change?
  • Why?
  • Does this really fit within the product we have already?
  • (how) will it help differentiate the product from the competition?
  • Could this be a new product?
  • Are there any other products it may integrate with or impact? (ours or elsewhere)
  • Does this align more closely to another product than this one?
  • Do any of our competitors already do this? (and how)

Functional info

  • What solution options exist already?
  • Can you give an example of how that would work?
  • Under what situations might that not be suitable/successful?
  • What additional solution options can we think of
  • What’s the smallest simplest thing that could possibly work?
  • What’s “good enough” to meet customer needs?
  • Is there an 80/20 solution option for this?
  • How can we make this more discoverable, useful and valuable to users?
  • Is there an ingeniously simple solution for users?
  • What would it take to make a user say “wow!” (and is it worth the extra effort?)
  • What is the best solution in terms of cost/functionality/usability/quality balance
  • What performance and quality criteria do we have for this?
  • What is explicitly out of scope?
  • Are there any cross-cutting or performance risks?
  • Are there any other significant risks to be investigated?
  • What dependencies exist?
  • If we ship an incomplete solution, what is the follow-on plan and forecast cost for completion?

Market

  • What is the market demand for this?
  • Is there any market or customer sensitivity around timing for this?
  • What marketing is planned or expected for this feature (if any)?
  • How do we expect our competitors to respond to this?
  • For what we’re planning to deliver, what do we expect from our users on social media?
  • How will we launch this feature (alpha/beta/freq update/big bang etc)?
  • How will this impact our position in the market relative to our competitors?
  • What impact are we expecting on sales/renewals by announcing / releasing this feature?
  • What impact are we expecting on our reputation by announcing / releasing this feature?
  • How will we sell / price this?

It’s a lot like writing 10 minute test plans – so quick and so powerful.

Give 200 questions a try on your next big feature request.

Take It Off-Site (Part 1) – The Bad and The Ugly

Posted on by
1
Reading time ~ 3 minutes

Offsite meetings have a checkered past. Back in 2006 a colleague shared this painful article with me.  To quote from the main article:

“…only about 10 percent of executives consider offsites truly valuable. Half said they aren’t worth the time or money.”

Over the last 7 years I’ve seen the exceptionally high value offsite meetings can bring but also the stress and pain that often leads up to them.

At my last employer, the entire global executive and senior management team would have a 6-monthly operations review offsite that ran for 3 days. We booked out significant portions of a large hotel in the US and fly the entire team together from over a dozen sites around the world. Over 3 days, the leaders from each site would present their statuses, finances, roadmaps, portfolios, visions, strategies and plans to a group of about 50 of us. We’d put them under the grill and review their work in depth both as bosses and peers.

We’d take time to focus on specific strategic issues that benefitted from face-to-face focused collaboraton. (When your management team are distributed around the world. A few intense days of co-location often delivers far more decisions and clarifications than 6 months of project work and conference calls.)

The general approach for these was: Prepare, Pitch, Review, Collaborate, Revise, Re-pitch.

Sounds pretty sensible? – It is…        … if you know what you’re in for. 

The offsite workouts were usually brutal but exceptionally valuable. By the end of the week everyone’s plans were in far better shape, we all understood what each other were doing, found areas for shared benefit and made a lot of difficult decsions.

Better still, we spent a few days working, eating and drinking together. 3 days of deliberate convergence in order to stem the behaviour issues associated with extreme divergence kepts us functioning as a successful management team.

Whilst the outcomes were great, they took their toll. The pain behind the scenes generally involved a bunch of us working 2 weeks of long evenings and weekends to pull all the data, presentations and spreadsheets together. ($100m of software projects contain a lot of moving parts & data) Often we’d still be revising our work during the start of sessions and whoever went first bore the brunt of painful lessons and questions whilst everyone else frantically updated their slide decks to accomodate the new knowledge.

And here’s the thing – the lines of questioning…

Our Senior Exec at that employer was an exceptionally sharp, experienced, bright guy. After working through multiple iterations and having joined the operations team on the organizing side of the offsites I saw what made him tick. He had a brain full of powerful questions that he’d learned from experience and was constantly adding to them. He knew what to ask and when that would lift the lid on just the right barrel to find a body (if there were bodies to be found).

As a spectator, sometimes it’s satisfying seeing the blood on the floor when someone you think is an ass-kisser takes a roasting. It’s not so fun when it’s your own team.

I even helped develop a set of “difficult questions” for our Head of Operations in the weekend prior to one of these offsites. They were great questions to ask. The thought and effort put into developing them was a lot like spending an hour writing test cases up-front. We learned quickly what we really needed and wanted to know (and why). We were confident we could get under the covers of even the most prettied-up project report.

But we could have made the whole thing so much less brutal.

Much like writing test plans, if we’d just put the questions out for participants to review in advance they’d have adjusted their research and reporting to accommodate them rather than playing project question battleship on the day.

So here’s an action for you.

Next time you’re reviewing a project or a piece of work, capture the questions you regularly ask.

Now…

Share them

Share them with the people you’ll be asking beforehand.

Now they can answer those questions sensibly first and you’ll all have time to dig into more valuable insights.

I have a few more posts planned around “critical questioning”, plenty around running offsites and I’ll be sharing where I’ve been for most of the last year so keep your eyes open for more soon.

 

A Year of Whiteboard Evolution

Posted on by
2
Reading time ~ 2 minutes

Back in December last year I started supporting Red Gate’s .NET Developer Tools Division. As of this month, we’ve restructured the company and from next week, the old division will be no more (although the team are still in place in their new home).

When I joined the team things were going OK but they had the potential to be so much more so I paired up with Dom their project manager and we set to work.

The ANTS Performance Profiler 8.0 project was well under way already and the team had a basic Scrum-like process in place (without retrospectives), a simple whiteboard and a wall for sharing the “big picture”.

I spent the first week on the team simply getting to know everyone, how things worked and observing the board, the standups and the team activities.

We learned some time ago here at Red Gate that when you ask a team to talk you through their whiteboard, they tell the story of their overall process and how it works. Our whiteboards capture a huge amount about what we do and how we do it.

I attempted to document and capture at least some key parts of the journey we’ve have over the year in which we released over a dozen large product updates across our whole suite of tools. This post is picture heavy with quite limited narrative but I hope you’ll enjoy the process voyeurism 🙂 If there’s any specifics you have questions about, please ask and I’ll expand.

Next time, I think I’ll get a fixed camera and take daily photos!

The end result? Multiple releases of all 5 of our .NET tools including a startup and quality overhaul for our 2 most popular products, support for a bunch of new database platforms, full VS2013 support (before VS2013 was publicly released), Windows 8 and 8.1 compatibility and a huge boost for the morale of the team.  See for yourself if you’re interested!

Of course this is just one aspect of what I’ve been up to. You might notice the time between photos over the summer grew a little. See my last post for more insights into what happens at Red Gate Towers.

Some Thoughts on Project “Closure”

Posted on by
Reply
Reading time ~ 4 minutes

I’m currently working with the team of function heads at Red Gate developing a “skills map” for all our development roles. (I’m primarily covering Project Management).

Having “bought-in” skills inventories at previous companies and failed with months of time and effort wasted, we’ve taken our approach from the ground-up, knowing our role definitions are pretty unique to us and managed to get to “usable” for trials in less than 2 weeks! (We’ll be sharing what we did in the near future)

Having mapped out the set of skills and directions at a high level, we’re in the process of taking each skill and defining what the skill actually means to us, why it’s important, what does “good” look like and where to turn for more info or help. Each of us on the team is trying a couple out for starters and then planning to crowd-source the rest.

I’ve decided to start with “Project Closure” as a skill that’s not too simplistic, is really important to us and an area where through most of my career I’ve not often seen a “great job” done.

Before I progress, what I mean by Project Closure is everything required to get from an in-flight running happily along project to “done” – the ramping-down.  This is Not what PMI, PRINCE2, APM or most other standard PM definitions define as “Closure”.

This disconnect is why I decided to write this post. Most PM resources talk about closure being sign-off, completion of project documentation and lessons-learned meetings or retrospectives (and a few other process and stakeholder type things).

Having done a bit of hunting, it turns out there’s very little information available on “ramp-down”. It’s no surprise projects overrun with the lack of support and resources that exist around this area! “Traditional” project closure happens once everything’s already been delivered.

Forgive me if I’m being a bit ranty here but surely that’s after the horse has bolted, right?

What about all that effort of putting all those loose project tentacles back in the box first?

An Octopus in a treasure chest

How do we get from an “in-flight” project to “Done”.

My best analogy to this comes from the “String and Octopus Guide to Parenthood” that my first ever boss sent me a copy of over 15 years ago.

5. Dressing small children is not as easy as it seems: first buy an octopus and a string bag. Attempt to put the octopus into the string bag so that none of the arms hang out.

Time allowed for this – all morning.

Closing out projects well is hard and it takes  longer than you ever expect it to.

I’ve not finished writing up the full skill definition yet but I wanted to share where I am so far for anyone out there that wants at least a slight pointer in the right direction…

(Note, this is my definition based on the context I work in at the moment. It doesn’t conform to any certifiable standard so don’t scream if you answer your PMI exam questions on closure with stuff from this and get it wrong.)

A Short Definition

Project Closure (as a skill) is the ability to take a project from actively running to successful delivery and completion with a happy team, low defects, no panics, and in a timely fashion.

This is usually meeting a planned release date if there’s one set but for some teams can also mean getting to a point where we’re shipping production quality software with completed, working features on a frequent, regular basis and have the ability to move a team successfully off of a project stream (ready to work on another) and close it down in a satisfactory way for the team, customers, product management and the business if needed.

Why Is This Valuable?

Unless we ship valuable working software regularly we don’t keep customers happy and we find it harder to attract new customers. Working on products that don’t ship for long periods of time also has a pretty negative impact on morale for everyone involved – we love getting our stuff in the hands of customers and making them happy & successful!

We also risk building up large quantities of undelivered code or features (“inventory” waste in Lean terms), racking up undiscovered defects, increasing project risk and technical debt. The longer a project or feature is under active development, typically the longer it takes to shut down and ship.

Being able to ship and close down a project  is vital to our ability to balance investment across projects and products as it’s likely we’ll always have less teams than things we want to deliver and need to be flexible around team size, availability and commitments.

What Does “Mastery” Look Like Here?

Someone handling project closure really well will have a good handle on the state of development in relation to the remaining time left for a project to run and how long it’s been since we last shipped a successful release.

You’d probably expect them to be looking at what’s needed to close out the project from the point it’s about 2/3 complete. As an example – if you’re running a 3 month project, then most of the effort from the PM in the last month will be around closing things down.

They’ll be winding things down in a controlled manner with no surprises and no extreme rushes to the goal. Known bugs will be visible, regularly reviewed and going down, release testing will be planned, scheduled and resourced – chances are there will be a full-team release test towards the very end. Documentation will be all well under control, a UI freeze will be planned and completed. Features will be winding down or completed and bug fixing will be moving from high-risk breaking type bug fixes to showstoppers, visible, cosmetic or quality issues and small functional gaps for tying off.

They’ll have worked with our marketing team or product manager to ensure marketing is ready to go. Our sales and support teams will be being briefed on the new features, and we’ll have probably completed at least one bug hunt.

In the week or 2 before closure we’d expect to see a controlled code freeze and whilst the PM might be having to negotiate and plan what’s coming next they’ll still have a really tight rein on scope, be making decisions on any new incoming issues and setting clear priorities.

They’ll be encouraging the team to support each other across roles and swarming on areas that need a real push whilst ensuring that we don’t lose sight of the original project goals, customers’ needs and product quality.

 

That’s it – so far. If you have anything useful to add to this, please dive in and comment (mind the tentacles)

 

 

Back to the Oubliette – How We’re Digging Our Way Out

Posted on by
Reply
Reading time ~ 4 minutes

Back in December I moved to a new team. After 18 months on DevOps and email marketing projects I’m back to managing commercial product development. After a week of getting up to speed on the product and project (it was already in flight when I joined) I started looking at the bug backlog in Jira.

One problem with bug backlog tools is that they allow you to create bug backlogs. I considered shutting them all down but knew we’d find value in being more considered in our approach.

For this project I was pairing with another project manager; Dom Smith (yes, pairing isn’t just for developers). The project was a major new release for one of our longstanding successful tools.

This is the second time I’ve pair-led a project and every time the overall outcome and workload is so much better. One day the rest of the industry will realised that having a single PM running multiple projects will always get a suboptimal outcome. In fact another critical project (fixed time, fixed quality, fixed schedule, fixed scope!) elsewhere in the building is also being pair-led right now and is proving to be a great success.

Dom was a technical author in a previous life and is therefore rather good at keeping track of everything a team does over the life of a project. Another team were interested in what we’d done so fortunately Dom managed to capture everything we did to get the oubliette under control. Today’s post is brought to you courtesy of his work.

At the start of our review we had ~1200 open issues, of which about 400 targeted for the “next version”. The backlog had reached a state where nobody wanted to look at it as it was “too big” to resolve.

Fortunately strategies for breaking down big problems is something I tend to specialise in.

If I’d said at the start we were going to spend 4 months doing this, I think we’d have struggled. Looking back, we spent about 50-60 hours of our time and about 100 hours from the development team to get things under control.

We started with just one hour’s “space” and simply said. “OK, what can we achieve in 10 minutes”.  Fortunately bug backlogs have many “seams” to work through. We worked through the smallest easiest first and whenever things slowed down or value started to diminish, we’d move to a fresh seam and started digging again.

We started by setting up an hourly slot once a week to pair up and pull the things we were going to fix into the current version. In the process of this, we found many duplicates we could close. We also ensured that rough priorities (priorities would be clarified later) were set on everything we pulled through, and that they all had components (the functional or technical product area) set.

After a few weeks repeating step one, we started tackling the other end of the list: things that were out-of-date or really not going to get done.

Anything more than 3 years old was checked on a case-by-case basis with the starting assumption that it would be closed as ‘won’t fix’ unless we could argue a reason not to (primarily based on prevalence and customer impact). Pairing made these a sensible conversation rather than a  hasty decision.

“Autobugs” – we have an automated bug reporting system so that when users hit an exception they can choose to report it directly into Jira with no additional effort.

Any autobug raised prior to the last major shipped release that was not seen in the latest live release. We were working on v8.0 so any bugs reported against v6.x with no reports in v7.x, were closed

Any autobug raised only by one our development team on an unreleased build over 6 months old were closed.

After cleaning up the “noise”, we added a weekly, 45-minute meeting with the whole development team to review all the new issues added in the last 7 days, set a clear and appropriate priority, ensured component information was present, and set an explicit release target. (Either “current” (v8.0), “Next Minor” or “Next Major”. This helped contain the quality of new bugs – we “stopped the bleeding“.

We adapted our weekly pairing slot, to tackle the issues assigned to people no longer on the team (the aim being to ensure that they ended up with no issues assigned to them). Many of these could be closed as No Longer Valid, but there were a few which should have been prioritized that they were being sat on.

Again during the weekly pairing, we started working on closing bugs targeted at “improbably releases”. We had placeholder releases called ‘Future – Possible’ and ‘Future – Unlikely’ which, by their very nature, aren’t likely to happen. Again, we ruthlessly reviewed each in turn. Many had already have been fixed, and just needed 5 minutes testing to verifying they were resolved.

We added a further hourly weekly session with our product manager prioritize any issues we’d found through this process that looked more important but needed a product management decision. Having set the impacted component on everything we weren’t closing we’d found clusters of problem-areas that had been previously hidden, that became candidate focus for our next minor release (due to ship imminently).  We also checked any queries coming from the development team’s review of issues from the last 7 days, and the scope of work for the current release to determine ‘Must Fix’ vs ‘High’ vs ‘Would like to fix’.

In parallel to these activities, we worked with our Sales team to ensure CRM references were added to any feature requests in JIRA (both new requests and existing ones that were being asked for repeatedly). This helps our UX specialists and product managers with prioritizing these in the future and gives them direct customer links to follow up on actual needs and problems.

In the space of 4 months we closed over 50% of the backlog issues by not doing any development work –  just investing in three weekly meetings. We fixed another 25% by setting clear priorities, targets and sensible grouping of issues.

We aren’t there yet though. Bugs are still coming in and there’s still two big ugly piles in “Next Minor” and “Next Major” that we have yet to tackle but we’ll continue to put a little effort in on a regular basis to keep improving our position. Better still, the last release we shipped has significantly less bugs and the one we’re about to ship has less again.

We’re digging our way out!

 

Convergence & Divergence

Posted on by
1
Reading time ~ 8 minutes

image demonstrating convergence and divergence using people and tools

It’s been a while since I’ve had time to write but I’m enjoying a brief respite between product releases to collect everything I’ve learned in the last 9 months. I have a few rather significant new ideas I’ve been using that I want to share. This is the first. It’s long, in raw-unedited form and likely makes a few mental leaps so please take your time, digest, think about how all this can apply to your environments and ask clarifying questions. I’d like to get this in a more digestible form someday…

Before I start, a huge thank you to Matthew Dodkins who discovered a brief comment Joh & I made whilst presenting at Agile On The Beach in Cornwall last year was something far more significant than we’d realised…

Complex organisational structures cannot be static, in order to remain healthy they must ebb and flow, centralizing & decentralizing around roles, reporting lines, business needs, good practices and knowledge.

Having brought this observation to a more conscious point, I and my fellow managers at my current employer have put this into active use…

Most experienced facilitators are used to talking about a diverge->converge process as used in moving from brainstorming to actions.

  • Diverge = generate ideas
  • Converge = choose the most promising

What I’m talking about here has very little to do with facilitation and is a reversed view (converge, then diverge) however it’s more accurate to view this as a natural continuous tidal cycle.

A loop showing convergence and divergence

Theory: The Converge-Diverge Cycle

The Converge-Diverge Cycle applies to organizational structure, behavior, process and even technology.

Although at any single point in time an organizational structure may appear static, many organizations develop natural rhythms of restructuring over time. At General Electric that cycle was roughly every 2-3 years at a wholesale organizational level. At Red Gate it’s closer to 6 monthly but cycles incrementally through divisions and operational functions.

At worst, poorly managed organizational tides are pretty toxic but at best they help re-balance interactions, interpersonal relationships, behaviours and practices across diverging groups.

Here’s the cool bit…

Which direction are you heading?

You’re always in either a convergent or divergent cycle. If you know which way you’re heading you can make an explicit decision to let the tide continue in its current direction or to turn it back. The longer a tide moves in a divergent direction, the longer and more painful the resulting convergence may be. The longer things remain converged, the more constrained your learning, innovation and evolution.

(unnecessary or diminished-value convergence can also occur – think “spork“)

Simply being aware that convergent or divergent cycles exist makes it possible to step back, observe, interpret the current direction of travel and make a conscious choice.

Your Convergence may be my Divergence

In organisational structures, convergence can shift from one position to another, causing divergence in its wake.  (I’m getting a bit philosophical so I’ll back this up with some real examples shortly).  Think about the age-old “Us vs Them“ mentality. Most often seen between the “business” and “development” or in bad cases between “development” and “testing” or between you and your supplier or customer.

Whilst it’s important to take individual responsibility for increasing the bandwidth of communication from email to phone to face-to-face, it’s really hard to do – particularly in a conflict situation.  The more physically and organisationally separated groups or individuals are, the stronger the “Us vs Them” pull may be. Beyond relying on individuals to play nicely, how about changing the structure and dynamic of the groups to foster closer collaborative working.

Equilibrium

So now it gets tricky…

Each “Us” or “Them” has a set of existential goals and motivations. These aren’t necessarily combative but often they aren’t aligned to each other. We know this lack of alignment can cause problems but what happens when we realign?

The best example of this that I frequently see is organisational structures that provide a centralised (converged) service. The centralised service convergence drives common “best practices”, efficiency and greater synchronization across the group that are all trying to provide a similar service to multiple “customers”.

This convergence is often at the cost of quality of service, responsiveness, tailoring and specialisation to the needs of a given customer.

The “Us & Them” conversation is between the service and each of their customers.

From this shared starting point, if we reverse this, diverge and decentralise the group with the service team distributed to directly serve each customer we find that responsiveness improves, tailoring increases and localised “best practices” emerge but it will have its own costs and compromises.

Standardization

I spent some years running an organizational standardization programme and have been involved in many others. I’ve seen the pain and cost of these first-hand.  Often the primary benefits are in management reporting and process certification, not improvement. I’m a strong believer in no best practices. Following a “best practice” implies there is nothing better. This mindset will stifle continuous improvement. There are however best known practices for your current context, situation and experience.

Process or tool standardization is not a sensible goal in itself. What is this trying to achieve and is it really the end point or simply a pivoting point between converging and diverging?

Reconsider where you’re standardising today. If these stayed locked-down for a decade and only evolved in a single direction, would this be bad for your teams and your business? If so, what’s your divergence strategy?

Who’s “Us” and who’s “Them”

Initially the ties of a previously converged team remain strong. You benefit from the strength of prior working relationships and team bonds to maintain synchronization.

This only lasts so long. After a surprisingly short period of time – particularly if groups are under pressure – (less than 6 months in my experience), the “Us” vs “Them” returns however this time it’s between groups with diverging and potentially competing approaches.  The former ties have weakened and new ones are formed. And this increases over time.

There is no long-term equilibrium. There is always an “Us” and a “Them” somewhere.

Great, we’re doomed to hate each other eventually and our evolution is over – so what do I do?

Deliberate Convergence & Divergence

There’s many existing strategies for forging and retaining ties between groups and a bunch of organisational team-building resources available with a bit of searching. Most of these need time set aside and essentially keep some bonds alive but rarely provide opportunities for continuous evolutionary improvement.

Here’s the cycle that usually happens

  1. We’re heading in the wrong direction.
  2. Someone realises there’s a problem that requires convergence in a different direction.
  3. An organizational change programme is initiated
  4. Time and money are invested in effecting a large organizational change
  5. Productivity and Morale take a beating.
  6. The changes bake in
  7. Rinse & repeat

Here’s the “deliberate” equivalent

  1. As part of a regular review, current direction is assessed.
  2. We determine if we’re converging or diverging on the right things, what’s working well & what’s not.
  3. We make an explicit decision whether to change direction.
  4. We give things a “prod” in the direction we want to go.
  5. We do this regularly enough to stay fresh but slowly enough to be stable.

Here’s a couple of real examples from where I am right now…

In Practice: Organizational Convergence & Divergence

We have a number of teams who are responsible for providing centralised services. HR, Publishing, IS, DevOps, Finance. These groups are co-located teams and interact with their internal customers.

Team 1: HR

Our HR team assessed how they were working and made an explicit decision to diverge.

Each division now has an HR specialist who sits co-located with their customer.

The HR team still get together regularly but they’re now a diverged group.

They’ve structured things so they won’t diverge any further but also know that all decisions are reversible. We may re-centralise them in a year or two’s time in order to put a load of energy into a large centralised change.

Team 2: Dev Ops

Our DevOps team were a centralised group for over a year. They worked closely with IS but provide a service to sales, development and finance (among others).

Because of the nature of projects and changes on the cards we had 2 choices.

  1. Disband DevOps, put skilled DevOps staff in each delivery team and diverge the service
  2. Converge DevOps, Business Intelligence and IS even further to run under a single pillar of the organization.

We chose further convergence. The team have radically altered their processes and have focused on the top priority company-wide priorities. Some other teams will miss out on their requests but in the larger scheme, this was seen as the most effective structure for our current needs.

Team 3: Sales

Our product organization was divided into a number of divisions. Each division had its own sales force co-located with the development teams. This was working great for development but it gives a really bad customer experience when a customer owns products from multiple divisions. We’ve converged the sales team and brought their processes and practices together to give a better customer experience. We’ve sacrificed the closeness of development and had to drop some division-specific process tailoring but we’re having better conversations with our customers.

In all 3 of these cases, I fully expect these changes to cycle in a different direction at some point in the next 2-5 years. As do the teams – it’s simply how we evolve.

Because we know things will change again, we’re less entrenched with the status-quo.

As an aside, we don’t hot-desk here but because our organisation is so fluid, most staff have moved desks 3 or 4 times in the last 18 months. We treat this as normal. We still have our own space, desks, walls & possessions but we stay mobile enough to move ourselves in under an hour’s effort.

This week we’ve asked all our development staff to propose where they each feel they can best contribute for the next 6 months and based on those preferences I’m expecting to see over 20% of our teams move again.

In Practice: Process & Tool Convergence & Divergence

I mentioned earlier that standardization is a directional way-point, not a goal.

I spent nearly 2 years “standardizing” Scrum, Lean & Agile with one employer. At the time it was the right thing to do. Most parts of the software group had never had any form of large-scale convergence. As a result the effort & pain were significant however we took teams who had been working in their own evolutionary islands for 10-20 years and brought increased commonality to them. We reached very close to standardisation but deliberately designed our ISO processes to support limited positive divergence.

At my next employer, my first action as head of project management was to explicitly state that we would not be standardising our project practices. All teams had standardized on Scrum 3 years earlier and had been slowly diverging. Having observed the teams and contexts it was clear we had scope to diverge further whilst still remaining healthy. In fact, it gives us the ability for concurrent parallel learning and improvement. We learn more and we learn faster.

2 years later we’re at the point where I want to introduce some convergence. Rather than a complete standardisation we’ll be developing a playbook of “known good practices”. It won’t be exhaustive, it’ll start with the top 25 things we think are a no-brainer and we’ll work from there. Some of these things won’t be common across the teams when we start. Eventually they will be…

… and then we’ll decide whether to continue converging or to diverge again.

Great, now what?

Review where you currently stand.

  • Which groups are converging and diverging? – Observe and interpret.
  • How long have they been moving in that direction?
  • Are you willing to continue or is it time to adjust? – Make an explicit decision
  • How large and fast a change is needed? (if any)
  • How will you push in the direction you need? – Deliberate action
  • How long do you expect the next cycle to last? – Tidal change
  • When will you next check?

Whew! That was epic. Thanks for reading to the end. As always, I’d love your feedback.

 

 

 

Stopping The Line

Posted on by
1
Reading time ~ 4 minutes

A few weeks ago the Company I work for celebrated its 13th birthday. As part of the celebrations we were each given the latest copy of the “BoRG” – the company book.  On reading through the pages I found one of the teams I’m responsible for received an award.

This isn’t quite as positive as it sounds and I’m pretty sure the incident will become lgendary within the company. The lessons learned, what we did afterward and the forward thinking attitude of our senior management are however truly worth celebrating.

The (rough) Story

Over the summer one of our teams was working on some updates to our product deployment tools (we deploy upwards of 50 new releases across our product portfolio every month). Part of the automated process involves uploading a packaged installer for our software to a download location and updating our web site to point to the update.

Due to a mix-up between environments and configurations, one of our internal tests made it into the outside world. The problem was spotted and resolved fast but something was clearly wrong for this to have been possible.

This alone would have been rather embarrassing however this was about the 6 or 7th significant incident that had come from our operations teams in as many weeks. We’d recently restructured team ownership of parts of the codebase, were making a large number of significant infrastructure, library, test and build changes to our systems – mostly legacy code (code without sufficient tests). Moreover, we added a whole new team onto the codebase with a very different remit in terms of approach and pace, the volume of churn in the code had massively increased.

This was all during the height of holiday and conference season so many of us weren’t fully aware of the inner carnage that had been occurring. Handing over from one manager to the next repeatedly meant we’d not seen the bigger picture.

I returned from Agile 2012 to a couple of mails from my boss (who was now on holiday) to fill me in on what had happened with the (paraphrased) words: “Can I leave this safe in your hands”.

Over the first 2 hours of my return I was briefed by managers and team members on the situation. Everything was sorted, no problems were in the wild but the team’s credibility had taken a beating.

I’d seen similar things happen in other companies and had always been certain of the right course of action. This was the first time I actually felt safe to lead what I knew was right.

I donned my “Lean” hat and started my nemawashi campaign with our senior managers.

I spoke to each manager individually – they were already well aware of the problems which made things much easier. I simply said.

“These problems can’t continue, we’re going to ‘stop the line’. All projects are going to stop until we’re confident that we can progress again safely.”

I went a step further and set expectations on timescales.

We’d be stopping development work for nearly 20 staff for at least a week. We’d monitor progress daily, and approval to continue would be on the condition that we were confident problems would not reoccur.

By lunchtime I had unanimous support. It was described as a “brave” thing to do by our CEO but all agreed it was right.

A side-benefit of Lean is the shared language it provides. In every case when I approached our management team and explained that I wanted to “stop the line” they immediately understood what I meant plus the impact, value and message behind such an action.

Now of course you can’t prevent new problems with hindsight but you can identify patterns of failure and address these.  In our case I had a good understanding of what had been going on.

Initially I was strongly against performing a full root-cause analysis.  There were half a dozen independent incidents and a strong chance of finger-pointing if we’d gone through these. I was already “pretty sure” where our problems lay. The increased pace had led to a fall in technical discipline coupled with an increased pressure to deliver faster and a lack of sufficient safety net (insufficient smoke tests).

I divided the group into 3 teams to focus on 3 areas.

  • “before release” – technical practices
  • “at the point of release” – smoke tests
  • “after release” – system monitoring

With an initial briefing and idea workshop I stepped back and left the 3 teams to deliver.

The technical practices team developed a team “technical charter”.  We brought all participants together for a review, revised and then published this. Individuals have since signed up to follow this charter and we review it regularly to ensure it’s working.

The smoke testing team developed a battery of smoke tests for the most critical customer-facing areas (shopping cart, downloads etc). These are live and running daily.

The monitoring team developed a digital dashboard (that I can still see from my desk every day). This shows the status of the last run of smoke tests (and history), build status, system performance metrics and a series of alerts for key business metrics that would indicate a potential problem with the site – e.g. a tail-off in volume of downloads or invoices.

They also implemented some server-side status monitoring and alerts that we subscribe to via email.

Since these have been in place we *have* had a couple more incidents but in every case we’ve spotted and resolved it early.

Subsequently a couple of the teams have self-selected to perform a root-cause analysis on a couple of issues. This is exactly the behaviour I love to see, it’s not a management push, they simply wanted to ensure we’d pinned things down and done the right thing. Moreover, they published the results to the whole company.

The award…

 

 

Why You Should Stick To Using Whiteboards & Stickies

Posted on by
5
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”.