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.

Red Cards

Posted on by
Reply
Reading time ~ 3 minutes

One of the best facilitation tools I own. How to get a group out of a rat-hole & back on track without personal confrontation and minimal effort.

Name: The Red Card

Concept: When a group is in discussion on a particular topic they can often disappear down “rat holes” or off onto tangents. Every member of an agile team is empowered to “red card” a conversation that they feel is going off track. The group as a whole typically rapidly decide whether the red card is warranted or not.

Usage: I ensure that plenty of of small (playing card sized) red cards are available in the team rooms. To introduce them to a team that haven’t used them before, I will usually take a large session such as release planning and introduce the concept of red cards as part of the facilitation tools and ground rules at the start of a session. What I tell the teams is:

“Whilst I’m facilitating, I tend to get drawn into the conversations and need hauling out, especially if I start ranting. Therefore the red cards are required primarily to shut me up – although feel free to use them on each other too!”

Once a member of the team first uses a red card, that’s it – the lid is off. Expect use of cards to take off rapidly. (see “breaking the seal – part 2“).

Background: Chances are this has been used before me elsewhere in the world, but this is a tool I introduced to my teams after returning from Agile 2009. During one of the evening sessions there was a panel discussion. Questions were submitted in advance and each panelist had 2 minutes to discuss. After the whole panel had their say, the audience were given an opportunity to vote. On every seat was a large red and green paddle. If we wanted the discussion to continue we voted green. If we wanted to stop and move on, we voted red.

When I got back to Cambridge I introduced it during some training I was running. I “borrowed” my eldest daughter’s red & green art straws. There were a few “hot spots” on the course where 1 or 2 attendees would lose track. We had a great team who immediately raised a red straw. They enjoyed calling each other out so much that we had red straw warfare at one point!

After using the same in a couple more sessions it became clear the green straws weren’t needed. The red ones were getting tatty so I raided the stationary cupboard for some red card instead, cut this into pieces about the right size to hold up visibly and planted a few in the team rooms. These are now the social norm for facilitators on many teams worldwide but probably not well-known outside the company I’m at right now.

Impact: Of all the tools I’ve used over the last 2 years this one seems to have had one of the greatest impacts on teams and the most viral spread within the organization I work with. Even the management team now red card each other and they don’t even have the cards in the room. Like all good verbal anchors, everyone now knows what “red card” means during discussions. Better still – even on difficult teams I’ve not yet seen anyone use red cards in a socially unacceptable way.

Try red cards out on your next big retrospective – you might want a stooge to break the seal first of all and chances are you’ll need to set yourself up as the first target but once the team have been through this once, facilitating meetings will become more of a team sport than a job for you.

Agile 20xx – It Takes a Team

Posted on by
Reply
Reading time ~ 3 minutes

Inspired by this post I just read from Seth Godin. As an average joe, hob-nobbing with CEOs isn’t so likely for most of us but the interpersonal interaction certainly is worth making time for. However…

If you’re paying to learn and thinking of attending Agile 2011 (or any other really big conference) take a team!

For the last couple of years I’ve attended the big US Agile Alliance conferences. I love going although I miss my family; I really enjoy the social interaction, spending time with (on the surface) a bunch of smart, similar-minded people sharing a week of learning, collaboration and fun. There are of course undercurrents (see this old post from Jean Tabaka) but I still find attending these conferences a rewarding experience.

For anyone that’s not been, the Agile 20xx conferences are huge and seem to be getting bigger every year. The number of parallel tracks – all with great presenters means you really have to make a plan.

Each year I’ve attended, I’ve had the luxury of going out as part of a team. My advice to future attendees is the same – take a team and collaborate on what you want to see.

My goal each year is to walk away with at least 3 key pieces of new thinking that would add value to my teams. The travel and conference fee for just 3 ideas might be excessive but as I said, I also go to learn, collaborate and have fun.

If even 1 of the ideas I bring back is sticky enough to be introduced successfully to a group of nearly a thousand engineers worldwide then I think that’s worthwhile!

So which sessions do you attend?

Personally I tend to steer away from the “rock star” sessions. Most of what they’re presenting is covered in their current or forthcoming books (and I read a lot of those already) so I don’t get much from them. Other members of my team don’t read so much and so will go along to some of these. Get the team to strike a balance but make sure the motivation is to learn and share, not just to meet “famous people“.

The stuff out there from people without book deals is rarer so I make the most of those sessions but less-experienced or well-known presenters may mean a higher risk of a not-so-good session.  Also keep an eye out for the open space sessions and lightning talks. You’ll find a lot of up-and-coming talent and thinking out there but again, your mileage may vary.

I also tend to look for things that are relevant to my current context, and future direction, not just my current role. A big part of my interest is in viewing things from other people’s and roles perspectives – for example I’ve never formally had the job title of “tester” but “Agile Testing” is one of the best books I’ve read that really “gets” cross-role pairing and test strategies – relevant to developers and managers, not just testers!

Others may prefer to spend the entire week in “UX” or “Testing” tracks but generally I strongly discourage spending the entire week in a single track in your own domain – you just don’t learn enough of the other interesting gems. Maybe it’s just me but agile isn’t just about your own specialist area, it’s about the whole team and organization.

