Luis Gonçalves's Blog, page 7

What is Lean Change Management Model?

Resisting the change is a natural reaction, when you don´t involve people affected by the change. Jason Little wrote a book called Lean Change Management, this book shows how to implement successful change through examples of innovative practices that can dramatically improve the success of change programs.

About Lean Change Management Model

“All models are wrong, but some are useful” is a phrase acknowledged to a Professor of Statistics at the University of Wisconsin, George Box. He probably means that simple models can be useful for making sense of complex situations, even if they´re not 100% correct.

Below you can see the picture of the Lean Change Management Model by Jason Little. It consists of 3 main parts: Insights, Options, Experiments and 3 parts of Experiments – Prepare, Introduce, Review.

Source: leanchange.org

Here´s a brief explanation of the Lean Change Management Cycle:

Insights: It´s very important to understand the current state of the organization, before you can plan any change. In order to do that, there are several tools, assessments, and models you can apply to understand the current position. The Lean Change Management book describes many practices to collect Insights.

Options: When you gain enough Insights to start with the planning, you will need Options. Options have a cost, value and impact. Options usually include one or more hypotheses as well as expected benefits. These hypotheses are then turned into Experiments.

Experiments: Now it’s time to introduce a change and see if it works out. At this point you should learn enough about your current position and consider multiple Options.

Experiments also have a sub-cycle:

Prepare: This is the planning stage of your Experiment. At this point, all you have are your assumptions about the change. In this step you validate your approach with people affected by the change.

Introduce: In this step you start working with people affected by the change. Once a change will reach this step, it is part of the process.

Review: Here you review the outcomes of the Experiment. Normally you do this after the amount of time you thought you would need for the change to stick.

How to run a Lean Change Cycle

Lean Change Model is a nonlinear and feedback-driven model for managing change.

As described above, in this model, Insights is when you observe the situation as it currently is. Then you move to Options, where you evaluate cost, value, and impact of each possibility. From this you create a hypothesis to test the expected benefits of that test. Using that hypothesis, you form an Experiment.

Insights – listening the right way

When looking for Insights, the most important thing to do is listen but we must listen in the right way.

In order to actively listen, we need to use facial expressions and body language to show full attention. We should also ask clarifying questions that are neutral in language and without judgement.

We develop Insights by being curious, asking questions, and helping the people who want the change. By asking questions we can discover what the real problem is and discover new Insights.

Options – getting the root cause of a problem

Now, help people generate some Options by asking: What is the root cause of the problem they´re dealing with? Dig deeper and find out what is going on and what might be some possible solutions.

There are several exercises and practices that you can perform to get the root cause problem – for example Lean Coffee Session, Five Whys, Retrospectives, etc.

Experiments – building on curiosity

Now that you have some possible solutions, work together to create some Experiments to test them. Simply run one Experiment, and see what happens. The idea is to learn from that and determine your next steps.

Each experiment includes three parts: Prepare, Introduce, and Review.

What you need to do is to prepare for the experiment, introduce the experiment to those who are involved and then review the results together. Invite the team members to participate, get their feedback, and have empathy for their problems.

By using the Lean Change Model and conducting small Experiments, you can cause transformations in your company or on your team.


Creating hypothesis for experiments

All experiments start with hypothesis. Below you find a hypothesis structure:

We hypothesise by

We will 


Which will have


As measured by

You can follow the following thought process:

think about what the experiment would be
think about who would be affected
think about what would be the benefit
think about how to validate the Experiment as successful


By using the Lean Change Model and conducting small Experiments, you can cause transformations in your company or on your team.



It´s important that there is a strong alignment between you – executive, management, and staff using this approach and making it successful.

Developing your own change management process

It´s crucial to select and develop your own change process that best suits to your organization. There are 4 main components to developing your own change management process:

Developing your Strategic Change Canvas
Aligning your organization
Developing your Change Agent Network
Executing the Lean Change Management Cycle


Developing your Strategic Change Canvas
The best way to create a change strategy is through a facilitated session using big, visible canvases, and sticky notes on a wall. It´s recommended to have your change agent or anyone responsible for change implementation do that.

Facilitating a Strategic Change Canvas session

There are several different approaches for group facilitation. The most important thing is to visualize the canvas on a wall using sticky notes.

First create a canvas on a wall and use the following questions to guide you to complete the canvas:

What points haven´t we considered yet?
What are our assumptions about this strategy?
What is our riskiest assumption?
How often should we review this strategy?
How will we collect feedback from staff
What other important information should we put on this canvas?

There are several key persons that should be involved in this session: the Change Sponsor, the Change team and optionally executive team (depending on the size of the organization).

Aligning your organization

Once the Strategic Change Canvas has been created, it´s time to start aligning stakeholders in your organization with your change strategy.

If your organization is small, you can facilitate a session with everyone, including management and employees.

Here are couple of tips that might help you facilitating the “Change Alignment” session:

In bigger companies, re-purpose an existing department meeting and ask the manager and one member of the change team present the Strategic Change Canvas
In smaller organizations, do a full-day company session using any type of facilitation approaches for the large group.
Tip: facilitate this sessions starting with stakeholders that are affected by the change
Do an ADKAR Assessment survey

It´s important that you, as an executive, and change sponsors leave details to the team when aligning with change. That includes measurements too; Avoid telling teams how you´ll measure them, let them figure out their own progress measurements.

Creating organizational alignment around change is difficult and time consuming, especially in bigger organizations.

Developing your Change Agent Network

It´s important you have internal change management team or anyone that is responsible for implementing change. Executives and managers need to act as change agents. The reason is because people are more likely to work with their peers rather than external consultants (which is recommended to have too).

People might feel threatened or feel that change is being forced on them if they don´t see their peers being involved first.

Here are some tips for expanding your change team:

Get one person from each department that is affected by the change
Let early adopters that are being part of the change know that the change team involves extra work
“Promote” becoming member of a change team as something exclusive to attract the right people
Rotate the change team members periodically, depending on the type of change you´re implementing

Executing the Lean Change Management Cycle

Implementing a successful change program requires these basic building blocks. Change only fails when the people managing it blindly follow a structured process that isn´t compatible with the organization.

Therefore, it is important to build your own change management process using the Lean Change Management cycle.

Here´re some ideas:

Create a change program room: make your plan visible (using Strategic Change Canvas and Experiments)
Decide how often to have these meetings

