Losing product vision

Uncategorized,

Developers, and I am no exception, usually complain that product management people lose product vision. They are often tempted to fill the product with a bunch of “useless” features which dilute the real purpose of the product, the main job of it. And since one of the most unpleasant thing of a developer is not understanding the reason why a feature should be added, this often causes endless arguments and create a real barrier between us and them.

Now let me tell you a story that happened yesterday.

A teammate and I were were talking about making coffee. As both him and I own a single serving coffee maker at home, we always experience huge difficulties when we have to make coffee with the regular coffeemaker that we share at work. When I first had to use the machine three weeks ago, I had not touched a regular coffeemaker in the past four years. I didn’t know the proportions of coffee and water to put in the machine and the result was…spectacular.

During our conversation we came to think about a product. We had a clear problem to solve : measuring the volume of coffee to put in the coffeemaker. Instead of using a traditional measuring spoon, which would only partially solve our problem (we would still have to know how many spoonfuls to use), we quickly designed a kind of 10-cups measuring bowl :

10-cups measuring bowl

We had a product vision, a problem to solve, a job-to-be-done, or whatever you call it…and then the conversation continued. Within about 2 minutes our simple, easy-to-use, problem-solving, user-focused product was looking like this :

coffeemeasuringrobot

The new product was much more complete and full of really cool features : voice command interface, measures both water and coffee, can deal with more of less strong coffee, can make coffee for any number of cups, changes used coffee filters, washes the coffee pot, etc. But what was the problem we were trying to solve yet? Clearly we had lost our product vision.

Quickly designing a product is easy. Making it evolve in a consistent and coherent way is much harder, and it’s everyone’s job in the team to try and stay focused on the main problems the product is meant to solve. Because losing this focus is also very easy, we must work together on the product, not against each other like we often do.

Indian Planning Poker

#NoEstimates,

When I first heard of estimating work items – let’s call them stories – with Story Points I was like “WOW!! That’s amazing!! No more question about how long it will take! Just estimating the relative effort, it really is a good idea!”

Then I discovered Planning Poker, and again was amazed by how it can solve Asshole Driven Development issues (me being the asshole most of the time). I immediately decided to apply it with the team I was in charge of. We did ONE session, and everybody agreed that we were wasting our time. Yet we learnt a couple of things then:

  • We could easily treat small stories, the ones worth 1 or 2 points
  • We could not easily decide about big stories, and almost always decided to break them into smaller stories

All around the Web you’ll see that people recommend not to use the bigger cards of your planning poker deck, and to only keep the 1/2, 1, 2, 3 ones or so.

So we decided to give a try to T-shirt-size estimates, which was basically like keeping only 3 cards in our deck : S, M and L. We did ONE session, and everybody agreed that we were wasting out time. Yet we learnt a couple of things then:

  • We could easily treat small stories, the S-sized ones
  • We could not easily decide about big stories, and almost always decided to break them into smaller stories

Now here is the thing : we had a product to build and we wanted to now how long it would take to build some of the pieces of it (we are not discussing why here). We realized that we could not give any (accurate) estimate to answer that very question unless the pieces were small enough.

So we decided to always work on small-enough pieces of work. Obvious.

Now if for some reason you believe that you need estimates, what you can try with your team, during your next Sprint Planning Meeting, is a session of Indian Planning Poker. You actually only need one card in your Planning Poker hand: the thumbs-up card. Stick the thumbs-up card on your forehead if the story is small enough, or as small as usual, and not if not…and tell me about the results.

Post-Agile : Software Development As A Service

#NoEstimates, , ,

Maybe a new way of working for post-agile organisations

I wrote most of this article long ago but decided to keep it as a draft until recently. I actually thought that was more of an utopia than of a real, possible thing…but this changed after I watched Neil Killick’s talk on #NoEstimates.

