Agile Process

Agile: not Dead, but evolving

Agile, Agile Process, Management / / / Leave a Comment

Sorry. I’ve deliberately avoiding the click-bait “Agile is Dead” topic, until now.

For the last few years I’ve delivered a lecture on Agile to Oxford University students and this year the tutor specifically asked me to say something about the state of agile. When I looked over last years slides I see I was already talking about this. I’ll write more about this soon, if you can’t wait checkout “Xanpan 2021” from Frug’Agile en Arménie.

So, is Agile Dead?

Clearly not. (Albeit agile mania probably is.)

Agile is all around us. Teams work in sprints, hold daily “stand up” meetings, tools like Jira continue to sell, requirements documents are full of user stories, business journals regularly talk about “agile” and “agility” without any reference to software.

That doesn’t mean the result is perfect. The “agile” which prevails today falls short of what I and others in the community dreamed. As I’ve said before, Agile won the war but lost the peace.

Right now, agile isn’t getting attention because AI is. AI is soaking up all the discretionally time and budget so agile is squeezed out. Ironically, to get the most from AI you need the learning processes embedded in Agile to find better ways. Right now we don’t now the best way to use AI. We are in a vast experimental phase and we need more of the learning and feedback in agile.

Back to the question, is Agile Dead?

The common agile that prevails is a watered down, corporately acceptable version that is still a lot better that went before.

But then, most people don’t remember before agile. The Big Up Front practices which gave massive requirements and functional specifications; the defined process and ISO-9000 process audits, the guilt of “not doing it properly” and the inability of those doing the work to influence how it was done.

While many of those problems have resurfaced under other names in the agile world things are still a lot better. If we had stayed with that approach there would be no automatic updates to the apps on your phone, no digital business, nor much of the other technology that surrounds us. Maybe Apple and Google would be OK but legacy banks, airlines, telecos and Governments would be even worse than they are now and a million start-ups would never have started.

In truth, many of the “waterfall” processes were never followed. I worked on exactly one project that did it by the book, Railtrack Aplan. Officially it was a success, it went live. But what went live was a shadow of what was supposed to be delivered.

Everywhere else did something that (kind of) worked and then felt guilty for not doing “properly”. When I was at Reuters they tried to force us to work by the book, they destroyed much of their own capability in the process.

What has agile ever given us?

Agile showed there was another way and added democracy by opening the debate on “how we work”. The Internet help agile spread and opened up the debate in a way that had never been possible before.

If nothing else Agile gave us a better reference model, a better way of describing our work.

Actually, it gave us several reference models, Scrum, XP, DSDM, etc. Always, and everywhere, people adapt, when processes work they use them, when defined process don’t work they work around them. For a while agile licensed that working around, experiments were everywhere.

Agile was not so much new in itself as a new combination of ideas which were lying around.

The engineering practices in XP descend from the 1970s quality movement based on the work by Phil Crosby and W.Edwards Deming.

The self-organizing teams in Scrum drew on the sociotechnical systems. First recognised in the 1940s and 1950s by the Eric Trisk – then at P&G and Topeka and the genesis of Senge’s organizational learning.

The inspect and adapt philosophy in Tom Gilb’s Evo and then Scrum comes from Stafford Beer and management cybernetics.

Lean thinking draws on many of these ideas directly but lean also begat its own software process in Kanban.

As for the Frankenstein’s monster that is SAFe… you can decide for yourself whether SAFe is agile but it is definitely not lightweight. Because of its size alone it is hard to adapt SAFe and involve the workers.

The return of Agile?

Can we expect Agile to return to its previous permanence? Will the day come when everyone wants to hire a Scrum master? No.

That has passed. Organisations have ticked the Agile box – if only because they have moved on to AI. The days of big agile transformations are largely over because companies have declared success.

Put it another way: Management fads don’t return.

Imperfect agile is here, hopefully enough of it has been adopted that companies will continue to improve.

More importantly, those ideas underlying agile – quality, sociotechnical, cybernetics, learning – are still valid and will continue to have influence. Some companies will embrace them and get a lot from them, some will continue to reject and most will dip-in-and-out. These ideas will return, albeit in a different package and with a different name.

But none of that means agile is dead. Agile mania might be over but agile is continuing to evolve out of sight. Agile wasn’t the first coming of these ideas and it won’t be the last. Next post I’ll talk more about how I see it evolving.

