In my last post on Agile I introduced two issues that I believe are extremely important to companies that want to stay in the competition for customers. They are equally as relevant to today's discussion about Lean and Lean Startup.
The first is that new business techniques like microservices and DevOps really enable a different pace of innovation and hence offer up new ways to think about giving customers more of what they want.
For teams, it means more innovation, more often, in direct response to customer actions on a website or an app.
Agile is not suited to creating the agility companies need in that situation. We now innovate dozens of times a day. Agile has given us a great basis, along with Lean and techniques such as KanBan, to work faster but not at this cadence.
The second issue I raised was belief: how people come to believe in transformation.
Why belief is so important is that in the modern workplace you run out of techniques at some point in your innovation cycle.
This is a critical point missed by so many people who talk about transformation. You are transforming, at a certain point, to a no-technique, process-lite way of work. You are going to depend on emotion and belief to get you through. Agile, Lean, KanBan etc, all these will take us only so far.
What you need very often is mutual belief that you, as a group, will find solutions, you'll do it fast and with integrity plus respect for each other and customers.
Belief is an unplannable asset that you just cannot buy. It comes from giving people permission to find a way. Sounds kind of loose but that's the way talented people function best. Give them room, drop the rigid planning and reporting procedures. Let them find a way.
My teams have done that with Agile. They've pushed the boundaries of Agile and created new ways of work that in the end rely on us all believing we will find the right answers for customers because we are smart enough and disciplined enough to commit to that goal.
We were creating big Walls full of units of work. Were these Agile Epics and Stories? I suppose to a degree they were but we thought of them as any mechanism we could find to capture what users wanted.
They could be tweet length statements, photos, drawings, whatever it took to find a way.
In some places this process is referred to as story decomposition. But when you disaggregate in the way we were doing, you can't truly say these are stories. The significance of these small units of work only dawned on us slowly.
You are doing more than that. You are really making statements about value.
Going Beyond Lean to Value Seeking
After wrestling with Agile in this way, we went on to explore Lean techniques and we found Lean a useful discipline for us. To a degree we became obsessed with removing waste and wait-time. When you push to that degree you probably over-optimise.
By that I mean you think you're doing all the right things but by pushing always for efficiency you miss the system deficits you are creating. We wrote about that Pareto Optimisation in Step 6 of our 12 steps. You lose Pareto Efficiency when you go one step too far with optimising an area of work and then cause inefficiencies elsewhere.
It's often impossible to know where those Pareto deficits come in but it is possible to be more sensitive than we were being at the time.
Put that obsession to one side though, we also found that Lean makes teams think more about why they are working.
If you consider that we had these disaggregated units of work, it would be possible to abandon any one of them if we wanted to save on costs, which is how Lean gets you thinking.
So we had to find the right criteria for why we would continue to do work.
Bear in mind we could be working on dozens of work units, even hundreds. So we found that the idea of value was what gave sense to our decision making. With all these work units which ones would add value to customer lives quickest?
We imposed on ourselves the obligation to keep asking that question and in place of Lean we began to create a value-seeking culture.
Anyone who is familiar with value-stream mapping will know that in the end it is just a waste disposal process. It isn't adding value, it is taking wasteful activity out.
We wanted a more proactive and positive sense that we were doing valuable work.
You can't always know that, so to make value function for you, you have to be experimental. You have to create sustainable delivery matrices that you can push through to customers to see how they react.
Similar thoughts have been expressed by authors like Jez Humble who writes about continuous delivery and story toggles. Jez's work also draws on Lean StartUp and the idea of MVPs. We've argued against MVPs elsewhere.
MVPs do nothing to discourage feature packing by product owners. Instead you have to draw Product Owners further into the project and you do that by keeping the business objectives loose and iterative.
We never felt a need to have an MVP. In fact I discourage it. We stream new ideas and features into the flow and we have grades of features that gives us flexibility about resources. Teams are allowed to stream a low-functioning feature in before committing to an enhanced feature, for example, when they have some evidence that the feature has value.
The origins of FLOW
All this was a pivotal movement for me. We now had a system where some of the traditional weaknesses of software development were intuitively being resolved.
We saw improvements in productivity because it follows naturally from Lean that you have less waste. But we also saw quality improving as our new way of prioritising work by value removed context-switching by team members.
By context-switching I mean, pausing work because you are blocked, starting something new and then coming back to the original task. This can be frustrating for everyone. Working on multiple projects is wasteful, especially if you have to pick up someone else's half finished tasks. Usually you have no option but to redo them.
As we began working this way, each day at our stand-ups (yes I attend stand-ups) it became clear what the blockers were because we were clearer about our priorities. Wait-time or inefficient hand-offs stuck out like a sore thumb.
We began exposing dependencies more easily too, because we all had our eyes on those highly visible work breakdowns. Something else had become apparent.
Our pioneering use of FLOW "demanded" that we also use DevOps. DevOps didn't have to start as an underground activity, in the way many IT innovations do. It just made sense and as CIO I made it happen by co-locating teams from Development, Operations, Analysis, Testing and Product.
The consequence of that, of course, is that there are even fewer handovers and, as you can read elsewhere, our shorter cycle-times were allowing us to by-pass code collisions, multiple code branches or other complex integration challenges that still occur with Agile.
We got an additional cultural benefit. As we pushed back against the traditional job descriptions, everyone pitched in as if the team were a start-up.
But more importantly, the energy and enthusiasm was infectious. Guess what? We were enjoying our careers and not just doing our jobs. We had reached acceptance momentum. We had generated incredible belief.
That is the point at which the adoption of new techniques gets the buy-in, support and implementation of the entire team.
The significance of belief and emotion
Most accounts of digital transformation make no mention of emotion. The speakers don't pause to talk about how it felt to have people rely on you or what it means to actually care about how we work.
In FLOW emotion is really important. FLOW leverages Lean, KanBan, DevOps, Continuous Deployment, Open source, Platform As A Service, Infrastructure as Code, Cloud, MicroServices...the list goes on. But this list has quite a few things in common.
It's a dangerous list. It sticks 2 fingers up at the status quo and screams for change....which can be risky and can leave a pioneering CIO or CTO out on a limb.
But it also has an emotional core. it works through belief. Emotions are difficult for hierarchies and for systems and processes.
I have been quoted a number of times saying that I almost got fired introducing these elements but as a boss of mine in San Francisco once said to me, if CIO's don't take risks, the business wouldn't move forward. And at our level, it's not a question of "if" you will be fired, it's usually "when". Hence you have nothing to lose.
Therefore, during my career I have in fact had numerous battles with executives and even my own Technology Leaders (in previous organisations) who push back against anything new.
It's also how I became familiar with the terms "Machiavellian Leaders" and "Toxic Employees". My adage here has always been to encourage these people to do the best work of their careers...somewhere else.
And I recommend working with people at all levels in your organisation to seek out the ambassadors of change, the people who believe in what you are doing and what they want to do.
But we are often faced with negative feedback from some Agile Practitioners, Trainers and Consultants who's careers depend on the current Agile methodology.
They want you to follow the script, to not stray out of the guidelines and whatever you do, don't remove the current jargon with something simpler.
In my practice I've found emotion and belief are central to what happens when you push beyond Agile and Lean. People are relying on each other more. Success is a group effort and it's not clear what will bring it home.
The techniques and the jargon of IT, that very masculine use of language we hear around us, it becomes oppressive to people who need to believe inch other and believe in the people who are leading the effort.
I have a few summary things to say about that:
1. We have to create permission cultures, giving people permission not to fail but to experiment, discover and find new ways to work. There is no real playbook other than at a certain point trust and believe.
2. When you do that people believe in you and the organisation. They go home excited about coming in the next day and they expect you to lift their careers. You have a responsibility for their futures and their emotions.
3. Digital transformation is really in the end about the emotional transformation of the workplace. Take your own journey but don't shirk it.
We just sent you an email. Please click the link in the email to confirm your subscription!
OKSubscriptions powered by Strikingly