Transitioning Methodology In Midstream
Have you wanted to switch from the waterfall methodology to an agile and DevSecOps approach? After all, agile methods coupled with DevSecOps process automation can drive quality, performance, and security improvements while increasing program-wide productivity and controlling risk.
So, yes, you may have several reasons TO switch:
- Agile and DevSecOps are better, faster, and cheaper than traditional methodologies.
- Many developers prefer to — and are used to — working this way.
- It’s how to achieve DevOps benefits of continuous delivery and cloud infrastructure-as-code.
- You have organizational mandates.
- Or, you just may have the desire to modernize or be feeling external pressure to do so.
Agile methods are iterative and incremental development processes require rapid and flexible responses to change. A complete solution may not be fully defined at the beginning but quickly evolves. A team can take on the highest priority requirements, build production code, and launch within weeks.
With DevSecOps, testing for threats is constant, automated and fast—instantaneously doing what would have taken humans weeks or months to perform. Security is integrated throughout the product lifecycle and is a fundamental part of every stage of development, so there are no surprises or delays because of security reviews or issues.
But, you may also have plenty of reasons NOT TO switch:
Contractual: Your project and contract structure, published schedule, and progress payments may be tied to milestones or other project events that specify or imply waterfall.
Project state: There are BDUF (Big Design Up Front) implications — the time and capital already invested in requirements, design, documentation — and the implication that all requirements will be fulfilled at launch.
Security and quality risks: Agile methods can push new or refactored code into production every few weeks, but traditional manual security compliance and manual testing require longer timeframes, even months.
Personnel: For an agile approach to be successful, at least one experienced team, product owner, and stakeholder are needed, and coordination must be increased substantially.
Organizational: Substantial change to “business as usual” is necessary to make agile work. All of the processes that stakeholders, project managers, business analysts, users, designers, and developers work under will change to some degree. Users and stakeholders have to attend end-of-iteration demos, accept the results, and be empowered to say yes to launch and to continually improve, update, and reprioritize the requirements. So, teams need to self-contained – everyone needed to build the answer for the next iteration must be a member of the team.
How do you know if transitioning is the right move?
Making the switch may not be possible, depending on your contract, and it could be detrimental depending on your team’s experience. Is the timeline and delivery date flexible? Does the budget allow for making a change? Is the client program team familiar with the agile approach and is the project development team thoroughly experienced in working that way?
If you’ve answered no to any of these questions, you’d be advised to ride out the waterfall and possibly plan for a bug fix team after launch to be your first agile test group or define a set of version 2 features to be built and assign that task to an agile team.
If your project has some time and budget flexibility and may be hitting some barriers, it can be smart to make the transition, though maybe not entirely. For a large, multi-year project, think in terms of risk segregation. Choose a pilot that won’t impact overall success, milestones, deliverables, or budget.
If the siloed pilot is successful, the method can be expanded to other areas of the project. For a smaller project, if time and money aren’t a problem, switching to an agile approach can mean getting to a better product faster.
Remember, transitioning is not just a shift in methodology.
Transitioning requires a shift in culture, and that requires a commitment from everyone involved because they will be adopting new tools, new procedures, and maybe even new team members who are experienced at transitioning from one method to another midstream.
T-Rex employs SAFe® (Scaled Agile Framework) and a proven, proprietary process for implementing agile approaches on both new and in-process projects. We’ve used our tailored SAFe on one of the government’s largest, most secure, and most complex mission critical projects ever with the U.S. Census Bureau.
For more than a year, we have been releasing top-performing software with zero security defects, leveraging our highly successful tailored agile approach to assess, define, develop, implement, and integrate mission-critical applications. Contact us to learn more about the benefits and potential risks of transitioning your project.
Contact Kelly Ralston
703.742.0566
kelly.ralston@trexsolutionsllc.com
twitter
