Category Archives: Project Management

You Are Not A Lathe Operator

Posted on by
Reply
Reading time ~ 3 minutes

This weekend my replacement copy of “The Goal” arrived. (My last copy escaped).

I wrote the following article in mid-2009 – some time before I read Goldratt’s “The Goal”. This was eventually published in 2010 internally at the company I was working with at the time. Today felt like a good day to refresh it and share more widely.

________________________________________

If you haven’t yet done so – read up on the theory of constraints. In fact I recommend that every manager in any size of organization obtain and read a copy of “The Goal” discuss it with your peers & teams and make copies available for your staff.

In Spring 2009 I had the good fortune to attend a training course in Florence, Italy – a hub for European manufacturing training for a large Oil & Gas company.

One of my working team during the week was in the process of implementing a lean production line for the local factory floor. Their layout and travel spaces were all mapped out but the reason for him attending the training was to cover the human aspects of such a radical change.
He had factory floor staff who had been performing the same expert role for 20-30 years or more. Now they were being asked to radically change their working practices and he was feeling the pain.

An operator producing bearings may traditionally be measured on their production volume (and quality).  Their single-minded goal is to maximise their own output. The more bearings produced, the better an operator they are. In some cases, particularly where waste is not well managed, volume may even trump quality.

In a production line, operators are contributing not to the production of bearings but to the production of complete working units as part of a team.
They have to look both up and down-stream and assess the state of flow through the entire team. If there’s a bottleneck in the line, they’re expected to adjust or stop their own activity to help out and “level the load” in order to maximize the performance and throughput of the entire assemblies they’re working on in the factory.

The challenge here was that some operators had learned over years of training and measurement to sub-optimize around their own roles and personal output even though the real unit of value was in the whole team’s output.

His challenge was not unique and for this particular company, lean manufacturing was already a major focus. The striking synergies between lean & agile meant I was able to share insights from my own experiences with him.

Now let’s take his example and consider some quotes often heard during software development.

  • “It’ll be far more efficient if I do all the coding now in one go.”
  • “Seeing as I’m already doing some surgery here it makes sense to add these few other things that I’m pretty sure we we’ll need”.

Often these are suffixed with “it’ll be ready in when it’s ready”.
I’ll raise my hand and admit to this behavior in the past – particularly when in the midst of a major refactoring exercise.
But…

  • What about everyone upstream and downstream of my code?
  • What’s the impact on the testers of me delivering 3 months worth of code over 2 days worth of code?
  • Do I have people waiting for work downstream?
  • If I changed my delivery practices would I get feedback sooner?
  • If I got feedback sooner would those bugs be less of a pain to context switch and fix?
  • Would the overall throughout of the team be greater?
  • If requirements change how much of my work would be wasted?

This is where agile and manufacturing meet.

Admittedly in manufacturing, the concept of a multi-skilled operator is far more prevalent than in software however the software industry equivalent is often described as the “Generalizing Specialist” – that is: whilst a member of the team may primarily be role X, they are able to add support and value in role Y – even if that’s not their job title.

This may be a simplification of reality but some skills are exportable or importable across roles and allow us to level the load by having others do the heavy lifting.

It is the responsibility of every member of a development team to consider the entire value-stream, the activities of all skills and roles that contribute to a working product increment and ask questions like:

  • “Am I working on our top priority item? – if not, should I contribute to it in some way?”
  • “Could we be delivering more finished work sooner if I helped out elsewhere?”
  • “I’d really appreciate someone covering these areas around the edges of what I’m working on”
  • “Here’s a problem that keeps slowing us down, let’s figure out how to remove the bottleneck.”

Think about your current role in a development team.

  • Are there opportunities for members of the team covering different roles to support each other better?
  • Is anyone over-producing in comparison to capacity of other areas and causing headaches downstream?
  • Could some conversations be had sooner, be much shorter and save pain?

Take some time out this week and consider how your teams and individuals could improve their cross-role collaboration, share some of the heavy lifting and deliver as a more cohesive unit?

The Hidden Dangers of an Independent Quality Organization

Posted on by
Reply
Reading time ~ 3 minutes

“We need an independent quality organization, to keep the project managers, developers and business honest”