Change Team Daily Standups
Change Team Retrospectives
Strategic Change Canvas Refresh – revising the Strategic Change Canvas
Lean Coffee
Retrospectives


Do not use status reporting – ask your change team to go to your big visible room. It´ll be hard but you need to stick to open and honest dialogue

These 3 pieces are the key points you need to build your own change process. Avoid creating too much process at the beginning.  The interactions among your change teams will be better equipped to deal with complexity. Therefore, create enough process to trigger these interactions.

If you´re interested in attending one of our Lean Change Agent workshops, please visit the training calendar page.

____________________________________________________________________________________

Sources and references: 

Lean Change Management book by Jason Little
Leanchange.org
How to run a Lean Change Cycle, Happy Melly

 

The post What is Lean Change Management Model? appeared first on Luís Gonçalves.

Why OKRs Are Not Delivering The Result Executive Managers Expect

I believe that many organizations implementing OKRs are making a big mistake. At the very least, OKRs will not solve the problems companies are expecting them to resolve.

OKR (Objectives and Key Results) is a simple way to align the organization’s goals with its strategy. Companies define their strategic themes, then create Objectives and respective Key Results to align everyone with the most important strategic goals.

The concept is like Management by Objectives; senior managers place their vision on the top, then cascade down to the bottom of the organization as they define their strategic goals, but let’s take a better look at the differences.

OKR and MBO – What is the difference?

OKR is evolved from MBO (Management by Objectives), taking the best practices out of and adding a few on its own. MBO was introduced by Peter Drucker in 1954. Both MBO and OKR are goal-setting frameworks. Their principle is to evaluate and enhance the performance of employees over a period of time. They are however few differences, like the way in which they measure performance, frequency or their end purpose.

Important differences between OKR and MBO

Frequency of review

Companies that use MBO normally perform yearly performance reviews. They set the objectives for employees for the entire year, so the performance is analyzed and the end of each year. The goals are broad.

OKRs have a higher frequency of reviews. Companies set goals monthly or quarterly and are then evaluated accordingly. This allows people make corrections earlier when there is still a chance.

Mode of measurement

MBO scoring models are flexible, they´re open-ended and use both qualitative and quantitative measures.

OKR measurement is quantitative and is precise. OKR rely on SMART goal setting technique.

Confidentiality

MBO is strictly confidential as it is done between a manager and his employee. Objectives are set individually for each employee. The performance directly influences compensation.

In OKR, the key results of individual employees are aligned with team and company objectives. There is no confidentiality. The objectives need to be linked together to achieve company goals.

Purpose of review

The main purpose of MBOs is to resolve the compensation of employees based on their annual performance. The focus is always on the individual performance.

Compensation is not affected by the achievement of OKRs. The main focus is to push to achieve excellence.

Expected performance

With MBO, you are expected to achieve 100% or more. If you achieve less, your compensation is affected.

Normally, 60-70% achievement is expected with OKRs. The goal setting should be ambitious, but also realistic.

Everything looks good but…

The OKR method allows every staff member to have a very clear understanding of the company’s vision and mission. Everyone in the organization can create their own objectives to fulfill the company’s strategic goals. Managers can then create their objectives to support the staff goals.

In theory, this is a fantastic approach because society is moving so fast, and we live in a very complex world. Frontline workers are the best people to understand the customer’s needs and fulfill their requirements. Therefore, they should be the ones who create the products that delight customers.

Because they understand the customer’s pains, the team defines their objectives to create great products. Managers can then create their goals to support the line below and so on.

In truth, this practice does not work. In the following section, I will show several reasons why OKRs will not solve the big problems in your organization.

It is very difficult for Executives to give up their power

OKRs require a completely different mindset from management. If OKRs are applied properly, executives must delegate their responsibility to the whole team. Many executives feel like they have lost their power, which is very difficult for most leaders to do.

In many cases, when organizations apply OKRs, they apply the process the in the same format as Management by Objectives: using a Top-Down Approach. But this format does not create value for the organization because the top managers do not understand what the customer’s real problems are. When defining the objectives, they are usually not in alignment with the company’s current reality.

How consultants are selling OKRs to organizations

Another issue I see with implementing OKRs is that many consultants are selling OKRs as the new way for the organization to become Agile. Let´s be very careful with this thinking. Implementing a tool will never make your organization Agile if the culture and management style does not change first.

OKRs often create very challenging objectives that cannot be achieved. Consultants defend this by maintaining that reaching 70% of the OKR is a great work. However, optimally, you want to create an environment that encourages employees to achieve 100% of their goals, not 70%. In our opinion, by telling your employees it is OK to achieve only 70% is fostering a culture of underachievement.

In most of the companies where OKRs were implemented, I noticed that people do not reflect on how the OKRs impacted the business. At the end, OKRs just become a checklist for the managers to check if people fulfilled their OKRs.

In summary, I believe that in theory, OKRs could be a great tool. However, in practice, OKRs do not deliver the results they promise. Now you might say “How come when Google uses OKRs?”

That may be true, but let’s face it, your company is not Google! You do not have the same culture or the same developers that Google has. In my opinion, Google can try whatever they want; the result will always be good. Just think about a great football team, the coach can change a couple of players, but the team will still be great.

Most of us believe that copying another company’s best practices is the solution for our problems, but most of the time, this does not work.

So, if OKRs are not the best option; if they do not bring extra value to the organization, what is the alternative? What is the solution?

What should we do instead?

I coach, train, and consult organizations to implement an Agile Portfolio Management. In my opinion, this is a more interesting approach because the leaders in an organization can define their own budgets for strategic projects. Executives can define what projects or products the organization should work on in the next six to twelve months. They can also allow the people working on those projects to create their own “product backlog”.

As part of this process, the organization must list all the ongoing projects and map all the people who will be involved in each project.

This is a huge step that 90% of the organizations do not take. It creates complete transparency in the amount of work that is ongoing in the organization. The process proves that it is not possible to deliver the products as they should be delivered because there are too many parallel things happening simultaneously, and no real focus by the company.

After you identify your revenue streams – the products that are bringing the revenue to your company – it is time to start terminating or stopping the projects that are not directly connected to the strategy of the organization.

You can work on the strategic projects that you believe will add revenue to your company. In most cases, you will quickly learn that you do not have enough people to do everything. You will have to prioritize projects based on their business impact and not some gut feeling.

I usually work in three-month cycles to help organizations define the most important goals they want to achieve within the next three months of their Revenue Streams.

