Agile Process - Allan Kelly

The Agile virus

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.

Perhaps thats not so odd after all. Fighting infection is one of the ways bodies grow stronger. And some virus have positive effects – Friendly Viruses Protect Us Against Bacteria (Science Magazine),
‘Good viruses’ defend gut when bacteria are wiped out (New Scientist), 10 Viruses That Actually Help Humankind (ListVerse), and virus play a roll in evolution by removing the weaker of the species.

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?

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 the Project Myopia audio edition

The Agile virus Read More »

Agile is a Crunchy Nut Frog (and some dirty secrets)

800px-Argentine_Horned_Frog_Ceratophrys_ornata1-2019-06-6-15-26.jpg

Remember the Monty Python Crunchy Nut Frog sketch? – especially the final section..

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.

True, I make a point of being a contrarian – go read my old Heresy: My warped, crazy, wrong version of Agile.

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 sure 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?

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 the Project Myopia audio edition

Agile is a Crunchy Nut Frog (and some dirty secrets) Read More »

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 »

The power of small declines

Agile Process / allan kelly / December 13, 2018

Last year I wrote about the power of 1% improvement, and how powerful this can be when that improvement occurs frequently. For example, if a team improves 1% a week then over the course of 50 weeks (a year) they would improve by over 62%.

A few days ago I had a revelation: the opposite is also true.

If a team enters a downward spiral then a 1% decline in productivity each week has similar effects but in the opposite direction. In fact, as I think about this I see more and more occasions where a team can loose small amounts of performance which actually saps their productive capacity. Like the frog in hot water they don’t realise they are cooked until it is too late.

The graph above shows what happens to value-add over a year when a team is 1% less productive each week. The blue bars show how value-add falls each week. The red line shows how each week the team declines slightly compared to the week before.

That the red line get higher seems odd but it makes sense: each week the team is 1% less productive than the week before. So at the end of the second week the team is 1% less productive than they were in the first week. At the end of week 50 they are 1% less productive than week 49 but only 0.62% more less productive than week 1 because the 1% decline was from a lower total. Getting worse slows down because the team are worse!

At some point the value-add ceases to justify the cost of the team. But as these changes are very gradual that is going to be hard to see.

Why might this happen? – lots of reasons

First off there are the corporate drains on productivity. Consider corporate security processes: think about passwords alone, the need to change passwords regularly, have longer and longer passwords, have different passwords on different systems, and so on. Sure cyber security is important but it can also be a drain on productivity.

Then there are the other hassles of working almost anywhere: finding meeting rooms, booking meeting rooms, setting up webex conference calls, “cake in the kitchen”, restrictions on internet use – whether it is limited access, site blacklists, or authorised “white list” sites only.

It is easy to see how a large corporate can gradually drain a team. But there are other reasons.

There are personal drains on productivity too. Consider internet use during work time. The likes of Facebook, LinkedIn and Twitter which aim to keep you on their sites as long as possible. Using LinkedIn is almost a necessity in modern work – got a meeting coming up? someone applied for a job? looking for a lead? – but once your in, Microsoft wants to keep you there.

Then think about your code base: is the code getting better or worse?

Easier to work with or harder to work with?
Do you write an automated test for every change? Or save time today at the cost of time tomorrow, and the next day, and the day after, and …
Do you take time to refactor every time you make a change? or are you constantly kludging it and making the next change slightly harder?

Notice here I’m not talking about those big time consuming changes that happen occasionally: new employees, reorganisations, mergers – things that happen occasionally, take a chunk of time but finish.

So, is your work environment getting a little bit better every week? or a little bit harder?

If we think at the “very little” level it is unlikely that things are the same as last week. Staying the same will be hard. Things are probably a little bit better or a little bit harder. Extend that over a year and – as the theory of 1% change shows – things are a lot worse, or maybe a lot better.

What is important is the trend, and the trend is going to be set by the culture. Do you have a culture of small improvements? Or an acceptance of small degradation?

