When writing, people think in paper shape.

So why is it all our whiteboards are mounted in landscape?

Hang them up them portrait-style and panel them along a wall.

Just try it – portrait mounted whiteboards make a much better tool.

In my time working for a large multinational I led much of the design and layout work for redeveloping the office space at one of our sites to support agile teams. As part of this I reviewed and improved our available wall and whiteboard space.

As an experiment in one of the boardroom style rooms I arrange to have 3 large whiteboards mounted portrait style as 3 connected panels.  They proved significantly more effective than normal boards and became some of the most heavily-used whiteboards in the building. As a result I replicated the same setup across as many other rooms as would accommodate them.

I can’t tell you why others liked them but from my own experience I found working in multiple portrait-format significantly easier than landscape. It allowed focus areas and footnotes in a way that a pair of normal whiteboards in the same space didn’t. This helped me arrange thoughts more cohesively with a natural information flow that landscape boards didn’t offer. They also worked as natural extra-large swim lanes during workshops and allowed multiple team members to work side-by-side on related aspects of a workshop.

It’s hard to remember all the benefits on a Friday afternoon. They just “felt” nicer, different, better.

Give this a try and share your experiences here.

I wrote the following article in mid-2009 – some time before I read Goldratt’s “The Goal”. This was eventually published in 2010 internally at the company I was working with at the time. Today felt like a good day to refresh it and share more widely.

________________________________________

If you haven’t yet done so – read up on the theory of constraints. In fact I recommend that every manager in any size of organization obtain and read a copy of “The Goal” discuss it with your peers & teams and make copies available for your staff.

In Spring 2009 I had the good fortune to attend a training course in Florence, Italy – a hub for European manufacturing training for a large Oil & Gas company.

One of my working team during the week was in the process of implementing a lean production line for the local factory floor. Their layout and travel spaces were all mapped out but the reason for him attending the training was to cover the human aspects of such a radical change.
He had factory floor staff who had been performing the same expert role for 20-30 years or more. Now they were being asked to radically change their working practices and he was feeling the pain.

An operator producing bearings may traditionally be measured on their production volume (and quality).  Their single-minded goal is to maximise their own output. The more bearings produced, the better an operator they are. In some cases, particularly where waste is not well managed, volume may even trump quality.

In a production line, operators are contributing not to the production of bearings but to the production of complete working units as part of a team.
They have to look both up and down-stream and assess the state of flow through the entire team. If there’s a bottleneck in the line, they’re expected to adjust or stop their own activity to help out and “level the load” in order to maximize the performance and throughput of the entire assemblies they’re working on in the factory.

The challenge here was that some operators had learned over years of training and measurement to sub-optimize around their own roles and personal output even though the real unit of value was in the whole team’s output.

His challenge was not unique and for this particular company, lean manufacturing was already a major focus. The striking synergies between lean & agile meant I was able to share insights from my own experiences with him.

Now let’s take his example and consider some quotes often heard during software development.

• “It’ll be far more efficient if I do all the coding now in one go.”
• “Seeing as I’m already doing some surgery here it makes sense to add these few other things that I’m pretty sure we we’ll need”.

Often these are suffixed with “it’ll be ready in when it’s ready”.
I’ll raise my hand and admit to this behavior in the past – particularly when in the midst of a major refactoring exercise.
But…

• What about everyone upstream and downstream of my code?
• What’s the impact on the testers of me delivering 3 months worth of code over 2 days worth of code?
• Do I have people waiting for work downstream?
• If I changed my delivery practices would I get feedback sooner?
• If I got feedback sooner would those bugs be less of a pain to context switch and fix?
• Would the overall throughout of the team be greater?
• If requirements change how much of my work would be wasted?

This is where agile and manufacturing meet.

Admittedly in manufacturing, the concept of a multi-skilled operator is far more prevalent than in software however the software industry equivalent is often described as the “Generalizing Specialist” – that is: whilst a member of the team may primarily be role X, they are able to add support and value in role Y – even if that’s not their job title.

This may be a simplification of reality but some skills are exportable or importable across roles and allow us to level the load by having others do the heavy lifting.

It is the responsibility of every member of a development team to consider the entire value-stream, the activities of all skills and roles that contribute to a working product increment and ask questions like:

