How to spice up your Scrum using Improv?

/by

Have you ever been part of a great team? A team that made you love going to work every day. A team that encouraged you to accomplish goals that you thought were near impossible.

Have you ever been part of a team from hell? A team with constant conflict and disagreements. A team where everyone was too afraid to speak the truth.

In his book “The Five Dysfunctions of a Team”, Patrick Lencioni refers to trust as a foundation and key ingredient to high performing teams. He also indicates, “Teamwork begins by building trust. And the only way to do that is to overcome our need for invulnerability.”

Improv is a great method that allows us to overcome our need for invulnerability. It allows individuals to naturally become more aware and vulnerable, which helps to build a stronger bond of trust. As defined by Wikipedia, improv ‘is the form of theatre, often comedy, in which most or all of what is performed is unplanned or unscripted: created spontaneously by the performers. In its purest form, the dialogue, action, story, and characters are created collaboratively by the players as the improvisation unfolds in present time, without use of an already prepared, written script.’

WOW, unplanned and unscripted.  How often do our Scrum teams encounter challenges like these and yet they struggle to respond or move forward? Many of us think that we can’t do improv. We panic because we don’t know what to do or say. However, improv helps teams to build key skills – many of which align with the Scrum principles:

  • Courage – improv encourages individuals to come out of their comfort zone and to take risks
  • Openness – improv fosters collaboration and trust
  • Respect – improv supports the notion of accepting and building on others’ ideas
  • Focus – improv reinforces the act of staying present and listening effectively on both a verbal and an emotional basis
  • Commitment – improv fosters commitment from team members to have each other’s back

Many principles that actors live by are the same principles that a high-performing agile team should live by. As stated in the Agile Manifesto values, priorities should be placed on responding to change over following a plan and on individuals and interactions over processes and tools.

Similarly, improv can also be used in an agile environment. Here are some examples of ways which you can apply improv to help your team, organization, and yourself:

  • Has your daily stand up become stale and boring? –  Revitalize this ceremony with spontaneity using improv.
  • Stuck in a meeting on a Friday afternoon with low energy and disengaged participants? – Recharge the energy levels with a dose of improv.
  • Does your team have a working agreement? – Use improv to form team agreements (e.g. how do we handle failure? how do we celebrate learnings?).
  • Is psychological safety an issue in your team?  – Introduce improv before a retrospective to help create an environment of “one team”.
  • Forming a new team? – Help team members build personal connections by learning about each other through improv.

The list is endless but most importantly, have fun doing it. Also, just like any other exercise, make sure the teams retrospect and apply the learnings to become a high performing team!

For more improv game ideas, click here: https://www.slideshare.net/SunnyDhillon5/spice-up-your-scrum-with-improv.

If you’re interested in learning more about Scrum and Improv, you can email me at [email protected].

Introducing Agile to Government: How the most amazing LEGO City was built using Scrum?

/by

The answer is *drum roll*… a ton of fun and the creation of the most amazing LEGO city ever!  

When and where did this event take place and who were these 70 City Planners?

This event took place at the Spring Municipal Information Systems Association (MISA) Conference in beautiful Langley, British Columbia. Note: A big thank you to everyone from MISA who participated, and for the invitation to introduce Agile to the municipal government.

The MISA LEGO city had all the features and necessities of an ideal city –  an airport, a power plant, a hospital, a fire hall, fire engines, and even a pub for all of the LEGO people to kick back after a long day in LEGO city! But it didn’t end here. Not only were there a school, a library, and a civic center for the arts, there were also roads, sidewalks, street lights, and power hookups to all of the buildings. Sounds amazing

So how was such an incredible LEGO city like this get built in less than 3 hours?

The answer lies in Agile.

After an overview of Agile methodology and iterative/incremental delivery, the 70 City Planners got right down to business – to learn and experience Agile concepts by building a functioning LEGO city. More precisely, experience Agile at scale with a single backlog of work ordered by the Product Owner team.

The first steps needed to create the MISA LEGO city included the following:

1. Form 9 cross-functional teams

2. Create a shared backlog of stories, and agree on the priority deliverables for the LEGO city i.e airport, firehall, bar/restaurant, parks, etc.

