Transparency instead of planned slack

railway-188025_1920

A fellow agile coach pointed out an interesting difference between the planning of traditional project management and agile methods, that I think deserves a blog post on its own: transparency.

When you plan traditionally and draw a Gantt chart, based on activities and allocated resources, you create the critical path – that is, the sequence of activities that must be finished on time in order for the final deadline of the project to be met. Most project managers know that this critical path, given the vague time estimates given and the sometimes poor understanding of the complex tasks at hand, will not hold. To counter this, they do one of two things:

  • They inflate the time estimates by some factor (by 2 or pi or some other arbitrary number)
  • They insert buffers into the critical path, to be used if needed

I can imagine that many project managers, especially for larger projects, do both.

The main issue that I have with this – and I say this not only as an agile coach but also as traditional project manager – is that it is not very transparent. The practice might need to be explained to the project team (”hey, we said it would take 2 days to do task x, why did you write a week?”) and it might be hard to motivate for the customer (”hey, why have you planned two weeks of doing nothing?”). There is also the factor of Parkinson’s law to consider: if you show everybody involved that a specific task will take 4 weeks to complete, it somehow always seem to take no less than 4 weeks.

Now, the precise (albeit faulty) planning of traditional project management does not exist in agile methods. Thankfully. I prefer the transparency of agile methods. We do not claim to know precisely how long something will take; instead we make a promise that we will work with a sustainable pace with the most prioritized features first. We do not plan in advance for one sprint of doing nothing, just in case. It’s done when it’s done. Also, after a few sprints we will be able to tell the customer when most of the things in the backlog – given that it is not re-prioritized too much – will be finished.

So, how come that many customers still request a traditional project management approach, with a fixed date, scope and cost? Sometimes, it is because they have to fulfill legal obligations or their own contracts, but most of the time I think it is that they simply do not know that there is a better, more transparent way. It is up to you, the reader, to enlighten them!

 

Waiting for the guy with the keyboard

Have you ever been in a meeting, where most of the people in the room stare at the screen, watching somebody typing stuff into a document or a form? It’s painfully slow, the funny guy in the room makes fun of the typist, some of the attendants starts fiddling with their mobile phones, another starts doodling on a piece of paper. All the energy that was supposed to be in the room is gone, and you start to wonder why you even bother with these meetings – after all, it’s only the guy with the keyboard that is doing any work.

How did you end up in this room? That’s bound to be different for different teams, but typically it has to do with the backlog. You decide, somewhere along the way, that it is too much work to keep both a digital copy and an analogue version of the backlog – and since it seems easier to just use the digital copy, you skip post-its and whiteboards. The result: you end up waiting for the guy with the keyboard.

How do you fix this?

The first step is to realize is that you have a problem. This can sometimes be hard, as people might not see what is going on. If you are the scrum master – and often end up as the guy with the keyboard that the rest of the team is waiting for – then it might be tough to see how the meeting is perceived by the rest of team. After all, for you, the meeting is probably quite stressful, right? But if you see blank stares, people start fiddling with their phones or correcting your spelling mistakes, take a hint!

The second step is to realize what the problem actually is. Surprisingly, many teams do not see this. Instead, they start blaming the process, Scrum or meetings in general. As a scrum master, you might be tempted to give in. You start to get that it might be quite boring to watch somebody type, and you start to excuse some parts of the team that probably will not contribute anyway. Or, you start to have the meetings less frequently.

And suddenly, your decision to save work by using only a digital tool has influenced the heart of your process!

There is a very simple solution. Go back to post-its and whiteboards! By all means, use a digital backlog tool, but be prepared to spend some time to prepare before every meeting (to print index cards or similar, and to bring post-its and pens) and to do some typing after every meeting. But trust me, having an engaged team that collaborates instead of waiting for the guy with the keyboard, is certainly worth it!

Requirements

During the last year or so, I have been caught up several times in discussion regarding ”agile requirements” or some similar catchy phrase. ”Christoffer”, they say, ”as an agile coach, what is your take on requirements? Should we have them? In what format? Who should write them? Where should we store them? And can we really start developing stuff without having them ready and approved?”

