Agile Tales - Tales of the Agile world

Why all late projects are the same

29/11/2011

Just read an astonishing article by Tom DeMarco (PDF here) on why “All late projects are the same”. It’s just amazing. Had some great insights. Some highlights:

All projects that finish late have this one thing in common: they started late.

This sounds really, really obvious at first, but it isn’t. Tom defines two underlying reasons for not starting a project early:

Nobody had the guts to kick off the project until the competition proved it doable and desirable; by then, the project was in catch-up mode and had to be nished lickety-split. […] is a legitimate business failure. Interestingly, it’s not software developer failure that’s in question here, but that of some marketing arm that got one-upped by superior marketers in another company. Making a lot of noise about those software folks who failed to build the catch-up product fast enough is just a way to de ect attention from what really happened and who is responsible.

If the project were started long enough before its due date to finish on time, all involved would have had to face up to the fact from the beginning that it was going to cost a lot more than anyone was willing to pay. […] This leaves us with projects that started late because they didn’t offer enough value to justify their true cost. This is garden variety failure, in my opinion: it happens all the time. If a project offered a value of 10 times its estimated cost, no one would care if the actual cost to get it done were double the estimate. On the other hand, if expected value were only 10 percent greater than expected cost, lateness would be a disaster.

Posted, by Igor Macaubas in management Tags: engineering, management, peopleware, software

When you are struggling: what agile is really about

10/11/2011

We need to go back to basics: get out of the process!

Since the early release of the agile manifesto, much have been said about what agile is really about. People have fought epic battles over whether distributed team works or not, whether it is Scrum or Kanban, Lean, DSDM or Crystal Clear the “right” choice, whether the standup daily meeting has to be held when the sunshines or when the sunsets, and so on. Much energy has been spent on such kind of discussion, and this really doesn’t seems to add up in the end.

Despite what’s written on the agile manifesto (don’t forget the twelve principles as well), a lot of people are still stuck with the basics. Still talking about processes, estimation, certificates, and what the role of the Scrum Master is versus the role of the Product Owner. While these questions are indeed important and matter in our day, we can not be carried away by them, and focus solely on them.

People over processes

People over processes is the first value stated in the agile manifesto, but yet the most misinterpreted and forgotten one. Please don’t get me wrong: processes are really important. But people are more. It’s there, in the manifesto. Misinterpreted because it’s not about destroying processes – this is a surprisingly common misconclusion. And forgotten because even within the agile community, people focus way too much on processes.

While there are tons of books on processes, be they agile or not, and on software engineering, they are basically books on tools and techniques. Where are the books on the human relations involved in software craftsmanship? There are a few authors that have been on this subject, two of them I had the opportunity to meet in person: Lyssa Adkins and Jurgen Appelo. I’ll not get into details about their books, because this is not the point of this article. They’re both great books, and over the past couple of years they’ve changed my view of the world of software development.

Stop blaming the process, start caring about your culture

I’ve participated in two company-wide agile adoptions, and on both cases the main obstacle, the major issue we had to deal in a day-to-day basis was the culture in place. The real struggle was about changing the internal culture, not the processes. If you can read and follow instructions, you can grab a Scrum guide and have it running in almost no time. It’s dead simple. The thing is the aftermath, which isn’t written anywhere: making agile stuck, changing the culture. This is really hard. Culture is defined as “The set of shared attitudes, values, goals, and practices that characterizes an institution, organization, or group” (source: Wikipedia).

So far, I’ve come to one conclusion: there’s no right or wrong way to “do” agile. There are cultures in which the introduction of a new process is easier, there are cultures that makes it almost impossible to change. And it’s really easy to just blame the process and get away with it: the process just can’t fight back.

But how do we fix a broken culture?

This is an answer that you’ll have to figure out for yourself, mainly because there isn’t a right one. And cultures are also not broken, they’re just different. And we have come to live and understand in a world full with differences, so it’s not impossible. It might be hard.

What agile is really about

Agile development is really about values and principles, not processes. For some companies, agile is just a different way of doing things. It’s easy, and it just works. In other companies, adopting agile means a disruptive, ground-breaking and throughout transformation in the company culture. Process is secondary. So, again, human relations got in the way. So, if you’re struggling with your agile implementation, don’t give up. Read the manifesto, see the values and principles there.

Don’t look for what’s wrong with your culture in place, look for what’s different. And then start asking why it’s different. Generally, when you ask ‘why’ on something, on the third depth (from the 5 Why’s problem-solving technique) you’ll see what’s really there, the real root cause of that social convention or behavior. And then you’ll be surely able to bridge it in a different way to the agile manifesto. I’m yet to see a businessman, an entrepreneur, a manager, no matter what level they’re on the corporate ladder, disagree with the agile manifesto. But what I’ve seen are a lot of roads paved with right intentions, but then things go awry because of the culture in place.

So my tip here is simple: empower your people, make them aware, accountable and responsible for their decisions. Getting down to the most basic thing: as human beings, we always want to get better. And I’m sure you’ll.

Closing remarks – updated