Today I thought I’d let “Bad Captain” take the helm for a few minutes.

In talking about software quality at Agile Cambridge a couple of weeks ago, the audience were invited to share their insights. Mine was to “avoid independent quality hierarchies” – to which I received a small round of applause (likely from those that recognize the dangers). I’ve had this article in the shed for many months and although my context has since changed, there are many in the software world that face this pain and need your support.

We trust our managers and teams with the finances of multi-million dollar projects, we trust them with staff pay and appraisals when those knowledge workers are generating our primary source of income and we trust them to preserve our intellectual property!

OK so in many cases we have reviews but these are within the same organization. Some companies sadly don’t trust their teams with the quality of what they’re delivering in the same way?

  • What happened to damage or erode the trust?
  • What’s being done to rebuild it?
  • Is it beyond redemption?
  • Who can lead the change?

Most managers I know and most development teams succeed by having a high level of professional pride and integrity and by doing the right things for their team and product. In the situations where a manager or team doesn’t behave in that way it’s incredibly rare that they don’t get called out by their peers.

  • It’s professional and long-term product suicide to short-change quality, we just don’t do it.

There is no good reason for a manager and team to not set their own high quality standards and meet them.

Beyond “keeping teams honest”, the other argument I heard for an independent quality group was:

“Because it’s a required function further up the management chain, that’s just the way it is”

Don’t get me started on empowerment, continuous improvement and root cause analysis. It seems incredible that in the 21st century, staff in many organizations perpetuate this attitude. The truth is that this is still incredibly common.

Unfortunately I don’t have all the answers today but here’s a couple of thinking tools to present…

Let’s run on the assumption that we really do need an independent quality group. As I see things, that team has 2 options.

Option 1: Set a high quality bar and challenge/encourage teams to meet it. Negotiate down or stand your ground when the project teams challenge the setting of the bar.

  • We’ve just built a new source of conflict and waste in our organization with a management chain that have a vested interest in their group’s own continued existence. Nice move!

Option 2: Set the bar at a level we think the team can meet.

  • We’ve just low-balled our quality for the team. Better still, the team working on delivery are not accountable for raising their quality game because that’s been taken away from them!

Now let’s turn things around.

Option 3: Let teams and managers set their own quality bar. Arrange a proper review where the team use their professional pride to challenge the level they set and determine what’s achievable, what they could strive to achieve next and what are the business and engineering benefits of doing so?

Risk: The team low-balls their criteria.

  • Mitigation: Lead by example, drive a culture where everyone takes personal responsibility. Reward and recognise teams for raising their game.

Funny, for some reason Option 3 doesn’t seem to need independent QA.

Where I work right now doesn’t have an independent QA/QC organization. Our quality is high, as is the level of trust exhibited throughout the company.

This is the simple stuff, don’t break it with vested organizational interests.

Caveat: I understand regulated environments have a necessity for compliance and  independent oversight however that compliance environment is either for safety or due to exceptionally high trust-related risk . If that’s not relevant to your organization, why then are you still doing it?

I’ll return the rudder to Captain Crom in future.

Where’s My Tools?

Posted on by
Reply
Reading time ~ 3 minutes
hand

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?

Piratical Management (Pirarticles)

Posted on by
Reply
Reading time ~ 2 minutes

I’ve spent very little time on writing articles directly related to my nom-de-plume.

There are 3 main reasons behind this.

  1. Most* of my “Bad Captain” thinking is fuelled by negative workplace, management and team experiences and I’ve not had any for a long time.
  2. I have a backlog of 70+ more valuable articles and ideas already without adding pirate concepts into the mix.
  3. There are plenty of articles already discussing pirates and management on the web, why re-invent the wheel!

*The rest is probably fuelled by cider, rum and late-night ramblings with close friends – think “Father Jack with earrings”

So as I make final preparations for a dawn raid at the Grand America Hotel in Salt Lake City and a week at Agile 2011 I’ve been digging out some reading material…

Here’s a quick pick-through of piratical management articles (“pirarticles”) I’ve found on the web so far plus a couple of potential reads to add to my “booklog” (thanks @MarkDalgarno for that very sticky term last week).

Articles