The teams provide product backlogs based on the customer’s needs. These goals are structured to define expected revenue, expected cost savings, improvements, and other measures that make sense for the organization.

If you start connecting your vision to your strategy, your strategy to your portfolio, and your portfolio to your products using clear goals for three months, you can create a highly focused organization that delivers its best work to their global market.

At the end of the three months, you can reflect on the business impact your product delivery has made. This is the point where I see most of the companies failing.

Many people talk about Agile Retrospectives, but no one does a “Business Retrospective”. I find this piece is missing in most of the companies. Of course, the scope of this activity differs significantly from a regular Agile Retrospective.

Often, companies produce “stuff”, hoping to get some business benefit out of it. Very seldom I encounter companies that reflect on the impact that their development has caused the company.

When you apply Agile Portfolio Management, you can perform a business retrospective to find out what you have delivered in the last three months.

When I say three-month intervals, it does not mean that you deliver your product after the three months. It means, you should be delivering every day, every minute, and every second, whenever your organization can deliver. Three months is an interval timeline for when your company makes its public release and analyses the business delivery to the market.

When you implement this process into your organization, you can start analyzing every task your teams perform. By doing this, you will have a better understanding of the impact that your actions and your development have on your business. Then, if you inject the learning and experiments into the next three months, you will start to see spectacular results. Your company will become Agile, Innovative and a Learning Organization.

Did you like this approach? Would you be interested in trying this out in your organization? Well, I´ve got a perfect training tackling this path. Why don´t you look at my company´s website at the Agile Portfolio Training for Leaders? Check for more information here.

References:

http://upraise.io/blog/difference-mbo-okr/

 

The post Why OKRs Are Not Delivering The Result Executive Managers Expect appeared first on Luís Gonçalves.

Lean Change Management – A New Approach To Introduce Changes

This is a guest post written by Jason Little. The original version of this guest post was published on my company´s blog Evolution4all.

Why Lean Change Management is different

In the autumn of 2014, I led a pitch to implement a large change programme for a major broadcaster. On the Request for Proposal they had asked that we take an agile approach.

I have an Agile software development background, but my experience of using Lean or Agile techniques for managing change? Zero.

After reading Jason’s book “Lean Change Management”, I transformed my approach to leading that change programme. I experienced plenty of bumps along the road. However, implementing theses ideas helped me to lead one of the most successful change initiatives I’ve ever been involved with.

So, why Lean Change? Because it works better. We know that taking Lean and Agile approaches have proved to be significantly more effective in developing software. However, as change leaders and managers, we work at a level of complexity equalling if not exceeding that of software challenges. When we take a Lean/Agile approach, we markedly improve our effectiveness.

Writer Beatrice Kaufman once said:

“I’ve been poor and I’ve been rich. Rich is better!”

When it comes to change approaches, I can say:

“I’ve used traditional and I’ve used Lean/Agile. Lean/Agile is better!”

So how is it different?

Lean Change differs from traditional approaches in 5 major ways.

1. People-first, not process-first

In many of the traditional change methods, we place a major emphasis on process. Let’s take  an example of Kotter’s 8 Steps. His approach is characterised as a set of steps to follow, from Establishing a Sense of Urgency through to Anchoring New Approaches in the Culture. Now of course Kotter’s work provides great wisdom. But, the issue with this and other approaches is the emphasis on the sequence of ‘best practice’ activities.

With Lean Change Management, we do have a loosely defined framework to design experiments. However, there is no overarching methodology for executing change. The key principle is to co-create change with the people affected, in whichever manner and sequence makes sense in context.

2. Co-creation not consultation

In traditional change programmes, the central key is a change team. They interview those affected, create change readiness assessments, design new processes, construct communication plans and so on. When they take your views, they analyse, synthesise and consolidate these inputs into ‘programme documentation’. When the change managers present this to people, it can seem like a confusion of corporate platitudes, or worse, something totally unrecognisable.

In the Lean Change paradigm, we see the central engine as an act of co-creation. Change agents and those affected design all aspects of the change initiative together.

3. Experiments not change activities

In traditional change programmes, the main currency is change activities. Activities broken down into tasks on a plan. The team must do interviews, workshops, presentation, and skills assessment.

In Lean Change Management, the main currency is experiments. From a design perspective:

Which type of experiment?
Who with?
How to prepare?

From a management perspective:

What’s the maximum number of experiments we can execute at once?
Which ones failed?
Which succeeded?
What did we learn?

We also acknowledge that any experiment successfully adopted will itself change the System. This new landscape provides us with the canvas to further experiment.

4. Feedback-driven not plan-driven

In traditional change, the change team carefully craft a set of dependent change activities; all laid out on a plan, with a defined start and end point. A lot of effort is spent maintaining that plan and tracking variance. There are three major risks in this approach.

Risk 1: Responsiveness

When being driven by a plan, the change initiative itself is much less responsive. Changing the direction of the change effort itself becomes much more expensive in traditional approaches. As the effort continues, it becomes increasingly hard to course-correct as the environment changes or underlying assumptions prove to be invalid.

By contrast, feedback from experiments drives Lean Change initiatives, with a strong focus on giving those affected a strong voice. Lean change agents create fora with a high degree of psychological safety. This means people at any level of the hierarchy can feedback and directly influence the next experiments for the team to conduct.

Crucially, lean change agents design the initiative such that it can be highly responsive to this feedback. Using kanban-style flow-based management of the change effort, the team can course-correct easily in response to feedback.

Risk 2: Horse before cart

The second risk of a plan-driven approach relates to Pournelle’s Iron Law of Bureaucracy. The law states the following:

“In any bureaucracy, the people devoted to [] the bureaucracy itself always get in control and those dedicated to the [authentic] goals [] have less and less influence…”

As the English might say it, “putting the cart before the horse”. When we orchestrate change using traditional methods, we typically create a central function to plan and coordinate. By doing so, we create a greater risk of the Iron Law asserting itself. Namely, the risk that the planning functionaries become more powerful that those authentically committed to achieving change.

Risk 3: Self-fulfilling illusions

The final risk is that when we create large, centrally-managed programmes of change, we put many professional reputations at stake. In such a situation, the people around the change team adapt to provide the illusion that change is happening. Those in charge of the programme see want they want to see and those affected tell them want they want to hear.

As Lean Change Agents, we accept that some level of high-level planning and bureaucracy is valuable. However, we approach management differently. We use a lightweight approach to planning and commit ourselves to rapid ‘feedback-and-respond’ cycles.

