Gamification, Defer Commitment and Real Options

Last week we had a Scrum Master Gathering: 60 people from 8 countries and 5 different companies meeting to discuss and share thoughts about Agile coaching, one of the most challenging and yet the most exciting jobs in the world, during 2 days of learning, sharing and fun.

The first day was a full collaborative and self-organizing day, where everybody could contribute to the emerging agenda by proposing an Open Space about burning topics to share or issues they wanted help about from a fellow coach.

The second day was instead about Gamification and Learning Lean: a day of creative sessions to bring back home a number of brand new games to teach the Lean Discplines from Mary and Tom Poppendieck’s book. In fact true Lean Software Development requires that coaches help their teams achieve the necessary mind shift and find new ways of doing things. There is scientific evidence that one of the best ways to learn is by playing: that’s how kids learn and learn fast. And gamification is just the process of using game thinking and game mechanics to solve problems and engage audiences.

But creating a game is not easy; it requires a number of steps to define the main elements:

• What is the Goal of the game?
• Which Mechanics do you like to use? (e.g. levels, points, badges, mission)
• What are the Rules of the game? Are they clear and not ambiguous?
• How many Players does the game require?
• How much Time is necessary? 

A couple of us decided to pick a Lean discipline nobody had selected, being one of our favorites instead: Defer Commitment aka Decide as Late as Possible.

Inventing a game to teach this subject didn’t look so straightforward in the first place, but, being this discipline all around ability to keep your options open until the Last Responsible Moment and live with uncertainty, we decided to take inspiration from Real Options.

What are Real Options? I suggest you to have a look at this article to start understanding a bit more.

The authors explain that in the SW development world, we can learn the following from the Financial Option maths:

1. Options have value.
2. Options expire.
3. Never commit early unless you know why. 

Starting from these considerations, we created a game based on “Guess who?”

You know? The famous game where you must figure out the name of a mysterious character based on the information you manage to get by means of Yes/No questions.

Let me share how it works and the different components:

• Goal

The Goal is the same as the original game “Guess who?” except for having to reach it within a time box of 1 minute

• Mechanics

The game mechanics is based on Points: you start a round from a total of 40 points; each question is costing 5 points. If your answer is wrong you get no point. Who gets more points in 2 rounds wins.

• Rules
• Each rounds is time-boxed to 1 minute, which represents the Last Responsible Moment to take the decision and guess who is the character chosen by the other party
• You start from an amount of 40 points and can give your guess at any time before the 1 minute timer expires
• You can guess right away without asking any question: if you’re right you get 40 points
• Or you can ask how many Yes/No questions you want to get information about the mystery man within the 1 minute time-box. Each question costs 5 points, so if you ask only one question and you’re right with your guess, you get 35 points
• If you’re wrong, you get no point, so asking questions has a cost, but reduces the risk of failure
• All questions have the same cost, so it’s up to the asker find the proper question to maximize the amount of information and knowledge you can get

• Number of players

At least two: either individuals or teams

• Time

2 rounds of 1 minute for each player + 10 minutes debriefing at the end

The final debriefing is meant to let the players reflect on the game, conceptualize the experience and get all learning out of the proposed metaphor, i.e.:

• Exactly as “Guess who?” SW development is a discovery process based on the scientific method: make an hypothesis and verify it through empirical learning
• Options have an expiry date: the Last Responsible Moment
• Keeping your options open until that moment has a cost, but minimizes dramatically the risk of failure
• Since each experiment (like each iteration in Scrum) has the same cost, the key to get faster to success is always to run the most valuable experiment, the one which gives you more information 

Hope now you got curious to try it out. Let me know how it works.

Applying Agility to training and education

You know: I strongly believe that Agile values and principles apply and work very well whenever you have a complex problem to solve, something that you have never done before.

So, if you have a vision of what to reach, but do not know where exactly you’re going and your domain is not deterministic, there’s no chance you can define your path upfront: the most sensible approach you can try is to do one step at a time and strive for fast feedback to verify your assumptions and adjust consequently.

