Project Management tips for keeping DevOps projects within time & budget frameworks.

Project Management in the Age of DevOps

DevOps is a concept with different interpretations and definitions, but when you get down to it, it’s all about developers and operations teams breaking down silos and working together to innovate faster. For many companies, the ability to innovate at a rapid pace — responding to market conditions and customer feedback — is a key factor for success. Adopting the DevOps philosophy requires a new mindset, new tools and new skills.

5 tips for keeping DevOps projects on time and under budget.

By Christopher Null 25 Nov 2014

The continuous development and delivery cycle of DevOps has increased the speed of code deployment, but it’s turning traditional project management into an artifact of the past. Now more than ever it’s crucial to keep projects on time and participants all operating on the same page. How do you do that in an age when software is increasingly defining business success? The pros working with DevOps share some hard-earned advice.

Out: Organizing employees based on department
In: Integrating everyone into a single team

“Standard project management philosophies don’t always apply to DevOps,” says Craig Schneider, managing consultant with Excella Consulting. That means dropping the usual hierarchical approach to management and carrot-and-stick standbys when it comes to deadlines. Step one is to bring everyone under one roof.

“The DevOps folks should not be treated as a separate organization with their own deadlines and responsibilities,” says Schneider. “It is absolutely critical that DevOps folks be embedded with your development teams or at least be working very closely with them in a collaborative fashion. The old model of creating tickets or change requests and assigning them to the Ops or Admin folks to implement is no longer relevant with DevOps.”

Ivo Vachkov, founder of Bulgaria-based DevOps services provider Xi Group, emphasizes that “DevOps should be treated as an integral part of the development process. It is usually not a task that can be directly delegated to an operationally inexperienced developer. Serious operational background is required to do it right.”

Out: Deferring quality assurance to the end of the project
In: Building in time to test as you go, at every step

Gone are the formal QA-driven days of develop, then test and then revise. Successful DevOps deployments require organizations to embrace test-driven development and continuous integration approaches to keep projects running swiftly, says Sandeep Sood, founder of Monsoon, a mobile application developer.

Sandeep Sood

Sandeep Sood


Founder, Monsoon

Testing still has to happen, and the team must build it directly into the development schedule — and above all, not sweep it under the rug in the race to get the latest build up. “Test, test again, then test some more. Software will have bugs. And DevOps code is no exception. We’ve had painful experience with this,” Vachkov says.

Out: Telling
In: Showing

Talking to the team about progress on a project is ineffective in today’s complex, visually driven environment. Sood recommends requiring all team members to demonstrate their progress, rather than giving verbal updates.

“One of the most common mistakes in the field is being too afraid or lazy to demand that team members are fully transparent about their progress,” Sood says. “Ask for an actual demo every week, at a set time and day. Did you write some code that does X? Let’s see it, even if it is fairly rudimentary right now. Did you get a test server up and running? Let’s take a look. This can feel uncomfortable at first, but it gradually becomes habitual. Because progress is fully transparent, people get help early, and it’s completely clear when a piece of a project is at risk.”

Out: Prioritizing requirements based on importance
In: Treating nonfunctional requirements as equals

Many developers knows that as a project approaches launch, “wish-list” requirements that don’t affect the functionality of the product often drop off the to-do list. While the honorable intent is always to add these dropped requirements back in later, the reality is that they rarely return. This is how products go out the door with poor documentation, an unfinished user interface, or temporary graphical elements. The solution is to treat all requirements as standard requirements, even if they’re merely cosmetic.

“The implementation phase is usually the longest and most tedious. Short deadlines, team friction, and management pressure lead to a strain on resources, and this is where most nonfunctional requirements are dropped on the floor. Adding them ‘later’ is a recipe for disaster,” Vachkov says.

Out: Hoping for the best
In: Expecting the worst

Finally, it’s key to remember that the first iteration of any new product isn’t going to work properly. In fact, it probably won’t work at all. Planning for testing, as outlined above, is a good start, but planning for recovering from a disaster is also critical. The team should build potential failure directly into the project timeline. If things work out better than expected, the project will be pleasantly ahead of schedule.

“Design for failure. Always assume it will happen, and design the recovery process,” Vachkov says.

Christopher Null

Christopher Null is a 20-year veteran of technology and business magazines and websites. After turning in stints with Ziff Davis’s PC Computing and founding Future Network’s Mobile Magazine, Null spent four years at Yahoo! on the front lines of technology blogging. His first major website, Filmcritic.com, was acquired by AMC Television in 2009. Null received his MBA from The University of Texas at Austin.

Advertisements
%d bloggers like this: