5 Agile Lessons Worth Learning

If you can't learn your own lessons, at least learn someone else's

Jim Dempsey of compaid.com recently hosted a webinar entitled “Agile Lessons Learned.” I was initially put off by a lengthy introduction to Scrum because I had been led to believe the material was geared towards more advanced practitioners.

Eventually, though, Jim got to the meat of his talk by going into a fair amount of detail on a few dozen lessons he’s learned over many years of training and implementation of Agile methods. Here are five points I picked out of his slides, all of which I absolutely concur with, although I have to add a “yeah, but…” to the last one.

Lesson 1: Conduct Product Owner training when introducing Scrum

When I implemented Scrum at Raven it was top-down but didn’t ingrain in the project lead the responsibilities of his role as Product Owner.

Sure, I told him he had final say on the backlog and I informed him of the deadlines he had that revolved around the team's beginning and ending of sprints, but I didn’t properly convey the critical nature of his involvement. If I had made sure he had proper training as PO perhaps the project would’ve met with better results.

Lesson 2: Don’t build the Product Backlog in the Sprint1 planning meeting

If you’re getting the stories in place for the very first time during the planning meeting for your first sprint, you are already going to impose delays on your team. You won’t have enough information in place when they need it and/or it won’t be as well thought out or prioritized as it should be.

Get your backlog sorted before you sit down to plan sprint #1. And keep in mind you don’t need the entire project prioritized into the backlog at this point. In fact, as the Poppendiecks point out in an excellent example in Implementing Lean Software Development, you don’t want to prioritize beyond the next three sprints or so – it adds too much waste from bookkeeping and most of the items will change out from under you, anyway.

Lesson 3: Tools should be used if and only if they add value to the team’s work

Do not force a tool on your team because “it’s the company standard” or any similarly poor line of thinking. First of all, I’m a big believer in the saying, “The work chooses the tool.” If you decide ahead of time that you’re going to use a hammer at all costs, you’ll reach new heights of inefficiency when you encounter your first screw.

Second, your team’s progress, work quality, and mental wellbeing have a whole lot to say about any software choice. Maybe they don’t even want software. Maybe a whiteboard and some markers will do. Let them decide what adds the most value.

Lesson 4: When Scrum gets tough (and it will) don’t succumb to old habits

You need a predetermined resolve not to fall back into your old habits of moving deadlines, working overtime continuously, and cutting corners to make a milestone.

Those are the reasons that your competitors who employ wisely iterative and adaptive improvement techniques (such as Scrum and Lean) are making better games, selling more units, and retaining better talent. You absolutely must have quality leadership to get through tough times – I’m not saying Scrum alleviates that need. But forcing overtime and increasing your production debt by pushing off features is not the solution.

Lesson 5: Team will tell you if a stabilizing sprint is needed

This is where I felt the need to add to Mr. Dempsey’s material with my own commentary. Yes, a committed team should be able to speak up and request a stabilizing sprint if deteriorating build quality requires it.

However, your producer or project lead should also be stepping in at some point to make that call. The team can do everything within its power to execute on the vision for the game, but that vision belongs to whoever holds the creative reigns.

It’s her job to provide that leadership, to make the tough decisions between adding more features and solidifying the build you’ve already got. If you’re not getting that kind of leadership from your creative lead, step up and hold her accountable.

My favorite quote: Scrum is "Extremely simple but very hard"

Overall, this webinar was helpful to someone who’s looking to implement Scrum but isn’t entirely sure what they’ll find on the other side. The material was also reassuring to folks who’ve already started working with Scrum but weren’t sure if they were the only ones having a tough time with it.

As one of the slides specifically stated, Scrum may be based on common sense, but it’s still difficult. This is, of course, true. What’s also true, though, is that the benefits of Scrum are worth the effort, especially in an arena such as game development where solid specifications are hard to come by.

In preferring Agile methods you are giving your project the best chance of creating the greatest value, pleasing the most shareholders, and minimizing your team’s crunch time.