Simple Planning

What is necessary when you need to plan the next sprint/iteration ?

The picture above is the result of a chat with Lasse in my current project, and it was enough to set the expectations for the two weeks of work we had to plan.

Each post it is a story and time goes from left to right. Stories that are in the same vertical line can be played at the same time, and that big pile on the right means that those stories are dependent on each other, but can still be played simultaneously if developers are careful and communicate enough with each other.

This wasn’t anything planned, but it was simple enough for what we needed, and since we were working in a distributed team, taking a picture and sending it around was they way we had to share it with everyone. Worked just fine : )

Lean Lego Game @ dtsato.com

Since me and Danilo started presenting the Lean Lego game in 2008, a lot of people have been asking for information about how to run the workshop by themselves, in their companies, etc.. During this time, we have created a presenter pack, which we happily distribute to anyone who wants to use the material for non-commercial purposes.

To make this information more accessible and easy to find, we have created a page for the game, where you can find more information about it, and how to get in touch with us and get the material you need.

Here you go: Lean Lego Game

Enjoy!

Agiles 2009

I’ve been for the past two weeks in Brazil, and during this trip I’ve had the opportunity to participate in the 2nd Latin American Conference on Agile Methodologies, Agiles 2009, which was also being sponsored by ThougtWorks.

The conference itself was great, with a really good attendance (around 500 people), including students and professionals from different south-american countries and lots of good speakers, including Brian Merick and Diana Larsen.

I had a presentation on the first morning, titled “Is Agile The New Waterfall ?”, which tried to propose a discussion about how the (unfortunately) de facto way of agile adoption might influence negatively the future of the movement. Gladly, the presentation went really well, with a fully packed room, lots of questions and good feedback from the audience.

ThoughtWorks also used the opportunity to announce the opening of a brazilian office in Porto Alegre, which was done at the ending of a very well received keynote from Roy, which talked about the industry, his views on South America and also about the company and its purpose.

We had a great time overall, and the organizers should be congratulated for the effort of making this event possible, specially when all the people behind it were working as volunteers.

In case you are curious, you can find pictures from the event here.

What’s the Tech Lead Doing Anyway ?

Some days ago when having a discussion at work about the responsibility of the tech lead in an agile team, I’ve realized that this is not a so simple subject as I thought it was. Therefore, good subject for a post : )

But before being dictatorial and just writing my opinion, I ran a small twitter poll asking about this subject. Fortunately, most of the answers matched what I think in some level, so hopefully I will be able to cover it all here.

Before starting, a last note. I was reminded that the term tech lead might not be so used and known as I think it is, so if you don’t use this term at all, sorry : ). You can replace tech lead for architect, technical manager, master jedi, whatever you feel like…

Giving an introduction, the tech lead (TL)  term is defined here as a person who has the technical overview over a specific project. Some people disagree about the need for a tech lead at all, but that’s the topic for another post, and here we will assume that the tech lead exists and is a single person. Ok, that was the easy part.

Now the more subtle (and polemic) part comes here, so I will give my opinion on it (with the help from @dtsato and @flessa).

What a tech lead should be doing:

Have a technical overview over the whole project – As a developer doing everyday work, it is easy to lose the long term perspective about where the project is going and make decisions that will be better in the short term, but harm the project in the long way. It’s the job of the TL to keep that in the mind of the development team.

Make sure the project has a common face – Standards are important IMO, and making sure the project still makes sense as a whole, avoiding knowledge silos it’s the job of the TL. He shouldn’t have to enforce standards or ways to develop code, but facilitate the discussion within the team.

Remove technical impediments – As the most experienced person in the project, its natural that sometimes the TL will be the person in the best position to remove technical blockages that the team might have.

Bring people to a good technical level – If the team has different levels of experience, the TL should work to help people achieve a good work quality by sharing his knowledge and incentive others to do the same.

Write code. Write a lot of code – The TL is not a superior being that gives directions from the top of a mountain. Don’t know about your opinion, but if I can’t rely on the TL to sit down and pair with me when I have a problem I can’t solve, it’s no good to me.

I think that is enough for now. Now, for what the tech lead should not be doing:

Be the person responsible for the code – Being the tech lead doesn’t mean being the owner of the code, or the team’s boss. It’s everyone’s job to create high quality software, and the TL should only expose problems to the team and lead them in the right direction (emphasis on lead, not mandate).

Making all the difficult decisions alone - During a project, the team will be exposed to different technical decisions that will have to be made. Allowing the TL to take them alone just expose the team to more risk, since they won’t understand/care about what was decided. What we want to achieve is that Paulo exemplified here.

Impose his opinion – This is probably the most important point. Remember collective code ownership ? It is still very important. No matter how brilliant a TL can be, if he can’t share his knowledge/decisions and specially the responsability with the rest of the team, things will go bad.

Systemic Thinking

Some days ago I read this article about how the credit crunch was explained to the Queen by a “group of eminent economics” (whatever that means).

The interesting part in my opinion is this paragraph, which was contained in the letter sent to the Queen:

“Everyone seemed to be doing their own job properly on its own merit. And according to standard measures of success, they were often doing it well,” they say. “The failure was to see how collectively this added up to a series of interconnected imbalances over which no single authority had jurisdiction.”

If that doesn’t make people believe in systemic thinking, I think this might be a lost cause : )

Empower

Peer pressure enlists loyalty in ways that bureaucracy doesn’t.

John Mackey, CEO and co-founder, Whole Foods

This quote is true in so many different levels, but still quite ignored by the standard way of management.

The normal company, instead of making a good use of peer pressure, label it as a bad thing, and believe in the passive-aggressive affirmation of its values and rules as the way to better manage employees.