Having presented at Agile Cambridge last year; I and my team have submitted a couple of proposals for Agile 2011 as we’re hoping we can start to give something back. There’s a lot of presentations out there so our chances are slim however despite the number that don’t make it, there are hundreds of great ones that do.

When planning your sessions, take a team and go for a knowledge portfolio – balance risk & reward to get maximum return on your investment. You won’t regret it.

 

Breaking The Seal (Part 1)

Posted on by
Reply
Reading time ~ < 1 minute

Following on from my last post; “Communicating in Patterns” here’s the first of my regularly used concepts – alluded to in “Don’t Open More Barrels Than You Can Consume“.

Name: “Breaking The Seal” or “Cracking Open” etc.

Analogy: (This one makes me think of the campfire scene in blazing saddles even though it’s only partially relevant)…

You only open the lid on a new can of beans when there isn’t enough in the current can to feed the family.

Underlying Concept: One of the key ways of delivering maximum throughput on teams is to limit WIP (work in progress/process). Teams inexperienced at this tend to start additional items or “break the seal” on new work when blocked or when a team member has completed their last personal task. We need the team to take a hard look at the work at hand, consider swarming around a given item or story and only open the lid on a new item if there really is no additional value to be gained from another member of the team helping out on the current top priority item.

This works on many levels – here’s a few…

  • Every time you open a new can you risk not finishing it all and having to throw the leftovers away.
  • Opening too many cans and forcing the family to eat them all causes bloating.
  • Eating excess beans takes longer and leaves no room for dessert.
  • Unfinished cans in the refrigerator tend to get pushed to the back and go moldy.
  • Very few people like cold beans for leftovers. (actually – sometimes I do)

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.

10 Minute Test Plans

Posted on by
1
Reading time ~ 2 minutes

Struggling to introduce TDD or Acceptance Testing? Here’s a really powerful simple first step that you can perform immediately – How to get your development teams “thinking” about tests and how to test with little or no negative impact and a few seconds setup time.

This assumes you’ve already broken out your story/feature/activity into developer-sized tasks.

  1. Push the keyboard away and get a sheet of A4 or Letter paper and a pen or pencil.
  2. Draw 2 lines to Divide the paper into 3 roughly similar sized areas.
  3. Pair up with the developer who’s going to work on a task.
  4. Start a timer –  you have 10 minutes.
  5. Spend 3 minutes listing out as many “pass” cases as you can think of between you – all those simple “happy path” things.
  6. Spend 3 minutes listing out as many “fail” cases as you can think of – bad inputs, exceptions etc.
  7. Spend 4 minutes thinking of all the boundary cases you can think of – e.g. date/time/time zone, rounding, location etc. Often these boundaries depend on your problem domain.
  8. That’s it – you’re done!

OK, this isn’t going to give you perfect code and it does take a bit of practice. Try not to agonize too much about whether these are unit, functional or acceptance tests for now. We’re still learning to fly here.

Much as standing up collaborating at a whiteboard uses a different part of your brain to coding; paring up, brainstorming and writing with a good old pencil & paper does a similar job. The discipline of not touching the code for a short period of time and thinking about how you’re going to test and what could go right or wrong will significantly improve the quality of what you produce – it usually makes the coding easier too.

Better still – you should now have your first unit tests to write! – pick the simplest ones you have on there and get them working! (I usually start with input validation. I know it’s not directly related to end user value but once I get a good grasp on inputs the rest fits in my head more easily.)

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.

Just Enough Design

Posted on by
1
Reading time ~ 3 minutes

Some years ago at a prior employer I had the luxury of working with a team delivering a large green-field Java & Oracle project. The requirements were complex and the interfaces, APIs and business logic all needed some pretty exotic thinking to make everything work.

Prior to that project we’d delivered plenty of relatively simple work and been through requirements, design, code, unit test, integration, system test, documentation etc many times. We were generally a “pretty good” team.

We hired a new member – a very experienced and hands-on architect. He brought a whole load of knowledge we were looking for to the team and more…

After being on board about 2 weeks he called a meeting with the entire team. Hauled us into a room and pointed out just how poor we were at proper design. Moreover he took control of the situation, developed a series of design spec templates, guidance and examples, got the team fully ramped up on UML, capturing design decisions, practices, patterns – the works.

Using our new design knowledge and tools, we moved onto the first critical phase of our green-field project in 2 groups.

Group 1 had to get a working proof of concept to the customer in a matter of weeks, group 2 needed to start designing the way more complex second round of features.

For group 1 (a small pilot team of 2), one of the team did about a week’s research, wrote up the basics and hit the ground running (no real design). Group 2 were not allowed to touch a line of code until the designs were complete!

From memory, start to finish; that first phase took about 3 months.

After the initial work was completed, both groups 1 & 2 progressed onto the next round of features based on the design efforts group 2 had completed.

After about 2 weeks we realized we were having to sacrifice one of the team (our feature lead!) almost full-time to maintain the designs. Coding was completed in a total of about 6 weeks. The fastest coding turnaround we’d ever had for something of this scale and the functionality was way harder than the first round of work.