5. “Catch the wave” don’t “initiate and drive”

The fifth and final differentiator of Lean Change lies in the fundamental premise of how change happens. In traditional approaches, people believe that change happens when senior authority figures lead people to a new way of operating. The Lean Change approach sees change as a social movement; a viral effect ignited by leaders potentially anywhere in the organisation.

The basic paradigm for traditional change programmes goes something like:

Senior executive identifies an issue or set of issues.
Senior executive secures budget and resources to ‘implement change’.
Change team create vision, scope and plan to drive through the changes.

Change as a social movement

Lean Change turns this on its head. In Lean Change, the approach looks more like:

Senior executive or manager identifies an issue or issues.
Change agents scan the landscape for emergent responses to this issue; the ‘loan nuts’ and their ‘first followers’ trying something new.
Change agents work with these activists, or provide spaces for theses activist to emerge. They seek to amplify their impact and accelerate the change through further experimentation.

Here we see the role of the change agent not principally as a designer and a planner, although this might be part of their job. Rather, we see the change agent as a scanner, an enabler and a protector of disruptors. Their second, equally important role, is to work with those being disrupted. As George Koenigsaecker puts it in his book ‘Leading the Lean Enterprise Transformation’:

“If you only support [the activists], the antibodies will get more active and will multiply, offsetting the impact of your [activists]”

So, the change agent must, on the one hand support the disruptors. On the other, they must work attentively and assiduously with those being disrupted. The more these groups see a change as a threat, the more powerful their response to neutralise that threat. This is where the change agent must work hard to constantly maintain an open dialogue. They must listen, empathise, be straight and engage in ongoing co-creation with those affected.

Conclusion

In conclusion, Lean Change is a co-creation-led, responsive and experimental approach to change. It sees change as a social movement.

The post Lean Change Management – A New Approach To Introduce Changes appeared first on Luís Gonçalves.

The World Cafe – Agile Retrospective technique

The World Cafe format is well known in the moderation space, but I have rarely seen this setup used as an Agile Retrospective.

The World Cafe normally requires larger groups than a typical Scrum team.  For that reason, the World Cafe is recommended to us if you work on a multi Scrum-team project, or if you hold larger retrospectives with all team members on a regular basis.

What to expect

The World Cafe is useful to spread Scrum patterns, practices, tips and tricks across the teams. If done well, you can expect to gain benefits by using Scrum processes and experiments done by your teams.  On top of that, you as a Scrum Master, will get a good picture of where your team currently is in Scrum adoption.

What is needed for the World Cafe exercise

I recommend performing this exercise using round tables. Count with six to ten people per table. Place a big sheet of paper, pens or markers with various colours at each table. I´d suggest trying the paper napkins instead of flipchart sheets. In my experience, writing directly on the table triggers some kind of psychologic effect that increases creativity and removes the typical “post-it-format” boundaries set by countless “mad/glad/sad” retrospectives.

In addition, you´ll need to write three questions. I´ll describe more about that in a bit.

Source: Timothée Bourguignon
The Flow

First, divide the group evenly at the tables and let them elect a moderator for each table. The moderators will stay at their tables during the whole retrospective.

Groups start discussing the first question and write down all the ideas they have. They are allowed to do anything – brainstorming, sketchnoting, mindmapping, etc. Set the timer for each discussion, when done, ask participants to go away.

The participants should now form into new groups, if possible, grouping with people they haven´t yet talked to. The moderators present a brief summary of what has been discussed at their table and introduce the second questions to the new group. They moderate the discussion further using the same or another technique, as they wish to.

Repeat the same format for the last question.

The Questions

The questions or statements to be discussed in this technique are key elements of a retrospective. Tip: choose the questions wisely, because choosing wrong ones you could threaten the whole discussion.

Some examples of statements:

„Our team has been dealing with following difficulties in the past sprint(s) “
„Our team has been successful running the following experiments in the past “
„X weeks/months from now, the project is a complete success, thanks to “

Discussing the first question, you will experience current problems being verbalized and developed as people tell what has been painful in the past. Through the second question, different people will be laid onto the problems that are still visible on the table. Doing that, we want to have people think about the solution they implemented while being influenced by problems faced by others. The intention of the third question is to get new ideas out, ideas that often came out from the discussion but could not be expressed in the second round.

Conclusion

This technique is simple, but efficient in helping teams influence each other and come up with ideas on their own. Do not expect any radical ideas to emerge, but you should be able to see great ideas and experiments to run immediately.

To close this retrospective, gather the whole team and ask the moderators to present the outcome of their discussions. If you want, collect action items using silent voting (raising your hand) to prioritize the items in order of their importance.

Pictures credit: Tim Bourqguignon (Pictures are licensed under “Creative Commons Attribution-ShareAlike 4.0 International License”)

 

The post The World Cafe – Agile Retrospective technique appeared first on Luís Gonçalves.

How To Build Ownership In Your Team – Case Study

How to build ownership in your team – it’s not something that is synonymous with Agile Development but it should be. Having software teams work from a backlog without questioning the rhyme or reason is how teams traditionally worked, however I believe this age is coming to a swift end.

As I will explain through this post, having a team that takes ownership of their project are more dynamic, energetic and consistently making better decisions for the product, feature and the entire business.

Case Study: The Notification Project

In my last role as Technical Lead for a Scotland based Technology Company, I saw first hand how involving them throughout paid dividends. The team just had finished a 9 month waterfall re-architecture project — they were keen to start building user facing features. The project itself was around increasing conversion of the home page. The Scrum Master and I convinced the product team to let the entire team to be involved in the very inception of the project.

After two days full of meetings the development team had gained a full background into the project, spent hours trying to find low-hanging fruit with the highest impact, they had been involved in high level backlog planning and prioritisation. By this point every member of the team, even the newest engineers, were given opportunities to contribute to the project. Already the team were more emotionally invested.The team quickly begun work trying to solve the problem, but rather than building feature after feature they opted for a more Lean approach. You see, one of the features from the inception that was mentioned was a Facebook-eque notification system, and rather than build the full feature I had managed to convince them to simply fake it:

Put a notification on the home page
Tell the customer we have really great content when they click
Measure if the conversion increases

Simple. The team dived right in. With an A/B test, the team had proven that customers who had seen the notifications were 25% more likely to convert to a paying customer. This was figured out within days of the inception meeting.

