You can buy Agile, but should we sell it?

Here is your Agile Transformation sir, I even put a ribbon on the box…

11092_ff2b6714-3be6-46f3-95f2-2bdf8f4c2180_grande

I enjoy reading the opinions and debates within the Agile community on social media, even contributing from time to time. Of late a few articles have stood out, maybe it is because I am seeing a growing trend of concern, concern for ourselves. The deepest concerns focus on the topics of “selling Agile” and “imposing Agile”, although I feel the question of imposing agile is related, in part, to resenting a revenue stream that others are achieving through “Selling Agile”.

Agile, at its heart is about feedback, about giving back and learning. Those who initially consolidated their ideas down into a written manifesto did for the best of intentions, the second line of the manifesto even states “… and helping others do it”. The point here is that the concept of Agile approach is a gift, for all. It was never created to make money.

There are very few things that have been created and given away for the betterment of the world, Penicillin is the poster child, but the concept of the internet could also be considered. The problem is what happens next – look how much money is now made from the internet. Wherever there is the opportunity to make money, someone will attempt to, and the more successful they are at doing it, the more others will be encouraged to follow.

Tragically Agile has moved from a theoretical ideology backed with a reasonable description, to a commodity. There are many many people bemoaning this slow transition, nearly all of whom are culpable – myself included. As they invested their time and efforts to gain skills and experience in this new concept, they needed to feed their families and pay their mortgages and started to sell what they had; in the knowledge that was “valuable”… You can either sell a service or a product. A service is customised to the client and is typically high value but being so customised is not very scalable,  it can’t be resold. Products on the other hand are consumer agnostic, one iPhone X is the same as another. Products are much cheaper than services, but they leverage economies of scale to enable huge profits. This is what has slowly happened.

There is now an “Agile Industry”. This used to be a few independent consultants contracting into organisations to support their self improvement along Agile principles, that work slowly morphed into what we call an Agile Coach. Then came engagements with larger organisations that required more work and the concept of the Agile transformation started turning up and that introduced the money pot of Agile training. The final step in the transition to a commodity was the certification; which is really an attempt to patent an idea. Now we have a multi-million pound industry ranging from independent consultants to large dedicated organisations selling transformation. The ultimate Agile product is the “Scaled solution” a highly comprehensive, easy to understand, standardised, easy to pitch, silver bullet offering rainbows and unicorns to all….

The problem with the product of “Agile” though, is that while most know of it, and everyone wants it, very few really know what really good feels like. We are now in the incredulous place with some massive multinationals investing in “Scaled solutions for Enterprise Agile Transformation” not because they really know what it is or means for them, but because other companies near them are investing in it. These companies are buying into their competitors decisions without actually having any competitor results to compare against. All companies want to improve, but few will naturally invite change because that is disruptive and risky, so if someone offers improvement, without making any necessary changes clear, then it is tempting to buy it. People are buying a transformation where nothing changes, a real twenty-first century emperor’s new clothes.

This is the salesman’s dream, the ability to sell something to someone who will buy it only because someone else has. If you can sell something without needed to tie a value return to your product then you can make millions, and millions are being made.

This is not to say that I don’t believe that an organisation becoming more Agile will be beneficial to them, I am just deeply uncomfortable that I can sell promises and dreams, and retire rich; free from the responsibility to ensure that those promises come true. If you don’t have to worry about the success of your product then you can afford to tailor your offering to maximise profits, which typically will mean to standardise the offering, shift it from a service to a product. To refer to a great Dan North quote, “Behaviours are practices in a context”; to get the desired behaviours you need to tailor your practices or change your context, or ideally a bit of both. However if you are selling a standard product then you need to be context agnostic, which means the results will be extremely variable.

Having worked in numerous organisations trying to make things better, I have concentrated on introducing practice at the bottom and changing my context through engaging at the top. If you can’t engage high enough in the organisation then you’ll struggle to impact the context you are working in, and the culture slowly erodes your efforts. If you only engage at the top, then the practices you are advocating will feel imposed and inappropriate which will manifest as resistance and failure. In my experience the lasting changes come from bottom up activity, enabled with top down intent based leadership, you need both. Importantly both come from within. It’s really quite hard to do this from outside and impossible to do without a locally customised approach.

