I am guilty of Agile training

Allan Kelly from Allan Kelly Associates

iStock_000010964034Medium-2018-01-11-17-17.jpg

Over Christmas I was thinking, reflecting, drinking…

Once upon a time I was asked by a manager to teach his team Agile so the team could become Agile. It went downhill from there…

I turned up at the clients offices to find a room of about 10 people. The manager wasn’t there – shame, he should be in the room to have the conversations with the team. In fact half the developers were missing. This company didn’t allow contractors to attend training sessions.

For agile introduction courses I always try and have a whole team, complete with decision makers, in the room. If you are addressing a specialist topic (say user stories or Cucumber) then its OK to have only the people the topic effects in the room. But I am talking about teams and processes, well I want everyone there!

We did a round of introductions and I learned that the manager, and other managers from the company, had been on a Scrum Master course and instructed the team to be Agile. Actually, the company had decided to be Agile and sent all the managers on Scrum Master courses.

So the omens were bad and then one of the developers said something to the effect:

“I don’t think Agile can help us. We have lots of work to do, we don’t have enough time, we are already struggling, there is masses of technical debt and we can’t cut quality any further. We need more time to do our work not less.”

What scum am I? – I pretend to be all nice but underneath I allow myself to be used as a tool to inflict agile pain on others. No wonder devs hate Agile.

My name is Allan and I provide Agile training and consulting services.
I am guilty of training teams in how to do Agile software development.
I am guilty of offering advice to individuals and teams in a directive format.
I have been employed by managers who want to make their teams agile against the will of the team members.
I have absented myself from teams for weeks, even months and failed to provide deep day-in-day-out coaching.

In my defence I plead mitigating circumstances.

One size does not fit all. The Agile Industrial Complex* has come up with one approach (training, certification and enforcement) and the Agile Hippies another (no-pressure, non-directive, content free, coaching).

I don’t fit into either group. Doing things differently can be lonely … still, I’ve had my successes.

I happen to believe that training team members in “Agile” can be effective. I believe training can help by:

  • Providing time for individuals to learn
  • Sharing the wisdom of one with others
  • Providing the opportunity for teams to learn together and create a shared understanding
  • Providing rehearsal space for teams to practice what the are doing, or hope to do
  • Providing a starting-point – a kick-off or a Kaikaku event – for a reset or change
  • and some other reasons which probably don’t come to mind right now

Yes, when I deliver training I’m teaching people to do something, but that is the least important thing. When I stand up at the start of a training session I image myself as a market stall holder. On my market stall are a set of tools and techniques which those in the room might like to buy: stand-up meetings, planning meeting, stories, velocity, and so on. My job is to both explain these tools and inspire my audience to try. I have a few hours to do that.

As much as I hate to say it, part of my job at this point is Sales. I have to sell Agile. In part I do that by painting a picture of how great the world might be with Agile. I like to think I also give the audience some tools for moving towards that world.

At the end of the time individuals get to decide which, if any, of the tools I’ve set out they want to use. Sometimes these are individual decisions, and sometimes individuals may not pick up any tools for months or years.

On other occasions – when I have time – I let the audience decide what they want to do. Mentally I see myself handing the floor over to the audience to decide what they want to do. In reality this is a team based exercise where the teams decide which tools they want to adopt.

If a team wants to say “No thank you” then so be it.

In my experience teams adopting Agile benefit greatly from having ongoing advice on how they are working. Managers benefit from understanding the team, understanding how their own role changes, and understanding how the organization needs to change over time.

Plus: you cannot cram everything a team need to know into a few hours training and it would be wrong todo so. You don’t want to overload people at the start. There are many things that are better talked about when people have had some experience.

Actually, I tend to believe that there are some parts of Agile which people can only learn first hand. They are – almost – incomprehensible, or unbelievable until one has experience. That is one of the reasons I think managers have trouble gasping agile in full: they are too far removed from the work to experience it first hand.

You see, I believe everyone engages in their own sense making, everyone learns to make sense and meaning in the world themselves. In so much as I have a named educational style it is constructivist. But my philosophy isn’t completely joined up and has some holes, I’m still learning myself.

When I do training I want to give people experiences help them learn. And that continues into the work place after the training.

So I also offer coaching, consulting, advice, call it what you will.

But I don’t like being with the team too much. I prefer to drop in. I believe that people, teams, need space to create their own understanding. If I was there they wouldn’t get that space, they wouldn’t have those experiences, and possibly they wouldn’t take responsibility for their own changes.