Some short articles for when my cognitive load means I don’t have space for anything more plus one or 2 that are more formal.

Books

I’ve not read either of these, I’d be interested in some reviews from people that have done but for now they’re going onto the booklog.

Music

  • Pressgang – Not directly about Pirates per-se but they do belt out a few amazing seafaring related folk-rock stories.

A little history (not much)

Deadly Serious:

A reminder that whilst my moniker is a light-hearted dig at my appearance and occasional nocturnal ramblings, there’s a whole other side to “real” pirates…

Transactions for Managing Technical Debt

Posted on by
Reply
Reading time ~ 4 minutes

If you’re losing capacity maintaining brittle code or infrastructure, the “litter patrol” in a related neighborhood may be good practice but how do you visualize and manage the true source of your pain?

This is based on a mix of my own experiences and great nugget of insight picked up from Jim Highsmith at Agile 2010 who in turn credited Israel Gatt.

First the paraphrased nugget from Jim…

“Teams need both debt reduction and debt prevention strategies.”

Here’s the quote from Israel back in December ’09.

“If your company relentlessly pursues growth, the quality/technical debt liability it is likely to incur could easily outweigh the benefits of growth. Consider the upside potential of growth vis-a-vis the downside of the resultant technical debt. When appropriate, monetize technical debt using the technique described in Technical Debt on Your Balance Sheet.”

Here’s my expansion to Israel’s article…

How do we know we have debt?

We “know” it’s there, we feel it. But do the right people know about it? You may be allocating permanent team capacity to keep bailing without seeing the hole.

  • Train all your teams in spotting technical debt
  • Develop and communicate your debt strategy to your teams and stakeholders.
  • Determine a common unit of currency (points, hours, money, NUTs) that your stakeholders can understand and engage with and use this to describe the transaction decisions you’re making.

Communicate current debt – “Balance”

  • This is obvious but hard to achieve. For the debt that hurts; quantify the cost and determine what you could do if it were resolved. Get that opportunity cost shared and get your solution sponsored. In most large companies if you can demonstrate a cost reduction or productivity improvement you can get support.

Communicate new debt – “Recent Transactions”

  • Not the decade-old pile in the corner! Focus on what you’re forced to add because of deadlines and market pressure. Every time you make a debt-related compromise, get that conversation exposed. Determine the maximum acceptable age for any debt being added, a cost (in your selected currency) and a priority. Whilst there are cases where a debt may never need to be repaid, chances are you’ll need to pay the next transaction off.

Limit debt – Set yourself a “Credit Limit”

  • What’s the maximum debt your team/project/product is willing and/or able to tolerate? Set a credit limit and stick to it. If we blow our limit, we’re in trouble. My personal rule-of-thumb is if it’ll take more than one whole sprint for the entire team to clear all new debt then you’re worryingly-leveraged and heading away from releasable software. This approach means a simple default credit limit for a new project (using story points as currency) is the same as your velocity – simple to calculate and remember. You could convert this into the average hours (and therefore financial impact) a story of that size takes if that means more to your leaders.

Whatever you do, don’t over-mortgage your product. You don’t want your product portfolio to collapse under unrecoverable bad debt.

Set a maximum age threshold – “Payment Terms”

  • Use topping & tailing approaches to control and ratchet your debt age to keep the span down.  If your debt exists for more than N sprints (say 3) promote it to the top of the priority stack. Fixing new debt when it arrives is hard work and items do slip through. For those that escape, setting a maximum age means you’ll cycle all your debt through and keep it fresh. Even tough problems get resolved rather than rotting in the debt heap.

Visualize and report your debt – provide a “Debt Statement”

  • Put all debt visibly on your wall as cards or stickies, give it a different color, heading, whatever – make it visible. Now every sprint let’s highlight the numbers, the growth, reduction, reiterate your limit. If you’re using an electronic tool, try putting all the debt items under a single parent and tracking cumulative flow and burn-up of debt rolled up to that item.

Prioritize your debt – “Positions”

This is getting a little more advanced and difficult to manage – I’d reserve this for only projects that already have high debt where the simple strategies alone are too invasive.

  • Partition your debt into 3 positions. New:Short-term, New:Long-term, Old:All.

