Share →
Buffer

Are your projects managed by a traditional PMO? Is your company culture all about planning? Are your executives expecting gantt charts, EV, and strong budgetary management of your software projects? Are you trying to transition from a traditional SDLC to an agile SDLC?

If your organization follows a more traditional SDLC and you want to move to shorter iterations, you may want to stop and ask yourself, “What is it that we want to improve?” Likely, the compelling reason for moving to agile is because you need to deliver product faster. But enforcing 4-6 week iterations does not mean you are going to be able to deliver more quickly. Agility isn’t just about short iterations. It’s a unique discipline that requires a mental and cultural shift. In your 2-4 week iteration you are delivering potentially releasable product, which means you need to go through the design-build-test process within that period. Many traditional organizations think they can take their existing requirements gathering, designing, building, and testing processes, miniaturize them, force them into short iterations, and suddenly they are agile. It doesn’t work that way.

There are many things that must be put into place before you can get to short sprints that are capable of releasing shippable product with a high degree of confidence in it’s quality. Remember, agility is about fast feedback, building quality software, and delivering value to the customer. It’s not about shortening your delivery cycle.

Prioritize your organizational goals for moving to agile. What is it you wish to achieve? Now ask yourself, are you willing to do what it takes to get there, including radically altering your SDLC practices? Unit testing, less upfront design work, building a safe-to-fail culture, and having cross-functional teams are just a few of the areas that need to be developed if you are to become agile!

(Original article appeared in June 3rd 2015 edition of The Tempo)

Print Friendly