After our crash-course in the pain of full-on software design,  our architect reconvened the team to lead a design practices brainstorming session.

“OK, now you know how to do proper software design; of the tools, practices and documents you used, which do you want to keep and which do you want to ditch?”

Our management seemed to have had the foresight to allow our architect this social experiment knowing full-well that the net result would be a major overall team improvement (the same manager also helped us develop successful business cases for major refactoring efforts – a pretty forward thinking guy).

So what did we keep and what was our philosophy?

Philosophy first:

The greatest value in design after the fact is not in what was implemented but why we chose to do it that way (and why not another way).

The second greatest value in design after the fact is for team members (especially new joiners or maintainers) to get a foothold into the codebase and be able to navigate around safely.

With these cornerstones in mind we kept a few things…

1: High level architecture – a verbal or pictorial summary of the general concept and approach. Often just a photo of some legible whiteboard sketches. – our first foothold

2: Top level flow – a sequence diagram defining the overall flow of responsibility between actors. – our main “ladder”into the codebase.

3: Design decisions and rejections. (in a wiki/threaded discussion) – why did we choose to do things and why did we chose not to do others. – since learning the “why & why not” approach we saved days of ramp-up and maintenance pain on projects.

4: Complex algorithm annotations – for the really gnarly bits. (Avoid this where possible) – draw pictures for these where you can.

5: Public interfaces – as peer and tech-author-reviewed Javadoc post-implementation. I like public interfaces – they’re a great long-term commitment to communicate in a given stable way. In this case they were also a commitment to our customer. Doing a decent job on these saved a world of support pain later.

6: Unit & functional tests – yes, these are design too!

That’s it! – we ditched a whole world of class diagram hell and parameter definitions. We could still sketch out basic class diagrams when needed but not the level of depth needed to generate code from a CASE tool. We ditched all the noise and blurb and we made it clear why the product was written and behaved the way it did.

So – give your teams an easy leg-up into your code and then explain why it does things rather than telling people what it should do.

I’m Drowning in Confetti

Posted on by
Reply
Reading time ~ 3 minutes

What happens when card-walls, foam board and stickies get out of control?

The same thing that happens with poorly maintained software.

“…But we spent time on them we can’t possibly throw them away!”

Time for a litter patrol I think…

About 2 years ago I ran some Agile training up in Scotland. One of the early exercises was to get the team to brainstorm and develop a backlog for a new product. (later exercises covered release planning etc.)

On every table was a pile of coloured stickies, marker pens and biros.  I asked everyone to grab a pen and some stickies and collaboratively start developing a coarse list of features and end user needs. All but one person in the room grabbed a biro and sticky pad and started listing as many things as possible – on a single sticky!

There’s some lessons to learn from this abut giving good instructions but the big thing for me was realizing how our culture has changed so much at the site I’m usually based at.

In 3 years I’ve seen a team transform from nothing on the walls to everyone having their own personal whiteboards, pinboards, information radiators at every wall and corner, a myriad of story maps, coloured indicators, charts, tables, diagrams and the real killer – A0 size portable foamboards covered in stickes everywhere!

Sounds pretty good – all that information right?

Perhaps we’ve come too far.

I sat down in a meeting room today and looked at the board that had been “parked” in there sometime in the last 6 months and recognized my own handwriting.

It was from a difficult release retrospective I’d led for a large team. The board was covered in things to “try” and a few things to stop doing. The original retrospective didn’t end so well. I pushed for selecting a top 3 actions (from nearly a hundred ideas grouped into logical sets) and failed to reach a conclusion.

Looking at the board today, despite the pain at the time I reckon that team have actually achieved or tried nearly half the things on the board and most have stuck.

I’m going to take it back to the team shortly as it’s a great way to see just how far we’ve come.  Quite a neat find!

But…

This is one of nearly 100 foamboards in the building. (We have about 10-15 scrum teams). My team sees these particular boards multiple times per day during various unrelated sessions but we don’t do anything with them – they’re just parked.

Many of our boards are delinquent, things are starting to look a bit untidy. In some cases there are multiple boards that are the output of week-long workshops speculatively planning releases that we’re now in full swing on.

They were useful once but now they’re hiding in corners and we don’t know what truths they hold.

We have photos of them in the wiki but they’re not important enough to keep right in front of the team and maintained.  We still feel an attachment to them – all that energy and time spent getting those thoughts visible…

Time to clean house I think.

I can either be brutal or more selective. Much like clearing out the garage, sometimes having an impartial person to help clear up may be needed.

My Lesson: Just because you spent time on it doesn’t mean it needs to be kept. Remember the XP acronym; YAGNI?  “You Aren’t Gonna Need It”

It applies to all artifacts developed during a project, not just code.

If something has served its initial purpose or achieved most of its intended value, make a clear decision on what to do with it. Are we into diminishing returns? Should there be some explicit action to retire the artifact?

If you care that much about it, how about giving it a wake?

Whatever approach you take, don’t let your information radiators rot. All that out of date noise will cloud out the actual information.