• “Am I working on our top priority item? – if not, should I contribute to it in some way?”
• “Could we be delivering more finished work sooner if I helped out elsewhere?”
• “I’d really appreciate someone covering these areas around the edges of what I’m working on”
• “Here’s a problem that keeps slowing us down, let’s figure out how to remove the bottleneck.”

Think about your current role in a development team.

• Are there opportunities for members of the team covering different roles to support each other better?
• Is anyone over-producing in comparison to capacity of other areas and causing headaches downstream?
• Could some conversations be had sooner, be much shorter and save pain?

Take some time out this week and consider how your teams and individuals could improve their cross-role collaboration, share some of the heavy lifting and deliver as a more cohesive unit?

My team’s doing an amazing job, in 9 months we’ve increased our velocity from 28 points per sprint to 65 by changing our development practices and adopting XP.

Now we do TDD, pair programming and relentless refactoring. Better still, we have story kick-offs and the team swarms around a single story until it’s complete. We all do the scrum-ban can-can to get ready-ready for done-done…

That’s nothing says the other manager, we’ve just increased our velocity by 1000% in one sprint with only one change to our practices!

…

We added 3 extra zeroes to every story point estimate.

Believe it or not, this really does happen in some organizations although usually much less extreme and obvious. Story point inflation becomes more common when velocities are compared either across teams or reported through management.

Q: What’s the best way of increasing a team’s velocity?

A: Use it as an external performance measurement.

The same issue holds true for the total number of stories completed.

Q: How do you make your teams complete more stories?

A: Make stories smaller.

It’s a a well-known fallacy that using story points for anything other than a team’s own diagnostic for tracking their progress towards a goal is risky.

Also bear in mind that if you’re using velocity and story points the way many of us have been taught then you’ll be using historic averages rather than ranges. If you examine the probability curves of historic averages, there’s a strong possibility you’ll only hit that forecast velocity 50% of the time. (I’ll expand on this in a more detailed article on estimation)

Do not confuse story points with being anything other than an internal diagnostic to the team and don’t confuse numbers and “data” with meaningful feedback.

If you want to measure the delivery success of the team, focus on what was actually delivered.

Ask stakeholders and customers for feedback – frequently.

Try a simple Net Promoter Score style survey or even better, be lean and “go see”. If you can’t go see, get a video testimonial from the “customer”, play it back to the team and the management.

It’s a lot harder to distort the meaning of a recorded conversation than metrics.

Building flat-pack furniture is for some reason way up there on my stress-o-meter.
Back in November (when I first drafted this article) I bought myself a new laundry basket, it’s quite a nice wooden box with a flip lid. When I collected it, I discovered it was a flat-pack.

I’ve been confronting a lot of longstanding issues recently (one of many reasons for being so quiet on the writing) – this was the second time in a week I’d had to build furniture.

“What’s this got to do with software?” You may ask.
Everything – not around writing it but around your customer and user experience.

Experience 1: The Charity Shop Bed
I bought a bed from a charity shop, it wasn’t cheap but it was nice. I was expecting it to turn up partially assembled (as a second-hand piece of furniture)
To my mixed surprise and dismay it arrived still completely wrapped but with one box opened.

STRESS ALERT - FLAT PACK BED!

I had to face my fears - get on and build.
I reached about 90% done and discovered an important (but not obvious) piece missing – a central leg.

AAAAAGH – All those stresses and fears were confirmed

Yes, I should probably have checked all the parts were there before starting but I was in “JFDI” mode after building up the momentum to even start!

I called the shop and politely complained.

After 2 days of chasing around, the shop were unable to find the missing piece so they gave me their display model instead.

There’s a couple of mixed experiences here…

First, I hate unfinished jobs. Sitting in my room with a part-made bed with the frustration of the missing parts and the belief I’d bought a cheap secondhand bed didn’t sit well with me. Whilst looking online for replacement parts from the manufacturer I actually found the same bed brand new for £50 less.

I buy furniture from charity shops expecting it to be cheaper and not new. I also expect it to be as seen in the shop (and not have to build it myself). Otherwise I’d have shopped around online. – Beware

Second, I hate complaining, I hate asking for things. This issue put me way out of my comfort zone. The manager of the shop was exceptionally helpful, professional and apologetic. She clearly went way out of her way to spend 2 days with staff trying to track down the parts in their storage warehouse before arranging a replacement. The time lost was frustrating but as I didn’t yet have a mattress I wasn’t too annoyed.

