Category Archives: Scrum

Jul 18 2008
2 Comments
Agile, Lean Software, Scrum, Software

Not Sure the World Needs Another Named Prescriptive Methodology

This, on the very same day that some tries to create a definitive list of methodologies, Net Objectives (the one-time sister company and training provider for the company I contract through) has just announced their new flavor/version/whatever of Scrum, which they are calling Scrum# (pronounced “sharp”, like C-sharp). It is (as far as I can tell) essentially Scrum + Lean Thinking + Emergent Design + Focus on scalability. Many things that a lot of us are doing already.

To be fair, the approach they are taking is exactly the one that I would advocate, focusing on and being mindful of the principles/values of what works and what doesn’t work. I’m just not sure I can get behind the name.

Jun 13 2008
2 Comments
Agile, Scrum, Software

The solution here is not process dogma

The other day I was discussing a process/dev workflow problem with one of my friends. I managed to get a basic understanding of what the problem was (team disagreement about the importance and sequence of sprint reviews, retrospectives, and planning) but we were both too pressed for time to brainstorm for a solution. He had a meeting to attend, and I had a demo to give.

The only advice I gave was, “The solution here is not process dogma. You can’t just fall back on the Scrum rulebook and say ‘we’re supposed to do it this way’, you have to get to the value of why you should do the previous review/retrospective before the next planning.”

The value, of course, is that you should be taking what you learned from the last sprint and using it to inform your actions of your next sprint. It’s Scrum’s larger-scale feedback loop (the small feedback loop is the daily meeting).  Inside or outside of Scrum, feedback loops are important for making software well.

When I was thinking about it later, I realized that process dogma is never the solution. Software development is intellectual work, and to make a persuasive case with skeptical people, you have to do better than “because the book says so.”

Jul 02 2007
4 Comments
Scrum, Software

The Problem With ScrumWorks

For the last few projects at thePlatform (a truly great place in almost every respect) we’ve been using the basic version of ScrumWorks. For the projects before that, we used the sticky-note-on-whiteboard approach (not without its own set of problems, of course) and the customized excel spreadhseet approach (again, with problems).

Usually, for sprint planning, one of the product owners/solution architects will fill in the uncommitted backlog ahead of time, and we just drag things around and refine estimates during the meeting.

Today, with our regular product owner gone on vacation, I put the majority of things in ScrumWorks, and it was painful.

The most recurring problem was that i had to estimate both stories and tasks before I could put them in the sprint. It totally breaks the creative flow of “oh, we’re going to need to do this, put that in there” if I get these, and there’s no other word for it, rude, dialog boxes popping up telling me that I can’t do what I just tried to do, in that I have to do something else first.

On top of that, there’s this rigid two-level hierarchy in place. If I accidentally enter something that should be a task as a story or vice-versa, too bad, I’ve got to re-enter things, and re-estimate things (in different units of measurement, no less) to appease the software.

At that point, I’m working to serve the needs of the system, and not the other way around.

The biggest revelation that I had today, which I shouldn’t complain about too much, as I only spent around 30 minutes doing it, was that this isn’t the way that I would model a software development project.

Besides the rude UI around entering stories/tasks, there’s no logic for collective ownership or load-leveling (as in, “Gee… it looks like those are all things that Kevin’s going to do and Mo has nothing”). I prefer to estimate both stories and tasks as small/medium/large than days/hours (sometimes with a translation table that says that small = 8 hours, on average, etc.)

I’ve been wanting to write my own software project management tool for years, the design of which changes as I learn more about how different teams approach software tools. I’m eager to try Mingle, from ThoughtWorks, as I trust that they know how to develop a less offensive user interface.

My hope is that the people developing/using these tools realize that they are essentially modeling tools. The “state of the world” in ScrumWorks is an incomplete model of the actual state of the project. Like any model, it can only approach reality, and after a particular point, you get diminishing returns with marginal verisimilitude. Also, just like I’m starting to see the Scrum process as too prescriptive (that is, “what” driven instead of “why” driven), ScrumWorks is way too prescriptive. I don’t want people telling me how to make software, and I sure as hell don’t want software to tell me how to make software.

Even though it means that I’ll have to give up a whiteboard, I might just start lobbying for the sticky notes again.