I’ve been practicing software development in a Kanban team for several years now, around a single product. A first observation I want to make here is that current “Agile” way works fine with long-term projects, at least if :

  • you build a stable team
  • you slice the work into small SMALL pieces of work
  • you try to keep the work items of the same size, asking simple questions like “Is this work item as small as usual?”
  • you limit work in progress at every level of your process
  • you get rid of “expert” effort estimates and use historical data, statistics and probabilities instead (possible because you built a stable system thanks to the first 4 points)

When I speak to people working in web agencies or other kinds of software development shops, they often tell me it’s not going to work with small projects, when teams must work on several projects at a time, for several customers. They also tell me about contracting problems : how to be Agile – and what are the benefits of it – when dealing with fixed-scope kind of contracts?

That’s why I’d like to describe my hopes for a post-agile world, hopefully solving the issues above, by describing the kind of practice I’d like to see emerge in the years to come. I call it Software Development As A Service. It goes like this:

  • The team implements some kind of Agile/Lean principles so as to get a stable process, like what I succinctly described above.
  • We consider the team as a whole, a system converting customer money into customer business value at a (statistically) predictable rate.
  • The customer and the shop agree on some sort of Service Level Agreement based on lead time distribution for the given team. Transparency is compulsory here.
  • The contract becomes a fixed-cost contract

So I guess that post-agile really is about customers becoming agile too, and embracing the fact that software development is partly made of uncertainty.

If you have any thought on that, feel free to leave a message here or on twitter.

How good are your estimates?

#NoEstimates,

uroboros
An Agile iteration often goes like this, whatever the framework you are familiar with:

  • the product owner prioritizes the backlog of work items (features, epic, user stories…)
  • the team gives estimates for the top of the backlog, using story points, ideal time, actual time…
  • the team and the product owner agree on what will be done
  • the team actually does the magic
  • the team shows what has been done, and we compare with what was expected

Among any other thing, we often compare the estimated velocity, the number of story points the team thought they would tackle during the current iteration, with the actual velocity, the number of story points the team actually managed to sweep away.

By doing so we try to learn two things:

  • how fast the team goes
  • how accurate its estimates are

Pretty logical indeed : we compare expectations with what actually happened… but… WAIT A SECOND! What are the facts I am talking about? ESTIMATES? I am trying to calculate the speed of the team relying on the very estimates which I am trying to know the accuracy, and this accuracy cannot be computed otherwise than by comparing with the actual speed of the team!

BAM!!! Your head just blew up! You are a uroboros!

Now the good part, because I know that some of you still have their head rather intact. I hear you say “We don’t need to know how accurate the estimates are, we just need to know that they are always the same, based on the same scale“…and you are absolutely right. If the team always estimates work items the same way, we can easily monitor its velocity.

Now say that our team velocity is 20 story points per sprint. The backlog is full of user stories estimated at 1 or 2 story points, but one of the stories is worth 19 points. What are we going to do with it? We are going to break it into smaller stories : there is too much uncertainty, too much risk with such a big story, even if the team could theoretically handle it. Ideally we would break it into 1-point or 2-point stories, because that’s the kind of story the team is used to working with.

If we go a little further, we will realize that what we really need in order to calculate the team velocity is that every story is almost always of the same size, whatever the size, even if our intuition tells us that the smaller the stories are, the better our calculations will be.

So we stop estimating user stories with story points – or whatever – and ask the team a simple question : is this story small enough? or better is this a standard story?

A the end of each iteration we just count the number of stories done and do our math…welcome to the #NoEstimates world!

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?!”).

Non-allegiance

No dogma

I’ve been talking about this before so there will be no surprise : I don’t like dogma-driven thinking in software development (people who know me personally know that it’s also true in politics or any other area).

Tonight I stumbled upon an initiative of Alistair Cockburn : The Oath of Non-Allegiance…and of course I’m in:

I promise not to exclude from consideration any idea based on its source, but to consider ideas across schools and heritages in order to find the ones that best suit the current situation.

I signed the oath of non-allegiance