The ownership part now kicked in, this was the only piece of work that had been planned in detail. It was now up to the team where to take this. Fast-Forward 2 months and they have an entire Notification Microservice delivered and, more importantly, increase the bottom line for the business. The team are ones pushing the business to look at data during every catch up — they are effectively driving the project. A true sign of a mature, high performing software team.

Start Building Ownership in your Team

That’s obviously a tale of a single software team where ownership made a difference, yet I have seen it time and time again, when teams are owning their projects and their delivery is exceptional. When teams are delivering well, the key business metrics will change faster.

Here are a few steps how to build ownership in teams;

Cross Functional Team

The advantages of Cross Functional teams have been written about for years; Speed, Innovation, and Accountability all increase. (See here). Having a UX Designer work closely with Software Engineers allows them to create dynamic relationships. Ensure there is a platform within the Cross Functional Team for everyone to contribute their ideas.

The role of the leaders

The leaders in the group i.e. Technical Lead, Product Owner and Scrum Master should all facilitate giving the team a larger say into product and feature direction. By having the development team working closely with the PO, the team feel connected and involved in the direction.

Involve the team from the start of a project

Allowing the team an input is the easiest way to build ownership. Most software developers don’t want to simply be “code-monkeys”. Software developers love problem solving. When starting the project, push for the business to allow the team to get involved early. This will have an upfront cost, however, having a team take ownership is worth it. This leads on to…

Problem statements over feature requests

Be Lean. Try and solve a problem with data. Problem statements should be “How do we increase our revenue through our search results?” or “How do we increase the number of sign ups for our beta?”. Build a backlog when you have the data that you have solved the problem. Allow the team an opportunity to contribute and solve the problem. How do developers know that they have solved the problem?

Analytics, Metrics and Data

Yup. In order to understand the problem the team need data. Before the team begin any work they need data to have a base-line. In order to know if they have achieved their goal they need to be looking at… you guessed it, data.

A great way to give the team an opportunity to focus on analytics is to replace Monday Stand Up with an Analytics Debrief. Take thirty minutes with the team to walk through what the state of the project is. At this point you can start to…

Build, Measure and Learn

Start the Lean Cycle. Once the team have proven that they can solve the problem, let them own the next steps. Allow them to put their opinions forward about the next steps. Development teams, usually made up of Software Engineers, UX Designers, and a Tech Lead — these a smart individuals they will have great ideas, especially if they feel like they own the product or feature they are working on.

A huge part of the lean movement is the Pivot or Persevere moment. By looking at the data every day and specifically every Monday teams are are given opportunities to say “Hold up. We aren’t getting the Return on Investment, let’s try something else.”

As you can see, by putting the emphasis on building a team with ownership you will be building a data-driven, lean, cross functional team. When a team cares, and have the right information at hand, it’s never too long before success come their way.

Conclusion

By using some of the methods above, teams will feel like they own more of the product/feature they are building and in turn delivery will increase. I have seen when teams are given ownership and use lean principles they excel, they deliver faster than traditional SCRUM teams.

These teams must be living and breathing analytics, but it is analytics that they own, it’s the data these teams obsess over, and due to this they make the right development choices and unsurprisingly the right business decisions.

The post How To Build Ownership In Your Team – Case Study appeared first on Luís Gonçalves.

Engaging Retrospective – A Fun Way To Engage With The Team In Your Retrospective

Engaging Retrospective – Twitterspective

Engaging retrospective – the Twitterspective is a paper-based social media-like retrospective exercise that can be used to gather data and generate insight from the team. It borrows parts from a different social media channels and mixes them into one. This is a fun way to engage with the team through a familiar mean.

How does it work? 

Before doing this exercise expect to see people smiling or giggling as you explain they will participate in a social media simulation on paper. In this exercise, everyone needs to be heard and will have their opinions accepted by their co-workers.

Once the Twitterspective Feeds starts to be filled up with post-its, the peers will be reacting to each post in real time.

I recommend using this exercise after your warm-up activity. This is a good exercise to change your traditional retrospectives. It gives a good opportunity to both shy and outgoing team members to be heard.

Instructions

1. Prepare post-its for each participant

2. Make sure you have a whiteboard, window, or a wall space that is large enough to place plenty of Post-its. This will act as your ‘Twitterspective Feed’

3. Ask the team: “If you were to express your opinion on a social media channel about the last Sprint (or any other chosen topic) what would you say?”

4. Allow 5-10 minutes of silent writing and ask the team to include hashtags about their ideas

5.  Ask the team to post their “Tweets” on the Twitterspective feed.

Source: Anthony Petrucci

6.  As a facilitator, you will read each post-it, one at a time, and have each team member to: 1) comment on the post-it (Give them 2 minutes to write their comment) 2) ‘like’ or ‘dislike’ the post. Please note – the author of the post DOES NOT comment or like/dislike his own post.

7. As a team, go through each post along with its associated comments. Take the conversation a little deeper when necessary. This conversation should not be longer than 40 minutes.

8. You should gather the team´s ideas during the discussion.

Timeline

Explanation/Introduction (1-3 minutes)

Writing Tweets (5-10 minutes)

Tweet and comment evaluation/discussion (30– 40 minutes; only allow 1-2 minutes to write each comment)

Conclusion – Identify and gather outcomes (5 minutes)

 

The post Engaging Retrospective – A Fun Way To Engage With The Team In Your Retrospective appeared first on Luís Gonçalves.

Why Is It So Hard for Executive Managers to Adopt an Agile Management Style?

Why Is It So Hard for Executive Managers to Adopt an Agile Management Style?

For years I have struggled to understand why adopting an Agile management style is so hard for many executive managers. I have often wondered why “these managers” cannot see the obvious: if you want to go the agile route, you need to change the way you lead people.

Of course, I still believe that for companies to use the agile style to become learning organizations, their executive team must adopt the right mindset. However, the way I was originally communicating this idea was clearly not the most effective.

Looking back, I understand how arrogant I was. I remember being in front of several executive managers and telling them how wrong they were, and how their style was not appropriate to lead their company in the right direction.

If you are an executive manager and you are reading this, I am sure you too would have wanted to kick me out of the room immediately. Luckily, a few years ago, I had the pleasure of working with one of the best corporate leaders of today. He was not only my superior but also a great coach who listened to my crazy ideas patiently and respectfully.