Signup for the my latest posts by e-mail and download a free book

Thanks to Fritz Geller-Grimm for the parrot picture under CC license

Agile: not Dead, but evolving Read More »

What I’ve been getting wrong about PDCA

Agile, Agile Process, Continuous, Management / /

I’ve been teaching planning lately and once again it seems to me that the PDCA cycle – aka Shewhart or Deming cycle – is pretty much the core of all planning. Or rather, it is the basis for all mutli-pass planning – when iteration is allowed. (One-pass planning, big-up-front-design “BUFD”, is fine for trivial situations but alway has problems in complex situations.)

So, again I’m reminded of why I don’t like PDCA. Two reasons.

Adjust over Act

When the fourth step is labeled “Act” it fails to speak to me. “Act?” I ask, “Didn’t we just DO?” Easily fixed, label step-4 “Adjust” – many people do. Now it says, “Plan a bit, do a bit, check the results, now adjust the plan or the way you are working.” That makes more sense to me.

4 unequal steps

Secondly, the typical presentation – like my diagram above – makes it look like the four steps are equal and that is not the case. Just in terms of the time they take the fourth is almost always the shortest. Which of the other steps dominate is going to depend both on the planning culture where you are and the amount of work that needs doing.

Many places will put a lot of time and effort into planning. While this can entirely justified if you are building something that lives depend on, planning suffers from diminishing returns. It is often far better to plan a little, run around the circle and plan some more. Planning is learning but so is doing, you can learn more by a few minutes of doing than hours of planning.

Other places will skip planning altogether and launch into doing. While over-planning is problematic jumping straight in is also a problem. Either way, in terms of the PDCA cycle, planning is not an equal element.

Now when planning is skipped or rush the doing phase is going to expand. In fact, on a really big endeavour which needs a lot of planning the doing phase can also be very large. Of course, its entirely possible that your planning is so excellent that you see an quick way to deliver. But again, doing is not an equal quarter.

Test-fix-test-fix-test doom loop

The same does for the check (or test) phase. It can be long or short. If your planning was good, and your doing was quality then you can hope that the check phase is really small. It does happen. But too often there is little quality in planning so you actually end-up with a short-circuit as the checks fail and more doing is needed to fix things. (This is the test-fix-test cycle that can destroy any schedule.)

I wouldn’t expect Plan, Do and Check to be equal sizes, depending on your organisation, culture and the nature of the thing you are doing I would expect one to dominate.

But I don’t see that in Adjust. Adjust is the forgotten child. Indeed, in many projects, especially at the end, everything just goes hell for leather do-check-do-check-…. Adjust, and even planning, goes out the window.

Using PDCA successfully

Even in the best places Adjust is always going to be the shortest of the four. The irony is that it is probably the most important. It is the step where reflection and improvement happen.

The truth is I’ve always struggled to apply the PDCA cycle formally. But when I look back at almost every single engagement the actual work can be mapped to the PDCA. It is fundamental, whether building product, running sprints, setting and executing OKRs or almost any other non-trivial work. Its just that the steps are not equally time consuming or equally respected.

And the secret to making it work well? Simple, go around fast. A little planning, a little doing, quick check, small adjustments and go again. Learn in the planning, learn in the doing, learn all the way round and put that learning into action.

What I’ve been getting wrong about PDCA Read More »

4 quick fixes to bring order out of choas

Agile Process, Management / /

I have been working with a coach recently to think about what I do. Odd as it might sound I have real trouble articulating what I do. This is particularly true when I’m employed to work on team performance and processes. In my mind I turn up, I talk to people and they then makes things better. Can I take the credit for that?

One of the reoccurring comments I get from clients is that I bring order from chaos. While I’m immensely proud of that it is a hard sell when trying to articulate the value companies can get from hiring me. That is because it implies you already have chaos, and who wants to admit that?

Whether chaos or not I’ve been running over my past engagements and a few things stand out. These are things that I have repeatedly done with teams, things which have made work better (and therefore more productive, efficient and fulfilling.)

Most of these suggestions are quick fixes: you can introduce them pretty quickly and see results. But they do not detract from long term improvement. Even if you have time these are a good place to start.

Triage processes

These come in various shapes and sizes. Typically this means appointing one or two people to quickly review work requests and decide if they need immediate action, can wait a little while or be pushed back.

