Coaching conflicts

Allan Kelly from Allan Kelly Associates

CoachingConflicts-2020-04-1-12-36.jpg

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.


Subscribe to my blog newsletter and download Project Myopia for Free

The post Coaching conflicts appeared first on Allan Kelly Associates.

Mission Impossible: the Product Owner

Allan Kelly from Allan Kelly Associates

SecretAgents-2019-10-27-18-53.jpg

Is the product owner role impossible to fill well?

Do we set product owners up to fail?

Have you ever worked with a really excellent product owner? Someone you would be eager to work with again?

The lack of really outstanding product owners isn’t the fault of the individuals. I think product owners are asked to do a difficult job and are not supported the way they should be. Worse still, in many organizations the role of product owners is misunderstood, they are seen as a type of delivery manager when in fact they are a type of product owner.

There questions have been on my mind for a while, next month I’m giving a new presentation I’m Oredev in Malmo – and which coincides perfectly with the publication of my new book The Art of Agile Product Ownership (funny that). So by way of preview…

I’ve long argued that product owners need four things in order to do the job well: skills, authority, legitimacy and time. Lets look at each in turn:

1. Skills: the kind of thing a product owner learns on a Certified Scrum Product Owner course are table stakes. Yes POs need to be able to write user stories, split stories, write acceptance criteria, understand agile and scrum, work with teams, plan a little and so on. While necessary such skills are not sufficient.

The bigger question is:

How does a product owner know what they need to know in order to do these things?
How do they know what customers want?
How do they know what will make a difference?

Product owners need more skills. Some POs deliver products which must sell in the market to customers who have a choice. Such POs need to be able to identify customers, segment customers and markets, interview customers, analyse data, understand markets, monitor competitors and much more. In short they need the skills of a product manager.

Other POs work with internal customers who don’t have a choice over what product they use, here the PO needs other skills: stakeholder identification and management, business and process analysis, user observation and interviewing, they need to be aware of company politics and able to manage up. In other words, they need the skills of a business analyst.

And all POs need knowledge of their product domain. Many POs are POs because they are in fact subject matter experts.

That is a lot of skills for any one person. How many product owners have the right skills mix? And if they don’t, how many of them get the training they need?

2. Authority: Product owners need at least the authority to walk in to a planning meeting and state the work they would like done in the next two weeks. They need the authority to set this work without being contradicted by some other person, they need the authority to visit customers and get their expenses paid without having to provide a lengthy explation every time.

3. Legitimacy: Product owners need to be seen as the right person to set the priorities. The right person to visit customers, the right person to agree plans and write roadmaps. They need to be seen as the right person by the organisation, by peers and, most importantly, by the development team.

Authority and legitimacy are closely related but they are not the same thing. While the product owner needs both the lack of either results in the same problem: people don’t take their work seriously and other people try to set the agenda on what to build.

Unfortunately Scrum contains a seldom noticed problem here: product owners are team members, they are peers; the team are self organising and are responsible for delivering the product. (There is an egalitarian ethos even if this is only Implicit.)

But Scrum sets the PO as the one, and only one, who can tell he team what to do.

There is a contradiction.

4. Time: Product owners need time to do their work – which is a lot, just read that skills list and think about what the PO should be doing. And don’t forget the PO is a human being who needs to sleep for seven or eight hours a night, may well have a family and a home to go to.

When does the product owner get to do all of this?

Leave aside the question of where you find such people, or whether our companies pay them enough and ask yourself: do product owners get the support they need from their companies and teams?

So often the PO ends up in conflict with the company about what will be built and when it will be delivered, and they end up in conflict with their team about… well much the same issues every planning meeting.

Think about it: do we ask too much from our product owners?

Do we set up product owners to fail?

I’d love to hear your opinions, comment on this post or drop me a note or leave a comment.

I’m going to leave you hanging here today. In the Oredev presentation I’ll try and suggest some solutions – and there are some in the Art of Product Ownership. (Last year I described one in The Product Owner refactored: the SPO/TPO model.)


Like this post? – Like to receive these posts by e-mail?

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

Check out my books – The Art of Agile Product OwnershipContinuous Digital and Project Myopia – and the Project Myopia audio edition

The post Mission Impossible: the Product Owner appeared first on Allan Kelly Associates.

The Product Owner Delta

Allan Kelly from Allan Kelly Associates

ValueAddPO-2019-07-1-08-19.jpg

As regular readers might know I’m working on a book called The Art of Product Ownership to be published by Apress later this year. One of the chapters is entitled “Why have a Product Owner” and a few days ago a bunch of ideas crystallised into this…

