Agile Excellence, Part 1

One narrative of a successful Scrum sprint. This really demonstrates how most big organizations are getting value out of Agile methodologies.

So there I was, slogging away on some .NET code at a largish enterprise that was “really into Agile, we’ve been doing Scrum for like three years now!” We were a week into the current three-week sprint.

At that morning’s standup, we’d gone around the table as usual. Jon said he was taking the refactoring story on the WCF middle tier. Ellen, who I think was Scrum Master of some other team, assigned me the task of resolving an exception that was being thrown by client-side code. Jeff said he couldn’t package the database changes because there simply wasn’t anywhere to check them into TFS (version control). I had code checked out, modified, and working to implement a feature in an upcoming release; but I was holding off on checking it back in because, per the team lead’s policy, we can’t have more than one branch “because people keep doing it wrong.”

That afternoon, the team lead’s boss came around and called a quick meeting.

Phase I, he said, was running late and he wanted to know why. And furthermore, when was Phase II of the project going to get done?

Ellen said she had all our burn-downs and they checked out, as everyone had burned down approximately forty hours. She had also added up all theĀ estimates for the stories that were going into Phase II, and they came out to 990 hours, and since we had six team members Phase II should be done in four weeks. In fact, she said, we could put all of Phase II into the next sprint, which would give us just one week of carry-over.

Okay, that’s good, said the boss–but when can we start testing the current release, the Phase I release?

That’s when the team lead told everyone we don’t really have a deploy script for the test server, and there’s not really a production server at all. It can take IT a while to provision the new production server, he went on, but in the meantime we can host the production system on a spare Windows 2003 server. Jeff pointed out that Windows 2003 won’t run .NET 4.5 applications, so we’d have to retool the application to .NET 4.0. He agreed, though, that it wasn’t worth doing until after QA finished testing the current code.

But there were still a few tasks left before testing.

The boss thought my priorities in particular were off. “Look,” he said, “you can’t possibly need to have the API to FedEx doneĀ before the Data Access Layer.” I tried to tell him I wanted to hit the FedEx API first because it was a higher risk and thus would benefit from the greatest possible lead time, but the team lead cut me off, saying it was a low priority and wasn’t going to be in the current release anyway. (I later quietly asked, “Why was it in this sprint if it’s a low priority?” The answer: “We had to allocate all your hours and that was the only thing that would fit.”)

The boss whipped out his “to-do list” for the Phase I release. The FedEx thing wasn’t on it.

I was excused from finishing the API to FedEx, because another team needed that Data Access Layer done as early as possible in the sprint. It wasn’t on the to-do list either.

Our sprint ended successfully!

A couple weeks later, my feature in the upcoming release was still not checked in, but since my code was more or less done we figured it had to count. That WCF middle tier compiled and seemed to run okay, but the refactoring broke several unit tests that hadn’t been fixed yet. We added “Fix or comment out failing unit tests in WCF” to the sprint after the next one so we could get Phase II in first. The exception I’d gotten from Ellen took a couple of days to fix, because it had something to do with the Razor version we were using and I don’t know that much about Razor. Finally, Jeff’s database changes were handed over to a special meeting of the SQL Developers team, which was eventually going to build a schema repository.

As for rolling out Phase I, well, we had to add a story that simply read “Backfill to .NET 4.0.” The boss said that should only take a day so we assigned it three points. (Each developer was expected to do about twenty points per week, so that seemed about right.) Our scrum master said he’d take care of the test deploy script so it wasn’t necessary to add to the actual sprint. And we added a story (which just said “test”) for the QA department to do. We assigned it one to eight points, depending. And we’re not sure when that backup Windows 2003 server is coming through, but we created a story (“migrate to 2003 server”) for me to do. I don’t have production access but I can probably get an IT person to work with me on it.

You know what?

The great thing about working in a Scrum shop is that everyone’s super flexible and does the best they can without relying on management to tell them what to do all the time. It’s so empowering!

 

The W part of DTSTTCPW

When developing iteratively, what exactly constitutes premature optimization? When doing the simplest thing that could possibly work, what does it mean to “work”?

A couple of weeks ago, a question turned up on the BaseCamp site we use to coordinate one of my projects. One programmer asked what we thought of a certain calculation he was setting up on the database. It had to do with accumulating “rating” points of an item in a tree-shaped threaded discussion.

Continue reading “The W part of DTSTTCPW”

From today's memo pile

We’re not a Scrum shop. We’re more of a Kanban shop that has Scrum-like meetings. Which a lot of teams do. Here’s how to make the Scrum meetings Not Suck.

To: Everyone
From: Mark

A note on process…