In one case this mean that all urgent support requests or bug fixes were added to the teams work board in a special column. A few minutes before the daily “stand-up” the Product Owner and Team Lead would review these and decide if it was immediate action, push-back or hold for the next regular planning meeting.

(In the most urgent cases work might begin as soon as the request was made but that decision was reviewed just before the stand-up the next day.)

In another case I convened a weekly meeting to review all the urgent work requests which had some in in the last week (mostly things people called bugs.) Collectively we would agree the prioritisation (1, 2, … 5) and then, for just the priority 1s list them in priority order. Unless the customer service manager and myself (as Development Manager) agreed something new became more important during the week we stuck to this order.

There are plenty of other examples I can give but you get the idea. These triage processes work wonders at controlling task switching, confused priorities, decibel management and other sins. Consequently they boost productivity, work order and satisfaction.

Sacrifice one

Hand-in-hand with triage I often sacrifice one team member to urgent but unplanned work: bug reports, customer service requests, and so on. Even on a team of 3 or 4 having one person designated at the urgent work or fixer can payback both in addressing issues and allowing others to work uninterrupted. This designated person isn’t assigned to any other work, or at least nothing time critical.

There are a few engineer who relish this role and love nothing more than a stream of “small fixes.” Most engineers would rather work on bigger items and stick with them for a few days. So unless you are blessed with one of these people rotate the role between team members.

Routines

I’ve no claim to originality here, this is 101 in the agile processes playbook. Still it is effective. Choose the routines and ceremonies that make sense for your team: daily stand-up, regular planning/replenishment (I prefer weekly, most teams do it fortnightly, just please avoid 3-week sprints), retrospectives (not necessarily every iteration, perhaps monthly, at least quarterly) and regular releases. I’d love to work with a high performing team who do many releases a day but the only time I’ve seen teams doing such is with bug fixes. Again, weekly, fortnightly, monthly, these can all bring more structure than you have now.

And of course, if you are using OKRs create a cadence and put the dates in your calendar.

Create focus

Taken together those three suggestions: triage, sacrifice and routines all aim to create more team focus. Focus is one of the most powerful tools you can use. These three changes start to create focus.

Beyond them there is so much more that can be done to create focus: backlog structuring and prioritisation, OKRs, testing approaches, various graphs and measurements, …

Statistical forecasting

Even if a team is making effort estimates – in time, story points, tea bags or whatever – start collecting data. Actually, since most teams these days are using electronic tracking systems you probably have an archive of data which you can mine today.

Go and analyse the data.

How many “stories” do you do a week?

What is the cycle time for a story? What is the average? The longest? The shortest?

What is the average time a story spends in the backlog?

How many things are in flight at the same time?

What is the bug count? And what direction is it going in?

What is the team “velocity” ? More importantly, what is the backlog growth rate?

There are many more question you can ask your data. Not infrequently you find that the data you have is not good enough to answer these questions but that itself is information.

When you start to answer these questions you can start to forecast based on data not guesswork.

And by the way: I’m more than happy to help you analyse your data, just get in touch and we can work something out.

Quality

So far all my suggestions can be done relatively quickly. The next one is a longer burn: improve quality.

When you quality is low a defect – a bug – can raise a hand at any time and create chaos: disrupt a release, distract and engineer, panic a customer, etc. etc, Defects can be high profile, very disruptive and difficult to close. Defects can destroy any schedule or plan no matter how carefully constructed.

The solution is simple: improve initial quality.

To do this install test-first working, code reviews, frequent customer review, shorten feedback cycles, etc. The catch is these can take a little time before they pay back.

Two I haven’t mentioned

Now there are two things I haven’t mentioned so far and will have some readers wondering why I haven’t: reduce work-in-progress and introduce outcome oriented working.

Reducing WIP can have wonderful effects but explicitly reducing WIP requires authority or credibility – and usually the credibility is required to persuade someone with authority. Introducing triage, sacrifice and routines will have the effect of reducing WIP but without the overhead of persuading people that “doing less produces more”.

So I only target WIP directly once I have picked some other low-hanging fruit. Plus, having the data to back up my case will really help. Attempts to reduce WIP usually start with a screening of Stockless Production.

Similarly, outcome driven working requires a certain credibility and trust to pull off. So often people are just drowning in work which OBVIOUSLY NEEDS DOING. Even if the engineers aren’t then there are plenty of other people saying “Just F…ing do it!” So asking people to take a step back and think about the desired outcome can be hard. Better build up some credibility first.

