Agile

Some years ago when I was doing my masters degree I was shown a video called “Stockless Production” which was filmed at HP in the early 1980s. It was a brilliant illustration of Kanban, or Just In Time, or, as they liked to call it Stockless Production.

Its brilliant, the video quality is poor and the sound is even worse!

I few years later I found the video on the internet – it can be hard to track down. Although some experts exist elsewhere on YouTube I’ve never seen the whole thing there.

I often show the video as part of my work coaching and training teams. I use it either as part of a Kanban introduction or for teams already doing Agile a la Scrum to help them think about flow and quality.

Last year I paid to have subtitles added to the video. I’ve uploaded it to YouTube and in the hope that many more people can enjoy the film, have a little laugh and learn.

Many thanks to Brian Barnes at Osmium films for help with the subtitles.

A word on copyright: I’ve not made this available before because I have no idea about copyright. You can tell from the fashion (and lack of women managers) that this is at least 1981 and it is even conceivable its out of copyright.

I have made efforts to track the copyright down and failed. I believe that at some point the video – and copyright I guess – was passed from HP to Motorola University. I read somewhere that the video actually had an HP or Motorola part number. Given that the HP of this video no longer exists (it has split twice, first HP and Agilent, then HP into Hewlett Packard Enterprise and HP Inc.) and that Motorola no longer exists (and that it also split multiple times).

Phewww… Agile on the Beach isn’t for another 3 months but in one way its just ended for me. So it is a good time to share a few notes, specifically about speaker selection.

Background

My role in Agile on the Beach centres on the speakers. In the early days I hand picked the line-up but for the last 4 (or maybe 5) years we’ve run an open call for papers. I write the CfP, I run the CfP process, I talent spot (and encourage submissions), I respond to (potential) speaker queries, I run the review processes.

This year the CfP opened at the star of December and earlier this month we published the full line-up, so the majority of my work for the conference fell in that period. The majority of this blog will focus on our selection procedure and provide additional feedback for those who submitted.

Those of you who are thinking of attending AOTB 2017 will also get an insight into what happens behind the scenes. And anyone – all of you I hope! – who are thinking of submitting to a future Agile on the Beach or any other conference may well learn something useful.

Everyone who submitted should have notification by now – accept or decline, please let me know if you don’t. For those we didn’t accept I’ll shortly send an e-mail with more information on how your submission faired.

It helps to understand the AOTB review and voting procedure (a blog from couple of years back). This year I widened the scoring system from -2 to +2 to -3 to +3 in an effort to spread out the scores bit, I’m not sure it helped through.

Another change was the addition of four new reviewers who are not on the conference committee. This removed some of the workload from the committee and, I think, made for better reviews. It also meant that no submission had fewer than 4 reviews and some as many as 7.

The big public change to Agile on the Beach 2017 is a move from September to July – a move forced on us by changed in the academic calendar at Falmouth University. But behind the scenes our organization changes have been even bigger – partly because we had 3 months less to organise 2017.

One big change is Mimas – more information on my Conference Review mini-site.

After several years of an ad hoc system of managing reviews I bit the bullet last summer and created our own conference submission and review system. I’ll blog more about this soon but right now let me say, like every other software development it seemed to take longer than expected!

However it has massively simplified things. I think next year, with the system in place and far less work needed, my life will be better. But, it has been work – and I’m so glad I did it test first!

Anyway, what can I tell you about the submissions themselves and the reviews….

About the submissions and reviews

There were over 320 submissions from over 220 potential speakers. With so many submissions I’m worried that we will loose out on fresh voices, I’m also worried some of the true experts will be deterred from submitting.

For each track round 1 reviews reduced this to a shortlist. For each track we decided a cut-off score, submissions which scored above this were on the shortlist and those below marked for decline.

We then did a double check, there were several sessions below the cut-off which held promise – e.g. interesting speaker or a novel topic – which we added to the short list. We specifically looked at all the submissions which didn’t make the cut-off but had been given a 3 score (the highest possible) by at least one reviewer. Most of these were then included on the shortlist as well.

And one or two, certainly no more, which were removed from the shortlist.