Finally, because there are so many minor factors that can sap your productivity capacity then it is quite likely that if you aren’t getting more productive then you are getting less. In other words, you need to be working to improve just to stand still.

The power of small declines 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 »

Agile won the war but lost the peace

Agile, Agile Process, Business / allan kelly / November 8, 2018 / 15 Comments

“I’ve spoken of the shining city all my political life, … in my mind it was a tall, proud city built on rocks stronger than oceans, wind-swept, God-blessed, and teeming with people of all kinds living in harmony and peace; a city with free ports that hummed with commerce and creativity. And if there had to be city walls, the walls had doors and the doors were open to anyone with the will and the heart to get here. That’s how I saw it, and see it still” President Ronald Reagan, Farewell to the Nation, January 11, 1989

Back in 2001 when the word agile appeared it was a manifesto – a set of ideas, the term “agile” also served to group a bunch of tools and techniques which could make software development “better.” More importantly to my mind, it painted a picture of a shining city on a hill we all wanted to live in.

Agile was a place you wanted to go, it was a journey you wanted to make, it offered hope. More important as the tools – sprints, stand-ups, etc. – and approaches – just in time, last responsible moment, test first – were the stories agile people – including myself – told. These were stories of a better world, of that shining city on the hill.

And not unimportantly, in a world of search engines “agile” gave you something to search for. Before agile you could search “make my software development team better” or “software development process improvement” but what you got was a very mixed offering. AltaVista (and the young Google) would suggest links for CMMI, or ISO-9000, or vendor tools to “fix it”, or proper design, or… there was no coherent message. Most of these ideas resolved around senior people making big decisions and then imposing them.

Then along came agile: it offered to involve everyone, everyone made decisions, everyone was happy and we could all go to that shining city on a hill – more than that, we all had an important part to play in building that city.

Today everyone is agile. Nobody is promoting traditional (“waterfall”) working, CMMI, PMI and everyone else has incorporated agile (to some degree). Not being agile is about as popular as leprosy.

But very few of us have reached the shining city on the hill.

Along the way agile has been watered down, in becoming compatible with everything else it is less different, it is less attractive, fewer workers are motivated to take the journey. And as “the powers that be” have found ways to bring control-and-command back to teams (maybe in the name of scaling) fewer people are invited to help build the city.

Ironically, as we (the agile community) has made agile management friendly we have made it less worker friendly. Today senior managers “get agile” and want their organisations to be agile. But those at the code face seem to have less and less motivation. And those in the middle… sometimes they seem to want to change just enough to declare success but no so much that things really change.

For some people agile has become completely discredited – I wrote Why do Dev’s hate agile? last year and I’m presenting it in London next week. Agile isn’t a shining city on a hill, agile is trench warfare.

And Googling “agile” presents a long long list of links with less and less coherence.

Agile won the war. Agile is respectable and everyone is agile now. Big business rush to be agile, Governments want to be agile, blue-chip consultancies will sell you agile.

But agile lost the peace.

While many say they are agile, few software developers live in a shiny city. The place they live in might be better than the place they came from but it doesn’t live up to the dream many of us shared 15 years ago. Agile has become an excuse for failure and a thing to be imposed.

The thing that passes for “agile” today is too often a watered down version of the original dream. Worse still, we don’t have a word to describe that shining city we all want to get to. Russians have an expression for this:

“We wanted the best, it turned out like always.” Viktor Stepanovich Chernomyrdin, Prime Minister Russia, 1998-1999

Me? – I still dream of that shining city on the hill, I still believe agile is the right way to get there, I still wave the flag for agile but more and more I feel the need to explain myself and tell people that the agile I dream of is not the agile they may experience.

Receive these posts by e-mail?

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

Agile won the war but lost the peace Read More »

More Continuous #NoProjects questions

Agile, Agile Process, Continuous / allan kelly / October 24, 2018

