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.
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.
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.
Testing isn’t, or shouldn’t be, about finding bugs. Type-1 Testing is about ensuring you can go to Type-2 Testing and get some useful feedback. Customer feedback is the really valuable stuff: does your product address the need you saw? Is there more to do? More value to be got? – and does the value delivered justify the cost of doing it?
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.
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.
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.
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.
“Gee, I really wish I could be that type of Product Owner.”
His comment made me smile. He nicely summarised much of the argument in Art of PO. The book makes a case for an expansive product owner – one with product management skills and business analysis skills; a product owner who looks to improve value over the short and long run, and for product owners with more customer empathy and marketing skills than code empathy and technical skills.
Many of the Product Owners I meet aren’t really owners of the product. Rather they are “Backlog Administrators” and as such the industry is creating another problem for itself.
Over the years the product owner role has been diluted, so many product owners are not really owners of their products. Instead their role is limited and constricted. They are judged on how many features they get the team deliver, whether those features are delivered by some date or whether they have met near term goals of doing the things customers – or internal users – are complaining about.
In other words the whole team is a feature factory: requests go in and success is measured by how many of those requests reach production.
Sure that is one way to run a team, and in some places that might be the “right” way to do it (a team dedicated to addressing production/customer issues perhaps.)
Unfortunately agile is prone to this failing because of the sprint-sprint-sprint nature of work. The things in front of you are obviously more valuable than the things that are not. The people shouting at you today obviously represent greater value than those who are sitting quietly asking nicely. And both groups can mask bigger insights and opportunities.
Hang on you say: Is this the same Allan who has argued against long term planning? And against analysis phases? The Allan who always argues for action this day?
Well, yes I am that Allan. And I agree that I regularly argue that teams should get started on coding and limit planning and analysis.
But that doesn’t mean I’m against these things, it only means I’m conscious of the diminishing returns of planning; and I know that what is technically possible frames not only the solution but the problem – because often we can’t conceive of the problem until we see how a solution might change things.
Teams need to watch out for the “bigger” questions. Teams need to take some time to thing long term. Time needs to be spent away from the hurly-burly of sprint-sprint-sprint to imagine a different world. Dis-economies of scale may rule but there still needs to be consideration of larger things, e.g. jobs to be done over user stories.
The responsibility rests with the Product Owner.
They own the product the way I own my house: I have to pay the mortgage and I have to change blow light bulbs but I also need to think: how long will the roof last? Will we build an extension? When will we rebuild the patio? And where am I going to put a car charging point when that day comes?
I don’t take those decisions in isolation, I don’t spend lots of time on them and I don’t let them get in the way of work today. But spending a little time thinking about them, and I may well leader on the discussion. Taking a little time to think through out how things might fit together (don’t do the roof until after the extension is built) has benefits.
And so many Product Owners aren’t doing that. Worse still their organizations don’t expect them to. Maybe they see an Architects doing that, or a Product Manager – or maybe nobody does.
The thing is: the Product Owner is the OWNER.
Managers and architects are hired and fired as needed. The buck stops with owners.
Many organizations have got this the wrong way round. The Product Owner role is diluted and individual Product Owners emasculated.
Advertisement: at the time of writing there are still a few tickets available for my online User Stories Masterclass beginning this Wednesday, 90 minutes each week for 4 weeks.
Last year I was coaching a team. One of the big problems the team faced was excessive work in progress – and tendency for developers to start new work when they hit a blockage. Eventually, with the help of the Product Owner who saw the problem too, we starved the work pipeline. The team actually ran out of work. We saw this as a great success. It had never happened before and meant we could really focus and prioritise work.
Unfortunately, this happened when the two of us were not instantly available. You can argue that we should have been instantly available. Or that people should have made more of an effort to contact us. Or that we should have left a secret stash of work to do. Or that the team should have self-organized to fix the problem. That is easy in retrospect but really, I still don’t see it as a problem.
A few hours without work? I see it as a momentous moment, the start of something great.
But that is not how others saw it. The team, the Product Manager, another Agile Coach on site, and anyone these people could tell were quick to tell us how awful it was: “the team ran out of work.” Word spread quickly that the team had run out of work. My name was dirt.
Doing good by one group isn’t always seen as good by others. When you work as an agile coach conflicts occur daily. But some are bigger and more persistent than others.
For most of the last 10 years I’ve mainly worked as a “drop in” coach (“light touch” I like to call it). I visit clients for a short period of time, talk about improvements, problems, solutions, give directive or non-directive coaching and don’t return for days or weeks. I’m not the same clients every week, maybe I drop in a few days a month and talk to people.
Last year was different, I spent almost all of it with one company, mostly embedded in one team as an official “Agile Coach.”
Comparing these two approaches to coaching has left me with a lot to reflect on. In particular I found a number of conflicts which troubled me, I’m not sure I ever worked these out and I’m sure others find the same things. So I’d like to share…
Responsible to the team, accountable to the organization
I was lucky, it was one of the team members who called me in but it was the bigger organization that was paying my fees. While I felt responsible to the team I was accountable to the organization.
That organization wanted things and expected me to deliver: they wanted a team which performed better (delivered more stuff and more value!) They wanted the team to share common practices and ceremonies with other teams.
For the organization I was the bringer of change to the team. But I could only do that if I was accepted by the team. That limited my ability to push through changes. Even if nobody else saw that conflict I felt it every day.
At one level team did want to change but they also wanted the organization to change and I had very little power there. Both sides, the team and the organization had no-go areas. More conflict.
The organization restricted my ability to do things I thought would improve the team. Things the team accepted would help: like spending money on training. So I was bearer of bad news to both sides: one side saw me asking, then arguing for money while the other saw me failing to deliver.
That organization also expected me to operate within the organization: join coaches meetings, sign up to shared coaching goals, complete team assessments, etc. None of these things were necessarily bad in their own right but it meant I had two masters: the team and the organization.
When push came to shove I prioritised the team but I know some coaches who prioritised the organization. I know some team members mistrusted their coaches because they believed their coach would put the organization first.
Honouring self-organization but creating change
So an agile team is self-organizing. That gives them the right to self-organise to work exactly as they do today. Self-organization gives them the right to not change anything – something I wrote about way back in Changing Software Development.
But, almost by definition, the (agile) coaches role is to bring about change, to help the team do better. Conflict is inevitable.
Sure you say “its a question of motivation … the coach needs to create the motivation to change and do better” and I would agree, but, even in creating that motivation one is creating change, one is intervening. Which brings us nicely to….
Leading without authority
Agile coaches lack authority – if they had authority they would be managers, I’ll blog about that in future. In a way not having authority is liberating, one can’t use the whip no matter how much one wants to! But it is also difficult.
The organization, and the coach, wants to create change but without authority even the smallest changes can become massive efforts. When the team is divided themselves, or even when one team member objects to implementing a change becomes like wading through treacle. That can be demoralising for the coach.
Yet a little authority can go a long way in pushing through change and overriding objections.
And on occasions I did reach for authority, but that creates a conflict within oneself as a coach: was I right to do it? am I honouring the team? the team members? am I creating a learned dependency?
Accepted while pushing the unpopular
Nowhere is that conflict clearer then when pushing through an unpopular change in the face of opposition – even minority opposition. As a coach one risks loosing future changes because, most change the coach “initiates” is done with the acceptance of the team, pushing through an unpopular change – even with a majority, even with leadership support – risks future acceptance.
One is constantly asking: how far can I take this team right now?
And: if I take them too far will they trust me tomorrow?
And, most of all: am I right to do this?
Hardly a day pasted last year when I didn’t agonise over these questions. And as I write this I imagine one of those teams members reading this and saying “Huh, and you got it wrong.”
Who gets the credit?
As a coach your job is to make others perform better, but really, only they can perform better. You can’t make them, you can only help them. The final decisions rest with them.
So who should get the credit? – surely it is them, they made the change, they did something different.
That creates an inner conflict. It also creates a conflict with the organization: why should they keep me employed? After all I didn’t make any difference, they did it.
We know the value of positive praise and acknowledgement, but when there is nobody to praise you, when the team don’t recognise the coaches role (which can be hard if the coach is doing a good job) then one becomes demoralised and that saps ones strength to carry on.
As people we need acknowledgement, as a human we all have needs. But the coaches role so often demands that we forego acknowledgement, praise and recognition.
Conflicts exists
This isn’t an exhaustive list of the conflicts I’ve encountered and hopefully as you read this you can see solutions – I can myself! But what I want to say is: these conflicts exist, I’m sure other coaches have them and even when there are solutions those solutions need to be applied.
Living with these conflicts can be hard, mentally and emotionally. Burnout happens to coaches.
And organizations get fed up with coaches who don’t deliver change, don’t turn up to non-team meetings, keep asking for money, don’t crack the whip or exceeds their (none existent) authority.