Therefore an Agile approach suit very well many different fields, even outside IT, given that people involved in solving the problem have the right domain knowledge. 

For instance, as a trainer, I use an Agile approach for designing and delivering my Agile and Lean courses to Product Owners, Scrum Masters, Teams and managers.

Last week I got interviewed by 4 students from a Human Resources Master (a psychologist, a sociologist and two economists) about my thoughts and experience on applying agility to training and education, which is actually a complex domain. The interviewers resulted to be very passionate about the subject and it was really an interesting 3 hours long discussion about many aspects.

I will try to summarize the outcomes here by using the same pattern we followed during the session: going through the values in the Agile Manifesto and try to understand how they can be concretely implemented in the domain of training development and delivery.

1. Individuals and interactions over processes and tools

We normally use a collaborative team approach (2-4 people) when designing a new course. We try to understand the learning needs of the client and ideate possible solutions that are pulled from the backlog and implemented incrementally by leveraging on pair working as much as possible. We use a task board to visualize the work and understand the progress.

We apply pair training for delivery and try to foster a collaborative approach in the class, where the trainers are mainly facilitators of people learning using different teaching techniques.

We use tools like working agreements to set a stage of ground rules for the class. Understanding is prioritized over delivery of a pre-determined content and physical tools and face-to-face conversation are preferred over other ways like web-based training.

2. Working software over comprehensive documentation

We try to get feedback as fast as possible as we proceed with the training design, by showing concrete examples of what we have in mind (slides, activities, other material) in order to validate our assumption and verify whether they match clients’ learning needs. That’s in contrast with detailing the training contents up front in a document and hoping to get feedback on that, where clients do not have necessarily the domain competence to understand and to map it with their needs.

We also think that learning is achieved by means of a complex recipe, where magic happens during live training delivery due to a combination of good material, inspiring activities, group collaboration and teachers’ skills. That’s why we do not aim at producing documentary or even self-explanatory material, which often gets the result of having neither good training material nor good documentation. Training should inspire, provide a vocabulary, create curiosity and new questions, which can best be satisfied on the web or by reading books.

3. Customer collaboration over contract negotiation

As I said, fast feedback is crucial. For that reason you need to get your client involved in designing the training with you. That’s why we engage an early collaboration which happens face-to-face when possible or remotely (via mail, chat or phone/video calls).

When our contact person is not the primary customer of the training, we try to get in touch as soon as possible with a number of training participants (when they are available) to interview and get a better understanding of their learning needs or even help to get themselves understand their needs.

4. Responding to change over following a plan

We try to keep our options open until the last responsible moment, both during course design and delivery.

We’re open to late requirement changes as much as possible, stated that they fit the allocated timing for the training and propose other items to down prioritize if we think it adds too much to allocate in the given time frame.

We divide the course in modules and monitor the progress of the delivery by means of tools like task board or burn-down chart, so that we’re ready to adapt. We follow a time-first planning approach: we always finish on time and if the timing doesn’t go as planned, we decide which modules to cut together with the class.

Looking forward to your comments, if you’re interested or have experiences in the field of agility applied to training.

P.S. Thanks Valentina, Lydia, Patrizia and Francesco for the awesome chat and all the best for your work.

Are you an Agile coach?

In the last 3 months, I met an incredibly high number of people, who call themselves Agile coaches: it looks like it is a fast growing family. For some reason when introducing each other, every time it is like a dejavu and it seems to me to hear the very same words: “My name is xxx, I am an Agile coach. And you?”

And this makes me smile every time, because it reminds me a tale from a friend of mine. 

When her sister was a child, they met a Great Dane: you know the huge dog, which size is more comparable to a horse than a dog?  

So her sister approached the dog and said: “My name is Carmen. I am a 6-years old girl. And you?

There’s a lot of misuderstanding about Agile coaching (as well as a lot of mystification around Agile, I hope I can write something about in the near future), but still in my view it is one of the most challenging and yet exciting jobs in the world, even if honestly or on purpose misled.

