corporate - Allan Kelly

Story Generators

Agile, Agile Process, Business, corporate, Requirements / allan kelly / March 22, 2019 / 1 Comment

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?

Subscribe to my newsletter & receive a free eBook “Xanpan: Team Centric Agile Software Development”

Check out my latest books – Continuous Digital and Project Myopia – and now Project Myopia audio edition

Story Generators Read More »

Money talks: A tale of two change programs

Agile Process, corporate / allan kelly / November 21, 2018 / 1 Comment

Like many in the agile community – or what sometimes gets called the agile industrial complex – I am all for piecemeal adoption, small scale before large scale, get good at doing stuff then expand it out… – what else would you expect from Mr Diseconomies of Scale?

The “start small” and grow might even be regarded as the canonical approach to agile implementation. But from time to time I run across something that makes me wonder…

Four or five years back I got involved with an agile transformation programme at a large financial institution, not a bank, more of a mass market asset manager. I was attached to a small team trying to make the whole company agile.

The coaches viewed themselves as a guerrilla movement, changing the organization from within. They had some success, there was a bunch of stuff the agile teams and the coaches were doing wrong but that is another story. This was a licensed insurrection.

As is often the case, this team found it lacked the ability to ask the big questions and get people outside the team (often the higher ups) to engage or change themselves. The organization wanted agile down in the engine room – at the code face – but they didn’t want to rethink how they set requirements and approached projects. The whole organization was chronically project driven, obsessed with long term planning and offshore development. Economies of scale thinking ran riot.

Because the agile change was at the team level the product owners lacked authority to make real decisions – like not delivering functionality. Yes the organization wanted to “be agile” but the management cadre didn’t see any need to change their own behaviour.

One day I met two men who ran the company’s “Software Process Group.” They were guardians of the formal process and “working practices”. My immediate reaction was that they wanted to kill agile and stick with ISO-9000, PRINCE2, CMMI and certified approaches. They scared me. But actually they were very clued up. They got agile. They saw it was better than the current process.

These two had no role in the agile transformation, their role was to ensure the company kept its CMMI level two certification. This was really important to the company because this allowed the company to do business. They told me a story…

During the previous 20 years the company had grown large, very large, by buying up competitors and companies in related markets. These companies had been thrown together and costs stripped out. One day the financial regulator came to the company and said:

“We have been examining your IT functions. They are not fit for purpose. If you don’t fix it within 12 months we are going to withdraw your license to do business.”

Shit hitting the fan doesn’t come much bigger than this.

The company went to IBM and said “Help! – Fix it – we’ll will pay anything.”

IBM flooded the company with people. IBM imposed a process – a traditional CMMI compliant process. IBM changed the company, not just the programmers but everything. The company did as IBM told them.

And don’t imagine it was cheap. I bet that the change and IBM fees were on the agenda at every board meeting during that period. The men I had met were the remnants of that programme, they worked for the company not IBM, their job was to ensure the company maintained accreditation and the financial regulator wouldn’t have cause to come back.

Now contrast this with the piecemeal, small scale, bottom-up change that us agile folk are so fond of. Time and time again we get stuck: “the business won’t change”, “we can’t get access to the senior people”, “existing processes and expectations are unassailable”, “projects are killing us” and so on.

I’m sure IBM faced many of those same problems but they had one big advantage: They were expensive.

OK, they had a second: the loss of license would destroy the client company. But when threatened people often respond by sticking with that they know so maybe it was a double edged sword.

Because IBM were expensive they had access to anyone they wanted access too. Because they were expensive they had authority. And if someone didn’t want to make the changes IBM suggested then IBM could simply ask the next person up.

Once again money is information: by spending lots of money with IBM the company was signalling it really wanted these changes to happen.

Agile changers may not like big change, they may point to the inherent risks, they may point that use of authority conflicts with self-organization, they may understand that diseconomies of scale rule and they may point to a bunch of other risks.

But they should also note one clear advantage: a big expensive change programme brings authority all of its own.

Money talks: A tale of two change programs Read More »

Reverse-Tolstoy continued – from Agile EE

corporate / allan kelly / November 8, 2010

In my last posting I suggested thatif Leo Tolstoy worked in a corporate IT department the opening lines of Anna Korenina might have read:

“Unhappy corporate IT departments are all alike in the same unhappy way; all happy departments are happy in their own way.”

I call it Reverse-Tolstoy (because he actually wrote the reverse, well kind of). I want to continue that rant with some other ways corporate IT departments repeatedly mess up.

Belief that process change is it
I wrote in my previous entry that corporate IT departments do not focus enough on the technical side of Agile, specifically they don’t think about code quality and technical practices. Part of this is caused by a belief that process change is the change they require. That is to say, that changing the process they use, whether that means “Agile” rather than “Waterfall”, or Scrum over ISO-9000, or Kanban over ad hoc, or what ever, well, thats the change they need.

