Lean Thinking

Tuesday, 11 April 2017 17:19

Lead by Example

Published in Agile

Leadership is crucial to a large scale agile transformation. You can go so far bottom up but to achieve any sort of real scale you need to get some leaders involved. A lot of what I do day to day is get leaders involved and engaged in the transformation process. When talking to leaders, this question inevitably comes up - "What is the single most important thing I can do as a leader to make this work?" For quite some time, my standard answer has been "Set a good example."

Have we ever seen this situation - the boss has just announced a fantastic new agile change program and that he or she is right behind it. "Agile is the most important thing the organisation can be doing" they say. But over the next few weeks it becomes clear that they aren't turning up to the business scrum, are too busy to make the sprint review, can't afford the time to attend backlog refinement. Then other people's attendance starts to drift off. "Too busy" becomes the standard excuse for missing something. The agile transformation falters, struggles on for a while, then vanishes without a trace.

Tuesday, 13 December 2016 09:12

Capability Building In Practice

Published in Agile

Last time we looked at how to transform large organisations by building capability internally rather than buying capability externally. There are a lot of benefits to this approach. It's faster. It's cheaper. It's more effective. But it does fundamentally change the way an organisation sees its agile transformation program.

Most of the time, a traditional coach-led transformation program is set up to minimise the disruption to staff. Apart from some training and a new way of working (and maybe a slight blurring of strict job titles), the organisation sees its staff doing pretty much exactly the same thing they were doing before the change. Developers develop, testers test, they just do it in a new, agile way. With an internally-led transformation, this is not the case. A significant number of staff will be involved in this program for a long time. This will impact their day jobs. So the first rule of internally-led transformations is - give people time.

Tuesday, 20 September 2016 18:42

Principles Part 4 - Feedback Loops

Published in Agile

So, where are we now? Over the last few weeks we have looked at the first 5 of my agile principles -

  • They are built around small, self organising teams
  • The team has a clear vision of what they are doing and where they fit into the bigger picture
  • The team has a well defined backlog of work
  • There is a content authority responsible for making sure decisions are made quickly
  • There is a clear bidirectional service agreement between the team and the rest of the organisation

We have a pretty good setup going now - we have an efficient delivery engine (the team), a destination (the vision), a route (the backlog), a navigator (the content authority) and last time we added a clear service agreement, so the team and organisation know what's expected of each other. With this sort of structure they can really start to get things done. But there is still one more thing to add to make the team really high performing - the ability to improve.

This is where my sixth principle comes in -

  • There is a fast feedback loop that allows the team and organisation to optimise both the process and the product.
Tuesday, 06 September 2016 18:38

Principles Part 3 - Service Agreement

Published in Agile

When we left our hypothetical team last post, they had the first 4 of my principles applied -

  • They are built around small, self-organising teams
  • The team has a clear vision of what they are doing and where they fit into the bigger picture
  • The team has a well defined backlog of work
  • There is a content authority responsible for making sure decisions are made quickly

They have their powerful delivery engine (the team), they have their destination in mind (the vision), they have their route planned (the backlog) and they have someone looking head and changing the route (and even the destination) if things change (the content authority). Is that all they need?

No (otherwise I would only have 4 principles not 7). The team is going to need some support from the organisation. Management support to help remove roadblocks, release funding appropriately, make sure the team has the right resources and so on. At the same time, the organisation needs to know that the team is going to get to its destination in a reasonable time and at a reasonable cost. After all, this isn't a casual road trip; the purpose is clear - to deliver business value, and the organisation needs to know that the team is doing that.

This is where principle 5 comes in -

  • There is a clear bidirectional service agreement between the team and the rest of the organisation
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.

Calendar

« January 2018 »
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