We also moved a few sessions between tracks in both rounds when we thought they were better in another track. But, with so many submissions we rely on those submitting to make intelligent choices on which track is most appropriate.

For 2017 the track shortlist cut-off score was:

• Agile Business, 60 submissions, 9 speaking slow, shortlist threshold score: 8
• Agile Practices, 57 submissions, 4 single slots available, shortlist threshold: 8
• Product Design, 22 submissions, 4 single slots available, shortlist threshold: 7
• Product Management, 38 submissions, 5 single slots available, shortlist threshold: 6
• Team work, 83 submissions, 5 single slots available, shortlist threshold: 7
• Software Delivery, 54 submissions, 9 single slots available, shortlist threshold: 9

(When a double is chosen then two single slots are combined.)

I was particularly happy to see more submissions in the Software Delivery track this year.

We had lots of very strong submissions from very strong, experienced, speakers. There are a few names we’ve declined this year who I find it hard to believe we said no: Judith, Karl and Steve spring to mind.

We also had quite a few weak submissions were the potential speaker only gave a few words of synopsis and biography – some even left the bio blank. I marked a lot of submissions down because the synopsis and/or bio did’t really say much. Some of these weren’t much more than a title and a list of bullet points.

Now quantity shouldn’t be a substitute for quality, less is more and so on, but… in a number of cases there wasn’t enough information to make a judgement so the submission was marked down. It also puts a question in my mind as to how interested the speaker is: I’m probably investing more time in reading and thinking about the proposal than they put into writing it.

If you want to speak the competition is fierce. You need to put really effort and thought into you submission.

Of course some synopsis go the other way and are too long, you bore before you get to the end. Similarly for biographies, not too much but not too little either.

Some synopsis spend all their time talking about the problem they will examine and said very little about the solution. Others seem to jump into solution without saying why – that is particularly true of talks which involve a brand-name tool or technique. (Sessions dealing with specific tools, especially commercial tools, are seldom scored highly by AOTB reviewers.)

There is an art to writing a synopsis: describe the problem (not in too much detail) and say something about the solution (without giving it all away), while at the same time being engaging and leaving the reader wanting to know more.

A few speakers – all from the USA interestingly – didn’t seem to read the call for papers. They requested speaking fees and/or proposed sessions which didn’t match our topic areas. I wonder if some people just fire off submissions to every conference?

To be clear: we don’t pay speakers.

We do sometimes give keynotes honorariums but we choose the keynotes, we don’t ask for keynotes in the open submission system. Normally we have already agreed our keynotes before the we call for speakers.

(If you know of someone you think would be a good keynote for AOTB please drop me a mail.)

As always those who requested long-haul airfare tended to get marked down. We don’t set a budget for speakers but we do keep an eye on costs, we have paid long-haul fares on occasions in the past but we can’t afford to pay many. This year both our keynotes are long-haul.

I can’t see any way around this. Its unfair but is a genuine constraint.

This year we did offer speakers the option of paying their own long-haul airfare and we would pay in country travel costs.

And similarly double sessions tended to get marked down. Again unfair but hard to avoid. We are aware of this problem and we do create some doubles space (the bonus track) but it is still a trade-off.

This year we seemed to have a lot of talks about “mechanical scrum” and “failing Agile”. Maybe this is a sign that Agile has come of age. These sessions didn’t score highly largely because they spent most of the synopsis setting out the problem rather than discussing solutions.

Failing Agile is well… a fact of life. It is only interesting when we can learn something from it – something not to do, or something to do differently, something to prevent or rectify the failure.

What will I want to do differently next year?

• I hope to add a few more independent reviewers.
• I’m thinking of designating track leads for reviews, these will weed out the clearly unsuitable submissions and help with the shortlisting.
• Mimas will have a few tweaks but for AOTB it is essentially done.

So advice for those anyone thinking of submitting in future:

• Read our Call for Papers: yes, I know it is long but we give a lot of information
• Choose your track carefully: your changes of selection are much better if you submit into one of the more specific tracks (Software Delivery, Product Design and Product Management) rather than the three more general tracks (Business, Practices, and Teams.)
• Put some effort into the synopsis, especially the short synopsis, tell us a bit about the problem but not too much, and tell us something about what you are going to say. The long synopsis isn’t as important but is useful for giving more detail.
• Don’t take “long” synopsis as literally, it does not need to be very long. If you have a strong short synopsis then just leave long blank.
• Watch your timings: some speakers gave detailed timing breakdowns (to the minute), on the whole these aren’t believable and people got marked down. However some speakers were just too ambitious in their contend and reviewers didn’t believe they could cover it all.
• Double sessions really need to be outstanding, and they need to be interactive. No lecture based double has ever been selected.

I hope some of that is helpful to at least some of you.

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?

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!

The other day I was at an event for start-ups and entrepreneurs – no, not the “Agile for Startups” event I’m speaking at in a couple of weeks, for once I was in the audience. Half way through the organisers decided to do a type of speed networking – so we could get to know each other, find employees, find clients, find investors, whatever.

One of the people I got to spend a few minutes with was an entrepreneur on the hunt for a CTO. As I often, usually (always!) find at these sort of events, there are far more potential non-coding entrepreneurs than there are “techies” to go around. Such events seem to be populated by non-techies hunting techies.

As soon as she heard I code she saw an opportunity… and she blew it. So for the benefit of other entrepreneurs hunting techies…

What she said was:

“Our product is 80% built, we had an intern last year and now we need someone to finish it.”

I also ascertained that: the start up was her and her business partner and as yet they had no customers. So I could also deduce that they had not validated the product Lean-Startup style, they had built and now were looking to “finish” it and find customers. So their start-up strategy already posed question.

When I asked “what is the technology stack?” she didn’t get the question at first asking and then said “I don’t know, its not my area.”

So whats’s wrong here?

“80% built”

That shows how little they understand about IT products, it ain’t never finished. Once you start using it people want changes, people see opportunities, digital business models depend finding new ways of using technology to create value.

If it was “finished” then… where is your business? – in a digital business the product is never finished.

Any CTO they hire is going to spend most of their time educating the founders – probably why they need a CTO in the first place!

But think for a moment, what if she is right? What if it is 80% done? Then the remaining 20% does not represent a lot of work for the new techie/CTO to do.

“an intern”

OK, there are some students who are awesome coders. Some of them are wasting their time at University, they should just go and earn big money. I was probably one of these people, I went to University and my degree has helped me later in life but…

The chances are this intern is better than average 20-something coder who has left behind a big mess – without unit tests. The CTO they hire is going to spend the next few years cleaning up that mess.

Lets put this together:

• This is has not been validated in the market so it is a technology play
• The founders not only lack technology skills but lack an understanding of technology business
• A technology play by non-technical entrepreneurs just sounds like trouble

What lessons can we draw form this?

1. Firstly don’t confuse wanting a CTO with wanting a programmer. I think this lady and her partner do need a CTO and they do need a programmer, they may even be the same person – and I certainly hope any CTO remembers how to code. But… in trying to sell the role to me she was very confused.

2. They do need a CTO because this is a technology play. But I don’t think they see that, they see the need for a coder. They need to think more clearly.

3. She needs to recognise that “80% completed by an intern” is not a good sales pitch to any programmer (let alone CTO) worth their salt. It plays down both the amount of work to do, the challenge and promises a big mess to clean up.

4. Not knowing the technology stack is criminal: it is the most basic question any techie is going to want to know – a PHP Lamp stack is completely different to a Java AWS stack – and it is the most basic filter when recruiting technical staff. True it is not so important if you are hiring a CTO for a company with 50 developers but in a small startup the technology and business strategy are intimately connected.

Finally, yes, I could be tempted by the right opportunity to be a CTO – even a coding CTO – maybe one day…

Let me give you the punch-line and then explain myself:

As soon as testing starts every “project” becomes a test driven.

If there is no formal testing period then that phase begin the moment customers/users start using the product.

I’ve recently been watching a slow motion train-crash, I had no power to avert the train crash and those I could alert didn’t want to hear me. So I was thinking: what will happen in the end?

The project has been forced on the organization by external authorities. Even if it wasn’t the budget allocated means it is too big to fail, it will take careers with it so it must succeed. It will be an exercise in pass the parcel with everyone attempting to show they did what was expected to avoid blame.

