Category: done

"Stop Starting and Start Finishing" - A successful Lean philosophy

May 15, 2009 by Jack Milunsky

Introduction
One of the killers on software development projects is Work-In-Progress. We have learned from the Lean experts and from the teachings on the Toyota Production System that too much work-in-progress is a liability. Just yesterday I was asked to spot the problem with a sister company's task board. Sure enough one developer had 5 or 6 "in-progress" tasks on the task board. It took me a split second to notice.

Productivity
The problem with this situation is that as a developer if you're working on more than two tasks, simultaneously your productivity takes a dive. Additionally you're going to end up with many unfinished tasks that never get completed. This is a classic problem in Waterfall where tasks have half-lives are in the order of man months. The more tasks in play at any given time, the more tasks that never get finished.

My First Agile Project: Go-Live - The Final Frontier

January 26, 2009 by mattgrommes

Picture courtesy of papalars. on flickr

We did it! The project I've been talking about all this time has finally gone live and is now being used in production. Pretty much everything worked fine on launch day as well, which was nice. :) In this installment of My First Agile Project, I'll talk about the last week of the project and where we go from here.

The last weeks of any project are pretty hectic and this was no exception. Our last week was a weird one though as we were theoretically in a code freeze (more on that below), and we still had to finish final testing, and we had to be done by Thursday so our database admins could start the data conversion first thing Friday morning. We all pretty much ran around like chickens with our heads cut off all week but once Friday came a weird sense of calm had settled over most of us (it might have been a fog of fatigue or brain tiredness, it was hard to tell). The DBAs had run through the conversion process 29 previous times so while they were working, it wasn't some new process. The conversion process ran like clockwork, even finishing a few hours earlier than projected, and on Sunday we began the final Go-Live steps.

My First Agile Project: The Last Mile

January 12, 2009 by mattgrommes

Picture courtesy of Dru Bloomfield on flickr

Welcome back to My First Agile Project. I spent a few weeks doing as little as possible for the holidays but now that I'm back at work we're starting to head toward the actual end of this project. For real this time; barring any natural disasters, stress-induced insanity, or alien invasions we should be live by the end of the month. So the next couple of posts in this series are going to be about the end of My First Agile Project as we complete this and transition to whatever comes next.

As I've discussed before, we've missed a couple of other deadlines in the past but this one just feels different. On past deadlines, when we thought we were close enough to done we'd find a 3-day weekend and try to decide if we could finish everything by then (converting all of our old data takes a long time so we have to basically shut the company down while we do it). Of course, things come up and we're too optimistic so when it comes down to it we've had to abandon the previous dates. We thought we were going to be able to do it at the end of November but again we missed it due to changes being made at the last minute and unforeseen problems. This time though, our list of remaining issues is small enough that when we decided on this new date we were all a lot more comfortable with it than in the past. This feels like an actual date of completion for everything, not a deadline we're rushing to meet.

"I know it doesn't work but it's done" - a story about the definition of done

November 28, 2008 by Przemysław Bielicki

Picture courtesy of orinrobertjohn@flickr

Some time ago I was talking to engineers responsible for some part of the software and I was asking when they will be ready for production. In other words I asked them when their features will be ready. They told me that they are ready now. What was my surprise when I tried to test their software and discovered that about 50% of cases were not working at all. So I asked them why they told me that they are "done" when they haven't even implemented half of the planned features? They answered me: "We know it doesn't work but it's done - we implemented something so it's done. Now we have to work on quality i.e. implement rest of the features."

When I heard this I think I might have looked like the lady from the picture. I couldn't believe someone can think like this - if we implement one use case out of one hundred we can consider the project done? The rest is the "quality"? I don't think so.

In this post I'll try to explain once again what is definition of done and why it's so important to have the same definition at least among all the people involved in the development of a single project.

My First Agile Project Part 6: The First End Of Our Project

October 6, 2008 by mattgrommes

Picture courtesy of Photo Mojo@flickr

Welcome to Part 6 of my team's first adventures with Scrum. If you want to start from the beginning, see the table of contents at the bottom of this article. Each part stands alone though so don't worry.

In this part of the series, I'll talk about what we did when we approached what we thought was going to be the end of the project. As it turned out it was only the first deadline that we would miss. Near the first deadline we went off of doing Scrum sprints and planning in favor of fixing bugs as they came up in testing. This cost us a lot of team cohesion and focus. Read on to hear about what led us to missing the deadline, why we went off Scrum and how we got back on the right path. As usual, I hope our story helps illuminate some decisions teams make with the best of intentions that can lead to unforeseen negative consequences.

When, How and Why Definition of Done Should Be Extended

December 7, 2007 by Artem Marchenko

Definition of done is one of the central concepts of Scrum process. Every iteration the team is supposed to release an increment of software that is fully done. Ideal Scrum team every iteration delivers software right to the customer hands, manages to arrange the trainings, print documentation and so on. Most of the real world teams, however, aim at somewhat smaller goals. What exactly is expected to be delivered by the iteration end depends on the team's definition of done.

Evolution of Done