- Posted by mateid on August 9, 2010
As a follow up to my previous posts and the issues we’re dealing with on my current project let’s look at how we’re dealing with blockers.
First of all what are blockers? Things that prevent me from doing my work and moving the ball forward, things that make me waste the clients time and money. As of late there are a couple that have managed to sneak in and we’ve not dealt with them effectively. They weren’t blocking any high priority tasks but it is a somewhat unsettling trend. Perhaps that is why the visibility was so low, they were just flying under the radar.
During the standup we all say our piece followed by “no blockers” or “I am blocked by…” (Stating “no blockers” at the end of your update is a bit of a smell to me, it smells of agile implemented as a control mechanism but that’s a post for another day) So how is it than that we have issues that remain unresolved for extended periods of time? The must be a disconnect somewhere. The problem is that blockers were not assigned an owner. Lack of ownership is an issue we learned to deal with quickly.
Soon enough when a team member reported a blocker we started noting it on a sticky, and placed it in a column on the wall dedicated to blockers. We found that an approach that works reasonably well is having a team member own the issue. Just ask for volunteers during the standup! An expected resolution date associated with the item also helps drive the resolution or further escalation. At the end of the standup when everyone has given their update we go through the blockers and deal with them on a case by case basis. Obviously if discussions are taking a long time you can take it off line with a couple of teammates. We found that the increased visibility and daily attention helped us deal with various issues effectively and keep the dev machine from grinding to a halt.
We found that when dealing with blockers what works best is increasing visibility and ownership of the issue. Taking control of your blockers really helps to keep the project moving and it gives an tremendous opportunity to deal with tough issues early and effectively.
- Posted by mateid on August 8, 2010
I’ve been away on vacation for the past week and now I’m back to work. It’s amazing how refreshing a few days off can be, and I’m pretty pumped to be back on my project. Some time off also helps put things in perspective. I can think clearer and see some beginnings of anti-patterns that are making their way into our team’s daily activities. Some of them are mostly related to attitude rather than technical issue and they need to be stopped as soon as possible. I was lucky enough to be on a very difficult project recently where I’ve learned a lot, and I want to talk about how we used to deal with similar challenges. One sentence sums it up: don’t be dogmatic, be pragmatic.
We’re looking at a fairly small project, with lots of front end development using MVC2 and jQuery. Lately we started having some discussions (some of them very heated) about our test coverage, pairing, technical debt and so on. We are starting to fall into the dogmatic trap and I don’t think our project will benefit much from it. Some members of our team expect 100% test coverage, pairing all of the time and zero technical debt. Heh, one can dream! But remember there is a price to pay for these things, they don’t come free.
Take the test coverage for example – the team is somewhat split on this issue: some think that 80% is good enough, others insist that we must be close to 100%. Personally I find myself in the 80% camp. I think to expect 100% test coverage is unrealistic. Test coverage is just another tool to tell me if my tests are covering the code base adequately. If we’re hovering around 80% and I can refractor easily and the test suite is highlighting issues consistently and effectively I am happy. I’d rather spend my time delivering business value than refining my test suite. If on the other hand we’re having issues that go undetected until late in the QA cycle or worse, than yes I wholeheartedly agree we need to work on our test suite and perhaps improve the coverage in troublesome areas. But asking for 100% test coverage is dogmatic and not very helpful to the client. Ask yourself if setting unrealistic expectations for coverage is helping you deliver business value more effectively. When will the client benefit from the activities you’re engaged in and how much value are they going to get in the end? I think this is pretty much the ultimate measuring stick when working on an agile project.
Another good example is technical debt. Say we have about 10% of our code that is somewhat sketchy. It doesn’t really hurt us on a day to day basis but it definitely is high up on the refactoring list. What do you do? Spend the next three days refactoring it or pick up a story and deliver a couple more points? I know it can be a tough choice - the code going into disarray or delivering a few ore points. Here the team is again split. Some think the code is fine, others cry bloody murder, this abomination needs fixing now! Remember this particular piece of code is not hurting us right now. To me the smart and agile thing to do is take note the offending area and deliver business value. I’m not saying sweep it under the carpet! Just deal with the issue pragmatically. If you’re having a hard time justifying refactoring it now than make a low priority tech task and deal with it later. There will be ups and downs in the iterations and an opportunity to fix it will definitely open up.
Don’t be dogmatic, be pragmatic. There will probably always be those that ask for 100% test coverage, zero technical debt etc. Just remember that every project is different and pragmatism will serve you much better than a dogmatic attitude.
- Posted by mateid on October 12, 2007
Scott Hanselman has a couple of videos from the ALT .Net conference in Austin. Here's the post. Should be very interesting. I wish there were 48 hours in the day!