Anyway… in the end, I thought, they will enter a testing phase, as with all testing phases it won’t be just a test phase it will be a test-fix-test-fix until such time as the organization runs out of the will to continue. Just like every traditional project.

Which, when you think about it, means that when this project enters testing it will become Test Driven.

Sure the project will spend months “designing” and “implementing” but the project is so big nobody can understand it. Only when the parts are brought together, and the deadline is close, will people do what it required.

At that point they will be test driven.

Up onto that point all the planning, designing, implementing and what not is just shadow play, people avoiding doing what is needed.

This argument can be extended to every traditional project where testing is left to the end.

Between the start of work and the start of testing work might be done but how much of this is usable, how much of this is finally included in the solution is anyones guess. Once testing all work is test driven.

All software development is test driven, in the end.

I’m the stupid one.

For years now I’ve heard people talk about “digital” but I failed to grasp the significance.

It started with “digital agencies” which I took to be advertising agencies which did websites, although the websites they were trying to build contained a lot of functionality. These odd advertising agencies seemed to offering services more akin to Logica than Stirling Cooper.

I ignored the digital label, after all I reasoned: everything in IT, in software development is digital – analogue computers never really took off. “These fools” I thought, “are stating the bleedin’ obvious.” Digital was a label attached almost without meaning. Or so I thought.

Perhaps on one level “digital” is a marketing term, and perhaps because of that it holds little meaning. But, it is a term that people identify with, and because people identify with “digital” it has meaning.

Slowly, over the course of the last year, its dawned on me that I was the foolish one. The label digital isn’t attached without meaning. Adding digital means those who use the label have come to my world.

My world always was digital but the rest of the world wasn’t. Now they are.

For years I, and others, have been arguing that software has the capacity to completely rewrite the business world. “Software is eating the world” as Marc Andreessen said. I’ve been saying: “Every company is a software company” for years but I just discovered that Forbes magazine said it too!

I’ve been making this argument but I don’t need to, everyone else has worked it out. It is only IT folk like me who are slow on realising that everyone else wants to be in their world.

And Agile? – do we need Digital Agile?

In the new digital world Agile just is. Agile is tablestakes, don’t bother trying to play in the new digital world if you don’t at least aspire to Agile.

None of these digital-whatevers would try and be anything other than Agile.

True they may do Agile badly, true they may have vestigial waterfall thinking, they may find it difficult to break away from the traditional supplier model and even undertake projects but in the digital world nothing else works.

Many of digital-somethings out there are there to disrupt the incumbents. The incumbents may be adopting elements Agile and Digital but they have non-trivial legacy problems: legacy process, technical legacy (with technical liabilities), legacy mindsets and people who understand success in the legacy world not in the new agile and digital world.

Agile was the midwife at the birth of Digital.

In the days when IT folks clung to the idea that everything could be known in advance, and written down – in cryptic language nobody reads – and change actively resisted, then creating software technology was the preserve of high priests. By democratizing the process Agile has allowed more people to engage with the technology.

Agile and Digital, maybe not strawberries and cream, more like self-raising flour and sponge cake. Agile allows everyone to have a go, and everyone has a chance of winning!

This piece first appeared in my newsletter last month. Subscription is free from the Software Strategy website.

​From time to time questions show up in my mailbox from people asking questions. I like to post the questions and answers here in the hope that others might benefit. I’ve done this a few times before (“Agile Clinic: problem with our agile…”)

I’m always glad to help but it can be hard to find time, plus, not everyone wants to talk about this in public. So, before I jump into this clinic Q&A, I should mention that members of part of Alex Pappworth’s “Be a Brilliant Business Analyst” group can now book one-on-one online consultations with me.

Anyway, to today’s question….

“[We are a Drupal based software development organization in India. It is 150 member team with representations in South East Asia and the US. We have 2 Agile coaches in the organization who are stretched in time managing different projects.”

Hardly surprising, 150 people, multiple projects, multiple locations. I don’t know what the “right” ratio of coaches to teams/people – there probably isn’t one single answer, not least because it will depend a lot on the maturity of the teams, i.e., established teams will need less help than new teams but all teams should have a coach to call on.

“We are looking at restructuring our organization so that these coaches can be supported for project delivery. As of now the Agile coaches have 3 primary responsibilities – 1)project delivery 2) Agile process coaching and 3) people management. Of these 3, project delivery and people management is the most time consuming and exhaustive.”

