Dietary Manipulation (Part 2) – Carbo-Caution

Posted on by
Reply
Reading time ~ 2 minutes

My first article on dietary manipulation was intended to be the last. However as I learn, so I must adjust…

Some time ago I had the pleasure of guiding a team through a backlog prioritization session – taking items from a large unsized, unordered backlog down to a subset that we believed could be achieved in a short window of time (either in the next 6 weeks or to the end of the summer).

I had the benefit of free lunch in the staff canteen. At the time I wasn’t sure if the food selection was normal for the site or if it was just an end of the month special – either way, the food was very good. Although there were salads and yogurt, it was frighteningly easy to load up on a mountain of well-prepared comfort munchies.

The session I was running was scheduled for about 2-3PM.

Can you see this coming?…

Remember how I previously loaded a team up on carbs so my audience would hit their low-ebb during a difficult patch?

…

When I’m leading a workshop with an unfamiliar group I’m not very good with pauses & quiet periods so I tend to fill in the gaps (I already know it’s a weakness for coaching). Despite the mix of comfy armchairs and the post-lunch downturn, the team did a great job. They were very tolerant of my ad-libbing and ran the exercise in really good faith but even so it was really hard work for me.

The good news is we achieved our goal in just under an hour. A small, actionable, prioritized set of “must do” items for the team to dedicate some time to clearing before the end of the summer.

Next time, I’ll try loading up with fresh coffee and see what we can get done in 30 minutes and before everyone needs a bathroom break 🙂

…

Epilogue: – I’ve just started working with this team full-time. The food is that good and the team are that accommodating all the time.

Must try to remember… No mid-afternoon team workshops. Oh and …must… …stick… …to….  salad & smoothies.

Well – sometimes.

Black Holes & Revelations

Posted on by
Reply
Reading time ~ 3 minutes

Have you ever had to deal with a black hole on your team?

“As predicted by general relativity, the presence of a large mass deforms spacetime in such a way that the paths taken by particles bend towards the mass. At the event horizon of a black hole, this deformation becomes so strong that there are no paths that lead away from the black hole” – Wikipedia

I’m not a physicist so here’s a simplified view that I can fit in my smaller brain:

Black holes are like huge “gravity traps” sucking in all energy from the surrounding area. Energy and mass are drawn toward the event horizon, sucked in and lost forever. The more they take in, the larger or denser they get.

Here’s some cool stuff I learned from Karl Schoemer a few years ago.

A team undergoing change can be coarsely divided into 3 behaviors: Design, Default and Defiant/Detractor.

• The “Design” population are your role models; your supporters & change agents – but be aware, some may have short attention spans or become zealots. This is up to 20% of your population.
• Those following the “Default” behavior will sit on the fence; “What.. …ever”, “it doesn’t apply to me”, “I’ll carry on as I am thank you” are all common “default” responses. Typically this is 70% of your population!
• “Defiant/Detractor” behavior exhibits extreme symptoms including shouting, arguments, tantrums, sabotage, threatening to leave and pulling everyone else down with them. Less extreme responses include focusing on the minutiae, public cynicism and endless debate without action. In many cases, whilst this may seem prevalent, often this is actually as little as 10% of your population!

Now let’s return to the Black Hole. In space, black holes are invisible – only their effects can be seen. In change management, we simply fail to recognize and identify them.

Human black holes must be understood and handled with extreme caution.

For those inexperienced with black holes, your instinct will be to try and defuse them. You must spot when you are feeding a metaphorical black hole, rewarding negative behavior by pouring your finite energy and resources in. Feeding black holes provides them additional credibility in front of their peers – their gravity trap grows ever-larger.

Lean values time… Eliminate waste! – Where are you wasting your energy?
If you removed the energy feeding a black hole would it eventually burn out?
In human change, detractors usually either get with the program or leave.

If you’ve read some of my prior articles you’ll know that whilst I appreciate good people; if your behavior and attitude isn’t up to scratch, all the technical prowess in the world is unlikely to make me want you on my team.

Some black holes may be an almost permanent rift in space. Work to minimize their impact and sphere of influence rather than offering more fuel. Consider using them as your “professional cynic” – your sounding board for the detractor response – but be aware this is a lot like playing dodgeball with a burning coal. It’s usually safer to move them away from the powder magazine instead.