Three short questions and answers to finish off my series of left over questions about #NoProjects, #NoEstimates and the Continuous model.

Q4: How do we prioritize and organize requests on a product that are from opposite business owners? – for example legal (who wants to reduce the risk and annoy more customers) and sales (who want to increase the features and simplify life) can be arbitrated in a backlog?

You can think of this as “which is worth more apples or milk?” It is difficult to compare two things which are actually different. Yes they are both work requests – or fruit – and each can make a case but at the end of the day you can’t make everything number 1 priority.

In real life we solve this problem with money.

Walk into your local supermarket. Apples, oranges and milk are both price in the same currency, sterling for me, Francs for the person who asked this question, maybe Euro’s or Dollars for you. So if we can assign value points to each request we are half way to solving the problem.

Now sales will argue that without their request there is no real money so whatever they ask for is worth more. And legal will argue that nobody wants to go to jail so their request must be worth more. You can set your analyst to work to calculate a value but a) this will take time and b) even when they have an answer people will dispute it.

Therefore, I would estimate a value – planning poker style. With an estimates value there is no pretence of “right” or “correct”. Each party gives a position and a discussion follows. With luck the different sides converge, if they don’t then I average. Once all requests are valued you have a first cut at prioritisation.

Q5: How to evaluate the number of people you need to maintain software?

I don’t. This is a strategic decision.

Sure someone somewhere needs to decide how much capacity – often expressed as people – will be allocated to a particular activity but rather than base this on need I see this as another priority decision. If a piece of software is important to an organization then it deserves more maintenance, and if it is not important it deserves less.

You could look at the size of the backlog, or the rate of new requests and contrast this with the rate at which work gets done. This would allow you to come up with an estimate of how many people are needed to support a product. But where is the consideration of value?

Instead you say something like: “This product is a key part of our business but the days of big changes are gone. Therefore one person will be assigned to look after the software.”

If in three months more people in the business are demanding more changes to the software and you can see opportunities to extract more value – however you define value – then that decision might be revised. Maybe a second person is assigned.

Or maybe you decide that maintaining this product isn’t delivering more value so why bother? Reduce work to only that needed to keep it going.

Q6: How do you evaluate the fact that your application becomes twice as fast (or slower) when you add a new feature in a short period of time?

Answering this question requires that the team has a clearly defined idea of what value is. Does the organization value execution speed? Does the organization value up-time? Does the organization value capacity?

Hopefully some of this will have come out of the value estimation exercise in Q4, if not the analysis is just going to take a bit longer. The thing to remember is: what does the change do for the business/customers/clients? Being faster is no use in itself, but doing X faster can be valuable.

The real problem here is time. Some changes lead to improvements which can be instantly measured. But there are plenty of changes where the improvements take time to show benefit. Here you might need to rely on qualitative feedback in the short run (“Sam says it is easier to use because it is faster”). Still I would keep trying to evaluate what happens and see if you can make some quantitive assessment later.

Notice that Q4 and Q6 are closely related. If you have a clear understanding of why you are doing something (Q4) then it becomes easier to tell if you have delivered the expected value (Q6). And in trying to understand what value you have delivered then you refine your thinking about the value you might deliver with future work.

Another feedback cycle.

These questions concludes the series of question carried over from the #NoEstimates/#NoProjects workshop in Zurich – see also How should we organize our teams? – Dealing with unplanned but urgent work – How do we organise with a parallel team? – if you would like me to answer your question in this blog then please just e-mail me.

The #NoProjects books Project Myopia and Continuous Digital discuss these and similar issues in depth and are both available to buy in electronic or physical form from Amazon.

More Continuous #NoProjects questions Read More »

Dealing with unplanned but urgent work

Agile, Agile Process, Kanban, Xanpan / allan kelly / October 3, 2018

