NOT SHIPPING STUFF? XPS SECRET WEAPON: COLLECTIVE OWNERSHIP BEATS SILOS EVERY TIME
đ Specialization => Silos (And Why Thatâs a Problem) Many will read this and think they already do it. But there is always more to do especially as scale always attempts to reinvent this problem in new ways. What was once the solution to last weeks problem is now the cause of todays problem. This is a process that should continue left all the way up the chain. You hired a âDeployment Wizard.
Read more
BREAKING DOWN SILOS: HOW ALIGNED TEAMS SHIP FASTER
Every tech leader has seen it: A âhigh-priorityâ feature takes weeks (months!) longer than expected, not because the work was hard, but because of misalignment between product, engineering, and delivery. The root cause? Teams optimized for local efficiency, not system-wide flow. When product defines requirements in isolation, engineering builds without early feedback, and delivery is brought in too late, delays and rework are inevitable. But the best teams donât just collaborate moreâ they redesign their workflow to eliminate handoffs entirely.
Read more
STRUCTURAL FAILURE LOOKS LIKE QUALITY AND DELIVERY FAILURE.
Different ways of working have different failure modes. We tend to pick ways of working that are simple to understand but have incredibly complex and costly failure modes. All our processes can be split into 2 approaches: handoff over multiple teams cross-functional team Both approaches have benefits and shortcomings. However, humans are not wired to understand the shortcomings of handoffs. This is because we donât see the feedback loops; these processes exist in time, making it incredibly hard for us to grasp problems that occur over time.
Read more
AGILE IS DEAD - HOW CAN SOMETHING THAT NEVER WAS BE DEAD?
TLDR This debate about agility is allegedly about getting more done, but its not. Itâs about people being unhappy because the way we work can be disempowering, disrespectful and demeaning. It is horrible being on the end of a sustained drag of picking up individual tasks, doing them and picking up the next with no connection to the impact of that work or say in how or what should get done.
Read more
TECHNICAL DEBT IS NOT CONSTRUCTIVE
The Metaphor Technical Debt is typically a measure of the cost of developing software. Given time pressures it is often desirable to make short term decisions in order to enable the release of value sooner. This can lead to software that is more difficult to maintain and modify - for instance it will often lack the necessary abstractions or have poor structure. This software is often said to have a high âtechnical debtâ.
Read moreGOING FASTER DOESN'T GET SOONER - DOING LESS DOES
I think an image of Sysiphus pulling a backlog up a hill sums this post up. Co-pilot wants the agile coaches to wear capes and a sprint review party at the top of the hill. Scary stuff! I say things like âHumans cannot intuit multiplicationâ, âcomplexity is multiplicationâ, âwe can manage complexity but not remove itâ. TLDR The glue for all this is that the amount you go faster does not produce a straight line with reduction of time to get there.
Read moreIS / SHOULD WHAT WE DO WHEN BUILDING SOFTWARE BE CALLED ENGINEERING?
Agility as learning - engineering as the realisation of telos Other classical forms of engineering are not really working in complex adaptive systems, they are in physical systems. Whilst we can take scientific method from them, the thing we are measuring and building for will change its behaviour - and we are in the business that should be designing for this. This is very different to say a bridge or tunnel - which are phenomenally complicated things.
Read moreDEBUGGING TEAM DYSFUNCTION - SAFETY
I recently got told that the cycle of depression goes something like this You feel like you should be doing something Not having done it leads to you having negative thoughts (usually about yourself) So you promise that you will do the thing which may also involve negative thoughts goto 1 The point behind this is that not doing things and also feeling bad about not doing things gets into a cycle that leaves people feeling depressed.
Read moreSOURCE CONTROL LOG HYGIENE - AKA SHOULD YOU SQUASH COMMITS?
Engineers love things to be neat, simple and clear. Itâs all we do! When we are implementing something new we should realize that if we reorganize everything then we can make a change in a single place and Blam! we are done. Working in this way is incredibly safe if we have other good engineering practices - such as outside-in TDD driven by meaningful customer interaction based requirements. This results in almost every single engineer - ever - at some point in their career deciding that squashing commits is a good idea.
Read moreSABOTAGE: USE GOVERNANCE TO COUPLE USER BEHAVIOR TO CODE DEPLOYMENTS
In engineering we can do so many things that have changed the way experience is delivered to customers. Sufficiently advanced tech looks like magic (to butcher Arthur C. Clarke). The next bit is likely old news for many readers (ie private companies in industries like ecom) - however, in public sector governance this might fall under the category of âradical thinkingâ because we rarley see this happening. It seems like contract negotiation maybe gets lost in the weeds and misses the big picture of what constraints the agreement puts on how delivery can work.
Read moreCOMPLEXITY KILLS PROJECTS - BUT YOU *CAN* MEASURE IT
Complexity kills projects It causes everything to stop as more and more energy has to go into changing the existing system rather than producing the desired work done. There is a wonderful equation in physics: Work Done is Force times Distance. If you fail to move something over a distance, then you have not done any meaningful work. Think about that next time you are holding a weight - it doesnât mean you are not expending energy.
Read moreIS 'DONE' A TOXIC IDEA? AKA RISE OF CEPHALOPODS AND DISTRIBUTED CONSCIOUSNESS.
Done is the idea that something is finished. It has reached its end state. It has been built, it has reached its teleological end. Isnât it strange that something that has only just been built is done? It has gone through its life cycle? It has achieved its purpose? Does that sound like something that has just been shipped or something that is about to be retired? Do we really mean Done?
Read moreWHY COUPLING AND COHESION IS A TERM PRODUCT AND DELIVERY NEED TO UNDERSTAND DEEPLY TOO!
Coupling and Cohesion We work in a world where we build things that need to change and they need to change in ways we cannot really know yet, Because of this our primary design goal at all levels is to be able to make changes - therefor when we have systems that are hard to change we know our designs could improve. This means our delivery, product and technical designs all can have the same ideas and principles applied to achieve slightly different practices and understanding - but all be connected by the same framework.
Read moreSABOTAGE! HOW TO DESIGN A PROJECT WHERE EVERYTHING WILL GO WRONG AND MOST PEOPLE WON'T UNDERSTAND WHY
Why write about sabotage? Skip this section if impatient, it is introducing an idea for this series of blog posts, and why. I have been trying to write a positive piece to explain what âgoodâ would look like, and itâs really hard because I donât think there is a space that is good - it is more the space of âwell we tried those things and found their tradeoffs suck, so now we are left with spaces and ways of working that avoid those patterns - and if they are required we deliberately choose them expecting, and so measuring and managing, problemsâ.
Read moreON DELIVERY, PRODUCT, VALUE, AND THEIR RELATIONSHIP WITH CLIENTS AND CUSTOMERS
So often I go onto projects that are floundering because basic errors have been made in team structures. This is simply because often people put into non-technical roles lack the holistic view and deep technical expertise of how whole systems behave. The view of these roles is often that they are just about maintaining and updating spreadsheets of how progress is to be tracked against timelines - which is arguably one of the largest wastes of resources when a project is late.
Read moreWHAT CAN STARCRAFT 2 TEACH US ABOUT DELIVERY: COST OF DELAY
Starcraft 2 is a Real Time Strategy game (RTS) where 2 or more players play against each other to build a base and construct units and then blow stuff up. The first person to lose all their buildings loses. Lots of fun. Its 14 years old and made me realise something really important. Most games that I invest time into getting good at end up giving me insights into what we do professionally.
Read moreQUEUES AND BACKLOGS ARE A CAUSE OF LOW QUALITY IN DELIVERY
A question Are delivery and product people aware that in engineering, we have various types of queues and buffers? There is a significant amount of science and theory behind queues and their managementâit is essential because they are a core part of how large-scale systems perform. How much of this theory, experimentation, and practice exists in the product and delivery space, where the digital delivery production system happens? In my experience, it is none but has anyone tried to cross pollinate here?
Read moreMODERN XP SHOULD NOT BE FOCUSSED ON ENGINEERING
Who were the XP People When XP came about it was from a position of highly skilled people with a wealth of experience attempting to describe a sane way of doing the whole thing that was known as engineering. This is back when everyone from delivery to production were considered engineers. These people were generalists, they understood the customer, the business, they were entrepreneur minded people, they wrote books and created community in an era where most communication took place via a printing press and book shops.
Read moreWHEN WILL IT BE DONE? FEEDBACK LOOPS AND DETERMINISM - WHERE DELIVERY MEETS ENGINEERING
In the delivery realm, we have one fundamental question: How long until we get our stuff? Gross Lead Time Does Not Depend Upon Estimates The last post summarizes how gross lead time of delivery does not depend upon estimates - the vast majority of the time comes from how the system is structured. This system is what produces the enormous variance via feedback loops (and later we will find also wait times, but we have not considered multiple pieces of work yet).
Read moreFLOW: SYSTEMIC PREDICTABILITY COMES FROM ELIMINATING FEEDBACK LOOPS
TLDR I want to get to writing about how capacity of teams works with rates on input and throughput - but to get to that I think the previous 2 posts need summarising in a way that can be taken as a simple call to action. The summary of these posts is that if you want to go fast and have quality and do surprising things then we need to employ cross-role ensemble teams.
Read moreWHY ARE WE LATE? HOW DO WE INCREASE THROUGHPUT?
Humans are terrible at understanding feedback loops In The Goal it is stated that businesses have about 80% waste. This means for every 100 spent only 20 delivers value. This sounds surprisingly high. By the time you read the following I think you will suspect this is low for the operational processes involved in designing, building, delivering, running and maintaining software. We know people are bad at understanding the effects of compounding.
Read moreTHE POWER OF PREDICTABLE METHODS
Table stakes - Best practices and predictable repeated failure Engineering projects often go badly wrong and waste large amounts of money and damage the mental health of those involved. The cause of this is often seen as deployment and quality failure. However the root cause of this is often the decision making frameworks.I donât expect anyone to just trust me on that, but what I do want to show is that when we introduce some structure and analysis it is pretty simple to fix a lot of problems.
Read more