3. Determine a shared Definition of Done –  an agreement across the teams outlining how the teams will know that a deliverable is completed i.e buildings are integrated (power, roads, streets), and quality criteria are met (all buildings must be sized to accommodate a typical LEGO citizen)

The First Sprint: What was done and what were the learnings?

Armed and ready for the first sprint, the teams were off and running. In total, two energy-packed, highly creative, and jubilant Sprints/Iterations were carried out. All 9 teams had done the following per sprint:

i. Sprint Planning: Plan what to build [Duration: 5 minutes] 

ii. Sprint: Build deliverables to the Definition of Done [Duration: 10 minutes] 

iii. Sprint Review: Inspect what the teams have delivered and gather feedback from the attendees (primarily, Product Owner) to adapt the plan for the succeeding sprint  [Duration: 15 minutes] *** The focus is on the product

iv. Retrospective: Inspect how the teams collaborated and performed and identify areas for improvement [Duration: 10 minutes] *** The focus is on the process – the way in which the teams are working together.

The first sprint allowed the teams to uncover some invaluable learnings:

1. Teams worked independently of each other 

  • The 9 teams picked up one story each
  • There was little conversation and engagement between teams
  • There was little or no integration between deliverables

2. There was almost no discussion with the Product Owner

Outcome: During the Sprint Review, although the Product Owner was pleased with the progress, nothing was accepted. Why? Due to lack of integration (Learning #1) and unclear initial requirements from the Product Owner (Learning #2), the stories were not completed.

The Second Sprint: Based on learnings from the initial sprint, how did things changed?

Armed with the learnings from their first sprint, the teams set out to tackle Sprint #2 and the changes that were made had a significant impact on the outcome.

1. Teams worked together

  • A 10th story was started and almost done
  • Teams engaged with one another, which produced much more value than if they had worked alone
  • The LEGO city was integrated and functional

2. Teams negotiated with the Product Owner over the acceptance criteria and deliverables

Outcome: There was a clear prioritization of the backlog, and all 9 stories were completed while meeting the Definition of Done.

Through this simulation, teams were able to experience self organization. They learned how to plan and organize tasks during the Sprint. While facing the pressure of a time-boxed sprint, they also learned to communicate with each other and to focus on the sprint goal as an integrated solution. Finally, teams learned to measure their performance and to make improvements. However the greatest takeaway for these teams was the realization that working on projects together can involve lots and lots of fun as well as laughter.

To all the MISA LEGO City Planners – congratulations on building an amazing LEGO City!  You have definitely raised the bar on LEGO City planning!

Are you interested in running a Scrum simulation at your company, for more information contact us by clicking here.

Siamo presenti agli Italian Agile Days 2018

/by

È Brescia la sede della quindicesima edizione degli Italian Agile Days 2018 e noi non potevamo mancare al tradizionale appuntamento novembrino della comunità Agile italiana. Contribuiamo come sponsor e ci potrete trovare in giro per la location gentilmente offerta dal Dipartimento di Ingegneria dell’Informazione dell’Università di Brescia.

Alessio Bragadini presenterà Lontano dagli occhi, lontano dal cuore (Trucchi Agili di sopravvivenza per team remoti) in cui si parlerà di team distribuiti usando anche l’esperienza della squadra di agile42. Perché il lavoro remoto è meno semplice di come appare e, così come Agile, richiede un investimento culturale.

Leading and Lagging Indicators: What is the right way to measure performance?

/by

“If you can’t measure it, you can’t improve it.” – Peter Drucker

The reason why we measure our own performance stems from the believe that there is room for improvement. Knowing that you are “doing something” is not enough. Instead, you need to know what you are “doing wrong” and what you are “doing right”. If it’s wrong, stop. If it’s right, continue.
This is where leading and lagging indicators comes into the picture.

A leading indicator is a predictive measurement that can be used to influence change, whereas a lagging indicator is an outcome measurement that can only record what has happened.

A classic example is driving sales to your ecommerce store. What measurements come to mind? Conversion rate? Website traffic?

What is a lagging indicator?

Conversion rate is a lagging indicator because it’s an outcome of what you had done to drive sales (e.g. running ad campaigns). For clarification, conversion rate is the percentage of visitors on your website who decided to make a purchase. You take the total number of website visitors who made a single purchase and divide that number by the total number of people who visited your website. (Kissmetrics) Outcome-based metrics, such as conversion rates, are easy to measure because the numbers are readily accessible. As a result, we find ourselves heavily focused on measuring outcomes.

The benefit of measuring a lagging indicator is the ability to track progress. If your conversion rate is falling, you know immediately that you aren’t driving sales to your store. The downside of measuring a lagging indicator is the fact that it is an after-the-event measurement. This means you cannot use take this measurement to influence the future.

What is a leading indicator?

On the other hand, website traffic is a leading indicator because it can help to predict how likely you are in driving sales to your ecommerce store. The assumption is that the more traffic you receive, the higher the probability that people will purchase from your website. Given this insight, you would focus on activities that can increase your website traffic and ultimately contribute to overall sales. Such activities can include running ad campaigns or publishing content on different social media channels.

The benefit of using a leading indicator is the ability to adjust your course. For instance, if you decide to run ad campaigns on different channels (e.g. Facebook, Linkedin, Google, etc.), you can track which channels are driving the most traffic to your website. Based on this information, you can adjust your initial decision by redirecting your focus on selected channels. However, do you see any problems here?

Let’s say you decide to focus on running Facebook ads because it drives the most traffic to your website. It’s great that you’ve managed to increase your website traffic, BUT did your conversion rate increase correspondingly? This poses two problems:

1. Taking actions that affect the leading indicator but not your end goal

Just because Facebook ads are driving more traffic to your website, this doesn’t mean more people are purchasing your products. On the other hand, although LinkedIn ads are driving less traffic, the traffic it directs to the website may result in higher conversions. If you end up allocating your entire budget to Facebook ads, then you’re missing out on sales opportunities.

2. Believing that the leading indicator will result in the achievement of your end goal

The observation that increasing website traffic will lead to more sales is an assumption. You can have more people on your website, but this doesn’t guarantee that they will buy your product. Instead, sales can be affected by other factors such as the loading speed of your website; this raises the question as to whether or not website traffic is a valid leading indicator. Consequently, people shy away from the use of leading indicators because it takes time to assess their validity.

What is the right way to measure performance?

Leading and lagging indicators go hand in hand. In order to measure your sales performance, you need to measure both your conversion rate and website traffic. If you rely solely on conversion rate, how can you identify the actions that you need to take in order to increase sales? Contrarily, if you rely solely on website traffic, how can you know that you are indeed driving more sales? As a result, a lagging indicator without a leading indicator means that you lack clarity on how an outcome will be achieved and miss early warnings on whether or not you are moving towards your strategic goal. Likewise, a leading indicator without a lagging indicator means you lack confirmation on whether or not you are indeed achieving your end goal.  (intrafocus, Lead and Lag Indicators)

Presenting at the Regional Scrum Gathering South Africa 2018

/by

The South African Agile community meet once again in Durban on November 8-9. agile42 is happy to sponsor and support SUGSA, the Scrum User Group of South Africa that organizes this and other wonderful events.

I will present the talk Leading in Complexity together with Don Gray on Thursday 8th and Breaking Bad Scrum with Faye Thompson on Friday 9th.

Some notes about Leading in Complexity. We live in a world characterized by uncertainty, volatility, chaos, and ambiguity. Which tools do we need to shift a system? How can we use the system’s inherent properties to shift patterns of behavior to a more suitable fit for function? Join us in this workshop and experience the answers!

Canceled software projects litter the landscape like the galleons in the Graveyard of ships. Projects escaping the graveyard resemble Frankenstein. They lurch, not quite dead, but not that useful. Wrecks happen not due to lack of will, character, or effort, but due to insufficient skill in rapidly-changing conditions.

In today’s complex, fast-paced development environment, leaders need different tools to shift the systems wherein they work. In this workshop, we use the ABIDE mnemonic to navigate system properties. We look at how these properties have an influence on the system and how we can start to use them to shift behaviors, and create new patterns.

Motivation to Get Better

/by

Zingat.com started operating in cooperation with Doğuş Group and REIDIN in 2015. Zingat.com is a reliable real estate information and marketing platform that brings together real estate professionals and individuals under the same roof with accurate and comprehensive reference information by adhering to the concept of high quality service and transparent information.

What was the need?

Since Zingat is in a highly competitive business and being agile is the only way for them to be responsive to the market needs, they have been using Scrum and agility practices for a long time. Initially, there was only one team of four people who created the product “Zingat” from scratch. Since then the business has grown tremendously and as a result, the number and size of teams has grown. Currently there are 4 teams who are getting continuous requests from internal customers and external customers.

As we wrote above that they have already been applying Scrum practices, they were facing challenges and difficulties, so they decided to get coaching support. It was at this time that Zingat’s CTO and Product Director came across our blogpost Scrum Antipatterns and thought that we were the right partner to support them. We offered them our Team Coaching Framework which is a revolutionary initiative by agile42 to speed up the team learning process and performance.

Creating Transparency and inspection

There are a lot of coaching tools you can apply to teams but since every team is unique and needs are special, we started with team assessments. This enabled the company to see what was missing and get a clear idea of the current status of the individual teams. In the assessments, we discussed with the team members how well they were able to turn agile principles into practices and also how well they were they are as teams. The results were self reflection of the team members so they were able to see and decide what actions needed to be taken. This was not a top down instruction, but instead bottom up commitment from team members.

Every team had different improvement areas but in general below were the initial findings.

Technical Excellence

Due to the complex, adaptable nature of software development, teams work with a lot of unknowns. This means that even with infinite planning and analysing, teams will always be making some assumption of how that software will be used in the future. The software teams were in need of perfect “analysing” within long hours of meetings before taking the items into the sprint.

Sustainable Pace

The productivity and cognitive abilities of a team decreases with overtime, so Agile always promotes sustainable pace of development. Sustainable development also means catching an average productivity in terms of Sprint outputs. What we realised was, team had the opposite of this criteria. Agile teams were in need of clarified backlog items to include in the Sprints. Therefore, they had long hours of technical review and analysis before sprint planning meetings. Most of the time, Sprint backlogs were not ready according to team size although it was an experienced team. Sprints could not be started and a few days of breaks were decided until the backlog items get ready for team. The rhythm of the productivity was not predictable.

Business & development team

The Agile Manifesto describes a customer who is engaged and collaborates throughout the development process. This makes it far easier for development to meet the needs of the customer. The case was customer involvement was lacking through whole the sprint events so that team members were in ambiguity to be clear to start the items.

Customer satisfaction

There was not a regular feedback mechanism between Scrum team and business partners, team had the intention to do their best but lack but they generally were able to verify customer satisfaction  after they deploy it.

Changing requirements

It took a long time for a requirement to be clear enough this sometimes prevented the teams’ capability to pull the next most valuable item. And since it took a long time before entering the some more valuable items were already in the que to be pulled by the team.This created a tension between Product owners and development team and was damaging trust in the Scrum teams.

What areas did we work at ?

Leadership level

The leadership team was aligned on the critical problems to be addressed and the desired cultural change. We had a backlog of leadership items to be worked on. One to one coaching was one of the achievements that implemented according to misalignment inside leaders.

Team level

  • New teams were formed including testing capability to make them able to deliver without dependency.
  • Agile principles emphasise face-to-face communication wherever possible so the first thing that we asked them was to place every team member together. Scrum teams need to be self-organising and this starts with how to organise their communication at team level, so a Working Agreement was written how to maximise benefits of co-location. That agreements were live and it is up to them to update whenever needed.
  • Yet Scrum supports cross-functional, self-managed teams in which individuals help each other in completing the tasks. The ownership of completing user stories lies not with any one individual but with the complete, collective team. So assigning user stories to individuals were stopped and team started to take collective ownership of Sprint backlog items. Teams started proper daily stand ups to give daily decisions and their progress in the Sprint. 
  • To be able to support sustainable pace and increase Product Backlog readiness firstly key stakeholders were informed about how teams were working to develop their requirements and how they could contribute the process. They started to attend to review meetings to give feedback about Sprint outcomes. Secondly, teams started to perform regular backlog refinement meetings to gather data, discuss and split backlog items to support the Product owners backlog management.
  • Previously retrospective meetings were held in large groups with the attendance of whole development team. Now they started to perform this meetings in the new formed stabile Scrum teams which allowed environment for every member talk (even the silent ones) and give more teams decisions and actions. This helped to improve team spirit and trust.

Rediscovering Scrum

  • Although Zingat has significant experience with Agile practices, to take everyone on the same level and page took 2 days of Scrum training.  There were  a lot of discussions , questions from the teams it was realised that some practices were misunderstood and some basic Scrum activities were not done properly. People were thinking that Scrum needed to solve all the problems. So it was made crystal clear that Scrum is a framework that helps manage and control the process and they can’t  benefit from it if you break the fundamentals and they need to transparently talk about the issues and find solutions for the problems one by one. Scrum provided the necessary transparency, inspection and adaptation. Now after having the aligned Agile knowledge teams were invited to execute the Scrum rituals as it is written in Scrum guide.
  • There needed to be someone to take care of Scrum process and support teams in their agile journey, so the Scrum Master role was introduced and a volunteer took the Scrum Master role in the organisation. They had the alignment of Agile knowledge so that every team member was ready to evolve. The Scrum Master, who was willing to improve Agile behaviour inside the organisation, was coached and mentored by agile42 coaches to remove impediments within the organisation. 
  • There was also some confusion about Scrum roles and organisational roles which were preventing the Scrum teams’ self organisation and ability to give decisions.The responsibilities and authority was discussed among management and Scrum team and alignment was secured in the organisation.

What are the achievements?

The feedbacks from stakeholders and employees have been largely positive. Here’s a selection.

«Although teams and team members had experience in practical application of Scrum and Agile frameworks, teams were not aligned for the correct application of scrum.»

«There were disputes on definition of team. Now there is a clear understanding of definition of team and self-organisation.» 

«Before agile42 coaching support, Scrum was considered to be set of nothing but rituals. Now team agrees that although rituals (dailies, planning meeting etc) are required, the most important thing is the philosophy behind it.»

«Product owners were acting as the customers of development team. And vice versa. Now they are aware that Product Owners and development teams are indeed one team that run towards one goal.»

«Scrum teams used to have stories that are exceeding their capacity so that they could not manage to catch their Sprint goals. Now with the help of coaching support, they are aware about their capacity and make the planning accordingly.»

«ScrumMaster role has provided teams to better define and solve their conflicts.

«Teams started to use shared workspace.This change dramatically improved their  collaboration and communication inside the team.»

«Every company has inconsistencies which is unique to it. agile42 taught us the Scrum framework very well but on the other hand, our requirements were defined for further solutions by diminishing the uncertainties.»

«Solutions and required processes were defined by teams by working closely.»

«“The roles and responsibility” definitions were one of the conflicts inside the teams. Every role were studied with owners and the rest of the team so that respect and trust can be built.»

«Teams had honest and genuine support through all processes so that a more healthy way of working was built.»

«We learned transparency is one of the unshakable pillars of Scrum so we are trying to build a transparent medium. Team members are trying to solve their problems by facing openly with each other.»

«DOD has provided a common language for team members so that Sprint outcomes is now in a better quality.»

«Using Time Box has really worked for us to hold more productive meetings.»

«Teams are now have a better focus on their Sprint Goals.This has raised productivity on the other hand reducing complexity.»

«In our previous model of work, Scrum teams had no knowledge about why they are doing the Scrum rituals. Now they are conscious about what is Scrum and its framework.»

What were the highlights for the company?

  • A full time ScrumMaster is needed for Scrum teams to better operate and for the organisation to improve incorporation of Agile mindset.
  • Team agreements are crucial when self-organising therefore teams need to define their way of working as soon as possible to be visible for everyone.
  • It is a long journey for people to be a team and it takes a minimum of 6 months for people to understand and explore each other. One of the requests for us was not to change team members unless they are forced to do that.
  • For a company to be agile, the culture or mindset should be changed accordingly. In Zingat, leadership is quite aware that agility is not gained only on the team level, it is also management responsibility to be in this mindset. There are some key elements that the leaders need to support their teams, by changing performance review systems, or providing Scrum teams a place to co-locate(as teams are small) so crucial actions can be achieved by the support of the leadership team. Our touching points had its impact with the help of leadership and will continue if the leadership preserves this focus.
  • Documentation was one of the long arguments when we worked with teams. Most of the companies has a judgement about documentation when working Agile.The Manifesto for Agile Software Development values “working software over comprehensive documentation”. This core value asks us to think about how much and what kinds of documents are needed and when they need to be written.The best documentation is the simplest that gets the job done. We don’t need to create a five-page document when five bullet points will do. We need to document only enough to provide a useful context. To determine what is truly the minimum amount of documentation required in Zingat, we explored their intent to use a “Definition of Ready” document. Their needs are more explicit and actionable now that triggered a fresh new start for Agile teams to produce better outputs.
  • The structure and organisation of Scrum events should be structured and has a rhythm so that culture starts to change with the help of more communication and collaboration.

Conclusion

Is everything perfect yet? No, of course they face challenges, ups and downs but this does not stop their efforts. Zingat is a company that has the consciousness of Agile values and has a spectacular vision to implement it at every aspect of company. By knowing that it is a journey they are eager and motivated to keep this continuous improvement spirit.

Quotes from Zingat Executives

«When I read the “Scrum Anti-patterns” article by Ebru Yalçınkaya, I realised that we actually have these anti-patterns on application of Scrum in the company, so I immediately contacted Ebru to see if we could work together. They have a very good background of agile and Scrum practices. Their approach on coaching was very smooth and thus fruitful. Very good team, highly recommended. Zingat is a very young and dynamic company that plays for the leadership in the industry. On top of strong product, technology and customer service we provide; being  agile across the entire company help us quickly reach our goals. Working with agile42 helped to get one step closer to our goals.”»

– Chief Technology Officer, Mehmet Erkek

«I would like to thank agile42 Coaches for their decisive and relentless support  during our agile journey. We manage to build a better way of working and smart process with your support.»

– Director of Product Management, Halil Uzundal

 

Exhaustion is Not a Status Symbol

/by

In her book, The Gifts of Imperfection: Let Go of Who You Think You’re Supposed to Be and Embrace Who You Are, Brene Brown shares her 10 Guideposts of Wholehearted Living. Number 7 on that list is “Cultivating Play and Rest: Letting Go of Exhaustion as a Status Symbol and Productivity as Self-Worth”. This resonates strongly with the 8th agile principle about sustainable pace. 

In the world of Scrum software development, it is all too easy to get caught up in pumping out user stories and increasing velocity sprint after sprint, but what does that type of hamster wheel mentality do to us physically, mentally, and spiritually? For that matter, what impact does it have on our products? Are we building fast things, or the right things? Are we making time to dream up big, new ideas and/or to build a cohesive team around our mission? 

“I didn’t leave work until 8pm.”

“I missed my daughter’s dance recital for this project.”

“I’ve been pulling 16 hour days for 2 weeks straight.” 

“I can’t believe she left as 5:30pm. I was still here for 3 more hours!”

“We’re going to make this sprint goal if it kills us.”

There is danger when exhaustion becomes a status symbol — for our organizational culture, our teams, and ourselves. There are specific risks of inadvertently creating a competitive exhausted culture within an agile transformation, and ways in which we can leverage the agile values and principles in order to mitigate those risks. We have to take the time to look inward, assessing our own attitudes and views about work life balance. 

The 8th agile principle says: “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”

Work-life balance is a buzzword that we throw around, but how often does the culture of an organization support exactly the opposite? Hero culture is rewarded, and our output is viewed as a measure of our worth on performance reviews. We set out to transform the world of work with agile and with Scrum;yet I’ve heard the Scrum sprint cycle described as a “hamster wheel” -an endless conveyor belt of backlog and sprint reviews that the developers cannot escape. This is not congruent with what we read in the agile values and principles. 

Here are some ideas to get you started:

  • Take the time to discuss what sustainable pace means for your team
  • Develop working agreements that address sustainable pace
  • Embrace estimation as a method to empower the team
  • Treat Sprints as a heartbeat, not a constant death march
  • Not only avoid but reject the hero culture
  • Speak up as team members and leaders
  • Evaluate the organizational processes and structures

I’m interested in inspiring a discussion about the pitfalls of a competitive exhausted culture, and how we in the Scrum community, even with the best of intentions, could be “accidentally responsible” for continuing to spin the hamster wheel. Although hero culture has been discussed before, if we have addressed our own potential culpability in creating it.  We need to make sure that the principles and practices of Scrum are being used for good, not for evil. 

If you are interested in learning how to create a sustainable pace for yourself, your team, and your organization, join me at the 2018 Toronto Agile Community Conference on Oct 30th for my talk on “Exhaustion is not a Status Symbol”. Explore how Scrum practices, used properly, can enable a sustainable pace.

Meet us at Agile People Sweden 2018

/by

We are happy to be at Agile People Sweden, a conference with a diverse set set of participants and speakers as possible: people from IT, Management, HR and other professions and people with different backgrounds from different parts of the world come to Stockholm between 23rd and 26th of October, 2018 to discuss ways of collaboration and interactions between people with different perspectives.

Keynote speakers will include Doug Kirkpatrick, Evan Leybourn, Fabiola Eyholzer and Dave Snowden.

agile42 will host and sponsor the coach clinic on the main day of the conference, Thursday October 25th. The coach clinic is a service for attendees of the conference, where attendees get free help from experienced coaches on any topic of their choice, and keynote speaker Dave Snowden will make an appearance as well. The sessions will be 15 minutes long, were the coaches are helping the attendees with their problems and questions. An attendee can extend the session if no one is in line waiting. Attendees can sign up for multiple appointments if one appointment is not enough.

We at agile42 wish to see as many of you as possible at the coach clinic! Sign up for the coach clinic on our board besides the clinic at the event, or drop in if there are free appointments. We are looking forward to meeting you, so come to join us at the conference. Remember to sign up fast, the appointments will be popular!

How we facilitated an all-hands retrospective for 60 people in three hours

/by

This blog post was a co-authored by Anita Siebold,  Pam Clavier and Lukas Klose. It is a short version that outlines the facilitation of a retrospective for 60 or more people. You can download the corresponding ‘how to’ guide, which includes a more detailed step-by-step guide, a planning checklist, and a closer look at lessons learned.

Setting the scene

Picture six eager DevOps pods, four enthused technical teams, five servant leader program team members, one Agile Coach, three intense hours and lots of coffee. This perfectly describes what our all-teams retrospective looked like.

All-team retrospectives (retrospectives that are attended by multiple teams, such as those of an entire program, or even organization) can be an important opportunity to inspect and reflect on how teams work together as a team of teams. It is also a chance to practice empiricism at a program level: be transparent, inspect, and adapt. We believe that mirroring scrum ceremonies at the program level can serve as an important success factor for organizational agility.

With only three hours and a room of about 60 very talkative and eager participants, we needed to be organized, focused and engaging. Here is how we did it:

Begin with the end in mind – know your purpose

We wanted to walk away from the three hour meeting with the following:

  • Three problem statements, with one or more proposed solutions (including acceptance criteria)
  • A focus group (+/- 5 people and a steward) for each problem statement

The focus groups should take each of the proposed solutions, converge them into a single approach and move that approach forward until the next all-hands retro.

Breaking down the retrospective into phases

We wanted to align our facilitation with the diamond of participatory decision making: diverge, discuss, converge. With so many participants, clearly we needed to do breakout groups, of which each would diverge/discuss/converge. We planned to use multiple and recursive diamonds (see illustration).

Phase I: Setting the stage

We started out with announcing the focus of the conversation (in our case: ”how can we get to ‘shippable’ every two weeks?”), followed by an introduction of the agenda and a crash course about using the diamond of participatory decision making. The crash course was to encourage and enhance inclusive conversations in break-out groups.

Phase II: Brainstorming and shortlisting problem statements

Then we asked the participants to do the following:

  1. Individually brainstorm a list of issues
  2. In groups of nine, consolidate, prioritize, and articulate a single problem statement
  3. Take turns in presenting the problem statement to everyone in the room
  4. As a whole group, shortlist and consolidate on a maximum of three topics

Phase III: Root cause analysis and solutions

After phase II, we asked the participants to gather around the shortlisted problem statements and self-organize into groups of five. The newly formed groups are asked to do the following:

  1. Select one of the three problem statements
  2. Create a poster for the chosen problem statement and provide…
  • a root cause analysis
  • a proposed solution
  • acceptance criteria

Once again, groups were asked to present their posters and feedback was provided by either

  • writing the feedback down on a sticky and attach to poster, or
  • putting a smiley sticker on the poster

Phase IV: Consolidate proposed solutions and drive implementation

At this stage, we called for a steward and a group of volunteers to take on one of the three topics. The purpose was to take this offline (in the weeks between retros), and follow up by

  • Consolidating the proposed solutions into a single way forward
  • Driving the adoption and implementation of the solution

Top 4 Learnings to take to your own retrospectives

Three months after the retro we had mostly good feedback, concrete actions taken and… lots of lessons learned. Here are some recommendations:

#1) Be very clear about the topic – When we presented the question to frame the conversation, not everyone was on the same page about what “shippable” meant. We cut the discussion about this short to stay on schedule, but this possibly affected the engagement and maturity of the subsequent conversations. Our take-away was that the focus of the conversation needs to be crystal clear. If it is even slightly ambiguous, it can become a big time-back-hole.

#2) Test your PA system ahead of time – The venue did provide us with a PA system, but we did not test it ahead of time. Once the meeting started we could not use it because the volume button was well hidden in a closet. Now as facilitators we could project our voices, so we initially thought – not a big deal, but when participants started to share their views it was sometimes very difficult to hear them. At the end we found the volume button, but it costed us some time.

#3) Define acceptance criteria early on – Acceptance criteria can be a powerful technique to avoid misunderstandings and ambiguity. We found that defining the acceptance criteria earlier than later could really improve the applicability of the proposed solutions.

 

#4) Provide support after the retro – Provide visibility and product ownership and Scrum Master support to focus groups in the weeks after the retrospective.

This blog article is a short version that outlines the facilitation of a retrospective for 60 or more people. The corresponding ‘how to’ guide includes a more detailed step-by-step guide, a planning checklist, and a closer look at lessons learned. 

My first time at the agile42 Innovation Sprint

/by

What can I say more than just WOW! What a week! But first, let me tell you how I got to the Innovation Sprint in the first place. 

My name is Sofia, and I started working for agile42 Finland & Sweden in May 2018. My role in the company is Business Relationship Manager. My days are filled with customer related things, like conversations, finding appointments, offers and training / coaching bookings and of course many e-mails just to mention a few. 

In the beginning of my journey with agile42 learned many new names, e-mail addresses, phone numbers and colleagues from various countries. This is always what it is like the first days of a new job, right? What can I say, I was amazed. Everyone was sending nice welcoming e-mails and that made me feel very good.

Days went by and at some point I heard about the Innovation Sprint. We needed to book tickets and organise the journey to Thailand. Little did I know of what was going to happen during the week, but I felt exited! 

While visiting the Headquarters in Berlin, I got to be a part of the planning towards the Innovation Sprint in Thailand. The office team had already done a great job with the planning, so I mostly got to understand a bit of the program, what the days were going to look like, what would happen during the week and so on. At that point I realised that there is much to think about to make an Innovation Sprint come together.

All came together very well, and we arrived in Thailand. The first morning in the meeting room I was just standing with my mouth open, watching people come into the room, like WOW!

The week went on in full speed, we got to know each other, we got introduced, and most importantly, got to work with each other. All faces got names and the big picture became clear to me. Everyone was helping, explaining, answering questions, caring, sharing, supporting and questioning. This is the mix I like and appreciate. As a “newbie” I never felt outside, I never felt that I could not ask questions (even silly ones), I never felt like the “newbie” even tho I was one. I feel that the week made us all unite, both the colleagues who have already worked a long time together and for all the new ones. The new guys where taken in with open arms, we got a lot of useful information. We got support from each other and that gave me great value, and great support to my work. 

I remember looking around the meeting room where we were working all days and being amazed by all the knowledge, all the information, all the experience there was in the room. Everyone had their stories to share, and ways of doing things. A perfect match of people doing what they love. I am happy I got to take part of the Innovation Sprint so soon in my new career at agile42, it made sense to meet everyone at once, in the beginning. The step to ask for help and support is much smaller now, and I know that people know I am still new and learning, so the environment to learn and fail is comfortable to be in. 

I know that I am not the only one happy about this week, and many of my comments above also occurred during the week in Thailand. The work and fun balance of the week was very good, a big thanks goes to the office team for that! In the evenings there were dinners and other programs that made us connect on personal levels, not only work wise. What also gave my Innovation Sprint experience a good bonus was that I had the chance to meet all my colleagues families, whom were also welcome to this event.

At the moment I am just waiting for the next time to meet everyone again, to see my colleagues I do not see every day or week or month. We keep in touch via other channels, but it is of course not the same as seeing face-to-face.