Tag Archives: lean

Stuffed with tasks

Kanban and Lean Software Development, ,

This blog is almost exactly the answer I made to a question from pm.sepent0x on pm.stackexchange.com (Best way to divide & assign development work on projects?)

Pent0x is a developer who is being assigned many tasks from various projects at the same time. He does not know how to complete his assigned work in time, particularly when he also has to deal with issues that arise in addition of his regular work. He really believe that there must be a better way to assign tasks than what he experiences – endures.

There is no Holy Grail answer to this question, but let me give you some food for thought:

Issues happen

This is not a real eye-opener, is it? Bugs, issues, defects or whatever you call them should not jeopardize the schedule, at least to a certain extend. Although rework is a loss of time, it happens in every (software) project and should be considered since the beginning. If every people – who are called “resources” in such a case – is stuffed with tasks at 100% capacity, any issue will make it 120%.

My advise here is to identify classes of service based on urgency and criticity, and allow some slack in the system so that the team can expedite important bugs when they happen without killing the schedule.

“[I]ssues […] you can’t always predict a time frame for”

So what? You cannot crystal-ball predict how long it will take to solve a particular issue : is this really going to change the fact that the issue must be solved? If so then maybe this issue was not that important after all, and some other tasks could have had higher priority.

When running too many projects at the same time, none of them will meet the schedule.

Running too many projects at the same time produces at least two effects:

  • People have to switch between projects. Switching from one task to another is hard. Switching between projects is harder by an order of magnitude. When switching, people lose focus, experience difficulties reminding about the context and basically lose time.
  • People have to deal with too many things at once. The human brain is not multitask. When someone has to work on several work items at the same time, the quality of his work will drop significantly. Not a surprise that making phone calls when driving (at least in France) or chatting with your neighbor in a classroom are forbidden.

My advise here is to limit the amount of work in progress at every level of granularity.

Pushing work

[…]and so most of my tasks that keep getting assigned to me start stacking on top of each other

Giving – pushing – work to someone is easy. When we tell someone to work on a specific task, we can then come back later and blame her for not having finished the assigned work, which is pretty comfortable, isn’t it? But by doing so we blind ourselves : we ignore systemic problems and transform them into personal problems. The PM won’t think “We have a problem with our process : we start too many things without finishing them…” but “This guy is really slow : look at how late he is“.

So my last advise will be : implement a pull system and visualize work. A pull system will make sure that the team “stops starting and starts finishing” (a Kanban adage, I can’t remember who said it first) while visualizing work might trigger some improvements in the way work is processed (“Don’t tell me that we currently have 26 work items at the same time for only 4 people?!”).

How long will we fail?

#NoEstimates, ,

I was talking with a new member of my team about a new project’s first feature. The feature is kind of a prototype for the application, a full-stack slice of the application meant to get quick a feedback on some initial design choices. When my colleague asked me:

How long will it last?

I immediately answered:

I don’t know : how long do you think we will have to go back on our choices before we eventually get to a satisfying design? When will we be satisfied of our best bad idea?

I can’t remember the last time I have seen a developer satisfied of its first draft, or an architecture being satisfying right from the start.

The work of a developer is rather similar to the work of a writer. I recently heard French writer Bernard Werber saying that, before he can send a new book to its publisher, he must rewrite it entirely several times. He was saying that he rewrites the book without using previous versions : he remembers about interesting parts and can easily get rid of less interesting ones.

Developers follow the same approach : the first thing is to find an answer to a specific problem, which is telling a story in a way. When the problem is solved, which might not be done with the first try, developers deal with the style : is the story a little bit too long? is it easily readable? are all these characters really necessary? should we split this paragraph? etc. This is called refactoring.

So if we ask Bernard Werber to tell us how long it will last to write his next book, he will certainly answer that he cannot answer. At best he could try a pragmatic approach : “For 8 of my 10 last books I had to rewrite them at least 15 times but never more than 18 times. Moreover writing a book once never takes more than X months. We could then estimate that there is 80 % chance that I finish my next book between FOO and BAR.” Who would blame him?