The aim of the Product Owner is to increase, even maximise, the business value delivered by the team as a whole. The Product Owner does not so much create value themselves as increase the value created by others.

Think of it like this: if the team randomly selected work to do and delivered it to customers then some value would be created. (For the moment I’ll ignore the scenario where that work detracts from the existing value.) The aim of the PO is to ensure the work done creates more value than a simple random selection. The greater the difference, or delta to use a mathematical term, between random selection and an informed selection the better.

The general hypothesis is that intelligent selection of work by a skilled Product Owner will result in both more value being delivered and an increasing delta between intelligent PO selected work and randomly selected work.

This difference the value added by a Product Owner. I like to call this difference the Product Owner Delta.

Now in real life work is seldom randomly so Product Owners are not competing against random selection. In some cases the alternative to a designated Product Owners is someone else: a senior developer, an architect, a manager or someone else. In such cases this person is taking on the Product Owner role. They may not have the title, the aptitude, the skills or official position but when work is selected by one person they are de facto the Product Owner.

In other cases the alternative to the PO might be selection by consensus on the team, or a sub-set of the team. Now it is entirely possible that such a group could outperform a single Product Owner in selecting work – especially is they have market and customer knowledge, some analysis skills, time to do the background research and so on. In some cases this works, for example think of a small start-up staffed by software developers creating software development tools.

However, in some cases selection by committee might be inferior to a random selection. Imagine a team which has never met a customer, argue about what to do, duck key decisions and never say No to any request. Its easy to image a dysfunctional selection committee.

There is more to increasing the Product Owner Delta than simply selecting the highest value items. Timely selection can help too. If decisions are not being made, or committees are spending a long time making decisions then having one person simply make those decisions in an efficient, timely, manner can increase the delta.

Time has another role. Because of cost-of-delay simply selecting the highest value items at any one point in time does not maximise the value delivered. Time Value Profiles (see Little Book of User Stories or my presentations on value “How much? When?”) expose this and need to be another tool in the Product Owners repertoire.

And of course, the Product Owner Delta is not the only reason to have a Product Owner in the team, but it is probably the main reason.


Like this post? – Like to receive these posts by e-mail?

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

Check out my latest books – Continuous Digital and Project Myopia – and the Project Myopia audio edition

The post The Product Owner Delta appeared first on Allan Kelly Associates.

The Agile virus

Allan Kelly from Allan Kelly Associates

iStock-952804252s-2019-06-6-15-18.jpg

The thing we call Agile is a virus. It gets into organizations and disrupts the normal course of business. In the early days, say before 2010, the corporate anti-bodies could be counted on to root out and destroy the virus before too much damage was done.

But sometimes the anti-bodies didn’t work. As the old maxim says “that which doesn’t kill me makes me stronger.” Sometimes agile made the organization stronger. Software development teams produced more stuff, they delivered on schedule, employees were happier, they had fewer bugs. In smaller, less established companies, the virus infected the company central nervous system, the operating system, and subverted it. Agile became natural.

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

The problem is, once the virus is inside the organization/organism it wants to grow and expand. It you don’t kill it then it will infect more and more of the body. Hence, software teams that contracted the agile virus and found it beneficial were allowed to survive but at the same time the virus spread downstream to the requirements process. Business Analysts and Product Managers had to become agile too.

Once you are infected you start to see the world through infected eyes. Over time the project model looked increasingly counter productive. Growth of the agile virus lead to the #NoProjects movement as the virus started to change management models.

Similar things are happening in the accounting and budgeting field. As the agile virus takes hold, and especially once the #NoProjects mutation kicks in, the annual budget process looks crazy. Agile creates a force for more change, agile demands Beyond Budgetting. Sure you can do agile in a traditional budget environment but the more you do the more contradictions you see and the more problems you encounter.

Then there is “human resources” – or to give it a more humane name personnel. Traditional staff recruitment, line management, individual bonuses and retention polices start to look wrong when you are infected by agile. Forces grow to change things, the more the organization resists the virus the more those infected by the virus grow discontent and the more unbalanced things become.

It carries on. The more successful agile is the greater the forces pressing for more change.

While companies don’t recognise these forces they grow. Hierarchical organizations and cultures (like banks) have this really bad. At the highest level they have come to recognise the advantages of the agile virus but to embrace it entirely is to destroy the essence of the organization.

Countless companies try to contain the agile virus but to do so they need to exert more and more energy. Really they need to kill it or embrace it and accept the mutation that is the virus.