3) Maintenance and Evolution
To keep a product alive, we choose backlog stories that will bring value, and do them one after the other.
But… as support of the application may take a huge part the work. And when the problem is critical, there is nothing you can do but stop what you do and fix it. This can blow any estimation.
How do you deal with firefighting in a #NoProjects world?
And techniques to avoid it.
How does #NoProject and DevOps work together?

Let me take the last part of this question first. Operations has never been plagued by the project model the way development has. When does a SysAdmin ever say “The project is finished so I’m not going to restart the server” ?

DevOps (aka Continuous Delivery) and Continuous Digital are a natural fit. The team is responsible and accountable: writing the code, deploying it and supporting it there after: “You built it, you operate it” as DevOps people like to say.

Of course the team needs to contain all the skills needed to service this approach. That might mean having an individual specialist on the team or it might mean that team members have multiple skills. A Continuous team is not just a DevOps team, it is also a Business-Technology team – or #BizTech to coin a hashtag. (This week I heard such a team called a BizDevOps team. That is one portmanteau too far for me.)

Which brings us quite nicely to the first part of this question: how do you manage – and perhaps even plan for: unplanned work?

What I would like to happen when unplanned work appears is that it is written on a card and placed in the backlog. It then takes its place with all the other possible work. But… as the questioner states: this work can’t wait, it is urgent.

Unplanned but urgent simply needs to be done. Quite possibly other work, less valuable work or work which is not time critical may even be interrupted.

At this point I was about to refer readers to an old blog post about Yellow Cards. But it turns out that I never wrote that post. Despite talking about Yellow cards for years I’ve never blogged about them. I wrote about them in Xanpan but for some reason or another I never wrote the blog… so here you go…

When a team is mid-sprint and unplanned work appears the team should:

First ask “Can this work wait?” – If so then write it on a regular card and put it in the backlog
If not then ask, is this more valuable than work we are doing now? – If not then someone needs to find the source of the request and explain why is isn’t going to get done.
Assuming it is urgent then it gets written on a Yellow card.
If it is really really urgent then someone drops what they are doing and works on the yellow card immediately.
If it can wait a little while then the next person who finishes their current work picks up the card and does it.
Once the yellow card is done mark it as done as with any other card and work continues as it was before.

Accepting unplanned work into a sprint impacts the other work the team is doing. I’m not a big fan of the commitment protocol so to me it is no big deal if this work displaces something else. But if your team are expected to hold fast to hard commitments while dealing with unplanned work then you have a problem, call me, we need to talk more.

At the end of the iteration we can look at the cards and reason about them. Now we can see the work we can manage it and decide what to do about it.

I count up the yellow cards – and all the planned work cards. That allows me to calculate a ratio of planned versus unplanned work. (Sometimes teams put a retrospective points estimate on a yellow but doing a card count is often sufficient.)

This can be tracked over time – graph it, make it visible again. Now we can look at the work and the pattern of work, reason about it, maybe do some root-cause analysis. Perhaps:

Perhaps much of the urgent work isn’t really so urgent, perhaps the team should push back more. Maybe the team, or one of the team leaders, needs to the authority to say No.
Perhaps most of the unplanned work comes from a particular person. Maybe this person doesn’t realise the impact of their unplanned requests, or maybe they need to be included in the planning process, or … a million other reasons.
Perhaps the unplanned work is coming from the same sub-system, maybe some remedial work on that sub-system could reduce the amount of unexpected work.
Perhaps the unplanned work is just the nature of the business and being responsive is valuable.

Looked at this way we can think about reducing the amount of unplanned work. But also, we can plan for unplanned work.

It is likely that over time a pattern will emerge. One team I know found that 20% to 25% of their work in any sprint was unplanned. They simply planned for 20% less work. They now had the capacity to cope with unplanned work. At the least they could expectation manage stakeholders.

One team found that each sprint they were doing about 20% IT support tasks (new PCs, Word problems, etc.) so they hired a support technician.

