Posts de ‘Agile Tales’

[Agile Tales] Comment on Stop wasting your time: Timebox it! by Dividindo reuniões em pomodoros – parece ótimo! – Fernando Garrido Vaz

Tuesday, August 1st, 2017

[…] via […]

[Agile Tales] Comment on Stop wasting your time: Timebox it! by Refatorando o planejamento da sprint – mais pomodoros, mais negócio – Fernando Garrido Vaz

Tuesday, August 1st, 2017

[…] segundo a lei de retornos decrescentes mencionada em outro post nesse blog. Já tinha lido o relato de um pessoal da sobre o uso da Pomodoro Technique para rodar reuniões, e achei que seria interessante tentar.  […]

[Agile Tales] Comment on When you are struggling: what agile is really about by Gebhard Greiter

Wednesday, January 20th, 2016

We need to think beyond the Agile Manifesto — the Manifesto’s approach is not abstract enough:

For defining Agile we should focus on the goal of Agile rather than on the misleading, very problematic way suggested by the authors of the Manifesto. Please read

The New (2011) Definitions of Agile or
The Manifesto can be Poison
The Manifesto is ignoring CIO’s Interest.

[Agile Tales] Comment on When you are struggling: what agile is really about by Jeff Patton

Wednesday, January 20th, 2016


I really like this… and I think you know I agree wholeheartedly.

There’s lots of odd paradox about process. We need just enough of it to work together. Too much moves our focus from what we’re trying to accomplish to the process – it makes the process what we’re trying to accomplish. Too little makes it challenging for us to work together.

In classes these days I do a quick word association. That is I write down the word “process” and ask participants to give me first words that come to mind. The words that come up usually aren’t particularly uplifting and give some strong hints about the culture they work in. I then write down the word “game” and ask participants to shout out the first words that come to mind. In addition to words like “fun,” and “team,” I often hear words like “competitive,” and “winning.”

It seems to me that games have just enough rules to allow us to play together as a team, have fun, and focus on the real object of the game – ideally to win. Winning in software [for me] is building a successful product.

Contrast that to the processes most companies labor under. Just surviving a process seems like winning at times. Winning at process is often “doing it right,” or “following the rules.”

One thing I recall from working with your company is that your leaders, most of them, seemed focused on winning the game. That’s the best cultural foundation a process can have.

Reminding people that process should feel like we’re playing a game has helped me a lot lately. Some folks still don’t like the Scrum game. I’ve often South Americans complain about US football that there’s “too many meetings.” :-) One agile “game” may not be right for every culture – but within an organization and especially a team, it’s important that we all be playing the same game.

[Agile Tales] Stop wasting your time: Timebox it!

Friday, March 19th, 2010
Timebox wall

Photo by 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

Pomodoro Picture

Photo by Rapha Autran:

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!

[Agile Tales] Pointless product design: It’s not about velocity

Friday, March 19th, 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 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 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!