Experimenting with Kanban: introduction

July 12, 2011

Today I’ll start a series of posts describing my recent experiments with Kanban System for Software Development (a.k.a. Kanban). In this first post I’ll describe our context, the core concepts of Kanban that we implemented, the steps that we took to implement those concepts and our conclusion until now.

Our context

We have to maintain and evolve systems that are already in production, which means that we need to deliver new features and fix bugs. The team was doing a ScrumBut: planning sprints but with a lot of interruptions and distractions during their execution, which caused most sprints to end with stories not done.

Core concepts of Kanban

We created a visual board representing our workflow, we are measuring and optimizing our cycle time weekly, we have limited our WIP for each state and we have explicit policies that describe the rules for each state transition.

How we started

The first step was a training session explaining the core concepts of Kanban to our team, that I did it myself. After that, the entire team participated in the creation of our visual board: defining our states, our WIP limits and policies. Then we populated the board with all the stories and tasks that the team was working at that time and scheduled our daily meetings and monthly retrospectives. After that, things went very smoothly, with the team reviewing and improving our states, limits and policies always targeting at shortening our cycle time. They even decided to print our cycle time history every week, so that they can keep track and improve it constantly. We are using JIRA to help us measure our cycle time: we have our stories both in JIRA and on the board, while the tasks are only on the board.

Conclusion

The team is delivering much more than they were with the ScrumBut implementation and they are feeling much more happy now, because they are being able to see their improvement through the cycle time history graph and also because now they know what each one is doing and being able to help each other more efficiently.

In my next posts I will describe the obstacles that we have already overcome and more details of our Kanban implementation. I’d also like to hear about your experiments! Are you trying Kanban, too?

The baby-product analogy

June 28, 2011
What if a baby had each of his needs served by a different woman?

  • one woman to change his diapers;
  • another to feed him;
  • another to wash him;
  • another to dry him;
  • another to change him;
  • and so on…

And what if each of those women was specialized in just one thing and that each of them served many babies a day, not just one?

Assuming that babies are different, with different needs and different timings, how each baby would be in some arbitrary point in time? Hungry? Wet? Naked?

Well, this is the way most companies are organized today! You can see each product as if it were a baby, and each internal department/silo/team as a mother specialized in doing just one thing and serving many babies. How each product will be in some arbitrary point in time? Hungry? Wet? Naked?

I’m not talking just about multi-skilled teams, with testers, developers, webmasters etc, as this is well understood by all agile-be companies today, but also about multi-component and multi-department teams as well! Specially multi-department teams!

Have you ever seen a company with lots of “multi-skilled” teams where each one was working on a single component of a bigger system? Can a team be considered multi-skilled if it is unable to deliver a complete user feature?

Have you ever seen a company doing a “waterfall sandwich”, where a big spec was done before development and a big bang release was done after the development, even if the development per se was done iteratively? Was this company really agile?

Wouldn’t it be wiser to organize a company in cells, one cell for each product, with each cell containing every person needed and focused in making a product the most delightful of all as a mother does to take care of her baby, doing everything that he needs to grow healthy?

When will companies stop to optimize resource utilization and start to optimize value delivered?

Measurable Value with Agile: the Impact Estimation technique

June 15, 2011

All agile methods have one common premisse: prioritize your features by business value. But how can we calculate this thing called business value?

I did some research recently and found this incredible technique called “Impact Estimation”, by Tom and Kai Gilb. There is also a paper by Ryan Shriver that explains it really well. I’ve been applying it for some time now and it is working really well in my context. What do you think? Can this technique help you too? I hope so!

Mission statement creation

October 24, 2010

One of my biggest challenges when I was assigned to be the ScrumOfficer at Abril Digital was how to unite the ScrumMasters and make them feel confortable following my lead, once I was younger than them all. I had the simplest idea one could have: why not build a mission statement for this team and with their own ideas? And that was what I did and it worked really well!

The brainstorming sessions

I organized a couple of sessions where each and everyone of them helped with their ideas of what our mission was. During this sessions not only they worked as a team, but also I was able to learn what each one of them was feeling about my leadership.

The result

After some sessions, the team finally agreed with this mission statement: “Orchestrate the realization of our organization’s business requeriments following the agile principles.”

Conclusion

After the mission statement creation no one had any doubt that I could lead them to a better future in our company, a future where the agile principles would start to be better understood.

A little help from a good friend!

August 20, 2010

They say that every people you happen to know in your life is there for a reason. If there is one person that I need to mention here is Guilherme Komel (@gkomel). A few weeks before our transition to our new job positions, he told me about a book that could help me fill the gaps to be able to accomplish my new tasks with ease. The book was: “How to win friends & influence people“, by Dale Carnegie.

The book

Yes, this book definitively had an impact on me. I recommend its reading for anyone in a position of influence. It teaches the right ways to approach people so that everyone will want to follow you and accomplish things in your name, once that things are related to a noble cause. A must read for every Agile Coach.

The Return of the Jedi

