Monday, March 20, 2017

What do you mean... Done?

The Monday status meeting is drawing a close. Doris the development manager was keen to start working through a file of resumes on her desk, Sarah the lead developer knew her pair Jo had started coding without her, Peter the product manager was on a flight to Madrid in a couple of hours, but Pat… Pat the Project Manager was a stickler for the agenda.

“And so,” concluded Doris, “the development team are now able to do weekly releases. All we are waiting on now is for Pat to tell us the customers have been informed and we will commence weekly releases - which means you can get your new features and fixes to customer even faster.”

“Actually,” Liz chipped in, “the new pipeline means we can do daily releases or even story releases. There is no need for us to batch work up into occasional releases.”

“Yes, yes, thats very good”, started Pat “however our clients have signed off on a roadmap and release plan that shows fortnightly releases, I’m negotiating with them for one week releases, some have agree. But right now we have a bigger issue to discuss…”

“Come on Pat” interrupted Peter “most of them will be only too happy to have their feature requests and fixes a bit earlier”

“Thats as maybe but there is a process we have to follow. Many of them run their own change management groups and the more frequent releases will cause them problems. In fact I know one change manager at a multinational who would rather we reverted to monthly release. But, as I was saying, there is a bigger issue we have yet to discuss.”

Doris and Liz gave each other known looks, they knew what was coming.

Pat’s face hardened, “When, ladies and gentlemen, when will we be done?”

And so an age old game commenced…

“What do you mean done exactly?” asked Doris.

“You know perfectly well what I mean by done Doris, how long have we worked together?” Pat paused. “Today is March 14, the project plan had us completing on January 31 which means we are nearly two months late. Luckily I’d built in four weeks contingency but we are now overdue and I have to raise an exception report and request an extension from the board. The first thing they will want to know is: How much longer? When will you be done?

“Hang on,” Peter was rattled, “you agreed with using the contingency, we could have called it done when we made the January 28 release but you yourself agreed that we should continue, I distinctly remember you saying you saw ‘revenue enhancing’ opportunities in the backlog and that everyone expected the contingency to be used anyway.”

“Thats as maybe Peter, but we need a line in the sand, this can’t go on forever.”

“What do you mean can’t go on for ever?” asked Liz nervously, “Do you know something we don’t?”

“Liz, I’m privy to all senior board instructions and I can assure you there are no redundancies in the pipeline”, Doris, ever the diligent manager, knew Liz was had suffered and unexpected Christmas redundancy at her last employer and there were still scars.

“Well technically Doris, the whole team will be released back to the pool at the end of this project. However I fully expect them all to be immediately assigned to the next project which starts the day after this one ends.” Pat didn’t have Doris’ knowledgeable touch. “Which leads me to ask again, when will you be done?

Liz was proud of their delivery pipeline: “If you are so keen to be done then we can be done on Thursday. The next release is scheduled for 3pm so we can call it a day then. In fact, if you want we could say we were done three days ago and start right now on the next thing.”

“Pat,” started Peter, “there are features in this project and features in the next project, its all the same product, frankly, I don’t care where you draw the line. Its all stuff to me, and the customers don’t care as long as they get their stuff.”

“Thats as may be, but we have a process to follow and its not about meeting a date its…”

“Not meeting a date? A minute ago you told us it was!” Like most of the programmers and testers Liz found Pat annoying.

“The date is important, Liz, because the later the date the greater the cost and the board have ordered us to reduce costs. When the new project starts we will have a new cost code and a new budget. So when, please, when will it be done?

Doris was about to point out that it was all the same money no matter what code it was spent under but Liz got in first.

“How much money have we left? Lets just keep coding till we run of money.”

“Liz, I repeat, we have to cut costs, that will not cut costs.”

“Then why don’t we pick up the remaining features and put them in the next project then?”

“Liz, that is amoral! That would hit the next project with scope creep before it starts, it would increase the costs and risk it not hitting its deadline.”

“But Pat, the next project can meet any deadline because it will release weekly. When we run out of time or money we just call it done. It is all a question of what Peter prioritises.”

At the mention of his name Peter felt he needed to intervene: “Pat, really, what do you mean by done? If its date then Liz is right.”

“Peter, there were certain promises made about what was to be delivered in this project.”

“Yes Pat, and we’ve met them.”

“No we haven’t.”

“Do your mean the features the McAnderson consultants put in the original BRD? The ones that never even made Should Have list, and which I dropped the day I was appointed 12 months ago?”

“No, not them, but I can quite clearly see a, what do you call it, ‘backlog’ of work to be done in the Pira tracking system.”

“Actually, Pira is out of date, we don’t keep it up to date” chirped Liz

“Well you should, its in your role and responsibility document Liz, I think it quite specifically say Team Leader should…”

“OK, OK, there is work to be done” agreed Peter, “but… it is low value work we only mark it as Must these days because Should is full of rubbish. I’m more than happy to de-scope it, there is much more valuable work right at the start of the next project.”

“I would also point out,” continued Peter, “that all the remaining backlog is work that was added after the project began, what you call scope-creep. If you just look at the work McAnderson identified - and which I didn’t remove - then we were done six months ago.”

“Peter, its not my job to decide what is in or out, that is up to you and Harry the CEO, my job is to manage getting it done. So I repeat, when will you be done?”

But Doris was on the war path: “Actually Pat, it is my job to manage the development work, and I have to ask you again what do you mean by Done?”

“You don’t mean date because you extended the date and could request an extension again. On the other hand we could be done on Thursday or last Thursday. Date is a meaningless criteria.”

“You don’t mean when will the staff be released because nobody is being fired and they are all going to work on the same code base and product, in the same office, the next day.”

