Agile Software Project Delivery in a Waterfall World – Part 2


Agile Software Project Delivery in a Waterfall World – Part 2

Continuing on with sharing experiences in how to fit an Agile software project to the demands of a waterfall management and budgeting style. Let’s examine the quirky terms you often hear “running out of runway” and “right to left scheduling” in these types of environments.

“Running out of Runway” is a somewhat amusing way to illustrate when a project’s sprint goals start slipping into following sprints and piling up sprint after sprint. Under normal Agile/Scrum rules, that’s ok and to be expected. But when you are managing to an end date, this can spell doom.   It’s nice to think that we can start off with a team that has assigned tasks and each person will continue to break new ground with functionality and do some refactoring, sprint over sprint. Reality teaches us otherwise and we often find developers stuck in areas of the code or requirements for far too long. If a particular area of the application that your team is developing drags on, even after the best efforts to encapsulate, estimate and understand the requirements and issues, then this is an indication of a serious problem with the project.   Team leadership needs to raise the priority of these areas of development and refocus the talent of the team to resolve them and move on, for the good of the whole team. Often we find that requirements and designs are wallowing or lacking and therefore a concerted effort to get beyond is necessary.

So how, as a team leader, do you accomplish this?   Here’s a few ideas that seem to work well:

-From the onset of the project the agile rules are laid out and the expectation that individuals will be called in if necessary to move roadblocks aside for and with other team members throughout each sprint needs to be made clear.

-Encourage developers to reach out for help when they get stuck sooner, rather than later and state upfront that it will be much better to get help then to spin your wheels and to set a short time limit for themselves.

-Cross training and exposure to different areas of the codebase to help spread the knowledge of the system is another great idea that I’ve seen employed successfully many times. Take easier tasks in one area and assign those to less experienced developers in that area so they gain knowledge of the patterns and techniques quickly.

-On a sprint by sprint basis, evaluation or scoring of tasks (covered in a future blog entry) by the team at the beginning of each sprint will help weigh the work items so that a determination of effort can help you identify what can be given to whom.

-Team members need to be rewarded for speaking the truth about their individual task status and while staying optimistic and energetic, must not fall into the trap of being overly optimistic about their ability to complete a task. The daily stand-up scrums are there to explain issues/roadblocks and elicit help from others, not just to proclaim that “I’m done on time, no issues ( especially when he/she really isn’t done yet )”.

“Right to Left Scheduling” is another way to illustrate having a deadline handed to a development team without regards to design efforts or project planning ahead of time. There are many legitimate reasons for this behavior in business and some not-so.   Often times in the software market place, small windows of opportunity are opened and a software development effort must try to fit new product or services in that timeframe. Sales departments and senior leadership often have a good idea of what those windows are and know that if the organization can achieve reaching that opportunity then strategic goals can be met for everyone.  In other cases a demanding client may be dictating the schedule for your based on their needs.   Otherwise known as time-boxing, a key to success here is to get ahead of the requirements immediately to identify the functionality that will be the most difficult to achieve and areas that are not clearly specified.   Seems like a no-brainer here, but often times requirements are pushed aside until later in the project lifecycle to the team’s demise.   The sooner the team understands what is ahead of them as a whole, the better the sprint planning can be. Over-communication of actual project status to the leadership team and client is essential here. If the schedule really is impossible to achieve, then compromise should be discussed sooner rather than later.

Stay tuned to Part 3, where I discuss delving into unfinished requirements and how to start achieving “wins” early on …

Leave a Reply