This is worrying. To my mind Agile coaches should be spending most of their time on process coaching and helping people – not helping with their work, helping them improve, maybe one-on-one coaching or maybe team coaching. I wouldn’t call “helping people” people management, that sounds like line-management or traditional project management.

So first off: get some project managers.

Regular readers will probably be surprised to hear me say that, and I am a little but there are times when a project manager is the right solution. One example, as in this case, when there is a client-supplier relationship and expected deliverables within a project model.

Yes, I question whether the project model is the best model to be using, and I’ll even question whether this company really does projects, but based on this information they do, they should have project managers.

Once you have project managers then the coaches can work with the project managers to improve team performance.

“We have contemplated separating the people management piece by placing a Delivery manager between a coach and scrum master.”

Scrum Masters too? Can’t they pick up some of the project delivery work in the absence of project managers?

One problem with “Delivery manager” is that the role is not well defined or even understood. It is a new role and one which is still emerging. We will probably never have a universal standard delivery manager role but right now it is ill defined.

If you were to add a Delivery Manager I think they would end up becoming a type of Project Manager. In which case we’ve both identified a missing role in your organization, the question is: who are the right people to fill it? Whether you call them project or delivery managers there it seems there is a missing role here.

Line management is a more difficult problem. Here we really have an evolving field.

So far I’ve not heard of any good solutions to “Who is the line manager?”

• Project Managers aren’t line managers because they lack the skills, plus projects are temporary and you want some continuity here.
• Scrum Masters and Coaches aren’t line managers because the type of coaching they (should) use shuns authority.
• Delivery managers…. well if I ever find out what a Deliver Manager does I’ll let you know.

Since Agile as a whole aims for self-organization the issue of line management, and there in some authority, has received little attention. Arguably you should drop the role all together but that is quite radical.

One solution I’ve heard is to make one manager responsible for all line management. At the same time moving towards greater self-organization reduces the need for line management.

“In the existing system scrum masters do not have the maturity or the experience of people management. Since we are still trying to figure our way out keeping in mind that we don’t increase our overheads I have the following questions to ask of you-“

Good call, if the people don’t have the maturity yet don’t make them line managers. And as I said, Scrum Masters probably shouldn’t have that role anyway.

“a) Is an Agile coach expected to do all 3. i.e delivery management of projects, people development(career progression, feedback in retros, conflict mgt) and Agile process coaching ( tech forums, building an Agile culture etc)?”

Well… that all depends how you define the Agile Coach role. I’d ask the coaches to sit down together and draw up a list of things they think they should do, and a list of things they do not to. Similarly I’d do this with the Scrum Masters.

As I’ve said, in my view, most of the time coaches should not be managing the delivery of projects or people development (line management). They will run some retrospective and feedback sessions, although I’d expect the Scrum Masters to take on most of this. And I would expect them to work on process, culture, etc.

(This old post might be useful What does an Agile coach do?).

“b) Given our geographical spread should we be hiring more Agile coaches?”

Yes, at least one per location.

Even if you don’t have developers in one location you will have some people – analysts? sales? – who would benefit from better understanding of the new way of working. And in a location with multiple teams you probably need multiple coaches, but not necessarily 1-to-1, as the teams have Scrum Masters, and some new managers of some sort, the coaches should focus their attention supporting these roles and the teams.

“c) If we were to get a delivery manager in between a SM and Agile coach, people management should be whose responsibility? (We are facing a huge challenge in finding the ideal combination of tech skills and people leaders)”

I don’t think so, this isn’t a hierarchy or chain-of-command. Project/Delivery Managers and Coaches are peers, they each have a different focus but have overlapping responsibilities. On any one team the Scrum Master and Project/Delivery Manager will need to decide between them they work together and which responsibilities they pick up.

Agile Coaches don’t have any additional authority however they are not under taking the day-to-day work, their job is different again.

Right now I think you need to untangle the Agile Coach role first, give it a few months and revisit these questions.