That is my list, what would you suggest I add to it?

And if you would like to discuss these ideas further please let me know.

4 quick fixes to bring order out of choas Read More »

Is there a difference between an Objective or goal?

Agile Process, OKRs / / / , ,

I tend to use the words Objective and Goal interchangeably, as synonyms. In fact, I think I might even say that somewhere in Succeeding with OKRs. But, I have been reeducated, there is a difference, subtle but I’ve come to consider it important. And it reaches back to the issue of goals within goals within goals, or maybe objectives within objectives within …

In many ways I prefer the word goal, it is shorter, more emotional and easier to find clipart to illustrate (search clipart for objective and you always get targets). But since we have Objectives and Key Results I have talked of Objectives and used Goal as a short synonym. Until last year when I (finally) got around to reading Richard Rumelt’s Good Strategy, Bad Strategy – a book which had been on my radar for a few years yet somehow I’d never got around to reading. There is more I could say about this book but that will wait for another day.

Back to my topic in hand, Rumelt says:

‘it is helpful to use the word “goal” to express overall values and desires and to use the word “objective” to denote specific operational targets.’

Rumelt made sense and I could see how this distinction could be useful. To illustrate it Rumelt says:

‘Thus, the United States may have “goals” of freedom, justice, peace, security, and happiness. It is strategy which transforms these vague overall goals into a coherent set of actionable objectives—defeat the Taliban and rebuild a decaying infrastructure.’

As if to prove the point I was teaching someone else’s course (something I don’t do very much) when up-came this quote:

“Goals are typically long term, overarching ideas concerning what you want for your business. … Objectives, on the other hand, are usually short-term and measurable. Many objectives may lead you to your goal.” (Forbes, 2023)

Back in Succeeding I talked of objectives being like Matryoshka and nested inside one another, what has become clear to me is that Goals are the outer dolls. By their nature they are a little vague – if only because the further into the future you look the vaguer things are. That means they may not have the very specific numeric tests Objectives, the inner dolls, need. Goals could lack key results entirely I’d rather they didn’t even if those key results were less testable.

So why do I say this subtle difference is important?

Well, precisely because Goals are imprecise, they leave much more detail open to interpretation, they allow for subjectivity and leave space for imagination and experimentation. As such they are both a tool for leaders to describe their shining city on a hill without being specific about in which way it is shinning or how high the hill is. That leave space for emotion, engagement and autonomy. By leaving space goals allow others to share. They are essential when the goal is somewhere off in the distance and actually, the way we think of shining might change between here and there.

That said, they may be used by teams and lesser leaders to describe general principles and aims which guide a team.

So, quarter by quarter set objectives, with key results, every quarter. These should be really precise. These objectives exist within a framework of annual OKRs and them within product goals and company goals. In fact, this takes me back to my description of level 1 goals and purpose. Armed with this language of goals and objectives that blog might well benefit from a little rework but the message stands.

With that in mind there is a space for leadership. Those who’ve read Succeeding will remember I advocate teams setting their own OKRs in line with leadership goals. Then the leaders reviewing the OKRs so both sides can find discrepancies (between the long term goal and the immediate objective). Well, Rumlet has something to say here too, even though he doesn’t discuss OKRs:

‘A leader’s most important job is creating and constantly adjusting this strategic bridge between goals and objectives.’

ObjectiveGoal
Narrow and focusBroad and more general
Backed by key results with testable numbersKey results might be backed by number but more likely to be general
Set by teams to direct operational workMore often set by senior leads to direct work – may be used by teams to define ambitions
Short term, a few months, year at mostLonger term, a year minimum

Is there a difference between an Objective or goal? Read More »

New year resolutions & improvement days

Agile, Agile Process / / / , , ,

Happy new year!

Traditionally new year is the time for making new resolutions. We resolve to change our ways, try new things, give up bad habits and make an effort to do things differently, for the better.

So why not try that in your work? Why not try that with your team?

A few years back I organised a “New Years Resolution” session at the company I was working for. Engineers gathered, we suggested ideas, we talked them through and we resolved as a group to do some new things. The fact that everyone was still fresh from a break and had been hearing about, and perhaps deciding on their own, new year resolutions, gave it an extra boost.

Yes, it was a bit like a retrospective and you could set it up as a retrospective on the past year.

