What will it take to get Agile-friendly finance models in corporations?

My friend and coaching colleague Khali Young posed this question to me:

"What are the pain points enterprise finance people have that would motivate them to move towards venture capital style funding models?"

I'm not a finance guy, nor do I play one on TV, but I do have opinions, and I have worked for a venture capital funded startup, plus several traditional corporations.

In the abstract, my sense is that this is a typical "why don't people change when things are obviously bad" question. And the answer is usually some combination of: they don't feel the pain (although others do); they feel it, but don't have the tools to address it, or there's some other factor inhibiting change.

As always, the details matter so let's break it down. First, I'll describe the basic difference in the funding models; next I'll explain why Khali's question even makes sense; and finally I'll hazard an answer.

Startup funding vs Corporate funding

Many funded startups think in terms of "runway". Like a plane trying to take-off before it runs out of runway, startups try to achieve so-called product-market fit — i.e. a scalable business model — before their funding runs out. Many will do this in lean-startup fashion by running lots of rapid experiments as they refine both their product (or service), target market, and method of reaching that market. Now, it may be that there are extra injections of capital along the way, but these additional funding rounds will increasingly dilute the investments of the founders and early investors, unless the valuation grows sufficiently rapidly.

My experience of working at a startup, especially in a leadership position, was influenced by the very real fear that the money would run out, and this drove us to keep trying new things.

By contrast, in traditional corporations funding typically revolves around an annual planning process in which the budget for various departments (or whatever) is allocated a year in advance, plus additional funding for major projects.

The corporate landscape has changed

This corporate funding model seems to have worked acceptably well in the past, but is now breaking down as complexity and uncertainty increase. No longer can organisations just continue to grind out profits based on the long-ago discovered business model, but they must continue to innovate improve, lest they go they be disrupted into oblivion. In other words they need to get back some of the quality of innovation that startups have in spades while continuing to deliver value.

Practically speaking, the seemingly artificial requirement to forecast a year or more on advance acts as a brake on organisational responsiveness. Agile ways of working, by contrast, emphasise just-in-time decision-making, enabling rapid response to external threats and opportunities, and to internally generated insights.

Agilists would typically prefer a funding model that supported the new work structures that enable agility, such as bringing smallish chunks of work to stable, ideally high-performing teams rather than assembling teams to tackle large, annual funding sized programs of work. With stable teams (and teams of teams in place) some kind of portfolio planning can dynamically assign the highest value work to the teams without having to justify it a year or more in advance. This enables greater responsiveness in suitably skilled up and structured organisations.

And in turn, this inversion of funding teams rather than work leads to a desire for compatible forms of funding: for example block funding for teams rather than funding for large programs of work. However, currently most organisations are stuck with the older forms of funding leading to unnecessary waste in — for example — mapping the new work to the older funding structures, and needless alarm when the adaptive work systems create output that diverges from out-of-date plans.

What will it take?

Now, returning to Khali's question, I suspect that the issue is that the pains are either not being felt by the key decision-makers in finance, or — if they are — that they feel unequipped to change.

To recap, the key pain points are:

1. Insufficiently rapid response to externally changing conditions
2. Waste generated by a mismatch between responsive (Agile) ways of working and older style funding mechanisms

In a coaching engagement with finance people using seemingly outdated methods, after first exploring their perspectives and pains, I would also investigate whether they were aware of the above two pains elsewhere in the organisation, and see how they respond to that information.

If they are aware of  (or once they are made aware of!) the issues, I would enquire as to whether they feel equipped and empowered to help. Are they aware of alternative methods such as Beyond Budgeting, Conditional Budgeting, and Throughput Accounting that provide a modern body of knowledge from which to draw?

As with many examples of seeming inertia there may be a lack of awareness: if you're not feeling the pain, why change?! Or if there is awareness, there may be a lack of sufficient knowledge, skill, or empowerment to remediate the problem. And there also may be additional countervailing forces at work — it's always worth checking, and often surprising and humbling to find out what else is going on in any complex organisation!

The MVP test of (Business) Agility

What does MVP — Minimum Viable Product — mean to you?

• A. A barely functioning prototype, possibly just a mock-up, designed to test key hypotheses for a potential future product, that — depending on the customer feedback — may or may not go ahead.
• B. The very first version of a new product, designed to solicit useful feedback from early-adopters that will be used to shape subsequent iterations.
• C. An almost complete product that we can confidently release to market once the project delivers, with all the "fat" trimmed.
• D. A substandard product that leaves out essential features, but is all we're going to be able to deliver, given budget and tight timelines.

