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.

Converting from agile-mumble to Scrum: the introduction

I’ve been a convert to Agile for almost a decade now. I was first exposed to it when I was working at a start-up called Bootleg Networks as a Development Lead (don’t bother looking it up, it is long lost to time). I’d just come from six years at Microsoft where Waterfall was the only methodology and it was followed religiously. I’d seen all the worst aspects of Waterfall and seen nearly none of the best, but I wasn’t up on any other methodology besides Ad-hoc (also known as “play it by ear”). We’d hired Carmine Mangione as our software architect and he came in spouting all this stuff about “Agile” and “XP.” While I was definitely ready to try a different style of development, it all sounded a bit unstructured to me. Carmine convinced me to try eXtreme Programming, promising that if it didn’t work, we’d drop it. We bought a stack of Kent Beck’s book for the team and jumped into it. I went from Development Lead to XP Coach and quickly became a convert.

We achieved a ton of stuff using XP at Bootleg very quickly with a relatively small team. That short stint really changed my mind on how professional software development could be done. Ever since then, I have found ways to incorporate as many aspects of agile methodologies into any place I’ve worked.

I ended up back at Microsoft a couple years later. The situation there had changed quite a bit. While most of the company was still doing waterfall, more developers were aware of Agile and were curious about it (even if their managers weren’t). I took on a risky new project. It was fixing an ancient set of code written originally by Microsoft, but completely eroded over the years by a series of contractors. It was a mess: full of bugs. Customers didn’t like it. Rather than try to fix it, I convinced them to let me and a small team rewrite it from scratch to clean it up and get the new functionality needed. Program Management was skeptical, Quality Engineering was dead-set against it. I put my neck out and promised that we’d bring it in on-time with a high-level of quality that would be instantly verifiable with a battery of developer-written unit tests. We got some initial buy in and we went to work. We followed as much of XP as we could with an undersized (4 person) development team. Needless to say, we got it done and it shipped as part of WinCE 5.0.

I left Microsoft to join Adobe and was really happy to see that Agile was not only acknowledged, but embraced across many groups in the company. There were many different flavors being used, including several custom ones. Scrum was fairly common though.

I was certainly aware of Scrum, but didn’t have too high an opinion of it. Everything I’d read and heard about it made it seem like it had nearly no process or structure. Looking at how different teams “followed” scrum practices, it seemed like it was just an excuse for Cowboy Coding with a tiny amount of coordination involved. It seemed like a parody of Agile to me at first.

At Adobe, I was lucky enough to be able to build a completely new team. For various reasons, the team ended up being split between two different offices. While I wanted us to follow an Agile methodology, after a lot of research, I couldn’t identify one that would really work for us wholesale. Instead, I took the pieces that made sense and incorporated them as I could. We ended up with a unique process that subsumed bits of Rational (short sprints at first, longer sprints in the middle and short sprints again at the end; co-located functional teams), XP (test-driven development, occasional paired programming, be able to deliver at the end of each milestone, constant refactoring and narrow focus) and Scrum (demo-able at end of each sprint). That was the goal process. Of course, we didn’t always get there. We were pretty open and made a lot of changes along the way to incorporate new best practices and dump the parts that didn’t work. This evolving process worked fairly well and we have had three successful product cycles over several years using it.

For all the good of our existing cobbled-together development framework, we were always finding the seams, the edges that didn’t quite meet. There were other issues too. Having co-located functional teams meant that each team had good velocity, but it also meant that cross-site communication was always a problem and it made collaboration difficult as well. The team was getting too silo’d in my opinion. I wanted to really mix things up for our next cycle and try something totally new.

Over time, I’d gotten over my initial knee-jerk reaction to Scrum as I encountered more teams using it in a more deliberate and successful way. One weakness I still saw was the difficulty of using Scrum in non-co-located teams, but I met teams that came up with ways to manage this.

I decided that we would try Scrum for our next cycle. If it worked for us we would continue to use it for future cycles. If it didn’t, we would incorporate whatever worked for us back into our old process. Luckily, Adobe has a full-time Scrum trainer in the company. We did our scrum training a couple weeks ago, and we start our first Sprint tomorrow.

I’ve decided to document this on my blog for a few reasons:

  • It is something about Software Engineering that I can write about without fear of divulging corporate secrets
  • It might be interesting for other folks in similar circumstances
  • It is too long to tweet 🙂