August 19, 2010

It was a long time since my last post. To be short: in a certain point in time I was a ScrumMaster and suddenly I was the manager of an entire ScrumMasters team, being responsible for the entire company’s software development process. Today I will start a series of posts about the learnings and insights that I had during this awesome period.

The Team

Our team was composed by 8 ScrumMasters and known as “ScrumOffice”, and I, the ScrumOfficer. Our main objective was to optimize the value chain between the business requirements conception until its delivery to the production environment, passing through development, of course. Our main pillars were: planning, conduction and optimization.

The Shepherd

My job was to guide the team in how to achieve excellency in our company’s Agile implementation, respecting the company’s constraints and trying to change/break/push/pull some of those constraints, paradoxically. And the tale started…

How did splitting stories above 5 helped us

April 24, 2009

During the planning meeting, two sprints ago, after the team made their estimates, I proposed: what if we split the stories with estimates bigger than 5? Their first reaction, as expected, was: are you crazy? These are the smallest stories we can think! Ok, I said, so let’s analyse one by one…

An important statement is that the “5” here is about our team’s scale. Other teams can have different scales.

Analysis results

After the analysis, some stories that were 13 became two stories, and the sum of their estimates were in general less than 13. Also, some stories that were 8 became two stories, with their estimates’s sum also less than 8. Just in some very very special cases we kept an 8. But we struggled to split all stories above 8.

Sprint results

All stories were DONE by the end of the sprint. The main advantages of splitting big stories is that the team often cuts out most of the uncertainties by doing it, and the result often is more stories with less points, which can be translated to more velocity.

Removing a very abstract impediment: the two week sprint length

March 23, 2009

At the end of the last year we faced the following situation: a product owner turnover, and the new one coming with a great idea. It happened to be that this great idea was a “happy new year” promotion, and so it would be great if we could implement and deploy it at the beginning of december. Unfortunately, we were at the beginning of the second week of november, and a sprint had just finished…

The problems

  • we use two week sprints;
  • we needed more time to plan the promotion;
  • starting a sprint without the promotion features would lead us to a late deploy date;

The insight

As I could do nothing about the fact that we needed more time to plan the promotion, and as this promotion could bring us very good results, I saw our sprint length as an impediment to deliver the value that our new product owner envisioned. So, I removed it! I proposed a one week sprint where the dev team could kill some tech debits and the product owner’s team could plan the promotion. Both teams enjoyed the idea, given the context, and we did it that way. After this one week sprint, we returned to the usual two week sprint, and implemented the features of the promotion, releasing it at the beginning of december, as it should be, and the promotion became a success!

Conclusion

An impediment can be as abstract and subtle as one can imagine. Even things we know as “agile laws”, as the fixed sprint length, can be bended to serve us better. Of course, before doing that I’ve made it very clear to the product owner that we were going to take this manoeuvre only because of this particular situation, and that we shouldn’t use it anymore, in any circumstance, given that he would have time to plan his releases with a lot more anticipation after this very first sprints of him.

Maintaining the story points scale

March 20, 2009

After applying the James Grenning’s companion planning poker games to estimate our releases, I became concerned about how to maintain the story points scale in the next estimation meeting, since we’ve dropped the traditional “an easy story as base”, and jumped to “an easy column of stories as base”.

The fact is, the solution is simple. I’ve just brought all the stories of the last sprint to serve as a base, and the team used it as column examples. The difference between this estimation meeting and the first one is that in the first one the team had no base, and just organized the stories in columns of similar difficult. Using the last sprint as a base, the team just slided the new stories under the already estimated stories, using the old ones as parameters. This even eliminated the need of planning poker for a good amount of columns, since we had enough stories as examples.

Also, I was in doubt if I should bring all the stories of all last sprints to use as a base, or just the stories of the last sprint. The thing is, the larger the range of points we bring as examples, the better the team will be able o maintain the story points scale. And also, fresh stories are better parameters than very old ones.

My conclusion is that we can apply the techniques proposed by Grenning every time, obtaining very good estimates every time! Just keep bringing the stories of the last sprint to help maintain the story points scale.

Estimating stories faster and more accurately

March 9, 2009

In a recently endeavour to find the blogs of all Agile Manifesto’s authors, I’ve found this post of James Grenning about some planning poker companion games. Luckily, we were about to do a release planning for both Brasigo and BlogBlogs here at WebCo, just the perfect opportunities to try a new approach to estimating.

The results:

  • 20 stories estimated in just one hour!
  • much more coherent estimation!
  • much more accurate estimation!

Why?

  • faster due to the great amount of example stories per column of similar difficult, facilitating the comprehension of everybody;
  • coherent, because the team compared almost all stories against each other to correctly sort them in columns of similar difficult;
  • accurate, also due to the great amount of example stories per column of similar difficult, so that each column had much more information than a single story could give in an usual planning poker game;

Conclusion

I highly recommend this method! Not only for release plannings, but for all estimation sessions. It is deep enough to do always.