The problem with these questions is that there really is no straight, ”do-it-like-this-and-all-will-be-well” answer.

I’m writing this post in a hope to address these questions, and more.

Requirements are neither the paper nor the ink

Let’s start by clarifying an assumption, that is often not fully understood. A requirement is not a paragraph on a piece of paper in a binder on a dusty old book shelf. Neither is it a user story, entered onto the back of an index card on a Kanban board. Those are not requirements – those are the artifacts of the requirement.

A requirement represents knowledge of a need or want, presumably related – at least on some level – to a system that an agile team is (or will be) working on. You need that knowledge in order to develop something. You cannot develop something without requirements.

How do you extract this knowledge? That depends. Usually talking to the person(s) with the need/want helps. Workshops or surveys might also be viable tools.

Who extracts this knowledge? Someone with the required skill set, obviously – but you already knew that. Does that mean that you need a requirement analyst in your team? No, not necessarily. Ask the team if they are comfortable with doing the requirement analysis themselves. Perhaps they have both the technical skill and the communication skill required.

How do you document this knowledge? Again, that depends – it could be in the form of use cases, user stories, mock-ups, prototypes, or whatever suits that particular form of knowledge. Document only when there is a clear purpose with the resulting artifact. If everyone involves have a sufficient understanding of the requirements, there is typically no need to document anything.

The artifacts are still important

Here is a huge, potential pitfall. Because, typically, we believe that we have sufficient understanding of the requirements, while we actually do not. We believe that we have collected all possible knowledge of the need, while we in fact have not. Or, it could be that the need changed, as they often do.

One purpose of creating requirement artifacts is thus to create a common ground, as a help to capture this knowledge and use it as a basis for discussion. But be aware that the use case or user story or whatever you use will change many times – because that is, after all, one of the purposes.

And, obviously, agile methods to the rescue: create something small, based on a few of the requirements – as far as you understand them at this point in time – and then show the result to the one with the need. This will help everybody’s understanding of the actual need, and lets you adjust the end result as you go along.

A philosophical view

A requirement can be viewed as a part of a perfect – albeit constantly changing – knowledge about a need. The artifact used to capture this knowledge  (be it that dusty old binder or that index card) will therefore always be fundamentally flawed. There is no way that an artifact, however detailed, can capture all that knowledge. So let’s not try.

Instead, embrace the fact that requirements evolve and change. Thus, your requirements – in whatever way you choose to document them – will not be done until the need is gone. Let’s not wait with development until then.

Talk to your customer support

I just finished having one of the worst customer support experiences of my life, it feels like these experience are getting worse and worse across the board. But I have a thought about how they could be a lot better for both the companies and the customers if we just think about it a little different.

The customer support problem

I spent many years working customer support for a lot of different products and companies. And I can say, people who are angry about automated systems and outsourced employees for customer support don’t understand the problem fully.

Customer support is a money loser for any company and the larger the company gets, the bigger a problem it becomes.

Think about it this way: (Not real math)

  • You buy a product for 20$.
  • The companies profit margin on that product is 5$.
  • You have a problem with that product and call customer support to speak to a person.
  • A customer support person costs 10$ an hour.
  • You spend 31 minutes on the phone with the agent.
  • This company has just lost money by having you as a customer.

The company is actually in a very tough spot here and in a lot of ways it’s not their fault.

Are you willing to pay for support? Probably not…
Are you willing to pay more for the product? Probably not…

I am actually not angry at the company for this, I understand the problem and why it’s hard to solve.

How companies respond

Companies have to make money. Period.
You also want your product for as cheap as possible most of the time.
Customer support needs to be made to cost less.

This is why you end up in annoying automated systems, this is why you get outsourced representatives in cheap countries, this is why they try everything they can to make you use the website.