One of my fears about having a “Scrum Master” type figure attached to a team is that that person becomes the embodiment of the change. Do people really take responsibility and ownership if there is someone else there to do it?

I prefer to drop in occasionally. Talk to individuals, teams, talk about how things are going. Talk about their experience. Further their sense making process. Do some additional exercises if it helps. Run a retrospective.

And then I disappear. Leave things with them. Let them own it.

Whether technical skills are concerned – principally TDD – it is a little different. Because that is a skill that needs to be learned by practice. I don’t tend to do that so I usually involve one of my associates and they are sometimes embedded with a team for a longer period.

Similarly, I do sometimes become embedded in an organization. I can be there for several days a week for many weeks on end. That usually occurs when the organization is larger, or when the problems are bigger. Even then I want to leave as much control with the teams as I can.

On the one hand I’m a very bad person: I accept unwilling participants on my training courses and then don’t provide the day-to-day coaching that many advocate.

On the other hand: what I do works, I’ve seen it work. Sometimes one can benefit from being challenged, sometimes one needs to open ones mind to new ideas.

If I’m guilty of anything I’m guilty of having a recipe which works differently.

And that team I spoke of to start with?

One day two some people did not return: that was a win. They had worked out that it was not for them and they had taken control. That to me is a success.

Most people did return and at the end, the one who had told me Agile could do nothing for them saw that Agile offered hope. That hope was principally an approach to quality which was diametrically opposite to what he initially thought it was going to be and was probably, although I can’t be sure, the opposite of what his manager thought Agile meant.

It is entirely possible that had his manager been in the room to hear my quality message I’d have been thrown out there and then. And its just possible I might have given him food for thought.

But I will never know. I never heard from them again. Which was a shame, I’d love to know how the story ended. But that is something else: I don’t want to force anyone to work with me, I don’t lock people in. That causes me commercial headaches and sometimes I see people who stop taking the medicine before they are fully recovered but thats what happens when you allow people to exercise free will.

O, one more thing, ad advert, I’m available for hire, if you like the sound of any of that then check out my Agile Training or just get in touch.

*Tongue in cheek, before you flame me, I’ve exaggerated and pandered to stereotypes to effect and humour.

Read more? Subscribe to my newsletter – free updates on blog post, insights, events and offers.

The post I am guilty of Agile training appeared first on Allan Kelly Associates.

Conclusion: Who works on what – Comparative advantage part 3 of 3

Allan Kelly from Allan Kelly Associates

HeadacheiStock_000014496990Small-2017-12-21-17-24.jpg

In my last two posts – Who should work on what? part1 and part 2 – I’ve tried to apply the comparative advantage model from economics to the question of which software developer should work on what. The model has come up with two different answers:

  • If productivity (measured by quantity of features is the goal) then it probably makes sense for everyone to work on the product that they are comparatively most productive on (comparatively being the key word here.)
  • If value produced in the goal then it may well make sense for everyone to work on the most valuable features (or product) regardless of personal strengths.

Along the way I’ve highlighted a number of difficulties in applying this model:

  • If common resources are being used, or if doing one piece of work impacts another, then the model doesn’t work.
  • There is no consideration of time or urgency in the model. When urgency enters the picture then productivity may well suffer.
  • Over time things may change: backlogs will stratify and people will learn.
  • Operating this model in practice requires data which is usually unavailable and so getting the data would itself take time.

At this point it is tempting to throw ones hands up in the air and say: “We’ve learned nothing!”

But I don’t think so. I think there are lessons in here.

Right at the start of this I knew this was a difficult question to answer, trying to answer it has shown just how hard it is to get a definitive answer. There are still more assumptions which could be relaxed in this model and still more variables that could be added.

The model has also shown how important it is to have a sense of value. Not only between products but between features. That in turn demonstrates the importance of both valuing work in the backlog and regularly reviewing those valuations.

However, the first big lesson I think that needs learning here is: you have to know what your intention is.

You need to know what you are trying to optimise.
You need a strategy.

For example:

  • Do you want to maximise the quantity of features delivered?
  • Do you want to maximise the value delivered? (probably measured in money)
  • How much do you want to allow for urgent work? And to what standard are you going to hold those requests?
  • Do you want to promote specific knowledge (so one person can become more productive in one domain) or spread knowledge around (so many people can work on many different things)?