What really made the difference though was her manner, tone on the phone,  complete reassurance and commitment to a successful outcome – the sort of behavior I expect when dealing with a business supplier, not a charity/thrift shop.

Experience 2:  The Laundry Basket
By Contrast, my cheap laundry basket was a joy. I wish I’d taken a picture before it was assembled.  Every part was clearly labelled, bags of components and fixings were grouped independently, packed in easy to open bags. There was even a bag labelled ‘spare parts’

It got better. The instructions were incredibly clear and precise. A paper ruler was provided to aid differentiation of screw sizes (although with the independent bags, this wasn’t a problem). Where there were 2 almost identical parts, an additional note in the instructions indicated exactly how to differentiate the two.

OK so I was alone and it was a dark evening but the exceptional user experience of that small laundry basket really helped finish off what had been a successful day in such a positive way that it even inspired me to start writing again.

Lesson – those small things that give your customer/user a positive experience after you’ve taken their money and when they’re expecting far worse really do stand out.

“We need an independent quality organization, to keep the project managers, developers and business honest”

Today I thought I’d let “Bad Captain” take the helm for a few minutes.

In talking about software quality at Agile Cambridge a couple of weeks ago, the audience were invited to share their insights. Mine was to “avoid independent quality hierarchies” – to which I received a small round of applause (likely from those that recognize the dangers). I’ve had this article in the shed for many months and although my context has since changed, there are many in the software world that face this pain and need your support.

We trust our managers and teams with the finances of multi-million dollar projects, we trust them with staff pay and appraisals when those knowledge workers are generating our primary source of income and we trust them to preserve our intellectual property!

OK so in many cases we have reviews but these are within the same organization. Some companies sadly don’t trust their teams with the quality of what they’re delivering in the same way?

• What happened to damage or erode the trust?
• What’s being done to rebuild it?
• Is it beyond redemption?
• Who can lead the change?

Most managers I know and most development teams succeed by having a high level of professional pride and integrity and by doing the right things for their team and product. In the situations where a manager or team doesn’t behave in that way it’s incredibly rare that they don’t get called out by their peers.

• It’s professional and long-term product suicide to short-change quality, we just don’t do it.

There is no good reason for a manager and team to not set their own high quality standards and meet them.

Beyond “keeping teams honest”, the other argument I heard for an independent quality group was:

“Because it’s a required function further up the management chain, that’s just the way it is”

Don’t get me started on empowerment, continuous improvement and root cause analysis. It seems incredible that in the 21st century, staff in many organizations perpetuate this attitude. The truth is that this is still incredibly common.

Unfortunately I don’t have all the answers today but here’s a couple of thinking tools to present…

Let’s run on the assumption that we really do need an independent quality group. As I see things, that team has 2 options.

Option 1: Set a high quality bar and challenge/encourage teams to meet it. Negotiate down or stand your ground when the project teams challenge the setting of the bar.

• We’ve just built a new source of conflict and waste in our organization with a management chain that have a vested interest in their group’s own continued existence. Nice move!

Option 2: Set the bar at a level we think the team can meet.

• We’ve just low-balled our quality for the team. Better still, the team working on delivery are not accountable for raising their quality game because that’s been taken away from them!

Now let’s turn things around.

Option 3: Let teams and managers set their own quality bar. Arrange a proper review where the team use their professional pride to challenge the level they set and determine what’s achievable, what they could strive to achieve next and what are the business and engineering benefits of doing so?

Risk: The team low-balls their criteria.

• Mitigation: Lead by example, drive a culture where everyone takes personal responsibility. Reward and recognise teams for raising their game.

Funny, for some reason Option 3 doesn’t seem to need independent QA.

Where I work right now doesn’t have an independent QA/QC organization. Our quality is high, as is the level of trust exhibited throughout the company.

This is the simple stuff, don’t break it with vested organizational interests.

Caveat: I understand regulated environments have a necessity for compliance and  independent oversight however that compliance environment is either for safety or due to exceptionally high trust-related risk . If that’s not relevant to your organization, why then are you still doing it?

I’ll return the rudder to Captain Crom in future.