I recently have had the opportunity to discuss Agile transformation with some of the most prestigious strategy and management consultancies. They are rightly reluctant to engage in snake oil promises to their prestigious clients, their reputation is worth too much to risk and they have seen their more delivery focused competitors flounder and suffer through overly commoditised transformation initiatives. However all are now feeling there is opportunity here; whether they all have the sufficient business agility to adapt their typically structured engagement models to support the more adaptive, immersive approach necessary to achieve real value change, I am not certain, some do for sure. If you start with the premise that we can do a rapid assessment followed by some predetermined structural and process changes from a standard playbook where the constraints to success are your own innate talent and efforts, then I struggle to believe you be successful. Things are likely to be different, but better?

If you want to help an organisation to become more Agile I firmly believe you need to have skin in the game of the improvement, you can do this as an external contractor, or a team of consultants but in both cases these people need to get inside the organisation, to be part of it, mutually learn with it. It is more of an experience based model than an assessment based one. Change comes from within, you can’t impose it from the outside. If you as a person want to be happier then that comes from within, from the outside I can dress you in jolly colours and paint a smile on your face but on stepping back, I now just have a sad clown.

The Agile industry isn’t really selling Agile, what is being sold is an ingredient in a recipe for success that also requires a lot of time, a lot of effort from within and no small amount of discomfort, but that doesn’t seem to sell quite as well. We aren’t selling cakes, we are selling flour, and the buyers need to be informed they’ll have to break some of their own eggs to get any benefit.  

Comments are welcomed – even criticism. It is only through feedback that we learn.

Follow me on twitter or here at @philagiledesign

 

For supporting perspectives and related ideas read these excellent articles:

https://blog.agilityscales.com/can-big-consultancies-deliver-agile-transformations-56bd3c54c87f/

https://guntherverheyen.com/2019/01/07/the-illusion-of-agility-what-most-agile-transformations-end-up-delivering/

https://www.leadingagile.com/2019/01/raise-no-more-devils-improving-organizational-capacity/

https://www.linkedin.com/pulse/rethinking-transformation-tobias-mayer/

https://www.linkedin.com/pulse/adopting-agile-youre-aiming-wrong-target-tim-snyder/

 

How company culture changes with product maturity

I recently attended a seminar with Kent Beck, a giant in the software delivery world, the father of eXtreme Programming. The topic was about the need to adapt our delivery approach based on where the organisation was within a growth pattern of, “Explore” to “Expand” and finally “Extract”. This progression was related to financial models: investment vs return, against risk.

3X diagramImage Credit to @antonyMarcano

The progression of the product connects to another standard of product theory, that of BCG’s Growth Share matrix which is a portfolio planning model used to divide up products on two axis, revenue generation and market share.

BCG Matrix

Credit @BCG

The progression from “Question Mark” to either “Star” or “Dog”, with the “Stars” finally becoming the “Cash Cows” (the dogs having been killed off along the way) is shown on the diagram. I believe the flow of “Question” to “Star” to “Cash Cow” is somewhat analogous to “Explore”, “Expand” and “Extract” and in both cases is a reflection of product lifecycle. What Kent Beck has explored is the consequence on organisational psychology in having products at the various phases.

In both models what is happening is a change of risk appetite, reflective of the changing balance between investment and return, and the consequence of failure.

I have merged the two ideas to make:

  • Exploring Questions:  Where we experience an unlikely very high return on low investment for a growing product with a small market share
  • Expanding Stars: Where we see a reasonable likelihood of a substantial return on significant investment, for a product that has a rapidly growing market share
  • Extracting Cows: (An unfortunate mental model) Where we see a very highly likely, small return on a large investment, for a product that is a stable market leader

Given this framework; Product development on Exploring Questions is typically undertaken in such small groups that the relationships between team members can be sustained without any process framework and the association between business and tech, between demand and supply, is so tight and immediate, that even most light touch Agile frameworks appear cumbersome. The best practices here are those that weed out the Dogs quickly, User Centred Design and Experience, fail fast experiments etc.

