And a month later...

It's been way too long since I wrote the last entry. Things at work have been kind of hectic. In the last four weeks, we reorganized, pushed out our third release of the year, reorganized again. Hopefully, the organization will stabilize enough so that we don't have to reorganize again before Thanksgiving.

In terms of the Scrum, we're moving forward. We see benefits, but our old habits continue to haunt us. We had to rearrange priorities during our release to handle those last-minute show-stoppers. Performance challenges after the release due to a fairly major architecture change required some additional reprioritization.

Overall, scrum works. The daily scrums are great at communicating progress. Every day, each team member communicates the tasks he or she is working on, the tasks planned for the next day, and obstacles that are preventing progress. That works great! We try to keep interruptions at a minimum. This has been somewhat successful. The team has now come together very well, and they're taking ownership of things that need to get done.

But we have encountered a few big challenges. First, while the daily scrums are great for communicating progress, they aren't so good at ensuring that everything is finalized, and tasks are actually completed. We haven't been good about communicating estimates. And we have a challenge with communicating between our on-shore scrum team and our offshore non-scrum team.

I contact Jeff Sutherland, one of the inventors of the methodology. Our model is similar to what he calls a "Type C Scrum", where the priority list is constantly rearranged. His company, PatientKeeper, has been successfully executing Type C Scrums for about two years. He sent me an advance copy of a book he's been working on. We'll be reviewing it both to provide feedback to Jeff and to see if we can apply some of the lessons learned by someone doing this a lot longer than we have.

Stay tuned for more updates.

Scrum and Priorities

So our first daily Scrum started on Monday and it went pretty well. In meeting with the developers, they confirmed what I originally suspected. Our throughput is low, not because the problems we have to solve are too complex, but because the developers are constantly interrupted to handle the next emergency.

So a prioritized product backlog is the right answer--with each item in the backlog being a defect (or more specifically, the tasks necessary to fix a defect). But we can't follow the traditional scrum methodology and create a 30-day-long backlog. We have to adjust our backlog on a daily basis to ensure that we are handling problems in the right order. Since we don't have a prioritized list, I started the team out by just having them pick defects from our defect tracking system and get working on them. I also committed to minimizing interruptions. That might be easier said than done, but we'll try. It takes a long time to break old habits.

Today (Thursday), I distributed a first cut at a prioritized list of defects. I'm also trying to recruit someone to serve as our "product manager", and maintain that prioritized list.

In the next couple of days, I'll regroup with the team to measure our progress in the first Scrum week. Stay tuned for more details.

More Thoughts on Scrum

I've been doing a little more thinking about Scrum, and have had a little success in getting it kick-started at work. Our first sprint, with a team of seven excellent developers, starts on Monday.

Here's some more thinking on the subject. The basic theory behind scrum is based on traditional process control theory. At first glance, it appears to be simply "management by to-do list". But there really is method behind the madness. Most existing software development processes assume that software development is a defined process--similar to that of building a car on an assembly line. If you've been doing software for a while, I'm sure you realize that is absolutely not the case.

Scrum is different. It acknowledges that software development is really an empirical--unpredictable--process. The methods used to control an empirical process are vastly different from those used to control a defined process. For a defined process, you can follow a recipe or series of steps to produce the correct output. For an empirical process, you closely examine the inputs prior to performing a process and the outputs once the process is complete. You put controls in place to react and change course when things go haywire.

So it sounds ideally suited to certain software development activities. But I'm trying to apply it to production support--maintenance of a system that is already in production. As with any support organization, our reacts to constantly changing priorities: we scramble to deal with the latest "emergency." Maintenance releases occur weekly on a regular basis, and sometimes as frequently as once a day. To complicate things even further, 80 percent of our support team resides in India, while the other 20 percent is located here in the U.S.

Scrum is really intended more for longer development periods, prioritized task lists that don't change, and development teams that have the luxury of being co-located and being left alone. There has been some talk about evolving Scrum to deal with concurrent development periods, and even weekly maintenance releases. And that will be the subject of my next blog.

Processes

I've been thinking about software development processes recently. I've actually been interested in them for quite a while. While at Andersen Consulting, I worked on an applied research process where we applied some of the latest object-oriented techniques on projects for a defense contractor. Those processes later became the object track for Andersen's Method/1.

Since then, I've applied both Extreme Programming and the Rational Unified Process to various projects. I've also worked on a very large-scale project where we followed a "homegrown" process influenced by the company's product development processes. This process is very much a waterfall process. As I said, the project is large, and in my experience, the larger the project, the harder it is to apply newer, less rigid processes.

But like any waterfall processes, it has its weaknesses. Because requirements must be specified up front, they often arrive late in the cycle and are rarely as complete as we'd like them to be. Because requirements are late, we struggle to complete designs in time for a thorough review. Because we rush through design reviews, we struggle with defects after the code is written. Although we test pretty thoroughly, the system is complex and we've introduced a lot of "hidden" defects into production. The burden of bringing those production defects under control is what's currently on my mind.

We have a team of about 30 people working on production support. The team does a great job of responding to problems quickly, but it's a thankless job. We're keeping our heads above water, but just barely. Our fix rate is just slightly larger than our incoming defect rate.

So I've decided to give Scrum a try. Scrum is a process, not a methodology. Based on process control techniques, it is almost more a philosophy than a process. With Scrum, software is developed by relatively small teams in 30-day sprints. The team controls what they develop, how they develop, and when they develop. This isn't the ideal scenario for Scrum. I'm not talking about a product development activity, I'm talking about software maintenance. I'll also have an up-hill battle to get our leadership team to accept this "untried" process.

I'll post updates as we make progress.

Jeff

Let's see where this goes

OK. Kim shamed me into really starting to blog. I've known Kim for a LONG time--I think it's about 14 or 15 years now. We worked together at Kaseworks. If you're an old-timer like Kim, you'll remember Kaseworks as one of the original GUI builder companies. Our products were bundled with Microsoft Quick C, and with IBM's C++ compiler on OS/2. This was in the early days, when Graphical User Interfaces were still new--most software was still character-based. In fact, one of our biggest competitors was Easel, a screen-scraping tool that interpreted mainframe screens and put a pretty front end on them.

Anyway, I discovered Kim's blogs last week, and realized that I've become pretty complacent. I spend my days at work, and haven't been keeping up with being on the bleeding edge. So I guess I'd have to say the Kim has goaded me...no, inspired me to start blogging.

I'm not sure yet how this blog will evolve. I've been a nerd for more than 20 years now. Started on the mainframe (Unisys), writing applications with COBOL. Got into PCs when they were still new, and started writing code in C. Then I discovered C++, wrote a book on it, and that got me into Kaseworks, where I created their C++ products. After Kaseworks had essentially died (a story for another day), I followed Deb Wright, our VP of Engineering to another start-up. That one bit the dust pretty quickly, and I needed some stability so I joined Andersen Consulting for a great project on component-based software engineering where I got my first taste of Java. After that project completed, I decided to do my own thing. That lasted about 5 years, and I joined GE Healthcare.

Professional interests include anything OO or component-based, software development processes, the politics behind technology, and leadership of technical organizations.

Unfortunately, I don't make a living by writing blogs. So I probably won't be spitting out blogs as quickly as Kim does. But stay tuned for the next installment in this gripping new saga.