Tag Archives: feedback

Seeking “Customer” Input

Posted on by
9
Reading time ~ 3 minutes
Overgrown statues
The hidden beauty of exploration

Those of you that have been following my posts in the past will have noticed my output has significantly reduced in the last few months. I still have plenty of articles to write but I’ve chosen to spend much more of my spare time outdoors exploring “old places” and enjoying rocks, trees and water and those things that are half-forgotten.

However…

I still want to keep writing and feedback I’ve had is that it’s been worthwhile for you readers so far – so how do I get more focused?

…

You’ve (hopefully) seen the fairly broad spectrum of things I write about already. Rather than my continuing with random musings as they surface (or mature naturally from my backlog of posts) I’d like your input.

Taking a cue from an article I read a few months ago (I really wish I could remember the site and author) I thought I’d share the headings from my backlog publicly.

If any of the draft titles below spark your interest, please comment and let me know and I’ll prioritise them in my backlog and work on expanding them into full posts.

Similarly, if they inspire something else that you think I could share, just shout.

All the best from the shores of Porta Rossa

Captain

The Captain’s (Back)log

  • Analysis Vs Delivery
  • Why You Should Stick to Using Whiteboards & Stickies
  • Estimates Are Not Commitments
  • Sub-optimizing Around Data
  • User Story Myopia
  • On Average Everything Is Average
  • The Story Point And The Damage Done
  • The Cuckoo’s Egg
  • The Automobile Association (On Setting Customer Expectations)
  • What’s Wrong With Your Picture?
  • The Problem With Big Problems
  • Give Me Something To Critique
  • Using The Pirates Code With Agile
  • Trust or Blame
  • The Management “Middle Tier”
  • Managing The Sushi Bar
  • Using Real Options With Your Suppliers
  • Scale, Supply And Demand
  • It Really Does Depend on Context
  • Stop Trying To Fix Your Weaknesses
  • Dietary Manipulation (Part 6) – Eat Together
  • Dietary Manipulation (Part 5) – Have a Beer
  • Dietary Manipulation (Part 4) – “Do Food”
  • Scrum/Kanban Board Refactoring
  • The Pitfalls of Measuring “Agility”
  • Single Piece Flow and Trading Out Stories
  • My Job is to Make Myself Redundant
  • Escaping The Oubliette (Part 6) – The SWAT Team
  • Escaping The Oubliette (Part 5) – Sponsorship
  • Do No Harm
  • Commitment & Planning Horizons
  • Project Envisioning with Six Stickies
  • Don’t Wait For a Retrospective To Improve
  • Technical Debt – Eating My Own Dog Food
  • Technical Debt (basics)
  • Critical Chain Estimation
  • Thinking Too Big
  • Creativity
  • Pairing, Peer Review and ISO
  • 1,000% Improvement Is a Statistical Outlier
  • Stop The Line
  • Zero Defects
  • What Documents Do Your Projects Produce?
  • Burn Down Chart Patterns
  • Business Cases & Portfolio Management
  • Legacy Code Vs Legacy Product
  • Limited WIP
  • Trust
  • Meeting Commitments or Delivering Value
  • How To Get Buy-in to Agile
  • Product Owner?
  • Inertia
  • Marketing and Follow-Through
  • Telling Vs Coaching
  • Ubiquitous Language Does Not Mean Japanese Jargon
  • Defusing The Politics
  • Why Agile is Harder than Waterfall
  • Don’t Ignore Your Environment
  • The Elephant in the Room
  • Broken Windows
  • 5 Whys
  • 6 Thinking Hats
  • Debunk Sessions
  • Risk & Reward
  • 3 Points are Better than 1
  • Desire Lines
  • The Power of Team Casting
  • Using Stage Gates to Your Advantage

*edit* – my first vote is in already from @fatherjack (thanks!) “Telling Vs Coaching” coming up next.

Another edit: Oct 2012 – thanks everyone for continuing to comment and vote. The top 3 items from the backlog by voting/popularity have now been delivered. I’m likely to write a couple of new ideas up whilst they’re fresh and then get back to the requests again!

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.