Ultimately it all comes down to forces. The forces of status quo and traditional working (Theory X) on one side against the forces of twenty-first century digital enabled millennial workforce (Theory Y) on the other. Victory for the virus is inevitable but that does not mean every organization will be victorious or even survive. Those who can harness the virus fastest stand to gain the most.

The virus has been released, putting the genie back in the bottle is going to be hard – although the paradox of digital technology is that while the digital elite stand to gain the digital underclass (think Amazon warehouse workers) stand to lose.

All companies need to try to embrace the virus, to not do so would be to condemn oneself. But not all will succeed, in fact most will fail trying. Their failures will allow space for new comers to succeed, that is the beauty of capitalism. Unfortunately that space might be also be grabbed by the winners, the companies that have let the virus take over the organization.


Like this post? – Like to receive these posts by e-mail?

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

Check out my latest books – Continuous Digital and Project Myopia – and the Project Myopia audio edition

The post The Agile virus appeared first on Allan Kelly Associates.

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

Allan Kelly from Allan Kelly Associates

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

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

Officer: Well why don’t you move into more conventional areas of confectionery, … I mean look at this one, ‘cockroach cluster’, ‘anthrax ripple’. What’s this one, ‘spring surprise’?

Shop keeper: Ah – now, that’s our speciality – covered with darkest creamy chocolate. When you pop it in your mouth steel bolts spring out and plunge straight through-both cheeks.

That like Agile to me. In AgileLand everything is sweetness and light. Agile has all the answers. Everything works. Agile is utopia.

I’ve taught enough Agile Introduction courses to know this is so – and pushed ti too. There is no scenario I can’t fix in the classroom with the application of the right Agile principles, tool or mindset. And if I can’t… well in that case, Agile is helping you see the problem more clearly and you have to find your own solution.

Honestly, part of the appeal of Agile is that: Agile is a damn good story. Agile paints the picture of a better world, and so it should. Particularly when delivering an Agile training course I see my role as two fold:

  1. In-part enough information so that teams can actually try Agile
  2. Energise people to want to try it this way

Except, there are some dirty little secrets in the Agile world which do’t fit with this picture.