Such a view ignores the technical side of change required. As I’ve said before, and I’ll say again, I don’t believe you can be Agile if you don’t address the quality issue. I also believe that the best place to start your Agile change is with the quality improvement (thats a TQM, ISO9000 or Six Sigma quality programme by the way).

No customer involvement
For these IT departments actual, paying, customers are a long long way away. This is changing a little but most of the customer they have are internal, i.e. other parts of the business. These customers have little involvement in the development of IT system. Indeed, you will frequently be told that they want minimal involvement.

The internal customers have an image that they can hand over and idea, sign a requirements document, and leave IT to get on with it. They might get involved in some acceptance testing but they don’t want to hear about it before then.

I think this view has been encouraged by corporate IT. I think IT as an industry has trained customer very well, customer now believe if they just write it down, hand it over then it will be. Kind of double-think really because most customers have also seen IT failure. However, they think its “IT failure”. The idea that they, the “customers”, might be part of the solution is strange to them.

Instead they cling to….

“Long” UAT cycles that are separate from development
UAT, User Acceptance Test, the thing that the “business side”, the people who want the software do to ensure you deliver what they originally asked for. Having thrown it over the wall, having waited, having complained the “customer” wants make sure you deliver what they asked for. So the have a user acceptance test cycle.

Unfortunately this normally comes too late in the day to make a real difference, and, real “users” don’t actually want to be involved. So you often find UAT is carried out by dedicated UAT testers who don’t actually do the customers job.

UAT ends up being just another test cycle. All too often it is where real testing takes place, by the time the software reaches UAT it is still buggy. Rather than being about seeing if the users like the software UAT is about finding bugs.

UAT is normally one of those “no go” areas when you start talking Agile. Frankly, the business doesn’t trust IT enough to believe they will deliver anything, let alone that it is of high enough quality or actually meet customer needs.

Personally, I think you can abolish UAT, but I don’t want to try until I’ve fixed the quality problems in the team and got the basics of Agile up and running. But during this time people keep waving big red UAT flags warning you not to mess with UAT.

This is another example of….

Adherence to existing processes and constraints
All the companies have existing processes in place. Many of them are simply “off limits.” You get looked at as if you are mad when you suggest they annual planning cycles aren’t Agile, or time tracking systems are pointless.

The trouble is, too many of these “off limits” areas and you end up with no change. One big off limits process is the time tracking system….

Time tracking systems – measuring inputs not outputs
Nether mind that time tracking is an act of fantasy on a par with Arthur Conan Doyle, or that it wastes a lot of people time and even more energy one thing that is never on the agenda for change is time tracking.

All these big companies seem addicted to measuring inputs rather than outputs. They know the cost of everything and the value of nothing. Or rather, they think they know costs but really the time tracking systems are so hopelessly inaccurate they don’t reflect what is actually happening.

Time tracking gets really dirty when resources are not visible, that is, when they are offshore. Manager worry that their teams aren’t working hard enough but my experience is the teams are working to hard and just not logging all the hours – the late nights, weekends. The offshore staff thing they are “doing whats needed.” Unfortunately when this short term fix gets ingrained into regular practice its a big problem. It is also a sign, and the cause of, a lack of trust.

SWAGs “High level estimates”
Large companies like to get early “high level” estimates, sometimes called “Seriously Wild Assed Guess”. The idea is to get a ball park number for initial planning and refine it later one.

Trouble is, they don’t. The SWAG is it. It is treated as commitment and people are expected to honour it. In the worst cases the SWAGs appear to work, but thats really because the time tracking system is such a fantasy-land.

Quick Test Pro and Quality Center
All these big messed up IT departments use Quick Test Pro and Quality Center. I’ve looked at these tools, albeit a little, and my conclusion: Emperor’s New Clothes. There is nothing there.

So why so many test groups are stuck on an old version I don’t know.

Message: Save money, throw them out, get FIT, Selenium, JUnit, etc. The best things in life are free.

I look forward to the day when writing a test script in a natural language like English is a criminal offence you can be sent to jail for. If you are going to write a test script then automate it. Precise English takes just as long to write as code. (Even then it isn’t so precise.)

Not really knowing why they are doing “Agile” – seems to be the fashion of the day
At the end of the day most of these corporate IT departments don’t actually know why they are trying to be Agile. I think if they were to really think hard the answer would be Fashion. Yes it sounds good but so did Business Process Re-egineering, ISO-9000 and offshore outsourcing.

Most of the staff inside the companies regard Agile as just the latest change programme. They know it will pass in time. Yes there are some very enthusiastic people in the company, and some highly paid consultants too but that was the case with BPR, ISO-9000, and every other change initiative.

The trick is: keep you head down, look like your going along with it and wait for the next fashion to replace this one. In other words: Don’t want to rock the boat too far.

Reverse-Tolstoy continued – from Agile EE Read More »