My Slides From My BBC Develop Keynote

I had a great time at the BBC Develop conference in London this week. The BBC were gracious hosts, the audience had some good (and not too easy questions) and the program had some really good talks; so I learned quite a bit and met some excellent folks. Special thanks to Tanya Rai, Colin Savage, and Simon Stevenson at the BBC for inviting me and putting on a great day.

Some upcoming talks (Stockholm and London)

Since getting to Spotify, I’ve been thinking a lot about what makes a good engineering culture and the best way to create, nurture and protect it. There is no simple formula, but I’m starting to understand better the things that have worked well in both the small startup teams I worked in as well as the big corporate ones. I’ve got two talks coming up where I’ll outline some of these thoughts. I hope that it will be insightful or inspiring to others. At least there will be some amusing anecdotes 🙂

I’ll be doing a short talk on Thursday next week at Valtech Days in Stockholm. My talk is specifically on doing real work using Lean and Agile techniques, based on my experiences building products at Microsoft, Adobe and Spotify. The line-up looks really great. It will be an excellent event.

On November 12th, I’ll be keynoting the BBC Develop 2013 conference in London. This will be a much longer talk where I go into the Spotify model of Lean and Agile development, and how it has grown a strong engineering culture. This event looks really awesome. It should be a really informative day. I’m really looking forward to it.

I’m not sure if either of these will be recorded, but I plan to continue talking about this as I keep working on these issues at Spotify. So if the subject is interesting to you, but you can’t make it, stay tuned.

Why I love physical agile boards, part two

I thought of this as I was writing the previous post, but decided that it was important enough that it deserved it’s own discussion.

Another benefit of physical agile boards is that, by their nature, they tend to limit the scope of your planning. To some, this may sound like a bad thing. It is actually one of the most difficult disciplines to maintain in agile development.

One of the things that distinguishes agile development from older development models is that Agile keeps the time horizons close. This is beneficial because the nature of software and systems development is ever changing, and long-term plans are almost always upset by the realities of the industry and of development itself.

Even strong agile teams see opportunities and features that don’t make sense right now, but they know they will want “someday,” The tempting thing in Scrum is to add these into the backlog, so that they aren’t forgotten. In Kanban, they may go into the “not started” column or some other “feature stash” (The Product Owner and I had a secret Trello board called this when I worked on Revel at Adobe). These far-off stories and epics become their own drag on the agile process, slowing down backlog grooming and sprint planning as the backlog becomes less and less manageable and stories get re-added because no one can find anything.

A physical board actually makes it physically difficult to do this kind of faux-waterfall long-term planning. There just isn’t anywhere to put the post-its/cards! The Product Owner may still have their personal feature stash somewhere, but it won’t become a drag on the whole team.

Similarly, the lack of physical space makes it difficult to over-plan the stories that are in front of the team too. When I was doing Scrum as front-line engineering manager, I found it difficult to figure out how many stories we should break down for a sprint in order to not run short. The tendency was always to task out a lot more stories than we needed, just-in-case. The virtual board makes it easy to plan as many stories as you want. In practice, stories have dependencies on each other and if you over-plan, you tend to just write incorrect tasks.

A physical board encourages you to plan just as much as you need, and not much more.

Why I love physical agile boards, part one

After years of exclusively using virtual Scrum and Kanban boards, I am using physical boards again. In the process of adapting, I’m rediscovering many great things about using a physical board. One benefit of a physical board that I didn’t expect is that your stories and tasks tend to be less formal.

Last week there were two stories on two different team’s boards that made me laugh. One was:

20130825-194731.jpg

The other (which I didn’t get a picture of) was “do the thing with the thing“.

A good agile coach would point out that both of these were under-specified and poorly written. A better agile coach would point out that as long as the whole team understood what they meant and there was an agreed-upon definition of done, then the wording doesn’t really matter that much and it is fine for the squad to have an occasional story like that.

Neither of these would have ever appeared on a virtual board. By being on the computer/net, the virtual board has two features that the physical board does not.

One is longevity. “Do the thing with the thing” is fine if it is a story under discussion every morning at standup, and tossed in the trash when it is done. “Do the thing with the thing” would be a cryptic mind-f*ck a few years or even weeks later if someone was reviewing old stories.

Now this longevity element is something that I used to like with the virtual boards, having the history and being able to see how things developed and where they came from. In reality, you don’t really ever have time for that and instead it becomes another digital barnacle that isn’t really that useful.

Another property of a digital board is transparency. Theoretically, anyone in the company can see it. This again, is both a positive and a negative thing.