Now that I have taken oath, I must make a confession : I sometimes exclude from consideration ideas based on their source when the source appears to me as dogmatic. This is a mistake. Extremism is a plague for learning and anti-extremism is definitely an extremism. So let me add this appendix to my oath:

I will not exclude from consideration any idea coming from schools, dogmas and heritages based on the single fact that they come from a heritage, a dogma or a school.

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/

Je lance aujourd’hui un nouveau site entièrement en français : matthiasjouan.fr

Le thème principal est le même qu’ici : le développement logiciel tant au niveau de la programmation pure et dure que d’un point de vue gestion de projet. On y parle donc de Lean Software Development, de Kanban et de tout ce qui fait notre art(isanat).

L’idée est en fait de satisfaire nos amis francophones, qui représentent plus de 45% des lecteurs de Scalable Ravings. Je continuerai bien sûr de publier ici le contenu en anglais

À bientôt sur matthiasjouan.fr

————————

I am launching today a new site entirely in French : matthiasjouan.fr

The main topic of this site is the same as here : software development, both in terms of programming and in terms of project management. We’ll talk about Lean Software Development, Kanban and every aspect of our craft.

The idea is to satisfy our French speaking friends, who represent more than 45% of the readers of Scalable Ravings. I will of course continue to publish English contents here.

See you soon on matthiasjouan.fr

The Wise Man and The Inquisitor Priest

No dogma,
A wise man
Wisdom…

This article is part of the « No dogma » series. Do not forget to read the other articles on this topic.

Ok…I know what you are thinking, but no! I don’t hate Scrum! The software development world is crowded by people who have had success with Scrum. Scrum solves many problems and reduces many risks that every software project is confronted with. And this is the same for XP or Kanban. I won’t deny it.

In fact there is a concept that I don’t like with methods like Scrum or XP : the ScrumMaster / Coach role.

First of all, I’d like to mention this article : Delete [ScrumMasters], by Tobias Mayer. Not the same discussion as in this post, but still an interesting view on the ScrumMaster role.

Actually I don’t hate ScrumMasters or XP coaches neither. The concept of coach is a good concept. What I dislike is their theoretical limitations due to the definition of their role:

The ScrumMaster is responsible for making sure a Scrum team lives by the values and practices of Scrum.

Learning Scrum – The ScrumMaster

The Scrum Master is by definition the Inquisitor Priest of Scrum. If he does his job well, he will make a team implement Scrum entirely, protect the team against non-Scrum interactions with external people, ban non-Scrum practices and burn sorcerers and witches.

This is not what I think a real coach should do, so let’s define another kind of coach. Maybe a LeanMaster, no an ImprovementSage or just a WiseCoach – you name it.

The WiseCoach – actually I like this one – is not related to any methodology or guru. His goal is not to make sure that the team implements the selected method well but to make sure that they improve themselves and focus on delivering more business value. He will never say “We are doing Scrum : we must blahblah” but “This part of Scrum does not work with the team : why? what could we change to improve it? what is its exact purpose? how could we get to better results with something else?“. He will never say “No Scrumbut here!” but “Let’s implement a kind of Scrum+” He focuses in putting the team on the auto-improvement path, with no dogmatic boundaries

The WiseCoach is change-oolic. Thus he prevents the team from being lazy and makes sure that they always try to improve in a permanent try-learn-improve loop. He helps the team analyze the current process and policies, mitigate risks and change for the better.

Finally the WiseCoach is a wise man, a philosopher. Thus he knows that software projects and teams are complex systems and that there is no such thing as “best practices”, good/bad dualism, true/false statements, magical answers, etc. Instead he believes in balance and small-step continuous improvement. He refuses ready-to-wear solutions. For him there is no absolute truth, there is a moment, a state that we need to improve.

This kind of people already exists of course. Some of them are proud of themselves, but others are hiding themselves in the dark. They are ashamed of their blasphemous behavior, but they should not. You WiseCoaches who read this : show yourselves!