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.

Anticipating the Next Tile

[via pfrhanzilicious on Flickr]In our development department we're currently working with two teams to build a new product. The platform team - as you might be able to guess - is working on the platform, the framework or architecture, however you want to call it. The other team, the one I am in, is working on the features, building on what the platform team provides us with.

Splitting responsibilities the way we do makes perfect sense. We do have those gray areas where it's not that clear whether something belongs to platform or might be a feature, but in most cases it is pretty clear what task belongs in what team.

There's one downside though, and that is that because each team is working on its own tasks, communication sometimes has to be pushed a little to happen. Although we're not working on the same tasks, we're still working on the same product and even if I can't interfere with how the other team is doing their job, it's interesting for me to know what they're doing and why they're doing it.

I want to compare that to my old version of Tetris on Nintendo's GameBoy (yes, the very, very old one) where on one side of the screen the next tile to come would be displayed. I distinctly remember that I deactivated that option, thinking that it wouldn't change my game. I didn't think that I even bothered to glance at that tile.

So, I did turn it off and... oh my god... I got so much worse! Without realizing it, I always noticed the next tile and some part of my brain clicked and made me integrate that information in my gameplay.

Why the comparison? I think that sharing information between teams works the same way. When I know what the other team does, what they're currently working on, what they plan to deliver and when they plan to deliver it, I can take that knowledge and have it in the back of my mind while I go about my own tasks.

Knowing what another team does might not directly affect my work. I think this is also one of the main reasons why communication between teams may be lacking a bit: Since our work is not directly affected, information about what happens outside of our little feature realm seems like a nice-to-know thing. I don't necessarily need it and it probably doesn't change how I should go about implementing my feature right now.

Nor do I have the power to do anything about it if I don't like it. Whatever the other team is working on will sooner or later pop up in my code anyway. As long as I don't have a say in that matter, why would I want to know any details? (I might be able to mention my concerns and ideas, though. So that's a plus as well.)

However, developing with new tools and technology brings enough surprises as it is. Eliminating what other surprises - even little ones - there might be as best as I can means that I can work more comfortably and confidently on my own tasks. It gets me out of the little vacuum of my team and reminds me that there is a world outside of the feature set currently implemented. And whatever happens in the future I might at least have heard of it before.

Productivity Tools: Launchy

I started to use simple productivity tools while reading The Productive Programmer by Neal Ford. Although there were a lot of tools for all kinds of things mentioned in this book, I decided to go slow and pick just a very limited selection and see whether they made any sense for my way of working.

I picked Launchy for my Windows PC and naturally Quicksilver for my Mac. Though Quicksilver is a lot more interesting and powerful, I didn't really get around to play with it as much as I'd like, mostly because I use my Windows PC a lot more than my MacBook.

Launchy in comparison offers mostly basic launching functionality. It's running in the background and can be brought forward by holding alt and hitting the space bar. You can probably change the keyboard shortcuts, but the default combination is pretty comfortable and easy to use, so I just left it as it was.

You then start typing the name of the application or file you want and Launchy scans its catalog (we'll get to that in a minute) for it. It will offer the most likely choice, which you can then open directly by hitting enter. You'll also get a list of other matching results that you can access using the up and down keys or click with your mouse.

As for the catalog, you need to set up the catalog by telling Launchy which file types in which folders should be part of the searchable catalog and then scanning your machine accordingly. At the moment I included all applications and folders and .doc and .pdf files from selected folders.

Launchy proved to be a perfect tool for people like me who keep their desktop very, very clean and usually access files and applications by using quick launch or navigating directly to the respective folder. I like to have sensible folder structures to put my files where they belong from an organizational point of view. On the downside that means that I have files all over the place and need to change folders very often. Launchy makes it very easy to access a file or folder and saves me from having to click through folder after folder and search through a long list of file names to get to the stuff I want.

I wouldn't have expected that radical a change, and from the outside it probably only looks like a small thing, but I honestly wouldn't want to go without Launchy now that I've gotten used to it. The only disadvantage I noticed so far is that you have to rescan your catalog every once in a while to make sure that new files and applications are added to the catalog. I'd also like Launchy to get a few extra features, bringing it a bit closer to the power of Quicksilver (an application I wouldn't even dare writing about, because I feel like I've used to less than five percent of its capability so far) than it is now.

However, I can only strongly recommend that you try it out for yourself. You can download Launchy at http://www.launchy.net/. Plus, it comes with a cute icon. Just saying.