10 ways to misuse cards on the wall
February 7th, 2009
Having cards on the wall is one of the most basic agile practices. Writing index cards or post-its and sticking them on the wall is fun and makes the work place look cool and organized at the same time. What we can’t forget, though, is that just having them there doesn’t make any team agile. And we can tell something is going wrong…
- When people work on features that are not on the wall
- When there are no priorities for the cards
- When people don’t work on the highest priorities first
- When people work on more than one card at the same time
- When just one person can tell the current state of a card
- When people don’t have a clear definition of Done
- When people have to be told what’s the next card they should be working on
- When the wall is not constantly updated
- When just one person updates the wall
- When people can’t tell how they are doing by simply looking at the wall
These are clear signs that the wall is not being as helpful as it could. And if these issues are not being worked on along the way it may not take long before people start questioning the use of the wall in the first place.
Nice post.
I guess that “When people have to be told what’s the next card they should be working on” is my favorite (maybe because of the challenge and motivation).
Ivan, tell me. How can I learn agile without a team to work with or a coach to teach? I try to read some notes (not books), but it seems that I must have a team – or I won’t learn agile. Is that right?
Actually… I guess I know how to answer my question (duh): “I can’t learn (and use) agile without a team because agile is all about people.”.
I’d say that’s not completely true. When we talk about people we’re not only talking about the team. Customers, users and any external collaborators/stakeholders are also affected by the practices used during development.
In this case there’s always room for learning and improvement. You may not have a chance to apply all the agile practices you read about, but you definitely have a chance to play with them and, most important, evaluate whether they fit your environment.
Hmmm.
That’s a great idea. I guess I’ll use unit tests, DDD, Repository & DAOs (I’m starting to understand the differences between them) and (I hope so) integration tests (maybe the most toughest [sorry, but I don't know if this word exists]). What do you recommend for integration tests? FIT?
Those things that I said above are agile practices, right?
The question is that I’m in the last year at University. So, I’d like to use agile practices at my final work. That way, I can show some companies here in Brazil that I have a little of agile in my blood
What do you think?