“And you don’t mean scope, the ‘what are we building’, because McAnderson gave us the wrong stuff to start with, everything they asked for has either been done or cancelled. Peter is happy to move work to another project and even happier to dump stuff altogether.”

“And if, heaven forbid, we were seeking to maximise value then we would immediately jettison everything left in this project and start the next one now because all the remaining work has less value than 80% of the next project.”

“So Peter, before you ask anyone ‘when will it be done’ again, can you please explain just what you mean by ‘done’ ?”

Sometimes the obvious isn’t so obvious, readers of a similar age to myself may well remember the scene in Flash Gordon where on of the baddies says “What do you mean, Flash Gordon approaching?” What do you mean, Done?

Sunday, March 05, 2017

Whats Next? - Agile disruption

A question from a LinkedIn follower, I thought I’d share my answer with readers:

“Hey Allan,

I'm giving this a shot reaching out to you. I recently was exposed to agile in the workplace (I am in a field now that I did not study) and am learning more about the process. My company introduced it to me. I have found a couple notes pulling it back to you with your experience. My questions are:

- What do you think is next after Agile?

- Where should I start with learning about this?

And do you have any advice for me, I am just now being exposed to software/electronic development and this process and would like to be able to contribute to our company?

So first things first: great you have set about reading up on it yourself! Ultimately Agile is all about learning and taking it on yourself to learn more about it is a great first move - you will go far!

What is next after Agile? - Cynical me thinks that people who ask that question are hoping agile will go away or looking to leapfrog it to the next thing. When posed inside a company I wonder if it is a form of resistance or obfuscation. Still … I do think “what next” about myself…

At a day-to-day level the next thing is already here: Continuous Delivery, although for those of us who started with Extreme Programming (XP) this is very much “back to the future.”

What is next after Agile? - that is a question that has been asked many times in the last few years. I’ve taken a stab at it myself over the years - like my “Future of Agile” presentation from 2009. In retrospect that presentation was both right and wrong on two counts. It was right because it has become clearer and clear over the years that Agile is Lean, Agile Software Development was our Lean revolution. Over time Agile has absorbed more and more Lean ideas.

The presentation was wrong on the first count because Lean has not, and I think will not, displace Agile. The Kanban insurrection has done a great in breaking the Scrum hegemony but Agile is here to stay - albeit infused with more and more Lean. (Take my own Xanpan for example.)

More significantly I was wrong because the thing that comes after Agile is not a replacement for Agile, rather it builds on Agile, Agile is building block - or as I put it a couple of weeks ago, Agile was the midwife.

Consider Toyota, they have been “lean” for decades, what came after “lean” for Toyota? It isn’t “Lean 2.0” or “Super Lean.” Lean enables them to do things like the Prius. Lean allows Toyota to pursue their strategy, Lean allows Toyota to produce almost as many cars as VW with half the workers.

Increasingly I don’t even think Agile has even replaced “waterfall” (aka “traditional”) software development. Big corporations still largely practise a form of waterfall with an Agile vinaigrette dressing. I don’t like it, it drives me nuts but fundamentally the vast majority of large corporations that exist today are incapable of pure Agile because they have been built for a different world.

That doesn’t mean they can’t borrow some things form Agile, it doesn’t mean Agile techniques can’t help them be better than they are but it does mean they will never truly be Agile - but then, it is wrong to say every company must be truly Agile, or be truly Agile in the same way. (For those Agile folk who can stand the madness there is good money in selling unsafe fast cars to the middle aged.)

But what does this mean for the future?

Well… traditional incumbents are increasingly vulnerable from Agile disruptors - companies which challenge them with new products and services which are only possible when technology is build in an agile fashion.

And that is what comes next: Agile Disruption.

Only we don’t call it Agile Disruption, its called Digital.

This is happening now… our technologies are making all sorts of new business opportunities possible but exploiting those opportunities are only available to the Agile company.

Only with an Agile process can firms truly harness the power of modern tools like Amazon Web Services, Ruby and Clojure, etc. etc. Processes designed in 1970 are a poor fit for 2016 tools and technologies. Its a bit like an airline using the operating processes it had for DC-3s when introduced Boeing 777s.

As computers get more powerful the opportunities they can address are greater, if a company can turn that opportunities into money they have a business. To understand this you have to consider Moore’s Law: Computing power doubles every two years.

The computers of today can address problems twice as complex as those two years ago.

The computers of today can address problems four times more complex than four years ago, eight times more complex than six years ago and 16 times more complex than eight years ago.

To put it another way, the next increment of Moore’s Law will increase computer power by more than all the previous increments added together.

You get the picture?

I was recently inside a large bank. It takes them over a year to get a new idea into production. If I recall correctly, 27 months is more normal, that is over two years. In other words, processing power has doubled in the time it takes the bank to get out of bed.

So Agile isn’t going away but the focus will be elsewhere. This is playing out in a number of ways.

Right now being Agile is table stakes. Continuous delivery is cutting edge but will soon be the minimum required. (If you are competing with Amazon it already is, if you aren’t competing with Amazon today just hope they aren’t eyeing your market.)

The discussion of “digital business” is the obvious one. Another is the rise of the #NoProjects/#ProjectLess movement I’m closely associated with. Underpinning both of those is continuous delivery.

Which means, if you want know more about what happens next:

  • Start keeping your eyes open for anything to do with digital business - most of it is rubbish but among the noise there is some good thinking
  • Read #NoProjects/#ProjectsLess
  • Learn about Continuous Delivery

A word warning here: I’m guessing you work in more traditional company. As you open your mind to all of this you are likely to make yourself unpopular with your colleagues as you try to implement these ideas and warn them. Unfortunately most existing companies have a Mayor of Rotterdam problem.

And naturally, keep reading my blog!