Category Archives: People

The Egoless Daily Stand-Up

Posted on by
1
Reading time ~ < 1 minute

Back in about 2004 I was really proud of myself for coming up with the term “Egoless Development” in explaining my team’s approach to self-organization and collective code ownership. The concept was actually invented some years earlier than my use of it.

(egoless :: proud – an oxymoron perhaps?)

Somehow I doubt the author had Egoless Daily Stand-Ups in mind though…

Most of the variations I’ve seen on the 3 basic questions in a daily stand-up have a small but significant issue in common – they’re entirely ego-centric.

    • What have I done since yesterday?
    • What am I planning to do today?
    • Do I have any problems that would prevent me accomplishing my goal?

me…

Me…

ME…

There’s a mountain of guidelines on daily stand-ups (some of the best being Martin Fowler’s) so I’m not going to retread these. All I offer here is a tweak in thinking.

These are about the team, not you…

Consider these – either as questions themselves or in your approach to responding to whichever questions you use for sharing with the team…

    • What have I finished or accomplished that others on the team need to be aware of?
    • What am I going to “open the lid” on that I should confirm with others before starting?
    • Where am I stuck, who can help me and how does that impact the team?

How is the work you’re performing going to aid the teams commitment or goals?

As a footnote, Mike Cohn’s suggested 4th question for the scrum of scrums – “Are you about to put something in another team’s way?” works (at least in my mind) for the same reasons – it’s more about other teams than you.

Learning to Say “No”

Posted on by
Reply
Reading time ~ 2 minutes

The great thing about working with software development teams is that on the whole they’re a nice bunch of people who just want to get on and do the right thing.

The tricky thing in large-scale enterprise product development is that there’s often aggressive targets pushed through sales & marketing onto product managers.

A common response is to take a shotgun to the enhancement request backlog and ask for everything from the development teams and negotiate down from that point.

Craig Larman & Bas Vodde summarized this brilliantly using game theory in the second of their scaling agility books as the “your fault” game.

Assuming like many large companies you’re faced with the challenge of an annual commitment-based project/backlog and you’ve whittled that down to the best you can do; chances are your product manager will come back at some point through the year having visited a customer or partner and, like Columbo, ask for “just one more thing”.

Agile development is meant to give us the flexibility to do this right?

The typical nice guy response is “well… it’s going to hurt … but we’ll try”…

Great! When your team gets kicked around the room at the end of the year for failing to meet their release commitments, I’m pretty sure I know whose “fault” it’ll be.

FrAgile

So… Time to dig yourselves out of that abusive relationship, get a backbone and learn to say “No”.

OK. Maybe that’s a bit harsh. How about…

“Sure we’d absolutely love to do that but here’s everything we’ve already committed to for you. What would you like us to drop first?”

That still sounds pretty collaborative – but now it’s on your terms.

You’ve also just highlighted that being Agile doesn’t mean not making commitments if that’s what your business needs, it means managing your customers better.

If the previous “we’ll try” conversation is the norm for your teams, chances are this is the first time your product manager has ever been put in this situation. Don’t expect it to be pretty or easy. You’ll need to stand your ground and limit the options available.

I’m a fan of visual management so here’s my take.

  1. Take all the features you’ve committed to already and put them on cards or stickies.
  2. Draw a box around them so that there’s no room for anything else.
  3. Bring your product manager to the table, hand them the new feature or item they want on a card of similar size to an equivalent feature.
  4. Ask them to trade out something so that the card fits.
  5. Once the trade-out decision is made. Confirm any timing impact on the other features.
  6. Optional… (but recommended If you’re in a low-trust environment) Get the decision in writing recorded in whatever your system of record is.

If you can’t get your product manager in the room, do the same thing with excel and coloured blocks representing each feature in a pipeline. Adding a new feature in anywhere in that pipeline extends the end date. If you’re on a fixed-date commitment that means something falls off the end.

Simple?

Give this a try or adapt something similar for your own needs.

Captain, You’re Wrong!

Posted on by
Reply
Reading time ~ < 1 minute

With limited time and bandwidth, leading a large global development team on a large complex project requires rapid decision-making on difficult problems.

