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.
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.
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.