Scrum – Here Be Subtlety

Blame versus Bullshit

In one of our sprints I had worked with another developer to fix a bug that we found in one of the modules already implemented and integrated into the Main codeline. The bug must have been there from the start and it accidentally deleted an attachment from the database if it was considered too big to be handled by the UI. It was fairly easy to miss, although not exactly a minor bug. You just had to stumble over it at some point and we did.

During the sprint demo we mentioned this bug while going through the list of important bugs we fixed and it quickly turned into an argument with another developer from a different sprint team about whether this really was happening (it was, data was deleted from the database, we CHECKED), whether it had any side effects (it did, only those were the same side effects that had already been there from the start) and when this bug was introduced (guess what, nobody cared, it was a bug, it was fixed, end of story). The quote that stood out though was the overly awesome „Then it was not my code.“

So here’s the thing. Nobody cared. So far nobody had blamed anyone. Nobody had checked source control to see who was to blame, because so far nobody had thought about checking. Once we had found the reason why data was deleted we started working on a solution to not let that happen. Then we closed the case.

Naturally after the sprint demo the first thing to do was to actually check who introduced the bug. I don’t need to tell you, who it was, do I? On the plus side, from that day „Not my code“ became one of the most quoted lines in our office.

Here’s the thing. In our development department there was a lot of healthy blame going round. By healthy blame I mean the kind of blame where you find something wrong or strange in the code and you go to the person who wrote it and ask about it. It’s the blame where when a feature goes wrong you go and have a talk about why it happened. It’s the kind of blame where when you find awkward code you sit down with the developer who wrote it and go through the code.

To sum it up: You might name names, you find the responsible person, you point out the error. But you do it because you want to improve the team, the code and the process. This is not about telling someone that they are stupid or pointing fingers and feeling superior. The fact was, everybody was doing it all the time.

Yes, even this kind of healthy blame might feel bad sometime. It’s not your favorite moment of the day when someone stands at your desk telling you that you probably did something wrong. It’s also not your favorite moment when you have to go to someone and point out a bug that you found.

Here’s the thing: It’s not personal. It made people aware of when they didn’t understand a concept. You would sit together and figure out what the issue was and how it could be solved. It made you re-evaluate how you went about implementing something and probably made you vow not to do it again.

Basically, healthy blame can be relabeled as „learn from your mistakes“. The only thing is that in order to learn from your mistakes someone actually has to come up to you and tell you. Otherwise it simply won’t happen. So embrace the blame. And as the blamer be prepared to be proven wrong. It happens all the time as well. That piece of weird code might actually have a reason – it just needs better comments.

What this has to do with „not my code“ is very simple. In an environment where blame is not considered evil, you don’t care about who did what and when. If it’s something serious or discussion-worthy you will seek out the person responsible. If it’s nothing serious, and easily-missed bug, some inconsistency or some code lines that aren’t exactly pretty, you just fix it, be done with it and move on the next thing. And that’s what we did.

The Long-Lasting Effects of Scrum are Not Yet Known

Recently I moved from a Scrum team to a non-Scrum team. I was kind of aware that after nearly a year of doing Scrum (a total of eleven sprints) this would make a difference to me, but only now can I say for sure how that affected me and my perception of work in the first days after switching from Scrum to non-Scrum.

Frankly, it’s kind of terrifying. This is even stranger since for the most part of my work experience so far I have worked in non-Scrum environments. It seems like the Scrum-experience is indeed a bit intense and has an effect on you that you might not expect.

The way I work now can be loosely described as „there is no defined process“. In other words, there’s work to be done and the goal is to get that work done on time. That’s it.

During the first week I was confused by the lack of daily Scrums. We had daily Scrums at 11:30 am and I noticed that around that time I got slightly nervous and had to remind myself that there was no daily scrum. No more. I could just keep on working. Similarly the lack of daily feedback irritated me. How would anyone know how far I’d come since yesterday? How would I learn what everybody else was doing? (The answer, of course, is simple. They could ask me. I could ask them. Done.)

Apart from that, the lack of tasks is even more irritating and it still gets me from time to time. How long am I supposed to work on this? When is it done? When I should I start worrying about how long it takes? How long is it supposed to take anyway? Help!

Fortunately, I think these are just minor withdrawal syndroms that I will get over soon. But still, I find it interesting how the way Scrum works and the way you work with Scrum can affect you, especially if suddenly you find yourself NOT doing Scrum anymore. The bottom line is, Scrum provides a safe (or seemingly safe) environment for the team to work in. Things are clear. There are rules. There are numbers. There are timeframes. There are commitments. There are dates. There are times.