Eventually, he sat me down and forced me to reflect on my ideas. He asked me a simple question: “If everything I do is so wrong, how on earth am I leading a one-billion-dollar company?” Sometimes a simple, but a powerful question can change everything.

In that moment, I finally saw something that was not previously clear to me. Let me explain: for years, I have preached that executive managers must be Agile; I was very proud to tell them how wrong they were. But the truth is, they were extremely successful business people while I was a simple “transformation coach”. I am not trying to put myself down, but if you think in terms of success, they were much more successful than I was.

Executive Managers do not see the need to change to the agile management style because their life has been very successful without Agile.

After realizing that their success was the result of their past actions, I needed to change my approach. I needed to explain today’s market to the managers so they would understand the need for change. There are several different reasons why management needs to change. I have presented the ones I use the most below.

Society is not static like it was 20 years ago

Twenty years ago, society was much more static than it is today. The entry barrier to start a business was huge; only wealthy people, or those with a large initial capital, could start a company.

Because the barriers were so enormous, there was less competition. Nowadays, anyone can start a company and compete against the bigger corporations. I often say that it has never been so easy to make money than it is today. But at the same time, it has never been so difficult either because everyone has access to the same tools; there is far more competition today.

Executives must adapt to this new society and allow their companies to become more Agile if they want to survive this highly competitive market.

Companies, educational systems, and society were built using Taylorism Ideas and is not valid for today’s changing world

Most of our society is still built based on Taylorism Ideas. Educational systems and organizations are assembled in functional areas, or functional silos. Executive managers must re-think the way they run their organizations.

During the Taylorism Era, organizations were set up with functional departments. But in today´s world, companies cannot survive using this outdated model. Executives Managers must re-think how companies are organized. They need to base their company on value streams. They need to build their organization using personal networking to create solutions that customers will want.

Agile is not a process, Agile is the new revolution in our society.

I hear a lot of people (especially here in Germany where I live) say that Agile is not necessary, because that “Agile thing” is for software, and cannot be applied to other industries.

Well, if you are one of those believers, I have bad news for you: Agile is not a process. In my opinion, Agile is the new revolution in our society. I see the agile movement as the new industrial era of today’s society.

I truly believe that Agile is a completely new revolution, and it will change the way our society is built in tremendous ways. If you, as an executive manager, do not realize this, the chances of you being overrun by younger leaders are very high.

I wrote this article because I believe that most executive managers are brilliant people. I admire them and am continually fascinated by how much they can achieve. But, I realize that to prosper, they will need to overcome future societal challenges. I do not believe that there are many people who can explain clearly to management why they need to change the behaviour that once led them to their current success.

If you are reading this, and you are an executive manager, you might be interested to learn more about us. Evolution4all is a management consulting company dedicated to helping executives transform their companies into agile and learning organizations. We can help you increase your company’s reputation as an innovative leader that transforms to flourish in today’s most challenging market conditions.

Currently, I am helping an organization transform the strategy of their daily operations by using a method that I personally developed. As a result, this organization will communicate their major priorities clearly to all their employees. They will also outline how all staff contribute to the strategic success of the organization.

I started Evolution4all because I want to make a difference in the world by improving one company at a time. I want to help businesses create fantastic working environments where employees feel highly engaged. I want to enable staff to contribute to the success of their company because I believe that this grows a wealthier society.

Contact me below if you would be interested in learning more about this approach for your organization.

 

[contact-form-7]

The post Why Is It So Hard for Executive Managers to Adopt an Agile Management Style? appeared first on Luís Gonçalves.

The One Single Thing You Must Do To Be Better At Scrum

Scrum does not provide a quick fix. It will not help your software get better overnight and it definitely won´t increase trust among your team members quickly.

But there´s a trick to make Scrum work for you, and it´s not getting a certification or hiring an experienced agile coach.

Let´s take an example from 2 famous people

You´ve definitely heard of Bruce Lee, American born martial artist and actor who was raised in Hong Kong. He is famous for his martial arts related movies, such as First of Fury, The Big Boss or Enter The Dragon.

He was not only an actor and martial artist, Lee was also a philosopher. Lee said: “I fear not the man who has practiced 10,000 kicks once, but I fear the man who has practiced one kick 10,000 times.” 

Another example, Jeff Hoffman, an entrepreneur, motivational speaker, film producer, and jazz artist, tells the story of startup founders who were pitching him on a new business idea (Inc.com).

These founders, according to Jeff, were bright, motivated, passionate, and with brilliant idea. However, instead of selling him one great idea, they tried to sell three ideas. Big mistake.

Jeff Hoffman says: “What do you think happens when you try to launch three ideas at once? Nothing.”

What do they have in common?

It´s not hard to guess… Bruce Lee and Jeff Hoffman might be in different fields, but they have something important in common. They both believe that to be good at anything, you have to focus on a single thing at a time!

Coming back to Scrum…

And this leads us to Scrum. Sorry to disappoint you, Scrum is not a project management framework that solves all your team´s problems. It´s actually not really a framework, it´s more of a state of mind.

Scrum is anyways a great starting place for your team. But after you´ve incorporated scrum principles and found its deficiencies, what do you do then?

Retrospective

You might be all familiar with retrospectives, a method for inspecting, adapting, and improving your team´s processes. Retrospectives helps your team to go over what´s going well, what´s not going well, and what it can improve.

Hopefully you´ve been running successful retrospectives. But you can still ask yourself: Is there a way we can apply the principle of “being good at one thing” to retrospectives?

Action Plans and Follow Through

Let´s focus on the action plan – the outcome of a retrospective. Action plan is a list of items the team agrees to fix or improve. Action plan consists of one or more action items written in an actionable format.

Some teams choose to follow SMART acronym (specific, measurable,assignable, realistic, time-related). Some follow the Who, What, When paradigm (who will be responsible, what will be done, when will it be done). Both work well.

In my experience, I´ve come across many teams that tend to create long action plans (5 or even 10). These teams finish their retrospectives excited, but at their next retrospective they find out that nothing has really changed. Why is that always the case?

Here´s the one single thing you must do to be better at Scrum

The advice that Bruce Lee and Jeff Hoffman tell to become really good at something we have to focus on it alone, applies to Scrum and retrospectives too.

This means that the action plans we create should have a single action item. Just a single thing that the team agrees upon, prioritizes, and is committed to fix.

Focusing on a single action item gives a high probability that the team will follow through on implementing it.