What they don’t see is that the only way to really generate a company with the  wanted values is to hire people who believe in them and empower them as much possible, making “good” peer pressure be the driving power fo your business.

It’s hard to accept that the employees define the values of the company, and not the other way around.

Lego Lean Game in Sardinia

Last month me and Danilo presented an extended version of the Lego Lean Game at XP2009 in Sardinia, Italy.

This was the first time we tried this version, and it can be considered a success, with good feedback and some people asking information to run the workshop within their companies/classes.

You can find more information about how it went on this post Danilo wrote, and the slides are also available here (if you like to see how it went, pics are here). As he said, we prepared a package with all the material needed to run the workshop, so feel free to ask us for it if you have participated and are interested in doing it : )

Dev Complete? No!

Recently we’ve had a discussion in a project I was working on about the concepts behind dev complete and qa complete stories, which are normally in a lot of agile wall’s swim lanes, and how they affect the project’s flow.

The point here is not to discuss how to measure your goals, since this was discussed in previous posts, but what I wanted to explain is how (what I’ve realized during that discussion) I don’t like the term dev complete, and why it can affect your team.

First of all, development complete implies the idea that we don’t need any more development in one specific story, and as anyone who has been in an agile project might have noticed, this is less true than we wanted it to be.

What frequently happens is that stories which are in the dev complete lane come back to development when they don’t meet the QA criteria, and suddenly development has to be done again for something that didn’t need any more development.

And what I find most annoying is that development complete has the word complete on it, which has an underlying meaning that someone (the devs, in this case) have completed their job, and that they could feel good about it at this point.

What goes away when this assumption enters someone’s mind is the fact that the objective (for all the team, including those devs), is after the qa complete stage, when the story is actually delivered. And this situation just gives another motive to the always disturbing separation between developers and qa’s.

So if you believe in how measures affect the results of a team as I do (more info on that here, here, here, here, here, here and here), change all your dev complete stories to qa ready, or something similar, and enjoy a little bit more peace of mind.

What is Your Goal?

One of the best things about Agile is the introduction of software development as a system. Software stopped being treated as a sequence of separated steps to be seen as people with different competences working together to achieve one goal: deliver software.

This is not new in any sense, and it was exemplified by Deming on one of his books:

I could do a much better job (fewer mistakes) if I knew what the program is to be used for. The specifications don’t tell me what I need to know.

Despite this advance, most software development teams fail in really understanding this concept, and still normally don’t see the power of using one unique measure to manage the project, not getting the idea that the effort of the system should be only measured once, in what is its goal.

You must be asking what is the problem of having different measures to verify the sanity of the project. And that is what Peter Drucker explains in his Post-Capitalist Society book:

In knowledge work… the task is not given, it has to be determined. ‘What are the expected results from this work?’ is the key question in making knowledge workers productive. And it is a question that demands risky decisions. There is usually no right answer; there are choices instead. And results have to be clearly specified, if productivity is to be achieved.

What it means is that tasks cannot be fully specified anymore, the workers have to make decisions every time about how to proceed in certain situations, and they can just do it correctly if they have a clear vision of what is to be obtained, and what is the final goal of the work they are doing.

This concept is also illustrated in the draft version of Mary and Tom Poppendieck’s latest book (still in the draft version), when they are explaining the case of Southwest Airlines, which has as main advantage against the competition, the fact that its planes stay less time in the ground, thus generating more revenue.

Southwest maintains a systems perspective; it doesn’t let individual department measurements or increased revenue opportunities distract it from the primary objective of maintaining profitability. Southwest makes it clear to every employee – from the agent closing the gate to the baggage handler transferring luggage – what is important from an overall perspective. Everyone at Southwest knows the mantra: “Airplanes don’t make money sitting on the ground.” So everyone works together to get each plane in the air as fast as possible.

The important here is that we have one measure. One variable that everyone can rely on to make decisions during their work, and the ability to do it makes a whole difference in the overall performance of a team,  fact that often not considered in software development, where different measures distract people from the main goal.

As an example, a common situation I’ve seen in project is to track bugs within the iteration, and use it as a measure of code quality. Well, the goal of a software team is to deliver software without bugs, but it doesn’t matter at all if in the process of creating software bugs are found and solved prior to the software being released. If that is the way the team works best, so be it.

Another example is a case where a project had a problem with bugs creeping (this time, after iteration was finished and software delivered), and when discussing the fact we’ve realized that because of the pressure to deliver, we were delivering development complete, and not QA complete stories, so QA was actually done after the iteration finished, and yes, the team’s velocity was based on development complete points.

Well… if the goal you set to the team is to deliver dev complete stories, guess what you’re receiving in the end… dev complete stories!, it doesn’t matter how many times you repeat “Let’s focus on delivering quality software“. As Goldratt said, “Tell me how you measure me and I will tell you how I will behave.”

So, what is your goal?

Lean Lego Game @XP 2009

Next month, Me and Danilo Sato will be presenting the Lego Lean Game ate XP 2009, which will be held in Sardinia.

So, what is it?

The Lego Lean Game is an activity developed to teach people about the basic concepts of Lean thinking in a dynamic and fun way, demonstrating Lean practices in an imaginary production line to build Lego houses.

Why?

The idea came from the fact that Lean is becoming a common term in software development, but many people haven’t been introduced to the concepts that made it successful. This workshop aims at introducing this concepts to the participants, making them understand where Lean comes from, and why apply them in the software world.

Should I Come?

If you are interested in Lean, but haven’t had time to study about it, this is the perfect place for you. More experienced people are also welcome, since the hands-on activity makes you discover many aspects that might have been missed before.

If you want to have a better idea of how it is, you can check this video (sorry for the shaky camera : ) ), from the presentation we made at Agiles 2008.

Hope to see you there!