I will try to share what it is in my view.

Let’s start with the word “coaching”. It comes from the English word “coach” and gives the sense of taking a person from a point A to a point B. Myles Downey in Effective Coaching defines it as “The art of facilitating the performance, learning, and development of another”.

But an Agile coach (likewise as I said some weeks ago for an Agile manager) is not only a coach.

First of all in coaching it's the coachee to define the direction, like a “coach” doesn’t take the lead itself in defining where to go: it’s all about the coachee's agenda then.

On the other side, if you’re an Agile coach is not only about your coachee's agenda, it’s also about your agenda of teaching about Agile values, principles and practices, because you know by experience that they can improve their performances as individuals and teams by being and living Agile.

So an Agile coach is not just a coach (and even less just a facilitator), but he’s able to be a teacher and a mentor, when it is time help people who do not have enough tools to perform a certain task or solve a certain problem in the complex world of SW development or in the art of working as a performing team.

Then, while it is enough for a professional coach or a facilitator to master only coaching skills or facilitation tools, without necessarily knowing anything about their clients’ or team’s context, only first-hand experience and hands-on practice can give an Agile coach enough tools and credibility to give some direction when it is needed by the circumstances: you want your team to be off their comfort zone to be able to learn, but not too much to fall into chaos or panic.

And being a teacher is even a different job, where you need specific skills and practice different tools: that’s why you could have heard about “allied disciplines” as the tool set for an Agile coach.

But what should you exactly be able to teach, mentor and coach about? 

Let’s see what we can derive from the Agile manifesto.

1. Individuals and interactions over processes and tools

Encourage self-organization and collaboration: they are keys to success. Help them learn how to work effectively by means of experiment, fast feedback loops and safe failure. Help them see their conflicts and to choose what to do about them.

2. Working software over comprehensive documentation

Help people to get things done. Teach, mentor and coach on Agile technical practices, both individuals and teams. Stimulate a culture of SW craftsmanship in your company, based on mastery and apprenticeship, excellence and deliberate practice, ability to find solutions to always new problems.

3. Customer collaboration over contract negotiation

Teach and coach your company on Agile values and Lean principles, so that they can be more effective on the market. Have business and development like one team: teach them not to play the contract game inside the same company. Promote a culture of continuously creating learning, by means of close collaboration with the customer on the product.

4. Responding to change over following a plan

Train your team and organization to be able to keep as many options open as possible until the very last responsible moment and make informed decisions. Enable cross-functionality and e2e approaches to be more flexible to change. Coach your organization to always look at the big picture to focus on the most important stuff, validate hypoteses instead of blindly follow plans and change direction when needed.

And you should live yourself and role model the values and principles you would like your team or your coachee to learn: you cannot just be on stage.

For instance, challenge yourself the status quo and continuously improve: be soft with people and tough with processes, as Toyota teaches, starting with your own way of working.

So be the first to experiment, look for fast feedback loops on what you’re doing and reflect on the results. Continuously learn and practice new coaching and teaching techniques, be passionate and energize others. Be ready to share what you learned and contribute to local and global communities. 

Empower, be always there to protect your team and have the courage to stand for what you believe in.

You don’t work as an Agile coach: you ARE an Agile coach. Aren’t you?

A Lean manager is not a coach!

Or is not only a coach.

Or, even better, is not primarily a coach.

Many times I heard people saying that traditional management style do not apply in an Agile and Lean context and therefore it must be replaced by coaching as THE way to help people develop.

I think this is wrong or at least shows a narrow, easy and fluffy view of what a manager is supposed to do for an organization in the 21^st century who wants to run its operation inspired by Lean thinking.

But let’s have a look at the different Lean disciplines one by one and try to understand better what is the essential contribution needed from you as a manager.

1. Eliminate waste

First step to eliminate waste is to see the waste. So you should know (and know very well) the Value Stream of the product(s) you’re working with and continuously challenge the current practice to identify waste. 