Set a different credit limit and payment terms for each of these and as part of prioritization set a ratio of effort/pay-off against each that ensures that at a minimum debt is sustained at a constant level but focus on cycling through so that the contents remain fresh.

Taking Action

Here are a few other points to explore – mostly around debt reduction.

• What “small wins” exist for you? Are there some simple debts than can be cleared quickly?

• If you sacrificed a team member for 1 sprint to pay off some short-term debt, would you be able to increase the overall team performance in later sprints?

• If a particular single debt item is too big for a team to swallow in a single sprint, can you call in or implement a parallel “SWAT Team” to fix it?

• What capacity do you need to reserve to sustain your current debt level?

• If you were going to reduce your debt burden by 10-20% what effort/capacity would that require and how long would it take?

• Can you demonstrate a return on investment for a particular piece of debt-reduction?

• Worst-case scenario: Could some debt control run “under the radar”? (And if this were discovered, what problems would be caused?)

Wrapping up:

Develop both debt prevention and reduction strategies for your teams, don’t just focus on reduction.

Treat technical debt like real personal or business debt: use “credit limits”, “statements”, “balance”, “transactions” & “payment terms” to your advantage.

To achieve effective reduction, work through the Oubliette strategies and in worst cases, consider a “SWAT Team”.

Improving Your Retrospectives

Posted on by
2
Reading time ~ 3 minutes

Inspired by Carl Bruiners – he described many unsuccessful retrospectives as “Happy Clappy” or “Toothless”.

– I love the term “happy clappy”

Last weekend  I hosted/facilitated a short session at the UK Agile Coaches Gathering on “How To Improve Retrospectives”. A valuable hour or so of shared challenges and lessons. Here’s the highlights I was able to capture.

Let the Team Vent

  • If you have a very frustrated team with a succession of issues, give them time for catharsis. 2 or 3 “venting” sessions to let off steam rather than retrospectives needing concrete action may actually be necessary. After the sore points have been drained, circle the team back around to actually solving some issues
  • Facilitate the venting to keep it constructive, not personal and ensure they are actually draining issues, not fuelling flames

Think Lean

  • Prevent batching and waiting by raising issues sooner with the potential to address improvements rapidly before a retrospective even happens
  • Capture your data points and lessons as soon as they come up – on the board for the team to see every day. Discuss them as part of the stand-up
  • Track activities, lessons and problems on a timeline during the project or
    sprint, not at the end. There will be less head-scratching and forgotten issues in the retrospective. It’ll be faster to get moving, you’ll have fixed more and people will feel the time spent has been more productive
  • Consider setting a threshold / count of the number of issues or lessons raised as a trigger for a retrospective rather than just sticking to a sprint rhythm

Figure out what to do with “stuck” actions

  • If there are recurring problems beyond the team’s control, take them off the table. There’s no point in self-flagellation. Raise them in a forum other than retrospectives
  • Define a clear, workable escalation path for when a team needs support to resolve a retrospective action
  • Work with “management” to clear at least 1 stuck retrospective action in order to build team trust in both the management and process – prove it’s working, worthwhile and supported

Keep it interesting & fresh

  • Once a team is used to the general structure of retrospectives and using these relatively effectively, use variety to keep things fresh and interesting – see the “Agile Retrospectives” book and associated mailing list for ideas
  • Retrospect on your retrospectives, – e.g. using start/stop/continue

Beware of US/UK social differences

  • Thanking and congratulating each other is not a common cultural behavior in the UK. Get teams comfortable with other activities and working as a team before approaching some of the “softer” areas
  • Recognise your team members may not be happy talking about how they “feel” about projects, each other, values or any other “hippy” concepts

One of attendees at the coaches gathering described a painful retrospective experience where a single member of a team effectively shot down a retrospective by refusing to participate in sharing feelings. I’ve had similar derailing experiences where a single team member didn’t want to take ownership of any actions or decisions and pulled a team with them. In both cases we just called a halt to that part of a retrospective and moved on. There’s always next time.

