Sep 15, 2020
When I started getting involved in project management it didn't take long for someone to bring up the iron triangle. In essence it talks about the relationship between cost, time, scope and quality and how as a manager making a change in one necessarily means a change in others. These days my linkedin feed is full of wisdom along the lines of "Good, Cheap, Fast: choose two". The times they aren't exactly a-changin'...
So rather than regurgitate that triangle, let me substitute the 3 corners with a different set of values: Form, Function and Execution.
It could look a bit like this 
Function -- The 'what'
Taking ownership of "what" is typically the realm of product teams. I'm not trying to suggest that they are the only ones involved in defining the function of a product or feature, but they are leading the charge on discovering and defining this.
Without trying to provide an exhaustive list, there are quite a few good tools out there on how to uncover function. The Design Sprint can be quite effective, particularly if you're in need of rapid prototyping and lots of fresh ideas. Equally the lean startup ethos and Lean Canvas can be a useful framework. And of course you can also base yourself more on user data, no matter if that's in the form of focus groups, surveys or insights you gather from existing usage. All of those ultimately serve to answer the same macro question "what does this thing do" or, more apt, "how does it add value for the customer". (and yes, the customer could be internal to the org)
Form -- The 'experience'
This is predominantly the corner of the creative team, and I take creative in a fairly broad sense. Obviously it'll feature the usual suspects producing stunning visual designs, but I also think of User Experience and related research, copywriters, etc. Most roles that contribute to first order "the look and feel" of your product are in this corner for me. I do say first order, because obviously there are 2nd order things such as performance, reaction time, etc.
While Form has a value of its own, for most commercial products I would say that its main purpose is to support and enhance function. There is a lot of literature on form vs function (or how form follows function if you're into industrial design), but the reality is that they can't really live without each other. Even "no design" is still a design choice.
Execution -- Bringing it all together
The 3rd component in this trinity is what I call execution. It's all the activities that take the input from product & design and transform that into a tangible product for people to use. In software, that means the bulk of the work here is in the engineering team. In reality product&design should work closely with the engineering team because while they work they make thousands of small decisions. All of those have an impact on the final output.
To give you an idea, something as simple as rounded corners on a button used to be rather difficult technically and so even though the design team might have them everywhere, when time is finite engineers might agree with design to have rectangular buttons. A particular report might be a great feature, but it turns out it takes 5 minutes to generate...does that still meet the "adding value for teh customer" test?
These kind of questions do come up and no engineer tries to do a bad job, but the decisions they make are what the final product will look like...by definition.
Ok...so play nice?
I'm hoping it's obvious that these 3 groups don't really play in isolation, even though I've seen many organisations pretend they are. How often have you seen a company go through this cycle: define a feature, get the creatives to design it, give the "final design" to the dev team, dev team produces something within feasible technical constraints, ... original feature doesn't really address the problem and isn't quite what the design team thought it would be.
It's one of the main reasons that I believe in cross-functional teams. If these 3 teams work closely together and are aligned (and incentivized) to produce a result together that tends to create better results.
Aug 02, 2020
"Let's apply some duct tape and we'll sort it out properly later on"
I'm going to take a wild guess and claim you've said or thought that at some point in your life. It doesn't really matter if it was a DIY situation, a broken down vehicle, some plumbing or any other situation where you needed a 'quick fix'.
Quick fixes in software
The truth is that when writing software we would love to fix everything properly, but for a long list of reasons you might not get to there. Could be anything from deadlines, bugs you can't quite smash, a tired developer, ... . The problem with applying duct tape in software though is that it's not quite as visible as in real life and a lot easier to forget. If it ain't broke,don't fix it; right? So why would you go back and undo the duct tape for a proper solution.
Given the reality we will have duct tape, I'd rather shift the attention to the decision of applying it. In my ideal world, duct tape is a choice. Not a tool to be forbidden, but one to applied knowingly. Anyone who's been in my team for a while has heard me say this
"There will be duct tape, I just want to know where it is"
Most of the time when creating delivery processes my goal is not to eliminate the duct tape. In fact, just like in real life there are many scenarios where a short term "quick fix" is a perfectly acceptable solution. However what I am trying to create is a situation in which the choice to apply duct tape is made for the right reasons, or at least the tradeoffs are understood. So a good process in that sense creates visibility, it creates room for discussion without being overly religious on doing "the right thing" but rather takes this on a case by case basis.
In theory this is very easy, creating visibility into what's going on can be done any number of ways and there are entire books written about methodologies that raise awareness of the work going on. No matter if you are looking at an agile or a more traditional process, they all have aspects to create visibility and inspect the work. However, the hard part is creating a culture in which engineers, or generally anyone at the front line, feels comfortable highlighting that they are about to apply duct tape and can have that conversation. And particularly that kind of culture is what I focus on. A process is only as good as the way it is executed, and a lot of that comes back to culture and team work.
Aug 01, 2020
I love a good model. Imperfect as they can be, they're invaluable in trying to organize the world and create clarity between detail and big picture.
As a consultant it was only ever going to be a matter of time before I ended up creating my own model for the world around me: the world of (software) delivery organisations.
At heart my job is usually very simple to define: create a system in which the right work can be delivered in a controlled manner. Let's unpack that a little bit. It starts by knowing what "the right work" really is.
Delivering the wrong thing isn't the goal here, or in fact anywhere I'd hope. So any system with that goal has to deal first with understanding the input and how to make sure that input fits those goals.
The second part, "a controlled manner" doesn't mean a command-control "manage the detail" style. Instead I mean controlled in a more statistical interpretation, as in "within the bounds of acceptable variation".
The last part to think about, and arguably the most important, is that any process or framework ultimately has a number of people to think about. While I do subscribe in part to the Ohno "it's the system, stupid" line of thinking, in the end the work still is done by people and so that's a dimension that has to be factored in. Each of those is worthy of a long discussion, but for now let me stick to introducing the Onion.
The Onion
The Onion really is a meta-framework, if you will. It doesn't prescribe any particular actions in the way some proejct management methods would. Instead it takes a step back and tries to place the various methodologies and practices in context. In it's simplest form, the onion is a set of concentric layers from the inside out: delivery, quality, automation, framework, governance.
Delivery
The heart of the onion is delivery. Going back to what I said earlier, designing systmes in which the right work can be delivered is essentially my job. So at core, teh capacity to put product or services in the hand of customers is what drives a business forward and generates revenue. It doesn't really matter if your product is a small toy, a complex supercar, some software or a product that is really a service like a lawyer or consultant. At the end of the day, value comes from delivering this product to people who have a use for it. That's as true on a macro level (i.e. company wide) as it is on a team or even individual level. The only difference really is the scope or type of customer, which could vary from team mates to internal teams to external customers.
Quality
I tend to look at quality through 2 questions:
1. Are you delivering the right thing?
2. Are you delivering the thing right?
Or slightly more philosophical: is delivering the wrong thing right better than delivering the right thing wrong?
The first perspective is all about understanding demand and requirements, the second is inspecting the processes. Not looking at both these perspectives is a classic pitfall when organisations "go Agile". They'll put all their focus on the second perspective, trying to do a better version of Scrum/KanBan/SAFe but end up simply building the wrong thing better.
Automation
In a perfect world where you are delivering, both the right thing and the right way, the focus shifts to repeatability. I would also expand that definition to "repeatable without extra variability". In other words, consistency is also important.
That's where automation comes in.
I'm going to take a pretty broad definition here of automation as any rules based system that gets consistently executed. In it's purest form that is probably code, but it could equally be a set of rules for people to follow and help them make decisions.
If you take that in terms of dollar value of time spent by a person it's not easy to understand that situations that require judgement and creative solutions are worth more than repeating a set of steps over and over. And if anything, the latter is more prone to human error.
So with that in mind, gear your automation towards maximum leverage while allowing enough variability in the creative/hard/unclear sitautions. 100% automation isn't a goal, it's about freeing up people to engage with the hard problems rather than the mundane.
Framework
This layer and the governance layer around it are less about directly affecting the product but focus more on the processes, both creations and management thereof. In my experience people discuss this layer a lot, but often don't bother reflecting on how this affects the other 3 layers inside it.
We're doing Scrum has become short hand for a few ceremonies with sprints and daily standups. Similarly KanBan seems to have been reduced to swimlanes and no sprints.
Consider this though: which company has ever won because they had the best prince2, scrum, kanban, SAFe, ... implementation? I'd argue those that won consistently delivered value to their customers, and their internal process was likely some amalgamation of things that worked for them.
Governance
In many ways this layer deals with the most important decision of all: the decision of how you make decisions.
Governance isn't about picking a particular framework, let alone directly impacting quality levels in the delivery. The core problem of governance is around defining focus, boundaries, tolerances, and even strategy. It sets the broad guiedes for what is valued, what the organisational design should optimize for and the top level execution of how that will be achieved.
Summary
As you move through the layers 2 dimensions change. The first is very obvious: you are moving away from directly impacting the core. The second is the time it takes to get feedback on a change. Changing a line of code has immediate result, tweaking the parameters of how you make decisions will take quite a while before the effects are seen throughout the organisation.
This is at heart the difficulty with moving from individual contributor roles into leadership, and either of those trying to overreach too far is likely to have negative effects. In fact individual contributors typically look from the inside out, whereas senior managers tend to look from the outside layers inwards. As a result they might optimize for different things and at times even seem at odds. This model however has helped me for well over a decade in staying grounded, and help teams focus on the place where they can add most value for the entire organisation.