How to Achieve Customer Satisfaction with Scrum, DevOps, and microservices

Read the Article on Medium published in the Serious Scrum publication

As software companies move toward automating software delivery and testing, they may consider extreme modularization with microservices.

Scrum and DevOps

Scrum and DevOps methodologies are very closely linked; without adopting Scrum or Scaled Agile, it will be very difficult to implement DevOps.

The DevOps methodology is very much linked to the concept of silo removal at various stages of software implementation. In particular, the breaking down of barriers between the developers, the testers, up to the people responsible for the release and installation. It is crystal clear that to break down these barriers you need to have teams that are responsible for the entire supply chain: from the requirement gathering to the development, testing, release, and installation.

While the DevOps methodology leverages test and installation automation, you always need people to automate testing and modify and improve release and installation processes.

How Scrum Helps

Fortunately, Agile frameworks, especially Scrum and SAFe (for large projects) meet these needs. Scrum, in particular, prescribes to have self-organizing teams that can handle a requirement from beginning to end.

The Product Owner is responsible for managing the business initiative, taking charge of the Product Backlog. The Product Owner will share the Product Backlog Items with the Scrum team.

The Development Team will be responsible for processing the Product Backlog items, which often contain User Stories, into work that the whole Development Team will take charge of. In doing so, the Development Team will estimate the effort needed to complete the items.

The Scrum Team is made up of the Product Owner, Scrum Master, and Development Team members who include cross-functional members, such as software developers and quality assurance professionals. In this way, the team can complete the realization of the business initiative, from the requirement gathering to the release and beyond.

Frameworks created for DevOps come in handy, allowing to automate the versioning, build, test, and release processes as much as possible.

The Branching strategy

When practicing Scrum, it’s critical to have an increment that can be potentially released at least at the end of each Sprint. To be able to release so frequently you need to have a good branching strategy. Fortunately, some tools allow you to manage the software in the best possible way both in terms of tools and processes.

Projects that do not have a clear, shared branching strategy, create code conflict issues, code changes, and regressions in the source code. The product is ready to be released, at best, when you need to make an official release every 4-6 months.

Worrying about the quality and maturity of the code to be released only when you are near to the official release date results in issues that may not be solvable in the short amount of time that you identify to stabilize your code. This type of approach leads to situations of high stress where it becomes necessary to work outside of office hours to try to recover problems that are most often not solvable quickly. Adding new features in small product increments solves these kinds of problems and helps to be focused on the real needs of end-users.

Git and Gitflow

The most widely used versioning system for source code is Git. Git gives you the ability to create branches in a very simple, fast way, and without requiring too much hardware resources. In the past, many companies used SVN as their preferred versioning system; one of Git’s biggest advantages over SVN is the ease of creating both local and remote branches.

GitFlow is a set of guidelines, which suggest the best way to manage branches with Git; by following the guidelines you can always have stable software versions that include a set of known features.

Atlassian GitFlow

The figure above illustrates the branching strategy recommended by GitFlow. In the master branch (blue) there is the last official release of the product; in the Develop branch (purple) there is the latest full version of the features developed; the feature branches (green) include the features under development that still need to be merged into the Develop branch. This type of branch management solves many problems in managing the versioning of your code. It also helps to have in the Develop branch the latest stable version of the product including all features implemented and that can be released at any time.

Scrum and branching strategy

Having a well-defined branching strategy helps to have a product that can be released at any time. This is the key to being able to release, if necessary, a product increment after each Sprint. Although some features that need to be implemented within the Sprint are delayed, they do not affect the operation of the product because they remain on feature branches without being merged into the Develop branch. A good practice is to run automatic regression tests before merging the software to the Develop branch; so you can be sure that all previously implemented features are not impacted by new developments.

About microservices

To be able to properly handle the whole process, it is necessary that the software has been built in a modular manner and that it has been properly documented. Dividing the software architecture into functional modules and creating a feature model is a good way to document the software. Functional modules do not necessarily correspond to microservices, a good microservices architecture usually is inherited from a good modular architecture.

The extreme modularization of microservices leads to software management problems that if not addressed correctly will fall on us putting the entire software platform at risk.

Being ready to migrate to a microservices architecture means you have the infrastructure ready for automated testing, build, and automatic releases. It should be taken into account that with the proliferation of independent software modules some operations that could be managed manually (test, build and release) will have to be automated.

Many times the use of microservice architecture is considered the solution to all the problems, indeed it is the last thing to try after: properly modularize the software in functional domains and try to run more instances of the software in load balancing to try to solve performance issues.

How to achieve Customer Satisfaction

Scrum enables software development teams to be able to demonstrate new functionalities to the customer on every product increment. The product increment can be as small as one week. So potentially every week new product functionalities can be demonstrated and released. To be able to release new features every week, it is needed to have a well-modularized software (microservices) and have the needed automation in place to test, build, and release (DevOps).

It is crystal clear that a development team that is able to release working new features every week to the customer that is asking for them will be the dream of any client. Moreover involving the customer in the Backlog prioritization and Sprint review will keep him/her engaged all the time and make her/him feel part of the team. A happy customer is also a helping customer, on the contrary, an unsatisfied customer is an unaccommodating customer that will help the team sinking down.

Some history

The system development life cycle (SDLC)

“Originated in the 1960s, to develop large scale functional business systems in an age of large scale business conglomerates. Information systems activities revolved around heavy data processing and number crunching routines” Elliott & Strachan & Radford

The first formal description of the waterfall model was made in 1970 in the article ‘Managing the development of large software systems’ by Winston W. Royce. In this article, there was already the understanding that software testing can lead to major changes in software design

The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Winston W. Royce

In 1986 Hirotaka Takeuchi and Ikujiro Nonaka introduced the term Scrum in the context of product development in their Harvard Business Review article, ‘The New New Product Development Game’.

In 1995, Jeff Sutherland and Ken Schwaber jointly presented a paper describing the Scrum framework at the Business Object Design and Implementation Workshop.

In 2001 the Agile Manifesto was born

In 2009, the first conference named devopsdays was held in Ghent, Belgium. 

In 2011 the Scaled Agile Framework was born to scale the Scrum framework for large Enterprises.

In 2011 a workshop of software architects held near Venice used the term “microservice” to describe what the participants saw as a common architectural style that many of them had been recently exploring.

FINAL THOUGHTS

Agile, DevOps and microservices are all very popular concepts and very valid management and architectural methodologies, you just have to be careful not to try to adopt them just because they are trendy but to have a good understanding and evaluate the real benefits for the organization.

If you liked the article you can read more in the Agile section