“What leeway do you have in your projects to try out other approaches and to consciously go new, simple paths? To what extent do companies give project managers, scrum masters and product owners as well as consultants a free hand in choosing the procedure, in project planning, in communication or in the type of cooperation in the team (keyword self-organization)? And with which approaches are you successful? ” This is what the project magazine asks in the latest blog parade with the topic “ More success through new freedoms in the project “.
I am happy to take part in this blog parade and answer the questions asked from my point of view. I am part of a team (with 5 people) that provides infrastructure services for a major customer. The product is a mixture of hardware and software such as a car, airplane or an ICE. So that the customer remains anonymous, I will not go into detail on the product. It is important that a product is manufactured (hardware) which communicates with various IT systems via IT infrastructure and maps special use cases for the user. “A use case is a use case and bundles all possible scenarios that can occur when an actor tries to achieve a specific technical goal with the help of the system under consideration ” (Source: Wikipedia ).
initial situation
One day our client requested that we be on the project From now on, work more agile and the various service providers are more closely networked. He suggested the Scrum of Scrums method for this. The idea was we work with the same software on the one hand (Jira – software for process and project tracking) and, on the other hand, we regularly cross service providers change. We are a total of four service providers in the project, which up to before 12 months have worked side by side rather than together:
- IT infrastructure service provider (we)
- IT software service provider
- Hardware manufacturer
- Business consulting
Scrum of Scrums: in a nutshell
I already have the method behind Scrum of Scrums in detail in my Article on Scaling Scrum and will therefore only briefly sketch them at this point: The simplest approach to scaling Scrum is Scrum of Scrums. Imagine a project with six teams. Each team in turn consists of 8 team members. All teams hold their own daily scrum meeting. Further (overarching) Scrum teams are then formed, each of which consists of a representative of the six teams and meets weekly.
Scrum of Scrums in Practice
In our project, each service provider has his own Team that works according to the classic assignment of the customer. There As an outsourcing service provider, we use our own tools and Working methods. We used to talk directly to one or more The customer’s contact persons were exchanged about the tasks. Through the new Scrum of Scrums, we are now working together, agile and networked.
In the first step we have to work together to implement it analyzed: who has to work closely with whom? The first result was that Cooperation between hardware and business consulting. This was important since especially the hardware can only be changed with difficulty in the course of the project and for series production exactly to the use cases of the specialist department must be coordinated. In terms of content, the meeting usually revolves around that Technical concept.
We then act as an infrastructure service provider the task of our servers and virtual environments to new hardware adapt. In this context, the hardware manufacturer agrees extensively us in another meeting. The content is mostly technical Implementation of use cases.
Finally, there is another round of coordination with the IT software service providers, in which software and operational issues are clarified (DevOps). DevOps is an artificial word from the terms development and IT operations and describes a process improvement approach. A representative from the business team is often also present at the meeting so that requirements are not misunderstood. A coordination between software and hardware is not necessary, as we have virtualized the environments to such an extent that it is not important for the software manufacturer which hardware is used.
Due to the contractual situation, service providers have to continue to be controlled by the customer. Because of this, every circle in the second level a dedicated contact person for the customer as an organizer and Scrum Master. We work together on a Jira board of the customer, which is synchronized with our internal ticket systems.
Overall, there is also a meeting every week in of the overall round carried out. The representatives of the district report as also a representative of each service provider will discuss the overall progress and overall Ask. All contact persons and decision-makers of the customer are also closed invited to this weekly meeting. The central element is a Jira board with epics so that everyone can get a quick overview. An epic is short said a big task (e.g. setting up a webshop), which is divided into further subtasks (Securing a domain, installing a web shop system, etc.) structured becomes.
Implications for collaboration and success
Thanks to this new way of working, collaboration on complex product issues, which can only be dealt with by several experts, has improved. The cohesion and fun in the project have also increased significantly, as well as the bond with the customer and the commitment to the product. In order not to violate guidelines, each meeting and each circle is carried out by a special contact person of the customer. It took us almost a year to establish the working method and we always had the full support of the customer’s management.
In my experience, clients nowadays are not only open to new approaches, they often even know their way around and what they want so well that they themselves ask the contractor to use certain methods. What experiences did you have? Feel free to take part in the blog parade with your experience!
[werbung] [fotolia]
