In the late 1990’s, several new methodologies began to gain acceptance in the software development community. These methodologies emphasised close collaboration between the development teams and business stakeholders; frequent delivery of business value, tight, self-organising teams; and smart ways to write, test, and deliver code.

Agile software development describes a set of values and principles for software development under which requirements and solutions evolve through the collaborative effort of self-organising cross-functional teams. Most agile development methods break product development work into small increments that minimise the amount of up-front planning and design. Iterations, or sprints, are short time frames, that typically last from one to four weeks.

At the end of the iteration, working functionality is demonstrated to stakeholders. This minimises the overall risk and allows the product to adapt to changes quickly. An iteration might not add enough functionality to warrant a product release, but the goal is to have an available release (with minimal bugs) at the end of each iteration. Multiple iterations might be required to release a product or new features.

DevOps and Agile

DevOps, then, enables the realisation of the benefits of faster delivery of functionality achieved through Agile. A fundamental requirement of DevOps is that the Ops team is continuously engaged with the development team throughout the life cycle of solution development. Ops should participate right from the initial stage to understand the business requirements, the epics, and the release time lines. They should also contribute to determining the solution's technical and schedule feasibility. From the initial stage through the development stage, the Ops team should provide the necessary inputs to the development team in order for them to build and validate the Ops-related requirements.

The Management Challenges with DevOps

When it comes to managing DevOps projects, thinking Agile is a core requirement. Using Agile leads to a faster and more adaptive management process that breaks down once-monolithic projects into quick-hitting sprints.

The tricky part is that the management of agile projects requires more continuous effort and, more subtle attention than the classic waterfall techniques. In a typical waterfall project, the executives approve a budget and a schedule at the outset; after that, it's just the occasional review meeting to gauge progress and to give feedback. The project managers can simply "ticks the boxes" as each requirement in the spec passes its acceptance criteria.

In contrast, agile projects require much less up-front work; the specification and controls are developed and enforced during the life of the project. Agile projects have no detailed specs—sometimes not even when they're completed. Control is enforced around seven recurring events. These events are as follows:

• Project planning: Project planning includes creating a product vision statement and a product roadmap and can take place in as little time as one day.
• Release planning: Planning the next set of product features to release and identifying an imminent product launch date around which the team can mobilise. On agile projects, you plan one release at a time.
• Sprint: A short cycle of development, in which the team creates potentially shippable product functionality. Sprints typically last between one and four weeks.
• Sprint planning: A meeting at the beginning of each sprint where the scrum team commits to a sprint goal. They also identify the requirements that support this goal and will be part of the sprint, and the individual tasks it will take to complete each requirement.
• Daily scrum: A 15-minute coordination and synchronisation meeting held each day in a sprint, where development team members state what they completed the day before, what they will complete on the current day, and whether they have any roadblocks.
• Sprint review: A meeting at the end of each sprint, introduced by the product owner, where the development team demonstrates the working product functionality it completed during the sprint to stakeholders, and the product owner collects feedback for updating the product backlog.
• Sprint retrospective: A meeting at the end of each sprint where the scrum team inspects and adapts their processes, discussing what went well, what could change, and makes a plan for implementing changes in the next sprint.

The Need for Stakeholder Reporting

DevOps and Agile needs proper tooling, particularly around reporting to key stakeholders, to be really successful. As DevOps has evolved a complex tool chain has emerged to help manage Agile projects. One of the leading management tools is Atlassian’s Jira, but again Jira can spread in an uncontrolled way inside an organisation and add to the reporting problems.

Because agile processes are iterative it is sometimes difficult for stakeholders to really understand what is happening in projects or whether projects are on time and on budget. These stakeholders include not only Dev and Ops but management, product management, marketing, sales, finance etc. The problem is increased when stakeholders need to look across multiple projects.

Expertly-Managed Remote Agile and DevOps Services from Anaeko provide executive reporting of quality, progress and cost.

Anaeko have partnered with Octopus Deploy to provide Multi-Cloud and DevOps Services. Octopus automates complex deployments and seamlessly integrates with your DevOps tools. Anaeko are DevOps specialists, having delivered solutions to a range of sectors with various levels of scale.

Join our next Webinar - Making Modern Deployments Simple: