2019
Introduction
Started to work with a new team in a financial IT company in a bank branch. The company has 5 branches, all located in Germany. It is a large-scale enterprise with around 7,145 employees and a turnover of EUR 1.6 billion . In 2018, they started a new program to transform the enterprise from traditional to Agile, and began with 700 employees in the “Centric”program. My new team was a part of this transformation program. The management decided to use a SAFe framework for the transformation program.
The team had already worked together 11 months. Old team members had started to leave the project and newcomers had arrived 2 months ago. The scrum team had PO, Development Team (Business Analyst, Full-Stack Developer, Front-End Developer, 2 Back-End Developer, Config Manager/Scrum Master, Tester).
For 11 months, they had managed to survive the transformation process of the company and worked with an Agile Coach and different Scrum Masters. Unfortunately, all Scrum Masters had a double role like Config-Manager/Scrum Master.
When I joined the team, they were frustrated with agile and agility and saw no advantages in it. The team had internal conflicts, no rules on how to work together, weak work performance and velocity with no stability in it, a lot of bugs and a pronounced home office culture.
The team had the goal to Go Live with a new customer portal at the end of the year. The team had 4 months to be self-organized and deliver the shippable product to the customer.
Background information
After some interviews with Release Train Engineers, PMO, Product Owner and Development Team, I found out that most of the management was not happy with the team. There were many great professionals, but a lot of hidden challenges and issues with team performance.
At that time, the status of the team was quite miserable. A lot of internal conflicts, no transparency, no engagement in teamwork and the team members didn’t want to take responsibility for the results (Graph:Team Self-Assessment).
The team had no clue about how to plan, and always overestimated their plans (Graph: Team Velocity).
Graph: Team Self-Assessment
Graph: Team Velocity
From the previous graphs, it is evident that we here had to deal with a non-self-organizing and ineffective team.
My expectations on the team at that point were as follows:
- Trust building: between members of the team on Scrum, Scrum Master, Product Owner
- Solve all internal/hidden conflicts within a team
- The team engages on all work
- Increase the responsibility of every team member
- Be result-oriented
- Achieve every goal of sprint
- Delivery every sprint a shippable and releasable product
Based on the expectation, I defined the following targets:
- Propagate an Agiles Mindset within the team
- Improve self-organizing values
- Increase understanding of SCRUM values and Agile principles (timeboxing and give actual know-how to team members)
- Present the role of Scrum Master as Servant Leader
- Support Product Owner in her tasks
- Try an eXtreme Programming (Bugs “close to zero”)
The Way to transform the team
The beginning of the transformation was quite a challenging time for the team, and it was as well an exciting time for me.
As known from “John Kotter’s 8-Step Process for Leading Change”, a sense of urgency was created by management: “GoLive for customer portal within 3 months”.
Figure: John Kotter‘s 8-Step Process for Leading Change
Build a guiding coalition
For two weeks, I observed the teamwork, communication ways, interpersonal behavior and the agile values of the team. That gave me the possibility to identify innovators, adopters and also „grey“ cardinals/hidden leaders.
Graph: The law of diffusion of innovation
Form a strategic vision
I created „Agile Road Map“ and got approval by the management on how to change the behavior of the team.
As is known from the iceberg theory, if we want to change the mental models/team member behavior, we had to start to present a new system of work. Some of such techniques were structural meetings, timeboxing for all scrum events, team board, etc.
Figure: Iceberg Theory
Enable
I convinced innovators and started to work with them so that they could share the team vision with other team members. We addressed the necessary topics in sprint planning, dailies and especially retrospectives.
Figure: Timeboxing all scrum events (example Daily Scrum)
The physical Team Board helped us to clear all barriers ot of our way. The team started to communicate freely, discussed working topics and impediments directly on the Team Board. Every team member knew what happened in our sprint and what kind of impediments we had. We increased our transparency. At the same time, team members started work towards a sprint goal, and not to undertake any other work that would not pay any value to our sprint. We were able to see everything that we needed on our team radars – all necessary information, e.g. process diagrams, team velocity, list of vacations and attendances, important dates (releases, publications, check-ups).
Figure: Team Board
I refreshed the team view about Agile, and developed their expertise on Scrum.
Figure: The results of scrum training
Generate short-term wins
Quick wins – all conflicts resolved.
After the retrospectives, every team member felt good and energetic. We prepared all actions to move to technical excellence.
We reduced the time for our meeting and got more time to work on user stories. All the meetings started to be timeboxed and structured (agenda, contributors, targets, timing etc.).
We developed working agreements and specified the existing definition of “Done” to deliver a shippable product.
Figure: Team’s working agreements
Figure: Definition of „Done“
Sustained Acceleration
During the trailing of new techniques such as swarming, pairing, mob-programming, time it was difficult at first to sit without a keyboard, give instructions and mutually discuss the right way to solve the issues.
The frustration to cooperate closely was gone after two Sprints. Everybody enjoyed it and found it a very effective technique to bring a team forward to achieve a sprint goal.
We started to be more efficient and to transfer know-how within the team.
Figure: Swarming, Pairing, Mob-Programming
Institute change
At the end of the period, we achieved all 12 principles of Agile, were a self-organized team that delivered the shippable product.
Graph: Compare Team Self-Assessment before and after
Graph: Team Velocity after
Conclusion
As a team, we achieved our target – “Go Live” with the customer portal!
For me, as Scrum Master, it was very satisfying that the Development Team had made huge progress after three months, in accordance with my action plan. Now it can be stated that we are a self-organized team with great spirit, ready to move forward to new challenges
All the expectations I had concerning the teamwork were fulfilled:
- Agile Mindset: 12 out of 12 agile principles are outlined
- There is an open atmosphere in the team
- No obvious conflicts
- Team members are committed and responsible
- Bugs & Tickets process has been stabilized and leads to consistent processing of Bugs & Tickets
- All team members participated in Scrum Fitness
- “One Face to customer” project was successfully completed
- Requirements for a uniform appearance of the Union teams for PI-9 have been created
- With Team Board we have managed to focus on goals and tasks
- Know-how transfer with pair programming, swarming and mob-programming works well
- Team Velocity has been stabilized and improved
- Meeting satisfaction level has increased
- Team members are up to date (SCRUM and Kanban)
- After the self-assessment, the team members are committed and take responsibility for user stories and the project
- The goal of a “self-organized team” was achieved