Where could your wasted energy be better spent?
Simple! Use it to shift the center of gravity on your team away from the black hole.
Partner with your “design” members as a team and swing your population of defaulters toward your chosen direction. Some may be pulled toward or into the black hole but work on the overall gravity shift to bring the team around.

If you don’t have sufficient design weight to adjust the center of gravity right now, go digging for more – one person at a time if needed. At some point you will be able to tip the balance.

(Oh – a nod to Muse for inspiring the title of this post)

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.

Intellectual Humility

Posted on by
2
Reading time ~ 2 minutes

I love having conversations with people I respect, look up to and know are an expert on a subject I’m interested in (and usually ten others besides).

Every now and again I’ll find myself nodding sagely as they reference some great wonder, piece of writing, language, blog, book, person that they assume I know about.

There’s a good reason that I nod along…

I don’t want to interrupt the flow of what they’re saying, it’s interesting and I want them to continue uninterrupted as I take what they’re saying on board.

There’s also a bad reason…

My intellectual ego is seeking their respect and validation. It’s preventing me from admitting that I’m struggling to comprehend.

Unfortunately in a group situation, this momentum can carry us too far. Once the thread has reached a suitable stopping point, how often are we willing to go back and ask for an explanation, more context or admit that we “don’t know” something that someone else assumed we do.

Watch out for rooms full of people listening to something they don’t understand and nodding, not wanting to interrupt and secretly not willing to be the first in the room to break the seal on their lack of knowledge.

What time do we waste walking away not understanding the full picture and having thrown away the best opportunity to seek clarity?

When you don’t know the answer or don’t understand, don’t pretend.  Lead by example and others will also be encouraged to ask or research and share. This in turn will build a stronger knowledge culture for your teams.

There’s no such thing as a dumb question. If you thought of something to ask in a room full of people I guarantee at least one other person will have as well.

Avoid playing intellectual chicken, be proud to ask the first dumb question of the day and get people to respect your intellectual humility rather than your intellectual ego!

The Joy of Peer Reviews (Part 2 – Documentation)

Posted on by
1
Reading time ~ 4 minutes

Another agile management myth to dispel – agile projects have no documentation…

The level of documentation you provide depends on the needs of your stakeholders.

About a month ago I spent some time discussing code reviews and promised a follow-up on document reviews.  Since then, the number of documents I’ve needed to work on or review has been pretty slim so there’s not been much scope for inspiration.

One of my teams are coming to the end of a major release and our product managers are re-evaluating parts of the portfolio. Both of these events drop us into some more traditional documentation areas for a while.

Before I progress, there’s three types of documentation we tend to deal with on a project.

  • Product documentation (user-facing)
  • Control documentation (mostly management-facing)
  • Technical documentation (mostly team-facing)

We produce a lot of information in all these areas but of most of it isn’t as formal documents.

Here’s the bits we treat formally…

  • Vision, business needs & minimum marketable feature set
  • High level plan (priorities, scope, cost, schedule, quality)
  • Significant, complex or high level designs (functional or technical)
  • End-user and admin guides
  • Significant scope changes (change control)
  • Closure (agreement from stakeholders that we’ve met commitments)

Before going any further. The main rule of thumb in documentation I follow is:

Strive to keep your overheads to a minimum

Focus on the level of documentation needed by the relevant stakeholders and seek alternatives where feasible. For example user guides & help files may be better replaced with automated drive-throughs, screencams and audio descriptions. Project reviews may be best served with a conversation, a single slide with some visual anchors and a sign-off.

My teams have had cases where we felt we needed more documentation because we weren’t happy with the level of traceability from our less-formal approaches.  This tends to vary depending on what levels of organizational trust exist and how much protection you may need.

Where you do need formal documentation – regardless of which of the above types it falls into here’s my basic document delivery and review guidelines…

Delivery

It’s remarkable how much good documentation is very like code.  My mantra is “deliver early and often”.

  • Start by delivering the scaffold, walking skeleton or spine of your document and get that out for initial feedback on structure.
  • Consider swarming your team around parts of the document to accelerate delivery.
  • If you have interaction across teams, ideally have the teams write their components for you – do the editorial but they cover the “meat”.
  • Balance time invested with expected value – especially before initial reviews
  • Start adding flesh to the bones one section at a time.
  • As each section is “good enough”, send it out for a draft review.
  • Following review, rework the meat and polish
  • As major themes come together for completion, review again for cohesion.