Most of the practices that we see in an Agile delivery I would describe as being suited to the Expanding Star world, rapid gains with constant feedback to ensure we on track. The key here is sustainable delivery, staying ahead of the pack. It is said that success is always a surprise, because if it wasn’t someone else would be doing it, and in this phase product development are trying to increase revenue and market share to ensure the idea, the surprise, remains theirs.

I see the Extracting Cow phase as markedly different, the risk profile and consequences of failure here are much more akin to traditional engineering disciplines. You can’t add decide to add a swimming pool to the 30th floor of a building after completing the first 28 storeys. Product delivery in this phase is much more likely to adopt frameworks and governance that avoid failure than aim for rapid gain, and we say hello again to our old friend Waterfall.

To use a different analogy, to see the changing behaviour against the consequence of failure consider the following epic conflicts:

  • In the novel, “Lord of the Rings” you have a plucky few to take on an uncountable near unstoppable foe, with a slim chance of success but a massive return of saving the world. They are gung-ho in their exploratory approach making it up as they go along. The consequence of inaction is fatal. They have everything to play for, and in the scope of middle earth, not a lot to lose.
  • The Roman Empire between 150BC and 50 AD, had one of the finest fighting forces on the planet and certainly superior to anything nearby. The gains from conquest were substantial and the likelihood of victory high which lead to an enormous expansion. They expanded because if they didn’t someone else would, they didn’t risk losing what they had, they risked losing the opportunity for more. They were systematic, organised and effective. Their only downfall was the sustainability of holding onto the new territory, grow too far, too fast and the cost to operate without sound investment can exceed the returns, and you fall.
  • In the 1983 film, “War Games”, a computer responsible for nuclear war simulation eventually accepts that the only viable course of action, is to take no action. The only winning move is not to play. The consequence of failure is too great.

For an Agile Coach it is important to understand how this product evolution impacts on our ability to work with organisations. How the mindset shaped by the product lifecycle stage transcends the product, and comes to dominates the parent organisation. Typically small fast companies grow on the back of a successful product and become large, risk adverse corporations. It is as if each company has one product and slowly changes their organisational psychology to match that single product’s evolution. Facebook changing its motto from, “Move fast and break things” to, “Move fast with stable infrastructure” is a clear example. If a company was structured along product lines then it would be reasonable to expect that the area owning an Expanding Cow would be slow and reserved, whilst an area associated to an Exploring Question to be fast and dynamic, but that isn’t the case.

What happens is that the organisation “matures” with its first product, loses that innovative capability and is trapped either trying to innovate within a highly constrained system or not innovate at all – innovation becomes a timid extension of a secure product. In an attempt to reduce risk, a mature company typically chooses to split out certain components to specialists, silos are created, technical component teams propagate, swathes of middle management appear to ensure that nothing goes wrong – and stagnation sets in.

perfection-is-stagnation-900x506

At this point an organisation in this state, paralysed and inert but still sustaining huge revenue, many consider an Agile transformation as a possible route out. Many coaches work in this environment – and most find culture the biggest barrier, most of the Agile practices are not suited for this risk adverse mindset, many Agile coaches have cut their teeth in Exploring Questions or Expanding Stars and are lost in the face of the corporate governance of a gargantuan Extracting Cow, the frustration has prompted so called “Scaling Frameworks” to appear which ape agile values while remaining compliant to the NOT SAFE TO FAIL, siloed environment.

But should the main focus of delivery even be happening there anyway? Back to BCG’s model; Cash Cows should be milked, extracting profits and investing as little as possible. The cash that is derived should be used to fund the next set of Questions and to propel those Stars. Are the mature organsiations doing this? Aren’t they all too often ploughing the cash from their Cows back into their Cows, costing a lot for low return? They hold their market share though economies of scale and the value return on effort spent, is often so low that they deliberately choose not to measure it, so as to not own up to their wastefulness.

I believe large organisations with mature products need to have a strategy that focuses on introducing exciting new products funded by revenue from their established ones. The investment should be high in the growth areas and cut to a minimum on those products that have reached the Extract Cow level. Whilst it may be prudent to have a risk adverse approach to the operation and maintenance of the Extracting Cow, that mindset, those organisational dynamics, MUST NOT be replicated in the other product development areas.

