Archive for the ‘Agile’ category

« Older Entries
Newer Entries »

Focus on the Right Point

December 8th, 2008

This post came from a pub discussion with Liz, and actually originated from this thought I’ve been having for some time, an came back in one of my recent readings (not to say also in one of my recent projects)…

I participate in some agile mailing lists, and one question that frequently happens is what I should do about people not showing up/showing up late for the stand-ups in the morning. And normally this comes with statements like: “I’ve tried it all already: waiting, not waiting, punishing late arrivers, making them buy ice cream, etc… and nothing works”

And this situation came again to me mind while reading Ricardo Semler‘s book, Voce Esta Louco! (not published in english so far, but it means You Are Crazy!), when he describes how flexible time was introduced in his company.

To give some context, Ricardo runs Semco, a brazilian company which has business units in a lot of different areas, from shipbuilding to hotel management, but is best known for the industrial democracy that its owner has been implementing since the 80′s.

This particular situation he describes occurred when Semco, in the 80′s, was going to allow production line employees to have flexible work hours, and as expected, most of the top managers were totally against the idea, since it violated a basic principle: for a production line to work, everybody has to be there at the same time.

And ricardo’s answer for that was (free translation):

It’s obvious: if the employees are not working at the same time, the production line stops. We know it, but the adults that work in the production line also know it. And why would they put their productivity and their jobs at risk? If they are not worried about how the production line is, producing or not, then we have a much bigger problem, and the sooner we know it, the better.

And that’s what happened, one day before the program started, the employees gathered and decided what time they would start to work.

But what does this have to do with daily standups? Well, the whole example was to indtroduce the same answer I always give to these questions: if your team doesn’t show up for the standups, you shouldn’t worry about why they are late, but ask yourself why they don’t care. That’s your problem.

2 comments »

Posted in Agile, Development, Lean, Management

Tags:

Agile vs. Usability?

November 25th, 2008

Thre’s been a recent discussion around how agile methods face usability, mainly following Jakob Nielsen’s post about how agile, if poorly executed (that’s my opinion), can be a threat to usable software.

I don’t want to say again what was already said, and I believe that agile and usability can be a good match, as long as you know what you’re doing, but what sometimes bothers me is the common thinking around agile methodologies, that usability = what the client wants. I’ll explain.

In most of the agile projects I’ve been (not to say all of them : ) ), whenever there is some issue around how to make some feature in terms of usability, like “how should be the user experience around this operation”, the common answer is: “let’s ask the client..”.

Well guess what? The client never thought about usability in his life. Of course he used computers already, but he probably doesn’t know how to better develop an application to make it more usable. And this situation gets even worst when the client is just a proxy to the real user, who will probably not even work in the application being developed.

To give a pratical example,  if you asked a bunch of people how they would like to search for web pages in the pre-Google era, how many do you think would answer a “blank page with a text field on it”?

If this ask-the-client behaviour comes from pure lazyness or some cover-your-behind strategy, that’s another discussion, but what I think most agile teams should change in the way they work is to stop pretending that the client has all the answers, and trust a little bit more in themselves to create solutions.

And my guess is that the clients would also like it, because I don’t believe they want to spend their time answering questions like “which is the best solution for this problem: a select field or radio buttons?”.

And if you really want to trust the client to tell you how to build software, do it in a real HCI fashion, observing real users using your application and getting your answers from there.

Cheers,

Francisco.

7 comments »

Posted in Agile, Development

Tags:

Lean Workshop at Agiles 2008

November 3rd, 2008

Last October me and Danilo were in Buenos Aires, Argentina, to present a Lean Workshop at Agiles 2008.

The idea came from our perception that despite being one of the main buzzwords in the agile community, Lean and its origins are still a mistery to a lot of people, specially now in the current tool age , where kanban means a card wall with some numbers on it.

The workshop aimed at introducing Lean concepts through a hands-on activity, where the participants had to build a simple lego house in this 4 step process.

  • Step 1: “Buy” the Lego(TM) pieces and sort them by color
  • Step 2: Sort them again by size
  • Step 3: Separate the pieces required to build one house
  • Step 4: Build the house and sell it

If you are wondering how that turned out in practice, you can check the video here.

In order to go through all the Lean main concepts, the activity was divided in three phases, being the process executed differently in each one: a push system in the first, pull in the second and a single person workcell in the last.

Before every phase, we introduced the concepts that were going to be applied, and after the production, a “retrospective” was held to discuss good and bad points of the process according to the participants.

This way, we could stop and explain the needed concepts between each phase, and were able to go through push vs. pull systems, waste, kanban, kaizen, and work cells, among others.

The feedback we got was very good. All the participants we spoke to later said it was easier to understand what we were talking about when they actually implemented the ideas in practice, and felt the problems that each solution had.  What also helped is that most of the participants we’re being introduced to Lean, and this was the exact kind of public we had in mind when we prepared the workshop.