Which leads me nicely on to: Agile Improvement Days – maybe I can help you?

Last year I visited Scandinavia several times to run a series of improvement day workshops for a client. The days were based around a series of well tested exercises, group discussion, reflection and action planning. Most of the days focused on teams but one of the days was specifically for product owners and another for business representatives.

These workshops came to mind when I was reviewing the survey I ran a few weeks ago: over 27% of respondents said their agile initiative “needs a reboot”. (Another 27% said it was early days and 33% said they were “in search of great.”) In thinking about how I could help these teams I realised I had a ready made, tried and tested answer: the improvement days!

As much as we talk about kaizen and continuous improvement it doesn’t always happen. Teams need reminding sometimes. I’ve long been a fan of the lesser know kaikaku – also called a “kaizen-blitz”. Even the best teams can benefit from trying something different. In fact, the best teams probably need something different simply because they have tried everything else.

So, I’m now offering my Agile Improvement Days workshops in their own right. You can have a single one off day, a package of days for multiple teams, different days over several weeks or have the days customised to your own need.

Feel like rebooting your team? Help your team move from good to great? Or deal with a specific issue? Have a look and let me know what you think,

And please, forward this on to anyone who you think might benefit from such days.

New year resolutions & improvement days Read More »

5 options for when the boss changes the target before you reach the last one

Agile Process, Digital business / /

Another question which came up at Oredev recently:

Q: What do you do when leaders change direction before you have finished your last goal?

I’m sure many readers will recognise this problem, and let’s face it: it can be depressing, you’ve not finished and suddenly you are heading off in another direction. When it happens repeatedly it is especially depressing.

Unfortunately, the term “Agile” implies that one can change direction and change regularly. So maybe this is something we just have to accept? – although depressing, is it really a problem?

Before we try and fix this problem lets acknowledged that it might not be a problem. Chris Matts used to tell a story of a company which when it landed a big enough sale simply threw away what it was working on, rolled back to the last stable release and immediately started working on the new thing. They had rationally calculated that when a sale was big enough it was worth more than the partially done work. (If I recall correctly, they made releases regularly so they would only be throwing away two weeks work at most.)

So, your first option, solution #1, is to optimise your work and deliveries to support rapid changes in direction. One could even argue this was “true agile”.

But, for many teams repeated changes of direction are a problem. They are a problem because the team aren’t able to move forward at all let alone reach a destination. Work which is partially done is either abandoned (and lost) or left unfinished. Unfinished work may increase costs because it gets in the way. We might tell ourselves we will come back and finish it once the panic is over but, as I discuss in always time for tea, that never happens.

So that is the real problem: changing direction is not itself the problem, rather the problem is that nothing is finished. When teams complete and deliver work at the end of every sprint, then as long as direction changes only occur in the planning meeting then there is no problem.

The same applies to more regular changes if the team can finish their work. So, if at the end of every day the team complete some work and deliver it then, if the next morning things change they still loose nothing. True, it might still be depressing that things change so often but it wouldn’t represent a loss.

Thus, solution #2 to this problem: make your pieces of work small and self contained to minimise the loss and increase your ability to roll with changes.

One cause of this problem can be the Product Owner is not doing their job properly. The PO should be peeking into the future and understanding what is round the corner. Sometimes they don’t do that because they lack the skills, other times because they lack the time to do it, but mostly they don’t do it because they lack the authority. They don’t get to visit customers or people in the organization usurp their authority.

So, solution #3 is to fix the Product Owner: make sure they have the authority, skills and time to do their job.

Solution #4 is to go to source: the people causing the changes and work with them.

When I’ve seen this before one of the driving forces was that the people asking for the change of direction didn’t feel the team would be able to complete one piece or work in a timely fashion and advance to the next. Nor did they appreciate the loss that that caused the team when they repeatedly change direction.

Now, if you apply solution #2 and work with lots of small then you can build trust by delivering early and often, that will give you more credibility when asking the direction changers to slow down. But that is unlikely to cure the problem entirely.

Therefore it is important to help those causing the changing direction to understand the consequences of changing: and the fact that constantly changing direction might be the cause of the problem they are trying to solve themselves. To this you need to create a feedback loop so people can see the consequences of their decisions.