Extracting Cows die, eventually. There are plenty of case studies of huge products that have ceased to exist, some have taken their parent companies with them, some haven’t. The BCG work has shown that for companies to survive the death of an Extracting Cow they must innovate, diversify their product portfolio, use the revenue of their Extracting Cow to fund their next set of Exploring Questions, with a few being successful. Invest in tomorrow, rather than hope that today will never end. Kent Beck’s work helps us to understand that the organisational approach across the portfolio needs be variable. Through combining the two I believe it is not sufficient to diversify your portfolio, you must diversify your approach and governance, maybe even culture to match. For your Questions to become Stars you need an Explore based mindset and approach.

Organisations need to reinvent themselves, not just their product offering, in order to survive; the mindset and governance honed to operate and maintain a mature product is an impediment to discovering its replacement.

 

About me:

I am Phil Thompson, an Agile Consultant, have worked at many places in many industries and with many people, mostly in Europe, mostly in the UK, mostly in London. My opinions are my own, shaped and challenged by the people and companies I have been fortunate to work with over the past fifteen yrs.

You can reach me at @philagiledesign or LinkedIn

 

Use Service Design as a tool to challenge

Some would argue that Service Design has been around for ages, for those people that were designing and developing great products years ago, this was what they did, but didn’t take the opportunity to name it, package it and market it. Service Design, as an industry, could be dismissed as the latest reincarnation of common sense – however if it really was so simple and obvious then why weren’t we all doing it, oh how we titter at the common masses for their foolishness, uncomfortable in the knowledge we were just lucky.

Modern Service Design principles and practices are at their most effortless when there is a prevailing wind supporting those activities and their timeline, and there is a very clear vision that focuses on outcomes. Service Design is a structured approach to ensure that users are able to achieve what they need, from their initial desire to the final outcome. Within IT projects it starts with upstream investigations to ensure that what is delivered will fit neatly into the fuller user experience and then manifests more as a user-centric culture from that point on, constantly focusing on the differential between what the user has and what they need. It involves activities such as identifying the users, understanding why they want something, what they are currently doing and how they would naturally approach their need.

My experience with Service Design is less about creating great products but more about identifying and exposing poorly thought through projects. If you follow a service design approach it is very hard to accept a long list of requirements without confidence that they will deliver something appropriately sized in the users’ best interests.

It is more common in a supplier client relationship to feel the need to (and have the opportunity to) challenge the prescribed solution on a table than an in house build. We, the business, have decided we need this widget – please build the widget… This request now usually solicits a slow “Okaaaaaaaaaaaaaaaaay” from me.

The trap in front of you is to ask the obvious question, “tell me about this widget?”. The right question is, “tell me why this widget will solve your problem?” It could be that the response is a full well researched and documented study on user behaviours and needs, with a few supporting usability studies on prototypes which come neatly packaged with a user researcher to join your team. I say ,“It could be…” but really, that isn’t my experience. Careful questioning usually exposes weak assumptions and through pushing a Service Design strategy you can bring everyone to a common path avoiding too much conflict or loss of face.

Projects that proceed without a good foundation on Service Design (or common sense as it was called before it got a name) typically end in one of three situations:

  • Successful with substantial changes during delivery
  • Successful but over-engineered and expensive – and usually late
  • Abandonment

An immediate focus on the widget proposal on the table will typically take you down these paths, I’ve been there, don’t go there.

We need a strategy for this…

Been here before?

“I hear your issue and I think you are right, we need a strategy for this…” (feel free to roll your eyes at this point).

This is typically said in response to an expression of a problem – rather than a request for a strategy; and what is a strategy anyway?

 

Strategy should be a set of principles applied continuously, that support decision making to ensure alignment to your objective. It is not (or should not be) a fixed plan that implies excessive Big Design Up-Front. However I suggest our opening line isn’t referring to either of these strategies, no in this case it is much less. I will rephrase…

“I hear your point and I think you are right, I don’t know what to do. I don’t want to make a decision, because it might be wrong; but I don’t want you to think that I don’t know what to do, and I need you to remain thinking I am important.”

 

