Lean Cheating

I used to cheat on school exams.

In fact, a friend and I had a system: He would learn question one and two, I would learn question three and four.

During the exam, he would answer his questions I’d answer mine. Then we would leave the papers on the table so we could both see the other’s answers. We both scraped a pass, the system worked.

Having a chat about this recently, I realised we were using lean principles. We limited our work, had a pull system, and collaborated. Most importantly, though, we trusted each other. If either of us did not put some work in, we would both fail.

This made me think, without trust – everything else goes out the window.

You can set up boards and talk about breaking down work and setting up work in progress limits but, without the full trust from management and the customers, it won’t matter much.

The team needs to trust each other. Maybe people are only used to working in silos, dev teams, test teams etc. They may not fully trust the other teams, they may only have interacted with these teams through emails or a bug tracking tool.

The management also needs to trust that the team can manage its own work. The customer may only be used to a massive document and a two year wait, so trust will need to be built to change that.

Personally, what helped me build trust with others was pairing. Once someone has a clearer understanding of another’s role, it helps break down walls. Testers stop seeing developers as “that faceless person who gets assigned a bug”. Developers stop hating these “faceless testers who keep finding problems with their work”. Analysts stop worrying about whether the software will work, as they have seen it and can happily show the customer.

Everyone gets to sit together and see what each other does. When a team gets good at it, you won’t even need a bug tracking tool anymore.

So much like the band Madness “All I learnt at school was how to bend, not break, the rules”. I also learned the importance of trust, which you can build anything on – including great software!

madness_-_baggy_trousers

8 thoughts on “Lean Cheating

  1. Today is the 10th anniversary of WikiLeaks and this post makes me think about how much transparency and trust are fundamental for a peaceful society. Governments don’t trust each other, what of they were completely transparent? Would that improve trust? Thanks for a great post Darryn!

    Liked by 1 person

  2. I agree on the importance of trust and that pairing is a great way of achieving that. Your opening example of cheating in an exam leaves me wary though. It may show trust between you and your pair (or, well divided individual tasks) but it also shows cheating the overall goal value (your learning) off your other stakeholders. Also, I don’t see it particularly good example of pairing. It’s work done individually and integrated, a good example of pairing would show that you both had unique points and cheating not only allowed you to barely pass, but gave you two together insights that you couldn’t otherwise have. Because, pairing is not getting them most (or least) out of you effort wise, it’s about making a better deliverable at once.

    Like

    • Hi Mareet,

      while I agree on the fact that cheating is not a good thing and it doesn’t match to what pairing is, I read the cheating metaphor in a different way. I see the cheating being not against the learning or each other or against the customer, but against the rules of software development. Pairing was a novel practice in the 90’s when the XP guys introduced it and in that sense could have been seen as cheating the rules.

      Cheating as transgressing the rules we impose on ourselves every day, cheating in this context is to me experimenting with something novel.

      What do you think?

      Like

Leave a comment