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!

Portrait Vs Landscape

Posted on by
1
Reading time ~ < 1 minute

I’ve been very busy for the last few months in my new job but will be presenting at a couple of conferences in the Summer. In the meantime, here’s a short thought to share…

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.

 

You Are Not A Lathe Operator

Posted on by
Reply
Reading time ~ 3 minutes

This weekend my replacement copy of “The Goal” arrived. (My last copy escaped).

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?

Story Points are Only for the Team

Posted on by
1
Reading time ~ 2 minutes

One manager says to the other…

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.

The Flat-Pack User Experience

Posted on by
2
Reading time ~ 3 minutes

Some things in life cause more stress for me than others.

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.

The Hidden Dangers of an Independent Quality Organization

Posted on by
Reply
Reading time ~ 3 minutes

“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.

Rapunzel’s Ivory Tower

Posted on by
Reply
Reading time ~ 3 minutes

“If the problem exists on the shopfloor then it needs to be understood and solved at the shopfloor” – Wikipedia

Some years ago I took on an agile coaching role at a very large corporation. Like many stereotypical large corporations, they were seen as data-driven, process and documentation-heavy. Management culture was perceived as measurement-focused, command & control and low-trust.

They had a very well established set of Lean practices and managers promoted strong values around empowerment. Despite Lean training for all staff, there was still a very limited “Go See” culture.  Above a certain level it was still traditional management-by-numbers and standardization – mostly by apparent necessity through scale.

James Lewis recognized some of these challenges. (but was perhaps more brutal than my insider view)

At the start of the transformation the leaders wanted to know “who’s agile and who isn’t”.

Disturbing as the thought might seem, their motivation was sound. We’d all put our careers on the line to “go agile” in order to turn around a struggling group. The last thing needed was a disaster project with “Agile” being labelled as the cause of failure.

(Nearly 2 years further down the line, we managed to have at least one project fail early and be recognised as saving over a million dollars).

We developed an extensive “agility assessment” in order to teach all those involved that “being agile” wasn’t a binary question and wasn’t just about Scrum practices.

The measurement system for the assessment acknowledged that whilst there may be “good” answers, there are no “right” answers or “best practices” – teams could actually beat the system. (If there were “one true way” of developing software, the industry would be very dull).

Beyond measurement, the big challenge I and my team faced was the pressure to “operationalize” agile. To develop common standards, procedures, work instructions, measurements and tools worldwide. The Quality Management System (QMS) culture from our manufacturing background meant that interpretation of ISO accreditation needs was incredibly stringent and was required in order to do business with many customers.

Ironically that requirement kept us almost entirely away from the teams delivering software!

Operationalization was what our managers were asking for and it was very difficult to say “no”. Traditional corporate culture defined this as the way things should be.

So from stepping into a role where we expected the gloves to come off, where we could get out of the management bubble and start making a real difference with teams; within a few months my entire team found themselves unwittingly captive in an ivory tower.

We saw it coming and felt powerless to stop it but as permanent employees fresh into our very high-profile roles, those painful home-truths could not be comfortably raised.

I and my team spent that first period doing what was asked of us and helping teams out for the odd few days at a time wherever we could.

Fortunately all was not lost. At the same time, we invested in a highly experienced external group to engage on each of our sites and drive some of the changes we needed to achieve from within the teams.

Was the value I’d hoped to add in my role lost? – Actually no.

The managers got what they wanted – heavily seeded with a our own more balanced agile/lean understanding and experience.

We weren’t perfect but made a significant series of improvements. The teams actually delivering products had far more experienced consultants supporting them, who as contractors could take the right risks that permanent staff could not have done at the time.

This 2-tier approach actually gave the delivery teams more air-cover to find their own way whilst we worked on coaching the management.

The teams still had a long way to go but were heading in the right direction and getting progressively better. At the same time, the management team learned that Agile isn’t simply a case of running 2 days Scrum Master training, developing a set of procedural documentation and expecting that everything will show 1,000% improvement.

After the initial bedding in period, I and my team were able to build up sufficient trust with our leaders that we could set future direction ourselves.  The kick-start needed on change within the teams had already been made. (far more effectively than we could have achieved alone). 

With our leadership trust established, after being holed up in a tower for too long, our coaching team were able to reach the real world again. This time it was entirely within our own control, with the management support we needed and enough credibility remaining with the teams we had interacted with to move forward.

We were free, able to step in, learn more, tune, help out and spend months at a time properly embedded on teams taking them forward – reaching that point of empowerment for our team was a coaching journey in itself.

If you’re in the fortunate position to be an agile coach or in a similar role in a very large or more traditional organization, make sure you recognize that your coaching efforts will often be as much (if not more) necessary in coaching your leaders first.

Post #Agile2011 Playlist

Posted on by
Reply
Reading time ~ 2 minutes

An insight I picked up from Jeff Patton during his user story mapping workshop at Agile 2011.

  • Use music to help you facilitate your sessions

Jeff used “Kung-Fu Fighting” as backing/timing music for one of the group exercises.

When I got home I sat at my computer trawling my music collection for perfect facilitation tunes ranging from 3 to 10 minutes long.

I have loads that I’ll unleash on teams over the coming months 🙂

There’s an important trick to these though. They have to be the “right” tempo and style to match the activity and team – generally upbeat and well-known enough that team members can “feel” the end of the tune coming.

In the meantime, in a change from my normal programming I’ll switch to my other passion; music…

If like me it’s been a really intense week and you’re on a post conference come-down (see Doc List’s post on similar here), here’s my recommended selection of music (in this order) to recover to…

If there’s any of these you don’t own, buy them now or cue them up on your favourite online station! I’ve added links to the hardest-to-find tracks.

2011-08-14 All Agiled Out – on Spotify

* playlist heavily influenced by available music selection on the airplane journey home

Note – If you’re not feeling so cheerful, It’s important you don’t stop part-way through.

For anyone who’s a fan of “High Fidelity”, the art of the compilation tape is the journey you’re taken on.  This one will only leave you happy if you make it to the end!

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?

Piratical Management (Pirarticles)

Posted on by
Reply
Reading time ~ 2 minutes

I’ve spent very little time on writing articles directly related to my nom-de-plume.

There are 3 main reasons behind this.

  1. Most* of my “Bad Captain” thinking is fuelled by negative workplace, management and team experiences and I’ve not had any for a long time.
  2. I have a backlog of 70+ more valuable articles and ideas already without adding pirate concepts into the mix.
  3. There are plenty of articles already discussing pirates and management on the web, why re-invent the wheel!

*The rest is probably fuelled by cider, rum and late-night ramblings with close friends – think “Father Jack with earrings”

So as I make final preparations for a dawn raid at the Grand America Hotel in Salt Lake City and a week at Agile 2011 I’ve been digging out some reading material…

Here’s a quick pick-through of piratical management articles (“pirarticles”) I’ve found on the web so far plus a couple of potential reads to add to my “booklog” (thanks @MarkDalgarno for that very sticky term last week).

Articles

Some short articles for when my cognitive load means I don’t have space for anything more plus one or 2 that are more formal.

Books

I’ve not read either of these, I’d be interested in some reviews from people that have done but for now they’re going onto the booklog.

Music

  • Pressgang – Not directly about Pirates per-se but they do belt out a few amazing seafaring related folk-rock stories.

A little history (not much)

Deadly Serious:

A reminder that whilst my moniker is a light-hearted dig at my appearance and occasional nocturnal ramblings, there’s a whole other side to “real” pirates…