Basically the word strategy is over used and often thrown in as an opportunity to procrastinate without losing authority.

So how can we help prevent this response from being given (or even from giving it ourselves).

Firstly, take a stance that doesn’t suggest that solutions can be plucked out of thin air for a problem and then put through an expensive development process that won’t return against its own risk for months or years. Once the expectation is lifted from having to implement a solution with unknown consequences, then it is possible to retain authority whilst investigating, rather than acting.

Next understand the metrics by which the problem, and hence its resolution, can be measured. If you can’t define the metric, then you probably don’t really have your finger on the real problem.

Now suggest an idea that will affect the metric in the right direction and ask people involved what could we do to test whether the implementation of the idea will have the desired impact on the metric – a safe to fail experiment – mindful that most experiments DO fail.

Then do that test. This is a proactive decision to DO something, ACTUALLY DECIDE TO DO SOMETHING. Later assess the findings and then you can decide if the idea is worth progressing with. Now the expensive decision to invest in something is a lot less risky and the deep desire to procrastinate to avoid making a mistake is reduced.

 

Now you can call this User Research, Lean, MVP, Agile or whatever. I have avoided doing so because I don’t want to solicit an emotive response against poor implementations of these things that lead to organisations stating “We don’t do that here”. This is a call to those situations where enormous time and money is wasted with the word “Strategy” because it is an excuse to justify doing nothing hoping the problem will just evaporate!

Agile needs to be Business Strategy not IT Strategy

In my last posting I wrote about my frustrations with large projects dressed up to look Agile but without delivering WORKING SOFTWARE, so just compiling risk.

It is very easy to point and throw stones, but what can we actually do about this – and why do we often see Scrum governance at the build phase working within a waterfall implementation phase? Why do we get Water-Scrum-fall?

A place to start would be to observe where this behaviour is most likely to manifest. From my own person experience – and I’d love to get comments from others with differing experience – I see this most frequently in large companies whose main business has IT as an enabler, not as a main product or sales channel. Or basically, IT is not central to business strategy.

So I would suggest to address the issue of failing Agile initiatives / poor adoption of Agile, is to delve deeper into that business strategy, to understand how Agile principles can be incorporated into business leadership.

A common theme at Agile conferences at the moment is corporate culture and examples of Agile principles being applied outside of software engineering, and both of these are tapping away for the same reason, successful Agile adoption requires organisational cultural change and adoption of the principles throughout all departments – not just IT.

I would suggest that the first step would be to express the corporate Target Operating Model in Agile terms – explain how their roadmap can be iteratively achieved considering all elements, people, process and technology. Instead of feature driven end state targets, we should switch to Goal Orientated roadmaps * showing incremental value not a fixation on solutions we can’t be confident in.

* see http://www.romanpichler.com/tools/product-roadmap/ for details

People and Process will need to come before technology in any cultural change. People that value small steps, empowered teams and are customer centric. Processes that enable a safe to fail environment – and don’t mandate stage gate delivery. These will be seismic changes to many organisations – and would require exec level support to take root.

But how is this going to happen:

I would suggest that the Agile movement stops preaching to the choir and starts talking to the real power breakers. Getting project managers, architects and developers together is reinforcing something which is widely supported, but where it is really needed is at the executive level – and there is far too little genuine understanding of the cultural (rather than process) side of Agile behaviours with that group. We should start inviting these people to our arena and tailing our content accordingly. Produce collateral and case studies for IT departments to submit to their senior leadership.

The other route, probably more realistic, would be to focus not on the existing knowledge leaders in the Agile movement, but to those that already have the networks and trust with the necessary audience – the top management consultancies. I am pleased to see that this message is starting to get through as Delotte, McKinseys and the Boston Consulting Group have all set up Digital agency wings, mostly relatively recently, but I can’t help thinking that slightly misses the point – it once again puts Agile Principles in an IT box.

Agile shouldn’t be IT strategy, it needs to be Business Strategy.

Big used to eat small, now, fast eats slow, and Agile is fast. If we can bring the partners of the top consultancies to this line of thinking – then with top down influence we might start seeing some changes.

Comments welcome

#philagiledesign