done.
Gather some insights from our previous Use Cases to understand how we work:
-
Being Agile
What exactly does it mean to work agile? Is it a question of attitude - mindset - or is it a method? We would say both:
For us, being agile is simply the opposite of being static. In the business context, agility means continuously adapting to changing conditions and constantly interacting with customers and their needs. The aim is to achieve results that are as close as possible to what is needed and deliver added value to users. Products that are loved.
Applying agility becomes easier when you understand the underlying principles and values. Once this has been achieved, you can transfer agile procedures to individual situations and requirements and have the chance to use approaches that fit instead of trying to pack your own situation into a prefabricated approach. Create your fitting box instead of fitting into a box.
Use Case DB Systel Transport & Logistic Cluster
In the context of organizational development, we have held training courses that start with agile principles, explain the values and finally explain agile practices and agile approaches. Using an onion model, we worked our way from the outside to the inside.
Use Case Blue Movement powerd by Bosch
Also here, we used the "agile onion" and organized an introductory session for all business units. As we believe that learning does not work with pressure fuelling, we introduced the low-threshold format "Agile Lean Coffee": in regular sessions, we discussed questions about agility brought in by the employees and incorporated impulses from our side.
-
Building Product Teams
What are the building blocks of a functional team?
1. Have a shared vision
2. Have clear priorities that make it easier to maintain a focus
3. Have a common approach to work
4. Have psychological safety enabled
5. Have a team coach
The BI X Innovation Hub tests product ideas in terms of desirability, usability and feasibility. Within this framework, smaller product teams are constantly being formed that validate assumptions, design MVPs and develop pilots together for an average of 6-12 months. With a minimum set-up of 3-5 people, we have a kick-off to outline the what in order to define a clear vision. Once the "what" is in place, it's time to prioritise: What do we start with, what comes next and after that? This is followed by the derivation of baby steps that bring us closer to the goal and the vision: We create an initial backlog. Now that we know the scope, we can also check the required skills again. In an expectations workshop, we identify needs and wishes for the joint work and derive a confirmed working approach from this, in which the team's needs are reflected. Then we can get started.
-
Agile Requirements
How can we package our customers' requirements into "sprint-ready" packages for our product teams and how can we ensure that the delivered results satisfy the user?
As Product Owner, Pascal is also responsible for preparing a planning perspective for the next Product Increment, that means what are.we going to deliver during the next 10 Weeks?
We have developed an evaluation matrix that defines the maturity standard, dependencies and technical requirements of the capabilities. As a next step, we have set up an exchange with the business analysts involved to regularly discuss all capabilities. The outcome of both was then reflected in Pascal's planning. Finally, the relevant capabilities are formulated in epics - all the components required to realise a customer requirement - and then derived into smaller packages - the user stories - in the next step with the development team. The finished user stories - DOR - are then implemented in the sprints - work phases.
-
OKRs - what matters the most?
Working with OKRs - Objective and Key Results - helps to set clear and visible goals and to measure and identify the activities that are likely to achieve the goal.
The digital and fully remote "Blue Movement" - a dutch-german Start-Up - powered by Bosch has already been working with the goal setting system OKRs for 1 year when we joined. At the beginning of our cooperation, the employee feedback on the understanding of the OKR methodology and the relation to the set goals was very diverse. We started an OKR reset:
The first step was an intro session "OKR in a Nutshell" to enable all participants to understand the method and to give room for potential experiences. This was followed by an OKR retrospective to categorize the experiences already made. At the same time, the Leadership Team set the impulse to agree on what is important in the coming year and to refresh the vision and strategy. The update was shared with everyone and questions were also clarified here. This was followed by an OKR Cycle 1 preparation phase in which the objectives for the next quarter were prepared both top-down - in the Leadership Team - and bottom-up - in the teams. They met digitally for a 2-day planning session. Firstly, the objectives that were identified as the most important were defined. The second part was to determine the key results. As we represent outcome-based OKRs, we dealt with 3 questions here:
1. What are the users and customers behaviours that drive business result?-> Helps us to define relevant because outcome based Key Results!
2. How can we get more people to do more of those behaviours?-> Helps us do define concrete actions/To Dos aka Initiatives.
3. How do we know that we are right?-> Helps us to decide for the right metrics to measure our progress
The OKR cycle was started with a confidence vote. This was followed by bi-weekly check-ins to track progress. At the end of the cycle, a review was conducted with everyone to share and discuss results. This cycle also ended with an OKR retrospective, which was both the conclusion and the start of the next OKR cycle.
-
Flight Levels
When an entity or start-up is founded, it is important to identify the right structures that link the right people with the right topics. This is precisely the motivation behind our use of Flight Levels, as an approach that structures information and simplifies the division of labour. Flight Level 3 defines the vision and strategy, Flight Level 2 develops a concrete roadmap and coordinates and resolves dependencies, Flight Level 1 is responsible for the implementation and delivery of the product.
Use Case 1) Flight Levels within DB Systel
In context of the transformation of DB Systel to a poroduct-based, self-organised network organisation, the flight levels corresponded to the cluster (FL3) - unit (FL2) and team (FL1) levels. The portfolios and partners are strategically managed at cluster level. The units are formed on the basis of partners and/or services and strategically build up the necessary skills and human resources. Finally, the services and products required by the partner are implemented at team level.
Use Case Boehringer Ingelheim -Animal Health Digital Products & Projects
Animal Health is aiming for digitalization and have digital Products for Pets and Pet Owners developed internally. To structure the work and delivery flow the digital unit decider to work with Flight Levels. As part of our implementation, we communicated the Flight Level structure to everyone involved and clarified questions about the approach. A meeting flow was set up for all levels, which enabled both the exchange and the dedicated work in the respective subject areas. FL 3 has strategic sessions, while in FL2 the epics are worked out together in regular working slots and the dependencies are mapped. FL 1 jointly details the requirements of the user stories.
-
Coaching on the Job
Digital work increasingly requires product owners who strategically align the product and structure its content in order to implement it together with the product team. This is where another role comes into play; the team and work flow coach. The task is to design a work approach that is tailored to the team and product needs, to track it and to constantly adapt its functionality. This task is very complex and combines structural thinking with coaching and facilitation skills. It requires not only the creation of a team spirit but also the involvement of all stakeholders in order to ensure functionality beyond team boundaries.
Product Owner Coaching
In order to transfer former Project Managers into skilled product OwnerI we start with having regular 1:1 Coachings. We aim to enable a profund understanding of agile values and principles. Because once agility has been understood in its essence, its various practices become a simple transfer. As a second step we train agile practices liue ser stories and the idea that every need or problem can be solved in a value-orientated and outcome driven way. When applied consistently, the sum of your user stories result in a structured backlog that always focusses on the added value to the customer. Happy backlog - happy Team and best chances to have a happy User as well.
Scrum Master Coaching
In our 1:1 for Scrum Masters we are available as experienced sparring partners and provide help for self-help. We create an Impediments Backlog to capture the challenges, make their extent transparent, distinguish structural from operational problems and derive solutions. We take a solution-focussed approach and concentrate primarily on the desired target state rather than the initial problem. We see our support here as a kind of supervision that helps the coachee to recognise their own strengths and use them in a goal-oriented way.