My plan is to document our transition as much as I think might be interesting to others. Our situation is a little different from most since we are transitioning from a different Agile process to Scrum instead of from a non-Agile process. My team is also somewhat unusual since most of our clients are internal to the company who each use a different methodology (most Scrum, but some waterfall and some other Agile), but we also deliver our technology straight to Adobe’s customers on both long and short cycles. So we have a lot of impedance matches to account for. Some things may need to wait until the cycle is over for fear of disclosing too much, but by focusing on the process, I hope to be pretty open.

I’m not going to go too far into the mechanics of Scrum here since there are a zillion better places for that and because I’m still learning it myself. If I use a term you aren’t aware of and you can’t find a good answer on Google, ask me in the comments and I’ll try to answer it for you.

A bit on the details: My team doesn’t have a “Product Manager,” so I will be taking on the role of Product Owner even though I am the Engineering Manager. I’m not planning to act as a Scrum Master, that role will be taken by the QE manager of the team. If I have some free cycles I can use for development, I will act as a Scrum Team member, but I will not participate in Planning Poker as an estimator. We will have two scrum teams, each team incorporating developers and QEs from both of our sites. We’re going to do short sprints so that we can make changes quickly to our process.

I hope to create a little series here if I have time to keep it up to date.

Stay tuned.

Homegrown Sustainable Sandwhich Shop

I’ve tried a few different sandwiches at Homegrown since they opened. I like their concept and I want to like their food, but every time I’ve been underwhelmed and felt a bit ripped off.

This week, I tried their Po’Boy. For over $10, I got two tiny pieces of fried fish with a little spicy mayo on a roll and a tiny bit of over-spiced slaw in a cup. The fish seemed fresh, but was relatively tasteless and the tiny swipe of spicy mayo didn’t help much. The fish portions were small enough that there was an ocean of bread left over on the small roll it was served on.

Yesterday’s experience has been fairly representative of the food there. I’ll add that I usually take out rather than eat there. At lunch time the place can be quite busy and it is organized rather poorly since there isn’t a place to wait and not be in the way. So you often get a gaggle of people standing in the areas around the tables or where you order and pick up the food getting in each others way.

Homegrown seems to be succeeding, but I’m not sure it is because of their food or their concept. If they cut their prices by 20-30% and reconfigured their space a bit, I might like this place a lot better. You can certainly eat better for the same amount of money without having to look too far and that is what I will continue to do.

Homegrown Sustainable Sandwich Shop on Urbanspoon

Google vs. Microsoft: Peter Wilson’s view

Peter Wilson spoke at Ignite Seattle last night (How do I keep missing these?!?). Having been a senior dude at both Microsoft and Google, he has some true insider perspective on each. It is through the lens of what he cares about (cloud computing), it does have some good perspective. What is interesting to me as a former softie myself is that while he doesn’t say anything horrible about either place he definitely seems to still be a lot more supportive of his more recent employer than his previous one. While I love the concept of the Ignite talk being limited to 5 minutes, I would have really liked to hear more on this topic. Maybe he’ll do a longer version at some other local tech meet-up that I’ll completely miss as well 🙂

via TechFlash: Google vs. Microsoft: The view from a guy who worked for each

The best spam comment I’ve received thus far

This is by far one of the top-grade wrote articles on this content. I was searching on the exact aforesaid field of study and your position completely took me off with the way you see this matter. I congratulate your insight but do leave me to come back to input further as I’m currently widening my research on this case further. I will be back to join in this discussion as I’ve bookmarked and tag this very page.

Grant Skinner’s Things Every Flash Developer Should Know talk

One of the sessions that I was really looking forward to seeing at MAX was Grant Skinner’s “Things Every Flash Developer Should Know.” I’ve really been inspired by some of his work and although I’d seen his slides (they are posted on his site), I wanted to see him present it. I’m hoping that they will post a video of it on Adobe TV, because I got a lot more out of watching it than I did by just reading the slides.

The Actionscript and Flash parts were the main draw for me, but I actually got a kick out of the software architecture and software engineering-ish slides as well. He ended up presenting a nice overview of some of the core of software engineering and development in a succinct and easy to understand way. I would certainly recommend this talk to the folks in the community without formal training, especially as a gateway to finding areas to learn more. I think as more and more experienced developers with formal software training move into RIA development with Actionscript, you’ll start to see the general level of software quality in the community rise (especially if the new-to-Actionscript developers embrace the sharing ethos of the greater community).

I didn’t agree with all of his edicts – especially about commenting, documentation and some of his personal coding guidelines, but those were pretty minor quibbles with a really great talk.