I find there’s one large challenge in writing documents – Inertia – don’t underestimate the effort needed both to get moving and to be properly finished.

Most experienced coders understand about getting into “the zone” or being in “flow”. This same situation holds true for writing documents however personally I find it’s much harder to start moving on a document, takes more sustained effort for completion and requires more polish than my code. Once you are in flow. Stopping is equally hard. Much like delivering small frequent reviewable coding tasks takes practice, so the same applies for documentation. The team approach to documentation is a great way around this once you have a scaffold in place.

Review

If producing documentation is like cutting high quality code, then it should be no surprise that reviewing documentation should be treated with similar respect.

Bear in mind, usually when you’re reviewing documentation, you’re probably at a point in the cycle where you can prevent major defects and costs in future by asking the right questions.  Reviewing documents is not a hurdle to overcome it’s an essential quality step in setting your projects up for success and in ensuring we have consensus and understanding on results.

I’ve divided the checklist into 3 parts. “Thinking”, “Approach” and “Review”.

Thinking

A few considerations to make before starting the review itself (and before submitting for review)

  • Discipline – treat this review just like you would a code peer review.
  • Should it be a document , could it be something else?
  • Who is the intended audience, is it pitched at the right level?
  • Is this technical, control or product documentation (and how does that impact our approach)?
  • Is this primarily for management, the team or our customers/users?
  • Is this document transient or permanent?
  • How critical is accuracy/precision? (compare for example to scientific or medical papers)
  • How will this document be maintained and who by?

Approach:

What form is the review going to take?

  • Round table vs offline – will the review be individuals at desktops, as a round table session or a mix of the two
  • Piecemeal or big bang – I mentioned my preference for part-deliveries. This only works if you’re willing to perform part-reviews.
  • Feedback cycle – how will you manage feedback? For large critical documents I usually forecast 2 rounds of review/rework and a total elapsed time of 2 weeks from the initial draft to completion. (that’s assuming a well-managed but not top priority review cycle). The author/coordinator should have this at the top of their stack until it’s “done done”.

Review

Points to look for – these start simple and get trickier as you go through the list.

It’s disturbing how many people only review using a subset of the top items here and get no further. Lazy reviewers may read a document without actually reading it. (Although perhaps this is a reflection that we’ve missed something in the perceived value of a document)

  • Document information and headers/footers are correct
  • Consistent formatting & numbering e.g page numbers, typefaces, sizes
  • Spelling & grammar
  • Tables of contents & figures are up to date (ctrl+a, f9, update all – in Word!)
  • Cross-references work and point to the right locations
  • Related documents or prerequisites are both accessible and necessary
  • Use of correct templates where required
  • Proper heading formatting – helps with maintenance of TOC
  • Use of change tracking and versioning
  • Identify reviewers, owners, approvers
  • _________________________________________
  • Lots of words when a picture would be better
  • Emotive descriptions (where not valid)
  • Unfounded facts and numbers (particularly sales, estimates and time lines)
  • Impacts on other teams (especially without consultation)
  • Expectations from other teams (especially without consultation)
  • Over-optimistic statements (see unfounded facts and numbers)
  • Unbounded requirements
  • Missing assumptions
  • Alternatives and rejections
  • Over-technical or not detailed enough for audience
  • Length/brevity (much like some of my posts)
  • Emotional attachment to content or single approach/ideas
  • Any prior examples of similar to compare, reference and/or improve from
  • Voice of the customer (and their future accessibility)
  • Who are the decision makers and arbitrators,
  • A clear problem statement
  • Well-defined vision
  • SMART or Elephant goals
  • What does “good”, “done” or “success” look like?
  • Quality, acceptance criteria and tolerances
  • Any disconnects between related documents or teams
  • Anything missing

Phew! – as before, I’m sure there’s more.

To summarize in one sentence…

If your documentation is important to your stakeholders, treat it with the same reverence as your production code.

Agile Is Just A Means To An End

Posted on by
2
Reading time ~ < 1 minute

A couple of months ago I posted that software is just a means to an end.

Here’s an equally commonly lost point – in fact it’s almost identical.

Agile (or Lean, TOC, whatever) is a means, not a solution.

Our customers, users and stakeholders don’t want “agile”, they want “success”. Once they have success they’d quite like a means of making that success more repeatable but ultimately they simply want success.

