A couple of weeks ago I gave a private presentation to an organization entitled: “The Business Case for Agile in 2020.†Actually, it surprised me a bit that in 2020 people still wondered what the business case for agile was but that probably says more about my arrogance and the agile bubble I live in.
It was hoping to keep this blog virus free. Indeed my “Conflicts in coaching†was going to be the first of several on agile coaching (what else could I do in the air going to and from Agile on the Beach New Zealand?) But…. the world has changed, I’ve changed…
It is a very scary time. Both health wise and economically: I know at least one software engineer who has lost his job as a result of the slow down. But I also know random (inappropriate) coding jobs still appear in my mailbox, I continue to see job adverts on Twitter and LinkedIn and I know one company that has landed work and had to hired contractors to work on a corvid-19 project. So some observations…
Observation 1: Covid-19 will go down in history as the first digital health crisis.
Digital technology has a big role in fighting the virus. Decisions and actions are being driven by software models of what could happen. The famous Imperial model is now OpenSource and Microsoft engineers are reported working to improve the model. (At a few hundred lines of R code there isn’t that much to refactor – although there are some very long functions and I can’t see any unit tests.)
Apps are being created to track contacts and you can bet that the search for antidotes and vaccines is utterly dependent on software. Digital powered home delivery networks and internet shopping have made closing the economy just about possible.
Those who are not directly fighting the virus are continuing to work because of digital technology. Zoom, Skype, and the like might be the most obvious beneficiaries of the virus but many others will benefit too. Although the virus is simultaneously putting a strain on our digital infrastructure and necessitating human action – witness the search for Cobol programmers in the US.
Not only have most IT, sorry digital, workers decamped to home but so too have many others – in fact almost any occupation that can. Schools are delivering lessons and distributing home learning kits online. Industries which can’t move to online working will suffer the most. (Except those which put themselves in harms way like medical staff and, to a lesser degree, delivery staff.)
And when not working online media like Netflix, YouTube and BBC iPlayer keep us sane.
For us digital folk this is no big deal. It is an extension of normal life: we are at home 5 days a week not one. But for other folk, this is big. Even the most digitally inept lawyer is having to get with the technology. As people are forced to become familiar with digital technology …
Observation 2: Digital technology adoption will be accelerated by the virus
Which means, while some technology companies (like my friend’s) will not survive, those that do are set for a boom. Post virus swaths of the economy will be destroyed but technology is in for a boom.
That boom is driven by the three forces above: 1) unlike others, our industry is not destroyed, 2) technologist continue to work remotely, and 3) non-technologist will learn to use more technology.
In particular digital healthcare – both back-office big data background analysis and customer centred applications – will play an oversized part. This field was already growing rapidly but the experience gained during this crisis can only help the sector.
But also…
Observation 3: The economic devastation caused by the virus will open up many new opportunities for digital companies to enter markets and thrive
Companies which fail create opportunities for new companies – either a like-for-like replacement or a new type of company. Previously, while those companies were active, digital technology had to compete with the existing providers, the incumbents. With those companies gone the way is clear for new digital technology companies to enter the market.
I’m not saying this isn’t going to be horrible; company failures will be painful and it new entrants will take time to get established.
And what of Agile?
Observation 4: Covid-19 is the ultimate test of agility
Forget arguments about what is agile and what is not agile. Forget ScrumBut, Wagile and the other insults hurled at those judged to be less agile than thou.
Forget agile assessments and agile maturity frameworks; forget ticking off ceremonies and declaring yourself agile. In the new world the more agile you are the greater your chances of survival.
On paper you may have the most agile team in the world but, if that team, and your organization, cannot now demonstrate how it changes rapidly it just isn’t agile.
Every single plan that existed before March 1st is now invalid. Right now companies need to pivot like never before. Agility helps companies pivot. Those who can’t pivot, or can’t pivot fast enough stand to loose the most. If you can’t pivot you aren’t agile, QED.
Companies which still operate in hierarchal command-and-control mode will find it more difficult to switch to distributed teams and remote working. When everyone is remote you need to delegate decision making. Companies which don’t trust employees, companies which constantly check what employees are doing will find home working incredibly difficult and expensive.
Individuals and interactions are more important than ever before. Processes and tools are essential but few heavy weight processes will survive the instant shift to completely distributed working. Any tool which doesn’t help now is an impediment.
Those companies which are still struggling with technical liabilities (aka technical debt) will find the cost of living with those liabilities just increased.
Observation 5: Test driven medicine
Day after day I read in the papers that the UK is not doing enough testing. It seems that countries like South Korea which do a lot of tests and base their strategy on knowing who is infected (and therefore who is safe) and then tracing the virus are doing best.
That means testing needs to be rapid – a short feedback loop.
And testing needs to be cheap so it can be done at scale.
Doesn’t that sound familiar?
The cost of not testing is precautionary isolation. That cost is not sustainable.
If you could test anyone, and everyone, instantly the offices, shops and schools could reopen: you would just test everyone who arrives.
The testing strategy agile has been advocating is now needed to fix the world. And in the UK the Government seems to be as resistant to a test first approach as the most obstinate software manager or engineer.
As much as I hope the world will shortly return to how it was it will not. It will never be the same, we don’t quite know how it will be but it is already clear that digital technology and agility will be part of it.
Both sites accept other credit cards so don’t worry if you have another currency and we can post anywhere – if you get stuck get in touch and we’ll find a way that works.
In retrospect I think the presentation should have had a big question mark (“?â€) in the title. In many ways I’m asking “Is the Product Owner role impossible to fill well?â€. I had some really good discussions on this topic after I gave the presentation and I will blog more about the role soon. In the meantime check out my new book if you want more of my thinking, The Art of Agile Product Ownership.
Finally, while I was at Oredev I gave another presentation: Evolution: from #NoProjects to Continuous Digital (also available for download). This presentation itself was an evolution. So I’ve christened this version the “2020 edition†to distinguish it from the earlier version. I am attempting to do two things here:
One, be clear that the #NoProjects argument has itself moved forward. When #NoProjects began in 2013 the argument was very much “The project model is not a good fit for software development.†Now, as we approach 2020, the argument has moved on: business (and just about everything else) is digital, in a digital world advancement means technology (software) change. Therefore rather than following a start-stop-start-stop project model are organizations need to structure themselves for continuous digital technology enhancement.
Two, building on that argument I try to talk more about how our companies need to update their thinking. Specifically what does the new management model needs to look like?
More on all these subjects in my usual depth soon.
Like this post? – Like to receive these posts by e-mail?
Smaller cartons of software are cheaper and less risky
Â
Vasco Duarte and myself are running our #NoProjects/#NoEstimates workshop again in London – February. This is a one day class with myself and Vasco, it is very interactive, lots of exercises and lots of changes to ask us your questions.
“A one day introduction to #NoEstimates and #NoProjects. Learn to apply the digital-first tools that help you deliver more value in less time. From breaking down 9 month projects to 30 minutes, to learning to reduce investment risks. In this workshop you will learn how to transform your product development.â€
Continuous Digital is the second of my two #NoProjects books. Many people ask: “why two?†“What is the difference between them?†“Do I need to read both?â€
Short answer: Project Myopia explains why the project model is bad for software development. Continuous Digital describes what to do instead.
Long answer: as the #NoProjects hypothesis grew, as I thought about it more, as I talked to others about the ideas – specifically Steve Smith, Joshua Arnold and Evan Leybourn – the ideas grew. My thinking both on “what to do instead of project management†and “why do something different†grew.
Specifically I saw that the combination of Continual Delivery and Digital Business meant there was a stand alone case for moving beyond the project model. Whether you agree with the problems I discuss in Project Myopia or not there is a case for changing the way businesses are managed.
That is why I split the too books. Project Myopia is a companion book, it is not a prequel, a sequel, a book one or a book two. It is a book some people will read in its own right.
Continuous Digital argues that since business are increasingly digital, and as businesses strive to survive and grow then technology development is not a separate “project†it is inherent to the business. Technology and innovation are business as usual.
Stopping, even pausing, work – as in the project model – surrenders competitive advantage and introduces extra costs (time, money, risk). What is needed is a new model. A continuous model.
Continuous Digital is now published on Amazon in digital form and will soon be there – and in other booksellers – in physical form. (If you can’t wait for a print copy you can buy one from Lulu where they are slightly cheaper too.)
So I’d like to say Continuous Digital is done. But…
Even before I saw the final print version I had requests for an audio version of both Project Myopia and Continuous Digital. I’m debating whether to do these, if you would buy an audio version please let me know, if enough people want it I’ll do it.
Second, once I saw and held the final, done, version in print new ideas came to me. I don’t want to revisit the text – although I might fix a couple of typos – but Continuous Digital is a big book, 350 pages. And I know many people will be put off by the size.
So I’m thinking of turning it into four smaller books, each around 100 pages in length and each corresponding to one part of Continuous Digital. Maybe.
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.
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.
Project Myopia – the original case for #NoProjects – has been a long time in the works but it is now done. Published. For sale on Amazon.
Projects fail. Some say 40% of all IT projects fail, some say 70%. And it has been that way for years. Each project fails for its own reasons but they all share one thing in common: the Project Model. Could it be the project model itself which creates failure?
Projects end. Successful software continues. Twenty-first century digital businesses want to continue and grow.
Project Myopia is available to buy on Amazon today – the physical version should joined the eBook in a few days.
Project Myopia gives the case against projects – the hard core #NoProjects arguments. A second book, Continuous Digital will join Project Myopia in a few weeks on Amazon. Right now copyediting isn’t finished on Continuous Digital, plus the physical copy needs to be worked out. In the meantime late drafts of Continuous Digital are available on LeanPub.
Project Myopia – the original case for #NoProjects – has been a long time in the works but it is now done. Published. For sale on Amazon.
Projects fail. Some say 40% of all IT projects fail, some say 70%. And it has been that way for years. Each project fails for its own reasons but they all share one thing in common: the Project Model. Could it be the project model itself which creates failure?
Projects end. Successful software continues. Twenty-first century digital businesses want to continue and grow.
Project Myopia is available to buy on Amazon today – the physical version should joined the eBook in a few days.
Project Myopia gives the case against projects – the hard core #NoProjects arguments. A second book, Continuous Digital will join Project Myopia in a few weeks on Amazon. Right now copyediting isn’t finished on Continuous Digital, plus the physical copy needs to be worked out. In the meantime late drafts of Continuous Digital are available on LeanPub.
In my presentation at Agile on the Beach last week I continued my discussion of Agile and Digital. It is increasingly clear that digital and agile are intrinsically linked. Specifically, business need agile processes to get the most out of digital technology. My “Agile, Digital & the new management paradigms†presentation is online but let me give you the argument here.
There is a long standing model of technology change – so widespread I can’t find the original source – which says change comes in three steps:
First new technology allows the same processes and activities to be done better, faster, cheaper, more efficiently. In this stage new technology is used to do the same things, the processes and practices change little.
Next new technology allows process and practices to be reconsidered and changed to make the most of new technology. Work becomes even better – whether that be faster, cheaper, higher efficiency, superior products, whatever.
Finally new innovations appear because of the technology and new processes. One can see opportunities for new businesses, new business models, the next round of technology innovation and more.
So the whole thing repeats.
Look at the photo above. According to WikiCommons this is a picture of a factory at Woolwich Arsenal sometime in the 1800s. Notice the belts stretching from the ceiling to the workstations. These carried power, or to be more precise motion. Above the workers is the line shaft which turns. The shaft is driven by a central power (motion) source somewhere, probably a water wheel or a steam engine.
This is before electricity. The line shaft and the belts carry the power the factory needs to work. And they break, the longer they are the more prone to breaking they are. Factory design is constrained by the need to have straight lines for the line shaft and short distances between the shaft and the workstation. And factory design dictates layout and processes.
Then came electricity.
Electricity allowed each workstation to have its own motion generator. At first factory owners used electricity to do the same things faster and more reliably. They could dispense with the steam engine and thus the stokers and coal it needed. But at first they didn’t seize all the advantages electricity brought.
It took time to understand how a factory could be laid out more efficiently and how processes could be changed. When they did factories got even more efficient and faster. Some might argue that it took the coming of Lean manufacturing to complete these process changes.
The same story has played out in industry after industry with technology after technology. Think of Word processors: first they helped secretaries do their job faster, then processes changed and everyone wrote themselves, goodbye secretaries. Containerisation in the shipping industry is another. First ships loaded and unloaded faster. Then the shipping companies innovated but more importantly world trade innovated. Some observers claim containerisation was a more significant factor in trade globalisation than free-trade agreements.
Digital technology is like electricity. It changes business, it creates new opportunities for doing things differently. To get the most from digital technology you need new processes. Right now most companies are stuck – even happy – doing things faster. Only when they change processes will they get the full benefits.
Agile processes are that change.
Agile ways of working help companies get more from digital technologies. Without Agile companies using digital technologies are just doing the same old thing faster.
Agile started in software development for two reasons. First software developers had a lot of problems, they had the need to change. Second, programmers had the first access to digital technologies.
Ray Tomlinson, a programmer, was the first person with e-mail. Tim Berners-Lee, a programmer, had the first web-browser. Ward Cunningham, a programmer, had the first Wiki. I could continue.
Software developers created Agile because they needed to and they could.
This is why Agile is taking off in marketing.
Outside of technology itself marketing has probably been more exposed to digital technology than any other part of business. First with digital publishing then with social media. At first digital helped marketing departments do the same work faster. Next it changed what you could do entirely. Marketing is adopting agile because those processes allow marketeers to do a better job when working with new digital technology.
So forget all those arguments about agile being a better way of working (it is but never mind).
Forget all those stories of agile like processes and practices before 1998 (yes they existed but that doesn’t change things).
Forget the debate about waterfall and upfront planning versus agile and just-in-time (that is history).
All you need to know is:
Digital technology is helping you do things faster/better/cheaper.
Agile ways of working allow you to get more from digital tools.
Someone ask the other day: how should a organisation be designed?
There are two potential answers, which actually aren’t as contradictory as they look at first site.
The first is very simple: Don’t.
That is, don’t design your organization, don’t set out an organizational chart, don’t set out a plan and aim to restructure your organization to that plan. Rather create the conditions to let a structure emerge.
I suppose its the difference between “design” meaning “create a plan for the way you want things to be” and “design” meaning “the way things are arranged.” To differentiate them the first might be called “intentional design” and the latter “emergent design.”
That does not necessarily imply all emergent structures are good. As we see in code sometimes emergent designs are not always the best and over time they need refactoring. Which implies at some point there needs to be intentional design.
Put it like this: I’d rather your organization pulls the design rather than you push a design on the organization.
Organizational structure is itself a function of business strategy. And both need to be part emergent and part intentional. Although you might have noticed I tend towards emergent while most of the world tends towards intentional!
Thus it helps to have a reference model of how you think the organization should be, maybe something to steer the organization towards.
So the second answer to the question would be longer:
Create standing delivery teams which are embedded in the business line itself. This is sometimes call stream teams, or stream based development, or “teams aligned to the value stream”, or several other names I can’t think of just now.
Each business line is itself a stream of work and digital delivery teams support that work.
Teams contain all the skills and authority to do the work that is required for that business stream.
The team is part of the stream so the business/technical divide should dissolve. Something I call BusTech.
Teams are value seeking and value creating: the team seeks opportunities to create value for the business and delivers on the most valuable ones.
Devolve authority to the teams whenever you can. Teams are mini-businesses. (Notice I deliberately don’t use the word empowerment.)
Teams grow when the business is successful and more digital capability is needed. And teams shrink when money is tight or less capability is needed.
Teams may split (Amoeba style) from time to time. New teams may be in the same business line (addressing another question) or part of another, possibly new, business line.
Active – or Agile – Portfolio Management sits on top to monitor progress, provide extra resources, remove resources, etc. There may even be multiple portfolio processes, one at the business line level and perhaps one above multiple business lines.
Minimally Viable Teams are started to explore new initiatives, sometimes these go on to be full standing teams but they may also be dissolved if the idea doesn’t validate.
Seek to minimise common services between teams because these create bottlenecks, conflicts and delays. Each team should stand alone. This may mean some duplication, and therefore some extra costs, but accept that. Once you have your model working you can fine tune such things later.
Don’t worry about planning and synchronisation between teams to much, worry more about getting the teams to release more often and deal with synchronisation issues when they become a problem.
They are the main points at any rate. If you’d like to know more Continuous Digital contains a longer discussion of the topic. (Continuous Digital actually builds on Xanpan in this regard, and the (never finished) Xanpan Appendix discusses the same idea.)
