New to agile? What to do when you are behind

Wow, has it really been more than a month since I posted something on my blog?  Ouch!  I guess I’ve been busier than I thought.  I knew it had been a while, but I thought it was 2 weeks, not a month.  For those of you who expect content from me more often, I’m sorry.  I’ll try to get back on the 2-3 times per week train.

The good news is during my time away from blogging I found lots of new topics for future posts.  In the coming weeks you find postings on different estimation techniques, how the theory of constraints can help agile implementations, using kanban, and a whole lot of other interesting stuff.  If you have a topic you want me to cover, please email me using the link near my picture.  I’ll start on the blogging train with a quick post on what to do when you are behind!

Now, to make this post somewhat useful.  I’m obviously very behind on my blogging.  My personal goal is at least 2 postings per week so at this point I am about 8-10 postings behind where I want to be.  Since I do use the agile concepts I teach, I have to be transparent and admit it.  The first step to resolving the problem is to admit there is a problem!  This is also applicable to real projects.  You can’t mitigate risk, change priorities or adjust for issues unless you know the issues exist!  Transparency is a key agile concept.

So, what is the magic bullet for step 2?  There is none.  We’ve exposed the reality, now it is time to deal with the reality but we need to be reality-based with our solution.  In my case I could sit here and type that I will suddenly spit out 10 posts this week and catch up.  But even if I could do it, it wouldn’t serve the intended purpose.  I specifically chose 2 postings per week with 3 at the upper limit because I believe it lets people digest what I write.  If I suddenly pop out 10 postings in a few days people just won’t read or absorb them.  I want this blog to be a useful source of information, not something people avoid because there is “too much” content!  Again though, the same thing happens in real-world projects.  If a team is behind schedule they can sometimes pull off heroic efforts in order to get back on track.  Unfortunately, this often points out a bottleneck somewhere in their process which means all of the work won’t be absorbed properly.  Maybe they have some specific testing resources which won’t keep up, or the necessary environments will change too quickly to be used properly, or some downstream resource will be inundated with work which can’t be done faster than a certain rate.  In other words, it is very possible for the heroic effort to simply build a queue which can’t be squeezed through the system anyway.  The best approach here is to analyze what can be done and the impact it will have.  Heroic catch-up efforts are usually ill-fated for many reasons.  In my case, I’m not going to be heroic.  I’m not on a “real” project, so I have the option of just saying the past is what it is, I’ll adjust my velocity back to being 2 postings per week, and occasionally try to get out 3.

Then there is the follow-through phase.  Now that I have made the commitment, I need to follow through.  I’m in good shape so far because this blog entry counts as 1 of my 2 entries 🙂  For a real project a team may need to commit to more accountability.  If a new goal is set and the project is adjusted to allow for success then the team still needs to deliver on the expectations.  This is why the “fix” from the previous step needed to be reality-based.  It makes no sense to commit to something which is a fantasy.

Hopefully the transparency exposed the problem early.  Being reality-based allowed for a fix to be implemented which still can be considered a success.  And the follow-through will be done appropriately by everyone on the team.  If this occurs, then behing behind isn’t necessarily a bad thing.  It is better to expose it early than expose it late when there is no chance for correction except by moving the end date.

Until next time I’ll be Making Agile a Reality™ by helping teams recognize when they are behind and helping them understand and implement realistic solutions to their problems.