Nevertheless nowadays people keep asking estimates to knowledge workers – developers. It might be story points, ideal days, or even month/man or real days. The developer must hazard himself into the dark art of crystal ball divination : he must first analyse the feature, estimate the development time of what he just imagined, predict how long it will take to get to a satisfying result – which may mean finding a better idea and implement it, predict interruptions, waiting times, bugs, perform a risk analysis, etc. It would be easier to roll a pair of dice.

I think this is the main difference between Lean and Agile Software Development : pragmatism. Making random estimates is pure waste of time, and taking decisions based on those estimates (alone) is a major risk for the project. That’s why leanists and kanbanists prefer statistical approaches and modelisations : taking decisions based on facts. Thus I should have answered something like:

Before you get in the team, the cycle time of 85% of the features was less than 8 days, and less that 12 days for 95% of them. In my experience, I can tell you that the first feature of a project is always longer than any other. Now that you are in the team, considering the fact that we must teach you how we work, we can say for sure that it’ll be even longer than usual. Nevertheless, it is impossible – I mean statistically – that it takes more than 14 days.


This post is an adaptation of http://matthiasjouan.fr/combien-de-fois-penses-tu-te-tromper/

Slack Time : A try-learn-improve catalyst

Kanban and Lean Software Development, Uncategorized, , , , ,
kaizen

In my opinion, a software development actor – by actor I mean a company, a team, a PM, a developer, the PM’s dog – starts being Agile and thinking Agile when he realizes two things. First that the customer – or product owner – cannot detail all the requirements and all the features at the beginning of the project, and will probably change his mind anyway. Second that software development is a creation activity (craftsmanship), not an engineering activity.

Once he realizes that, he begins to feel confident in the fact that some things cannot be streamlined and plan-driven from the start, that there is no such thing as a recipe to make a good software, and that both the requirement part and the pure development part are somehow made of try-failure-try-success cycles. So we try and experiment. If you are developer you might want to try and build your own set of best-practices that fit your current situation. If you are a project manager you might want to try to improve the process by making some small adjustments in a try-and-learn format. In short you stop being dogmatic, you stop thinking in terms of plan-and-apply and begin to believe in try-learn-improve.

This new try-learn-improve culture is basically what Japanese people call kaizen, which is kind of a buzz-word these days. The whole Agile thinking is based on the concepts behind kaizen : improve what you are doing every day, step by step, little by little, from the inside, each time the environment changes, etc.

At the highest level this is now a no-brainer: we stop trying to deliver the whole value – the whole product – at once but deliver it little by little, adding value at each step and gathering feedback as quickly as possible, allowing a quick learn-and-improve loop. Scrum, for example, completes this loop on every sprint through a review with the stakeholders and a retrospective with the team.

At a lower level, however, things are not so obvious. Of course people know that there might be some improvements to do. If you ask a developer, she might give you a list of two or three things that should be improved. Same for a tester. But they just can’t make those improvements. They just don’t have time. And because they don’t have time, they cannot complete the try-learn-improve loop. Why? Because their project managers try to hunt slack time down, believing in the 100%-utilization dogma.

There is a misunderstanding here, a confusion between “a good process utilizes all the resources at 100%”, which is questionable, and “utilizing all the resources at 100% makes the process good”, which is definitely wrong. And project managers that continuously try to maximize resource utilization are wrong. They are running after a symptom, a consequence of what they really seek. Metaphorically having a fever does not make you having flu.

If you are a Kanban-aficionado like me, you already know that limiting the work in progress can help us getting the process under control and ensures that things will end up being done. We are not going to start a hundred things at the same time without completing them. But WIP limits serve another purpose : creating slack time. When someone is “blocked” because of WIP limits and cannot do regular work he has to do something else, which can be about improving its own work, thus completing his own try-learn-improve loop, or, if you believe in self-organized teams, improve the current flow by helping unblock the bottleneck, or even improve the whole process if possible.

But even if you don’t practice Kanban, you should still try to create slack time, thus creating room for improvement. The main advantage of creating slack time with work-in-progress limits instead of scheduling it is that it might create opportunities for improvement right away. For example, a developer who cannot do regular work because the testers are overburdened might work on test automation improvement, etc.

