Defending Whiteboards

What I especially love about the video below is that it shows how utterly important whiteboards are if you want to work creatively in a team. I can't stress this enough, and I also seem to be the greatest defender of whiteboards in our development team and the first to add "No whiteboard in conference room" as an impediment to our taskboard.

Even now the whiteboard in our current team office is far too small for my taste. To compensate this we have pinned big sheets of flip chart paper pads pinned to the rest of the walls. My old Scrum team was located in two room, so we had two whiteboards, but that still wasn't enough at times.

Especially during design phases you need room to sketch. In a Scrum team with five developers it is not uncommon, if not preferable, to have two user stories running at the same time which means you need two designs, which means two whiteboards is the minimum that you can work with. I would still argue you need more for any technical problems, additional tasks or just whatever pops up.

Even when you constantly erase what you don't need, we often came to a point where the only option left was taking a picture of the whiteboard to make room for the next problem. That worked, but it is still a limiting factor when you need to organize your creativity.

A thing as shown in the video where the same content can stay on the whiteboard for days and maybe more so that people can always come back to the design, rethink and rearrange sounds too good to be true.

On the other hand, I'm not complaining. As a creative team, we find ways to be creative and work within an informative workspace. As I said, flip chart pads make a good whiteboard-ersatz for a lot of problems. They don't provide the flexibility a whiteboard does, since you can't easily erase stuff, but they generally work well, too. You can also get cheap pinboards at IKEA (and probably elsewhere) and use these to put up reminders. Or you can hi-jack whiteboards in other offices that are currently not used.

I still believe that whiteboards are one of the most important tools you need when working in an agile team and you can never enough.

Scrum 101 - First Thoughts

We've been working with Scrum for a few month now and so far it has been a very interesting few months. For all of you who don't know what Scrum is, here's the gist:

Scrum is what you might best describe as a framework for agile developing. The reason why I'd call it framework is because it doesn't so much tell you how to do things, but it provides a set of rules and roles that surround the actual developing. The key of Scrum is the team itself, which is self-organizing. Development cycles are usually two to four weeks. At the beginning of each cycle or "sprint" the team commits to deliver a certain set of user stories, then works on these stories and holds a sprint demo at the end of each cycle to present their results to whoever is interested.

There's tons of information about Scrum on the internet, so if you want to know more, you can either ask me or use your favorite search engine.

What I learned in these past months is that there are a few key things that you and your team need for Scrum to work. One of them is transparency. The other one is discipline. If one of them is missing, you might just be heavily screwed.

When I said transparency, I could have just as well said communication. It sounds so clichée, but communication really is the key. I still like transparency better because it sums up nicely what Scrum is really about and good communication is the way to reach transparency. I don't think you can have one without the other. Or, okay, you can communicate without actually being transparent. However, I don't see how you get transparency without communication.

When you start working in a self-organizing team, stuff gets lost. It just happens. All the time. We've identified communication (or the lack thereof) as one of our key problems after the first sprint and we're still working on improving ourselves. It's surprisingly hard.

Which leads right to the other thing: discipline. It sounds so school-masterly, but it's true. I'm not talking military drill discipline here, just a healthy dose of get-your-crap-together. Because truth is, if you don't, the rest of the team will suffer for it. The lack of a team lead means that the team is responsible for what they do. There's no single person in charge or responsible.

To be honest, it is kind of scary at times. Self-organizing sounds so cool in theory and it is kind of cool in practice. It has its drawbacks though. When there's nobody to tell you what to do, there's also nobody to tell you what not to do, what better to do or how to do what you do. The team has to figure out how to finish their goal and often that's not as easy as it sounds.

When I talk about discipline in Scrum I'm talking about doing the best you can to get your tasks done. But more than that, I expect you to always think about what needs to be done to get everything delivered with the best quality possible. I expect you to not ignore any problems in hopes that they go away if we don't talk about it. I expect you to think outside of the borders of the taskboard. Also, in times of increased crankiness, I expect you to suck up and be nice. We all have bad days.

Discipline doesn't mean working non-stop cranking out code. It also doesn't mean sticking to fixed rules and doing everything by textbook. And it should never ever mean not having fun.

Working in a self-organized team requires communication, transparency and discipline, because as a team member I depend on the rest of the team. In short: I need to trust my team to be able to work effectively. So I'd like to add trust as another key word for Scrum teams, but that's a story for another post.