We seek to promote our way of working (one of our goals as an agile community) but risk missing the actual goals of our stakeholders?

Our conversations should move away from Agile by name and onto:

  • how do we best attain our stakeholders goals?
  • how do we effectively identify those goals?
  • how do we attain consensus on what those goals are?
  • what do “success”, “good” and “OK” look like for everyone involved?

If we step back, agile is just a marketing term – a simple pattern for a collection of mostly proven ways in which we believe we can work effectively. Where we need that marketing or verbal anchor, let’s use it – (much like we’ll use whatever agile practices and culture we know are useful in attaining our stakeholders goals) – but let’s ensure we’re not having methodology and culture conversations for the sake of methodology and culture alone.

Before diving into “agile” discussions, step back and (re-)establish what success should look like for your customers and users from their perspective.

Express Your Real Motivations

Posted on by
3
Reading time ~ 2 minutes

Hidden agendas make you unpopular, especially those that are poorly concealed.

Everyone has an agenda. I prefer mine open and public. Some may try to take advantage of that but most will respect it…

Some time ago I attended a session with a team where there had been some communication challenges. The team’s normal very tight, cohesive ethos was fraying.

As a globally distributed coaching team they’d arranged to co-locate for a week to bash out a few things and generally get together before returning to their usual sites.

Dinner and a couple of beers into the first evening together and the team spirit had started to sparkle again – recognizing each other as friends, not just colleagues. The hint of political undercurrent was still gnawing at the edges of the smiles.

Into the second day and one of the very perceptive team members called a halt to proceedings.

My paraphrasing of the conversation…

“OK, time for a break. Before we go on, let’s catch up with each other for a bit… …why are you really doing this job, what’s your motivation – what’s your angle?”

This team knew each other well enough to already know the answers but actually calling them out publicly in front of each other was a new step in uncovering potential hidden conflict.

Because the team ran on trust and acted as a balanced cast (I’ll write about team casting in future); everyone acknowledged and accepted each others’ motivations knowing that despite being potentially sensitive they were honestly and openly given.

Even better, they discussed how each other could support those motivations.

The politics and tension were gone.

Earlier this week I watched someone with a blindingly obvious personal motivation attempt to leverage it in front of a smart bunch of people who were mostly there for related but different reasons. Rather than a public calling out, it was handled through amiable debate over a beer later but everyone in that following conversation recognized the unspoken calling out had been made and started trying to re-engage and collaborate.

Or at least I hope they did

In keeping with the spirit of this post I therefore share my own agenda…

  • I’m naturally creative and like to share
  • I seek personal but usually not financial reward
  • I want to be recognized for “good” things

I strive to make a positive difference by sharing my thoughts or observations and by participating in conversation. I seek personal reward through constructive intelligent feedback, good friends and good company.

Escaping the Oubliette (Part 4) – The Litter Patrol

Posted on by
Reply
Reading time ~ 2 minutes

As promised in my last installment on oubliettes…

Your team might not be fully ready for the merciless refactoring encouraged by some agile approaches but this will help you stay heading in the right direction whilst keeping the delivery vs refactoring impacts balanced out.

The cost of change has a (roughly) logarithmic relationship to debt. I’ve seen first-hand how high-debt systems become almost impossible to change and it’s not pretty.

In a debt-ridden system we are eventually faced with a choice; refactor or replace. Eventually even once-newly-replaced systems build up debt and the refactor/replace choice returns. Craig Larman & Bas Vodde’s most recent book covers the debt/cost relationship brilliantly in the section on “legacy code”. They also describe the oubliette strategy of “Do No Harm” or as I call it – “The Litter Patrol“.

This is a particularly powerful debt management approach as it’s both a prevention and reduction strategy.

Here’s the basic concept…

When working with an area of legacy code, you’re working in a particular “neighbourhood“. If that neighbourhood is untidy your care and attention to that neighbourhood is diminished. Much like the “broken windows” principle; once the damage seal is broken, neglect and further damage follow and overall code quality deteriorates rapidly.

So (without going overboard), every time you’re working in a particular neighbourhood, what can you do to clean up a few pieces of litter?

Not the run-down shopping district between lines 904 and 2897 but more the abandoned classic car between lines 857 and 892 or the overflowing trashcan on the corner between 780 and 804.