One team I worked with would write down the request on a card and take the card and person making the request to the kanban board which showed their work for this sprint. They would ask “Where do you want this work?” The person asking for the change would be asked to decide which work was to be derailed or reprioritised. When this was simply a matter of positioning an index card on the board this was easy to see, the physical act made this really impactful.

Another client redesigned their burn-down charts so the powers-that-be could see that every time they changed direction they increased work and lost what had already been done.

Longer term, there is a question of strategy and sticking to that strategy. Constantly changing direction is itself a valid strategy. It is only a problem when complete responsiveness is not the strategy and when the team are not prepared for it, i.e. when change goes against the strategy.

Having a strategy (which isn’t complete responsiveness) allows one to judge each change request against that strategy. If the change request is coherent with the strategy then doing it makes sense. If not then there is a discussion to be had and there is probably a good case for rejecting the change.

This is not to rule out strategy changes, companies should pivot and change strategy sometimes. However, if one is constantly pivoting and abandoning strategies then it is a sign something is wrong. Strategy, by its very nature, should have some longevity.

Unfortunately, companies often lack strategy either completely or fail to communicate what the strategy is. One Town Hall does not mean everyone knows and follows the strategy. Strategy is embedded in every decision and action of the company leaders.

So, solution #5: fix the strategy.

When ever option you choose Objective Driven Agile can help.

5 options for when the boss changes the target before you reach the last one Read More »

Agile: Prix fixe or a la carte?

Agile, Agile Process, Xanpan / / /

small-andersen-jensen-Hk2eu3OODdg-unsplash-2020-08-11-14-40.jpg

Advert: September micro-workshops – spaced limited

User Stories Masterclass, Agile Estimation & Forecasting, Maximising value delivered

Early bird discounts & free tickets for unemployed/furloughed

Book with code Blog15 for 15% discount or get more details

“They don’t do Scrum so much as ScrumBut”

“We don’t do Scrum by the book, we changed it”

“We follow SAFe, except we’ve tailored it”

“We do a mix of agile methods”

“They call it agile but it isn’t really”

You’ve heard all these comments right? But have you noticed the tone of voice? The context in which they are said?

In my experience people say these things in a guilty way, what they mean to say is:

“They don’t do Scrum so much as Scrum but we don’t do it the way we should”

“We don’t do Scrum by the book, we changed it, we dropped the Scrum Master, we flex our sprints, …”

“We follow SAFe, except we’ve tailored it by dropping the agile coaches, the technical aspects and …”

“We do a mix of agile methods, we don’t do anything properly and its half baked”

“They call it agile but I don’t think they really understand what agile is”

Practitioners aren’t helped by advisors – coaches, trainers, consultants, what-not – who go around criticising teams for not following “Brand X Method” properly. But forget about them.

I want to rid you of your guilt. Nobody should feel guilty for not doing Scrum by the book, or SAFe the right way, or perfect Kanban.

Nobody, absolutely no person or organization I have ever met or heard of, does any method by the book.

After all “agile is a journey” and you might just be at a different point on the journey right now. To me agile is learning and there is more learning to be done – should we criticise people because the haven’t learned something?

All these methods offer a price fix menu: you pay a fixed price and you get a set menu.

In reality all agile methods should be seen as an à la carte menu: pick what you like, mix and match.

In fact, don’t just pick from the Scrum menu or the SAFe menu, pick across the menus: Scrum, XP, Kanban, SAFe, LeSS, DaD, whatever!

And do not feel guilty about it.

Do it.

My agile method, Xanpan explicitly says: mix and match. Xanpan lays out a model but it also says change things, find what works for you, steal from others.

The only thing you can get wrong in agile is doing things the same as you did 3 months ago. Keep experimenting, keep truing new ways, new ideas. If you improve then great, if not, roll-back and try something else.

In other words, keep learning.

Picture: Thanks to Andersen Jensen for the above photo on Unsplash.

Subscribe to my blog newsletter and download Project Myopia for Free

Agile: Prix fixe or a la carte? Read More »

Is Agile is obvious?

Agile, Agile Process / /

iStock-1174931869-2020-07-27-14-29-2.jpg

Now booking: September micro-workshops – spaced limited

User Stories Masterclass, Agile Estimation & Forecasting, Maximising value delivered

Early bird discounts & free tickets for unemployed/furloughed

Book with code Blog15 for 15% discount or get more details

Is Agile Obvious?

From time-to-time people say to me:

“Agile is obvious”