The truth is that change is hard. Most people have a natural preference to stay within a comfort zone. How likely is it that your team will be able to change 10 things at once? Almost zero chance. How likely is it that your team will be able to change a single thing within a specific time period? Much higher.

And that´s where the secret is to be better at Scrum. It´s not to run more effective retrospectives or producing action plans. You all do that, I´m sure. It´s about having a sharp focus on a single action item that will have a measurable impact on the team´s performance.

Scrum does provide all the answers, it provides the conceptual framework for continuous improvement, which enables your team to get better. If you follow this advice, you will soon discover the true power of Scrum and agility.

All you have to do is focus on the one thing.

The post The One Single Thing You Must Do To Be Better At Scrum appeared first on Luís Gonçalves.

How To Be A Good Scrum Master – Starting Your Scrum Master Journey

How to Be a Good Scrum Master – Starting Your Scrum Master Journey

Two of the most common questions I’m asked every week are: “Luis, I attended the CSM or PSM training. Now I have the certification, but I do not have a clue where to start. Can you help?”, and “Luis, every time I start as a Scrum Master in a company I feel a bit lost, can you guide me?”.

This month (June 2017), I started a new engagement with a company. I will be assisting the organization’s mature team as well as three other teams in their agility processes. This has created the perfect opportunity for me to develop something extremely valuable for you. I decided to take advantage of this engagement and share with you all my activities with the Scrum Masters I´m currently helping.

I cannot promise that I will write about this topic every single week. I plan to build a small pocket book that will serve as a guide for every Scrum Master who starts a new job. I will outline a list of ideas that Scrum Masters can implement in the 20 first weeks of their new role. You will receive a different idea every week to try with your team. I will not only provide you with the idea, but explain why is it important as well.

Twenty weeks is roughly six months; the time that I believe we need to provoke real change in an organization. After six months, we become part of the organization’s system, making it more challenging to implement new changes. It’s easier to implement change at the beginning because it the first 6 months, you’re “new” and everyone is eager to hear your ideas. But after the probationary period, you are just another colleague.

I started my career back in 2003; within two years I was lucky enough to join Nokia. I was fortunate because I was exposed to Agile and Scrum very early in my career and it allowed me to observe what many Scrum Masters did during their careers.

My career path is a great example to demonstrate that it does not matter how good you are as an engineer. It matters more how agile you are. If you are not able to bring that component into the business side of the company, you will be out of the market quickly. That´s why Agile is not a “software development thing”.

So How Do You Start As Scrum Master?

Based on what I said earlier, I could identify key activities that Scrum Masters can do to cause huge impact on their teams.

Every time I join a company, I have a small roadmap that I advise Scrum Masters to follow. I want to be very clear here: you, as Scrum Master, know best what the team needs. It is likely that you will not be able to follow my roadmap religiously because you will need to adapt your mapping to your own team’s needs. My objective is to provide you with a baseline so that you do not feel lost. So, do not follow every step, but instead, adapt according to your circumstances.

The first thing I recommend to any Scrum Master when they start with a new team or organization is to ramp up a “Personal Kanban Board”. This will help them to keep track of their activities.

Below you can find 20 activities that you can put on your kanban board in order to start your job as Scrum Master.

One-to-one meetings with each team member. Ask them what are their biggest concerns and take notes. You will probably get a lot of tasks for your Kanban board through these meetings.
Do a workshop to clarify the roles and expectations of you and the team members.
Coaching Alliance – you should have this quite clear. Every professional coach has this with their clients; you should do the same.
Stakeholder mapping – this is a great way to help you get to know who works in the organization.
Make team policies visible in the room. It´s always great to have them visible so the team does not skip basic working etiquette.
Run a one-day team building workshop; it’s a great way to establish the product vision, team principles and values.
Establish a Kaizen board in the team room. This is mandatory for everyone who is serious about experimentation and learning.
Establish an Agile Retrospectives Input Box. Sometimes it can get boring to come up with all the topics in the retrospective, so it is nice to collect the topics up front.
Achievements wall – usually we never celebrate victories, but this is a great way for us to celebrate our accomplishments.
Kudos wall – a simple way to show people that we care for and respect each other.
Ramp up an organizational impediment board – this is a great way to remove organizational impediments.
Learning wall – this is where teams put their weekly learnings
Ramp up your communities of practices
Run workshops on flow and the principles of product development flow.
Organize a release planning to help your organization see more than just one sprint in the future.
Teach your product owner how to do release forecasting to help him/her to communicate with stakeholders
Run a workshop on user story mapping.
Run a workshop on impact mapping. Your product owner will love it!
Run a workshop on system thinking and causal loop diagrams.
Ramp up the practice of pair programming and install a pair programming matrix board

There are some people that believe Scrum Master is not a full time job. If you include all these activities into your personal Kanban board I am sure you will have work for several months. I hope your personal Kanban board will be dynamic and you will add tasks on weekly basis based on what your team needs.

During the upcoming weeks, I will write more blogs on each of these topics. As mentioned, I plan to write a small pocket book to help Scrum Masters organize their work during the first six months of their career. If you are interested learning more about this fascinating work, please subscribe below.

Hope you enjoyed.

Thanks,

Luis

The post How To Be A Good Scrum Master – Starting Your Scrum Master Journey appeared first on Luís Gonçalves.

How To Hold Absolutely Interesting Sprint Review Meeting

During a Scrum, regular sprint review meeting is scheduled to test, code, and determine the usability of a piece of software. Teams are expected to deliver a shippable product during each increment or Sprint.

To ensure their success, sprint review meeting is held at the end of each sprint. During the review, the Scrum team shows the Scrum Master and client what they have accomplished by demonstrating the newly designed features.

Sprint review meetings are deliberately informal. Programs like PowerPoint are forbidden and a preparation time limit of 2 hours maximum is set. These meetings are not, nor should they be viewed as a distraction or major detour for the team. Instead, they should be a natural transition and result of the sprint session.

Typically, the Scrum Master, members of the management team, the product owner, customers, developers from other projects, and the Scrum team participate in the sprint review meeting.

A goal for the software is set in the sprint planning meeting. Achieving this sprint goal is very important. To ensure this has been done, the delivered project is assessed and compared to the goal during the sprint review. Each product backlog is also brought into the review to ensure that the goal has been met.

Sprint Review Meeting