An answer of A or B bodes well, C or D poorly.

The key idea behind an MVP is to maximise learning with a quick, early version. Practitioners of real MVP leave time and budget in the kitty to change course based on customer feedback and development team insights.

As a bonus, by releasing early you establish that your development team are capable of delivering something (which also helps their confidence, especially for a new team). And you slash technical risk by forcing early resolution of issues with your production process early on, while the product is still small.

Answer A leans towards mock-ups, design sprints, or concierge MVP to test assumptions, but doesn't prove development capability per answer B.

Answers C and D are problematic. They hint at a mindset or culture with a low tolerance for ambiguity and complexity: this leads back to the old-fashioned desire to reduce anxiety through over-control by nailing down scope up-front. It's also highly likely that you need to start listening more to your customers, not the HiPPO (highest paid person in the office) [pdf].

Another test: if your MVP is around 80% of what you think you'll need, you've missed the point. MVP should be more like 5 to 20%, the smaller you can get away with the better.

Nowadays, most everyone claims to be Agile. But can you pass the MVP test?

Passing the MVP test is a necessary, but not sufficient test of Agility. It's a good indicator, but not the whole story. Let's talk about other aspects another time.

Skillful management: Beyond carrots, sticks, and kumbaya

Different contexts call for different styles of management. An over-simplified summary:

The two key points:

1.  Self-organisation requires a high level of team maturity
2.  Relying on carrots and especially sticks is disastrous for complex work

Theory X and Theory Y

It's over 50 years since Douglas McGregor introduced his Theory X and Theory Y characterisation of managers, or — as we might say today — management mindsets.

Theory X managers believe that people are largely extrinsically motivated, by rewards (yummy carrots) and punishments (beatings with sticks) and accordingly must be strictly managed. By complete contrast Theory Y managers believe that people are intrinsically motivated by the likes of Connection, Automation, Mastery, and Purpose, and function better when given support and encouragement.

In principle Theory X managers tend to favour a command-and-control style of management, while Theory Y managers will opt for self-organisation and servant leadership, sometimes parodied as everyone gathering around the campfire singing kumbaya.

The risks of Theory X command-and-control management are well-documented when it comes to knowledge work: demotivated, uncreative employees.

On the other hand the risk with "the stand back and let it happen" style of "management" as an attempt at Theory Y is that if self-organisation doesn't spontaneously break out there can be a strong tendency to fall back into command-and-control. This is particularly the case when the manager doesn't have any other strings to her or his bow.

Work Complexity and Team Maturity

Context is at least as important as individual mindset.

In a crisis for example, command-and-control can be appropriate. But be very wary of a manager who manufactures crises to justify a preference for personal control. Carrots and sticks can be also be effective for low-complexity work. [Here I'm using complexity as a catch-all for volatility, complexity, uncertainty, and ambiguity (VUCA).] 

For high-complexity work a mature, compatible, motivated, and suitably skilled team can figure out what to do and how to do it. In this context self-organisation is key and the management role reverts to setting overall direction and providing outward facing support. In this happy context, kumbaya management works.

But what if the team is lacking in the necessary maturity to self-organise, or is short on a few key skills? Throwing them together and hoping that they gel seems like a dubious bet. That's where skillful management (and coaching) can be of great value.

In the short term, a skillful manager can act as glue and internal support for the team while also helping them to develop in maturity to the point where they can self-organise without additional managerial support.

Conclusion

Really skillful managers adapt to the people and to the context. Working with people is a complex endeavour in itself and the wise learn from experiment as well as theory.

* * *

Astute readers will have noticed that I haven't defined skillful management (yet) ... stay tuned.

To Collaborate, Really Listen

To collaborate literally means to work (labor) together (co-). It presupposes a mutuality, a togetherness, camaraderie, even friendliness.

Such equality and mutual concern is far from automatically the case among people and animals. Among higher animals the pecking order of dominance and submission is more often the order of the day. Similarly with people: in a hierarchical structure to coöperate with the boss is to do her or his bidding — you submit to your "superior's" dominant behaviour. And similarly, in such a set-up, you can expect your subordinates to follow your commands. Kiss up; kick down.

But this is a terribly ineffective (and unsatisfying) way to do knowledge work. Creative work benefits hugely from collaboration — the jazz approach of bouncing ideas off each other — where my half-formed and impractical idea is sometimes exactly what is needed to trigger a key advance by a colleague. Where in an unsafe environment I wouldn't volunteer an unfinished idea for fear of ridicule and loss of reputation, in a collaborative environment the collective genius and emotional support of the group comes in to play, and it is a magnificent and powerful presence!

In today's (and perhaps tomorrow's) workplace we have a mixture of preferred individual approaches: while many people are keen to collaborate there are undeniably rewards for successful application of dominant behaviour. Also, in the presence of strong competition many will learn the virtues of alternative strategies: avoiding conflict, doing what they are told (accommodating), or treating interaction as negotiation (compromising). For the ambitious, the game becomes one of picking your battles, and judiciously applying the alternative strategies when the fight is too hard or not worth it.