When I’m being honest it is kind of hard to argue with them, it is certainly “obvious” to me. But at the same time agile is not obvious, or rather, the opposite of agile is also obvious. For example,

Agile says: obviously, you don’t know the future so don’t plan and research too far into the future.
Non-agile thinking says: obviously, failure to plan is planning to fail, obviously you need a plan of action, you need to plan for the future.

Agile says: obviously, people work best when they are self-motivated and given a say in what they do.
Non-agile says: obviously, people are lazy and will do as little as possible, therefore someone needs to manage them.

Agile says: high quality makes it easier to change in the future, obviously.
Non-agile says: obviously, quality is an endless quest, there is no point in polishing something which isn’t important, 20% of the effort gives 80% of the reward so don’t do any more.

Agile emphasises the here and now, the soon, obviously requirements can be handled just-in-time, so live for today.
Non-agile says: if we don’t think about the future we will obviously duplicate work and incur additional costs.

And my own entry: obviously, software development as diseconomies of scale therefore optimise for lots of small. The opposite is equally obvious: economies of scale are what makes modern business – and the cloud – successful so exploit them

There are a number of obvious examples that go with that:

Agile says: obviously we should test every change and new feature by itself to avoid the complications of interacting changes.
Non-agile says: obviously full test runs are slow and expensive so bundle work together and test it on mass.

Both agile and not-agile are obvious. What you consider obvious depends on your starting point. Once you start thinking “agile” a lot of things become obvious. But if you are not thinking agile then, if you are thinking some other model, then the opposite is also obvious.

Some would term this “An Agile Mindset”. However I don’t want to do that, I find the idea of “an agile mindset” too nebulous. I also note that most of the people I hear talking about “an agile mindset” seem to clinging on to some piece of holy lore which I consider not very agile and they believe is totally agile (the project model and upfront requirements usually.)

Instead I find myself going back to Theory-X and Theory-Y. In general people fall into one camp or the other. If you, your philosophy on work and life, align with theory-Y then all the “agile is obvious” statements above are indeed obvious. Conversely, if you generally follow a theory-X philosophy then all the non-agile statements are obvious.

Perhaps surprisingly I find people can flip, and be flipped, from X to Y. What is more difficult is getting people to unlearn behaviours and actions which they acquired with a theory-X mindset. Even if some element of theory-Y (and agile) is now obvious people need help to learn the new way and let go of the old. Some people can do this by themselves, others need help – or at least help speeding up the change.

Yes, thats part of my job as an Agile Guide. Sometimes just talking (and reflecting on recent events) helps. Sometimes exercises (or process miniatures they are sometimes called) help. Sometimes it is by experiments, exposing people to others can help as well – so conferences, user groups.

Rarely do people change because they went on training and were lectured too, but good training incorporates talking, reflection, exercises, etc. Such training is less training and more about practicing the future.

Obviously, my training is like that: I aim to make my training courses a rehearsal for future actions. Actually, while I “sell” training I prefer to think of it as a rehearsal or kaikaku event – kaikaku events also call a “kaizen blitz”, they are big change events from the people who brought you kaizen, more on them another time.

So when someone I’ve worked with turns around and says “Agile is obvious” I take it as a sign of success. They no longer seem agile as something strange, it is normal, it is onbvious.

Subscribe to my blog newsletter and download Project Myopia for Free

Is Agile is obvious? Read More »

I’m an Agile Guide

Agile, Agile Process / /

aron-visuals-3jBU9TbKW7o-unsplash-2020-07-1-09-44.jpg

Anyone who keeps a keen eye on Linkedin might have noticed I recently changed my job description to Agile Guide. I feel “guide” more accurately reflects what I do: part coach, part advisor, part teacher.

I work as a consultant – a hired gun – but “consultant” is a very vague term and covers a lot of ground. Plus a lot of people in the technology industry have a very negative view of consultants. I’ve been known to share that view myself so while consultant might be an accurate description it was also vague and open to misinterpretation.

Many people consider me an Agile Coach, and I have worked as an agile coach. However – as I’ve written before – this too is a conflicted term. Most of us who go by the title “agile coach” like to talk about helping people help themselves, unlocking the individual, respecting the individual as the expert, and so on. I agree with a lot of that and I do it. Sometimes.

I also know what professional coaches do and I don’t feel I’m one of them. I have a lot of respect for real coaches. Such coaches put their own opinions second and I don’t. I am prepared to tell people the way I think it should be – they are free to ignore my advice but I’m prepared to say it.