Another team who agonised about unplanned work found that actually they only had about one unplanned card a week. Their problem was not excessive unplanned work but the fact that unplanned work tended to have a very high profile in the company.

Teams which find they have very high levels of unplanned work on a regular basis (e.g. over 50% of work for several months) may well decide to adopt a full Kanban system. Indeed, Kanban folk probably recognise my description as a very simple example of quality-of-service and policies.

I say more about Yellow Cards for unplanned but urgent in Xanpan so you might like to continue reading there.

This is the third question carried over from the #NoEstimates/#NoProjects August workshop in Zurich.

If you have any questions about Continuous Digital, Project Myopia and #NoProjects please mail them over and I’ll do my best to answer them in this blog.

Receive these posts by e-mail?

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

Dealing with unplanned but urgent work Read More »

How should we organize our teams?

Agile, Agile Process, Digital business / allan kelly / September 18, 2018

Q1: How should we organize our teams?
My team is owner of different trading platforms and the core services around it. But we depend heavily on other products (e.g. financial feeds, client identification, services to send orders to stock markets, etc.). And of course each of the team managing these services have other platforms that are their clients.

When Vasco Duarte and I ran the #NoEstimates/#NoProjects workshop (or #NoNoWorkshop as I think of it) in Switzerland last month the attendees asked some good questions. With Project Myopia done and published, and Continuous Digital almost done it seems like a good time to repeat, and elaborate, the answers publicly. This will take a few blog posts to work through.

(I now have several Continuous Digital workshops and briefings available, please let me know what you think. Vasco and I are looking at repeating the workshop in London later this year, please get in touch if you are interested.)

The picture above is the way I see the question, if you have another interpretation, or another scenario please let me know.

The Continuous Digital model is for stable, long standing, autonomous, value seeking teams staffed with all the skills they need. Much of my thinking derives from Amoeba Management. Importantly each team needs to see how it adds value. In this case the business facing teams can see this – they enable the business do make money. But the back office teams find it hard see how they add value.

Now there are several possible answers to this question most of which involve some sort of re-organizations.

Option 1: Share the value

This solution does not involve reorganisation and comes straight from the pages of Amoeba management: allocate some portion of the value earned by the business facing teams to the teams they depend on. For example, the Trading platforms team might generate $10m each year. It could not do this without the services of the other three teams. Therefore some portion of Trading team’s earned value is passed to those teams.

Think about it, Trading Platforms affectively buys the services of three other teams. If those teams did not exist Trading Platforms would need to do that work themselves. Therefore those teams are contributing and deserve some credit.

This requires a serious conversation and probably needs more senior managers to intervene. Indeed, in Amoeba Management, Kazuo Inamori says that such decisions were among the most difficult ones facing Kyocera and often required more senior managers to make the final decision.

Nor is it always clear who buys from who, does a Sales Amoeba earn the value and pass part of it to the manufacturing team who build the product. Or does the Manufacturing Amoeba hire the Sales Amoeba to get their product to customers and therefore book the revenue and pass some to sales?

In the case above one might find it better to consider the value of the whole trading team including both the traders and the programmers who make the platform. Or perhaps the traders rent the platform from the technologists.

According to Inamori Kyocera standing allocations are set between teams. Alternatively one might create an internal market in which teams bought services from others on a piecemeal basis. On the one hand I like that idea model because it would allow for negotiation and trade-offs. On the other hand I imagine it creating a whole new set of bureaucracy, politics and internal sales. On balance, I’d fix the allocations and review periodically.

Option 2: Vertical slice

If you look at the picture above you might replace the word “team” with “library” or “services” and you would have a module dependency chart. Conway’s Law is at work – the organization and system reflect each other. (Although without knowing the history here it is difficult to say whether this was Conway’s Law or Reverse Conway’s Law at work.)

The services can stay as they are but we just disband the back-office teams and pass their responsibilities to the (enlarged) business teams.

