X : You don't agree with agile?
Me : Eh? What? I agree with using appropriate methods based upon context.
X : Context of what?
Me : Context of the components of a project.
X : I'm not sure I understand.
Me : Ok. take your systems diagram ...
... turn it into a map by focusing on the user need, building the chain of components and asking how evolved is this component ...
... now realise that as things evolve their characteristics change which is why different methods have strengths in different contexts ...
... so, apply that pattern to your map and discuss with others. Allow them to challenge, to modify, to add missing knowledge etc.
But most importantly, realise that ...
... using agile (i.e. lightweight XP) is not the same as ...
... being agile.
Being agile requires you to use appropriate methods i.e. don't start building your own compute utility when there's a perfectly useable one out there.
X : Not sure why this matters?
Me : Hmmm. Take that systems diagram above. People often manage this with a one size fits all (i.e. outsource it all) and to make it manageable break it into "connected" areas i.e. this stuff is backoffice, this stuff is user experience ...
... let us apply one of those "connected" areas to the map. Let us choose engineering. Now, we're going to outsource this and so we're going to need a contract, so we know what we're getting ...
... well, I can tell you where the contract is going to mess up before we've even signed it. The stuff on the left will always occur excessive change control costs if you attempt to define it in a contract ...
... sitting down with a £600M+ contract, spending a day mapping and showing where the contract is going to massively overrun is one of my superpowers.
X : Why £600M?
Me : Happens to be a contract I'm thinking of.
X : What happened?
Me : They did it anyway and ...
... failed in all the right places. Massive cost overruns etc etc.
X : Why did they do it?
Me : The power of narrative. They believed in their story, they associated themselves (and their own power) with the story and they refused to accept challenge against their story.
X : Is this common?
Me : 84% of digital transformation efforts fail, over 50% of outsourcing efforts fail (and that has only come down because we count cloud as outsourcing) etc. It's more common than not.
X : But those failures aren't just contracts and purchasing.
Me : Agreed but a significant number of the failures appear to have a common thread - an excellent story built on a lack of challenge and a lack of situational awareness
X : Mapping seems a lot of work.
Me : It is. It took me an entire day to map out a £600M contract and spot the flaws ... seriously, are you really going to play the analysis paralysis card?
• • •
Missing some Tweet in this thread? You can try to
force a refresh
It amazes me that the most important metrics (lines of code, story points, cycle time, devex satisfaction) in development are the two that are never discussed, let alone measured ... mean time to answer (mttA) and mean time to question (mttQ).
Whenever we start with building a system or managing a legacy environment, we need to ask questions and get answers. Those are skills which can be hindered or supported by the toolset around you ...
... in the very worst cases, engineers are forced into reading code to try and understand a system. Upto 50% of development time can be spent on reading code ... a process we never question or optimise. That is madness.
X : Thoughts on a return to office policy?
Me : It happens for two basic reasons:- 1) loss of status symbols (top floor office etc). Many execs need these to say "I'm the boss" 2) headcount reduction (i.e. people will leave) due to a weakness in the finances.
Why?
X : What about productivity and innovation?
Me : Those are "reasons" given but they're all bogus and don't stand up to scrutiny. However, there is a third.
X : Colloboration?
Me : Stranded assets - offices etc. No exec likes looking at an empty building they spent £300M on.
X : Basically - status symbols, weaknesses of finances and political capital?
Me : Sounds about right.
X : Did you see Amazon has a return to office policy -
Me : Oh. That's concerning.geekwire.com/2024/survey-by…
X : Our strategy doesn't align with our business.
Me : How do you mean?
X : We create these strategy documents but they never really get implemented as the day to day business takes over.
Me : That's common. Can I ask a question?
X : Sure
Me : ...
Me : Do you map?
X : I've heard of your technique but we don't use it.
Me : Ok, so your business operations is not based upon a map of the landscape?
X : No
Me : And your strategy is not based upon a map of the landscape?
X : No
Me : What made you think they would align?
X : They are supposed to align and we wrote our strategy on our understanding of the business.
Me : Your wrote your strategy based upon stories. There's no means to create a consensus of your landscape, to challenge what your are doing. There is no mechanism for alignment.
X : Why do you continue to use twitter / X?
Me : Because I like the tool and the crowd.
X : Do you support @elonmusk
Me : No. I disagree on many of his views.
X : He is far right.
Me : Perspective matters. US is generally more right wing & Silicon Valley especially so.
X : What do you mean by "Perspective matters"?
Me : Elon's views are not that unusual for Silicon Valley - . There's a lot of support based upon a different view of economics and government.
X : Different?
Me : Different from Europe. cbsnews.com/news/trump-jd-…
X : People should just accept it?
Me : No. They should argue against it. The "left" did itself no favours by diluting its voice across multiple platforms.
X : Are you left?
Me : I view the market as tool to be used in the common interest of society. I'm a socialist.
X : What do you need to do in order to map a business?
Me : Ask ... 1) "Who are the users?" (at the least, include consumers and the business) 2) "What are their needs?" 3) "What is the chain of components required to meet those needs?" 4) "How evolved are those components?"
...
Me : Once you have done that, allow others to challenge it. Even better, build the map with others. It really is that simple.
X : But creating a map is difficult.
Me : Only to those used to making decisions without understanding users, needs, the supply chain etc.
X : How common is that?
Me : In business? The majority of decisions tend to be made with no understanding of users, needs, supply chain and how evolved those components are. We tend to rely on gut feel and stories with little to no effective challenge.
dX: How do you deal with strategy?
Me: First, we need to answer the Where question, which depends a lot on the what and why.
dX: And?
Me: Ok, some very simple steps ...
Step 1: Visualise your environment. That means getting people to discuss, collaborate & challenge in order to create a "good enough" map of your environment. Should be a couple of hours.
Step 2: Look at what's changing which is competitor moves, your moves & economic patterns.
Step 3: Using the map, determine where you could invest/focus on. You're not making a decision yet, you just want the options. By now, you could have spent four hours on the exercise.
Step 4: Decide where you should invest i.e. look at the options using why & what