But this is not enough: a Lean manager should help teams remove impediments they are not able to resolve by themselves and systemize solutions in the organizations to prevent the same impediment from coming back again (see more about this in my previous post 3 things we can learn from TPS)

2. Build quality in

This means for a manager working to build a culture of discipline and excellence, that is guide on principles and values instead of giving complex rules, teach people not to cut corners, challenge people to high performance and lead by example. And yes, that implies true leadership.

3. Amplify learning

Most managers face competition with other managers trying to meet locally optimized goals and maybe look good to the next level up. But this wastes a lot of organizational learning, which can be effectively used by pairing up with peers. So building and maintaining a network of peers is essential as well as continuously challenge own management style in the light of Agile and Lean principles (see also Cultural transformation through deliberate practice of behaviors). But amplifying learning also means:

·         concretely encouraging experiments, fast feedback loops and safe/fast failure

·         providing and being open to feedback

·         striving for a radical transparency (as Steve Denning calls it) as the unique way to control the complex system your organization represents

4. Defer commitment

Keep your options open up to the last responsible moment and be capable to live with uncertainty: there’s no other way around (have a look here). Furthermore early commitment could mean discard too early real options which might have provided more value, just not to afford the cost of deferring a decision.

5. Deliver as fast as possible

The fastest way of achieving a goal is to let a diverse team of skilled people self-organize to better judge how to solve the problem. And the best way to have them self-organize is to define what the goal is, make it compelling and clarify what constraint the environment around puts to the direction. Then if you want to help your team or organization to deliver as fast as possible, set a clear vision, explain clearly where to go and why, align all stakeholders around that vision and get fast feedback. Then set specific goals derived from the vision: in that sense you’re the PO of your organization, so write a backlog of stories aligned with what you think is the ultimate goal to reach. And finally give space to your teams to reflect on what they are doing to find ways how to go even faster.

If you're not a front line engineer, there's only one reason for you to exist: help your team move faster - Jan Bosch

6. Respect people

Who dare disagree with this? Actually this apparently generic statement hides a deeper meaning. It stands for: give people the environment and support they need to do a great job and trust they will do their best to accomplish their goal. So it’s not simply saying to a team: Now you’re empowered to do what you want, but putting them into the conditions to succeed. So it’s about staying close to the teams, Managing By Walking Around and Listening (MBWAL instead of MBSR – Managing By Status Report), energizing people around you, assisting on personal development. And yes: that might be teaching, mentoring and coaching as well.

7. Optimize the whole

Optimizing the whole means having an e2e view of your system, product or organization and consequently as a manager selecting the right metrics which can help you improve, measures only what adds value (less is more) and whatever you want to measure, measure it one level up.

Of course, being a Lean manager does not mean taking decisions your team would be able to take themselves, asking for reviews and reports or pushing activities on your people.

On the other hand coaching is all about the coachee agenda, but improving theValue Stream, build the organizational culture, set the direction or define proper metrics cannot be other than about your agenda as a manager.

So were you one of those who thought that managing an Agile and Lean organization meant just coaching?   

What’s your thinking now?

12 secrets of a successful Agile transformation – Part3

As promised here I am to complete the list of 12 tips for a successful transformation towards enterprise agility. In the previous posts (from last week and two weeks ago) we talked about the first 8:

1. Why?
2. The approach
3. Training managers
4. The pilot project
5. Scaling up
6. The Transition Team
7. Create the new roles
8. Cross-functional teams 

Let’s complete the list with the last 4 then:

9. Technical Excellence

Scrum is not enough! Scrum is a very powerful way of organizing work, but doesn’t say anything about how to practically do the work. Instead the biggest challenge for a waterfall organization is delivering a potentially shippable product increment in a short iteration. This implies finding new ways of doing things, applying state-of-the-art technical practices and build teams of professional developers, who are able to find the right solutions to always new problems.

Continuous attention to technical excellence and good design enhances agility. – 9^th Agile principle

