The power of agile programming lies in small, flexible and fast working teams. Developers working for large companies and on complex implementations have adopted their own approach to adjusting agile programming to the challenges that come with big business. “Scrum Team as a Service” is Euvic’s response.
There is enough potential to automate more than 30 percent of the tasks that make up 60 percent of today’s jobs, say researchers from McKinsey Global Institute. In finance and insurance, for example, workers spend more than half of their time collecting and processing data, i.e. performing tasks that could be easily automated using techniques that are available today.
Faced with a growing demand, developers have to ask themselves: how to implement automation in the most effective way? The Waterfall approach is outdated and ineffective. When the number of people involved in the project increases, agile methods, which were created as an alternative to the traditional, hierarchical style of IT project management, may fail. “This problem is not only about automation”, states Ola Hesselroth, Business Developer in Euvic. “It applies to all modern development.”
Agile way of communication
Agile software development is based on an observation that expectations of the client often evolve during the project. That’s why the development team tasks are divided into stages, most of which are completed with an implementation. Those stages, named sprints, last several weeks. During this time the IT team develops and tests pieces of software. After each sprint the team should be able to deliver a working version of the product.
Teams are fast, flexible and they manage themselves. There is no hierarchy, team members decide on their own how they will work. Thanks to this approach the decision-making process is shortened, and each member of the team works within the scope of their competences.
The advantages of agile programming in small projects become its weakness in large ones. In modest, well-coordinated teams it is easy to reach agreement. When the number of people involved in a project increases, communication becomes more difficult. Working in agile mode requires a high level of self-discipline, to which not everyone is predisposed. Responsibility for a project becomes blurred and its goals become unclear. Instead of quick and planned implementations, the team begins to extinguish immediate fires.
Scrum, DevOps and SAFe
Within the agile programming methodology frameworks such as Scrum or DevOps (learn more) have been created. They include specific guidelines, relating to clearly defined activities on each level of the production process. Both Scrum and DevOps assume iterative work, frequent solution delivery or close cooperation of teams on software development and maintenance. Scaled Agile Framework (SAFe), on the other hand, allows the use of agile methodology in large projects, where the team can exceed 50 people.
“We have been working according to the description of SAFe for a long time, before even knowing the method”, says Ola Hesselroth from Euvic. He jokes that he invented the wheel again. “The big difference is that we are trying to connect SAFe to the business. The scrum team’s work is just a half of our methodology. The other part is the customer.”
The Euvic’s setup offers a huge flexibility and control of delivered value via working closely with the backlog, budget and reviews of the delivered functions in each sprint review. The two most important persons in the project are the scrum team leader and the product owner (who represents the customer) working closely together. The product owner creates the product backlog. He agrees with the scrum team leader on the scope and story points needed per sprint and on the sprint budget – per quarter or for whole project. He is also responsible for the sprint reviews and testing the product.
Euvic’s methodology – “Scrum Team as a Service” is similar to the one described by Federico Berruti, Geet Chandratre and Zaid Rab from McKinsey. Their method, called “Agile automation”, is based on the scrum principles but adapts to the scale requirements of AI or automated environments.The five key components of McKinsey’s proposition are: team structure, upfront design, trigger driven stories, release management and program support. Let’s take a closer look.
Team structure.
As in other scrum frameworks, development team in “Agile automation” concept has to be flexible. It includes developers, testers, IT staff, and business stakeholders. Each group is led by a product owner, with expertise in the specific automation technology and a subject-matter expert from the business. “He has to be the one that leads and accepts what is delivered”, says Ola Hesselroth, Business Developer at Euvic. “A good product owner understands the problem that we are trying to solve, but he can’t be too technical. He needs to be humble and he has to trust that we have a team and architecture ready to handle our job.”
Upfront design.
Agile automation requires defining the process before work begins, to make sure that the final result will match business goals. Ola Hesselroth from Euvic emphasizes the role of the product owner, who is responsible for the ideation phase of the project. “He needs to know how to deliver value. And the best way to know it is to answer the question – what problem do I want to solve?”
Trigger driven stories.
When there is no way to distinguish user stories (they describe the features and properties of the system that respond to the user’s need), the trigger driven ones make it possible to break the project down into addressable chunks. Agile automation identifies a “trigger event,” such as the availability of certain data or a user action. “This makes it easier to use the new technology and everything it enables for creating better business values,” says Hesselroth. “It’s not only automation described by McKinsey but also event-driven technology like Lambda.” When it comes to big, complex projects, Euvic also divides them into different teams and deliveries. Building a “coupled” system makes it possible to still deliver value quickly and maintain team’s flexibility.
Release management.
Agile automation decouples releases of prototype and production software. The controlled schedule of production releases needs to be coordinated with business. That’s why Euvic recommends selecting the release manager (this function is often performed by the product owner), who should inform organization using Release Notes.
Program support.
Because this style of work is a big change for the whole organization, it is good to offer employees dedicated programs or stuff to support them, establish good practices, and monitor the progress.Customer support after the completion of the implementation is equally important. Euvic specialist are often a part of the maintenance and operations team and help customer solve problems and fix faults after the deployment.
One of the company’s customer was People’s Production, who runs a portfolio of brands in recruitment, staffing and job placement in Sweden. They required a new IT-infrastructure to meet the growing business needs and decided to choose the “Scrum Team as a Service” offer. Here you can learn more about this cooperation.
