Lean Thinking

Written by Published in Agile

Last time we looked at the trend towards massive scale in the agile community and some of the problems scale leads to. We looked at an alternative approach. A scaled down approach -

"Imagine, instead of a huge program, we have small groups of teams, say 2-5 teams in a group. Each group manages its own stakeholders, environments, dependencies and the like. Each group is directly aligned to a set of business stakeholders with a common set of outcomes, is funded through an investment pool aligned to business outcomes, not specific project deliverables, and delivers value end to end for the stakeholder group."

This approach would allow the organisation to deliver value efficiently without the need for massive scaled structures and the complexity and inefficiencies that go along with them. The only problem of course is that such a structure is impossible in most organisations because they are built around large programs and large platforms and simply don't have the ability, architecture or processes to handle a scaled down operation.

So where to from here? Can we move beyond scaled approaches to a scaled down approach? I think we can and the first step in that journey is to scale up.

09 May 2017

Should We Scale?

Written by Published in Agile

There has been a trend recently within the agile community to embrace massive scale. Not just a few teams working together but really large groups. Every day we see examples of bigger programs, larger release trains, all successfully being managed through agile techniques. Just recently, a colleague ran a PI planning event for close to 1000 people spread across three countries. I have seen other organisations proudly boasting that they have "the largest release train in the southern hemisphere", with some figures on the incredible budgets that the train is managing. The SAFe framework now has 4 levels rather than 3 to enable it to manage bigger and bigger structures. Less has Less-huge to do the same.

While I celebrate the achievements of the coaches successfully helping organisations achieve this, and the incredible feat of facilitation that a 1000 person, 3 country PI event must be, I can't help worrying that this drive towards massive scale is not altogether a good thing. Large companies want scale because that's the way they are used to working. They are used to thinking in terms of large programs of work involving hundreds of people. In order to help them, we have developed techniques that allow us to handle this sort of scale. But just because we can do something, it does not automatically follow that we should do something. There are significant downsides to scale.

Written by Published in Agile

How do things get funded in the organisation you work for? If you work for most organisations, a business case will be prepared and submitted to management for approval. The conversation around approval will invariably be based around cost and benefit - how much will this cost and how much will this make? This leads to some pretty well known problems. I have written about these problems before (The Problem with Projects and Outcome Based Funding) and they are pretty well known. Ask anyone involved in funding approvals and they will tell you that the process is pretty bad and things need to be done to improve it.

Organisations have tried many things - fast track funding for small initiatives, streamlined approvals processes, delegated approvals, all sorts of things, but the process remains inflexible, flawed and generally broken. I think this comes not from a flawed process but from a flawed starting assumption - that cost vs benefit is the correct way to allocate money. I think we are asking entirely the wrong question. No amount of tweaking the process will help if the process is answering the wrong question. So what is the right question? I think we should stop asking "how much will it cost" and start asking "how much should we invest".

11 April 2017

Lead by Example

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

21 March 2017

Everyday agility

Written by Published in Agile

I was having a discussion the other day about the difference between "doing" agile and "being" Agile. My standard question when asked this is - "how agile is your life outside of work?" Usually people look at me like I have grown a second head at this point, visions running through their head of family sprint planning events ("No dad, I can't accept the washing up card, I already have the homework card and that is much higher priority. You said so yourself.") and having to get out of bed late at night to move the "special cuddling" card from backlog to in progress. That's not what I mean. I don't expect people to live their life according to 2 weeks sprints. That would be "doing" agile at home. Which would be a bad idea.

What I mean is - when you have a problem to solve outside of work, do you naturally use agile principles to do it? This also tends to produce confused looks so I usually explain by running people through the way I write this blog (yes, this is going to be a blog post about writing blog posts. It will get a bit meta). When I first started this blog a good few years ago now, it was a bit...erratic. Essentially I never found the time to do the writing so posts just didn't happen. So I was faced with a problem - how do I make sure that work gets delivered? My answer to that was to establish a cadence.

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

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

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

Calendar

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