Thats why I also regard myself as part teacher: not just direct training sessions (which I do) but also one-on-one and in small free format group sessions.

So what title should I use?

I’ve struggled with this for years. My epiphany came a few weeks ago: Agile guide. I help others to get more agile, coaching is one tool but so is direct advice and teaching.

Hadn’t others thought of “Agile Guide”. So I checked out LinkedIn myself. One person. Someone I respect, someone I call a friend: Woody Zuill.

I checked in with Woody and his thinking parallels mine.

So I’m an Agile Guide – I help individuals, teams and enterprises become more agile in a digital world.

Part coach, part advisor, part teacher, plus thinker and route finder. I use skills of coaching, teaching and consultancy.

Who knows, maybe, it will catch on. After all, as Woody pointed out, we have both changed the world already.

Subscribe to my blog newsletter and download Project Myopia for Free

I’m an Agile Guide Read More »

Time value profiles – a little tool with big implications

Agile, Agile Process, Business / /
TimeValueProfile-2020-06-23-15-06.jpg

The picture above is a time-value profile: it shows how value changes with time. It is a graphic illustration of cost of delay.

A fine wine might increase in value over time but most things – think product, project, feature or just story – decay with time. Having something today is worth more than having it next week.

I invented Time-Value profiles – although I’m happy to acknowledge Don Rienertsen’s influence. I’ve included time-value profiles in many presentations and courses (they are a key part of my value workshop) but oddly, while I’ve mentioned them in this blog before I’ve never described them. So here goes…

Imagine we want to build a feature for a product. Naturally we ask: “what is this worth?”

Money is the obvious way to measure value but strictly speaking money is not itself valuable – unless you happen to want small colourful pieces of paper or decorated lumps of metal. Money is a store of value. The value of money is not the money itself but what you can exchange the money for. And because money can be traded for a wide variety of things, which are themselves valuable, money is a useful medium for comparison and measurement.

So the question “what is this worth?” may be answered qualitatively (“a vaccine is valuable because it saves lives”) or quantitatively (“a vaccine is worth $10 trillion because it allows life to return to normal”). In order to compare competing opportunities and valuations, and in order to draw a graph, giving value a numerical quantity helps greatly.

A time-value profile shows quantitive value over time when value is measured numerically: maybe in hard money like dollars or yen, or an abstract measure like business points, wooden dollars or Atlantic shillings (I just invented that but it works).

The graph starts today: we say “If we had feature X today it would be worth 100,000 shillings”. Maybe it is worth 100,000 because that is what a customer would pay for it, or maybe because we could sell 100,000 units at 1 shilling each, or so on.

But we don’t have X today. “If we get feature X next month it will be worth 90,000 shillings.” One month delay, one month late to the customer, one month later on Amazon, costs 10,000 shillings.

“If feature X is 3 months away then it is worth less than 50,000 shillings.” And so on.

Now, the unit of value – dollars, francs, shillings, wood – is of little important. Sure $1,000,000 is very different to ₽1,000,000 (Russian roubles if you don’t know) but as long as you don’t mix currencies the actual currency is unimportant.

What is important is the shape of the curve and, especially, where abrupt changes happen. Look again at the graph above: between months two and three there is a sudden drop in value. That has scheduling implications.

Once you start to think about time-value profiles then it becomes obvious that value is a function of time and we need to understand what that function looks like for any given work – project, product, initiative, feature, story, just anything in fact.

It should also become clear that the question “how long will it take to build X” needs to be inverted: “how long have we got to build X?”, “how much of X could we build?” or “in the time we have what could create something to satisfy need X”

And then “how much of the available value can we capture?”. Having X might be worth 100,000 but having a half of X might still be worth 50,000 more than not having X.

As I’ve written before: to any given problem there are multiple solutions. Engineering is not about creating the best possible solution, it is about creating a solution within constraints – as my widgets exercise shows.

Add in capacity planning and a whole new paradigm of scheduling opens up.

Not that I wish to ignore costs – and effort estimates – but they are secondary, and the subject of another blog. I’ll write more about this, and perhaps put something into a workshop, in the meantime my value workshop is the best place to find out more.

Subscribe to my blog newsletter and download Project Myopia for Free

Time value profiles – a little tool with big implications Read More »