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!

 

The deceptive role description

todo-list-297195_1280

The request

In some organizations, it is not uncommon for people to ask for a role description, i.e. some piece of text that describes what they or their colleagues are supposed to be doing. The reason for the request varies, but typically goes in one of four categories:

  • The person asking is unsure of what he/she is supposed to be doing
  • The person asking is building an argument towards a co-worker, that is believed to be doing the wrong things
  • The person asking want it to argue for a raise with his/her boss.
  • The person asking is recruiting for a specific role

The response

If you respond to the request by quickly emailing a document, chances are that you are doing the people involved a disservice. Here’s why: there is nothing wrong with role descriptions, except that they are deceptive. They give the illusion of clarifying mandate, responsibilities and tasks, but in reality no piece of paper will give you anything but perhaps a starting point for a discussion.

In my experience, no two people are alike, no two people will interpret a role the same, no matter if they both follow the same role description to the letter. And rarely, if ever, does a role description cover everything that you want a person to do, and you certainly never want a person to be limited what is in the role description.

(Sometimes, the person asking is just being difficult, because they do not like their new role. In this case, the response ”I’ll get you a role description, but only if you promise to do everything in it” gives interesting results.)

In all categories listed above, what the requester really need is support in their specific situation, not a document that was written by some consultant, years ago, for a different organization, in another context, with a different goal. If you, or somebody else, can give this support, then great. Otherwise, there is a trick outlined in the last paragraph.

The solution

Here’s the point: if you honestly want to know what you are supposed to be doing, ask! Ask your peers in the same role as you, your colleagues, your team members, your boss, your customer. They surely have an idea. Dare to ask for feedback on how you are doing, and have a discussion with people you trust about your priorities. And suddenly – and all without a role description – I’m sure you will find yourself doing things, good things, that will help both you and your organization to new heights.

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 😉

The Product Vision

telescope-122960_1920

Since I wrote the last post – about the ever so common product owner-team gap – I’ve been considering the issue and how to solve it, from what seems to be every angle.

Perhaps the solution is simply, as I stated in the original article, to point out the problem to the involved parties, and make them work on closing the gap by approaching their counterpart. But recently, I’ve come to the conclusion that there might be another problem, just beneath the surface.

When analyzing the problem more closely, the true issue is almost never that there is a gap between the product owner and the team. Instead, the problem is that the product owner and the team does not share a common vision of the product.

The product vision is a goal, a common idea, of what the product will be in the future. It might exist in the form of a prototype, design sketches, requirement documents or (perhaps more common) simply as a more or less vague idea in the mind of the product owner. Now, if the team does not understand, or share, this product vision with the product owner, it is not that strange if the gap occurs. The product owner and the team will inevitable talk about different things, mean different things, because they have have no common ground. So, the first step is thus to establish such a common ground. One way of doing this, is to simply gather the team and the product owner in a room, and workshop until a common understanding of the product vision is reached.

Now, what I have found is that the much more common reason for the product owner gap, is that there is no product vision.  There might several reasons for this, but the most common one is that the product owner considers the needs of the stake holders, but does not consider how the changes will work together as a whole. This is, instead, left to the team to figure out. While this might work with a brilliant, dedicated team, it is almost assured that this will fail with a team in a startup phase, or a team that is suffering from some dysfunction.

In this case, it is important for everyone to understand that there will be no great product, unless there is a product vision. Be it implicit or explicit – it must exist – how else can the product owner assure that the right stuff is being built?

Do you recognize this pattern? Please let me know in the comments.

The product owner – team gap

Product owner team gap

A fully functional, high-performing scrum team includes both a product owner, a scrum master and a development team. The product owner’s formal responsibilities are prioritization and funneling requests from the outside world into the product backlog, while the team and the scrum master grabs work from the backlog and turns it into potentially shippable increments.

However, this is not the full story. Many product owners struggles with the many responsibilities that comes with the role, and therefore – sometimes as a desperate measure to prioritize among their many business activities – delegate a lot of the responsibility to the team and to the scrum master. On the other hand, many teams expect all contacts with the outside world to occur through the product owner,  or that they do not need to worry about managing the product backlog (since that is the responsibility of the product owner).

When the product owner delegates too much to the team, it might leave the team feeling abandoned by the product owner. A good team might seize the opportunity to go ahead a prioritize the backlog themselves – which might work, but also might lead to suboptimal end results. A more challenged team might loose their agile practices altogether. After all, what point is there in having a demo, if nobody cares about the results?

Similarily, when the product owner is unable to fulfil the team’s expectations, the product owner might be frustrated by the teams inability to take the initiative. From the product owner’s point of view, it might seem that the team is waiting around to be spoon-fed ready-to-go-tasks.

I think of this as the product owner-team gap. That is, there is a gap between the decision level, where the product owner has the majority of the responsibility, and the operative level, where the teams technical expertise is required to refine and execute work.

This gap might seem superficial, because in no overview of Scrum there is such a gap. In reality, though, it almost always exists, at least at first.

One of the key ingredients in getting the entire scrum team to a higher level of performance, is to make sure that this gap is bridged. Either the product owner understands the importance of taking a step towards the operative level, and makes an effort not only to be present at refinement meetings, sprint planning meetings and so on, but also to truly understand the teams work environment and the teams needs and wants. Or, the team takes a step up to the decision level, and helps the product owner understand and prioritize the backlog. This means – among other things – that the team must make an effort to explain the contents of technical work on a level that the product owner can understand and relate to. The team must also explain why they need a product owner present in their day-to-day work.

For either of these solutions to work, it requires patience,  good understanding of agile values and preferrably the presence of an agile coach. Also, a key to success is interest in making it work. Without that, as usual, all approaches will fail.