Lean Thinking

Written by 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.

Written by Published in Agile

As an agile coach I am always pushing for cultural change. That's what agile is really - it's not a delivery mechanism, it's a fundamental change in the culture of an organisation. What do we mean by organisational culture? There are many definitions but the one that I like is that culture is a shared understanding of values. It's the understanding everyone has of what the organisation thinks is important. Culture drives behaviour - people will seek to maximise what is considered important in the culture and will behave in ways that do that.

The problem of course is that, as anyone will tell you, cultural change is hard. CEOs are tasked with changing culture and spend years failing to do it. People say that the only way to change culture is to change all the people. Or that cultural change only happens when a generation of employees retire. I don't agree. Cultural change is really easy. You just need to let people know what the organisation values. "Hang on", I hear you say, "Just wait a minute. Organisations have been putting out statements for years about what they want in their new culture. People can often quote chapter and verse from the CEO's latest values statement. Millions are spent on flashy communications. And nothing changes."

Written by Published in Agile

There has been a lot of talk at work recently about agile maturity checklists. There are dozens of them out there in the wild - the Nokia test, the unofficial scrum checklist, spotify checklists. Every organisation, at some point in their agile journey, seems to become consumed by a burning desire to measure just how agile they are, and sets about creating some sort of ultimate agility checklist mashed together from ones found online plus whatever else they can think to throw in.

There are a lot of reasons organisations want to measure agility. Some of them are good reasons, like looking for capability gaps so coaches and leaders know where more guidance is needed. There are also a whole lot of really bad reasons for measuring it, like comparing teams against each other at bonus time, or looking for conformance to a corporate agility standard. The biggest problem though with most agility checklists is that they measure the wrong things. They tend to focus on specific practices rather than focussing on desired outcomes. They are doing agile checklists not being agile checklists.

Written by Published in Agile

It's always good to go back to first principles occasionally so let's take a look at the agile manifesto. How does it go again? Processes and tools over individuals and interactions... No wait, that's not right. It's the other way around. But anyone observing the agile community over the last few years would be excused for thinking otherwise. For a group that follows a manifesto that explicitly prioritises individuals and interactions above processes and tools, we certainly get very hung up on processes and tools.

Be warned...this is a bit of a rant so you might want to stand back to avoid getting any on you.

For the last few years, the majority of the conversations I have had with other agile practitioners have been about processes and tools. Are you a Scrum or Kanban person? Do you prefer safe or less? Rally or jira? My response has typically been that they are all valid and I will use whatever is appropriate to best support the individuals and their interactions. Recently my response has started to shift towards violently banging my head against something solid, as it's more fruitful than yet another safe vs less argument. At least there is a chance that I will render myself unconscious and not have to hear yet again how less is "more agile" than safe or vice versa.

Calendar

« August 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