Possibly the most important part of your Agile journey is your ability to inspect and adapt. This helps you to constantly iterate and improve your output, methods, processes, and product. A retrospective provides the opportunity to look back on the sprint you’ve just completed and make plans to improve in the future. Here are 11 ways to ensure your retrospectives are successful.
Want to run better retros? Learn how in our online short course, Facilitating Retrospectives
What is a retrospective?
A retrospective is a meeting held for the purpose of reflecting on the product development or workflow process. The aim of a retrospective is to look closely at the processes and products produced during a sprint, discuss these as a team, and decide on a way forward together to drive constant improvement.
A retrospective is also known as a Scrum retrospective, retrospective meeting, a sprint retrospective, or simply a retro.
Why are retrospectives important?
When done correctly, retrospectives can be a catalyst for organisational change as well as team change. They can be a place to build and enable teams, or to help teams start their journey from the best possible place. Team retros can be a place for learning, problem solving, or having fun and motivating each other. This is why it is so crucial to get them right.
Common mistakes in retrospectives
Many retrospectives follow the same formula: the team is all gathered in a room around a small table. The Scrum Master throws some pens and some sticky notes on the table, and the team writes down what went well and what can be improved. They make lists and group the topics together. Often, half the people in the retro aren’t really engaged, and some are on their phones. Most of them would rather be coding.
While this makes sense on the surface level, when you look a little closer you often find the same strengths and weaknesses emerging every time. Actions aren’t always followed through effectively, resulting in a sort of Groundhog Day experience that can be very frustrating for all involved.
If people stop engaging in the meeting and feel that their time is being wasted, then it probably is. If meetings aren’t adding value and actively driving change within the team and the organisation, they aren’t achieving what they set out to achieve, and they need to be stopped or changed.
How to make your retros successful
There are some simple changes you can introduce to vastly improve your retrospectives. Here are our 11 top tips to make your retros successful.
Embrace the five stages of a successful retrospective
Diana Larsen and Esther Derby’s book Agile Retrospectives – Making Good Teams Great lays out five stages of a successful retro.
- Set the Stage: Understand where everyone is coming from today.
- Gather Data: Get the viewpoints of all members of the team so that you can create a shared picture of what is happening.
- Generate Insights: Unpack the data and analyse or look for the root causes.
- Decide what to do: Make sure the team decides what’s most important together.
- Close: Appreciate people’s time and get feedback on how to improve your retros in future.
Your retrospectives won’t always need to include all five stages, but this is an excellent base-line and makes for a good starting point.
Recommended for you: Take an online course on Facilitating Retrospectives
Tailor your retro to your team’s needs
A generic retro structure can be a good start, but if you want to make meaningful improvements you need to make sure you understand the specific needs of your team. The facilitator, coach, or Scrum Master should observe and pay attention during the sprint, project, or whatever cadence the team has. They should be looking closely at how the team works together and any difficulties they’re having. If you’re the Scrum Master, ask yourself:
- What does the team need?
- Is there a specific issue that they are grappling with?
- Are they making their sprint goals?
- How is the level of trust? Have they lost trust in each other or is there a lack of trust between the team and the product owner?
- Are they a new team still finding their rhythm?
- How are the energy levels?
With these answers in hand, you can start to put together a picture of what the team needs: maybe there are big trust gaps in the team that need to be addressed, or maybe they’re lacking resources. Maybe they have just had a hectic series of sprints, and they need to celebrate their wins and not change anything. The only way to find out is to be in tune with your team and the work they’re doing.
Recommended training to boost your skills: Advanced Scrum Master certification
Plan well
Once you have decided on what your team needs to focus on, you need a plan for your retrospective. Spend some time deciding how you are going to divide up the time spent in the retro: are you going to split it into the five phases? Do you need all five phases, or can you skip some? And finally, what are you going to do for each phase?
Break people into smaller groups
Groups of two or three are optimal in a retrospective.It makes it much easier to keep the energy high and keep people engaged. It is also much easier to get things done.
Encourage team members to contribute in their own way
Make sure you are encouraging everyone in the team to contribute in their own way. Many people are tempted to force people out of their comfort zones, such as making introverted employees take the lead on talking. While there is some merit to encouraging people to step out of their comfort zones, remember to play to everyone’s strengths. Someone who doesn’t like talking may prefer to do the writing, do some silent brainstorming in a small group, or get up and take notes on the board. These are valid ways of being engaged, and they bring the best out of people rather than putting them on the spot and causing anxiety.
Have an outcome in mind
A common mistake in team retros is to approach it without a specific outcome in mind, to see what comes up. This lack of structure can be useful on occasion, to allow the team more freedom to explore their experiences. However, most of the time it can make things feel directionless and can get in the way of moving forward. Make sure that there is an outcome for the retrospective and provide support to the team in reaching that outcome. Be careful not to make the change for the team: you want to encourage self-organisation.
Dig deep and find the root cause of problems
If you are only looking at the symptoms of a problem and not understanding the root cause, then you are missing a valuable opportunity for learning and improvement. You will also keep having to deal with the same or similar issues over and over again. This may also result in long lists of policies or agreements set up to change behaviour, but without meaningful change, because the root cause hasn’t been addressed. Analyse and dig beneath the surface, or you may just be wasting your time.
Make use of retrospective games and exercises
There are plenty of places to find great ideas for exercises to do during retrospectives. Diana Larsen and Esther Derby’s book Agile Retrospectives – Making Good Teams Great has a wealth of things to do and is an excellent starting point. There is also a website called Retr-O-Mat that has many ideas for games or exercises. While a game or exercise can be a great way to get creative juices flowing, break the ice, and relax the mood, be careful not to overload your teams with games. The most important thing is to pay attention to what your team needs, make sure your retro flows, and have an outcome in mind.
Use SMART goals
Remember to not try to do everything at once. One or two key changes are usually more than enough. If a team tries to do everything, they often end up doing nothing. A good idea is to come up with an Action Plan and include a SMART goal. Smart goals are Specific, Measurable, Attainable, Realistic, and Timely.
Get professionals involved
One of the best ways to transform your retrospectives into useful, successful events that the whole team finds valuable is to consult with professionals like the coaches, mentors and facilitators at agile42. Contact us to enquire about our services. We offer them remotely or in-person, and we can set you up for success so you can go forward confidently.
Ask for regular feedback
The easy answer to this is to ask for feedback from the team. At the end of each retrospective, devise a way to get feedback on the retrospective itself and ideas for improvement. There’ll always be someone who will just request pizza, but you will be surprised at the great ideas that are offered if you open the door for honest feedback. As you are asking for continuous improvement from your teams, make sure that you are also looking to continuously improve yourself and your retrospectives.
Finally, remember, if you are having fun, chances are others are too. Sometimes we need to be serious and sometimes we just need to have fun.
Goal setting as a tool for organizational change: a case study
/by Paul BultmannThis article explores how Objectives and Key Results (OKRs) and goal setting can change the collaboration style within an organization, based on agile42’s experiences with a particular recent case study. In this instance, we introduced OKRs and noticed a number of changes emerging organically within the organization. The OKRs were intended to set strategic product goals, but we noticed new ways of collaborating, bringing about positive organizational change and empowering teams to self-organize. In this article we outline the challenges the company was dealing with initially, the positive side effects the OKRs supported, and some assumptions that contributed to these positive side effects.
The challenges the company faced
We were approached to work with a product department made up of 15 tech teams, all of which work on a single product. They had several challenges that both the teams and management were hoping to improve.
Firstly, they had identified a strong lack of direction and priority on department level because there was no product strategy or roadmap. They were working from a long feature list from stakeholders, which had a number of contradictory requests and contained detailed descriptions with fixed scopes.
The teams were also noticing a lack of team autonomy. They weren’t able to make decisions related to product improvement. It was the kind of culture we refer to as a Feature Factory, where the team was building a large quantity of requested features rather than taking an iterative approach to build and improve the product. The result was a lack of focus on the value of the functionality. To make matters more difficult, the dev teams didn’t have access to the business problem, so they were not able to do any reasonable scoping.
Additionally, there were strong dependencies between teams. Most of them were able to deliver smaller features independently within their area, but when it came to bigger releases, dependencies occurred all over the place and created bottlenecks.
OKRs as a tool for organizational change
The leadership team started to experiment with OKRs and set strategic product goals for the department. Over time it grew to a full goal-setting framework. They started with big and broad intentions that were valid for the year. The intentions for the year included the following examples:
For every quarter the big intentions were broken down into Objectives and measurable Key Results, which were valid for the whole department. Some examples for the quarterly department Objectives and Key Results included the following:
With those given targets all teams were asked to set their own quarterly OKRs that contribute to the abovementioned department goals. All this was synchronized and made transparent in newly introduced events: every quarter there was a Review, Retrospective, and Planning event with all teams together.
The positive effects of goal setting
Some time after introducing the new goal setting framework, there were three key positive organizational changes noticeable that had not been anticipated.
Photo by Jud Mackrill on Unsplash
Focus on outcome instead of output
There was a distinct shift in the mindset, from an output- to an outcome-oriented approach. In the beginning the strategic goals were used to get a feature list implemented (e.g. integrate voucher provider X). This gave little freedom to the product teams for problem-solving.
By formulating the Key Result as a measurable business value (e.g. increase monthly active users by X%) the teams were asked to find solutions themselves. In this case a voucher provider could help to reach the Key Result, but it is only one possible way to do so among many others. The teams needed to ask themselves, “what can we do in order to increase monthly active users”? And that's a totally different challenge than “I have to implement feature X”. It encouraged team members to consider the impact of their work and the features they built, rather than just checking them off a list.
Product Discovery Streams
This positive side effect came along with another challenge and opportunity. While the teams were great at delivering a clearly described feature, most of them were not accustomed to being involved in solving a business problem. They simply didn’t have the skills required to dive into the business context, understand the customer, run interviews, evaluate possible ideas, and design and run experiments with a subset of users.
The organization started to realize that there was huge scope for new skills to be learnt. So they began to experiment with product discovery streams that were using design thinking, user experience design, and other approaches depending on the situation. Within a stream, people from different departments started to work together that wouldn’t have been in contact before, e.g. business development, operations, UX, product teams, and developers.
The organization increased its ability evaluate and test ideas before implementation, and reduced potential waste of unwanted features. Customer centricity also increased significantly as there was research made about their needs and wishes rather than untested assumptions.
The emergence of temporary teams
Another unplanned positive effect was the building and dissolving of temporary teams around business problems. Depending on the nature of the topic, as well as its complexity and size, a group of people came together to solve the problem. Previously, backlog items would have been sent from one team to another, with bottlenecks forming in between. The new system meant that teams faced with time pressure, teams could simply come together for a short period of time, get the work done, and then move back to their original teams - with the added bonus of enhanced sharing of knowledge.
Why did these positive changes occur?
There are a number of conditions that contributed positively to the above side effects of the goal setting. Although it is highly multifactorial, we want to highlight some factors that we believe have had a strong influence.
Connecting people rather than coordinating
First of all we observed a strong focus on connecting people rather than coordinating them. The leadership team understood that if people know and trust one another, they will collaborate in a meaningful way when it is needed. So there were a lot of social events and team building activities that created bonds between people, especially during pandemic times. This made it easier to ask for help and to collaborate on a specific problem.
Leadership allowed freedom to self-organize
We observed that the leadership team gave the teams a lot of freedom and set high expectations for the teams to self-organize. This was to such a high degree that there were even complaints about missing structure to help teams coordinate themselves, and concerns that the leadership team was too uninvolved. Although we initiated rounds for coordination, the interference stayed low so that the relevant structures simply grew around specific work needs.
The UX department was strong, capable, and eager
Finally we saw that the UX department was strong, capable and eager to change the mindset within the department and company. They quickly took the initiative to drive a product-focused rather than a project-focused mindset, and to experiment with product discovery. It also was their first time doing so, but they did a great job by involving the right people, being willing to fail and to learn from that.
Photo by Annie Spratt on Unsplash
What can we learn from this case study?
In conclusion we observed these organizational and cultural changes happened due to the implementation of OKRs (or any strategic goal-setting framework). It guided the department towards a few common goals. This influenced how the organization collaborated, while new structures evolved and rituals grew organically around these structures. This resilient structure developed organically - not by management or consultant’s design, but by the needs of the people that work with them.
Many organizations focus on designing collaboration models and defining how people are supposed to do their work. There’s a saying that will be familiar to most who have heard of Agile frameworks: “manage the work and let the people self organize around it”. This case study was a great example of this, and can serve as inspiration for other managers and leadership teams. Allowing teams to self-organise around the goal-setting framework has a big impact and can be a change management tool in and of itself, leading to new structures and ways of working.
Interested in transformation at your company?
We are available for training, coaching, consulting, workshops, and courses, both in-person and remotely. Take a look at our online short courses, browse our Scrum and Kanban certifications, and check out our leadership courses. If you’re interested and want more information, feel free to contact us.
Why is mentorship so important?
/by Ninja GranzowMentoring is a relationship centred on personal or professional growth that aims to enhance your skills and help you gain experience in a certain area of your life or work. Many successful people have built part of their professional career on having a mentor. In my personal experience as a mentee, I have found that mentors can guide us through challenges we face, help us grow, and support our lifelong learning process.
Read on to learn what mentoring is about, what makes it different to coaching, and how mentoring can help you achieve your goals. agile42 also recently hosted a webinar about all things related to mentoring, and you can watch it below.
What is mentoring?
Mentoring serves to transfer practical experience from one person (the mentor) to a less experienced person (the mentee). It is about the mentor sharing their relevant knowledge, experience, and skills while also providing guidance and support. This transfer of knowledge and building of experience is done through discussions, stories, sharing of anecdotes, and advising. Pairing up on practical matters at hand or practical demonstrations of procedures can also help to build up the mentee’s experience.
Because mentoring is focused on the mentees’ personal and professional development, it usually is a long-term relationship which may also contain aspects of career or life coaching. A good mentoring relationship can be a powerful tool for growth, which could lead to a new job, a promotion, or even a better work-life balance. This is why it is never too late for starting a mentoring relationship – it is not limited to your onboarding phase when starting a new job or the early stage of your career.
WATCH: agile42’s Mentoring Webinar
Agile coaches Ninja Granzow and Dennis Becker sat down to talk about their experiences and insights on mentoring, from the perspective of mentees. They answered the most pressing questions about mentoring: what is mentoring, and how does it differ from coaching? How can you set meaningful mentoring goals? They discussed the challenges in times of virtual collaboration, and how to nurture an effective mentoring relationship. Whether you’re a seasoned mentor, you have recently started a new job, or you are simply hoping to expand your skills, this webinar is worth a watch.
Coaching vs Mentoring: What’s the difference?
Mentoring is often confused with coaching, because a good mentor must also be a good listener and a good coach. And vice versa: coaches must sometimes act as mentors. As both coaching and mentoring provide similar benefits, there are a few key differences. To understand the differences, we need to explore what both coaching and mentoring are about in more detail.
What is coaching?
My personal coaching experience is as a Systemic Coach: in other words, a coach who works with the system. Systemic Coaching is non-directive, which means that it does not offer advise or direct solutions to problems. Rather, the focus is on asking the right open-ended questions, as well as providing trust, confidence, and space, for the coachee to have an effective and deep conversation and start to find their own solutions.
The coachee usually has a need to address a specific theme or change, even if they cannot yet put this into defined words. The coach’s task is to help the coachee to define or refine this topic, reach their objectives and consider how to achieve more by finding capabilities within themselves. The information, interpretations, goals and actions all come from the coachee and the coach merely facilitates discovery through discussion. The approach to address the change is and remains up to the coachee.
In professional relationships, coaching encourages individuals to perform in their roles, which often requires specific forms of coaching like Agile Coaching. Agile Coaching is the art of helping people see reality using an agile and lean perspective and change their paradigms, habits, and roles accordingly. It borrows a lot from Systemic Coaching. However, where the Systemic Coach is non-directing, the Agile Coach usually has an agenda of making the team more agile. As Agile Coaching has two very different sides (agility and coaching) there could also be teaching, role-modeling, advising, and mentoring involved in the process.
How is mentoring different?
While coaching is about providing a safe space for a journey of self-discovery, mentoring is focused on transferring specific learnings from an experienced person to a person who wants to develop a specific area of interest. As an example, when I joined agile42, I was mentored by a more experienced Agile coach, who provided guidance and direction. In my own experience as a mentee, mentoring typically is less structured and more informal than coaching. Even though I recommend having a mentoring meeting agenda and goals at hand (and it is up to you as a mentee to put this together), coaching normally follows a more rigorous structure for having a conversation.
Why is it important to have a mentor?
For me, as a person committed to lifelong learning, it is helpful to have a mentor for staying focused in terms of my development path. There are so many interesting areas of learning, and I can easily get lost with too many options. I am grateful that I can regularly exchange ideas and thoughts with my mentor and get a different perspective on my plans and development.
Personal growth and development is about learning: learning new skills and behaviours, discovering blind spots, and constantly expanding existing knowledge. This makes both mentoring and coaching extremely effective learning techniques that can dramatically improve your individual growth and performance.
Being mentored could help to deal with situations you do not feel confident with because you have never done them before, lack insights, or need feedback. Mentoring helps with increasing confidence and developing interpersonal skills. This also includes exploring your comfort zone and expanding it step by step. You could learn from your mentor in order to prevent you from stepping into very common traps.
From a company’s perspective, mentoring can increase employee engagement and retention, and also provides a great opportunity for mentors to learn more about different personality types, contexts, and points of view.
How to set mentoring goals
As a mentee, I found that achieving a goal was only possible after first getting to know my improvement areas, both short and long term, and across various aspects. I recommend asking yourself the below questions, and making notes on your responses:
Skills and experience
Personal growth and development
You can start by brainstorming high-level dreams and then break down your lofty ideas into individual goals that you are more likely to accomplish through short-term learning cycles.
There are a number of strategies and methods for defining your mentoring goals.
SMART goals
One strategy to create effective and realistically achievable goals is to use SMART goals. These are goals which are:
The graphic below explains a little more about each aspect of a SMART goal:
Competency Mapping
Another option is a technique called competency mapping. It is easy to do and you could even create smart visuals like a matrix in order to create a living artifact you update regularly.
Here’s how to do it:
Your mentor could also support you by guiding you through this assessment. When you have found suitable goals for yourself, your mentor can support you by helping you with the following:
Reflecting on goals
Your mentor can help you to achieve your goals by constantly providing constructive feedback and guidance towards your goal. For example, I usually plan to revisit my mentoring process every 3-4 months or after I have reflected on bigger steps of personal development. Together with my mentor, we then talk about what to change or add. The more specific you can define your goals, the easier it will be to focus on the right things and also find a matching mentor .
How to choose a mentor
When choosing a mentor, one of the most important aspects is to find a person you trust. This is a good basis to open up and talk about your blind spots, improvement areas, and challenges you want to overcome.
I believe that relationship-building and interpersonal skills are crucial in this context. Because this is a very individual thing, pay attention to your gut feeling. Who do you look up to in your network? Does this person have an honest and keen interest in helping you grow? Make sure this person sees mentorship as an option and not an obligation.
Mentoring should be built on solid and concrete advice, guidance, and first-hand experience, so your mentor also needs to have the knowledge and skills in the area in which you aim to grow.
Last but not least, the right person should provide dedicated, long-term commitment. Based on my personal experience, a motivating, encouraging energy helps to spice up your development journey. A good mentor is also someone who is open minded and can learn from you as well – a good mentoring relationship is not a one-way street.
Do you need a great mentor?
If you’re in a period of change or transition and you need to find the perfect person to guide you, get in touch! agile42 offers mentoring services, with certified mentors who are able to help you grow both personally and professionally. They can customise the offering to suit your specific needs, and provide professional guidance in any aspect of leadership, Agile, Scrum, and more.
11 Ways to Improve Your Retrospectives
/by agile42Possibly the most important part of your Agile journey is your ability to inspect and adapt. This helps you to constantly iterate and improve your output, methods, processes, and product. A retrospective provides the opportunity to look back on the sprint you’ve just completed and make plans to improve in the future. Here are 11 ways to ensure your retrospectives are successful.
Want to run better retros? Learn how in our online short course, Facilitating Retrospectives
What is a retrospective?
A retrospective is a meeting held for the purpose of reflecting on the product development or workflow process. The aim of a retrospective is to look closely at the processes and products produced during a sprint, discuss these as a team, and decide on a way forward together to drive constant improvement.
A retrospective is also known as a Scrum retrospective, retrospective meeting, a sprint retrospective, or simply a retro.
Why are retrospectives important?
When done correctly, retrospectives can be a catalyst for organisational change as well as team change. They can be a place to build and enable teams, or to help teams start their journey from the best possible place. Team retros can be a place for learning, problem solving, or having fun and motivating each other. This is why it is so crucial to get them right.
Common mistakes in retrospectives
Many retrospectives follow the same formula: the team is all gathered in a room around a small table. The Scrum Master throws some pens and some sticky notes on the table, and the team writes down what went well and what can be improved. They make lists and group the topics together. Often, half the people in the retro aren’t really engaged, and some are on their phones. Most of them would rather be coding.
While this makes sense on the surface level, when you look a little closer you often find the same strengths and weaknesses emerging every time. Actions aren’t always followed through effectively, resulting in a sort of Groundhog Day experience that can be very frustrating for all involved.
If people stop engaging in the meeting and feel that their time is being wasted, then it probably is. If meetings aren’t adding value and actively driving change within the team and the organisation, they aren’t achieving what they set out to achieve, and they need to be stopped or changed.
How to make your retros successful
There are some simple changes you can introduce to vastly improve your retrospectives. Here are our 11 top tips to make your retros successful.
Embrace the five stages of a successful retrospective
Diana Larsen and Esther Derby’s book Agile Retrospectives – Making Good Teams Great lays out five stages of a successful retro.
Your retrospectives won’t always need to include all five stages, but this is an excellent base-line and makes for a good starting point.
Recommended for you: Take an online course on Facilitating Retrospectives
Tailor your retro to your team’s needs
A generic retro structure can be a good start, but if you want to make meaningful improvements you need to make sure you understand the specific needs of your team. The facilitator, coach, or Scrum Master should observe and pay attention during the sprint, project, or whatever cadence the team has. They should be looking closely at how the team works together and any difficulties they’re having. If you’re the Scrum Master, ask yourself:
Photo by Jason Goodman on Unsplash
With these answers in hand, you can start to put together a picture of what the team needs: maybe there are big trust gaps in the team that need to be addressed, or maybe they’re lacking resources. Maybe they have just had a hectic series of sprints, and they need to celebrate their wins and not change anything. The only way to find out is to be in tune with your team and the work they’re doing.
Recommended training to boost your skills: Advanced Scrum Master certification
Plan well
Once you have decided on what your team needs to focus on, you need a plan for your retrospective. Spend some time deciding how you are going to divide up the time spent in the retro: are you going to split it into the five phases? Do you need all five phases, or can you skip some? And finally, what are you going to do for each phase?
Break people into smaller groups
Groups of two or three are optimal in a retrospective.It makes it much easier to keep the energy high and keep people engaged. It is also much easier to get things done.
Encourage team members to contribute in their own way
Make sure you are encouraging everyone in the team to contribute in their own way. Many people are tempted to force people out of their comfort zones, such as making introverted employees take the lead on talking. While there is some merit to encouraging people to step out of their comfort zones, remember to play to everyone’s strengths. Someone who doesn’t like talking may prefer to do the writing, do some silent brainstorming in a small group, or get up and take notes on the board. These are valid ways of being engaged, and they bring the best out of people rather than putting them on the spot and causing anxiety.
Photo by Hannah Busing on Unsplash
Have an outcome in mind
A common mistake in team retros is to approach it without a specific outcome in mind, to see what comes up. This lack of structure can be useful on occasion, to allow the team more freedom to explore their experiences. However, most of the time it can make things feel directionless and can get in the way of moving forward. Make sure that there is an outcome for the retrospective and provide support to the team in reaching that outcome. Be careful not to make the change for the team: you want to encourage self-organisation.
Dig deep and find the root cause of problems
If you are only looking at the symptoms of a problem and not understanding the root cause, then you are missing a valuable opportunity for learning and improvement. You will also keep having to deal with the same or similar issues over and over again. This may also result in long lists of policies or agreements set up to change behaviour, but without meaningful change, because the root cause hasn’t been addressed. Analyse and dig beneath the surface, or you may just be wasting your time.
Make use of retrospective games and exercises
There are plenty of places to find great ideas for exercises to do during retrospectives. Diana Larsen and Esther Derby’s book Agile Retrospectives – Making Good Teams Great has a wealth of things to do and is an excellent starting point. There is also a website called Retr-O-Mat that has many ideas for games or exercises. While a game or exercise can be a great way to get creative juices flowing, break the ice, and relax the mood, be careful not to overload your teams with games. The most important thing is to pay attention to what your team needs, make sure your retro flows, and have an outcome in mind.
Photo by Brooke Cagle on Unsplash
Use SMART goals
Remember to not try to do everything at once. One or two key changes are usually more than enough. If a team tries to do everything, they often end up doing nothing. A good idea is to come up with an Action Plan and include a SMART goal. Smart goals are Specific, Measurable, Attainable, Realistic, and Timely.
Get professionals involved
One of the best ways to transform your retrospectives into useful, successful events that the whole team finds valuable is to consult with professionals like the coaches, mentors and facilitators at agile42. Contact us to enquire about our services. We offer them remotely or in-person, and we can set you up for success so you can go forward confidently.
Ask for regular feedback
The easy answer to this is to ask for feedback from the team. At the end of each retrospective, devise a way to get feedback on the retrospective itself and ideas for improvement. There’ll always be someone who will just request pizza, but you will be surprised at the great ideas that are offered if you open the door for honest feedback. As you are asking for continuous improvement from your teams, make sure that you are also looking to continuously improve yourself and your retrospectives.
Finally, remember, if you are having fun, chances are others are too. Sometimes we need to be serious and sometimes we just need to have fun.
Mentoring: Interview with Agile Coach Dennis Becker
/by Lauren EdwardsDennis Becker is an agile42 coach with a background in law, agile project management and human-centred design. In 2021 he joined the agile42 team, and experienced our mentoring-based onboarding processes. We asked him a few questions about what mentoring means to him, and why it's such a key part of agile business onboarding.
He shares his insights and reflections in the video below.
Register for October's free mentoring webinar to learn more about mentoring and ask questions.
Read the full interview transcript below:
Why is it important to have a mentor?
There are many ways in which a mentor can encourage and enable the personal as well as the professional development of another person. For example, they can help focusing on a goal or provide qualitative feedback.
In a company, the knowledge of a mentor can help in training and creating a high quality and productive workforce through mentoring programs. With the help of a mentor, the mentee can set personal as well as professional development goals themselves. At times when the mentee is having troubles completing a task or achieving a goal, you can go and ask the mentor for help. This encouragement may motivate the mentee to continue despite obstacles and a mentor can also recognize and articulate the strength of the mentee to instill confidence.
There's honest feedback that comes from a trusting mentoring relationship. Through building trust, the mentee understands that the constructive criticism he gets or may get is aimed to their growth and is not intended to to make them feel miserable. A mentor can expose weaknesses and point out opportunities for improvement to the mentee.
In a nutshell, the mentor can support your growth, help you setting goals, and offer encouragement and feedback.
How has agile42's mentoring made a difference to your onboarding experience?
When you start a new job, and perhaps even take a new position, the flood of new information and things can often leave you somewhat disorientated. It's just too much. At first, it can even be difficult to recognize your own value, and how you can best contribute.
By offering weekly mentoring from the first week on, agile42 was helping me a lot to quickly understand the context and procedures I was in and to quickly get my head around things. However, we paid special attention also to my individual development, which means that we picked out various topics which are important from my perspective in order to reach goals and to improve.
Due to the situation with COVID, and the remote setup, the mentoring had a different importance, I think, than in previous jobs because it was more difficult to get a feeling for your work, for your colleagues, and what you actually do and with whom. So the mentoring was already helping me a lot to get started.
What is important when choosing a mentor?
What I think is important to consider when choosing a mentor is possible diversity. You will work closely with your mentor, and it's important that you harmonize with this person. Otherwise the relationship will feel a little bit strained or forced. But at the same time, you don't want to have someone who's just like you or your best friend, because you rather need someone who brings in a new perspective of things; who brings in diversity. And having this kind of mentor then helps you to step out of your comfort zone.
Secondly, trust is important. Trust is one of the greatest importance. After all, you will tell your mentor a lot of different things in confidence. In fact, this relationship will be most successful if your mentor trusts you as well as you trust your mentor. So build on this mutual trust to make the very best of your partnership.
Last but not least: expertise. You would like a mentor with enough experience to help you address your specific challenges. But that doesn't necessarily mean that you have to choose someone with the most years of work experience on their record. This isn't a matter of finding a mentor with the most years of experience or the greatest title. Instead, it's about choosing a mentor who has the knowledge as well as the experience to guide you along your own way.
To summarize, this means there are three important things to consider when choosing a mentor: first of all, diversity; second of all trust; and last but not least, expertise.
Curious about Mentoring?
Becker will be a guest in our October webinar, The Value of a Sensei: Lifelong Learning Through Mentoring. Along with agile42 coach Ninja Granzow, he will explore this theme and share insights. Register now for free to learn more and ask questions.
Festive Giveaway: Competition Terms and Conditions
/by agile421- The Promoter is agile42 whose registered office is at Grünberger Str. 54, Berlin 10245, Germany.
2- The competition is open to residents of all countries aged 18 years or over except employees of agile42 and their close relatives and anyone otherwise connected with the organisation or judging of the competition.
3- There is no entry fee and no purchase necessary to enter this competition.
4- By entering this competition, an entrant is indicating their agreement to be bound by these terms and conditions.
5- Route to entry for the competition and details of how to enter are via LinkedIn, Facebook, Instagram, and Twitter.
6- Only one entry will be accepted per person. Multiple entries from the same person will be disqualified and only the first comment posted per person will count as an entry.
7- Closing date for entry will be Friday, 10 December 2021 at 23:59 CET. After this time the no further entries to the competition will be permitted.
8- No responsibility can be accepted for entries not received for whatever reason.
9- The rules of the competition and how to enter are as follows:
Entrants are required to follow agile42, like the post, and post a comment sharing their biggest lesson form the year 2021. This can be done on any one of the four platforms where the competition is active.
10- The promoter reserves the right to cancel or amend the competition and these terms and conditions without notice in the event of a catastrophe, war, civil or military disturbance, act of God or any actual or anticipated breach of any applicable law or regulation or any other event outside of the promoter’s control. Any changes to the competition will be notified to entrants as soon as possible by the promoter.
11- The promoter is not responsible for inaccurate prize details supplied to any entrant by any third party connected with this competition.
12- The prize is as follows:
The prize consists of e-learning courses from the agile42 e-learning catalogue, for up to 10 individuals. Each individual may take one course. The voucher is valid for 12 months, and once enrolled, the winner will have one month of access to complete the course. The prize is as stated and no cash or other alternatives will be offered. The prizes are not transferable. Prizes are subject to availability and we reserve the right to substitute any prize with another of equivalent value without giving notice.
13- Winners will be chosen at random by software, from all entries received and verified by Promoter and or its agents.
14- The winner will be notified by direct message (DM) on the social media platform on which they entered within 10 days of the closing date. If the winner cannot be contacted or do not claim the prize within 48 hours of notification, we reserve the right to withdraw the prize from the winner and pick a replacement winner.
15- The promoter will notify the winner when and how the prize can be redeemed via voucher code. The voucher will be valid for 12 months from the date of issue.
16- The promoter’s decision in respect of all matters to do with the competition will be final and no correspondence will be entered into.
17- By entering this competition, an entrant is indicating their agreement to be bound by these terms and conditions.
18- The competition and these terms and conditions will be governed by German law and any disputes will be subject to the exclusive jurisdiction of the courts of Germany.
19- The winner agrees to the use of their name, image, and comments in any publicity material, as well as their entry. Any personal data relating to the winner or any other entrants will be used solely in accordance with current data protection legislation and will not be disclosed to a third party without the entrant’s prior consent.
20- The winner’s name will be available 28 days after closing date on the original social posts across the four platforms.
21- Entry into the competition will be deemed as acceptance of these terms and conditions.
22- This promotion is in no way sponsored, endorsed or administered by, or associated with, Facebook, Twitter, LinkedIn, Instagram or any other Social Network. You are providing your information to agile42 and not to any other party. The information provided will be used in conjunction with the agile42 Privacy Policy.
23- agile42 shall have the right, at its sole discretion and at any time, to change or modify these terms and conditions, such change shall be effective immediately upon posting to this webpage.
24- agile42 also reserves the right to cancel the competition if circumstances arise outside of its control.
How to Create a Kanban Board: A Practical Guide
/by Birge KahramanVisualization of your workflow is one of the primary practices of Kanban. A good Kanban board helps you track your progress and spot blockage points in your workflow at a glance. This transparency will enable you to improve your work stages, your workload, and your efficiency. However, if you search for Kanban board examples, most of the time they are not a good fit for your specific needs, especially if you are working in a non-IT area.
How to design your Kanban board
The very first Change Management Principle of Kanban states, “start with what you do now.” However, this can be overwhelming if you own multiple different types of projects and tasks.
Recommended for you: Kanban Foundations online course
It’s always a good idea to collaborate with your team members and utilize the group’s wisdom. A quick guided brainstorming session will help you gather the information you need, so you can reflect this on your board effectively and creatively. Keep in mind that the board will be an essential part of your working day, and it needs to be updated regularly by your team members. That’s why it’s crucial to come up with a board that is easy to understand and update. If you overcomplicate things, it will have a negative impact on efficiency and discourage your team members from using it correctly. However, don’t worry if you don’t get it perfect the first time: creating a Kanban board is an iterative process and you will be able to improve it over time.
Step 1: Ask the key questions
Before starting to lay down your daily tasks and processes, first, align on some key questions.
Step 2: Discuss the processes and tasks
After aligning on those answers, you can move on to the next step and start talking about your processes and tasks. Ask everyone to think and write about their steps after a task appears.
Depending on the nature of your tasks, you may have different steps. It will be easy if you draw a flowchart. If you are a customer care team, your flowchart is probably similar to this one:
Step 3: Group the tasks and start to visualize the process
You may want to group some of the steps under a single column. One thing to keep in mind, avoid back and forth travel of the tickets. They need to always flow in one direction. If you’re going to visualize the status of each customer request, your board can look like this:
You can choose different colors for different people and use initials or avatars to indicate the task owner. It’s also another Kanban practice to limit the work in progress (WIP), to finish the tasks at a certain pace without creating a crowd in specific steps. Monitoring the times of the individual cards will help you to improve your cycle and lead times.
Recommended for you: Make the process fun with the Kanban Pizza Game
If all your team members are doing their tasks in a similar pattern, it’s easier to visualize this. But if you have different responsibilities within your team, recommend grouping them. For example, you may use different “swimlanes” for different roles or subteams.
It’s also possible to create consecutive blocks, which is helpful if your tasks are more complex and need to be segmented.
It’s a good practice to indicate blocked items, for example with a different card color or with an extra marker, as indicated below.
You don’t always have to use columns and rows. You can get creative and design your board as it will suit you best. Let’s say it’s essential for you to see the distribution of the workload for equally important, parallel tasks. In that case, a pie chart may represent your workflow better than a table would.
Of course, you may combine them, too. If you can utilize physical boards or walls, it will give you more flexibility compared to a standard tool like Jira or Trello.
Download our free Miro templates to copy and modify for your needs.
Want to learn more about Kanban?
Kanban is a workflow management system that can help you visualize, streamline, and improve on your processes in the workplace. But there’s more to it than simply creating a board. Learn about it in our Kanban Foundations online course, or take a look at our webinars, which cover a broad range of topics on Agile, Scrum, Kanban, and just about anything else that relates to improving the workplace. There are also a number of agile42 training options, both in-person and remotely, which can transform the way you work:
If you need some more help getting your team started in Kanban methods, check out our Kanban Start-Up Package, which includes dedicated in-person coaching as well as Kanban training.
Join our free agile42 Community and gain access to thousands of agilists from all over the world to share experiences, challenges, and ideas. A safe and moderated community of like-minded people, who share a passion for all things agile – organizational culture, lean and agile methods, coaching & more!
Please do get in touch with us should you have any questions – we would love to hear from you.
Follow us on our social media platforms:
LinkedIn | Facebook | Twitter
Webinar: Human Factors in Agile Transformations
/by Amy BridgeAre we paying attention to the important human factors of coherence, psychological safety, and trust that connect us in the virtual and physical spaces where we gather? In July, agile42 coach Michèle Twomey, alongside our special guest Sonja Blignaut from More Beyond, explored this question and some of the hybrid models we are testing that enable essential human contact during agile transitions.
Michéle kicked off our two-part series on "Human Factors in Agile Transformations". In her video interview, Michéle gave us her take on Gerald M. Weinberg's statement: “all problems are people problems”. She also delved into what human factors one needs to consider in agile transformations as well as her sources of inspiration in her own journey of understanding human factors.
- Michéle Twomey
Next up, Sonja shared her insights on human factors within the realm of "complexity". She addressed the notion that, if we force too much change on people, we compromise their sense of coherence. Ultimately she believes we need to think about limiting the change in progress, the same way we limit work in progress within agile transformations. Listen to Sonja's video interview HERE.
Michéle and Sonja joined forces in our webinar on the 28th of July. The session raised many pressing issues we are currently facing, particularly around the expectation of always being available, always being online, and the important element of trust within the workplace. The audience had the opportunity to engage with their own questions, some of which included:
- Sonja Blignaut
If you missed out on the live session, we have the recording for you here - please feel free to share around with your network.
Join our free agile42 Community and gain access to thousands of agilists from all over the world to share experiences, challenges, and ideas. A safe and moderated community of like-minded people, who share a passion for all things agile - organizational culture, lean and agile methods, coaching & more!
Please do get in touch with us should you have any questions - we would love to hear from you.
Follow us on our social media platforms:
LinkedIn | Facebook | Twitter
Part 2: Human Factors in Agile Transformations
/by Amy BridgeOur long-time partner, Sonja Blignaut from More Beyond, shares her insights on human factors within the realm of "complexity". She addresses the notion that, if we force too much change on people, we compromise their sense of coherence. Ultimately we need to think about limiting the change in progress, the same way we limit work in progress within agile transformations.
Watch the full interview below:
Watch the recording of Sonja's webinar on "Human Factors in Agile Transformations".
Gerald M. Weinberg said, “all problems are people problems”. What do you make of that statement?
I think the best answer I can give is my favourite answer in complexity, and that is “it depends”. I don’t think we can remove context from that question. The reality is, that both the people as well as the problems are entangled in many different ways we can’t fully understand.
So, I will counter with another quote by W. Edwards Deming who said: “85% of the reasons for failure are deficiencies in the systems and processes rather than the employee”. He then continues to say that the role of management, therefore, is to change the process rather than badgering individuals to do better. I really like that because it brings together the idea of people and the context, the systems and processes they are embedded in, and how they are co-creating problems rather than just saying “it’s all about the people”.
What human factors does one need to consider in agile transformations?
In terms of the human factors that we need to consider for agile transformations, I think there are many, however, I will highlight a few and in our webinar, we will discuss more. Firstly we need to consider the anxiety that many people experience when we force too much change on them. It’s a bit paradoxical how we relate to change. Sometimes we seek out novelty and change and other times when it is forced on us, it creates a lot of anxiety and I think sometimes we forget about that.
One of my favourite frameworks to help me think through the human aspects of change is by Aaron Antonovsky. He created a framework called “individual sense of coherence”. There is much evidence that this has a strong relationship with the collective or organisational resilience. So he talks about three factors that make up an individual sense of coherence, which in essence means that individuals could feel that their internal &external worlds make sense.
The first factor is “comprehensibility”:
The second is “manageability”:
The third one is “meaningfulness”:
I think what happens very often is if we force too much change on people, we compromise their sense of coherence.
What is the role of decision makers in the context of an agile transformation?
From an organisational perspective and considering change in agile transformations, I think the role of an organisation and the decision-makers is to create environments and conditions where people’s sense of coherence can be maintained.
One of the things that I’ve noticed in many of the companies I have worked with, is that we don’t consider from an upstream perspective the impact of our decisions and the amount of change we put into the system, downstream. Very often an executive would say: “but I’m only driving one project”. But that one project, with all of the various silos that are involved, comprises a huge amount of change downstream, for the people who are at the receiving end of this. So I feel we need to think about limiting the change in progress, the same way we limit work in progress.
What have been your sources of inspiration in your own journey of understanding human factors?
I am naturally a curious person, so I draw inspiration from multiple places. However, in general, my main source of inspiration is the various theorists and thinkers who work in the field of complexity. So I tend to see everything through the lens of complexity.
Then also anthropologists like Gillian Tett and Aaron Antonovsky, and the field of systems psychodynamics and how social-technical systems work and all the various unconscious processes that happen there. And finally, my latest area of interest comes from biologists and how they are starting to look at flow and then also from the world of sports coaches.
So as you can see I’m drawing from multiple places and I look forward to seeing you at our webinar.
Watch the recording of Sonja's webinar on "Human Factors in Agile Transformations".
*Click here to read Part 1 blog post*
Part 1: Human Factors in Agile Transformations
/by Amy Bridgeagile42 coach, Michéle Twomey, kicks off this two-part series on "Human Factors in Agile Transformations". In this video interview, Michéle gives us her take on Gerald M. Weinberg's statement: “all problems are people problems”. She also delves into what human factors one needs to consider in agile transformations as well as her sources of inspiration in her own journey of understanding human factors.
Watch the full interview below:
Watch the recording of Michéle's webinar on "Human Factors in Agile Transformations".
Gerald M. Weinberg said, “all problems are people problems”. What do you make of that statement?
Just last week in a call someone mentioned: “We the people are the greatest obstacle to our change journey”. And yes, the problems seem to appear or become visible between people. This “between people” is how we connect and relate to each other; how we engage and collaborate with each other; how we think and communicate our thoughts with each other. So the space between what’s communicated both verbally and non-verbally and what is heard, perceived, understood, and interpreted on the other side, is what’s interesting.
The quality of this in-between space strongly depends on the connection to self. My self-awareness of what am I bringing into this space is tremendously important. So I believe that the space in between is where the potential lies and all possibilities are people possibilities.
What human factors does one need to consider in agile transformations?
Well, humans have different needs and values, but fundamentally people thrive when they belong and are part of a greater shared purpose, are given autonomy and an opportunity for mastery. So in an agile transition, an interesting question to explore is: “how are we intentionally creating and holding spaces for people to connect and relate to the why of an agile transition, to engage and collaborate towards a shared purpose through an agile transition”.
Now more than ever, we should be paying attention to how digital processes and electronic communication tools are reducing the shared experience of the “in-between spaces” where possibilities are born. See when I connect with you remotely through a screen or as an avatar, I no longer share an experience with you in a physical space. I am not able to shake your hand - not just to physically shake your hand but to be able to sense energetically who’s inside that hand. All of this information I believe - all of this auditory, tactile, energetic information is what contributes to the psychological safety and trust between people.
What have been your sources of inspiration in your own journey of understanding human factors?
My greatest inspiration has been the “gestalt” approach. “Gestalt” meaning “form” or “shape” and “gestalt” sees humans as more than brain and intellect, so connecting mind, body, and spirit energy and also an awareness of energy between people and the possibility of what forms and shapes might emerge in that energy space between people.
This relates to another inspiration from Dr. Gabor Maté and his work. Where he speaks of people as an embodiment of creative adaptations from past biographical experiences. So knowing self, being connected to self, and being very aware of what are my defenses, what are my triggers, and what am I bringing into this space between people is an important factor when connecting with others around me.
There are some key themes between “gestalt” and agile transitions that speak to me and one of them is taking personal responsibility as well as the here and now and focusing on how we show up and the quality of how we show up in a space between people.
Watch the recording of Michéle's webinar on "Human Factors in Agile Transformations".
*Click here to read Part 2 blog post*
Webinar: Dave Snowden on Digital Transformation
/by agile42June was all about "Digital Transformation". agile42 coach Martin von Weissenberg, alongside our special guest Dave Snowden, Founder and Chief Scientific Officer at Cognitive Edge, discussed the way agile and digitilisation are intertwined, and why it’s misleading to think of digitalisation as a one-time “transformation”
Martin got Part 1 underway with a video interview exploring what is a digital transformation and why it is necessary. Delving also into the organizational implications of a digital transformation.
- Martin von Weissenberg
In Part 2, the creator of the Cynefin framework and thought leader within complexity science and knowledge management, Dave Snowden, explained the role Agile plays in the context of a digital transformation & the organizational implications thereof. He also examined the social human impact of such changes.
On the 23rd of June we were treated to a thought-provoking webinar hosted by South African based agile42 coach, Peter Hundermark, along with Dave and Martin. The audience had the opportunity to ask their pressing questions in this Q&A-style panel discussion. Some of the questions covered included:
- Dave Snowden
If you missed out on the live session, we have the recording for you here - please feel free to share around with your network.