With all these things gone, you feel lost. (You really do.) The challenge now will be to create a safe environment to work comfortably in without all these fixed things surrounding you.

I will be working on that.

Don’t Call it Scrum.

We’ve been practicing Scrum at work for about nine month now. We got from one team to two teams and will be moving back to one team in a short time (although not really, but more about that later).

We’ve been constantly redefining the process. Sometimes it was little changes like coming up with a few easy rules to make daily scrums move along faster. Sometimes it was bigger changes like defining a new way to do estimation sessions.

In the near future we’ll be adding more teams to work on our product, some of which are offshore, which forced us to rethink our process. Currently nearly everyone working on the product is located in the same office, even on the same floor, so communication between Scrum teams, ScrumMasters and product owners as well as others involved in building the system has been easy and uncomplicated. This won’t be the case once we have teams in another country or even another continent.

One key change that has already been made is that the design phase has been dis-integrated from the actual work of the Scrum team. A designer who only recently was a member of one of the Scrum teams is now working with the product owner, defining designs for user stories.

Estimation meetings now take place with the product owner and designer present. Estimations are therefore made based on the existing design. This is not necessarily a bad thing. In fact it takes some of the risk out of the equation for Scrum teams. We no longer have to estimate something without having a design. Also, since the design is mostly made by one person in collaboration with the product owner and whoever else is of help, it ensures consistency throughout the system.

However, it makes me wonder whether we have already stopped doing Scrum and might just be doing agile. Not that this is bad in any way, it’s merely a question that I might ask. How far can you go from the process as it was defined before you have to admit to yourself that – while what you’re doing is Scrum-based – it’s not longer what you started with.

Is this a bad thing? Not really. In fact, it could come as a relief. Once you’ve drifted so far from the defined methodology that have to stop fooling yourself that you’re actually doing it, maybe it’s time to take a step back and review all the things you’re doing , re-evaluating what is working, what might need improvement and what is simply a waste of time.

On the other hand, sticking to a methodology makes you less eager to give up something that you might not like as long as you’re convinced it is a part of the methodology. (I.e. because daily scrums are such a key item in the Scrum process, you’re less likely to skip them even if you don’t like it.)

In the long run, Scrum is just a word. We might be on the brink of letting go of what makes Scrum Scrum, recognizing that we have our own agile process that has no name and probably doesn’t even need one. Whether we get there and how we will go on from there, I have no idea. But I hope it will be fun to find out.

Should Sprints End on a Monday?

Last week was the final week of a sprint and things were starting to get emotional. We were running out of time and probably the only reason we made it was that people were staying late to finish up stuff. The last day before the sprint demo, we were testing three forms, praying that we wouldn’t find anything that would need fixing and push us into another round of testing.

We were mighty lucky. No major bugs were found, and we only had to do a second round of testing on one form before I could leave on Thursday around 8pm – and out of the four of us I was the first to leave.

Then again, the sprint demo went really well. Everything worked, we could answer all questions, we were prepared, we had a list of bugs that we knew were there but couldn’t do anything about it. Two small bugs popped up during the demo, but that was okay and the sprint was successfully signed off by the product owner.

That was a Friday. We usually have the demo in the morning and the retrospective in the afternoon. However, the team was pretty exhausted, and I was fighting headaches, so I asked for the retrospective to be moved to Monday.

Today we had the retrospective and it went well. We could focus on the problems we had and come up with action items to help us avoid those in the future – just what you should get out of a retrospective. In fact, I personally think it was one of the best retrospectives we had.

I wonder whether it would have gone equally fine if we had dragged our sorry tired behinds to a retrospective after two long nights and nearly one and a half hours of sprint demo. There were a couple of not-so-nice things that had happened during these last days and I still felt pretty emotional about those. I can do pretty well with sucking things up, but a retrospective is all about talking about what went on during a sprint, so I wasn’t sure how well I would hold up.

My feeling is that while you should absolutely do a retrospective right at the end of a sprint it might be a good idea to do it on a Monday instead of a Friday. There’s a whole weekend between the last day of the sprint and the retrospective and it can definitely help calming things down. A weekend gives you time to let go of all the emotional stuff and get a bit of distance while still keeping memories fresh enough for a productive retrospective.

This leads to another idea. What about a sprint demo on a Monday? This could have two advantages:

1. The sprint team and everyone else involved can come in refreshed after the weekend, possibly with more energy than they would have on a Friday.