The three teams will need to co-operate and co-ordinate with each other as they now have shared responsibilities. This itself can be a problem – two developers changing the same code anyone? But the world has moved on. Technology has improved.

In the days of SCCS, Visual Source-Unsafe, manual testing and monthly deployments it was a pain to have two teams working on the same code. But distributed source code control, automated testing and continuous delivery make this option far more viable than it once was.

On the plus side each team can work at their own pace on their own priorities and knowledge is spread around. On the downside teams can still trip up each other, they may duplicate work and specialist knowledge can get lost. (Note I am not saying “nobody has overall design authority” is a downside because while a single Linus can be an advantage it can also be a liability.)

One more problem here: this solution directly breaks Conway’s Law. In theory it could work but quite possibly the homomorphic force behind Conway’s Law might reassert itself. This might create some problems further down the line so needs monitoring.

Option 3: Independence

Taking option 2 to the extreme you might even separate the teams completely. Again there are plus and minuses.

On the one hand the teams are completely independent, they can move at their own pace, with their own priorities, value is clearly attributed and there is now resilience in the system and risk is reduced.

However, there is duplication. Not only does this mean more work it means that there may be inconsistencies, a client recognised by Trading might not be recognised by Yet Another.

Both options 2 and 3 demand larger teams and this option might requires more people overall. One can’t be sure because teams might come up with innovative solutions or come up with some new mechanism for sharing.

I’m sure some readers will discount this option very quickly but there are big benefits to complete independence – particularly when teams are separated geographically (e.g. Trading in London, Some Other in Frankfurt and Yet Another in Singapore) or when they are addressing different markets. One of the dangers of shared modules is that they become bloated by generic features nobody really wants but someone has to pay for.

This approach might also be advantageous when the company is in a growth and innovation mode. Let each team grow as fast as they can and innovate. In time a “winner” might emerge or common elements appear naturally.

Another variation on option 3 would be to have one team take the lead. Say Trading, this would be a larger team who developed the share services as part of their business facing work. But they would not “genericise” those services. The other, smaller teams, would do what they needed, when they needed, to service their own value streams.

That is three options. I could come up with some more, none is perfect. The important things are:

Create a clear way for teams to see the effects of their work and share in the value.
Allow teams autonomy in decision making and reduce dependencies.
Keep it simple so everyone can see cause and effect.
And of course, keep the teams stable – don’t break them up.

If you have any questions about Continuous Digital and #NoProjects please mail them over and I’ll do my best to answer them in this blog.

Receive these posts by e-mail?

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

How should we organize our teams? Read More »

Release or be damned

Agile, Agile Process, Business / allan kelly / September 6, 2018

Back when I was still paid to code I had a simple question I posed to troubled development efforts:

“Why can’t we release tomorrow?”

This short simple question turns out to be amazingly powerful. I remember one effort I was involved with in California where a new CEO took over and started cutting jobs. I posed this question to the team and in a week or two we did a “beta release” – we did those sort of things back then. Asking this question was the key that allows us to question everything, to cut the feature list – or rather push work back, it stayed on the to-do list but we didn’t let it stop us from pushing to release.

We rethought what we were trying to achieve: we didn’t need the whole product, we just needed enough of the product to work to show to one specific target customer. Even if they signed there and then we had weeks before they used it in anger. But until we released something, until we had something “done” our team, our product, look like just another “maybe.” We had to draw a line under it so the new CEO wouldn’t draw a line under us.

Saying “only do the essential” is easy and come up again and again, whether it is Minimal Viable Product, Minimal Subset, Must haves in Moscow rules, but it is far easier said than done. One persons “essential” is so often another persons “optional extra.” In this context, when I say “essential” I mean “the parts needed to make the system work end to end” – I’m far closer to the old walking skeleton idea.