People habituated to these alternative forms of interaction will typically find true collaboration very different, and challenging.

To be clear:

• To dominate is to seek the win-loss (Fight)
• To compromise is to aim for 50-50 (Negotiate)
• To accommodate or submit is to take the loss and give up the win (Surrender)
• To avoid is to walk away (Flee)
• To truly collaborate is to go after the win-wins ("Let's Dance")

[This decomposition is based on the Thomas-Killman conflict modes.]

If you have a bunch of people who all genuinely want to collaborate, you're more than half-way there. But commonly, and increasingly so in larger groups, you will find that some will start to play another game. If suitably triggered, despite your noble intentions, you may also find that you are the one who seeks to dominate, or is intimidated enough to submit, or misses the relevance and walks away.

In short, before you can effectively collaborate, a group will need to be in a state where collaboration is feasible. Perhaps the group will need to traverse the Tuckman steps — forming, storming, norming, and finally performing (i.e effectively collaborating) — and that takes time.

A great first step is to listen. Where is everyone at? What are they saying? What does their body language tell you? How do they relate to you, and to each other? This is vital information that can help you chart your way towards a more collaborative atmosphere, rather than flying blind and getting frustrated when not everyone plays ball. A bonus aspect is that when people feel heard they will typically be more positively disposed to you.

What not to do: Predatory listening

Predatory listening is an evocative phrase describing behaviours that do not reflect the requisite mutuality for collaboration. The listener waits to pounce on the speaker when they slip up, appears nervous, or expresses any form of weakness or vulnerability. It is a means of establishing dominance, or at least undermining others.

Instead of engaging in predatory listening, those who truly seek to collaborate listen for understanding and empathy.

Even if you vehemently disagree with the speaker, try to understand and empathise. Then, instead of attacking, it becomes possible to respond by paraphrasing their position and discussing alternative viewpoints and trade-offs. If you've been prepared to really listen, reciprocity often kicks in spontaneously, and if not one can say words to the effect of, "I listened to you and did my best to understand your point of view. Could you please now extend me the same courtesy?"

Key points

1. Collaboration involves working together to go for the win-win
2. It can be undermined consciously or unconsciously by dominance (especially), but also submission, avoidance, and premature compromise.
3. Listening, observing body language, and how potential collaborators relate will help you to steer a path towards effective collaboration.
4. Predatory listening is a particularly destructive behaviour. Don't do it, watch out for it, and learn how to combat it without getting into a battle for dominance with the practitioner.

Practice

By paying close attention to the different non-collaborative forms of interaction that you and others engage in you can better prepare for collaboration and creating collaboration-friendly spaces. 

What's next?

In a future post I'll delve further into diffusing and re-directing inappropriate dominance.

All Eight Agile Wastes of Hanukah

In this series I cover one "Agile waste" for each night of Hanukah.

Kind of like the purported Hanukah miracle, in which one night's worth of oil lasted for eight nights I've made a single idea stretch across eight (now nine) blog posts!

To recap:

1. Low value features (introduction to Hanukah)
2. Handovers (lighting candles)
3. Defects (dreidel)
4. Technical Debt (Hanukah songs)
5. Work in Progress (Latkes)
6. Task-switching (Sufganiyot)
7. Delays (Neyyappam)
8. Human Potential (Gelt)

How about a ninth waste? Norman Bodek has suggested "Managers' resistance to change" as a separate category, but I think I'll save that one for another time!

