Lean Thinking

Tuesday, 19 September 2017 22:30

Pirate Teams

Published in Agile

A few months ago I saw a meme floating around contrasting a good agile team with a group of cowboy coders. Their chosen metaphor was a nautical one. The good agile team was the navy (age of sail style) - disciplined, focused, effective, working together for a common purpose. The bad team was, of course, pirates - rough, undisciplined, attacking stuff at random, scary but ultimately ineffective.

I looked at that, and knowing a little something about pirates (real ones, not the Long John Silver/Jack Sparrow/Captain Hook type Hollywood ones) it didn't quite ring true. In fact, if you look a little deeper, the age of sail navy is actually quite a good metaphor for traditional organisations and pirates actually make a great agile team. Since this is International Talk Like A Pirate Day, heave to for a moment ye scurvy dogs and let me explain.

Tuesday, 05 September 2017 17:33

Why Do Agile Teams Slip?

Published in Agile

"Come and have a look at my team" says my new stakeholder. "We have been doing agile for a few years now and while we started well, I think we have slipped back to old habits". How often have you heard this when starting a new engagement? Quite often? What do you see when you take a look? It's usually lack of planning, absence of meaningful retrospectives, ineffective standups, lax WIP limits, poor metrics, mini waterfalls. Yep. They have slipped all right.

When you ask the team why they think they have slipped, you will usually get answers like "we scaled up and things went wrong" or "the rest of the organisation is pulling us back" or "some key people left" or something like that. In my experience these are never the real reason. They may have contributed, but the underlying problem is something else entirely. That underlying problem is almost always the same - they never had the basics right in the first place.

Tuesday, 07 March 2017 16:50

When to remove the training wheels

Published in Agile

We were having a discussion about coaching teams at work a few weeks ago, in particular how deeply embedded a coach should be, so I naturally got to thinking about teaching kids to ride bikes. I know that sounds like a stretch but stick with me. Back quite a few years ago when I was teaching my kids how to ride, I did a lot of observing of other parents and, being a geek, did a bunch of reading online about how to go about it. There are generally two accepted ways to teach kid to ride and the difference is on how long to leave the training wheels on.

Method one leaves the training wheels on for a long time - until the child is "fully confident" and the second leaves the training wheels on for the shortest possible time (there is a third radical method that rejects the training wheel altogether but we shall leave such heresy out of this discussion for now). I was, for the record, a method two parent but I observed a lot of parents using both methods. Method one is the intuitive one - leave the training wheels on until the kids knows how to ride then take them off and away they go. Easy. Trouble is, it quite often doesn't work out that way because training wheels have some significant disadvantages.

Tuesday, 21 February 2017 16:44

Don't Wait To Communicate

Published in Agile

A nice short post this time to ease myself gently back into the business of blog writing in the new year. I hope everyone had a fantastic holiday season filled with as much of your chosen way of celebrating as you could handle without doing yourself lasting damage.

How many times have we seen this situation - it's standup time and the team are gathered around the board sipping their morning coffees. "I need to raise a blocker" says one of the team. "I need some help with the design and I've been stuck since lunchtime yesterday so can anyone help out this morning? I probably only need 10 minutes". The team discusses the problem, tasks are rearranged and the team works out how to get the job done. Sounds great doesn't it? But there's a problem here. Can anyone see it?

Published in Agile

Often in large organisations we have to deal with groups with names like "legal" or "compliance" or to use an example from my days in the healthcare software industry "patient safety". To a project manager, the function of these groups seems to be to throw up obstacles and prevent getting things done. These groups tend to appear out of the woodwork near the end of a project, inspect everything that has been produced, identify a bunch of problems and then block release until they are all fixed. The problem of course is that at the end of a project, everything has already been built so changing things is hard and expensive. There is also a very good chance that the money is starting to run out so these changes would push the project well over budget. Throw in a rapidly approaching release date and a team already stressed with defects and last minute changes, and it's no wonder project managers view these groups with dread.

Of course, these teams are not just a bureaucratic hurdle to be jumped. They do an important job. The organisation could be in serious trouble if they release anything that is illegal or is not in line with whatever regulations they are under. Groups like legal and compliance have the skills and knowledge to make sure that doesn't happen. In the healthcare company I worked for, patient safety was responsible for exactly that - the safety of the patients whose treatment was administered through the software we wrote. They were trained medical professionals, with years of hospital experience, who assessed what we produced and made sure that in the stressful, overworked environment of a typical hospital, that the software could be used without the risk of accidentally administering the wrong drug or the wrong dose or operating on the wrong leg (or even wrong patient) or anything like that. That's a pretty important thing to do. We knew how valuable it was. We still hated dealing with them though. Product managers would jump through hoops to get their product classified "non-theraputic" so they could avoid a safety review. The downside of course is that there was no safety review. If only there was a way that we could get the value that these groups provide without all the downsides.

Page 1 of 3

Calendar

« October 2017 »
Mon Tue Wed Thu Fri Sat Sun
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31