If you introduce a litter patrol in your teams and encourage a hygiene cycle with every change to your code, your debt load and future cost of change will rapidly reduce for the areas you hit most frequently.

Unfortunately although this is easier than a complete refactoring of a poorly designed class-hierarchy or monolithic god-class, in order to perform the litter patrol in safety on your code you need good unit tests or small functional tests for that neighbourhood and ideally some refactoring support (I like to call these your gloves, garbage bag and litter picker).

This challenge doesn’t mean don’t do it. In fact if you don’t have tests already, maybe your next patrol isn’t changing the code at all but to write just a couple of small, independent tests to demonstrate how that area is expected to behave. (You might even need to make some tweaks to make it testable)

If it’s hard, don’t avoid the problem, focus on making life easier one bite or constraint at a time.

Every time we successfully deliver a small clean-up task, the future cost of change to that area is reduced and our incentive to keep it clean is improved.

Look out for part 5 – sponsorship – coming soon.

Distributed Management and Work-Life Integration

Posted on by
Reply
Reading time ~ 4 minutes

This was posted on my office wall recently…
Dilbert.com

It brought home what the last decade of international teams and ubiquitous business email access has achieved for many of us software professionals.

Since the late 1990’s I’ve worked in globally distributed or virtual teams. There’s a huge amount of positive things to be said about the working experiences I’ve had with these teams over the years.

  • My cultural boundaries have stretched
  • I’ve had opportunities to work with great people all over the world
  • I’ve learned a mountain of cool stuff
  • I’ve met hundreds of new friends
  • I’ve visited amazing places
  • and…

…

  • I’ve left my family at home most of the time.

Sadly small children and transcontinental business trips don’t really mix. My family have been incredibly tolerant and I always look to bring something back for them. They have a pretty tough ride but they support what I do and I appreciate their patience.

However…

With teams in the UK, India and the US there’s almost always a full working day of support, conversations and questions that happen outside the normal working timezone. As the pressure to deliver and support these teams has increased I find myself checking my work mail when I should be attending my family.

I recently reached the point where I was clearing my emails down during public holidays so that I could filter through and achieve something when I got in the following working day.

I check my email during breakfast at 6 or 7am and reply to things that came in during the US evening or India morning.

I commute to work and check my mail again to find another series of mails from India and a few UK early starters.

I check my mail when I get home from work to respond to anything urgent that came in during my commute.

I check my mail before bed in case there’s anything new that will derail my plans and priorities for the following day or that I can respond to before the US working day is over and 24 hours are lost on a decision.

(I also occasionally make time to write this blog, enjoy my family, study and maintain the house)

If I don’t clear my morning and evening international backlog my day job doesn’t have time & space to get done but this is all at the expense of other parts of life.

So how do I get things back under control?

WIP Limit vs Buffer Overrun

Here’s where Scrum, Lean & Kanban meet personal time management…

Set yourself a WIP limit. When that’s full, decide what doesn’t happen or has to be traded out. If you don’t make a decision, something will fall on the floor and chances are you’ll have a pile of half-done stuff. (a buffer overrun).

Build a visible backlog and keep it groomed. When new work comes in, prioritize and size it. (Take a look at the Covey Matrix as a powerful means of prioritizing). If I don’t have clear visibility to my backlog of work (not just my email inbox) then once again my mental buffer overruns and things fall on the floor.

This is where my problems are – relying on my mental buffer and inbox to be my primary and secondary backlogs!

Determine how big your backlog should be and whether it should be tiered (e.g. week, month, quarter). Just like a mature agile team, don’t build a backlog that’s bigger than your planning (or thinking and coping) horizon. If it’s important it’ll come back when you have the capacity.

Next, just like your agile projects, get your backlog visible. When new work comes in, take your stakeholders to the backlog and have a prioritization and trading out conversation.

Some things will have time deadlines and some of these you can’t avoid so what else has to give? If you have more items with time deadlines than you can cover, take your stakeholders back to your backlog and force the prioritization discussion again.

I recommend pipelining work into “emergencies“, “small“, and “not-small“. This is enough to provide an interesting mental mix but aim to limit multi-tasking to a maximum of one item in each area. (Clarke Ching has some fantastic insights and demonstrations on why multitasking is evil).