First up is Micromanagement (#1).

As I said in Devs Hate Agile, the Agile toolkit can be used for good or evil. If someone wants to be a micro-manager par-excellence then Agile – and particularly Scrum – make a great toolkit for micro-management too.

The intention behind the Agile/Scrum approach is to give those who do the work the tools and approaches to take control of their own work. When they do so then great things happen – the workers control the means of production! However those same tools can be used by very effectively by those who would control the workers.

What micromanager would not want every team member standing up to justify themselves at 9am each morning?
Surely a micromanager would want working software at every opportunity? – and if you fail to deliver working software then…

In part this is because Agile is a great tool for apportioning blame (#2). When builds fail you know who did the last check-in. when tests fail you know who broke it, when cards don’t move on a board, sorry I mean Jira, then the powerful can hone in on those not pulling their weight.

Kanban is even better than Scrum here. I remember one Project Manager who used the Kanban board (26 columns!) we constructed to demonstrate why everybody apart from him was slowing work down. Try as I might I couldn’t get him to see each of problem to be worked on. To be fair to him, he was the product of a system where almost every step was undertaken by a sub-contractor, he had no power to change or reward sub-contractors, only to whip them.

Both these points illustrate the second dirty little secret: you don’t need to do everything (#3).

Simply holding stand-up meetings and end-of-iteration activities is a massive improvement for some teams.

Developers who adopt Test Driven Development will produce fewer bugs, waste less time in the debugger, and the testers who come after them will spend less time reporting bugs. Thus fewer bugs will need fixing and schedules will improve.

A Kanban board with WIP limits will improve workflow even if you do nothing else.

Yes, if you do every part of Scrum things will get a lot better.

And if you do every part of XP the total benefit will be better than the sum of the parts.

Part of the genius of Agile is that it can be implemented piecemeal. But that also means organizations and teams can stop. I’ve seen this a number of time: I introduce a bit of Agile, the immediate pain is relieved and the company looses the will to go further and improve more.

After all, who am I but an external consultant to tell them they could do better?

Once the pain if gone then the need to change goes too.

Now some dirty little secrets are being exposed. Most readers will know I have been active in exposing the dirty secret of Agile Project Management: the idea that Agile and the project model (aka project management) can work together.

Sure they can work together but… why? what is the point? Why go to the trouble of integrating Agile and Project Management?

Once you start working Agile the project model looks absurd. Hence #NoProjects – and why so many people have arrived at the same conclusion about projects independently.

In fact, it goes further than that. Companies that introduce full blown Scrum – including self-organizing teams – risk destroying themselves. In traditional, top-down, hierarchical companies Agile and self-organizing teams must be contained otherwise it will destroy the whole hierarchy. That is why banks struggle with Agile, the chocolate on the outside is really nice but sooner or later what they are eating runs up against what they are.

Finally, you might notice that in this post – and indeed in many of my other post – I don’t agree with other Agile advocates. Go and read Jeff Sutherland (I don’t agree over self-organization), Mike Cohn (I don’t agree over stories and points), Keith Richards (not the rolling stone, the APM man, I don’t agree over projects), Jim Coplien (he doesn’t agree over TDD), Joanna Rothman (we don’t agree on stories), Dan North (we don’t agree on teams) and just about anyone else and you’ll find I don’t agree 100% with anyone.

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

But the thing is: none of these people agree with each other.

Everyone in the Agile communities interprets it slightly differently.

The final dirty secret of Agile is: the experts don’t agree – there is no one true way (#5).

I feel sorry for new comers to Agile who expect to read the one-true-way but I’m also saw none of us “gurus” would want to any other way because we want variety and experimentation. And perhaps that is why one-size-fits all Agile scaling is always doomed.

Frog image credit: Argentine Horned Frog by Grosscha on WikiMediaCommons under CCL ASA 4.0 license


Like this post? – Like to receive these posts by e-mail?

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

 Check out my latest books – Continuous Digital and Project Myopia – and the Project Myopia audio edition

The post Agile is a Crunchy Nut Frog (and some dirty secrets) appeared first on Allan Kelly Associates.

Story Generators

Allan Kelly from Allan Kelly Associates

iStock-913773630small-2019-03-22-17-35.jpg

Recently I’ve been looking again at Jobs to be Done and OKRs (Objectives and Key Results). I increasingly see them as story generators and a potential solution to the tyranny of the backlog I described last time.

When I first looked at Jobs to be Done (and OKRs actually) I wondered if they constituted a fourth, top, level on top of Epics, Stories and Tasks. I’ve long argued against having more than three levels of things to do (or requirements as we used to call them.) There are big meaningful things to do (stories), really big things which we don’t as yet understand but look really valuable (epics) and the immediate small things to do right now (tasks).

Actually, I’d rather think most things can be dealt with by two levels and one level is the even better. So adding a fourth “even bigger” thing on top of Epics just felt wrong. Technologists (like myself) have a tendency to map everything into hierarchies; inverted trees with fractal like branches. But not everything is, or should be, a hierarchy, mapping the world into a tree like structure can add complications.

Unlike stories (and epics and tasks) Jobs to be Done don’t really lend themselves to the transactional “Done”. While you could put a Job all the way to Done on your Kanban board and track it from “To do” to “Done” in reality the customer job still exists. Sure you’ve improved it but you can improve it again – another example of Stable Intermediate Forms. This seems to be the great potential of Jobs to be Done, they keep on giving: as much as you improve your product to help with the job you can still improve it some more.

So each time you analyse the Job to be Done you should be able to find more stories to deliver to improve it. Hence the Job to be Done is not a “story” to do, it is a Story Generator. Every time you look at the job to be done you find more stories, every time you examine the result of the latest improvement you find more stories. The job will never be done. Some might see that as a bad thing but that also means the job presents a stable focus for ongoing work.

The same might be true of OKRs but in a slightly different way. Because the objective is reviewed periodically – every quarter or so – it lacks the continuity of Jobs to be Done but perhaps allows the team to switch targets, maybe it is stable enough.

The key results may well be stories in their own right, or they may be things which lead to stories. Either way one can expect some key results to be achieved and marked as done regularly. As they fall they are either replaced by new key results building towards the objective (which themselves lead to stories) or new key results are added for new objectives.

I’m sure there are other story generators out there but the key thing for me is not the mechanism but the existence of the generator. Once you have a story generator you do not need a big backlog of things to do. The generator will replenish the backlog whenever you need more stories – either because you have done them or the value has fallen.

Using a generator removes the need to have a big backlog which removes the tyranny of the backlog. The team are now free(r) to concentrate on delivering value towards their objective.

Finally, I wonder if anyone has used both OKRs and Jobs to be Done together? Right now they feel like alternative generators to me, having both seems like a bit like overkill. Although I accept that maybe OKRs are more corporate and Jobs to be Done are more product focused. Anyone got any experience using them together?


Like this post? – Like to receive these posts by e-mail?

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

Check out my latest books – Continuous Digital and Project Myopia – and now Project Myopia audio edition

The post Story Generators appeared first on Allan Kelly Associates.

The power of small declines

Allan Kelly from Allan Kelly Associates

DeclineGraph-2018-12-13-10-41.jpg

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

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

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

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

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

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

Why might this happen? – lots of reasons

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

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

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

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

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

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

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

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

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

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

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

The post The power of small declines appeared first on Allan Kelly Associates.

NoNo workshop in London

Allan Kelly from Allan Kelly Associates

Smaller cartons of software are cheaper and less risky
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.”

More details and booking at the Learning Connexions website.

The post NoNo workshop in London appeared first on Allan Kelly Associates.

Money talks: A tale of two change programs

Allan Kelly from Allan Kelly Associates

iStock_000005509580Small-2018-11-21-13-12.jpg

Like many in the agile community – or what sometimes gets called the agile industrial complex – I am all for piecemeal adoption, small scale before large scale, get good at doing stuff then expand it out… – what else would you expect from Mr Diseconomies of Scale?

The “start small” and grow might even be regarded as the canonical approach to agile implementation. But from time to time I run across something that makes me wonder…

Four or five years back I got involved with an agile transformation programme at a large financial institution, not a bank, more of a mass market asset manager. I was attached to a small team trying to make the whole company agile.

The coaches viewed themselves as a gorilla movement, changing the organization from within. They had some success, there was a bunch of stuff the agile teams and the coaches were doing wrong but that is another story. This was a licensed insurrection.

As is often the case, this team found it lacked the ability to ask the big questions and get people outside the team (often the higher ups) to engage or change themselves. The organization wanted agile down in the engine room – at the code face – but they didn’t want to rethink how they set requirements and approached projects. The whole organization was chronically project driven, obsessed with long term planning and offshore development. Economies of scale thinking ran riot.

Because the agile change was at the team level the product owners lacked authority to make real decisions – like not delivering functionality. Yes the organization wanted to “be agile” but the management cadre didn’t see any need to change their own behaviour.

One day I met two men who ran the company’s “Software Process Group.” They were guardians of the formal process and “working practices”. My immediate reaction was that they wanted to kill agile and stick with ISO-9000, PRINCE2, CMMI and certified approaches. They scared me. But actually they were very clued up. They got agile. They saw it was better than the current process.

These two had no role in the agile transformation, their role was to ensure the company kept its CMMI level two certification. This was really important to the company because this allowed the company to do business. They told me a story…

During the previous 20 years the company had grown large, very large, by buying up competitors and companies in related markets. These companies had been thrown together and costs stripped out. One day the financial regulator came to the company and said:

“We have been examining your IT functions. They are not fit for purpose. If you don’t fix it within 12 months we are going to withdraw your license to do business.”

Shit hitting the fan doesn’t come much bigger than this.

The company went to IBM and said “Help! – Fix it – we’ll will pay anything.”

IBM flooded the company with people. IBM imposed a process – a traditional CMMI compliant process. IBM changed the company, not just the programmers but everything. The company did as IBM told them.

And don’t imagine it was cheap. I bet that the change and IBM fees were on the agenda at every board meeting during that period. The men I had met were the remnants of that programme, they worked for the company not IBM, their job was to ensure the company maintained accreditation and the financial regulator wouldn’t have cause to come back.

Now contrast this with the piecemeal, small scale, bottom-up change that us agile folk are so fond of. Time and time again we get stuck: “the business won’t change”, “we can’t get access to the senior people”, “existing processes and expectations are unassailable”, “projects are killing us” and so on.

I’m sure IBM faced many of those same problems but they had one big advantage: They were expensive.

OK, they had a second: the loss of license would destroy the client company. But when threatened people often respond by sticking with that they know so maybe it was a double edged sword.

Because IBM were expensive they had access to anyone they wanted access too. Because they were expensive they had authority. And if someone didn’t want to make the changes IBM suggested then IBM could simply ask the next person up.

Once again money is information: by spending lots of money with IBM the company was signalling it really wanted these changes to happen.

Agile changers may not like big change, they may point to the inherent risks, they may point that use of authority conflicts with self-organization, they may understand that diseconomies of scale rule and they may point to a bunch of other risks.

But they should also note one clear advantage: a big expensive change programme brings authority all of its own.

The post Money talks: A tale of two change programs appeared first on Allan Kelly Associates.

Agile won the war but lost the peace

Allan Kelly from Allan Kelly Associates

iStock-856693018Medium-2018-11-8-16-53.jpg

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

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

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

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

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

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

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

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

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

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

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

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

But agile lost the peace.

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

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

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

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

The post Agile won the war but lost the peace appeared first on Allan Kelly Associates.