In many this is going to be a self-fulfilling prophecy, the result will be what you put in. That is, if people only work on one product then moving people between products will get harder and less productive. If people follow the value then value delivered will increase as people become more productive in the products with the higher value.

Knowing what your intention is should be the first step to formulating a strategy. And having a strategy is important because answering that question – “who should work on what?” – is hard.

To answer that question rationally one needs to create a model, a model far more complex than my model, then calculate every variable in the model – plus keep the variables up to date as they change. Then to apply that model to every work question which arises.

Phew.

Alternatively one can formulate a rule of thumb, a heuristic, a rough guideline, a “good enough” decision process. This might sound a bit amateurish but as Gerd Gigerenzer says in Risk Savvy:

“To make good decisions in an uncertain world, one has to ignore part of the information, which is exactly what rules of thumb do. Doing so can save time and effort and lead to better decisions.”

To build up such rules of thumb requires experience and reflection, something which might be described as intuition.

So to answer my original question in terms an economist would recognise: It depends.

Read more? Subscribe to my newsletter – free updates on blog post, insights, events and offers.

The post Conclusion: Who works on what – Comparative advantage part 3 of 3 appeared first on Allan Kelly Associates.

Adding value – Who works on what? – part 2 of comparative advantage

Allan Kelly from Allan Kelly Associates

Dollar000012188941XSmall-2017-12-20-10-51.jpg

In my previous post I tried to use the economic theory of comparative advantage to answer the question:

Who should work on what? or Shouldn’t every developer work on the software where they are most productive?

The economic model gave an answer but more importantly it provided a framework for answering the question. As I examined the assumptions behind the model it became clear there are many other considerations which deserve attention.

Perhaps the most important one is: value.

The basic economic model looks, perhaps naively, at quantity of goods produced. Really, one should consider the value of the goods produced. Not only did the model assume that every feature is the same size but it also assumed that all features have the same value.

Flipping back to the basic model, lets assume that each Bonds feature generates $10,000 in revenue while each Equities feature generates $20,000. Now the options are:

  1. Jenny and Joe both work on Equities, they produce seven features and generate $140,000 in revenue.
  2. Jenny and Joe both work on Bonds, they produce seven features and generate $70,000 in revenue.
  3. Joe works on Equities and Jenny on Bonds, the six features they produce generate $80,000 in revenue.
  4. Joe works on Bonds and Jenny on Equities, the eight features they produce generates $130,000 in revenue.

Clearly option #1 is the one to choose because it generates the greatest revenue even though Joe would be more productive if he were to work on Bonds. Adding value to the basic model changes the answer.

Now, again there is an assumption here: all features produce the same value. That is unlikely to be true.

Indeed, over time if no work is done on Bonds it would be reasonable to assume the value of the features would increase. Not that all features would increase in value but failure to do any would mean some of those in the backlog would become more valuable. In addition new requests might arise which may be more valuable than existing requests.

Further, while the value of Bonds features would be increasing the value of Equities might be falling. This follows another economic theory, the law of diminishing marginal utility. This law states that as one consumes more of a given product the added utility (i.e. value) derived from one more unit will be less and less.

So now we have exposed another assumption in the model: the model is static. The model does not consider the effects over time of how things change – I’ll come back to this in another context later too.

Over time the backlogs for both products will stratify, each will contain some items which are higher in value than average and some which are lower in value.

Lets suppose each product has its own backlog:

  • Equities backlog contains seven features with the values: $60,000, $54,000, $48,000, $42,000, $36,000, $30,000 and $24,000.
  • Bonds backlog contains another seven features with the values: $32,500, $10,000, $7,000, $6,000, $5,000, $4,000 and $,3000.

Now there are (at least) four options open:

  1. Equities: both Jenny and Joe work on the equities product. Together they will deliver seven features and a total of $294,000 of value.
  2. Bonds: both Jenny and Joe work on the bonds product. Together they will deliver seven features and a total of $67,500 of value.
  3. Specialise: Jenny does five equities features ($240,000) and Joe three bonds features ($49,500) delivering a total of eight features and $289,500.
  4. Value seeking: Jenny does her five equities features but Joe delivers one bonds feature, one equities feature and gets to go home early. In total they deliver six features and $302,500.

ValueDeliveredCompAdv-2017-12-20-10-51.jpg

