We have all seen the press releases come out. The CTO of some big organisation proudly announces that with this new agility thing they are now able to release to market every three months instead of yearly. Great news isn't it? Great endorsement of agile techniques, isn't it? Have you ever worked in one of those organisations? What is it like working in the delivery teams for one of those organisations? Is it, as the press release seems to indicate, some sort of IT workers' paradise where features flow easily into production and there are smiles and profits for all?

Or does it feel like an endless treadmill where releasing every three months just means jumping through all the hoops you had to jump through for the yearly releases but now instead of doing it once a year you are doing it all the time? Where the nightmare month you used to have once a year to push the release kicking and screaming out the door is now your normal workload? Chances are, it's not the first one. Feeling burned out? Are we achieving our results by throwing away one of our key principles - the principle of sustainable pace?

Leadership, AgilityDave Martin7 June 2017organisational change, sustainable pace, anti patternsComment

Scaling Up To Scale Down

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.

AgilityDave Martin23 May 2017organisational change, scaling, anti patternsComment

Should We Scale?

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.

AgilityDave Martin10 May 2017organisational change, scaling, anti patternsComment

When To Remove The Training Wheels

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.

AgilityDave Martin8 March 2017coachingComment

Don't Wait To Communicate

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?

AgilityDave Martin22 February 2017team, communicationComment

Capability Building In Practice

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.

AgilityDave Martin13 December 2016coaching, capability buildingComment

Coaching vs Capability Building

If you work for a large organisation and you want to transform the way you work to be more agile, what's the first thing you do? Chances are it's hiring a coach or two. That's not a bad way to start. Experienced people to guide the transformation make things much easier. But what do you do once the first pilot is done, you have proven that it works and demand is growing? More and more people are wanting agility. Your current coaches can't handle the load. What do you do?

What most organisations do is here some more coaches. And some more coaches, and more coaches and more as demand continues to grow. Now, as an agile coach, this has kept me in work for many years so I may be shooting myself in the foot a little when I say that this is a really lousy way to do an agile transformation. Yes, that's right. You heard it. An agile coach says that hiring a bunch of agile coaches is not a good way to transform an organisation. Let's look at why and then look at how we can do things better.

AgilityDave Martin29 November 2016coachingComment

Perfect Is The Enemy Of Done

Ever been in a standup and heard something like this - "I could complete this task but I'd like to re-factor the code one more time"? What about this one - "All the acceptance criteria are met so I could move this story to done, but I won't because there are a couple of additional cases I think it should handle as well... So I'll add a couple of extra tasks and work on them today"? What about this - "The feature is complete but we can't put it in production yet... It really needs to be bundled with that other feature to make an impact in the market" ? Or this - "The MVP is done but we have decided to hold off on releasing it to market because it's not the complete, fully featured solution our customers would expect"? Or this - "We have decided to delay the release by another couple of sprints to add in some additional features that will enhance the customer experience some more"?

One description of agile is "the art of getting things done". Done is a great thing to aim for. Done means delivering value, making a difference, achievement. Unfortunately, a lot of the time we are pretty bad at it. Done has a mortal enemy that tries to prevent us from ever reaching Done. It continually moves Done further and further away from us. We take one step towards Done and its mortal enemy moves Done two steps further away. The name of this mortal enemy? Perfection.

AgilityDave Martin15 November 2016MVPComment

Simplicity In Design

In my last post on architecture, I touched on the need for design simplicity. Simplicity is one of the 12 agile principles:

Simplicity – the art of maximising the amount of work not done – is essential.

So it must be important. But how do we get there? Why, when simplicity is so essential, do we keep developing complexity? Antoine de Saint-Exupére gives us a clue -

Perfection in design is achieved not when there is nothing more to add, but when there is nothing more to take away.

When we do design, we tend to take an additive approach. We look at a problem and add features until we consider the problem solved. The problem is that we tend to get carried away and add way more features than we need. We look at the initial problem and in solving that one, we lump together a bunch of related problems and solve those as well. We also have a habit of solving a whole bunch of problems that aren't actually problems yet but might be one day, just in case.

Good design, great design, is the art of looking at a solution and paring it down the the base essentials - the minimum we need to solve the problem. Let's look at a few examples of great design. The first one has been around for a very, very long time.

AgilityDave Martin1 November 2016architecture, design, simplicityComment