Deciding What To Do

  • Capture actions for the team and actions for “management” independently
  • Use dot voting or similar consensus-building activities for selecting actions
  • Encourage people to vote for what they’re motivated to address and capable of resolving, not just items they think are important
  • Limit the number of actions to commit to & address, you can always come back for more
  • If you complete all the committed items, consider pulling one more new action through

Agree When & How actions will be covered

  • Some items are “just go do”, others have more cost. Address just go do items as they come up
  • Consider use of stories for larger actions in backlog and prioritization
  • Try “sprint tasks” to keep “customer” activity/velocity independent of “non-customer” actions and improvements
  • Identify owners for taking management actions to the management (typically a coach, team lead or scrum master)

Thanks to Sophie Manton, Mike Pearce and other attendees for the insights & lessons they shared at the Coaches Gathering.

5S Your Scrum Board – (Part 2) – In depth

Posted on by
Reply
Reading time ~ 7 minutes

I’m a big fan of Goldratt’s Theory of Constraints for getting important improvements made in the most suitable order for a team. Our current scrum board is the result of focusing on the most evident, soluble problem each day for a couple of weeks. No grand plan, just good emergent design.

Note this is a very long article as some readers of part 1 asked for all the details as soon as I could get them written, today’s the first time I’ve been near my blog in a week. I’ll switch back to shorter posts after this for a while.

Here’s an in depth look at each of the areas of our board…

scrum board with placeholders

Using the peripheral space for useful stuff

 

Feedback

A single sticky with a quote regarding some feedback. The last 3 sprints we’ve left one up there that says “It shouldn’t be all that hard” . A reminder not to generalize (“it” was much harder)

Theme

One sticky. Our current theme is “Contact Management”, The next will be “Dashboarding” or similar. Just a little reminder of what the overall focus of the sprint or sprints is. This helps when clarifying or controlling scope, questions, debt & defects.

Capacity

During sprint planning we look at who’s in, when and what other commitments they have (beyond the usual overheads and maintenance activity). Capacity is calculated in half-day (4-hour) increments for each of us, totalled up as a whole team in hours. We then subtract 40% for overheads & support.

We track a second capacity number under the first which is the actual total effort hours of tasks completed in the last sprint. Generally this is a fair bit lower than the forecast.

The differences between these two figures are useful input for understanding our capabilities & overheads.

We limit tasks during sprint planning to around 70% of our maximum delivery capacity or close to our previous delivery capability  in order to leave space for unknown / discovered activities and hurdles. If planning another story would take us over this level, we hold off until we’ve actually been able to deliver the first – there’s no point in breaking stories down into tasks if they’re highly unlikely to happen in the next 2 weeks.

If we really do well, we can always reconvene.

Tags

At the moment we have 2 sets of tags on the board; “Blocked” and “Please Test”. The team no longer uses the “please test” tags so they’re likely to be removed this week. We assume coding tasks include developer-led testing activity and any other testing is planned in as scheduled tasks. This has reduced dev-test handover as the whole team focuses on the set of tasks required to complete a story, not their individual tasks.

I’m likely to add “red tags” soon for tasks that need particular focus or expediting. We’ll limit the use of red tags to one WIP item at a time and only when needed.

Key

A color key for our tasks. Currently we have

  • blue : code & test
  • green : design & ux
  • yellow : test
  • orange : management noise
  • pink : support & bugs

Stories

 The top horizontal swimlane of our board contains stories and story activities.  The left-most column of this contains story cards in priority order from top to bottom for stories planned for this sprint. The space here is deliberately small. The last 2 sprints we had only 2 stories listed, in the next sprint we’re actually reducing it to 1 and having the whole team pull single stories through. (Update – We ended up pulling single stories as a flow after this point right to the end of the project)

“Extra”

A placeholder for “extra” stories.

If we really do clear all the stories on the board, this area is a placeholder in rough priority order for the next 1 or 2 stories we might play. These are not broken down into tasks unless there’s certainty that we’ll actually work on them in this sprint.

Physical Holders

A more traditional lean technique. We have an individual holder for 1-2 pads of each color of stickies. We can quickly see if any are running low and replenish stock. We also have a holder for story cards although that’s rarely used (we generally don’t add stories when stood at the board).