…as well as a reminder of today’s Weekly Scrum meeting. I’m notifying everyone (including executives and non-technical managers) because you’re all invited to join today’s meeting as chickens, and because you might be interested in the process summary. If this stuff bores you, sorry about that. [And something about how to turn off the notifications.]

First off, the Scrum will start at 5pm. If other “pigs” will be in the office I will join you, so let me know. But we will also be on Skype (where I’m MarkWSchumann). Other pigs are: [names elided]

If you care to join the Scrum as a chicken (i.e., involved but not committed), that’s fine–let me know and we’ll include you.

End of announcement. Beginning of process talk.

For those newly tuning in or just standing by, the Scrum meeting is really really simple. Everyone in turn answers Three Questions:

  1. What did you get done since the last Scrum meeting?
  2. What do you plan to do before the next Scrum meeting?
  3. What obstacles do you have?

I’m gonna say something here.

The answers to these questions are often a variation on “I screwed up, and this is how I screwed up, and this is how it’s affecting my team.” Let me be clear about one thing: The process doesn’t work if you can’t be totally honest. Okay, two things: People aren’t gonna be totally honest next week if you make them regret this week’s honesty.

So if Alice admits she caused a blockage because she bit off more than she could chew, no fair scolding her about the same exact thing on Monday. She already spilled her guts. Don’t make her do it again. (She’ll wonder why she bothered to suffer that experience the first time if it didn’t count.) And if Bob tells you he botched some code and has to do it all over again, appreciate the fact that he said so. Don’t make it all dramatic. Just help him fix it and move on.

Got it?

And the Scrum should go really quickly–maybe about three minutes per pig I guess. And zero minutes per chicken, because chickens don’t get to talk in Scrum meetings. If an obstacle can’t be resolved instantly, we take it out of the meeting to talk about later.

This is not really a Scrum shop.

That’s been implicit all along, but now I’m actually saying it.

Scrum has burndown charts and a different kind of backlog system and an explicit kind of connection to management, among other things. We don’t need those. I think.

We’re more of a Kanban shop that has Scrum-like meetings. Which a lot of teams do.

I’m gonna draw everyone’s attention to the online Kanban system we have at AgileZen: [url elided] If you don’t have access to this, you should. I don’t care if you’re technically on the dev team or not–there is really one team here, and in a face-to-face workplace the Kanban would be an actual physical board placed where everyone can see it.

If you want to know why the heck stuff isn’t getting done, this would be the first place to look. That’s the transparency thing.

Very briefly, each “card” is supposed to move from the (sometimes hidden) Backlog column at way left, through the various columns, and into the (sometimes hidden) Archive column at way right. Cards edged in green are Ready to be pulled to the right. Cards edged in red are Blocked and need help.

I encourage everyone on the dev team to watch for Blocked cards throughout the board. You can often help with one that’s not currently in your own primary area of work.

Fantasy: the self-organizing team

Does it help to hand cards directly to developers and asking for status every day?

It sure does! It helps me feel super-duper important! It reassures the client that I’m in control! It reinforces my position!

It doesn’t get any more work done, but hey.

I wrote about this phenomenon in a different context about a week ago, but it’s come up again. Twice is a coincidence, three times is a pattern, right?

I was talking to a client the other day about a thousand things, in the space of half an hour. There were a few things that stung badly, but one of them was to the effect that I wasn’t managing the developers very well.

Continue reading “Fantasy: the self-organizing team”

80% of what?

Yeah, you got that whole 80/20 rule thing. 80% of what?

I’m a big believer in the 80-20 Rule. If you haven’t heard of this, it’s the idea that almost everything you do yields 80% of the benefit with the first 20% of effort. Similarly, you’ll find that 80% of your sales come from a 20% subset of your offerings. Stuff like that.

Sure, it’s a back-of-envelope rule of thumb sort of deal, but still a useful planning concept. (I love heuristics.)

On Monday, I blogged to the effect that non-software startup companies be satisfied with commercial off-the-shelf software that satisfies 80% of the functionality they require… because that’s so much cheaper than embarking on a new project when you are already hard up for cash.

Continue reading “80% of what?”

Good ideas in a Daily Scrum

The Daily Scrum is no time for good ideas! Save the problem-solving for afterwards.

Someone asked on LinkedIn the other day how to handle technical discussions in a Daily Scrum meeting that is ending early: do you use the free time, or defer the discussion for after the meeting?

To me, that’s an easy call. You do not have time for technical discussions in a Daily Scrum, the same way you do not have time to talk about last Sunday’s football game in traffic court. It’s not a matter of time, it’s a matter of focus and appropriateness.

Continue reading “Good ideas in a Daily Scrum”