As a final note, you are invited to read (and sign) Pawel Brodzinski’s Slacker Manifesto. You might also want to watch the video of his talk at LKCE2012 that deals with the subject.

A Bug Tracking Story

Uncategorized, , ,

I’ve been working at Ve-hotech for years now. I first started being a developer and then moved to a project manager position…and as far as I can remember the tracking of bugs has always been a problem. The problem is not actually the bug tracking itself but to find a way to handle bugs when you cannot solve them as quickly as they get reported by end users (yes, we’ve been through pretty tough times…)

A classical approach for handling an important amount of bugs is to use a web-based bug tracking system. This is a pretty convenient way to centralize all the reported issues. The business stakeholders can then sort the bug list and prioritize it, allowing the team to pick up the next more important issues and solve them.

Although this approach might be compulsory when dealing with hundreds of bugs or when the team is not collocated, it surely is a pretty big overhead when the number of bugs is thin and the team and product owners are working at the same place.

Understanding that nobody really wanted to use a web interface for managing bugs, that the redmine instance we were using was beginning to get out of sync, and as we were moving to Kanban, I decided to morph the bug tracking system into a physical, visual, post-it driven bug backlog. Imagine a 2-meter high sheet of paper covered with little, yellow sticky notes – 80 or so.

The goal of this bug wall was to ease the work of product owners, since they could see everything at once and select the defects they wanted the team to solve more easily. New issues were added into a special area of the wall so that stakeholders could identify them and decide where to place them on the wall – and when to put them into the Kanban flow.

There were three main drawbacks with this bug tracking implementation :

  1. The team – the people who know about the technical part – was not much involved into the prioritization/evaluation of bugs criticality
  2. There was no simple way to get a whole-picture view of the product stability
  3. Who can possibly sort 80 sticky notes?

To solve these problems, the boss (I wish I have thought of that first but…) came out with the idea of using a sort of criticality matrix.

We could actually dramatically improve how bugs were handled using two criteria:

  1. Intrinsic severity : Does this bug jeopardize users’ data? Does it happen all the time? Is it highly visible? On the contrary is it only a highly improbable situation? Maybe we could not even see it by ourselves? etc. We decided that four levels of criticality were enough, each one having its own set of criteria.
  2. Technical impact : How the team feels about this issue. Is there any identified risk? Is the fix difficult to implement? Do we need to rewrite an important part of the product? Do we even have a clue about how to debug this? etc. We don’t need any precise measures or calculations here. A simple gut feeling will do.

So the current implementation of the matrix is a 2×2-meter grid with horizontally the intrinsic severity, from A to D, and vertically the team feelings : 

As you can notice the first line is special. Bugs that cannot be quickly evaluated go there and need special attention as basically the team do not know where it comes from.

In the above example the two bugs in [A/???] are highly critical and must be dealt with as quickly as possible since, for example, they happen all the time and threaten user’s data, and the team don’t know at all how to solve them. On the contrary the four bugs in [D/:-)] are likely to be very improbable bugs that would be very easy to solve with no real impact on the rest of the product. There is no emergency to treat them.

As we wanted to have a global stability indicator, we affected each row and column an arbitrary coefficient : A=20, B=10, C=5 and D=1; ???=4, : -)=3 etc. In the above example, each [A/???] bug is worth 80 points (20×4) whereas [D/:-)] bugs are worth 1 point each. The above matrix can thus be estimated : 20*(2*4 + 2*2) + 10*(1*4 + 4*3 + 2*2 + 1*1) + 5*(1*4 + 4*3 + 4*2 + 2*1) + 1*(2*3 + 1*2 + 4*1) = 592

This approach facilitates decision making about scheduling while providing a good visualization and an easy-to-understand stability indicator. It can also break the last silo that might still exist in an Agile organization : the one between product owners and teams.

Do you use a visual tool for bugs with your teams? How do you prioritize them? Go share your experience and answer this follow-up question in pm.stackexchange.com