The highest value option if #4, which delivers $13,000 more than if they specialise. That might seem counter intuitive: the option that delivers the most money delivers the least features. And again it shows deciding work in the absence of value can be misleading.

The second best option is for both to do Equities only, this delivers $8,500 more than specialisation. Adding value to the basic model isn’t a big change but it has changed the answer. When output was measured in features then specialisation looked to be the best option.

Returning to the question of the static model, there is one more assumption to relax: Learning. Economist J.K.Galbraith pointed out that the comparative advantage neglects to factor in learning, and I’ve done the same thing so far.

Assuming Joe specialises in Bonds and spends most of his time working there he will learn and in time he will become more productive. Suppose after a year he can produce 5 bonds features in the time he takes to produce 2 equities features – a 66% improvement.

Now how to the numbers stack up? What is the revenue maximising choice now?

And perhaps more importantly, how long would it take before Joe’s increased output paid for all the time he spent learning?

But, another what-if, what if Joe had specialised in Equities instead? He would now be more productive on a product with higher value features.

Again the question “Who should work on what?” needs to consider intent. Which product do you want Joe to learn? Which product is expected to have the highest value? Are you maximising value or quantity?

As usual, you can argue with my model and question my assumptions but I think that only demonstrates my point: these things need thinking about.

If you want you can continue relaxing the assumptions and do more what-if calculations – for example I’ve assumed Jenny and Joe cost the same. Nor have I factored in risk or cost-of-delay. This model can get a lot more complicated. I’ve also assumed that partially done features have no value at all, each week starts afresh and no work carries over.

Read more? Subscribe to my newsletter – free updates on blog post, insights, events and offers.

The post Adding value – Who works on what? – part 2 of comparative advantage appeared first on Allan Kelly Associates.

Who should work on what? – Comparative advantage part 1

Allan Kelly from Allan Kelly Associates

CoachiStock_000009613557XSmall-2017-12-19-17-55.jpg

Returning to my theme of numerical and economic analysis of software development, I’d like to address that old chestnut:

Shouldn’t every developer work on the software where they are most productive?

We can model this question using a bit of economic theory called Comparative advantage – which is also the economics that justifies free trade. However, while this model will give us an answer it also raises a number of questions which are outside the model. In this case the model gives us a structure for examining the issues rather than providing an answer.

By the way, this discussion is going to span two blog posts, or perhaps three.

Lets set up the model with a simple case. As before there are some assumptions needed, its when we examine these assumptions that things get really interesting.

Imagine a small trading desk. The desk invests in corporate bonds and equities. Jenny has been working for the desk for some years and has written two applications for trading imaginatively called Equities and Bonds. She wrote Equities after Bonds and prefers Equities and is more productive on Equities.

Measured in features Jenny can produce 5 new Equities features or 4 new Bonds features in one week. (We’ll assume that all features are the same size for now.)

The company hires a new developer, Joe. He is new to the code bases he can only produce 2 Equities features or 3 Bonds features a week. Thus Jenny is the most productive developer on both apps.

Features per week
Equities
Bonds
Jenny5
4
Joe2
3

Now comparative advantage theory tells us not to look at the total output of either party but at the relative output. In other words:

  • For Jenny every bond feature costs 1.2 equities features. Equally Jenny can produce one equities feature at a the cost of 0.8 (4/5ths) bonds features.
  • For Joe every bond feature costs 0.66 (2/3rds) equities features. Or, to put it the other way round, Joe’s equities features cost 1.5 bond features.

Looked at this way, relatively, Jenny is a better (more productive) Equities developers and Joe is the most productive Bonds developer.

Think about that.

During one week Jenny can produce more Bonds features than Joe but when measured in terms of the alternative Joe is the more productive Bonds developer. This is the important point. You might say “look at everyones individual strengthens.” Relatively Joe is better at Bonds.

Together Jenny and Joe could produce 7 features for either product. If Jenny works where she is stronger, Equities, and Joe works where he is strongest, Bonds, then together they will produce 8 features. If they both worked on their weaker product then they will only produce 6 features combined but four of those six would be Bonds features.

So, it seems the case solved: Everyone should specialise and work on the product where the individual is relatively strongest. Although this is not necessarily the same as “who is the best developer” for a product.

But… things are more complex. Now we have the model we can start changing the assumptions and see what happens.

First off, we could relaxed the assumption about all features being a different size. However this doesn’t make any real difference. It doesn’t matter how big a feature is, Jenny is always 20% more productive on Equities than Bonds and similarly Joe is 50% more productive on Bonds than Equities. Using different size features complicates the model without creating new insights.