There’s also a holder for pens. We ensure there’s enough marker pens in the holder for everyone to have one during our standup and we ensure that there’s one of each whiteboard pen color needed for drawing graphs and totals on the board.

Hours (on stories)

This is the initial estimate in effort hours of all tasks we identified prior to & during sprint planning that went onto the board at the start of the sprint. We compare these with total hours completed at the end of the sprint to learn from and improve our tasking and estimation.

Over time we hope to gather enough data to see the typical ranges of hours spent on stories of each size (we expect a bit of overlap)

Sprint Tasks

Our second main horizontal swimlane is “sprint tasks”. These are all the activities required by us as a team in order to be able to complete the sprint and usually deploy our working software to production.  We also tend to add extra technical debt cleanup items into this swimlane.

This approach seems better at the moment than having specific (and artificial) stories for these activities.

It’s up to us how much trade-off we have between sprint tasks and story tasks in a sprint. Since creating this swimlane we’re finding 40-60% of our effort is going into this area however this is because we’ve been prioritising some technical debt and deployment improvement activities. That rate will adjust over the next couple of sprints.

Support/Bugs

The bottom swimlane on our board is for support issues and bugs. Right now we’re not using this very much as our support and old bug fixing activity has been relatively low.

We’ll see how useful this lane is longer-term.

Note, bugs related to work we’re actually doing are either fixed immediately and not added to the board at all or are added into the stories swimlane relevant to the story they’re found in.

Todo/Next/WIP/Done

Todo, WIP and Done are the typical status lanes for tasks you see on most boards these days. “Next” is an addition we added in very early on and has been a bit of a game-changer in managing the flow of tasks effectively here’s a link to the full article on the “next” column.

Retrospective Input

I talked a little bit about this at the UK Agile Coaches Gathering this weekend and I’ll expand more in a standalone article shortly. Put simply, we found that getting potential retrospective input visible every day during the daily standup has been more effective in driving continuous improvement and makes it easier to collate retrospective data at the end of the sprint. Mike Pearce also recommended something similar over the weekend – maintain your release and sprint timeline with pitfalls and lessons so that there’s less head-scratching at the end.

Graphs:

We’re tracking burn-down of task hours for both sprint tasks and story tasks in parallel (different colors). Then on the same graph we’re also tracking the burn-up of total capacity. It’s working okay for us at the moment but I can’t help thinking it’s still not quite right so I’m sure we’ll revisit this.

Beneath the burn-up/down we’re tracking per-sprint velocity as a basic bar chart. Straightforward, simple, easy to complete and easy to understand.

Sprint Schedule / Countdown boxes

As of the end of the last sprint we removed the sprint schedule, the list of historic dates wasn’t adding anything for us. We have the current sprint dates at the top-left of the board instead and have used this space for a set of countdown blocks 10..1 with effort hours to do and forecast remaining each day. This gives us immediate feedback as to whether we may have a problem in meeting the end of the sprint with current task scope. I’ll write up the experience on the countdown boxes separately once we’ve been using them a while.

“Done Done”

This serves a couple of subtle purposes…

There’s something very satisfying about taking tasks from the board and dumping them in the “done done” box.

We clear down the board into “done done” at the end of each sprint. This makes it clear that we’re not really done until we’ve completed everything and cleared the decks.

Although the box itself is basically a trash holder, it serves as a constant reminder that we’re not done until we’re done 🙂

We’ve added a few more things since I drew the original picture of our board…

Running Totals

After the daily stand up we sum up the total effort hours for each horizontal/vertical swimlane square/block and scribble those on the board. We can then transpose these into tracking graphs.

Right now we only track todo by horizontal lane and overall done but we have the data available for cumulative flow tracking if we feel the need.

Debt

We’ve added a very small space for newly accumulated or discovered debt related to our current work. It’s deliberately small to keep things minimal. When it fills up we’ll need to do something with it (if not sooner). It gives us one more line of slack if things go unexpectedly in a sprint for some reason whilst we still focus on deploying working software. This is still a running experiment but the intention is to treat this like credit card debt – it’s a short-term postponement mechanism, not a backlog.

Next Sprint Tasks

In much the same way as we have “extra” stories, we’ve added a placeholder for tasks we need to do in the following sprint but don’t have capacity for right now. This stops us overloading the current sprint tasks lane once things start moving without forgetting important future activities.