10. Cultural change

It’s not about doing Agile: it’s about being Agile, by embracing Agile values and principles. This means primarily focusing on value, on what really makes your customer happy and not your boss or the boss of your boss. Prioritize your work based on the contribution it gives to the people actually paying for the product and not because “we have always done like that” or in order to make people busy: busyness is not a good business.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. – 1^st Agile principle

Then let self-organizing teams to pull the work they are able to do. This is very much connected to why Agile. We’re in an industry with such high levels of complexity and uncertainty that we can no longer assume we can know or control everything goes on. So there’s no other way than building empowered individuals and teams who are able to take decisions autonomously using their best capabilities and judgments in the moment, respond to changes fast and reach a defined goal in the most efficient way.

The best architectures, requirements, and designs emerge from self-organizing teams. – 11^th Agile principle

11. Make your transformation self-sustainable

·         Build internal coaches who can teach and coach the new roles, support people to work as performing teams and be permanent change agents: if you’re really Agile, you’re never Agile enough.

·         Nurture Communities of Practice to give people a place where to meet colleagues who share the same passion or interest and learn from each other.

·         Adjust your HR processes (Performance management, career models, recruitment, reward and compensation) to support your transformation, instead of giving contradictory messages, and enable a collaborative environment of high level professionals.

12. Use an empirical approach

An Agile transformation is not a Change Program, you can plan upfront, set goals and KPIs, deploy it to the organization and track the progress. It simply doesn’t work like this. As you might have understood introducing Agile is complex: you’ve never done it before and you do not know exactly where you’re going, how can you define the steps to get there?

The answer is then to use Agile instead: yes, use Agile to introduce Agile.

So have a transition strategy and a transition backlog, but use an empirical, iterative and incremental approach.

Prototype and refine, make assumptions and validate them through baby steps, use fast feedback loops: it’s all about Continuous Improvement.

Of course using an empirical process control implies that you can observe your system to be able to inspect and adapt. Therefore enabling full transparency is a key success factor: make relevant information visible as much as possible from everybody to everybody to be able to really understand what’s going on and act accordingly.

Otherwise your transformation will degenerate into chaos.

So here are my summary on what it takes to have a successful Agile transformation.

Happy enough, my dear cheeky brother?

BTW, Happy Easter to everybody!

12 secrets of a successful Agile transformation – Part2

Following the blog post from last week, here is the continuation of the list of 12 tips for a successful transformation towards enterprise agility. We mentioned already the first 3:

1. Why?
2. The approach
3. Training managers 

Let’s move on with 5 more:

4. The pilot project

Since we’re talking about applying an empirical process, the starting point is to setup an experiment in terms of a pilot project. Scrum can help out with its framework to give some guidance and some practices which help understand the agile principles behind. A pilot project can provide objective information on the feasibility of rolling out Agile to all the organization. Craig Larman says that if an organization is not able to implement real Scrum with only one team, how can they succeed in scaling it in the whole enterprise? But be aware of choosing a proper pilot project. It needs to be important and critical enough so that people will consider it a serious try and a valuable success (it should be used to gain even more management support for the change), but not too critical to create a safe environment for possible failure. It should be end-to-end and therefore include all the stages that are needed to bring an idea into a product and it needs to be closely monitored and supported by senior management, ready to fix possible impediments.

5. Scaling up

Leveraging on the feedback from your pilot project and acting on the findings, you can start scaling up incrementally. This will allow better control and will enable the organization to build internal capabilities to help the teams that start later.

If you don’t know what you’re doing, don’t do it on a large scale – Tom Gilb

However beware not to be too slow, to avoid the organization finding them in the ford for too long and losing momentum, sense of urgency and a clear direction about the change to make.

6. The Transition Team

