I spend most of my days with large digital focused organisations. They usually have diverse platforms and scores of people trying to continuously deliver. But, like all huge organisations, implementing change, whether a product, process, business practice etc is a mammoth task. They talk agile, but to many, it is an elusive as a handful of sand. At the same time, agile has long since passed the tipping point. There are too many experts screaming it from the rooftops. The headlines are endless; Agile is faster, delivers value earlier, power to the people, you can change your mind half way through and it is not a problem… I sometimes contemplate starting a consultancy, just to deliver “Agile 101” to company leadership. I would do it, but I believe some guy has written a book on how to introduce agile using Lego so I think that boat has sailed.
I recently completed some research, to help me understand the different agile frameworks, and which would be better to deliver change. The more I investigated, the more it became apparent that there are many ways to chop the onion. I found a number of core questions, such as: The type of problem / improvement are we trying to address? How big are we? How mature are we? There are many others. But It’s the first question that I continually came back to. “What sort of improvement are we trying to address?” and this is the question I want to dive into today. I won’t be outlining agile solutions to these, just framing some of the problem types.
I’m sure if I chopped the onion with a software developer’s hat on, I would talk about things like SDLC and adaptive, corrective, perfective changes. But today, I have my agilest hat on and today, my onion has 6 types of change;
1) Transformation
2) Enhancements to current functionality
3) Operations – Defect Management
4) New functionality: Innovation / new journeys / new productions
5) Enablers: Exploration, Architectural, Infrastructure, Compliance
6) Internal facing work – Technical Debt, maintenance, refactoring
For each of these 6, I would ask different questions and look at how to deliver with one or numerous agile frameworks.
Transformation
The first one is transformation. It’s the word “transformation” that gets me each time. It is overused and bandied about to describe anything from a new eCommerce platform for $1billion dollars down to a simple modified architecture. But the dictionary uses terms like radical change and Rip & Replace. It implies BIG and I like my transformation to be big also. The problem is that I haven’t got a word for non-BIG. Is a new DAM, a transformation? I’ll leave that one with you. But you get the picture. Transformation is difficult and every part of your agile Spidey sense has to be activated and continually on the ball to deliver. Usually, new people, new processes, new leadership, new everything…..
The only analogy I can make is to think bringing a baby into the world and then surviving the first three months (both you and the little man) I have a son, I’m sure he won’t mind being my analogy, he lives at home and doesn’t pay rent so I need to get something out of it.
Enhancements to current functionality
Number two is straight forward and an area I spend a lot of time in. I regard it as one of the easiest environments to work in. Start-up can be a bitch but you have time on your hands. It is quite normal to set up a team, put a process in place and then wind it up and let it go. You can tweak it, review it, continuously improve it. It’s an ongoing delivery and weeks lead into months and into years. Your team matures, your processes mature and your leaders begin to understand the value.
This time, you have a new baby but then you get to watch her grow up, get a job and start to pay rent for the spare room and the car. The success or failure is very much in your hands.
Operations – Defect Management
When I meet people for the first time, I can spend ten mins trying to agree on terminology in this space. Terms like operations, defects, tickets, production issues, issues management. Each business uses different words. I was delighted when the term DevOps came into being as I can now use the term Operations in the same sentence as production defects. I have seen a number of models on how to deal with defect management. Some merge into development (thanks DevOps for helping), some have completely different teams, tools, processes. After all, you can’t tell your boss that the issue that is causing all VISA payments to fail will be fixed in the release in a week from Tuesday.
I use the same analogy as in number two. Your child is growing up but at one point they get sick in the car, or maybe they steal the car. Take your pick!
These ones need to be sorted quickly and you have to do everything in your power to make sure they never happen again. The last thing you need is to spend £50 in Halfords on industrial cleaners to get the smell out of the upholstery like I did a few weeks ago.
New functionality: Innovation / new journeys / new products
I deliberately separate these from enhancements, though there are many similarities in the way that you deliver them. I single out this type of change, not because they could be large, nor because you might need to ramp up a new team to deliver, but because changes in this arena should, in a perfect world, fall under the umbrella of Innovation and addressed using design thinking and lean start-up methods before they even arrive at the delivery front door. This would take an article all by itself (note to self) but I cannot stress enough that using these principles will provide the output MVP you need, to make sure you are delivering the right type of change, that will deliver value and with the greatest security that it will be a success for your customer and you.
Coming back to our growing little man, LEAN Start-up principles will help you pick the right school for him before you send him off to Eton and force him into a life of politics (is that a stereotype??)
Enablers: Exploration, Architectural, Infrastructure, Compliance
Internal facing work – Technical Debt, maintenance, refactoring
I will partner these together, for the sake of brevity. If we had a carpet, every leader would try to sweep them underneath. It is a battle already lost by most software dev bods. Many an architect repeats it until they get sick of their own voice (the database is 60% full….70%…90%) and then one day they stop even mentioning it until the boss gets a call on Saturday night, just after the third glass of wine and the end of Mrs Brown’s Boys to say that the customer can’t log in to the platform
It’s rather like when your 17-year-old is hanging around with the wrong crowd and you keep putting off addressing it. Then on that same Saturday night, you get a call from the police. They have picked up 3 young men in your car speeding on the A406 with two bottles of sherry and 12 stolen gnomes in the back. Don’t ask…….
So, the bottom line is that your backlog is made up of many types of change and each grouping has different questions that need to be asked. And how your organisation delivers them, whether using one framework or varying models, is a question you need to debate!