I also have to give him big props for his Flash-movie-as-slide-deck. A lot of times, I’ve seen developers create their own slide software as an intellectual exercise which all-too-often results in presentations that look a lot worse than powerpoint templates. His deck worked well, looked good, and was cool without being too distracting.

At the beginning of the presentation there is a quote from Dune that I hadn’t seen before. I grabbed a longer version of it here from one of his other posts.

‘Above all else, the [architect] must be a generalist, not a specialist. Experts and specialists lead you quickly into chaos. They are a source of useless nit-picking, the ferocious quibble over a comma. The [architect] on the other hand, should bring to decision-making a healthy common sense. He must not cut himself off from the broad sweep of what is happening in his [application]. He must remain capable of saying “There’s no real mystery about this at the moment. This is what we want now. It may prove wrong later, but we’ll correct that when we come to it.” The [architect]-generalist must understand that anything which we can identify as our [application] is merely part of a larger phenomena. But the expert looks backward; he looks into the narrow standards of his own specialty. The generalist looks outward; he looks for living principles, knowing full well that such principles change, that they develop. It is to the characteristics of change itself that the [architect]-generalist must look. There can be no permanent catalogue of such change, no handbook or manual. You must look at it with as few preconceptions as possible, asking yourself: “Now what is this thing doing?”‘
– From Children of Dune by Frank Herbert (1976)

some code for a change

I’ve written this function a zillion times, so I decided to post it on my blog. Yes, it could do more error checking (what if that new returns a NULL? what if an exception is thrown?). But it does more than zero error checking, so there you go. This is super useful if you are getting ANSI code paths from legacy APIs or if you are using boost::filesystem::path to store paths in a platform independent way (until the new boost comes out).

This particular version isn’t battle tested (yet), but it does work.

// convert a path from ANSI to UNICODE on windows using std::strings
// useful for converting a boost::filesystem::path into a wpath,
// until those APIs get merged
std::wstring convertStringToWString( std::string in )
{
    if (in.length() == 0 )
    {
        return std::wstring();
    }

    UINT wStringLength = MultiByteToWideChar( CP_ACP, 0, in.c_str(), -1, NULL, 0);
    if (wStringLength==0)
    {
        return std::wstring();
    }

    LPWSTR widestr = new WCHAR[wStringLength];
    wStringLength = MultiByteToWideChar( CP_ACP, 0, in.c_str(), -1, widestr, wStringLength );
    if ( wStringLength ==0 )
    {
        delete[] widestr;
        return std::wstring();
    }

    std::wstring returnVal = std::wstring( widestr );
    delete[] widestr;

    return returnVal;
}

Chez Shea

Chez Shea dining room.
Chez Shea dining room.

For years we’ve stood waiting at Matt’s In The Market and pondering what was behind the door at Chez Shea. We knew that it was supposed to be nice, but we never got around to eating there until recently. We were pleasantly surprised at the size (it is quite small and cozy), the environment (similar to Matt’s old vibe when it was smaller, but more romantic) and the staff (friendly, but not to the point of being annoying). I was very happy that I didn’t feel out of place wearing a suit, the other diners (for the most part) were dressed for special occasion meals as opposed to the shorts and t-shirts you sadly see too often in high-end restaurants around here.

The food was good with some touches of excellence, but not enough to be a draw on its own at this price range. If you are into “Big Flavors”, you can skip Chez Shea. The food was fairly subtle but solid; tasty, but not overpowering. Two elements of what I ate remained with me (admittedly these were the biggest flavors in my meal): I had a Hamachi Crudo which came with some sliced Jalapeno that added an interesting kick to an otherwise bland dish; and a Muscovy duck that was prepared two ways, one of which was a Confit Crepinette that was simply amazing.

The menu is fairly standard high-end northwest cuisine: seasonal, fresh ingredients, featuring seafood and northwest game. The menu itself was a little small, but it was ample enough that we were able to find good choices for four courses each. As with many higher end restaurants, the portions are smaller, but we didn’t leave feeling hungry. If we’d skipped a course, we might have left seeking some extra food though. The wine list was good as well, but not extensive.

Overall, we liked Chez Shea, but probably more for the atmosphere than the food. The food was good enough that we’d definitely consider it again for a special romantic dinner, but not so good that we’re already planning our next visit. I would definitely like to come back and try the Bistro some other night. It is even smaller than the restaurant and may be a great “date night” destination.

Chez Shea / Shea's Lounge on Urbanspoon