After writing the original article, I had some feedback from a friend of mine, Marcos Garrido. He told me, and I quote: “You know you’ve reached somewhere in your agile implementation when your team stops discussing The Process and starts discussing The Product“. I’ve had teams going up thru this phase and forward, and I know it: we’ve just ousted our bad, old habbits. So it might serve you as well as a good landmark that you’re heading to the right direction.

Posted, by Igor Macaubas in agile Tags: agile, principles, process, values

Stop wasting your time: Timebox it!

17/03/2010

Photo by Loungerie: http://www.flickr.com/loungerie/

Imagine that you have a very important job to get done, and as always, your time is limited. But you just can’t focus. As soon as you are ready to start working on your thing, your mind vanishes and starts wondering about something else, entirely unrelated. You try to focus, but all of the sudden you start to “listen in your head” to that new song you just heard in the radio 20 minutes ago when you were driving to work. Who have never been in a similar situation?

The human brain is limited – you cannot sustain attention forever. And your capacity to sustain attention diminishes as your day goes by. Your brain naturally needs to focus on/focus off in a regular basis, in order to have time to work through cognition – otherwise you wouldn’t be able to learn and make progress on your work. The University of Alberta’s Dictionary of Cognitive Science defines that sustained attention is:

Sustained attention is “the ability to direct and focus cognitive activity on specific stimuli.” In order to complete any cognitively planned activity, any sequenced action, or any thought one must use sustained attention. An example is the act of reading a newspaper article. One must be able to focus on the activity of reading long enough to complete the task. Problems occur when a distraction arises. A distraction can interrupt and consequently interfere in sustained attention.

If sustain your own attention is hard as it is, let alone sustain the attention of a 5 – 9 people in a meeting room for a long period of time. Ever since I started working my agile ways, I was introduced to the concept of Timeboxing. The concept is really simple: limit the time, so you focus on the high priority stuff first, and avoid multitasking at all costs. Timebox is everywhere: all Scrum meetings are timeboxed – from the crucial planning, review and retrospective meetings, to the trivial daily meeting. It works mainly trough peer-pressure – as everybody knows that the time is limited, the group will auto-regulate to avoiding losing focus.

Throwing Pomodoros at the problem

Photo by Rapha Autran: http://flickr.com/raphaautran

I’ve been doing two weeks iterations using Scrum. In the end of the sprint, we usually have a 30 minutes review meeting, a 1-hour and a half retrospective, and in the next morning, a 2-hour planning meeting. We’ve been doing this for a while, but yet again, I caught myself managing time, and having a hard time to keep the group focused on what to do. So I found out about the Pomodoro Technique, and started to use Pomodoro in my personal time. It worked great for me, and after a really bad planning session, I decided to try the Pomodoro technique to manage the group time in the next retrospective, just to see how it worked. At first, it was a very counter-intuitive decision: in order to keep focus, I would introduce more interruptions to the meetings. So I decided my magic number: each Pomodoro would take 35 minutes. Between each Pomodoro, 5-minute breaks. After two Pomodoro’s, a larger, 15-minute break. A clear, and visible agenda of what would happen at each Pomodoro. At the beginning of the meeting, I asked the team if they would let me introduce this new technique, as a trial, and explained the mechanics of the Pomodoro. The deal was to try once, and see how it went – and if the team felt it was a good idea, use it again as long as we felt it made some sense.

The first Pomodorized meeting

The first meeting that we tried to use Pomodoros to control the timebox and the progress of the meeting was a sprint retrospective meeting. Our sprint retrospective uses the basic structure of Diana’s Larsen and Esther Derby book (Agile Retrospectives: making good teams great). So we had a well defined and structured meeting – which helped us a lot in determining the agenda of each Pomodoro. We started the meeting, and everything ran smoothly. We had planned for a 3-Pomodoro retrospective meeting, with a total duration of 2 hours and 10 minutes, adding up all times (including breaks). The result was amazing: the focus of everyone was on the retrospective at all times. We had no interruptions, no cell-phones ringing (they were all off – part of our deal), no people going to the bathrooms in the middle of the activities. The overall result was excellent, and even tough we had a longer meeting, at the end everyone felt less tired and accomplished. So we started using Pomodoro’s at our planning sessions, and the things were just better. No worries about timing: Timebox is an excellent focus tool.

Final words

Focus is the new scarce: information sources are growing to infinite scales while available attention is stucked. How much information are we consuming every day? Studies of the Global Information Industry Center, from the University of California in San Diego, estimates that an average American consumed 36 gigabytes of data on an average day. Are we asking the right/necessary questions?

Stop to manage your time and start to manage your focus. Stop wasting your time: Timebox it!

Posted, by Igor Macaubas & Marcos Pereira in agile Tags: agile, pomodoro, Scrum, timebox

Pointless product design: It’s not about velocity

11/02/2010

I’ve started to wrap up some ideas for a blog post when I had a conversation with Jeff Patton about product design, while he were in Brazil with Globo.com doing some consulting work. Patton’s specialty is on product design, and he has some pretty good ideas about how to handle it – I’ll probably talk a little more about his ideas on another post – and I kind of had an epiphany when I saw the following tweet by Jeff:

Looking forward to the time when people use agile development to build great products, not just deliver dumb stuff faster – Jeff Patton

This instantaneously reminded me of a StackOverflow podcast I’ve listened to a few months ago. This was a remarkable podcast, because they had Uncle Bob Martin as a special guest. In the previous podCast of the series (podCast 40), Jeff Atwood made a statement that caused some discomfort between Uncle Bob and themselves, so they invited Uncle Bob to the next podCast to clear things out, but that’s not the point.

The point is when Atwood says (just search for “wordpress” on the transcript and you’ll find it):

So, to me the root issue is if you deliver a product, a software product, that nobody likes or wants to use, it really doesn’t matter how high quality your code is. That’s really the bottom line. And I think I’ve learned this from WordPress, because WordPress is a great, it’s a fantastic tool, but the code is the worst code you can possibly imagine. First of all it’s written in PHP which is already a problem right, on top of that it’s crazy PHP, like it’ll melt your brain if you look at it too long.

I can’t help but agree with Atwood’s statement. What I understood is that he said that the overall product quality is as important as the code quality underneath it – and even if you have a crappy code underneath, and a great product emerging from it, you could get away with it. This doesn’t mean that you have a license to produce crappy code if you’ve got a good product – it does mean that you have to pay attention not only to the technical part of the thing, and make an effort to design great products implemented with great code.

One trap that I see many people in the agile world falling for is not worrying at all about product quality, which take us back to Patton’s tweet. I see too much focus on the technical details (as of in engineering), and on the agile “process” or “framework”, leaving the Product Owner behind, alone in the dark, to “define the product”. It’s one major cause of many project’s failures. Agile is not only about creating great code, nor about following a “process” or “framework”. It’s about creating great products, collaboratively, as a team. This means a shared backlog, shared product ownership, shared vision.

What bring us to the point of velocity, as in throughput of the team. Your product will not be better if you deliver just as many features as you could, as fast as hell. In order to deliver a great product, you don’t need to go faster – you need to go well. It’s good to remember that Pareto’s principle applies very strongly in software development – 20% of our product features get to be used by our users for 80% of the application usage time. So, why don’t heavily invest in having this 20% of features mastered, so you can guarantee a freaking great experience for your users 80% of the time?

When I was talking about this with Marcos Pereira, he brought into light a fairly old post from Kathy Sierra, on Kathy’s Creating Passionate Users blog. In her blog post, she presents the Pareto Principle in a very good way, talking about The Design of Everyday Things, and how a simple car stereo got so bloated with features that it’s almost impossible to use it without looking into the manual. This is exactly what I mean, and we’ve seen greater successes of simplification out on the real world. Look at the iPod’s user experience. It’s easy, intuitive, and you barely have to look to the manual to use it. The advanced functionalities are still there, but you don’t need to bother with them just to listen to your music. MP3 players have been around for a long time, but only after Apple “re-invented” the iPod, this market kicked-off.

In order to achieve this excellence level in Product Design, you need to think differently when it comes to backlog prioritization. I’ve seen it work in a few Product Backlogs in Globo.com. Instead of having a huge pile of histories on your product backlog, precisely divided in order to provide incremental delivery, you just focus on the main functionality, and rank it according to the following experience-driven scale (this is just an example – please feel free to add/modify/build yours from scratch):

Ashamed of (the functionality exists, but doesn’t have a good experience. The team would be ashamed to present this piece of the software to an end-user).
Hum.. just fair. (the functionality exists, and is fairly usable. Depending on the importance of this functionality, it might be enough for a beta tester to try it out).
Enough (the functionality is usable. It’s just enough for production release, and most of the users will like it.)
The best! (the functionality is so good that our users just love it. This is the time to add the extra piece of functionality that will turn your users in addicted monkeys. Nah, just kidding! But this is the idea 🙂 – this functionality is now a master piece of work!).

Now would be a good time for an example…

So, for instance, let’s take a Webmail application as an example. One functionality that is in the 20% group that gets used 80% of the time is the “send email” functionality. Your team could deliver it incrementally and iteratively, by first creating it and being ashamed of it (ex. very basic send email – no BCC, no CC, no WYSIWYG editor). In a future iteration, your team goal would be to make the “send email” functionality just fair for usage (ex. add a WYSIWYG editor, add bcc and cc fields) – and then release to your beta users. On the next iteration, the team would add some more of this functionality, in this case the ability to send a message with levels of priority, or add labels, of whatever your team think that will make a difference to the end user.

This kind of backlog prioritization cannot be done if the team doesn’t feel the ownership of the product, or if the Product Owner doesn’t share the backlog with the team. The end result of this is a natural, user-driven prioritization, when people will start to take into account that maybe it’s best to invest on a new feature until it’s Enough than to make this functionality the bestest best since the beginning, and have other functionalities worked at the same time, incrementally improving them all.

This will basically help you do more of what matters, and less of what doesn’t matter a lot in the long run. Start with a beginner’s mind, and start building best products and making your users happier!

Posted, by Igor Macaubas in Product Design Tags: agile, backlog, jpatton, kathysierra, po, prioritization, product development, stackoverflow