After the activity, a link with software development was made, but always making clear that creating software is not producing cars, so it is much more important to understand the principles then to apply the practices.

Cheers,

Francisco

4 comments »

Posted in Agile, Lean

Tags:

Change!

October 21st, 2008

Last week I’ve attended to the Rails Summit, first rails conference to be realized in Latin America (btw, excellent event :-) ), and one thing that attracted my attention was what Chad Fowler mentioned in his presentation (sorry Chad, if the words aren’t exactly the same):

Real experience is equal to change. For most persons, 9 years of experience mean 9 years doing things the same way, but experience should only count if you are continually improving the way you work.

This got my attention since I frequently see people trying to use agile methods as pre-made recipes, which you can apply without thinking, as in “my team uses Scrum, or XP, or FDD, etc..”.

It won’t be the first time I say this to someone, but the Agile Manifesto states:

We are uncovering better ways of developing software by doing it and helping others do it.

So nobody should be afraid of changing the way he/she creates software, or adapting the agile practices to his/her context. The best way to develop software is the one that works for you. Change!

Cheers,

Francisco

1 comment »

Posted in Agile, Development

Tags:

We Need Standards

October 17th, 2008

Have you ever read a project codebase (yours or not yours) where you could find different ways of implementing the same thing? Different ways of implementing controllers, of writing tests. Don’t you think that is really bad?

If you answered yes to all the questions, I can say: me too :D

Recently I’ve worked in this codebase that has evolved trough time having different kinds of implementation for most of its basic components: different templates, different tests, different controllers, mainly because each developer had its better way, and no one bothered to synchronize with each other.

The result is that every time you open a specific file, you are not sure what to expect. And I had worked on it!
I wonder how someone that had never seen the code would react..

When looking back in the way we developed it, I kept thinking in how it would be much better if our team could develop code as one person would, having the same way of constructing the same things, having… standards.

But standards? How about innovation? We’ll just keep doing the same s£%^ code for years this way.. I know what you might be thinking, I had the same thoughts in the first time.

But there is where I think we can also learn from Toyota. They have standards, but they can change at any time, and I believe this could be easily applied to software projects.
Just because all the team decides how to build something, it doesn’t mean that they have to do it during all the project. Agile should be evolutionary, so the current standards should be always challenged. We only have to make sure that at any given moment, everybody should know the ways we write code.

And if I’ve found some case where the way we write controller’s tests doesn’t work, I can change it, and make sure that everybody knows what I’m doing. And to do this I might need just two simple tools: communication and (maybe) a simple wiki, where the team can write the standards being used.

And how about the benefits?

Well, having coding standards, the knowledge transmission among the team will be much better, since everybody will be forced to communicate and discuss why we are doing things this way. As a secondary benefit :D , you’ll develop code that is much more compreensible, manteainable and well documented.

Cheers,
Francisco

10 comments »

Posted in Agile, Development, Management

Tags:

South American Tour

September 30th, 2008

To the brazilian and south-american audience, and also to whoever might be around there in October, I’m participating in two very interesting agile events that are happening in this month.

The first one will be “Talking About Agile” (Falando em Agile), which happens in the 23rd and 24th of October, where I and Danilo Sato, also from ThoughtWorks, will be speaking about problems with agile adoption in real world projects.

We will also be presenting in Agiles 2008, which will take place in Buenos Aires, Argentina, and will have a keynote with Mary Poppendieck, as many other great speakers. In this conference we will present the Lego Lean Game, introducing Lean concepts in a hands-on experience.

Cheers,

Francisco

No comments »

Posted in Agile

Tags:

What is Lean? And Agile?

August 25th, 2008

In my recent readings about Lean, I’ve found a very informative table, which tried to clarify the myths around what is and what is not Lean, and contained the following information:

Myth – What TPS is Not

  • A tangible recipe for success
  • A management project or program
  • A set of tools for implementation

Reality – What TPS is

  • A consistent way of thinking
  • A total management philosophy
  • An evironment of teamwork and improvement
  • A never-ending search for a better way

Despite Lean not being a set of tools, all we see in the IT industry about it is a lot of … tools. Cycle-time, kanban, flow, pull systems, you name it and someone has already announced it as the latest solution to software projects.

I’m not saying that this tools won’t help us developing sotware, but we will sure miss a lot from what Lean has to teach us if we don’t start thinking about principles, i.e., the second part of that list, the philosophy and the thinking.

And if you start to think about Lean principles, you’ll see that they don’t differ much from the Agile ones (at least what I think about Agile :-) ). If you read about an environment of teamwork and improvement, can you tell if they are talking about Lean or Agile?

But again most people, when thinking about Agile, think about practices and not principles. Instead of being collaboration and communication, Agile for them is pair programming, iterations and retrospectives. And this is where I think the solution is. Stop thinking about what is the next set of tools that will make us better, and start thinking about which are the principles we are following and how to better apply them.