And actually most of the time this is a sensible approach. Customers support is 99.9% repetition (made up number), every customers support job I have ever had consists of solving the same 4-5 issues over and over again. Automated systems and cheap people reading scripts is a fairly effective means of solving this. Most people have a very smooth experience when they have the 99.9% issues. And if they don’t they might also make you go away and deal with it yourself, which is also a way of keeping their costs down.

At the end of the day it comes down to this, a company of any significant size works to make their customer support cheaper, because in order to get you to buy their product in the first place they need to keep the product at a competitive price.

A different approach

But what if we approached this problem slightly differently? What if instead of addressing the symptom, the high cost of support, we addressed the underlying root cause, the issues causing the support requests.

What if had the people who build the product, in software: development teams, spend time with the customer support? Or even spend time doing customer support?

I have worked with teams who took this approach in the past, and I can tell you that we see a very different outcome.

The development teams start understand where the problems in their product are, and they are able to attack them at the root cause. The 4-5 most common problems are the first to go.

  • They are able to identify the ones caused by errors and fix them, these calls stop coming in.
  • Then they learn about the calls that are caused by people not understanding the product, they make changes that make it easier to use, these calls stop coming in.
  • Sometimes they see the issues that are too costly to address the root cause of, but a lot of the time they are able to provide the support some tools to address them faster and easier, these calls now cost less to address.

A different way of looking at the problem.

In the first way the company tries to solve the ”customer support problem” they do make it cheaper, but they do so with a lot of upfront investment and ongoing costs.

They need to build and maintain that automated phone system.
Taking on an outsourced support partner is a huge initial and ongoing cost. They need to compare companies, negotiate terms, sign contracts, train people, pay people, deal with legal requirements of that country, quality control the partner is delivering on it’s obligations, the list goes on and on.

But with the root cause approach, every time they fix a problem they save these costs into the future and often for only the upfront investment.

It also provides a much better experience, which creates happy customers, which makes their brand better, which makes more people buy their products.

At the end of the day the root cause approach is better for everyone.

Not a silver bullet

This won’t fix everything, issues will still be there. Some people would still require support and be a higher cost. But maybe the companies support costs are low enough that they can see this as a cost worth taking? And if not, well, they still have a much better experience for the customers who had the original 4-5 issues.

 

What is Value?

Understanding Value

We talk a lot about value in the Agile world, but value is hard to define, and a lot of the time I feel organisations misunderstand the value they deliver.

Take one minute and try to answer this question. Write down your answer.
”What is the value your organisation delivers?”

Now, Take one minute and try to answer this question. Write down your answer.
”What is the value your Toyota delivers?”

Did you answer something like a car or other vehicle? If so, consider this, if tomorrow Toyota invented a personal transport system that could safely, cheaply and instantly transport you anywhere, would they lose all of their customers?

Of course not, because that’s a great product, but the main reason they would keep all their customers is because they would still be delivering the same value. The value that Toyota provides is not cars, it is transportation.

If they invented a transporter that could transport groups of 5 or less people and 1 cubic meter of luggage, a distance of 900 km, at a speed of 200 km/h before needing to be refuelled, with an entrainment system,  would they loose all their customers? Again, the answer is no, because they don’t just provide the value of transportation, they provide that value under certain constraints. They don’t cross oceans, they don’t transport huge amounts of cargo. They transport a certain thing, at a certain speed, at a certain cost, in a certain situation.

The car is not the value they provide, it is the mechanism by which they provide it.

But why does any of this matter?

Because getting too locked into the mechanism leaves you vulnerable to disruptive innovation, while at the same time stifling your own innovation. All a competitor needs to do if offer the same value with better constraints to hurt you.

Blockbuster declared bankruptcy in 2010 due to being unable to compete with companies like Netflix and Redbox.

But Blockbuster had every advantage in this fight. They already had access and agreements with the content distributors, they already had a huge and loyal customer base. If they had adapted quickly when they saw this change in the market they likely would have blown theses companies away.

Blockbuster didn’t provide the value of renting movies.

