I am sure some of you have noticed that my blogs have been a less regular the last few months. That is because I’ve been busy on other stuff. So a break from deep thoughts and advice on the software world to mention some other stuff I’ve been working on.
To my surprise Little Book has long been my best-seller so I teamed up again with Stacy Gonzalez – who voiced Project Myopia for me – to produce an audio version of Little Book. In the few weeks it has been available sales are already outstripping Project Myopia!
(And if you can’t wait, I’ve got a pre-copy edit version I can share with you provided you promise to write an Amazon review when the book is published. Mail me or use the contact form if you are interested.)
Finally, that picture at the top of the page. I’ve been working with Nicolas Umiastowski to create a playing card retrospective. These are based on my Retrospective Dialogue Sheets In our experiments they have given retrospectives another twist. More about these soon – and details of how you can get a pack (in the mean time get in contact if you are really keen to try them.)
Like this post? – Like to receive these posts by e-mail?
Some years ago I was managing a team at an internet TV pioneer. Shortly after a release our biggest customer – ITV – was on the phone complaining about a bug. Unfortunately one set of data fields were retaining their value when they should be wiped clear. It took a couple of months before we could include a fix in the release but we were confident we would make ITV happy.
A couple of hours after the fix went live ITV were on the phone. Why had we removed the daily cache? They weren’t just “working around†the bug, they were utilising it as a feature.
Sometimes it seems the problem you think you are dealing with isn’t the problem you are dealing with. Sometimes the way to solve a problem is not to fix the problem head on. Rather the solution comes from reframing the problem so that it is easier to solve. To put it another way: the problem you are trying to solve is knowing the problem you are trying to solve.
I sometimes think of this as “go and look at it from a different placeâ€. Whatever you are looking at – problem, opportunity, objective, way of life – looks different if you go and stand somewhere else. The more different the place you stand in the more different the thing looks.
Clearly one way of solving a problem is to define it as not a problem: “it is not a bug, it is a feature.†As the story above shows, one person’s “bug†can be another person’s “feature.â€
The question is then: is the reframing acceptable to others? – can others share the reframed perspective?
By way of example, lets apply this to agile.
A big part of agile is focus: small user stories, morning stand-ups and sprint planning all help create focus. Once you decide what you are going to tackle you focus on it, push other things out of the way and do it. And do it to completion.
You might call this “eating the elephantâ€: don’t eat it all at once, carve off a small piece, eat and repeat.
Pushed to either extreme this approach has bad side effects. Focus too tightly or too inflexibility and you might deliver a thing but not a thing which others recognise as a solution to the problem. But taking a view too broadly, or being very flexible, negates the way of working because you don’t deliver anything, – or the solution you deliver doesn’t please anyone (the “you can’t please all the people all the time†problem.)
Reframing can be a powerful technique but it can also work against you if other’s reframe the problem.
So, how do you know, or rather how do you frame and decide what your objective is?
Deciding what the problem is requires some imagination, it requires focus and flexibility – to stare at the problem but be flexible in how you see it. It also requires understanding and then the ability to communicate that understanding to others.
While I often hear people say “we should focus on the problem†I wish we could spend more time focusing on the problem of knowing what the problem is.
Reframing the problem is an inherently human thing. While machines may now, or in the near future, be able to solve many problems there is a problem of knowing what problem to present to the machine.
A big part of human work – often managerial work – is framing problems and deciding which to solve and which not to solve. Framing can make a small problem big, or a big problem small. That is inherently a human activity.
So, how do you know what problems to address? how do you know where to look for opportunities?
Now isn’t that a problem in itself? – surely we could set that up as an objective in its own right. Again it needs defining and framing and… So how does one decide to eat an elephant? And which elephant? And even, why eat an elephant at all?
It all becomes recursive. You can’t recurse for ever so hopefully sooner or later you need to come to the top – otherwise you have just reinvented paralysis by analysis. Detailed problem thinking needs to be combined with vaguer, even oblique, thinking.
To make this very real: I’m a big fan of metrics, they help focus, they help you know if you are going in the right direction. But I detest metrics too because they are a blunt instrument which can mislead so easily.
Metrics are great for focus but they need to be combined with a healthy dose of scepticism and oblique thinking. Metrics have limitations.
Sorry no solutions today. Just awareness of the problem of problems.
Like this post? – Like to receive these posts by e-mail?
Those of us who don’t code any more, and perhaps many of those who do, need Electronic Monks to help us with software development.
There is an old Douglas Adam’s book (Dirk Gently’s Holistic Detective Agency) which features an Electric Monk. The job of an electric monk is to believe things for you. In Adam’s story people have too many things to believe so they offload all that believing to an electric monk. In my mind I’ve always considered part of the monk’s work to include worrying. I can’t remember if Adam’s says this explicitly or just implies it. (And as I no longer have a copy of the book I can’t check.)
I’m currently very engaged with one client as an Agile Coach (although I sometimes wonder if “Shadow Manager†might be a better term, more of that another day). I regularly find myself staring at the board thinking about the work it shows and worrying about whether it will be done. Sometimes my mind plays “what if games†– “If that card is finished soon, then the other one could move down and…â€
The same worry plays out when looking at the backlog showing work not on the board. Or when I’m talking to the Product Owner. Or indeed when I find myself talking to middle managers and others in the company who have an interest in the work the team is doing.
Basically, there is very little any of us can do to move the work through.
Sure I can call a meeting and talk about optimising our workflow. But I’ve done that a few times already.
I could call a meeting and emphasis how important the work is to the company. I’ve seen this done many times. Some non-coders – call them “the business†– seem to think “If only the coders appreciated how important this work was then they would do it faster.†I hated this when I was a coder and I hate it when I hear others saying things like “Do they know how important this is?†Business folk sometimes seem to believe coders sit around drinking tea and coffee for most of the day.
By the way, I almost wrote “and Testers†in that last paragraph but then realised testers CAN make work go faster: they can just drop their standards, turn a blind eye to issues, accept things they wouldn’t have accepted last week. Piling pressure on Testers is a more effective route to getting work done than pressuring coders. But in both cases it is probably just piling up more work.
I could go to the coders and ask “Are you done yet?†– or as 5-year olds say in the back of a car on a long journey (or just any journey) “Are we there yet?†In both cases it doesn’t change the time it takes to get to the end, the answer doesn’t usually say much but asking the question will annoy parents and coders alike.
But if I do anything – like calling a meeting or asking “are we there yet?†– which involves distracting coders from working then I am slowing work down. It is self-defeating.
Yes there are things I can do to make work go more smoothly but once a piece of work is in flight there is little I can do. Most of the change I can make are to do with the way work happens. Or to put it another way: I can influence the climate work happens in but I can’t control the individual weather events which are the work items.
All I can do is worry. Thus my desire to offload that worrying to an electronic monk. Maybe more people in and around software developerment need to recognise they are in the same position.
Like this post? – Like to receive these posts by e-mail?
I was on a panel last year when someone asked that old chestnut:
“Surely before you start coding anything you need to design an architecture?â€
As regular readers might guess I took a very simple stand:
“No, you need to get something that works, you need to show you can address the problem in a way that delivers business benefit. You can retrofit architecture when you have shown that your thing is useful and valuable. Sure spend some time thinking about design and architecture but this should be measured in hours not days. As the system grows return to these discussions but keep them to hours not days. Embrace emergent design and refactoring.â€
Another panellist disagreed:
“And…â€
In 2018 you can tell someone is about to disagree with you because they don’t start “No†or “But†they start “Andâ€
“Companies have databases, and data centres, and standards, and you need to spend some time thinking about them. You need to integrate to existing systems. Changing database schema’s, let alone database application servers is big work and you want to avoid it if you can.â€
OK, I can’t remember his exact words but that is the tone I recall. I was told, I was wrong.
Despite all those very real concerns I stand by my position. OK, maybe I need to elaborate a bit so here goes…
The thing is, I have nothing against architecture. When you build a software system you will – before very long – have an architecture. It may not be a very good one but you will have one.
I encourage all developers to study software design and architecture. Coders make hundreds, even thousands, of decisions everyday when they are coding and there is an architectural angle to every decision. Coders need to be versed in good design practices so they make good decisions.
Nor do I have anything against guiding the architecture in such a way that it becomes better with time – indeed I think that is a necessity. Neither do I disagree with architectural conventions in a system or documentation, again they become more valuable with time.
What I’m not in favour of is: believing that you can set it from the start. I believe the more you try to predetermine the more time you will waste.
Architecture is nine-tenths what you have, and one-tenth what you think you have, or should have. Architecture exists in the minds and shared models of those who maintain the system as much as it does in the code.
There are some occasion when there is a completely blank sheet of paper to start with. New start-ups spring obviously, but even inside a large corporation there are occasions when it happens; say when the company wants to experiment with new technologies and approaches, or hedge options. There are two priorities here:
Be different, differentiate the solution from what already exists
Prove that this new solution delivers something of business benefit
So: pick the solutions that seem right to you now – thats “you†plural, you and the team you are working with.
Maybe spend a little time considering your options (Oracle? MySql? CouchBase? Mongo?) but don’t spend too long, hours not days. Accept that you will learn when you start using your chosen option and accept that you may change it, or that you may make a bad decision and be cursing you decision for ever more.
The thing is: all that time spent designing the architecture, researching options and making decisions is wasted if you do not deliver business benefit. If nobody uses it then having the perfect product, perfect architecture, is pointless.
Anyway, even if you spend months and agree the perfect architecture it will not survive. Once you start work you will find assumptions invalidated, you will find things don’t work as you expected, and you will find that the cheap code monkeys you hired to implement you wonderful design do things you didn’t expect.
Now consider the case where you start a new initiative in an existing environment. There are existing databases and systems to work with. Again you don’t need to spend a lot of time looking at options because you don’t have them. Instead you have constraints.
If the company standard is Oracle for databases you are going to use Oracle. If you need to integrate with SalesForce then you need to integrate with SalesForce.
You might believe that CouchBase is a better solution than Oracle from the word go. In which case you can either:
Accept that right now Oracle is the standard and use it even if it is an inferior solution. In time if you demonstrate business benefit than you will be in a stronger position to change. Or you might find that even an inferior solution is good enough.
Or
Argue your case and hope to win: if you don’t win then you are back to the previous option, if you do then great.
What I would not do is: embark on a lengthy examination of all the possible options with the aim of deciding which is best. This takes time and means you will deliver later, which means cost-of-delay will reduce the value you deliver. Sure the great design might generate slightly more business benefit, or get sightly more performance from your development team but you are also delaying.
If you start with a good-enough solution you will learn. That learning may change your opinion, or it might confirm your initial opinion.
Remember: You are not building the ideal system. You are building the best system you can within constraints. The best system you can with the time and money available. In an existing environment many of those constraints are usually given before you start.
Unfortunately, us development folk tend to limit options thinking and exploring to the initial stages of a development effort – usually before any code is written. Once work is underway they don’t consider options often enough, we tend to jump at the first solution we think of.
Like this post? – Like to receive these posts by e-mail?
As regular readers might know I’m working on a book called The Art of Product Ownership to be published by Apress later this year. One of the chapters is entitled “Why have a Product Owner” and a few days ago a bunch of ideas crystallised into this…
The aim of the Product Owner is to increase, even maximise, the business value delivered by the team as a whole. The Product Owner does not so much create value themselves as increase the value created by others.
Think of it like this: if the team randomly selected work to do and delivered it to customers then some value would be created. (For the moment I’ll ignore the scenario where that work detracts from the existing value.) The aim of the PO is to ensure the work done creates more value than a simple random selection. The greater the difference, or delta to use a mathematical term, between random selection and an informed selection the better.
The general hypothesis is that intelligent selection of work by a skilled Product Owner will result in both more value being delivered and an increasing delta between intelligent PO selected work and randomly selected work.
This difference the value added by a Product Owner. I like to call this difference the Product Owner Delta.
Now in real life work is seldom randomly so Product Owners are not competing against random selection. In some cases the alternative to a designated Product Owners is someone else: a senior developer, an architect, a manager or someone else. In such cases this person is taking on the Product Owner role. They may not have the title, the aptitude, the skills or official position but when work is selected by one person they are de facto the Product Owner.
In other cases the alternative to the PO might be selection by consensus on the team, or a sub-set of the team. Now it is entirely possible that such a group could outperform a single Product Owner in selecting work – especially is they have market and customer knowledge, some analysis skills, time to do the background research and so on. In some cases this works, for example think of a small start-up staffed by software developers creating software development tools.
However, in some cases selection by committee might be inferior to a random selection. Imagine a team which has never met a customer, argue about what to do, duck key decisions and never say No to any request. Its easy to image a dysfunctional selection committee.
There is more to increasing the Product Owner Delta than simply selecting the highest value items. Timely selection can help too. If decisions are not being made, or committees are spending a long time making decisions then having one person simply make those decisions in an efficient, timely, manner can increase the delta.
Time has another role. Because of cost-of-delay simply selecting the highest value items at any one point in time does not maximise the value delivered. Time Value Profiles (see Little Book of User Stories or my presentations on value “How much? When?â€) expose this and need to be another tool in the Product Owners repertoire.
And of course, the Product Owner Delta is not the only reason to have a Product Owner in the team, but it is probably the main reason.
Like this post? – Like to receive these posts by e-mail?
The thing we call Agile is a virus. It gets into organizations and disrupts the normal course of business. In the early days, say before 2010, the corporate anti-bodies could be counted on to root out and destroy the virus before too much damage was done.
But sometimes the anti-bodies didn’t work. As the old maxim says “that which doesn’t kill me makes me stronger.†Sometimes agile made the organization stronger. Software development teams produced more stuff, they delivered on schedule, employees were happier, they had fewer bugs. In smaller, less established companies, the virus infected the company central nervous system, the operating system, and subverted it. Agile became natural.
The problem is, once the virus is inside the organization/organism it wants to grow and expand. It you don’t kill it then it will infect more and more of the body. Hence, software teams that contracted the agile virus and found it beneficial were allowed to survive but at the same time the virus spread downstream to the requirements process. Business Analysts and Product Managers had to become agile too.
Once you are infected you start to see the world through infected eyes. Over time the project model looked increasingly counter productive. Growth of the agile virus lead to the #NoProjects movement as the virus started to change management models.
Similar things are happening in the accounting and budgeting field. As the agile virus takes hold, and especially once the #NoProjects mutation kicks in, the annual budget process looks crazy. Agile creates a force for more change, agile demands Beyond Budgetting. Sure you can do agile in a traditional budget environment but the more you do the more contradictions you see and the more problems you encounter.
Then there is “human resources†– or to give it a more humane name personnel. Traditional staff recruitment, line management, individual bonuses and retention polices start to look wrong when you are infected by agile. Forces grow to change things, the more the organization resists the virus the more those infected by the virus grow discontent and the more unbalanced things become.
It carries on. The more successful agile is the greater the forces pressing for more change.
While companies don’t recognise these forces they grow. Hierarchical organizations and cultures (like banks) have this really bad. At the highest level they have come to recognise the advantages of the agile virus but to embrace it entirely is to destroy the essence of the organization.
Countless companies try to contain the agile virus but to do so they need to exert more and more energy. Really they need to kill it or embrace it and accept the mutation that is the virus.
Ultimately it all comes down to forces. The forces of status quo and traditional working (Theory X) on one side against the forces of twenty-first century digital enabled millennial workforce (Theory Y) on the other. Victory for the virus is inevitable but that does not mean every organization will be victorious or even survive. Those who can harness the virus fastest stand to gain the most.
The virus has been released, putting the genie back in the bottle is going to be hard – although the paradox of digital technology is that while the digital elite stand to gain the digital underclass (think Amazon warehouse workers) stand to lose.
All companies need to try to embrace the virus, to not do so would be to condemn oneself. But not all will succeed, in fact most will fail trying. Their failures will allow space for new comers to succeed, that is the beauty of capitalism. Unfortunately that space might be also be grabbed by the winners, the companies that have let the virus take over the organization.
Like this post? – Like to receive these posts by e-mail?
Officer: Well why don’t you move into more conventional areas of confectionery, … I mean look at this one, ‘cockroach cluster’, ‘anthrax ripple’. What’s this one, ‘spring surprise’?
Shop keeper: Ah – now, that’s our speciality – covered with darkest creamy chocolate. When you pop it in your mouth steel bolts spring out and plunge straight through-both cheeks.
That like Agile to me. In AgileLand everything is sweetness and light. Agile has all the answers. Everything works. Agile is utopia.
I’ve taught enough Agile Introduction courses to know this is so – and pushed ti too. There is no scenario I can’t fix in the classroom with the application of the right Agile principles, tool or mindset. And if I can’t… well in that case, Agile is helping you see the problem more clearly and you have to find your own solution.
Honestly, part of the appeal of Agile is that: Agile is a damn good story. Agile paints the picture of a better world, and so it should. Particularly when delivering an Agile training course I see my role as two fold:
In-part enough information so that teams can actually try Agile
Energise people to want to try it this way
Except, there are some dirty little secrets in the Agile world which do’t fit with this picture.
First up is Micromanagement (#1).
As I said in Devs Hate Agile, the Agile toolkit can be used for good or evil. If someone wants to be a micro-manager par-excellence then Agile – and particularly Scrum – make a great toolkit for micro-management too.
The intention behind the Agile/Scrum approach is to give those who do the work the tools and approaches to take control of their own work. When they do so then great things happen – the workers control the means of production! However those same tools can be used by very effectively by those who would control the workers.
What micromanager would not want every team member standing up to justify themselves at 9am each morning? Surely a micromanager would want working software at every opportunity? – and if you fail to deliver working software then…
In part this is because Agile is a great tool for apportioning blame (#2). When builds fail you know who did the last check-in. when tests fail you know who broke it, when cards don’t move on a board, sorry I mean Jira, then the powerful can hone in on those not pulling their weight.
Kanban is even better than Scrum here. I remember one Project Manager who used the Kanban board (26 columns!) we constructed to demonstrate why everybody apart from him was slowing work down. Try as I might I couldn’t get him to see each of problem to be worked on. To be fair to him, he was the product of a system where almost every step was undertaken by a sub-contractor, he had no power to change or reward sub-contractors, only to whip them.
Both these points illustrate the second dirty little secret: you don’t need to do everything (#3).
Simply holding stand-up meetings and end-of-iteration activities is a massive improvement for some teams.
Developers who adopt Test Driven Development will produce fewer bugs, waste less time in the debugger, and the testers who come after them will spend less time reporting bugs. Thus fewer bugs will need fixing and schedules will improve.
A Kanban board with WIP limits will improve workflow even if you do nothing else.
Yes, if you do every part of Scrum things will get a lot better.
And if you do every part of XP the total benefit will be better than the sum of the parts.
Part of the genius of Agile is that it can be implemented piecemeal. But that also means organizations and teams can stop. I’ve seen this a number of time: I introduce a bit of Agile, the immediate pain is relieved and the company looses the will to go further and improve more.
After all, who am I but an external consultant to tell them they could do better?
Once the pain if gone then the need to change goes too.
Now some dirty little secrets are being exposed. Most readers will know I have been active in exposing the dirty secret of Agile Project Management: the idea that Agile and the project model (aka project management) can work together.
Sure they can work together but… why? what is the point? Why go to the trouble of integrating Agile and Project Management?
Once you start working Agile the project model looks absurd. Hence #NoProjects – and why so many people have arrived at the same conclusion about projects independently.
In fact, it goes further than that. Companies that introduce full blown Scrum – including self-organizing teams – risk destroying themselves. In traditional, top-down, hierarchical companies Agile and self-organizing teams must be contained otherwise it will destroy the whole hierarchy. That is why banks struggle with Agile, the chocolate on the outside is really nice but sooner or later what they are eating runs up against what they are.
Finally, you might notice that in this post – and indeed in many of my other post – I don’t agree with other Agile advocates. Go and read Jeff Sutherland (I don’t agree over self-organization), Mike Cohn (I don’t agree over stories and points), Keith Richards (not the rolling stone, the APM man, I don’t agree over projects), Jim Coplien (he doesn’t agree over TDD), Joanna Rothman (we don’t agree on stories), Dan North (we don’t agree on teams) and just about anyone else and you’ll find I don’t agree 100% with anyone.
But the thing is: none of these people agree with each other.
Everyone in the Agile communities interprets it slightly differently.
The final dirty secret of Agile is: the experts don’t agree – there is no one true way (#5).
I feel sorry for new comers to Agile who expect to read the one-true-way but I’m also saw none of us “gurus†would want to any other way because we want variety and experimentation. And perhaps that is why one-size-fits all Agile scaling is always doomed.
Frog image credit: Argentine Horned Frog by Grosscha on WikiMediaCommons under CCL ASA 4.0 license
Like this post? – Like to receive these posts by e-mail?
When was the last time you read your “roles and responsibilities†description?
My guess is, it was about the time you applied for your current position. Of course, if your HR department, or agile coaches, have decided to change your description you might have read the new document but even then, did you?
My guess is most people remember little more then the job title.
Like so many documents, it goes in one eye and out the other. And the longer it is, the more detail the less you are likely to remember.
So it won’t surprise you when I say: I don’t think roles and responsibilities documents have much use.
And it might not surprise you when I say roles are pretty pointless too.
To my mind your personal sense of identity, your own idea of who you are and what you do, plays a much bigger role in the actions you take in work and the responsibilities you accept – and those you ignore.
If, for example, your business card says “Business Analyst†it is not because someone defines your work as a “Business Analyst†it is because you see yourself as a business analysts and your sought out a business analyst role. You are a business analyst because you see yourself as a business analyst. You are not a programmer because you didn’t apply for a programmers job because you are not a programmer.
Let me suggest that what you actually do has little to do with what it says in some document, rather what you do is determined by your sense of identity, your identity may well be entwined with a job title. Identity is a powerful motivator.
If you consider yourself to be a programmer, a software engineer, software developer or whatever, then you probably shun business cards altogether but the same idea applies: you are a programmer not because you read a job description and say “I like the sound of thatâ€. You are a programmer because you like doing the things you think a programmer does.
Of course this can cause problems because different people see things differently. Things fall between the gaps – your manager expects you to update the user manual and you see that as someone else job. Or things get difficult because two people try to do the same thing: the programmers try to design the software and so too do the architects.
Things get more complicated when people – us consultants! – start trying to change things. Maybe we say “programmers should test the code they write†but programmers say “testing is a Testers job.†Its even more difficult when you try and remove responsibility for someone: “programmers are no longer responsible for updating the system documentation.â€
This is why I despair when people tell me problems can be fixed by updating the “RACI matrix†– don’t ask me what R A C I stands for, it seems to be a tool where responsibilities are listed against roles. RACI doesn’t change identity.
But you know what? – I like the way the world is. I do not want a world were people do what is on their job description and don’t do what is not.
People who are doing what they think needs doing, and who are doing it with the aim of producing a better outcome are motivated.
People who are doing something because it is in a job description, or because they’ve been told it is now their responsibility are not so motivated. Job description documents are pretty useless.
Whether you agree with me or think that people “should†do what is in some document: simply stop expecting them to do what it says. Instead look at what they do.
Go further, if something is missing ask “Who would like to do this?â€. Work with people who are motivated by asking them what they want to do.
Few, very few, people are truly disruptive and working against you – unless of course your final outcome is something evil. Work with them.
Delete the roles and responsibilities documents.
Like this post? – Like to receive these posts by e-mail?
I hate the “building software is like building buildings†metaphor. For a start most software people know so little about physical building that they are comparing the messy world of software construction with a idealised image of what they think happens in construction.
The above is a picture from my back garden last week. Only a couple of weeks ago the back of this house looked much like the back of my house, except it had an small, ugly, 2m x 1m kitchen extension on it. And it had an over grown garden, a third of which houses this big extension while the rest of it is full of building debris.
The builders moved into this house less than six week ago. During that time they have: cleared the garden, cleared the house of remaining furniture, dug foundations, concreted foundations, built a two story side and back extension, ripped the roof off both this house and the ajoining house and replaced the roof while also constructing loft conversions on both houses. The roof came off on Monday and the new one was done by Saturday.
Builders – roofers and brick layers – go fast. Three years ago I had some work done on my house. I was well impressed with the speed the builders ripped the back rooms apart, tore down a wall, bricked up a door, and built a new wall.
Then it goes slow.
Once the actual “building†is done the wiring, plumbing, plastering, decorating and other fitting-out starts and o my, it goes so slow. Hold ups are regular as parts and people are not available when needed. There is a constantly changing cast of workers as specialists appear for a few days and then disappear.
I expect it will be four or five months before anyone is living in my neighbours house again.
During that time it goes slow, work people come in but it is hard to see progress. And the progress is far less clear than when a wall disappears, or a new wall comes into being overnight.
And so it is in software… usually.
The thing about construction – both physical and software – is that so often the most visible bits are actually among the most quickest and straight forward. These are the bits where not only can progress be made rapidly but visibly too.
But lots of time is spent on less visible bits – the tricky bits. The Devil is in the Detail as the saying goes.
When people say “How can is possibly take so long?†they are speaking from the experience of seeing the visible bits happen fast. The less visible bits, where the time is consumed, they don’t know what is happening during the less visible bits and have few memories to guide them – but they did remember it went fast last month!
When my house was being worked on I often felt like saying “why isn’t it done yet?â€. The big changes, the heavy lifting, was done. How could all this other stuff? – the minor bits, the bits which didn’t require actual building – take so long?
Fortunately, software doesn’t need to be like this. There are alternatives. But working such ways means slowing down the early stages to deal with the detail as you go. Overall you get a more consistent (and sustainable) pace, and may well finish sooner but you loose the quick start that impresses people. Almost from day-1 they start complaining about the lack of progress.
Not being a builder I don’t know, but I do know I hired experts and I have to trust them. And I never tried to say to them “If this was software you would be done by now.â€
(Now I’ve written this blog I remember, I’ve said something two years ago… Heavy Lifting is the Easy Bit. Worth saying again I think.)
Recently I’ve been looking again at Jobs to be Done and OKRs (Objectives and Key Results). I increasingly see them as story generators and a potential solution to the tyranny of the backlog I described last time.
When I first looked at Jobs to be Done (and OKRs actually) I wondered if they constituted a fourth, top, level on top of Epics, Stories and Tasks. I’ve long argued against having more than three levels of things to do (or requirements as we used to call them.) There are big meaningful things to do (stories), really big things which we don’t as yet understand but look really valuable (epics) and the immediate small things to do right now (tasks).
Actually, I’d rather think most things can be dealt with by two levels and one level is the even better. So adding a fourth “even bigger” thing on top of Epics just felt wrong. Technologists (like myself) have a tendency to map everything into hierarchies; inverted trees with fractal like branches. But not everything is, or should be, a hierarchy, mapping the world into a tree like structure can add complications.
Unlike stories (and epics and tasks) Jobs to be Done don’t really lend themselves to the transactional “Done”. While you could put a Job all the way to Done on your Kanban board and track it from “To do” to “Done” in reality the customer job still exists. Sure you’ve improved it but you can improve it again – another example of Stable Intermediate Forms. This seems to be the great potential of Jobs to be Done, they keep on giving: as much as you improve your product to help with the job you can still improve it some more.
So each time you analyse the Job to be Done you should be able to find more stories to deliver to improve it. Hence the Job to be Done is not a “story” to do, it is a Story Generator. Every time you look at the job to be done you find more stories, every time you examine the result of the latest improvement you find more stories. The job will never be done. Some might see that as a bad thing but that also means the job presents a stable focus for ongoing work.
The same might be true of OKRs but in a slightly different way. Because the objective is reviewed periodically – every quarter or so – it lacks the continuity of Jobs to be Done but perhaps allows the team to switch targets, maybe it is stable enough.
The key results may well be stories in their own right, or they may be things which lead to stories. Either way one can expect some key results to be achieved and marked as done regularly. As they fall they are either replaced by new key results building towards the objective (which themselves lead to stories) or new key results are added for new objectives.
I’m sure there are other story generators out there but the key thing for me is not the mechanism but the existence of the generator. Once you have a story generator you do not need a big backlog of things to do. The generator will replenish the backlog whenever you need more stories – either because you have done them or the value has fallen.
Using a generator removes the need to have a big backlog which removes the tyranny of the backlog. The team are now free(r) to concentrate on delivering value towards their objective.
Finally, I wonder if anyone has used both OKRs and Jobs to be Done together? Right now they feel like alternative generators to me, having both seems like a bit like overkill. Although I accept that maybe OKRs are more corporate and Jobs to be Done are more product focused. Anyone got any experience using them together?
Like this post? – Like to receive these posts by e-mail?
1.JPG){kind=link}