Having a board that anyone can see means that what your team is doing, will do and have done is available to anyone. Status reports are (theoretically) not necessary. If anyone asks what you’re working on, you can tell him or her to go look at Trello/Pivotal/Jira/etc and bug you if they have any questions.

With a physical board though, they need to come to the team and look at the wall. This means that any misunderstandings can be cleared immediately, and communication is actually improved by, you know, people speaking to each other.

When you are creating stories, tasks and notes on a virtual board, you are writing for an indeterminate audience. You are writing for yourself and your co-workers, but you never know who else will be reading it. If something you write has to make sense to anyone, ever, you will be a lot more guarded in what you say. You will be wary of not only how the story is perceived, but also, how you as the author are perceived. It is the difference between the conversation you have with a coworker over a beer and the item that you post to a blog or twitter.

That consciousness of the potential audience takes all the spontaneity and fun out. The formality makes stand-ups and planning take longer as well.

If you work on a co-located team and are using a virtual board for your agile practice, try going old-school for a while. I’m betting that your stand-ups and planning will go a bit smoother if you know that the stories and tasks that you write are for your team’s eyes-only.

Whatever you do, don’t forget to do the thing with the thing, and while you are at it, unf*ck everything.

[see part two: where I discuss how physical boards help you keep a manageable time horizon to your planning]

Moving to scrum: changes

So we started this product cycle with two geographically-dispersed mixed-discipline scrum teams on two week sprints. Specifically, the geographical co-mingling was designed to break up some of the silos that had built up on the team due to the existing functional teams being in different cities. By the third sprint, we’ve now switched back to scrum teams that mimic the original functional and geographic splits and are now on four week cycles. This has made cross-team communication more difficult, but has made everyone a lot happier by keeping the scrum meetings more relevant to everyone on the team. I can definitely see why people like this more, it lets people focus on what they are doing, but I do think we are losing something by not spreading the knowledge of the different parts of the project around the team. Also, not having multiple functional areas represented in the scrum meetings means that some fresh perspectives are lost in any of the technical discussions that come up. Over the next few sprints we’ll try this out and see if this is working. I think this will probably be what we stick with, and we’ll need to address the cross-team communication issues separately.

Switching to four week sprints was mostly to reduce the amount of time spent in the scrum meetings themselves relative to the amount of working time. Between planning poker, retrospectives and sprint planning, a lot of time is lost to the process itself in a two week sprint. For a team used to working on 6 week sprints, fitting stories into 2 week chunks was also difficult. I like the idea of two week sprints, but in practice, it was difficult for a team that is new to scrum. We’ll maybe try 2 week sprints in a future product cycle.

We still haven’t switched to our planned internally created scrum tool which itself makes things difficult. Our backlog is an excel spreadsheet and our tracking is all on Wikis. Hopefully, we’ll be converted over to the tool by the next sprint, which should make life a bit easier on me and the scrum master.

Moving to scrum: breakin’ the law

Well, part of the whole idea is that scrum isn’t a hard-and-fast set of rules right? I had some meetings at another office last week which necessitated moving out our first sprint review and retrospective a couple days. So if one of the guiding principals of scrum (and agile in general) is that the dates don’t change, everything else does, that got blown right out of the gate.

Some new stories came up as part of the sprint wrap-up which means that we’ll need to do a new planning poker session. Also, some other things came up which mean that there is a bit of housekeeping to do before we start the second sprint. We’re now in some uncharted zone between two sprints while the product manager and scrum master do some cleanup while the scrum teams do some off-book work for a couple days. Yeah, not ideal, but we’re trying to get it back on track. This sprint was going to be a throw-away anyway as it involved a lot of transition and getting used to the framework.

The retrospective brought up some really good issues and some innovative suggestions from the team on how to handle them. If the suggestions work out, I’ll post them here eventually.

There are still some folks unclear on what we expect to gain by transitioning to a new development process, but most of the team is embracing it as a good experiment and chance to try something new. For the most part, everyone seems to have an open mind and that definitely makes a huge difference as we all try to figure this out together. It hasn’t been the smoothest transition, but so far so good, I think. We’re definitely not as productive as we were before (so far). However, I think that the discipline provided by the product backlog means that we are actually getting the most important things done first. That makes a huge difference.

How I know that I’m still an engineer and entrepreneur at heart