Varying the size of features doesn’t change the integrity of the model but it does make a difference if we start to look at throughput and consider time.

So lets relax the time assumption. What happens if Joe is in the middle of a Bonds feature and another feature gets flagged up as urgent. Should Joe drop what he is doing and pick up the urgent Bond feature?

The model doesn’t answer this question. The model is only measuring output. If we are attempting to maximise output then changing work part way through the week only makes sense if the both pieces of work – the part done original and the urgent interrupt – can still be completed by the end of the week.

So one needs to ask: is the feature urgent enough to justify Joe halting his current work and doing the new feature? Then perhaps returning to his current work?

Possibly but in making one feature arrive faster another would be delayed. Statistically there is little difference because the differences cancel each other out. Which itself demonstrates how managing by numbers can be misleading.

And what is Joe couldn’t finish both pieces by the end of the week? Would it make sense to reduce overall efficiency to expedite some work?

What if Jenny becomes available, should she work on Bonds? Even though she is relatively less productive at Bonds and would thus delay even more Equities features?

These questions can be answered in many different ways but answering them depends on what you are trying to maximise. And lets also note that in real life the data is unlikely to be so clear cut

On average Joe takes two and a half days to complete an Equities feature while Jenny completes one Equities feature a day. On average Jenny can complete her current feature and a second one before Joe could. But it doesn’t take much to invalidate that answer, in particular if feature sizes vary things change.

What if Jenny is working on an over-sized feature? – well call it urgent #1. Suppose urgent #1 is twice as big as urgent #2 and she has just started #1. Jenny will take three days to finish both features. If goes starts urgent #2 he will have it finished in 2.5 days, during that time Jenny will have urgent #1 finished. Looked at this way it makes sense for Joe to work on the highest priority even if it takes him longer.

And what happens if Equities has three, or more, urgent features? Even with Joe working more slowly than Jenny all the urgent features will be delivered sooner if Joe works on Equities too. Again, total productivity would be impacted but what is more important: total productivity or rapid delivery?

If efficiency is your objective then all is well, simply understand the relative efficiency of individuals and do the maths. (Except of course, understanding the efficiency of any individual isn’t that straight forward.) Adding time dependent features complicates things, the comparative advantage model helps show the cost of urgency although it cannot answer the question.

It is entirely possible, even likely, that efficiency is not the only concern, it may not even be the primary concern. Rather the timeliness of feature delivery may be more important.

Specifically, I have assumed that all features are about the same effort but I’ve assumed they are also the same value. Efficiency has been measured as quantity of units produced is a poor measurement compared with efficiency in value delivered. I’ll turn my attention to value in the next blog.

But before I leave this post, one more assumption to surface.

In this model Joe and Jenny are completely independent. There work does not impact the other and they share no resources. What if they did?

What if both Joe and Jenny handed their completed work to the same Tester? Or they both needed use of s single test environment? Or their work needed to be bundled into a common release?

In such cases the shared resource – the tester, the environment, the release schedule – would become the constraint on productivity. This is getting towards Theory of Constraints space.

For Joe and Jenny to work at their most productive not only would that bottleneck need enough capacity to service them both it would actually need more capacity to cope with the variation and peak load (when Jenny and Joe delivered at the same time.)

Providing that extra capacity at the bottleneck would allow Joe and Jenny to work at their maximum throughput but would introduce waste because the extra capacity would sometimes be idle. To tackle that question one needs a far more complex theory: Queuing Theory – which I’ve discussed in previous posts, Utilisation and non-core team members and Kanban: efficient or predictable, you decide.

Read more? Subscribe to my newsletter – free updates on blog post, insights, events and offers.

The post Who should work on what? – Comparative advantage part 1 appeared first on Allan Kelly Associates.

I’m delighted – I’m in the 20 TOP Agile Blogs

Allan Kelly from Allan Kelly Associates

I’m delighted, this blog has been listed in the “20 TOP Agile Blogs for Scrum Masters (2017 edition)”.

I recognise most of the other bloggers in this list and frankly it is an honour to be classed with them.

(The news also gives me something to publish in this blog be because I’m real and truly stalled on next economics piece! Requires some analysis.)

The post I’m delighted – I’m in the 20 TOP Agile Blogs appeared first on Allan Kelly Associates.