Management 3.0 is not another framework; it’s a mindset, combined with an ever-changing collection of games, tools, and practices to help any worker manage the organization. It’s a way of looking at work systems.

This post delves into how Management 3.0 practices could be used as an effective tool to bring change.

Moving Motivators

As an enterprise coach, I used Moving Motivators to help my enterprise head understand the intrinsic motivational factors of his leadership team, which is comprised of 12 managers. In one of their recurring catch-ups, I was invited by the enterprise head to help him understand the motivational factors for his team.

I printed enough sets of Moving Motivators (they are available for download) to engage everyone. I asked people to move around the room and arrange themselves in a way that gave them space to stack ten cards in front of them. Then I handed the cards to each individual and asked them to order them based on their individual preference of what motivates them the most. We said there should be only one card in a row.

Everyone was inquisitive and became really engaged with the game. We didn’t time-box the event as we wanted everyone to think and do it. Once everyone put the 10 motivators in order based on preference, we asked them to observe others. We didn’t ask individuals to delve into their thought process behind how they ordered it.

The enterprise head observed something that most people chose Autonomy, Mastery, and Purpose for their top three, and this helped him understand what motivated his leadership team. He then used this to adapt his own style to match their expectations.

Kudo Cards & Sprint Retrospective

In the team retrospectives, I use multiple liberating structures to bring out the voices of people. But one thing I am very fond of is Kudo Cards. Personally, I’m a fan of giving a physical card as a way to recognize someone.

I use Kudo Cards frequently in Retrospectives so that team members can recognize their peer’s work. I generally leave it open to the individuals to pick the Kudo Card of their choice in order to thank those who have helped the team or a person or to congratulate someone for who has done an outstanding job.

At times I frame retrospective questions as a way to provoke thoughts about certain missed achievements within the team. I have used it in different circumstances for my team to appreciate or acknowledge their peers.

Happiness Door

Happiness DoorIn

my Scrum Training workshops, most of the time I start with the Happiness Door. I use this in multiple ways.

It’s a great way to break the ice at the start of the workshop, as most people don’t know each other. Then it’s good to be used as an introduction to the class; it’s more fun than typical introductions.

I usually draw three expressions on the flip chart and stick it at the back of the door to the workshop room. It is used as one of the many prompts in my class, and I start with this and ask people to write their names on the sticky notes and paste them near the feeling they have.

I also do this purposefully at the start to make people associate with their feelings. During the debrief, I find that most people explain their souls to the group. The debrief at the end ensures that the candidates have conversations where they carefully collaborate based on other people’s feelings.

Delegation Poker

An impression of the Delegation Board

When I was working in a high-profile payment gateway company, there was restructuring in the organization as part of the transformation. The Product Owner role was newly introduced in the organization, and at times there were conflicts with the engineering managers, and there was a lot of confusion within the teams without clear accountability.

So we used Delegation Poker to help us come to a middle ground. Initially, I collaborated with everyone involved (Stakeholders, team, etc..), identified the key decision areas associated with them, and then sought consensus with everyone before finalizing it.

All the key decision areas were listed vertically in a column, and all the seven delegation levels were horizontally listed. We ran the exercise in three parts, one with the team, one with the product owner, and the other with the engineering manager. We captured all three perspectives and showcased them to everyone to make them understand the thought process of others.

We invited people to be available for a workshop and had them agreed on the levels of freedom for each area. We posted this in a place where everyone could see and after we noticed more clarity in ownership and a fair amount of alignment. We continued checking in with the process, and the delegation evolved.

Personal Map

Once in our team, we were planning for an outing, and there were multiple preferences voiced by people, and we couldn’t come to any conclusion. We wanted to get this sorted quickly, so we decided to do Personal Maps to make it transparent and arrive at a conclusion based on preferences.

We wrote our team name at the center and then added all 12 team members’ names around it in a big whiteboard. We then asked individuals to fill in their personal preferences in four areas.

• Type of outing (lunch in a restaurant, team activities in a beach resort, etc…)
• Type of food
• Timing
• Transport

The four areas are further diversified into different subcategories.

With that, we were able to get everyone’s view quickly, and we were able to identify a pattern and finalize the plan.

Communities of Practice 

Two and a half years back, when I was a PST aspirant, I had grouped professional friends from different organizations who had common interests in Agility. We were a closed group of 12-15 people from various organizations, and we named our group as Pragmatic Agility Group. We used to conduct online webinars fortnightly within our groups, with more than one individual taking turns for a webinar to present a topic of their choice in agreement with the group.

Then we met face to face once a quarter. It was a great learning experience for all of us. We also tried to implement Scrum within the closed group. People took turns to play Product Owner and Scrum master roles to gain experience to take their interests forward.

Over time, this group was transformed into an open community meetup. By then, I have started my PST journey. Still, the core group of people who had passion remained and became part of the organizing crew. Finally, this is turned into a public Meetup group called Scrum Master Studio today.

Meddlers Game 

Once when I was working in a start-up in a fund management product company, we had an internal restructuring done, and we had used the Nexus Framework for Scaling Scrum. Initially, the teams were component teams and didn’t have transparency in terms of customer value. They also faced additional overhead of integration.

We had three different suites of products in the organization, and I was given the accountability to form cross-functional squads for one of the product suites. I used the Meddlers Game to help the team simulate customer value generated with the help of cross-functional skills within the group.

We created certain constraints with the help of the Product Owner and the architect on the necessary skills needed within the team. When we did this activity, the team figured out that they lag in a specific ability to attain complete cross-functionality. The missing skill was technical writing. As the product was more of a customizable tool used by multiple organizations to publish their fund performance, technical writer skills were identified as an essential one to address gaps.

Based on the success story of the Meddlers game, other product suites also used it to form cross-functional teams.