An Update (November 2013)

I’ve been rooting through my old photos and found a picture of the board toward the end of the project (September 2012) so you can see what it *actually* looked like as it evolved beyond what I’ve described above.DevOps Email Marketing Project Board Sept 2012

If you’re interested in even more whiteboard designs (and how they evolved over time) take a look at “A Year of Whiteboard Evolution”.

Closing Comments…

Don’t be afraid to adjust your working area if things don’t seem to be flowing right.

This isn’t the end for our board adjustments, what we’re using will certainly be different in a few weeks time however today it serves our needs well and must remain simple enough for new team members to understand.

I strongly recommend reading Henrik Kniberg’s recent book. I read the review draft last week (July 2011) and saw close similarities in the board structures the PUST teams at RPS were using and what we have here. I also share the same view as Henrik that each team – even within the same group – should be free to choose their own board style.

Try taking a few of these ideas away to experiment with but you probably won’t need them all.

5S Your Scrum Board – (Part 1) – A Place for Everything

Posted on by
Reply
Reading time ~ 3 minutes

Some weeks ago I joined a new team. I don’t like causing disruption but I do like to get the pace of improvement going on my teams. Here’s how we started out together…

During my first week I observed my new team’s activities. They were trying hard and doing pretty well but hitting some hurdles. Their most obvious challenge was the impact of covering support activities and cleanup tasks in addition to new story delivery.

Other than the loss of expected delivery capacity, this unplanned work was causing problems during stand-ups. The flow and continuity of useful conversation was being lost as the team stopped to hunt around for the right coloured super-stickies, a working marker pen and figuring out where to put the tasks. (but… they were aiming to get these tasks visible!)

So…

Borrowing some 5S tricks from Lean, I started work…

  • Seiri (Sort); eliminate all unnecessary tools, parts, and instructions.
  • Seiton (Straighten); a place for everything and everything in its place.
  • Seiso (Shine); clean the workspace, and keep it clean.
  • Shitsuke (Sustain); don’t revert to old ways, continue looking for better.

I skipped Seiketsu (Standardize).

Each team I’m working with is establishing their own natural, effective way of working within a common framework. I don’t believe seeking further standardization is something that will help them right now. (Although I’ll be setting up a community of practice for sharing successful and failed ideas shortly).

We added a small new change to our board, stand-up and/or tracking every day over a week – generally this involved scissors, tape, markers and old cereal boxes!

We reviewed & cemented the successes and added a couple of bigger changes during our retrospective.

Here’s the current result. – I’ll post a photo in future (I’m writing this at home on the weekend).

scrum board with placeholders

Using the peripheral space for useful stuff

Clearing the decks, having specific right-sized places for consumables (colored sticky pads  pens, story cards) and swim lanes for support items & cleanup tasks solved a number of problems quickly…

  1. The support/new work split is clearly visible and we’re able to balance it better.
  2. For new work, we’ve reduced the number of planned stories on the board to a minimum and have a clear priority order.
  3. The team are now in the habit of making all new tasks visible on the board without interrupting the flow of the stand up – it’s not such an effort to add new tasks any more.
  4. There’s always enough of each coloured sticky pad and some pens right by the board. If the holders are looking empty, one of us restocks.
  5. Progress and status are clearly visible at a glance so we know if we have a problem and whether to adjust.
  6. The team felt like things were under more control. Allowing them to focus on doing their best work and to try other improvement & collaboration activities.

When the team started their next round of sprint planning we had another 5S lesson – Seiri…

The great thing with this team is that all stakeholders are on-site and easily accessible. Having faced a painful hurdle on their previous sprint with a story that turned out to be significantly harder than expected, they discussed and adjusted priorities with their sponsor.

They pulled the part-completed story off the board, moved it right down the backlog and picked up something cheaper.

The team completely reset their board at the end of the sprint – even with work started or planned but unfinished – just to remove all the noise.

Interesting (but obvious) side-note – Perceived value is influenced by perceived cost. If something looks too expensive, previously less-valuable items become worth discussing and implementing.

