Agile and DevOps Needs a Stakeholder Reporting Layer

Introduction

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

The term “Agile” was applied to this collection of methodologies in early 2001 when 17 software development professionals gathered in Snowbird, Utah to discuss their shared ideas and various approaches to software development. The joint values and principles that they agreed were expressed in the Manifesto for Agile Software Development and the corresponding twelve principles.

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-organizing cross-functional teams. Most agile development methods break product development work into small increments that minimize 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 minimizes 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 realization 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 mobilize. 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 synchronization 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 organization 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. This is where ServiceClarity come in. ServiceClarity’s business value metrics dashboards provide managers with real-time automated reporting on best-practice KPIs captured from cloud service metrics. Customers can set targets and automate KPI reporting in order to understand the agile processes that need to be improved.

By highlighting what is working and what is not through simple KPIs, and by identifying why through drill-down analysis, customers gain the required insight to optimize their agile processes.

Find out more on ServiceClarity for JIRA reporting, read more…