I took my first steps in technology over 20 years ago. If we exclude the year off I took in 2006 I have always been employed in many different companies and I can say with certainty that I worked on a “shitload of products” and I use that specific term with purpose, read on to find out.
During all these years, being somebody that loves learning, I ended up working as system analyst, developer, tester, business analyst, manager, leader, coach, change agent, plus some other short term hats.
If I exclude the last 6-7 years where I had the skills and the ability to influence decisions I can go back and say for sure that the products that were initially envisioned, before any customer feedback was used, can be called a shitload of useless stuff and one or two good ideas that resolve real customer problems.
Very often the product envisioned was very similar to the product that we delivered.
Am I saying that in my first 13 years I worked I mainly produced waste?
Pretty much YES.
Another thing I remember in those early years was that I was never in a team where we could say, oh thank god we are busy but it’s not too bad, we can do our work, go home and have a balanced life. Invariantly there was pressure. We need all this by that date, come on! Work faster!
To me, it always felt like we were told by Dilbert’s boss that if we shove some more paper in the printer it will print faster. Also, when we were not busy, then managers will fill our capacity with a new shitload of useless products created for the purpose to make people sweat, very often no thought on the customer whatsoever.
Am I saying that trying to deliver fixed scope, fixed date shitloads of products creates big problems to the workers that build them?
YES, not even the pretty much is needed this time.
Another thing that I have noticed through the years is that without exception, companies older than 3 years have already built a shitload of products that are now impeding their ability to respond to change and survive. We will call this “shitload of legacy systems”.
This specific shitload is used as the excuse for not being able to change, as if saying “yes sure, we can’t compete with the market and we will die soon, but it’s not our fault it’s the fault of the legacy system (that by the way we built)
Am I saying that the shitload of products are also causing the slow death of the companies that created it in the first place?
Next time you start a product, think twice before rewarding people for the delivery of all the scope, in time.
I have been helping organisations deliver products that matter to their customer as soon as possible, I am not in the business of delivering projects or shitloads of products.
I am researching new ways of demonstrating THE VALUE in MONEYof the “non built shitload of products and features”, if you are interested, let’s do this together.
I have had a lot of conversations, with agile people and not, around the topic of measuring success of an agile team. I have heard all sorts of metrics thrown around, from velocity, throughput, number of bugs or lack thereof, and so on.
The fact is that those metrics are completely useless, let me tell you why.
Imagine that your team in a period of 3 months has increased its velocity from 24 to 48. What does that mean? Some people will tell you they are 100% better or even 100% more successful!
I say that they are 100% better at delivering stories (assuming they didn’t game the metrics)
More than likely they work in an organisation that measure success based on the old Budget-Time-Scope paradigm.
Unfortunately in your search for speed you are sub-optimising your system and not achieving the real goal of your company.
What is a successful team?
A team is successful if they help the organisation they serve be successful, regardless of how many story points they deliver.
Let me tell you what a successful team measures.
A successful team measures business outcomes. What are business outcomes? Let me give you some examples:
1) x% increase week to week on downloads of your mobile app
2) y% increase in signups month to month
3) z% reduction of customer support calls month to month
or any similar outcome depending on your context where x,y,z>0
Because an organisation that obtains those outcomes is normally successful.
Even more importantly, the team will continuously monitor how their actions affect the business outcome metrics they have set to achieve so that they might decide to:
Stop writing that feature, we have obtained the result and any further bell and whistle wont give us ROI
Do more of this, the metrics are going in the right direction but not as expected
Stop doing this and do something else, this feature is not producing the results we were expecting
Ah, look at what the customer is doing instead of doing what we thought he would do! Let’s help them do it in an easier way…
Now compare this to delivering all the 1 zillion stories in the fixed scope at the velocity of 48 per sprint.
Product development has been my focus (more like obsession) for the last few years. I have read all the books and experimented with many of the approaches from lean canvas to impact mapping to the 100 different ways of framing an MVP.
While experimenting I had some success, many failures but in general I have been left with an after taste of something missing. Sometimes I failed to engage by using the wrong language, some other times I failed to even get started because some people just don’t want to hear that they might be wrong and are threatened by experiments that might just show that.
I had the fortune to attend the workshop “Lean UX in the enterprise” with Jeff Gothelf in Stockholm yesterday and I think I might have found a simple tool that can help me frame the conversations and get results.
Jeff is an excellent facilitator. During the workshop he gets teams of people to design a product. I was really impressed by the simplicity of the approach and the universality of the language used. But most importantly, at the end of the exercise, making decisions on what to build first becomes trivial.
His approach is linear, simple, easy to reproduce and will resonate with anybody with some understanding of lean and agile. I have to say this is a breath of fresh air in this space where some of the authors sometimes feel they are not great if they don’t introduce some new unnecessary term that creates ambiguity and confusion (but also a lot of discussion and website hits for them).
I am going to experiment with Jeff’s approach for the next product I see, I really look forward to it. Thanks Jeff!
I recently had a conversation with two colleagues where I was trying to explain the advantages of frequently delivering thin vertical slices of value, versus working on separated components and integrating at the end.
I have been familiar with this concept for so long, and generally take it for granted, but while explaining it, I found myself at a loss and only after a good while I was able to make my point. That conversation prompted me to write this article so that myself or anybody else can use it in the future for this purpose.
Let’s imagine a typical web application with a UI layer, a service layer and a database layer. Let’s consider the very common case scenario, where our developers are specialised and can either do UI or services or databases, no cross skills exist.
There are generally two approaches to deliver this application:
Create component teams that define interfaces between the components and deliver each component in isolation
Create a team that contains all the 3 skills required and deliver small increments of value, i.e. small deliverables that include the 3 layers and are releasable.
The first option, believe it or not is the generally preferred one by most developers and traditional software development managers. It gives the first ones the ability to use their main skill, and the second ones the illusion of efficiency as they think they are using the right skills for the right purpose.
Usually the dreams of component teams are shattered at integration time. Let’s imagine they deliver monthly sprints. Each team at the end of a sprint will believe they have their sprint done, because everything works in their context. What happens in reality is that at integration time, what seemed to be perfectly defined in the interfaces generally is proven incorrect. Things don’t work, teams defend their component design and implementation, blame other teams for the integration failures and nobody takes responsibility for the most important thing of them all: the customer can’t use the value.
By the second sprint, generally the teams decide that they need an “integration testing sprint” [sic] to fix the issues that the teams couldn’t prevent by using predefined interfaces.
This is generally the sign of the start of a slow death of the company ability to deliver customer value.
Time goes by and teams become more entrenched in defending their component and blaming the other components for any failure. Integration testing becomes lengthy and painful and the customer becomes less and less important than defending the status of our component team.
Have you been there? I have, and I bet you have too.
There is a solution.
The secret is to shift, from delivering a component, to identifying a thin slice of value that cuts through all components and the customer can use.
It seems easy, and once you get used to it, it actually is. The problem is the mind shift from system to value. People are used to delivering systems and not to resolving problems, if you want to identify thin slices of value to deliver you need to focus on resolving a problem for your customer abstracting yourself as much as you can from the underlying systems.
The first thing you need to do is to have teams that have all the skills required for the full stack of technology so that each individual team can deliver customer value independently. Like this:
Each user story will deliver a thin slice of value, developers will collaborate and pair instead of communicating through interfaces and the ownership will be on value being delivered instead of software components.
Working like this, the integration issues will appear immediately, as soon as we connect the layers with the first slice of value. This in turn will help us not to build too much software based on wrong assumptions. The first thin slice might be challenging and take some time, but it will contain a huge amount of learning that will be used to reduce the time to build the subsequent slices.
We can expand this same concept to product development.
Let’s imagine our company is an international online wholesale store where clothing shop owners can buy their stock. We now have an opportunity to expand our market by introducing jewellery to our products. The business owners are very excited because they believe that the new product could increase our revenue by 30% and they have identified the suppliers to get cheap stock.
The project Jewellery is starting! Everybody is excited.
After a short period of research we find out that customers living in the Democratic Republic of Regulationstan have some restrictions over the quantity of jewels that can be bought by an individual shop in a period of time. The amount varies depending on the jewels type (gold, silver, platinum). Also, other 10 countries don’t allow watches to be bought in bulk and to make things worse, in the country we live in, Paranoidland, regulation exists for jewels sellers to obtain and store Know Your Customer information for up to 10 years for jewels that contain diamonds.
We could design a complex system that is able to comply with all the limitations and the regulations, implement it and deliver it to be consumed by the whole world in 6 months. Or we could take one category of articles that don’t need to comply to our own country’s regulation and target a rich market that doesn’t impose regulation and deliver it in a week.
The choice will depend on so many context specific factors that I cannot possibly imagine, so I won’t make it.
What I know for sure is that, if we use the second option, there will be a massive difference in the output, the difference is that after one week, our product will receive feedback from its customers. With the customer information available we discover unknowns and making decisions on what to deliver next becomes much easier.
What’s this got to do with component teams and vertical slices teams you might say.
By delivering a vertical slice of value in a short period of time, we are able to evaluate it meaningfully, and use the feedback to decide what and how to build in the next slice. More than likely the first slice of value will give us enough information that makes less important or even completely irrelevant some of the slices we were planning to build in the future.
By doing so, we are deliberately discovering the unknowns and using learning as our guide.
The feedback we receive after each thin slice is our compass, every time we release, we get new directions and make sure we are never too far off the path to success.
On Success Measure Vs Bug count and a brand new approach to building Successful products
Back from Potsdam (Germany) where I attended “Agile Testing Days”, I now had 48 hours to reflect on what I saw and heard.
Gojko Adzic presented a concept that I believe could represent a paradigm shift not only in testing but in the whole software delivery approach.
He says that we all got it wrong when applying one of the quadrants of Agile testing because in quadrant Q3 we have been focusing on criticizing the Product based on our internal understanding of how to build a successful product and paying little or no attention to the final customers’ opinion on whether the product is useful and successful or not.
To visualize this, Gojko came up of with a model for software quality that mirrors the Maslow’s hierarchy of needs where the highest level in Maslow’s model (Self Actualization)
corresponds to Successful in Gojko’s Software Quality Model. In this model the lower levels are a necessity for the upper ones to be relevant, i.e. if a product is not Deployable and Functionally OK, we should not care whether it is performant and secure or if it is useful because obviously if we cannot deploy it, it won’t get the chance to perform and be useful, you get the idea.
Looking at the pyramid we immediately realize that as a software delivery team we can only assure the 3 bottom levels of the pyramid and to assure our product is Useful and Successful we need feedback from the final customer. We must involve our final customers in the feedback loop on our products, only they will really know if our product is useful and only they can make it successful or not. Gojko goes one step further and says that when measuring the levels we can apply a different level of focus. Maybe the bottom 2 levels should be delivered to be “good enough” moving up the pyramid we need to aim to “the more the better” as we get closer to Successful.
The most impressive part is yet to come and it is basically Gojko’s approach to measuring the Successful bit of the pyramid. He introduced a strategic planning technique based on 4 questions that he named Impact Mapping. Gojko says “An impact map is a visualisation of scope and underlying assumptions, created collaboratively by senior technical and business people“. In my opinion, the most revolutionary side of Gojko’s thinking is on his focus on behaviour change. In the third question he asks “How should our actors’ behaviour change?”. By focusing on this aspect we are able to visualize the impacts that we want to see as a result of our product/idea.
Using Impact Mapping we are able to visualize and test our assumptions in our path to success. By allowing assumptions testing, Impact Mapping helps find the shortest and cheapest path to product success, not bad at all…
Impact Mapping is a brand new approach and Gojko, says he doesn’t know yet if it will apply to every area of software delivery, it is up to the community now to test it, define applicability boundaries if any and improve it, you can count on me Gojko, I am up for it!
BTW, before you ask, yes I live in the real world.