Some years ago my team found the cost of delay on a wrong decision corrected later was generally far lower than the delay of holding out to be sure of the right one.

Many times I had to look at what little information we had and either make (or support the team in making) an arbitrary judgement call.

The reason this approach worked for us was that we were all willing to step up as soon as we knew were wrong (usually in light of new, previously unknown information) and call each other out. In fact I took it as a matter of personal pride that I could be wrong so often and yet my team could still outperform those around us.  In that team it was socially acceptable to be fallible and we encouraged less-experienced staff to challenge their more experienced counterparts.

The phrase “Captain, you’re wrong” is still music to my ears. It usually meant someone on the team was right!

Try this: When you’re stuck making a decision, choose the one that seems least wrong. You’re an experienced professional, sometimes your instinct will be all you have left to work with. Make it clear to your teams that if they find a decision isn’t working for them they can revisit it – as long as we get on with it now with no debating.

Breaking The Seal (Part 2)

Posted on by
Reply
Reading time ~ 2 minutes

In my first article on “breaking the seal” I described how this pattern applies to managing WIP on teams. There’s also a work/social concept that fits the same name with a different pattern…

Name: “Breaking the Seal”, “The Lid is Off” etc.

Analogy: When you open a new pack of good coffee there’s that great smell that comes out – suddenly everyone wants a brew.

Concept: Socially, many people are unwilling to speak up in a crowd or be the exception either in positive or negative situations. Fortunately for experienced agile teams, the social norm of staying silent has often become disrupted but you’ll need to break it back open once in a while and as a coach you’ll need to find ways to introduce it.

Being the first to speak up triggers team inertia; suddenly others’ voices will also be found.

How many times have you sat in a meeting where someone uses a term or concept you have no idea what they mean but you don’t speak up? How many other people in the room also have no clue but stay silent? This might be inertia, it might be fear or just an unwillingness to appear stupid. Particularly with technical teams where your career goal may be “technical guru” – being seen as wrong or not clued up may be a sign of weakness. Having a “wise fool” on the team breaks the seal on this but needs some caution applied.

In some organizational cultures it may not be socially acceptable to question more senior staff. This really gets to me. In fact, I’ll write another post dedicated to this.

Occasionally speaking up might be risky, particularly if there’s obvious management issues. (Nobody likes to speak about the elephant in the room when the elephant is in the room) In these cases arrange with a few like-thinking peers to take it in turns to be the one to raise issues so it’s not always you. This will also ensure that you’re not speaking alone with others relying on you to take the risks up every time.

On the more positive side, the “red cards” tool relies on this same concept for group self-facilitation. Where once it becomes socially acceptable to halt a problem or challenge others the team’s self-organizing capability steps up another notch.

Practice this in your own teams – challenge yourself and your peers to ask a dumb question or plug a rat-hole at least once a week.

Communicating in Patterns

Posted on by
Reply
Reading time ~ < 1 minute

I’m a huge fan of “patterns” or what I describe as “pattern thinking”. My main source of inspiration was not “design patterns” but rather Mary-Lynn Manns & Linda Rising’s book “Fearless Change“.

Whilst I’m no expert at developing my own patterns, the concept of planting a seed – a verbal cue or anchor – to encapsulate a powerful concept in a couple of words is incredibly valuable when coaching and leading teams and managers.

2 Great examples of this that aren’t mine are “Technical Debt” and “Code Smells”. Terms that people can latch onto quickly and use in conversation with generally little problem in being understood.

As a line manager a few years ago I required every member of my team to read Steve McConnell’s white paper on managing Technical Debt.  Whilst he wasn’t the inventor, his treatment of the subject was a detailed and resonant enough introduction for it to stick with the teams. The term technical debt is now heavily used (and usually properly understood) all the way up to exec level within the group.

I was recently privileged enough to have Naresh Jain visit my site to coach TDD & refactoring. In a week of training he effectively introduced our entire group to the very sticky term “Code Smells“.

I’ll be writing up and sharing some of my own verbal seeds shortly. I doubt they’re unique  but they’re how I choose to socialize specific thoughts, ideas & behaviors from my own experiences.