We were looking at a demo of an agile-project tool yesterday. The tool itself was pretty good, but I just kept thinking about how I could write it myself and how much fun that would be. Then, once I looked at the cost of the license, I had to restrain myself from taking a week off and writing a competing tool that I could release as open source or sell at half the price.

Oh build-vs-buy, you always throw a bucket of ice water in the face of my reveries!

moving to scrum: The First Planning Poker

That could have gone a lot better.

I had originally prepared the product backlog with stories that were way too large. I think that I was confusing the role of the Scrum Product Owner and the XP Customer a bit. I was worried about “being polluted.” After reviewing the Scrum planning process again, I realized that I really needed to break up the top priority stories. I took the top dozen and broke them up into around 40 smaller stories. Some I left for the team to break up as an exercise. I needed input from the team leads to break up a few of the stories, so I left them as epics. There were a few stories that defied division. These were large design tasks. We have to interface with a couple other teams and get some customer feedback, so we need to have some initial designs to present that are somewhat comprehensive. I knew that this would be difficult to incorporate in an Agile process, but it is a part of our work and I wanted to try and assimilate it. We also had some carry-over work from the previous release and some open-ended consulting that we needed to account for in our estimations. The carry-over work was interrupt-based, basically bugs found by other teams that we would need to turn around quickly. To incorporate this into the planning, I created a story at upmost priority to account for this possible work.

Given the distributed nature of the team, I decided to do the planning poker on-line. I booked some video conference rooms, but also a phone conference. Since physical cards would not work for us, we used Adobe Connect (‘natch) with a polling pod for each person to put in their card choice. I figured that most of the team would hang out in their offices and dial in to the meeting, but everyone came to the conference rooms and that actually worked really well.

I’d budgeted about 2 hours for Planning Poker. I figured that this would give us time to get into the process and go through a few sprints worth of stories. Turns out that my estimating skills on planning poker needs some work itself.

The hard-to-estimate high priority stories derailed us for a long time. Especially the open-ended consulting and bug fixing tasks. The team got stuck on estimating an unknown. It took a lot of time and a lot of frustration, but we finally reached a rough consensus and moved on to the difficult-to-split design tasks. We tried a zillion ways to split them up or come up with better estimates. In the end they got a high estimate and were tabled to the sprint planning meeting. In retrospect, even though these stories were the highest priority, I probably should have started us on the concrete tasks and come back to these later in the session. For a team’s first planning session these were some pretty tough tasks to work through.

Once we got past these tasks, it got a bit better, but it was still difficult. The team got too caught up in the details of each story, unable to make an estimate before digging deep. If there was uncertainty, we got really deep in the weeds. The 2 minute timer didn’t help. The more concrete stories that needed to be broken up took a lot more time than I expected too. Members of the team kept wanting to discuss details on each story. The scrum master and I kept trying to bring us back to the sprit of estimation, but it was a slog. After almost three hours, we had only gotten through a dozen stories, not even enough to get us through our first sprint. I’m going to look for better ways to explain the spirit and intent of Agile estimation to the team. It is difficult to grasp sometimes for detail-oriented folks.

Even though we were short of estimated stories, we went ahead with our first planning meetings anyway. One team was able to take on stories and create tasks and estimates from them. They may be a bit short of work, but they made some progress. The other team had difficulty pulling stories given the paucity of choices.

We learned some useful things today. We separated the teams to do the sprint planning, pulling from the backlog. The teams were in separate video conference rooms. I and the scrum master moved between them. We realized afterwards that we really need to have both teams together to figure out how the stories would be divided and then the teams should have separated to create their tasks and do their estimations. I was also too eager to jump into the poker session itself,  and I didn’t spend enough time going through the backlog with the team and discussing my priorities. We’ll fix these issues next time.

We’ll do a second planning poker session tomorrow. Before then, I’ll take in the new stories we created in the backlog, make sure that they are prioritized correctly, and try to break up some more of the stories so that we don’t have to spend time doing that in the poker session.

I knew the first planning poker session was going to be a bit rocky as we felt our way through the process, but for me it was brutal. I know that as we gain experience it will get progressively easier and so I’m more worried about the team’s morale right now than I am concerned about the process. We’ll see how it goes.

On one hand, our super short sprints play to our advantage as it lets us try stuff out in a sprint without a huge commitment. On the other hand, it makes breaking stories up into sprint-sized chunks really difficult. It feels a bit like we’ve jumped into the deep end because of this. We’re open to making a lot of changes, but we’re hoping to keep a consistent sprint length through the cycle since modifying the duration of our sprints will make it difficult to establish a rhythm. Again, we’ll see how it goes.