Tag Archives: tool

2 Visual Management Tools to Help Evaluate Your Options

Posted on by
Reply
Reading time ~ 4 minutes

Back in December 2012 I moved to a new team – from what was DevOps to .NET (same 3 roles as before – Dev Manager, Project Manager, Head of Project Management).

As part of my ramp-up on the team, products, customers, market and current challenges I was briefed by my new Product Manager and Division Head on the areas they’d like me to focus for the next few months –  and asked to deliver some draft plans for each of these.

I scratched around online to find a suitable A3 problem solving template as a thinking tool and struggled find anything that was quite suitable. The majority of A3 problem-solving tools are around defects/quality and root-cause analysis.

There’s a lot of wisdom in performing an RCA for a problem but sometimes you just need to move forward (see my “stopping the line” article).  In my particular case the change of teams would not be confirmed until I could satisfy my new potential boss that I was capable of covering their needs. In order to prevent confusion and disruption, this meant “going it alone” on my first iteration of a plan without interviewing the team on their thoughts. That makes performing an RCA problematic.

Here’s the A3 template I used.

Click here for a link to the PPT version

This got me far enough to complete the review – a win!

After discussion, I moved onto deciding next steps. Moving form vision and strategy to plans and actions and found that whilst I had a set of options, my timing was bad. The following week was “Down Tools Week” for all our development teams. Nobody was freely available to hassle about current projects and products and I didn’t want to interrupt the amazing things everyone was doing.

Rather than waste a week, I moved onto priority number 2 – increasing the team’s customer understanding. This needed less input but was also less well-formed in terms of approach, options and actions. My original plan had suggested one possible option but during review, it was felt I needed to provide and evaluate some alternatives.

I had the information to achieve this but hit a wall.

After half a day of thrashing with a blank slate I approached my new Division Head and asked for his help. I explained I was blocked. I had the right information but couldn’t move things forward. We spent 10 minutes discussing the problem with him essentially working in “Rubber Duck” mode.

After talking through the blockage we established a way forward. We discussed the (now much longer) list of options and an initial set of evaluation criteria for these. And I agreed to turn this into “some kind of evaluation matrix”.

As soon as I returned to my desk things fell into place…

We regularly borrow a few visual management techniques from Lean (we had a former Toyota UK guru spend a day a week here for a couple of years consulting with us on a wide variety of management topics).

One particular technique that has proven exceptionally effective is the visual representation of “Good/OK/Bad” using a colored circle, triangle and cross. When we were first introduced to this notation we were sceptical. Now, 3 years later we have a common visual form that all managers understand with patterns that can be seen at a glance and the approach is part of our routine reporting across all areas of the business. Even the monthly roll-up report for all projects I track across the entire development portfolio uses this same notation.

I took the list of options we’d been discussing and both positive & negative evaluation criteria, applied them to a matrix and used the (then new) notation to capture my thoughts.

Here’s the outcome.

Without any reading at all, the 3 strongest options stood out. Better still, this technique didn’t need anything more than expertise and instinct. I’m free to follow up with further research and evidence if needed but at that point we were after a first-cut and a quick narrowing of options to focus our efforts.

There’s an important subtlety in this notation to be aware of. A yellow triangle means “OK”. It’s not a problem but we think we can do better. A green circle means “Good” – we mean really good – not just “fine”. This ties back to an article I wrote back in 2011.

When we report something as “good” on a project status, we expect supporting evidence. When something is “ok”, we ask “how can we help or improve this”.

What this evaluation is saying is that we have a couple of really strong options that would help us achieve our goal. They’re strong rather than just the best of what we have.

Next time you’re trying to figure out what to do, try these 2 visual management and thinking tools as a way of unpicking and reassembling your options into something simpler and more cohesive. If you’re lacking options that have enough “good” points, try some more alternatives, don’t just big the best of a bad bunch.

(In the end I spent a year working with the .NET team. and shared a sample of the results here. )

 

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?

What’s on Your Radar?

Posted on by
Reply
Reading time ~ 2 minutes

This is a great tool that I first saw used by Thoughtworks for showing changes in technology trends over time…  http://www.thoughtworks.com/radar/ (I don’t know who invented it). The TW example is very busy – there’s a mountain of new & changing technology trends out there!

But. This is a fantastic simple tool for tracking changes in your own domain or environment. And it doesn’t have to just be technology, this could be customers, prospects, types of work, focus areas, anything.

Here’s a sample I’ve put together for agile coaching . The Arrows show a change in focus since the last review (typically quarterly).  This is deliberately not an exhaustive sample but gives an idea of the what you can achieve.  It’s a great clarifying tool for both your coaching teams and your stakeholders.

Detail on the numbered items in this example:

1: TDD – Introduce, train & coach TDD practices. Ensure teams have the tools available to do so and the space in their schedules to do a decent job. Performance will turn the corner after an initial productivity dip so this needs a lot of care & attention.

2: Code Smells – Train teams on identifying code smells and when to act. We need to back this up with being polite & positive – perhaps some collaborative walk-throughs.

3: Refactoring – With TDD & Code smells, teach the “right” level of refactoring. There’s the natural refactoring needed during development and then there’s the open heart surgery of bad legacy code. We could refactor entire products and move nowhere (@see Netscape). Need to make sure this pragmatically taught.

4: Embedded coaching – with the major increase in XP and technical practices over scrum, we greater technical embedded coaching capacity.

5: No new code without tests – Make it socially unacceptable to check-in without tests unless there’s a real reason. (“It’s not testable” is usually an excuse, not a reason)

6: Shared code ownership – It might have been your baby once but it’s time for others to see how ugly it is and help you pretty it up. Nobody “owns” code any more, no matter how much of their creative heart & soul is invested.

7: Zero defects – We still have a crazy defect backlog. Let’s stop the bleeding this year and get it under control. Longer term we’re looking to get down to a stable level of entitlement.

8: Feature Teams – we’re working as product delivery teams and communities of practice right now which is ok but we need to get to a point where we can deliver fully working features through the product suite as a cohesive team without handovers.

9: Scrum – teams are all now using scrum as their overall operating framework, observing the “rituals” etc. We still need to watch & adjust but the main effort is over, this is now normal operation for the teams.

10: Agile Metrics – We’ve taught the teams and managers how to understand the new data they’re seeing, use it to their advantage, to make reasonable forecasts and highlight problems early. Again this will stay just over the horizon, it’s not going away but not something we plan to revisit for a while.