IF the team were going to continue unfinished work, they would re-evaluate the remaining and  completed tasks, understand why they didn’t finish, learn and re-plan appropriately rather than assuming what’s on the board was correct.

Longer-term, I’m expecting this approach to also encourage more flow/pull-scheduling of stories. I’m aiming for us to only pull new stories onto the board when there’s a to-do slot free.

Finally I stepped back for a while to let the team self-organize and see if they could sustain the changes (a trick from my friend Carl).  About 80% of the changes have stuck with no support needed. Progress tracking and clearing the board down have needed some revisits. There were specific causes for these falling over but they’ve been recognised, addressed and are back on-track again.

In Part 2 I go into more depth on each of the areas of the board, what they do and most importantly why use them.

Have We Started Yet?

Posted on by
Reply
Reading time ~ 2 minutes

Here’s a great, simple tool for tuning and visualising WIP (Work In Progress) on your team.

Add a “Next” column between “Todo” and “In Progress” on your Scrum / Kanban board.

Team members only pull items into “In progress” from the “Next” column – and only when they actually start work on it, not when they plan to work on it.

Keep the “Next” column itself deliberately only wide enough for 1 task and replenish this with team input on priority/necessity when the “Next” column is empty.

This simple clarification has a huge impact on knowing who’s really doing what, when something has actually started and what we intend to do next.

For one of my teams I’m working with at the moment, this small tweak has had a knock-on impact of dramatically reducing the number of items in the WIP column to at most 1 per person (many tasks are covered through collaboration), per type of work (new features, debt/cleanup & support).

The team now use the full width (3 tasks wide) of the WIP column to indicate coarsely how “done” an individual task is (rather than filling the width of the column with potentially active tasks) which in turn has given us all much greater visual clarity on whether we’re actually going to reach our next goal – even when sat 10-15 feet from the board!

Here’s an example of what we have…

card wall picture

It’s really rewarding to see a team that instinctively “get” the value and benefit of simple visual management.

Give this a try with your teams and see how it works out.

I’m pretty sure next sprint we’ll only be pulling 1 story onto the board at a time – I’ll post about this in future.

 

Yellow is the new Green

Posted on by
Reply
Reading time ~ 2 minutes

It’s time to stop declaring the status of your projects, programs or features as Green!

This post is inspired by conversations with and presentations from Maxwell Keeler, VP product development at The Motley Fool during Agile 2010.

Max highlighted that after a few short weeks of Red/Yellow/Green meetings (or Red/Amber/Green – RAG in the UK), team status reporting rapidly morphed into “Green” meetings.

This pitfall cascades from management into teams themselves. If you report things as “green” to your management, those people working for you may have difficulty telling you that things aren’t green.

Here’s how RYG status should be treated…

Red – something is wrong, we’ll fail without intervention.

Yellow – there are some troubles/concerns that need to be managed through.

Green – everything’s groovy baby.

Here’s some common but poor reactions to these reports…

Red – Escalate! Drop everything, throw all resources at this unless there’s a higher priority fire elsewhere. Put the project and team in the spotlight until the fire is out.

Yellow – Escalate! Drop everything, throw all resources at this unless there are higher priority fires elsewhere. Put the project and team in the spotlight until the fire is out.

Green – everything’s groovy baby.

I was once even warned off saying “too much” on status calls in case sharing my concerns would create additional work for me!  I ignored the (now ex-colleague’s) advice – I aim to set the tone for my teams and organization myself.

Because of the fear of kneejerk responses, here’s what behavior is driven on the reporting side…

Red – my project is in failure mode, I should have raised issues sooner but I can’t hide from the problems any more.

Yellow – my project is on the brink of failure mode but somebody else has spotted it and called me out so i can’t hide from it any more.

Green – I’m busy enough without any extra scrutiny. If there are problems, they’re staying hidden as long as I can keep a lid on them.

It’s not surprising that “Yellow” generates a strong leadership reaction in these circumstances – it’s a vicious circle.

It’s time we called everything yellow unless there really are no problems. Colors are the “elephant test” for whether your project will succeed. Unless everything’s groovy, go for Yellow but where possible, ask for (or provide) real information and engage stakeholders to see the actual status or projects, not just their colorful abstraction.