DevOps is a hot topic at the moment, but as technology forges ahead with adopting the practice, the business unit seems to be lagging behind. The reason for their delay in embracing the practice is simple: the lack of clarity of their role in the DevOps world.
Traditionally the business unit was responsible for making strategic investment decisions and managing the financial aspects of projects and programmes. It comprises key stakeholders who focus on the ‘big picture’ of the programmes across the organisation and decide what to build, sponsor the development efforts, and ensure everyone has a clear understanding of the end-product that is being built.
While implementing DevOps doesn’t change the role of the business unit, it does require it to change the way it works. To implement DevOps successfully, the business, as it will be known from here on in, needs to change its approach towards production, budgeting and funding projects, and even adapt its team structure. As Brickendon has said many times before, DevOps is about a change in mindset, not just the adoption of a new methodology.
DevOps is about a change in mindset
In the traditional software delivery framework, the business works to produce the project scope, develop the project management plan, and define the business and functional requirements. This work is done at the start of the project and follows a strict and sequential process across three distinct phases: project concept; planning; and requirements gathering. The output of the first phase is used as the input into the following phase, and each phase needs to be complete before the project can progress further through the software development lifecycle (SDLC).
The challenge with working within the traditional framework is that the business presumes that everything it defines at each phase will still be applicable throughout the entire lifecycle of the project. It leaves little flexibility for the delivery team to adjust to any unexpected changes of the project’s parameters and locks release cycles and deliverables, which if missed, could have financial consequences.
Transition to DevOps
By contrast, within the DevOps framework, the business becomes the product owner and moves from working independently to working collaboratively within an integrated multi-skilled DevOps team. As product owner, the business takes ownership of the end-to-end software delivery process and sets the direction of the team in such a way that ensures workflow runs smoothly. It also retains the responsibility of ensuring that every member of the delivery team has a common and clear understanding of the features being built and how each feature delivers value to the end-product.
With DevOps, the business transitions from working in a rigid framework, where the entire scope of the project is defined up-front, to an approach where the scope is defined in small targeted sections. This enables work to be prioritised as appropriate, reduces the time taken to complete tasks and allows the earlier discovery of problems, making them simpler, cheaper and less time-consuming to fix.
Collaboration
One of the most important responsibilities of the business is to engage the DevOps team to define the project strategy and implementation roadmap. Where typically each group would develop strategies catered specifically to their own responsibilities, (Dev strategy, QA strategy, Ops strategy), with DevOps the product owner is accountable for producing a common strategy and implementation roadmap. The team collaboratively sets the project’s goals, determines actions to achieve the goals, and mobilises the resources to execute the actions.
A good strategy creates a common (unbiased) view of what the team is trying to implement, how they are going to execute, how each member of the delivery team will be involved in the implementation, and the associated timelines. It pushes each member of the team to think critically about their role in implementing the strategy and instils accountability for each in meeting their goals. Reality is that things will change throughout the project and as such the product owner must build flexibility into the strategy to seamlessly adjust the implementation roadmap along the way.
Fewer coding defects
Rather than writing complete detailed specifications and then reviewing them with the delivery team, the business produces a backlog of feature stories and works collaboratively with the entire DevOps team to define the desired and non-desired behaviour of each feature. Each story must include examples, pre- and post-conditions, acceptance criteria, and non-functional requirements that guide coding and testing.
Having all this information captured as part of the feature leads to fewer coding defects and improved quality software, while also shortening software development cycles. When defining feature stories, the business must ensure that every member of the delivery team has all the information they need in order to do their jobs. This means broadening the scope of the features to be defined to include non-functional requirements that address the needs of operations, compliance, and information security. Requirements should cover system reliability, performance, scalability and supportability. In doing so, they take on responsibility for the overall quality of the software.
Just in time
The analysis process goes from defining all of the requirements up-front, to the ‘just in time’ concept, where requirements are only defined as they are needed. ‘Just in time’ is an analysis approach of Lean Methodology and helps ensure that there is no waste in the analysis process. This also assists the delivery team to focus their work on what is relevant at the given time. Changes in the timing of the analysis naturally positions the business to take control of the workflow. Work is managed through a Kanban board which provides full of transparency of the project work, including work in process, project status, team progress, and team capacity.
This level of visibility allows delivery teams to rapidly adjust to any changing requirements. All change requests are filtered through the business so they can prevent any change in priorities from affecting the delivery team’s objectives. This differs from the traditional method where requests usually come in from multiple sources, cause conflicts between deliverables, and contribute to resource constraints.
Voice of the customer
Not only does the business continue to be the voice of the customer, it must also address the needs of the developers, testers, and operations and compliance individuals. In some organisations the business even conducts hands-on testing alongside the testers.
Lastly, it is expected that DevOps will impact the budgeting and planning cycle for IT. The business needs to think about how it will realign the budgeting process for DevOps. This could mean moving to shorter budgeting and review cycles, or using an agile product funding model rather than the traditional project funding. This flexibility would allow teams to allocate funds dynamically within the project, as they see fit.
Click here to read Brickendon’s latest DevOps flyer highlighting the benefits of implementing the methodology.