In a Sprint Review meeting, the Scrum Team and stakeholders discuss the work done during the Sprint. After assessing the work done along with changes made to the Product Backlog, the group collaborates on what steps should be taken next to optimize the value of the software. These meetings are always intentionally informal to keep the group focused on encouraging feedback and collaboration.

For month-long Sprints, review meetings should last a maximum four hours; referred to as time-boxed sessions. If the sprint sessions are shorter in duration, the review meetings will also be shorter. The Scrum Master is responsible for scheduling the meeting and informing everyone attending of the purpose of the review. The Scrum Master is also responsible of ensuring the meeting stays within the time-box.

The Sprint review meeting should include the following:

Attendance and participation of the Scrum Team, product owner, and invited key stakeholders.
The Product Owner should report the items in the Product Backlog; what backlog items have been done and what have not.
The development team discusses what went well and the problems they experienced. They should also inform the group what they did to resolve the problems.
The development team demonstrates their completed work while answering questions about their increment.
The product owner leads the discussion on the Product Backlog as it currently stands. They set projected completion dates based on the progress of the Sprint session.
To give valuable input to the Sprint planning, the entire group establishes the next steps during the Sprint review meeting.
This is a time to review potential changes in the marketplace, the valuation of the project and what areas are considering to be the most valuable. The next steps should also be outlined.
Review the timeline, budget, potential capabilities, and marketplace to determine the next anticipated product release.

By the end of the Sprint Review, revisions should be made to the Product Backlog to better define probable backlog items for the next Sprint session. The Product Backlog can be adjusted completely to introduce new opportunities.

Focus on the End User

Companies can be reluctant to involve end users for several reasons: some fear of scope creeping, others believe they are not allowed to ask the end users to get involved while some do not know who their end user is. End users are a vital part of the session. Never find an excuse not to involve them!

Involve the Product Owner

Too often, many companies organize their sprint reviews as a team presentation for the product owner to grade or judge their work. This format is complete nonsense! Sprint Reviews are not legal inquisitions or courts, they are an informal meeting designed to gain the customer’s feedback. Rather than presenting their data to a judge-like product owner, teams should collaborate with the product owner to review each completed story.

At the beginning of the sprint review, the product owner should stand first to welcome everyone and provide a project overview. The owner can then discuss the goals of the Sprint: what were achieved and what goals were not. It’s also a good time to talk about the quality level of the product, the software’s release, and product burndown. The owner can pinpoint what the reviewers should be looking for and explain to the team how to give their feedback. After they finish their introductory statements, the product owner can turn the meeting over to the Scrum team for a demonstration on the software’s functional abilities.

Understand Group Dynamics      

The group dynamics are altered significantly when the focus of the meeting changes from a lone product owner to a group collaboration that includes the Scrum team, stakeholders, and the end users.

When the product owner becomes part of the presenting team, the above roles change. Here’s a look at how each group is affected:

Product Owner

The Product Owner’s role changes to that of the real owner of the product. As a key member of the team, the owner becomes more responsible and accountable for the product. Their answerable for the decision-making and for presenting the results to the end users and stakeholders. He stands up and presents the product increment and gives insight into the state of the project.

By changing the role, the owner understands that he/she becomes more disciplined in maintaining the product design, release burndowns, and setting a level of quality for the work.

Another noticeable byproduct of this change is that discrepancies can be seen immediately. If the owner’s perceived reviews of the end users’ needs do not match the actual needs, it will become immediately noticeable.

Scrum Team

The Scrum team has a greater sense of pride and accomplishment, and is better positioned to demonstrate their work to the group. They are allowed time with the end user, and, in the best-case scenario, meet with the end users face-to-face time. Knowing the end user is the best way to develop quality software that will offer the highest value to the end user. By learning to accept feedback at each sprint session, the team gains more appreciation for the product owners and customers. The team will also feel less like they are being judged or graded by the product owner. They will come away from the meeting feeling more energized and motivated towards the next sprint.

Company Executives/Stakeholders

When executives and stakeholders are part of the review meeting, they can see the team work while participating in a real review of the work done and actions taken. Additionally, the end users can personally inform the executives/stakeholders of their needs.

Most importantly, they learn to act appropriately. The dynamics of these meetings are significantly different when customers are part of the session. When end users are present, executives and stakeholders spend less time bickering and criticizing others. Instead, everyone is on their best behavior, ensuring the review is more motivated and productive.

End Users/Customers/Partners

Without question, the end users are the stars of the review meetings because the spend valuable face-to-face time with the software developers. They spend so much time with the developing group, the end users feel as sense of belonging. Because they spend so much time and involvement in the development of the project, the users become the biggest company supporters. This acquired knowledge is valuable in reducing in flood of support calls that are common after a release.

Scrum Master

The Scrum Master facilitates the sprint review. This person establishes an environment among all members so that great accomplishments and goal achievements can happen. To make it happen, the Scrum Master must make sure the right people are at the meeting. He/she must also ensure the right room and supplies are readily available.

Other smaller details like ordering food and drinks is also the responsibility of the Scrum Master. While this may seem unimportant to some, food is fuel that teams need to continue their hard work during the meetings. Personally, I have ha many great conversations with teams while eating together.

One thing to keep in mind, this is not the Scrum Master’s show – they are not the star. The Scrum Master is there to support the team. They also welcome the end users and make sure they are included in the team, have the chance to be heard, and are behind the scenes.

Be Courageous

To master the art of feedback, you must first create an environment that allows open feedback to happen. Involving the end users in the sprint reviews can be scary, but remember: hearing the feedback early gives you time to make the needed adjustments. Waiting till the end to find discover you went down the wrong path is a waste of precious time and resources. So, if you’re still afraid of scope creep, let it go. During the review, the Product Owner will first decide what trade-offs will to make after each sprint review. You can use this opportunity to find out more about what the end users need and do not need; this helps reduce and eliminate overproduction of some features that will never be used.

By focusing on the end user, and creating an energy and excitement, you will create a sprint review that customers will want to attend. It’s easy to do; simply set up a review that offers direct value for the end user. Once that is done, just sit back, and listen. You will be surprised what you learn.

Sources used in this blog post:

https://www.mountaingoatsoftware.com/agile/scrum/meetings/sprint-review-meeting

https://www.scrum.org/resources/what-is-a-sprint-review

https://www.scrumalliance.org/community/articles/2009/april/the-sprint-review-mastering-the-art-of-feedback

The post How To Hold Absolutely Interesting Sprint Review Meeting appeared first on Luís Gonçalves.