Can’t say I’m surprised you are finding it hard to get the right combination of tech skills and people leaders. Such people are few and far between, sometimes it seems the two are mutually exclusive. Could you work with the existing tech leaders to improve their people skills? – training, coaching, etc.?

“d) Would it be a better idea to identify SMs with potential to be groomed into people managers and move them to a delivery manager role? My concern is that an Agile coach should not be stepping on the toes of a delivery manager.”

Certainly you could help the Scrum Masters grow in that direction. Whether they stay Scrum Masters or become something else I don’t know. And since you don’t have any delivery managers (yet) you talk that through when you are recruiting people (i.e. don’t hire people who have strong beliefs on this!)

(And, by the way, avoid the word “grooming”, in English English it has a very specific, very negative, meaning these days.)

Pheww…

In summary:

• More Agile coaches

• Have the coaches define their responsibilities

• Educate and grow the Scrum Masters

• Add a new role: perhaps experiment with one or two hires at first

I hope that helps.

This isn’t a happy story, it has no happy ending, I suffered personally, its personal but I want to share.

Its about trying to solve a problem with the fashionable solution rather than rolling back the last fashionable solution you applied which created the problem to start with…

A long time ago, well, the best part of 10 years ago, in a town far far away (actually the other side of London) I went to help a small part of a very large company “become agile”.

The managers wanted to be “agile” and insisted they knew what it meant and what the implications were. So my job was merely to help the change resistant workers change.

Now this company, like so many others, had decided that coding was expensive and should be done in a far away place, and this time I do really mean far away, far enough away to be cheaper.

The system in question was big, and old, over 20 years old, and millions of lines of Cobol. Fortunately the company still employed most of the people who had built the system over 20 years. Unfortunately they were to forbidden to code. They were too expensive for that. So the far away cheap people coded. I forget the job title the old coders were given, maybe it was SME but I thought of them as Architects – although Systems Analyst might have been a better title.

The far away coders, employed by a “partner” (outsourcer) were young, they lack programming experience. I suspect they had learned Java at college and been given a Cobol boot camp when they joined the partner. From what I could tell they were quite capable of making a code change at the function level but… anything involving system structure, multiple functions or some of the larger (too big) functions required help.

They needed to talk to the architects.

To avoid this the big company had the architects write “design” documents. But still the coders needed regular conference calls.

These coders also had a habit of changing, after 18 months on the contract the outsourcer moved them on. But then, many of them didn’t last that long; many left of their own accord before then. Consequently, just as one of the coders got to the point off properly understanding Cobol and the system they were gone.

To make sure the right work was done the big company had Business Analysts detail the need in big documents. Lots more to read.

Of course all this required a lot of testing for the partner, plus another partner (in a third location), and internal “user acceptance testing” (in a fourth location.) Implicitly the process and managers accepted lots of failure and expected testing to generate a lot of (re)work.

Now something else happens when you use an outsourcer and so many people: you need more management, at both the client and supplier.

All this complexity (not to mention cost) piled up and made them unresponsive. Hence they wanted to be Agile! That’s why I was there.

Every so often one of the projects would get into a real mess and the architects would be allow to take over and code. When this happened it was completed in a few weeks.

Most of the offshore efforts took months.

Yes the company was saving money on programmers but…

• They were spending more on business analysts and architects
• They were spending a lot on test
• They were spending a fortune on managing

But most of all they were paying in late deliveries, new products not in the market, delayed cost reduction initiatives and so on. Plus they were pained by poor completing date forecasts.

And it was getting worse.

So of course Agile was the answer.

But the problem the company faced wasn’t one Agile sets out to solve. The problem was one of knowledge: the company had the knowledge but wasn’t using it effectively. While they didn’t use the knowledge they were losing the knowledge. Knowledge couldn’t just be moved from the heads of people in London to the heads of people in a far away place.

The company ignored knowledge, or at least thought it could be written down. They saw the problem as expensive typists.

And me?

I diagnosed the problem as managers failing to understand, hence I wanted to spend time talking to managers. But they said they already understood and Agile was the answer so my wanted to talk to them was not what they wanted.

I crashed and burned.