Creating a successful Agile organization does not simply mean make a number of Scrum teams work: it means creating all the conditions around to enable those teams to succeed and get astonishing results. The Transition Team is an operative team, with the goal of helping and supporting the organization in implementing the Agile Transformation, by supporting teams, removing organizational impediments, training and coaching people, spreading the Agile values and Lean thinking. The team works as an agile team, driven by the so-called Transition Backlog populated top-down by the organizational transformation strategy and bottom-up by impediments from the team.

7. Create the new roles

In order to scale up you need to build new skills and behaviors for people to fill the new roles of Scrum Master, Product Owner and Scrum Developer. This is best done by means of a mix of training, mentoring and coaching and is a typical item in the Transition backlog. Understanding that we’re talking about new roles, you cannot find in the existing organization, is a critical success factor. One of the worst (and yet easy and most common mistakes) is to create a mapping between existing and new roles, like System ArchitectàProduct Owner or Project ManageràScrum Master. They are totally different jobs and you need to realize this and prepare to help individuals who are willing to learn and challenge themselves to fill the gaps needed to move to the new roles.

8. Cross-functional teams

Cross-functional teams who can deliver potentially shippable product increments at each iteration are a key element in a successful Agile enterprise. So one needed step is to change your organization, remove functional silos and have self-organized teams of 5-9 people with all needed competences working together permanently. And this might imply changes in the office logistics as well, to create the right environment to enable team collaboration.

The most efficient and effective method of conveying information to and within a development  team is face-to-face conversation – 6^th Agile principle

It’s probably enough for today: any comment?

Let’s have a date for the next blog post to talk about the remaining secrets for a successful Agile transformation. 

12 secrets of a successful Agile transformation – Part1

Last week I was discussing with my brother, who works as chemical engineer and is now preparing to pass his exam for a Lean Six Sigma Green Belt Certification.

He’s studying mainly about Lean production and I was explaining him how Agile has its roots in the Lean principles and disciplines and how essential is Lean thinking and Lean management approach to support an Agile SW development.

My brother is a clever guy: so he understood very well that embracing Lean means much more than the mere application of a number of practices. So is for Agile SW development.

He’s maybe a little too clever to ask me something like: “You say that you’re an experienced Agile and Lean coach: so what do you think it is needed for an organization to really leverage on Agile and Lean to deliver quality products in an effective way? What do you think are the key ingredients to have a successful enterprise transformation?”

Cheeky enough, isn’t it?

But somehow he forced me to step back, reflect, gather my thoughts and summarize my experience and learning from the last 3 years.

Here comes then a list of 12 tips as outcome of that exercise, which I intend to share with you in a series of posts. I will start with the first three today:

1. Why?

Before exploring how to implement an enterprise transformation to an Agile organization, the first step is about asking yourself “Why?” What is the need behind? What is the goal you intend to achieve? There must be a clear need for any improvement change: imagine how crucial it is to start off such a dramatic change. The “Why?” must be clearly understood and the vision for the change communicated and shared to align the whole organization. Otherwise you’re doomed to fail even before starting (more about Why Agile? here)

2. The approach

Due to what we said above, it is easy to understand that any successful Agile transformation implies a top-down approach, in terms of Company values, Management culture, Vision, Business goals and above all senior management support: you cannot do anything otherwise. However, changing an organization (irrespective whether big or small) into being Agile is not like the nth Change Program to be deployed with targets to comply with and a well-defined plan to stick to. There are aspects that need to emerge bottom-up, like practices to be selected by empowered and self-organized teams. So an Agile transformation is a sandwich transformation: you need 2 equally big slices of bread and both are essential.

3. Training managers

Given the importance of the top-down part in the enterprise change, the very first step is training managers, for them to understand the why, be able to share and communicate the Vision, embrace Agile values and be ready to support people with a new leadership style. Many times this critical step is down prioritize, if not even neglected. It is too easy to fall into temptation that becoming an Agile organization means making Scrum teams work and that managers, well, they are clever enough that can handle themselves or can get it with a short summary from a developer attending a Scrum course: being a manager in an Agile organization is a totally different job and requires new tools which must be learnt and cannot be improvised.

How do you see yourself and your story compared to these three items?