About the wastes

"All we are doing is looking at the time line, from the moment the customer gives us an order to the point when we collect the cash. And we are reducing the time line by reducing the non-value adding wastes." — Taiichi Ohno

Lean Manufacturing recognises eight wastes and its worth reading about these in the original manufacturing context. They can be summarised in the DOWNTIME acronym:

• Defects
• Overproduction
• Waiting
• Non-utilized/underutilized talent
• Transportation
• Inventory 
• Motion 
• Excess Processing

Mary and Tom Poppendieck translated the wastes from manufacturing to software development (slides). As with Agile software development, it turns out that most of these also make sense for any form of knowledge work. I've used their list as the basis for this series, and added in "the eighth waste" of non-utilized talent (human potential) to round out the set to Hanukah size.

I trust you have enjoyed the series, and encourage you to visualise your value streams from concept to cash, and start (or continue) eliminating waste!

Eight Agile Wastes of Hanukah: #8 Human potential

Originating in 17th century Poland, it has been customary for parents to give children gelt (i.e. money) for Hanukah.

Since the 20th century this has transformed into giving chocolate coins as a substitute or in addition to the cash.

If they wish they can then risk some of their chocolate coins by playing the Dreidel game (see Agile Waste #3).

Agile Waste #8: Human potential

When we regard human beings as cogs in a machine we cheat ourselves (and them) of their greatest ability: to learn and improve. Moreover, they frequently become demoralised and disengaged.

It is only human beings that can inspect and adapt: they can study the system in which they are part of and eliminate wastes and embrace opportunities.

Many management practices are either anything goes (which works at very small scale) or soul-crushingly bureaucratic. In this hyper-competitive and fast moving era we can and must do better.

By valuing and supporting people, they will become more energised, more productive, and less likely to leave. Replacing knowledge-workers is far more expensive than manual labour, as the time to acquire local and tacit knowledge in a new environment is typically lengthy and will require significant additional effort from existing staff.

What to do instead

There are many approaches to personal, team, and organisational development. Here are just a few suggestions:

1. Reserve substantial time for learning and improvement. As with product delivery, small batches are best: e.g. half an hour or an hour each day, or half a day to a day each fortnight. Blend individual and team learning, and personal and organisational learning priorities. Team-members should have significant autonomy in choice of learning areas. This is more difficult than it seems, but worth it!
2. Embrace the 70 : 20 : 10 model for learning and development: 10% formal training and coursework; 20% coaching and mentoring; 70% challenging assignments.
3. In product development organisations hold occasional hackathons
4. In a software team trial mob programming or start a coding dojo
5. Start a book club and read and discuss relevant books as a team or management team. Nowadays, what with books being so old school, you can also read blogs and watch and discuss relevant Youtube videos together.

Outside of work: For health and character development I personally practice martial arts, but that's not for everyone. Something that will take you on a journey to mastery that is probably not directly work-related is the ticket. Practice something meaningful long enough, and it will eventually influence how you work: here are my 10 Agile lessons from the martial arts.

Eight Agile Wastes of Hanukah: #7 Delays

Neyyappam are another traditional food fried in oil for Hanukkah. These sweet fritters are less widespread than latkes and sufganiyot, and are a specialty of the Cochin jews of South India.

I have not yet had the pleasure of trying neyyappam, but they look to be delicious!

Agile Waste #7: Delays

"A fast game's a good game."

Delays generate numerous kinds of waste:

1. If there's a long delay between planning and doing, conditions will often change, rendering your plans out-of-date.
2. Delays between activities make it more difficult to remember important details, resulting in additional defects (Agile Waste #3) and additional time spent re-learning.
3. The longer something takes to deliver, the longer the wait until benefits begin to be realised.

What to do instead

There are many great techniques for reducing delays:

1. By mapping your value stream(s) from concept to cash, you can identify where the big waits are and focus improvement efforts there.
2. Don't just limit your WIP (Agile Waste #5), limit your queue lengths. Long queues make for big waits.
3. Record impediments that result in delays and prioritise improvement activities to reduce and remove them.
4. Big items take longer to finish. Learn to split them down, and prioritise the high value components.
5. At the individual and team level, organise your work day to maximise maker time — big blocks of uninterrupted time — to help doers get stuff finished by reducing managerial interruptions.