I was reminded of this question by a couple of endeavours that came to my attention during the summer. Well, I say came to my attention, I feel a bit responsible. Both endeavours are happening at clients; clients who I had fallen out of touch with. My style of working is to help clients who want help, I don’t like selling myself. These clients didn’t ask for more help so I didn’t jam my foot in the door, in retrospect maybe I should have.

In one case the team were doing very well. They were iterating, they were TDD/BDD’ing, they were demoing, they were working with the client, they were doing everything … except releasing. Then one day the client asked “when will it be done?”

Now think for a moment: What if you could release your product tomorrow?

The thing is, without actual products those around the team look for signs that the team can be trusted, that they team will deliver, that the team are thinking about what is to be done. People ask for proxy-products: plans, schedules, risk-logs, budget forecasts and so on. When stakeholders can’t see progress they look for things to assure them that there is (or will be) progress (soon).

Who needs plans and predictions about the future when the future is here tomorrow?

Actual releases are they key to reaching the new world, they change everything.

So I feel guilty: I should have inflicted myself on these teams, I should have been there again and again bugging them “Go to release”, “Remove that barrier”, “Force it through”.

Being able to ship an update of your product has a transformative effect.

It demonstrates the team have the ability to do the job in hand.
It demonstrates you have quality. It obliterates the need for a test-fix-test-fix aka stabilisation aka hardening phase.
It blows away sunk costs because something has been delivered.
It removes “maybe” and “ready but…”
It is probably the greatest risk mitigation strategy possible.
It creates trust and provides a platform for solid conversations.

Most of all, a released product is a far better statement of progress than any number of plans or forecasts.

This does not mean everything is done. Sure there are things left undone but there will be things left undone when I’m on my deathbed, that is the nature of life. As much as we (especially men) love to collect entire sets there are few prizes in life for completing everything on your bucket list.

Having a released product utterly changes the nature of the conversation. Conversations are no longer full of “ifs” “maybes” “shoulds” “how long will it take?” “what are the quick wins?”. Those questions can go away. In its place you can have serious conversations about prioritisation and “what do you want tomorrow?”

This is all part of the reason I love continuous delivery. Teams can focus on real priorities and stop wasting time on conjecture.

In my book if you don’t have a releasable product at least every two weeks – say every second Thursday – you are not Agile. And if you haven’t released a product to live in the last two weeks you are probably not Agile.

I don’t care how close you get to a releasable product: it isn’t a release if it isn’t released to a live environment – close but no cigar as they say. (OK, I’ll accept the live environment may not be publicly know, or might be called a beta, but it has to be the real thing.)

Nor should you rest on your laurels once you have regular releases (to live) every second week. That is but first base. You have opened the door, now go further. There are at least 13 opportunities to improve.

If you cannot do that now then ask yourself: Why can’t we release tomorrow?

And start working to remove those obstacles:

Reduce the number of work items you are aiming to put in the release.
Fix show-stopper defects now.
Running tests now.
Get those people who need to sign-off to sign-off.

Software development has diseconomies of scale: many small is cheaper than few large.

And once you have your release you can turn your attention to making sure these things don’t happen again:

Reduce the amount of work you accept into development at one time.
Fix every defects as soon as they are found.
Automate tests so they can run more often. (Automate anything that moves, and if it doesn’t move, automate it in case.)
Find a way to reduce the time it takes to get sign-offs: remove the sign-off, make sure the signer prioritises signing or delegate someone else to sign (or automate the signature.)

If there are essential processes, activities, third-parties (or anything else) that has limited bandwidth which need to be done before release but inject delay then re-orientate your process around that bottleneck. For example, if your code needs to pass a security audit before release (an audit you can’t automate that is) then, downsize all the other activities so that the audit process is 100% utilised. (OK, 100% is wrong, 76% might be better, but thats a long conversation about queuing theory.)

Again and again I seem condemned to learn the lesson: nothing counts but working software which is used.

As for my team, and my job in California, it didn’t save me. I regret not asking the question sooner.

Release or be damned Read More »