It’s also worth rewarding yourself. You’ll find items that fall in the “distraction” quadrant of the Covey matrix are often where some rewards lay hiding. Identify a few interesting, fun things and make sure they get some airtime in with all the priorities to pay off some of your priority fatigue.

Simple right?

OK, this won’t break the email addiction but it will help manage the personal backlog and priorities more effectively.

When it’s personal rather than a project this seems so much harder.  With all that time teaching teams to trade out and prioritize, it’s time I started to eat my own dog-food.

Epilogue: This article has been waiting in my backlog for a couple of weeks to be rounded off before publishing. Yesterday the manager I’m pairing with planted a large kanban board by my desk with a list of the top priority management goals and activities that we have on our planning horizon right now down the left hand side and the associated tasks and states all prepped up! It’s not our entire backlog but it’s well more than we can achieve in the next 2 weeks and covers all the known top priority things.

Now it’s time to start managing the load properly again.

Escaping the Oubliette (Part 3) – Bug Blitz

Posted on by
Reply
Reading time ~ 3 minutes

Every product team I’ve ever worked in had a bug blitz at some point and often one every year or two.

There’s no arguing that a decent bug blitz is a powerful way of getting the numbers down and clearing all the bugs in a good, solid drive feels good but the necessity for them is caused by a buildup from somewhere.

If you find you’re needing a bug blitz on every release, take a look at your defect and debt prevention activities and make sure you’ve got some topping & tailing practices going on.

Usually bug blitzes are performed at the end of a project but if you’ve not done so before, try having a 4-8 week blitz at the beginning instead. You’ll run quicker afterward and (if you keep things under control), you won’t have to worry about having time to mop up at the end.

Once you’ve got the numbers down, set your maximum defect threshold (or ratchet) at this level for the remainder of the project and keep this new lower level sustained throughout development.

What’s good about a bug blitz?

A blitz is particularly useful if you can focus on areas of the product you’ll be working with soon. It’ll get your team working together (particularly if they’re newly formed) and familiar with these areas before all the major work starts.

Couple this up with developing some decent automated tests in those areas as part of the defect fixing and you’ll be developing a much safer scaffold for your new work and reduce regression risks during your next release.

You could take things further and perform some refactoring but I suggest keeping different types of activities separate at this point and just stick to straight bugs. If you have a specific functional area needing a real overhaul, it doesn’t fit the bug blitz mold. I’ll cover this aspect  in more depth when I talk about “sponsorship” for debt reduction.

I use bug blitz approaches when training up new staff. I review the defect backlog for a particularly grubby functional area and have a pair of staff take custody of it as caretakers. We pipeline the defects so that they can start with some simple introductory ones (usually low severity, noise or cosmetic stuff) and once we get confident in these we expand out into adjacent areas – it usually takes a month or two for them to really get warmed up.

The bug blitz is also a great opportunity to start new release development with a clean slate. It means no mixing types of work during feature development and gives you an opportunity to scrub the grime out and get a few new scaffolding tests in place.

What about the down-side?

First; they cost time and money. If you dedicate a team (or most of a team) to a blitz you’re not delivering anything new. This is obvious but important. What’s the impact of a month’s delay to your next release? (assuming you can ship with those bugs in there). And what will that delay do to your stakeholder relationships?

Be mindful of the impact a bug blitz can have on your customers. A high level of churn on existing functionality can be really dangerous. You might need to make a point of jumping through a few hoops to retain backwards compatibility.

Don’t be too hasty to refactor if customers are expecting certain things. If you don’t have decent automated regression tests, you really need to ensure you write at least a couple that hit the same area before you fix any defects. (I usually expect my developers to deliver at least 2 or 3 new automated tests with each bug fix).

Worse still, I’ve seen a batch of fixes in a functional area radically change behavior “for the better” according to the developers that raised the original internal defects who then discovered that customers were actually depending on existing behavior or had developed their business processes around the issues.

Sometimes, even if you think it’s ugly, it might be that way for a good reason.

With enterprise software, you’re often looking at heavily customized implementations, some of which have taken years and millions of dollars to evolve.  Smacking these with a mountain of churn on existing functionality can be painful and expensive for your customers. Whilst it makes your numbers look good, consider whether some things should really be touched.

In summary. Bug blitzes are a great way of starting with a cleaner work area and ramping up teams but beware of backwards compatibility, customer impact, time and cost pitfalls.

Read part 4 – “the litter patrol“