Many people don’t know that Netflix has been around since 1997, they provided DVD and Blu-Ray rentals via traditional post for a very long time. Netflix realised that the value they provided was not that of renting movies. They provided the value of entertainment, and by changing the mechanism and constraints by which that value was delivered they were able to take the world by storm.

Do you think it matters now?

Agile is about being able to adapt, not about being able to deliver features faster. Agile organisations need to focus on the value they deliver, not the mechanism by which they deliver it.

 

Calling it Kanban

I have been taking a liking to Kanban a lot the last couple of years, it’s feels to me like a natural evolution for most Agile people from Scrum. Don’t get me wrong, I like Scrum, and I find a lot of it’s practices to be great. And in many contexts perfectly well functioning.

But the last 3 teams I have worked with wanted to try Kanban, or so they said… I think there’s some kind of picture in peoples minds about what Kanban means, and I have rarely seen a team claim to be doing Kanban who I would say actually is.

While that is a little hard to say, because Kanban is so light weight, it does have a few rules, and limit Work in Process is one of them. The problem I am finding is, teams don’t actually want to do Kanban, what they want is to stop estimating, and stop committing. I’m not even saying I have an issue with this, I feel estimating is a precarious activity at best, and a wasteful and destructive one at worst. I don’t have a problem with the concept of no longer committing to Sprints, I think a flow based work cycle feels a lot more natural. But I think what most teams think they are getting with Kanban is what many developers dream about. ”Just leave us alone, it will be done when it’s done”. To me, this is not at all what Kanban is about…

Kanban focuses very heavily on delivery, that’s what I like about it!
Kanban focuses very heavily on collaboration, that’s what I like about it!
But they are right about one thing, Kanban doesn’t focus on estimation, it focuses on Lead and Cycle time, which I personally think is a much more effective system of gaining predictability.

I wouldn’t really take issue with this, except that I worry there are many work places that are starting to think of Kanban as a bad thing, because there teams are not really practising Kanban. So, what kind of things do I see?

They generally don’t have WIP limits, or ignore them, which is essential to the success in Kanban. When you don’t use WIP limits, you lose almost all the value, you just end up with a lot of work started and nothing finished. There’s no drive to unblock tasks, just keep pulling stuff in.

They don’t measure they cycle time and lead time, so they cannot have any predictability, and the question ”When will it be done” is answered with ”shrug… we are using Kanban”. This makes it not very popular with managers you can imagine 😉 When we have reached stability in Kanban, that’s a question we should be able to answer very easily ”7-9 days” type of thing. Also, with no metric, it makes it very hard to gauge improvement.

They generally just have a board that says To Do -> Doing -> Done, which is fine if that is indeed how your process works, but it basically never is, this is actually something I see in Scrum teams a lot as well. The board is a visualisation of you’re process, and as such it should represent how things work, not how you want them to work, and not just so you have a to do list. If you can’t see where things flow out from the point of ”code committed” then you don’t actually have any idea how much WIP you have. Also, you need to understand the inflow into the team. I am huge fan of visualising the refinement process in Kanban.

Example: https://leanpub.com/actionableagiletools/read#leanpub-auto-visualised-flow

The in and outflow are estential to success in Kanban. In order to get that predictability, you need to be able to have things arrive in a somewhat standard state, and have them leave with ease.

One of my favourite tools in Kanban or lean is the concept of explicit policies. Explicit policies are extremely helpful, not just in identifying discrepancies in the way the team works, but how to collaborate on fixing them.

So, a few quick thoughts on Kanban. You need WIP limits, otherwise you just have post-it notes on a wall.
You’re visualisation has to be representative of your process, otherwise, it’s just post it notes on a wall.
The other things can maybe wait a bit, but I think having a workshop about those early on is very valuable, and I will be doing a writeup soon about how I’ve started doing this.

I have several projects I organise in this way, running my company, the conference I organise, but those are a different context, and I don’t really need a Kanban approach in those projects.So, If you’re not doing this stuff, I don’t mind.

But please stop saying your doing Kanban and making organisations allergic to the word… It makes my job so much harder 😉