2. If the team runs into the unfortunate situation of not getting it done, they still have the option of working on the weekend. I know this is not something that people like to do, but in some cases working a Saturday might still seem like the better option than failing a sprint. Basically, having a weekend between the last day of the sprint and the sprint demo gives the team two days they could use if things go very wrong.

I wonder if this is worth a try for the next sprint. If we actually do change the schedule, I’ll keep you posted on whether it really makes a difference (and – if yes – whether it actually is better).

Meeting Flavors

Meetings are probably a very controversial topic in the everyday company world, and it’s just as controversial when it comes to software development. Meetings can suck the time out of your week and the life out of you if done wrong.

However, if done right, meetings can be one of your best tools for communication and knowledge transfer. In my opinion you just have to remember a few simple rules and think about meetings coming in a very limited variation of flavors.

The purpose: Result or information driven

When I say that meetings can be either result or information driven, I mean that the goal of the meeting can either be to reach a specific result or to pass on information (or both). Working in an agile information, I am in both kind of meetings all the time.

A typical planning meeting is result driven. At the end of the meeting we are supposed to have decided on the user stories the team will we working on for the next couple of weeks. We usually have small design sessions during a sprint, whose intended result is a working and agreed design.

On the other hand, we regularly have meetings where the main point is to get information across. Usually these are cross-team meetings, but daily scrums could also be seen as mostly information driven.

In most every case the purpose of a meeting is a bit of both, but it should at least be one or the other. In other words: Be clear what the goal or purpose of your meeting is and make sure that others understand it. It’s only fair to the people who attend your meeting to know in advance what they’re in for and what they can expect.

The style: Discussion or presentation

The style of a meeting can also vary. It can either be a discussion where everyone is invited to throw in their opinion and discuss a certain topic. Or it can be held in a more presentation-like style, with one or more people presenting while other attendants may discuss key points or ask questions.

Again, there’s not one or the other, but rather a mixture of both styles. A presentation without a bit of discussion will easily bore other people, while a discussion without a bit of a presentation of the issues to discuss will likely get out of hand when nobody knows for sure what the meeting is about.

Just like with a meeting’s purpose, the style of a meeting should be clear, make sense and be properly communicate to the participants.

That’s it.

For me, that sums it up. Sure, you could argue that there’s a lot more to it, and there probably is, but going with these four characteristics – or basic meeting flavors – I find that I can easily describe the kind of meeting that is most helpful for any given situation.

And to leave you with a few more meeting wisdoms from my work experience, how about these two:

Always, and I mean always, end a meeting with a result. Never wrap up a meeting without a follow-up e-mail, a list of action items, a working design or at the very least a set of notes. A result can also be to meet again (that would fall into the action item category) or to ensure that everyone is on the same page (get a short feedback from all participants and send out an email with the main points summarized). Never, ever leave a meeting empty-handed. For me, this is the best indicator that something went wrong with the purpose of the meeting.
Besides, meetings will be regarded less like a waste of time of it’s obvious to everyone that something came out of it. Getting a e-mail with a summary of all the discussed points will remind people that they didn’t waste their time being stuck in a room with too little air.
Make sure someone is the designated moderator for a meeting. Even for a meeting that is mostly a discussion or one which consists of several presentation by several people, there should be someone who acts as the owner of the meeting. That someone should start the meeting, wrap it up and make sure that there are no loose ends. You might be able to bend on this rule for more informal meetings, but be careful if you do.

If you do meetings right, they can be a helpful tool without getting on everybody’s nerves. Following a few simple rules should make that a bit easier.

That Calm Before the What?

Today was an oddly relaxing day at work. Tomorrow will be the last sprint demo of the year, and my team and I are pretty confident about the results.

However, it’s always a strange feeling you get so close before the finish line. You half expect something big to show up and show its nasty face, just like it happened last time – and that wasn’t a great experience.

But today I realized there are a few things you gotta learn to stay at least half relaxed through the whole Scrum thing.

First, I’m sure that no matter how well everything is going, you always expect something big to happen at the very last minute. We had three bugs popping up in the last 48 hours and dealt differently with each of them:

The first one was fixed by a developer yesterday evening and had unforeseen consequences. Basically, the original bug was fixed, but in its place a new bug appeared. Since the developer is on annual leave for the rest of the year, we decided to roll back the changes and get back to it in 2010. The original bug really was an edge case „only-happens-when-somebody-screws-with-security-settings-anyway“, so it seemed like the right call to get everything back to how it was before and tackle the problem with fresh energy.
The second bug turned out to be an already known bug in slightly different clothes, so we could move it to a different team’s queue and just check it off our to-do-list.
The third bug was brought to our attention by someone from another Scrum team and that one was also moved to the queue of bugs to fix in the new year. It actually was something left over from the sprint before this one. Plus, another developer on my team was smart enough to whip up a small test project and realized that it actually was a bug in the standard Silverlight control, and not in our code, so the solution might be to just file a bug report with the Silverlight guys.

What I’m trying to say is that the first thing I tried to find out about each problem is whether it would affect the sprint demo. In each of these cases the answer was „no“. Yes, some of these bugs need fixing, but none of them were critical and rather than letting panic reign the day before the demo, we decided to just keep our cool and assess the importance of each bug.

And yes, each bug fixed is a good thing. But sometimes, a bug hastily fixed in time for a demo is no good at all. We learned our lesson the hard way four weeks ago and we all agreed we would never make that mistake again.

So I’m still crossing my fingers and hope that we didn’t miss anything big. And I realized that I need to get used to the feeling to be afraid to have missed something. Apparently it doesn’t go away. However, if you learn how to deal with it, it’s not that bad. First, accept that this is how you feel if you care for what your team has done. Second, let go of the little things. There will always be bugs. But, if you’ve done a good job, there will be less.

Everybody Loves a Code Review

Today we had an impromptu code review during a meeting which is actually intended for our feature teams to get together with the platform team to discuss any issues, ask questions or just address anything that might be of interest to others.

This time it was mostly our team trying to get some input on problems we already had discussed within our team but felt we could need more people to chime in on and collect new ideas.

My main issue was that I felt that I was stuck implementing the UI for a pretty straight forward feature. Unfortunately, though it was straight forward, it was also fairly non-standard. The good news was that we had implemented similar features already. The bad news was that we had implemented different parts of what I needed (or thought I needed) in different features, so I was taking code from three different features and trying to mesh it together for what I needed. I had come to a point where it was kind of working, but not really.

I had also come to a point where I didn’t know where to start looking to solve the issues I still had. Our team lead told me that she’d take a look at it with me to figure out where the problems were. That was pretty much what I was looking for, but since I was pretty frustrated already I went on a bit more about… well… basically about how frustrating it was that I was digging through code that I felt I should understand, but really didn’t. I guess my frustration showed, because the next thing I knew, I was asked to bring my laptop so we could all have a look at the code and figure out where the real issues were.

There were six of us and it took us about an hour to get through the main parts and leave me with a pretty good idea what was still missing and how to solve it. As it turned out the code wasn’t half as messy as I thought it was, but I had made a couple of stupid mistakes, mostly due to my inexperience with frontend development. We got to tidying up the code a bit and got the feature up and running (with a couple of things missing, but still).

At the end I wondered whether I should feel bad for taking up five developers‘ time to look at my code. But you know what: I think I shouldn’t. Both my team lead as well as another developer from my feature team said that they actually liked the small code review session and I got the impression that everyone else liked it as well.

Here are a couple of thought on why code reviews are good for everyone:

Everyone looks at code differently. Everyone thinks differently, so you get a lot of new ideas you would have never though of.
Everyone has different experiences, so it’s a simple way to learn new stuff. It’s also a good exercise for explaining things to others.
You’ll see problems and issues popping up that you didn’t know where actually a problem. This also goes for pretty small and random problems that otherwise would have never been mentioned. So now you have a chance at solving them.

Basically, code reviews are a good way to solve an actual problem, but it also might reveal a couple of underlying problems that people weren’t aware of before. It’s a nice and communicative way to get your brain working, whether you’re more of an expert in the matter discussed and are suddenly forced to explain concepts to your colleagues or whether you’re the one with the questions trying to find a solution to the problem at hand.

If you’re someone who doesn’t like to present your messy code to others for fear of being thought of as stupid or if you’re someone who doesn’t like to throw ideas around the room while purely looking at code projected on the wall, code reviews might not be thing for you. For a code review to work you can neither try to hide your coding mistakes not can you point fingers and laugh. It can turn out to be a challenge for everyone, but it can be a pretty rewarding challenge at that.

I guess my main point is, if you feel like a code review could help, do it. If you’re the one with the problems, don’t be shy. Everyone makes mistakes, everyone has problems understanding different things. People understand. If you’re someone with more experience, share it. Explain. And for everyone involved I would just say: Ask. Help. Suggest. Try. Enjoy.

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.

Kategorie: Scrum