Wednesday, March 25, 2009

It's not "lite"

I worry that some folks support agile development because they dislike process and consider this a way to get by with doing less stuff that they don't enjoy. Take for example a discussion with a team on a agile journey. Developers indicating some push back when the code stops working due to some changes in progress. They voice the position that there is extra work to make the temporary changes necessary to keep the code working for the periodic builds. They could use that time to create extra value or function. At the same time the testers don't seem very enthusiastic about testing the latest build and reporting bugs. As the mentor for this team I worry that we are getting off track.
My best response is that we choose not to reduce the risk of undertaking a complex software development effort by writing detailed specs and requirements documents. Instead we choose (or I believe we choose) to reduce risk by incrementally create function and create frequent builds of working code. That is our risk reduction strategy. It is a corner stone for our plan to deliver a successful end product. I acknowledge that their is some extra work to keep things working - perhaps with some temporary scaffolding or temporary code. This enables us to demo the code and learn from it over the life of the project and not have a big crisis at the end and a long difficult to predict period of instability.
Next time I'll ask do you want to write specs and that start or keep the code always running and fix the bugs as they come up. You can 't have your cake and eat it too. We are all on a journey...

Wednesday, March 11, 2009

bugs and credit card debt

I've got two challenges that seem totally unrelated but have some striking parallels. One is credit card debt and the other is bugs on software projects. I have to say the idea of considering a bug list as a debt was first introduced to me in the book "Waltzing with Bears". These days with a new found awareness and sense of fiscal responsibility I wonder if I can leverage that into a better quality practices.
In a "traditional" project teams often work away according to a plan. Very often things don't go as expected and one of the places that suffer is any time planned for bug fixing. Or there is an accepted sentiment that "...they are just bugs and we can fix them at the end after all the hard work is done" we've got to stay on schedule. (In my experience more often than not a significant design flaw or requirements snafu is uncovered in the process of bug fixing and these issues are really harder than building new function. These are dirty problems people tend to avoid unless pushed by an experienced manager or agile mentor. )
Some teams even may have a bug review with the customer or product manager near the very end of the project. These are often difficult as during this review the only choice the customer has is to extend the schedule to fix the bugs or accept the bugs as known issues to be fixed in the next version. Hence they tend to want to avoid these sessions as they only present dilemmas not an opportunity for active decision making.
Some teams consider it OK to build up a large bug count. They also probably consider it OK to keep their charge balance at or near the credit limit. I recently pointed out to my lovely spouse that despite payments of a 100 dollars a month the balance of on a certain credit card had only decreased by 60 dollars in the last three months. In my minds eye that's almost 80 dollars a month wasted that could have spent on other things on tangible goods rather than interest payments.
The team that runs with a big bug back log faces the same waste. Granted there is the "cost of quality" analysis. We are not going to have a perfect product and fix every bug. But if in the course of doing business we make accommodation like:
  • Skipping that error when it is reported again and again in the automated test run.
  • Talking to one another via speech, email or instant messenger,or what ever about bugs that hang on for months.
  • Some one else rediscovering the bug and attempting to report it only for the bug report to be deemed a duplicate.
  • Reading past the old bug in the bug report when looking for new bugs. Considering what other bugs might be resolved by and open fix. A large open bug list makes the incremental cost of every new bug larger as the database grows.
  • Writing up the bug as a known issue for the read me or release notes when we finally complete the project and didn't get time to resolve it.
  • Not discovering other bugs that are masked by the bug due to people avoiding that functional area where the known bug was reported.
All of these things sap the productive energy of the project team like the 80 dollars a month lost in my family budget.

How do I cope.

1. Be vigilant and visible with test results. Keep them visible and on going.
2. Raise the threshold for what is considered a bug. Sure it would have been better if it worked that way.... but that wasn't in the user story and never discussed till now. Can we plausibly just make that part of user story backlog.
3. As part of the post sprint review, consider the new bugs that are still outstanding. Decide now if we can ship or put the product into production with these bugs. Don't be a fence sitter. It is OK to have up to 20% as "maybes" but if the customer/product manager can't accept certain bugs recently introduced then they get fixed before new user stories are added. This is part of what it means for each sprint to produce a potentially shippable product.
4. Remind the team what a crunch they use to have at the end of other projects. Use that as a motivator to not put things off and not be overly optimistic.

If I'm not running my credit card debt near the limit. I can be agile and make a decision to take advantage of great sale on new patio furniture or I can redo the basement the way I'd really like to after suffering from a flood. If I'm agile I pay as I go and I have choices. I have head room to respond when the unexpected happens. I can take advantage of business opportunities arise because I'm always just weeks, not months away from shipping or going into production.

Wednesday, March 4, 2009

Sometimes there are dark days

Maybe all the grim economic news has me down. The thought occurred to me yesterday that possibly some of the people on my team are attracted to and proclaim support for agile due to a mistaken belief that it is just project management lite. They don't see a lot of paper and ceremony and they think "gee this is a lot better than the place I use to be where we had to write all those software requirements specifications and fill out all those change request forms. I can just do what I enjoy - writing code....." And there in lies the central problem for someone promoting an agile development model. It is easier to give someone a check list to fill out or a template to complete than it is to shift their values or beliefs. If one is truly faced with some one who is so ego centric that they are primarily motivated just doing a private intellectual exercise - code writing you've got an up hill battle facilitating agile adoption. Maybe a hopeless one.

Going back to the Agile Manifesto, it is primarily a values statement. If you don't buy in to the values you'd really be better off with a cook book approach. The teams I've met and worked with that are truly practicing agile have been and are very driven by process. Ironically this is the opposite perception of those who don't understand agile and speak negatively about it. I met one of those people the other day. He started the conversation with "I hate Agile it cost our company x dollars on a project we did using that some time ago." He elaborated "when we got to the end nothing worked and there was lots of finger pointing. " Our conversation on Agile was tangential to our primary discussion and it wasn't the place to start evangelizing about agile. I should have been quick enough to key in on the "got to the end nothing worked part" My gut feel is that perhaps it was one of those loose type processes that masquerade as an agile project. Instead I said well "Agile isn't appropriate in every situation." That is also true.
And here's the part where I make my self feel better. What I needed to do in that situation was build a new relationship, not get on a soap box about Agile. So I was living the values statement of putting people ahead of process. In the end I can only hope that if I can influence people by being genuine and living the values I profess. And, throw a few hardballs like I did today when I called our team on letting the bug backlog build up.