I wrote a script to extract Azure DevOps work items. Why?
Because I wanted to test a hypothesis.
I wanted to prove how our software projects often miss the point.
To do that, I thought I could mine existing Azure DevOps data to prove something. But as I explored the Azure DevOps API, I concluded that the actual data itself isn’t essential.
The data models at the heart of our most popular backlog management tools don’t care about our work items. Volume matters. The volume of work item data means we lose the most valuable work items anyway in the complexity of teams, workflows, and states.
So instead, I changed my focus to generate data. I wanted to generate work items to see how easy it was to swamp the information in the data and when that critical mass occurred.
Look around us at our backlogs. A generation of busy work has left them in a terrible state.
So many of our user’s opinions, our hopes, thoughts, bugs and dreams get invested and encoded in backlogs living in work item tracking tools such as Azure DevOps or Jira. We are invisibly invested in these platforms. We take for granted that they work in our favour.
Occasionally we might haggle or discuss our workflows or talk about how work items should be written. However in the final analysis – only the content matters and often our tools obfuscate too much of the intention.
The Big Bang Transformation
Work items are subjective. Billions have been spent on Agile transformations to make work items more useful – easier to code – simpler to code – more generic. Billions more have been spent on lo-code platforms and consultancies that promise simplicity of implementation and that the business can ‘finally control IT’.
However, all of these transformations and actions miss the point.
Software needs subjectivity – it lives on opinions. People with real money buy software that helps them with something. We don’t need all the people to buy our software – just the ones that help us achieve our business goals. And we don’t want to write something “generic” because “generic” sucks. Generic is cheap. Generic is freely available.
Customers don’t buy generic designs. Customers buy cheap. Or they buy style. Sometimes they buy a dream. Or for convenience. Occasionally they buy it because we tell them they need it.
Therefore our opinions in our Jira our Azure DevOps are the gold we need to turn our average software into our gold software. How do we find them? And more importantly, how do we turn them from work items in Jira into something our customers will pay more money for?
The Implementation Details
For a successful product then we need two things. We need opinions and we need craftsmanship. We must learn to separate our what from our how from our why.
- What are we building?
- Why are we building this? And for who?
- How are we building to ensure we give the who what they want in line with their expectations?
- How do we keep this alive? Reduce technical debt, make our solution supportable?
And then how do we ensure the delivery is in line with expectations?
And at the point that the work item meets the developer – what happens?
At this point – the opinions meet the unopinionated:
- A good backlog is full of opinions.
- A good codebase lacks opinions but has a detectable style.
Because the developer cannot be opinionated in the eyes of the customer. The developer cannot be the one that breaks the spell. The organisation encourages and guides the developer to be creative.
We end with an opinionated backlog and strict guidelines on how the software product is developed.
Sounds good? But how do we get there?
Drop me a line to find out more.