2 comments »

Posted in Agile, Lean, Management

Tags:

About Retrospectives and Accepting Criticism

August 18th, 2008

I believe the most important point in any agile methodology is the possibility of improvement that is offered to the team through constant feedback and also practices like retrospectives.

However, I notice that sometimes teams are not used to question their own behavior, and make the same mistakes over and over again. This was also brought to my attention in one of the mailing lists I participate, where was questioned if teams do enough continual improvement.

These days, while reading the Toyota Way, I got some better understanding about it . According to the author:

Teamwork never overshadows individual accountability at Toyota. Individual accountability is not about blame and punishment, but about learning and growing.

And more important, in the words of Andy Lund, who is a program manager at Toyota and grew up in Japan:

People who have not been to Japan may not understand that the objective is not to hurt that individual but to help that individual improve – not to hurt the program but to show flaws to improve the next program. If you understand that deeply, you can get through that constructive criticism. No matter how good a program or a presentation someone makes, we believe there is always something that can be improved, so we feel it is our obligation. It is not an “obligatory negative”, but an obligatory opportunity to improve–it is the heart of kaizen

And that is exactly what happens in practice. People interpret suggestion and observations as negative criticism, and don’t see that the only way for a team to continually improve is to continually question its own behavior and face its weakest points.

Cheers.

No comments »

Posted in Agile, Lean, Management

Tags:

Student Syndrome

July 27th, 2008

One of the good concepts I’ve found while reading Goldratt’s books was the Student Syndrome, which Wikipedia defines like this:

Phenomenon that many people will start to fully apply themselves to a task just at the last possible moment before a deadline. This leads to wasting any buffers built into individual task duration estimates.

During the recent discussions about estimations, which happened in many posts, Chris Leishman wrote about the 3 reasons (P’s) for estimation (which are extremely correct, in my opinion), and selected performance as one of them. As Chris wrote:

The throughput (velocity) of a team is determined by the amount of ‘work’ being done over a given time-period and is measured in terms of the estimate.

After reading this post, I realized that measuring only delivered story points in an iteration (one thing I always thought was right), might not be enough to enable the full capacity of a team.

Explaining, story points are used as de facto standard in agile projects because they provide the separation between time and effort. This way, when I estimate a story as a developer, I have no time commitment to implement that story, and therefore cannot be blamed if I take more/less time than expected (what is probable, since estimation is just an educated guess).

While this practice is good because protects the developer from bad managers, at the same time it provides a lot of room for the occurrence of the Student Syndrome, since nobody knows if the story was completed in the predicted time or not, and all the buffers that were mentally created by the developers during estimation get lost in non necessary activities, like gold plating, for example.

And what I have been noticing in projects, is that stories that get played at the beginning of an iteration generally receive a lot more attention (necessary or not) that the ones that are being done close to the iteration’s end, which proves the concept that more work could be done, if we had some intra iteration kind of measure.

Despite being against the addition of any unnecessary metric to a project, I’m starting to believe that something should be done in this case, like reestimate stories in hours, or measuring cycle time instead of story points, or any other kind of practice that brings awareness to the difference between our estimations and what is actually happening in a story level.

Cheers.

6 comments »

Posted in Agile, Estimation, Management

Tags:

Uncertainty

May 20th, 2008

Project Uncertainty PrincipleThis came to my mind when I was watching this lecture, given by Ricardo Semler at the MIT Sloan School of Management, in 2005.

At some point in the lecture, Ricardo talks about intuition, and how intuition is very useful to solve problems, but still is not accepted in the corporate world.

In his words, talking about the chess match between Kasparov and Deep Blue:

How is it possible, at all, for something with 4 moves (Kasparov) to play something with 4.000.000 moves (Deep Blue)?

…. There is only one thing that he has that the machine has not, and that  is intuition.

…. Where are we putting intuition to play in the corporate world?

And this thought stayed in my head. Why the majority of people find it so difficult to accept intuition and to deal with uncertainty? In Ricardo’s words, why are we willing to trick ourselves and everybody else into thinking that we have control?

And why is this topic relevant to software development?

Because that’s one of the reasons that make agile methods so difficult to be accepted. Most people are not prepared to accept that the project duration can’t be precisely measured. Or that the scope should be flexible, because we still don’t know (oh my God!) what is important and what isn’t. And that the decisions we make should not be based on a complex function point calculation, but in simply in the team’s intuition?

Instead, they prefer to develop software in ways that have failed for many and many years, but still thinking on having control over all the project. They find easier to believe in an excel-calculated estimate for the total project of 170.1234hs than in an estimate that says “roughly 1 month”, and they hope to deliver software within fixed budget, size, scope and quality (good luck with that).

As Ricardo cited, it doesn’t matter if you are wrong, but you have to be precisely wrong.

Cheers

4 comments »

Posted in Agile, Management, Uncategorized

Tags: