Tag Archive for: agile

Scaling Agile Teams

We’ve been working with organizations for over 15 years and despite numerous existing frameworks and models, we’ve learned that there is no silver bullet when it comes to scaling Agile teams. Every context is different and complex. However, we believe that by applying Agile principles and some good practices, any organization can create a framework or model for scaling Agile teams: one that is best adapted to its respective environment and can grow organically. In this guide, we’ll describe a few best practices for scaling Agile teams.

Need help scaling? Join our upcoming Webinar: Implementing Agility at Scale, or check out our new training offering below.

What is “Scaling”? 

When we speak of “scaling”, we refer to any situation where more than one team is asked to work together to build a product or service to deliver value to the customer faster. With several teams involved, we face new challenges like the need for increased synchronization and improved communication. The following sections provide some good practices that allow us to address those challenges. In the following description, the assumption is that individual teams are working together using the Scrum framework including all of its roles, events, and artifacts.

Scaling Scrum Teams

What are Scrum Teams?

According to the Scrum Guide, “The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.”

The guide goes on to describe the characteristics of such a team: “Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how”.

The Scrum Guide further recognizes the challenge of scaling teams. “The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people”, it says. “In general, we have found that smaller teams communicate better and are more productive. If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.”

These “multiple cohesive Scrum teams” are the key to scaling. When you have multiple teams focused on the same product, their cohesiveness is reflected by the fact that they are small, cross-functional, and self-managing.’

Multiple Teams with Shared Artifacts

When multiple Scrum teams work on the same product, they should share the same Product Goal, Product Backlog, and Product Owner. Additionally, they must mutually define and comply with the same Definition of Done, since each team’s work needs to meet the same quality standards.

Product Development with Multiple Teams

When working with multiple teams, a Product Owner usually has more to do than one person can handle. In this case, it may be a good idea to establish a Product Owner Team which consists of a few people who share the responsibility of managing the Product Backlog.

Another option is to nominate a Chief Product Owner who coordinates the interaction and collaboration of several Product Owners who work closely with different teams. In this case, the Chief Product Owner is responsible and accountable for maximizing the value of the product and ordering Product Backlog Items accordingly. They delegate some of their responsibility to other Product Owners.

The following paragraphs will explore practices and tools that help organize, coordinate, and synchronize multiple Scrum Teams.

Cross-Team Collaboration

An organization with multiple teams working on one or more products or services needs to ensure value is being delivered across all teams. Since the work of one team might impact other teams, dependencies need to be identified and managed. 

Visualizing the Workflow

A Coordination Board is a good way of visualizing work across multiple teams, as shown in the graphic below. 

The Coordination Board promotes cross-team collaboration in that it gives transparency to the work and a sense of accountability for the contributing teams and individuals. It also helps prioritize feature delivery, identify and remove dependencies and blockers, and coordinate activities between the teams. With the Coordination Board, we zoom out from the team level and focus on cross-team collaboration. Feedback loops between the Coordination Board and the teams’ boards ensure alignment among teams.

The Coordination Board Process

The Coordination Board represents an end-to-end workflow and lists any activities necessary to deliver value. This ensures that the right teams work on the right things at the right time. It visualizes the steps necessary for an item from idea to delivery to customers and beyond. Typical columns of the Coordination Board are qualification, planning, execution, and monitoring.

Each column represents one phase in the lifecycle of an item. Explicit policies should define the entry criteria for each column as well as the practices and interactions performed in each step. Visual clues can be used to convey additional information and speed up decision-making.

Limiting Work in Progress creates focus and ensures fast problem-solving. By using flow and business metrics, the progress of items on the Coordination Board can be measured and improved.

Product Owners can use the Coordination Board to formulate the next Sprint Goal or define a cluster of features for the next release. The results of each Sprint are then fed back into the Coordination Board.

Participants

Representatives from all teams and relevant stakeholders must meet regularly in front of the Coordination Board to share updates and manage dependencies and blockers. This includes Product Owners, stakeholders, and representatives of all Scrum Teams, depending on the context.

Cross-Team Sprint Planning

When several Scrum Teams collaborate in order to achieve a shared Product Goal, it is crucial for all of them to align themselves with a shared Sprint Goal which would bring them one step closer to the Product Goal. However, creating a detailed plan for getting selected Product Backlog Items done during the Sprint is best still conducted on a team level during the Scrum Teams’ respective Sprint Planning (along the lines of the Scrum Guide).

So how do we marry these two seemingly divergent ideas? We advise that when working with multiple teams, you should split Sprint Planning into different parts. This enables Scrum Teams to converge when overall alignment or planning is necessary and to diverge to work on a team level whenever possible. This allows every Scrum Team to hold their own Sprint Planning (parts 1 and 2), ensuring that they align with other teams on the shared Sprint Goal (part 0) and on which items will be tackled by each team (part 3).

Sprint Planning Phase 1: Alignment 

Purpose

In Cross-Team Sprint Planning 0, Scrum Teams align in order to ensure that they are all working towards the same Sprint Goal. Without alignment, teams may waste time on Product Backlog Items not part of the Sprint Goal or fall out of sync.

Therefore, the Cross-Team Sprint Planning 0 is a joint meeting attended by representatives from all Scrum Teams, allowing them to collaboratively define why the Sprint is valuable, which Sprint Goal to work towards, and which Product Backlog Items each Scrum Team could pull in order to achieve the Sprint Goal.

Process

Product Owners propose how the product could increase its value and utility in the upcoming Sprint. Representatives of the Scrum Teams then collaboratively define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. Once the Sprint Goal is finalized, Product Owners share the top priority Product Backlog Items with the teams and final questions are clarified. The teams then pull the items that each Scrum Team wants to take to their respective Sprint Planning (Sprint Planning 1 and 2) and they collaboratively identify opportunities to work together in the upcoming Sprint.

Cross-Team Sprint Planning 0 needs to be completed before moving on to Sprint Planning 1 and 2, where each Scrum Team builds their Sprint Backlog and agrees on how the chosen work will get done.

Participants

Product Owners and representatives (e.g. Developers) of each Scrum Team.

Sprint Planning Phase 2: Teams Separate for Sprint Planning

Teams plan their own Sprints individually and internally after ensuring they are aligned with the overall goal (along the lines of the Scrum Guide).

Cross-Team Sprint Planning Phase 3: Alignment 

Purpose

At this point, Scrum Teams are aware of the Sprint Goal, have created their Sprint Backlog in Sprint Planning 1 and 2 and might have a rough idea of the Product Backlog Items that other teams have pulled. However, they are not aware of what other Scrum Teams have committed to.

Cross-Team Sprint Planning 3 is the opportunity for all teams to get a shared understanding of the items each Scrum Team has committed to work on in the upcoming Sprint. It is also an opportunity to commit to working together on particular topics when needed and to clarify how to handle any dependencies.

Process

Once each Scrum Team has held their respective Sprint Planning, representatives from each team come together in Cross-Team Sprint Planning 3 to share their Sprint Backlogs as an outcome of their Sprint Planning 1 and 2 by communicating the commitments of each Scrum Team.

They can also align and commit to collaboration for closely related items and conclude by starting the Sprint.

Participants

Product Owners and representatives of all Scrum Teams, depending on the context.

Mid-Sprint Collaboration

Once a Sprint has started, there are several opportunities for the team members to collaborate across teams: 

  • To resolve dependencies and remove blockers in a Scrum of Scrums
  • To collaborate with stakeholders on Product Backlog Refinement
  • To share knowledge and improve skills in Communities of Practice

Scrum of Scrums

When multiple teams are expected to collaborate and build something together, there will always be some challenges. These might include poor communication, misaligned priorities, or missing cohesion. Therefore, working at scale requires more frequent synchronization between teams and increased communication. This is where the Scrum of Scrums comes in.

What is a Scrum of Scrums?

The Scrum of Scrums is a meeting between teams that enables team members to connect better through frequent exchanges to be aligned on tasks and priorities. It is a vital tool to help manage or resolve dependencies between teams, such as when one team’s work may be impacted by another’s.

How to run the Scrum of Scrums

Each Daily Scrum within a Scrum Team ends by designating one member as an “ambassador” to participate in a meeting with ambassadors from other teams, called the Scrum of Scrums. The Scrum of Scrums doesn’t have to be daily, it could also be held once or twice per week or Sprint, depending on the teams’ need for synchronization.

The Scrum of Scrums proceeds as a normal daily meeting, with ambassadors reporting completions, next steps, and impediments on behalf of their team. Resolution of impediments is expected to focus on the challenges of coordination between teams; solutions may entail agreeing to interfacing between teams, negotiating responsibility, defining boundaries, etc.

The Scrum of Scrum will track these items via its own backlog, where each item contributes to improving between-team coordination.

Participants

Depending on the context, ambassadors may be technical contributors and/or each team’s Scrum Master.

Product Backlog Refinement

Purpose

Without a shared understanding among all teams working on the same product or service, the organization risks wasting effort by working on the wrong things or missing more valuable and important ones. 

Product Backlog Refinement improves the efficiency of the Sprint Planning meetings because it allows teams to clarify open questions and leverages the benefits of collaboration in prioritizing and capturing Product Backlog Items directly with stakeholders and the development team.

Process

Product Backlog Items are refined until they are ready for selection in a Sprint Planning event. Product Backlog refinement refers to the act of breaking down and further defining items into smaller, more precise items of value. Product Owners, Developers, and stakeholders collaborate to add detail, estimates, and an order to Product Backlog Items.

An overall Product Backlog Refinement with two or more Scrum Teams involved can be useful whenever it is necessary for shared understanding, to use alignment opportunities for closely related items, or when broader input or knowledge sharing is required.

Participants

Product Owners, Stakeholders, and representatives of all Scrum Teams, depending on the context.

Communities of Practice

Purpose

A Community of Practice’s goal is to share knowledge, improve skills, and advance the state of craft. Communities of Practice are intended to support individuals with specific professional needs by allowing space and time to share practice and knowledge. It is very gratifying to learn and share with a group of peers, who may have similar solutions to common problems or have found something else to work better for them.

Process

Participation in self-organizing Communities of Practice is voluntary. Membership includes only people who are practitioners of the same craft or skill. Management support is helpful; management participation or facilitation is generally not.

A CoP typically has periodic meetings. Meetings may have a default agenda, with specific topics depending on the type of activity taking place. Common activities include: sharing good practices and patterns, setting guidelines and standards for their specialty (e.g. UI standards), helping each other overcome challenges, establishing and maintaining knowledge repositories, doing research on emerging technology, or developing strategies for long-term improvement across the organization.

Participants

Agile organizations often form separate communities for Product Owners, Scrum Masters, testers, UI/UX specialists, analysts, and developers. Beyond that, every group of individuals who share professional needs can gather in a Community of Practice in order to share practice and knowledge. Members come from teams and departments across the entire organization.

Cross-Team Sprint Review

Purpose

The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. Scrum Teams present the main results of their work to key stakeholders and progress toward the Product Goal is discussed.

Cross-Team Sprint Reviews can be valuable when more than one team works on the same product or service and they benefit from greater visibility or if the business stakeholders are the same group of people for all Scrum Teams.

Process

Similarly to Sprint Planning, the Sprint Review can be divided into different parts when working with multiple teams: one Sprint Review per Scrum Team and one Cross-Team Sprint Review for all teams working on the same Sprint Goal.

During each Scrum Team’s Sprint Review (along the lines of the Scrum Guide), Product Backlog Items that are valuable for a larger audience of stakeholders are identified. Representatives from each Scrum Team then join the Cross-Team Sprint Review together.

During the event, Scrum Teams and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, participants collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities.

The Cross-Team Sprint Review is a working session and Scrum Teams should avoid limiting it to a presentation.

Participants

Product Owners and representatives of all Scrum Teams, depending on the context.

Cross-Team Sprint Retrospective

Purpose

The Sprint Retrospective is time set aside for a team to reflect on past events and behaviors and plan ways to improve the quality and effectiveness of its work.

Process

Similarly to the Sprint Review, the Sprint Retrospective is divided into different parts: one Sprint Retrospective per Scrum Team and one Cross-Team Sprint Retrospective for all teams working on the same Sprint Goal.

Once each Scrum Team has held its own Sprint Retrospective (along the lines of the Scrum Guide), representatives from each Scrum Team hold a Cross-Team Retrospective together that enables them to identify and address issues that cannot be resolved at the team level or that are valuable for improving collaboration and communication across teams.

The most impactful improvements are addressed as soon as possible. They may be added to the Sprint Backlog for the next Sprint and usually 10% of the Sprint capacity is allocated to address those improvements.

Participants

Representatives of all Scrum Teams, depending on the context.

Conclusion

The Scaling Framework described above is built on top and around a functioning Scrum Framework at team level. However, we have seen these principles and good practices work with established Kanban teams or a combination of Scrum and Kanban teams as well. 

We want to emphasize that the good practices for scaling agile teams described above are not to be seen as a prescriptive framework where you must simply follow all the rules to make it work and succeed.

On the contrary, we encourage you to apply the agile principles enriched with some good practices in order to create your own framework or model for scaling agile teams, one that can be most successfully adapted to your organization’s respective environment and that can grow organically.

Are you in the process of Scaling?

Scrum Alliance has launched a new certification to help you in this process. Certified Agile Skills – Scaling 1 (CAS-S1) addresses the most common challenges when it comes to scaling, including: 

  • What is Scaling and Why is it Necessary?
  • Approaches to Scaling (Principles-led, Practice-led, Pattern-led)
  • Principles of Organic Scaling
  • Introduction to Complexity and System Thinking
  • Value Delivery and Unnecessary Synchronizations
  • Organizational Culture and Decentralized Control
  • Scaling Patterns
  • Change Management in Scaling
  • The Role of Agile Coaches in Scaling
  • Scaling Case Study Deconstruction

The History of Scrum

Today, Scrum has become one of the most widely adopted Agile frameworks. It enables teams and organizations to deliver value iteratively and incrementally, adapt to changing requirements and foster collaboration and self-organization. The influence of Scrum extends far beyond software development, shaping the way teams approach complex work across various industries. But how did everything begin and what were the main landmarks along the way? Here is a brief summary of the history of Scrum.

Read more

Webinar: Why Technical Debt is an Opportunity

In software development, technical debt is a concept that reflects the extra development work that arises when we use quick or easy solutions. But the concept is useful beyond the world of software too. In the digital world, where new technologies and ideas are emerging just about every day, technical debt is almost unavoidable. So we need to know how to deal with it. 

Read and Watch

Everything I Needed to Know About Agile Product Development I Learned from Dark Souls

There are two activities in my life that have filled the years with a roller coaster ride of celebration and depression –  periods where I had to rely on grit and determination slogging through unending drudgery punctuated with moments of delight –  developing software products and playing Dark Souls.

I realize that not everyone who reads this blog may be familiar with the Dark Souls games. Luckily, I can sum it up with one image – the screen that players see more than any other:

A screenshot of the computer game, Dark Souls, with the text "you died" in bold red lettering across the centre.

Dark Souls has a reputation as a brutally challenging game. As I start playing Elden Ring, the latest game in the series, I’ve been thinking about what I’ve learned playing these games and how similar it is to Agile product development. Below are four of the things I’ve learned about Agile Product Development from Dark Souls.

1. It’s All About Learning From Your Mistakes

While Dark Souls may be unforgiving, it’s not a particularly complex game. Even the most challenging enemies have big tells for their attacks and are fairly predictable in their behavior. Despite how frustrating it may feel after the tenth time dying to the same enemy, the game’s developers want you to succeed. If you’re paying attention, each level teaches you how to beat it. Easier enemies teach you the skills needed to beat the harder ones. Every time you see the “You Died” screen, you should be asking yourself, “what did I do that got me killed, and what should I do differently next time?”

This might be the most important lesson in Agile product development that so few people learn. Most of the products we build are not simply copies of another product. We’re solving new problems or old problems in new ways. Missteps will happen. Success comes when we learn from those missteps and find an innovative solution.  

Related reading: How Dungeons and Dragons prepares you for being a Scrum Master

2. Take Small Steps

Nothing leads you into disaster like over-committing. In Dark Souls, a wise player will take the game one enemy at a time and always check their corners. This lets you re-evaluate your surroundings and take the best strategy for that moment, even if that strategy is to run back to safety to regroup and rethink.

Agile Product Development is no different. We take our development one small feature at a time. This doesn’t mean we don’t have a larger context in mind, but we also know that each completed feature could show us a fundamental flaw in our thinking. This gives us a chance to take a step back, regroup, and rethink.

Whether you’re playing Dark Souls or building a product, if you don’t want to end up in over your head, take it one small step at a time.

3. You Will Fail. Often.

While it is true that each failure is an opportunity to learn, that doesn’t mean that failure won’t hurt. Whether you’re throwing yourself at the same enemy for the 28th time or you bomb a feature you were sure would be a slam dunk, you will get frustrated and it will kill your motivation. The best players and Agile teams know how to recognize that frustration and recover from it. 

Find out what works for you to recover and re-energize. Do you need a break? A small win? Do you need the support of your team to rally and push through the problem? Too often, teams just resign themselves to the frustrating task, which rarely leads you to a successful outcome. 

4. Sometimes, Your Princess is in Another Castle

OK, I’m mixing game metaphors, I know, but the lesson holds. Sometimes hitting a wall in Dark Souls is an opportunity to double down and persevere. Other times, it’s a sign you need to go spend a little time tackling other challenges in another level. This can help you unwind the frustration, build new skills, and build up your character. You may find that when you come back to the challenge, it will be easier to overcome.

In Agile development, you will encounter technical challenges and business challenges. You may need to buckle down and work through them, but other times, turning your attention to other feature areas will help you make progress and get your team unstuck. Often, that shakes loose new ideas and new solutions. When you return to the earlier work, you’ll be armed with new ideas and a fresh perspective.

Conclusion

It may seem strange to compare two things that seem so different as playing video games and building products, but in the end, a challenge is a challenge. The ways we work through them carry over across our personal and professional activities. I hope some of these lessons resonate with you. 

Want to learn more about Agile? Contact us

Webinar | Agile Certifications: New Year, New Opportunities

While the Agile journey is exciting, it can be overwhelming. In this webinar, our senior coaches Daniel Lynn and Giuseppe De Simone help to give you direction on this journey. They explore the many options and agile certifications available to you. They outline the Path to CSP as well as the many other qualifications and experiences that can help you along the way. When mapping out your path, our coaches explain that you should be guided by what you want to learn and how you want to grow. 

Watch now | Agile Certifications: New Year, New Opportunities

Stay in the loop about upcoming webinars by joining our mailing list 

Meet your webinar hosts 

Daniel Lynn started his career as a software engineer and found himself passionate about developing products inside of Scrum. He is an experienced Agile Coach with a demonstrated history of working in the information technology and services industry. Daniel is passionate about what he does and helping others. 

Giuseppe De Simone is a Certified Scrum TrainerCertified Enterprise and Team Coach who is passionate about helping individuals, teams and organizations become more productive by embracing Agile values, principles and practices. Being an Approved Certified Agile Leadership and Path to CSP Educator, he is one of the very few in the world holding all the guide level certifications from Scrum Alliance. Giuseppe holds a Master degree in Electronic Engineering and started his career as a Software Developer. He became interested in how people can effectively work together and how teams can transform into an organism capable of delivering products and services which customers love. 

Browse the agile42 Agile Certifications

agile42 offers Scrum courses, as well as:

  • online Agile certifications;
  • Kanban training with certification from Kanban University;
  • ICAgile Agile Team Facilitation (ICP-ATF) and Agile Coaching Certification (ICP-ACC) training; and
  • Scrum Alliance Certified Agile Leadership training.
Agile Challenges

Eight Lessons We Learned in 2021

2021 was another unpredictable year. Although we seemed more prepared for remote working and different ways of doing business, there were, as always, some unexpected curve balls. COVID-19 variants, hybrid working arrangements, and cancelled Christmas parties, among many other challenges, made for an interesting year of work. If there is anything we can learn from the past few years, it is to expect the unexpected. There is always room to inspect and adapt. 

We asked you, our community, what your greatest agile challenges were from 2021 and what you learned from them. Here are eight of your biggest challenges, and biggest lessons, from the last year. 

If you fail to inspect, you fail to adapt

Having a plan and procedures in place allows you the opportunity to inspect and adapt. This is a vital step towards improvement. As Agile practitioner Jesper Ørting reminds us, “In sport, people train 99% of the time and perform 1%, but in business, we train 1% of the time and have to perform 99%, and we still expect it to work.” This begs the question: are we spending enough time planning, developing skills, and adapting? 

Scrum Master Riaan Johannes R reflects on how important having a plan was for his Program Increment (PI) Planning. “Face to face communication is already difficult with PI Planning, but doing this remotely is a nightmare,” he explained, “You need to not only have an agenda and a plan, but also facilitate via the tool you use and also know this off by heart.” 

Trust and openness can help to overcome uncertainty

When there is massive uncertainty, it can result in a lack of purpose, motivation, and cohesion among your teams. Scrum Master Floris Dafel experienced this. “I’ve learnt that a lack of purpose is like kryptonite to teams”, he said, “and it can be overcome by trust and openness. […] We did some trust-building team exercises that helped and also created our own vision where there was a lack of it instead of waiting for it. The challenges actually built a strong team in the end.”

Trust and openness

Photo by fauxels from Pexels

Change is a process and shouldn’t be imposed

For Agile Coach Matteo Betti, coping with change in a remote working environment was a massive challenge. They had the additional challenge of facing a massive reteaming. “I learned that you have to be patient and wait for the right opportunity to show things from different perspectives,” he explained, “Change should not be imposed. Scrum Master Daniel Palmisano shared a similar experience.“I learned that sometimes we have to be patient and let the people think about change and be willing to accept new ways of working,” he told agile42. 

During times of change, teams need time to embrace the process. The best thing a leader can do is communicate what is expected across the team, be open to new ways of working, and be patient.

Take action after a retrospective

While retrospectives can be a great opportunity to look back on a sprint and make plans to improve in the future, it’s important to make sure they’re geared towards real, actionable change. “Retrospectives can be great and insightful but the pitfall is that if nothing changes teams tend to say, ‘this is all useless!’,” shared Facilitator Valentina Sandi. “So Inspect – Adapt – ACTION”. A successful retrospective ensures action instead of running into the same issues every time.  

Make sure the team has a shared understanding of your goals 

When undergoing change and transformation, especially along your Agile journey, it is crucial that everyone shares the same understanding of both the process and the goal. “Our biggest fail this year was assuming that everybody on the team and organisation has the same understanding of what Agile and Scrum means,” reflects Scrum Master Claus Trohl. “We are now rectifying this by more widespread communication throughout the organisation.” 

Use the correct communication tools 

There are a multitude of tools that can help you communicate better, especially as more and more teams work remotely. For Lean and Agile coach Ilija Popjanev, changing their approach to communication has been instrumental. She says, “Our biggest failure was weak communication through emails. We learnt the lesson and switched to Slack and Whatsapp, now it is totally different.”

Use games, activities and tools in Agile facilitation

Mentor and Facilitator Nissaf Sleimi has incorporated games and tools to build resilience while facilitating. Using games to practise agile methods not only deepens our understanding of concepts but helps us to build confidence, communication skills, and trust. You can practise communication and other Agile concepts through these games, such as the Kanban Pizza Game

Agile games

Photo by Parabol on Unsplash

Keep learning, always

At agile42, one of our biggest lessons for the year was that the learning never ends. As we approach the new year, we want to make sure we’re not repeating old mistakes, and learn how to improve on the issues we’ve identified. Want to learn with us? Check out our online courses, enquire about our training and workshops, and sign up for our free webinars.

Part 2: Digital Transformation

For the month of June, we've teamed up with our partner, Dave Snowden, Founder and Chief Scientific Officer of Cognitive Edge. In Part 2, Dave explains the role Agile plays in a digital transformation and potential organisational implications. He also examines the social-human impact of such changes. 

Watch the full interview below:

What is a digital transformation and why is it necessary?

In a modern world, you need to be able to connect very quickly. You need people to be able to do things that are routine without difficulty, without problems. We need to have information in near real-time in many cases. So, digitisation is a key hygiene factor aspect of that process and essential within any modern organisation.  

What are the organisational implications of a digital transformation?

They are many and various. Part of the danger here is that people are seeing digitisation, like people saw business process reengineering back at the turn of the century - an excuse to reduce staff numbers rather than to increase the quality of services. So, the organisational expectations are that many of the routine tasks would go and instead become automated. 

However, those are in the center of a normal distribution. You also need to account for the fact that the exceptions will be many and varied, particularly in the early days. You need to create an organisation that can handle both the automation and nonautomation, the digitisation, and personal interactions. So, it’s not just simply a process of saying:

  • what can we do?
  • what can we automate?
  • what does digitisation affect?

You actually have to rethink the culture and the aspects of the organisation around digitisation - what it will mean for you, what it will mean for your staff and what it will mean for your customers. That is an exploratory process and not necessarily something that can be planned in advance.  

What role does Agile play in the context of a digital transformation?

Agile at its heart, is about fast cycles, high levels of customer interaction, high levels of experimentation, a willingness to be wrong, and a willingness to do things again and again until you get them right. Those sort of short-cycle, high interaction processes are key to digitalisation. Agile, properly applied, has a key role to play in making this transformation successful.

What is the social-human impact of such changes?

This is the area which everybody is neglecting. So, if I’m a customer, digitalisation can provide me with a very powerful way of doing routine tasks very quickly. However, when I start to move into exceptional states, everything sort of just goes wrong. 

To give a personal example; I got a package from Amazon the other day containing an expensive item that I never ordered. I contacted Amazon and they said, “do you not want it?” and I said, “well I never ordered it so something is messed up in your system”. Their digitised system couldn’t cope with me returning it, so I got a pair of size 8 shoes, which I can never use, for free.

You need to be able to interact with somebody in real-time and you need to have somebody who actually understands the concepts of your inquiry. At that point, digitalisation is supporting a human actor and not replacing a human actor. We also need to consider the degree to which society-level access is an issue. For example, if you live in a middle-class household, you are likely to have high-capacity broadband and digitised services that are easily accessible and make perfect sense. However, some people may not have the same digital access and are excluded from these new services and products. We need to think about making technology pervasive and open access widely enough to handle some of these societal implications. The danger is in the creation of a digitised class and an undigitised, disenfranchised class. 

What is the impact on customers?

For customers, if it works well, it becomes a very different, and often better, way of interacting. It was like when ATM’s took off -; you didn’t have totalk to the bank manager if you actually didn’t have enough money, the machine would tell you, not a person. The level of personalisation and automation was actually very powerful. The same is true with digitalisation – the customer now has more autonomy and agency in their interactions

As a customer, that impact is quite a powerful one. It makes my life easier and gives me more freedom. Except in cases where a high level of human interaction is required. When something happens that couldn’t have been planned for, the system needs to have the ability to adapt and change. One of the problems in a digitisation market is that, if you lose customer intimacy, you become a commodity supplier and customers might as well go to somebody else. So, even if you can automate things, even if you can digitize the whole experience, it’s really important companies also focus on maintaining intimacy and human contact in that relationship as a part of their overall approach to loyalty.

Watch the recording of Dave's webinar on "Digital Transformation".

*Click here to read Part 1 blog post* 

Part 2: What makes a great Product Owner?

In Part 2 of our series on "What makes a great Product Owner?", agile42 coach Lothar Fischmann, looks at why having a Product Vision is so important for a Product Owner and what we can learn from “Shark Tank”.

You can watch the full video interview below:

Why is having a Product Vision so important for a Product Owner?

One of the first questions we ask Product Owner’s when it comes to any kind of coaching conversation is: “what is your product basically about”? And hopefully, the Product Owner is able to give us a short insight into the main characteristics of his product and be able to tell us where the journey should go. If he is able to tell it to us, he should also be able to tell it to stakeholders, users, or clients. The basic idea behind the Product Vision is that the Product Owner should be able to make an elevator pitch for instance to his company’s CEO/CIO of the idea behind this new product.

Are there any good examples of Product Visions?

There are a couple of good examples of Product Visions that are very well known. For example, JFK’s “Man on the Moon” speech or Martin Luther King who stated, “I Have a Dream”  and, of course, Steve Jobs’ vision of the iPod. So what we are seeing is that a Product Vision can also be used for organisational or social development as Martin Luther King did. A vision and a clear understanding of the product is helpful and guides people on the journey. 

We use the idea of a Product Vision also when we talk about an agile transition. For example, where there is a sponsor at the top who has an idea of how the agile organisation could look like, what the benefit of agility is and why it is important to start working in an agile way. Other good examples of Product Visions can be found within shows such as “Shark Tank”. The principle behind “Shark Tank” is quite simple. There are people who have an innovative product idea and they would like to get some capital from venture capitalists. So they pitch their product and try to convince the “Sharks” to invest in their product.

What can we learn from “Shark Tank”?

The people on “Shark Tank” are extremely motivated in selling their product to the “Sharks”. In their presentation, they will focus on the most important aspects of their product and why people would buy it. Some of them also hand the product to the “Sharks” so they can touch, smell or possibly taste it, which can be quite important for some products. 

It’s not only the presenter's work we can learn from. You could also learn something from the “Sharks”. For example, what kind of questions are these people asking? Typical questions include:

  • have you already sold some of the items or is it still an idea?”
  • have you been able to collect customer feedback?
  • what did they say and how have you been able to incorporate that?
  • what is the market looking like? Are there any kind of competitors?
  • Why should we use this approach over other competitors? (i.e. a “make or buy decision”).

You will find Product Owners who have given a thought to all these questions, who prepared themselves in front of a mirror or with friends, who thought how to present their product in a succinct way that will be well perceived by stakeholders, users, or the “Sharks”. This helps people to understand the product and to develop it. Therefore, working on a Product Vision is always a good first step on your journey.

 

Watch the recording of Lothar's webinar on "What makes a great Product Owner?".

*Click here to read Part 1 blog post* 

 

Post agile42 Connect

The agile42 Connect - A Series of Fortunate Events was a great success. We had public sessions running from the 27th to the 29th of July, as part of agile42's Innovation Sprint. Usually every year the whole company, including families, gather together for a week of Innovation. Besides working together, creating new things, supporting ongoing work and services, we most importantly - have fun!

This year we were supposed to go to Canada for our Innovation week, however COVID-19 forced us to change tack. We instead went virtual and decided to make some parts of the Innovation Sprint public. We miss not being able to see each other in person, but what can we do?

In this blog post, we will share the Panel discussion with you as well as the other 3 webinars we ran this week.

Help us to help!

This year, we chose a needy charity, Nutrition with Love & Kindness, where those taking part in the #agile42Connect event could donate. This charity converted their venue kitchen business to provide 12000 nutritious meals a month to vulnerable families during this COVID-19 crisis.

Funds raised will enable them to keep providing 12000 meals a month to the local community. Good nutrition improves immunity and creates stronger, healthier, happier humans. With just €8.00 you will feed 1 person for a month.

Please donate and help those in need!

Let's start with the Panel discussion. Through out the week, in the back of our heads, was the thinking around "The NEW NORMAL". What is the new normal? Or is it just the normal? The Panel discussion was about pandemic effects, market changes and what might happen next. The panelists discussed their various challenges, how they've adapted their way of working and insights into how companies can try weather the storm.

We had a great group of panelists - agile42's, Peter Hundermark, was the moderator of the panel, along with guests, Christoph Bornschein from TLGG, Richard Sheridan from Menlo Innovations, Tim Mois from sipgate, Tobias Schiwek from Divimove, Sonja Blignaut from Cognitive Edge and last but not least, Andrea Tomasini from agile42. Below you can watch the recording of the session.

 

OrgScan Summer Offer

If you want to see how your organization is handling the changes we are facing, the challenges and how work is moving on, you can test your organizational culture with OrgScan Starter summer offer. The summer offer is valid until August 15th 2020.

Tuesday started off with a session in the morning by Bastian Wilhelms, one of the founders of sipgate. At sipgate, Bastian has been driving the change to an all-in agile, decentralized and mission based organization since 2009. He is a Senior Advisor to the Product Leads at sipgate and helps set the vision for success with Scrum as well as sipgate’s overall company strategy.

He gave us very interesting insights into how work has been continuing at sipgate, as well as how to find and establish meaningful metrics for any recurring fee business model. He also delved into story-telling techniques.

Please find the recording of this session below.

Tuesday ended with a session together with Richard Sheridan who gave us a virtual tour of Menlo Innovations. Richard shared Menlo’s history, culture and practices – and how they're rebuilding a joyful culture in our new normal of today. It was nice to be able to take part in the largest (so far!) virtual tour of their company. Some of our agile42 colleagues actually visited Menlo a few years ago, and now we had the chance to hear how Menlo works today.

The stories which Richard shared are something that we all can relate to, and if you missed this session, please find the recording below.

If you want to sign up for a tour, please feel free to contact our friends at Menlo!

Wednesday was the last day of our public webinars. The day started off with a presentation by Yasmin Akay and Lena Natus. Yasmin is the Managing Director of Divimove’s Production and Strategy Studio, Europe’s leading digital studio and home of digital content creators. Lena is a consultant at Divimove, and her role is Company Culture and Organizational Development. She is also an actress. This session was about Human Behaviour consuming entertainment content and interacting with it.

They spoke about Social Media, different platforms, what to think about, how to try out new things, to be human, to breath and to listen to the audience you are trying to target. This session was incredibly valuable to all of us trying to build images of ourselves online, as well as branding our companies.

Have a look at the recording here!

Last but not least, I want to thank everyone that took part in our #agile42Connect event this week. We had many new faces join the webinars along with our valued regulars.

A big thanks to all of our guests, some of whom even took time out from their vacations to join us! It was a pleasure to hear your thoughts and ideas on the "New Normal". As the guests donated their time for free, we really hope that you can make a donation to Nutrition with Love & Kindness!

A big thanks to all at agile42 for the fantastic virtual Innovation Sprint. 2020 will be the Innovation Sprint we will never forget. We're also sure our "fun day" on the 30th July will be just as memorable!

See you next year! 

Starting a Scrum Team

This blogpost will give you insights into starting a Scrum team, with a recording from the webinar and some additional information to support you with this journey.

As with Scrum in general, starting a team is easy to understand but difficult to master. I presented a webinar on this topic where I wanted to run you through the finer points of starting a team. Starting a team is not just explaining Scrum and proclaiming: “Go!”. It is a process in which the level of complexity needs to be evaluated in order to determine the right approach to move forward. Will Scrum really benefit you? Once this has been established it’s time to get into the nuts and bolts. I discussed what steps need to be taken in the first few weeks and what to expect while establishing a healthy team. 

Since we are progressively stepping into a world where remote collaboration is becoming the standard, I created the opportunity for Q&A during the webinar where we discussed some interesting questions regarding remote collaboration as well as other pain points. This can be heard in the recording of the webinar.

For those who missed the live session, don't panic! Here you can find the recording, and it is also available on YouTube.  Have a look and feel free to share with friends and colleagues. If there is anything we can help you with regarding this topic, feel free to contact us

 

 

We would also like to share a few links that may be of interest to you. We have a Scrum start-up package for kicking off new Scrum teams, and this link gives you some insights into this service. We would be more than happy to walk through with you how we can help support your teams. Please keep in mind that e.g. the Team Kickoff can be done every now and then with the teams, and we strongly recommend this e.g. after summer vacations or winter breaks. 

As we mentioned in the webinar, if you want to take your basic learnings to the next level, we recommend Certified Scrum Master (CSM) training. At agile42 we are currently running this training remotely, and dates can be found from the listing. 

For more on the topic of team dynamics, you can always book sessions with a coach, and if you want to learn how to support your teams with this, please have a look at the Advanced Certified Scrum Master (A-CSM) training or the Advanced Team Coaching Course (ATCC) where you can boost your own skills. These trainings give you, as an Agile Coach or Scrum Master, valuable support to help you with your teams. 

We have all kinds of support for the Agile teams, and many of the steps that I listed in the webinar are services we can provide, so please connect with us and we would be more than happy to help.

 

For more webinars and recordings, please look here! More  webinars!

 

 

Tag Archive for: agile

CAS-SA1 Training

New certification

Certified Agile Skills – Scaling 1 (CAS-S1) training

Our Certified Agile Skills – Scaling 1 (CAS-S1) training class is a brand new Scrum Alliance certification. There’s an unprecedented demand for companies to deliver more in the  contemporary business landscape. CAS-Scaling 1 provides a solid foundation to ramp up the results of your agile efforts and take production to the next level. Scaling agile requires focused collaboration, coherent objectives, and appropriate change management practices to ensure that the flexibility and responsiveness that make agile effective on a team level can be sustained on a much larger scale.

  • Duration: 16h
  • Delivery: Remote / Face-to-face
  • Certifications: CAS-S1 Certification (Scrum Alliance)

Overview

In CAS-S1 you will learn different approaches that need to be taken when working agile with multiple teams. Unlike prescriptive scaling frameworks, the course will equip you with the skills and knowledge to identify principle-informed patterns that apply to your organization’s unique and evolving context.

The class is presented in a highly interactive and collaborative format with elements of lecture, classroom discussion, exercises, games and simulations, smoothly blended throughout the class. We will approach the class at a sustainable pace and endeavor to take breaks often, to allow our brain to stay focused and our body to recharge when necessary. 

Upon completion of the class, students will receive a CAS-S1 Scaling certification.

Who should attend CAS-Scaling 1?

This course is ideal for change agents—managers, executives, coaches, and anyone participating in scaling within an organization who needs adaptable guidance and a tailored approach to the core aspects of scaling.

The CAS-S1 course is right for:

  • Managers guiding the change
  • Executives who believe in the change
  • Agilists who embody the change

You can supercharge your skills even if you’re in the middle of an evolving scaling transformation or have never attempted scaling. This course is designed to meet you and your organization wherever you are in your journey to expand the benefits of agile teams.

Training topics

  • What is Scaling and Why is it Necessary?
  • Approaches to Scaling (Principles-led, Practice-led, Pattern-led)
  • Principles of Organic Scaling
  • Introduction to Complexity and System Thinking
  • Value Delivery and Unnecessary Synchronizations
  • Organizational Culture and Decentralized Control
  • Scaling Patterns
  • Change Management in Scaling
  • The Role of Agile Coaches in Scaling
  • Scaling Case Study Deconstruction

Included in the training

  • Certificate for Certified Agile Skills – Scaling (CAS-S1) + two-year membership to the Scrum Alliance
  • Slack channel to continue collaborating with your classmates after the class and access trainers to ask questions
  • Option to join the agile42 Community and get access to a number of free learning resources, like books, articles and videos
  • Life-long warranty on the course: e-mail access to the trainers

Why train with agile42?

  • Experience: Over the years, agile42 has delivered Scrum & Agile training to thousands of professionals worldwide. Our instructors have decades of experience using and coaching Scrum in hundreds of organizations large and small.
  • Excellent ratings: We consistently receive excellent ratings from our participants. 
  • Techniques: In all of our classes, we use techniques from Accelerated Learning and in particular principles and concepts from Training from the Back of the Room.
  • Engaging: Our courses are highly interactive and fun – not a PowerPoint assault, and our participants stay engaged throughout the class, learn by doing, and have fun along the way. When learners talk and teach, they learn. – Sharon Bowman
  • Practical and Memorable: Participants learn through hands-on exercises, creating high knowledge retention.
  • Sustainable: We are contributing to a greener planet by decreasing our carbon footprint by not having people travel to the venue, and less paper usage in terms of flipcharts and post-it notes.
 
Mitchell F., Program Management Consultant

Your virtual environment

In order to ensure a collaborative, engaging and fun environment even virtually, we are going to use a number of digital platforms.

  1. We will use Zoom as a video conferencing platform. You can access Zoom through your browser or download the desktop application. We recommend you access through a PC/laptop with a webcam and mic or headphones.
  2. We will use Slack as an additional messaging channel. You will get an invitation to our class Slack channel. If you do not have a Slack account, please go to https://slack.com and create one using the same mail address you used to register to the training. If you already have a Slack account with another email address and you want to use that one, let us know.
  3. We will use Miro https://miro.com as an online whiteboard for digital collaboration. You will soon also get an invite to access the platform. The access is included in the training fee you paid, so it will be free of charge for the 2 days of the training.

You will receive further information and specific instructions before the training.

 
Michael M., Senior Project Manager

Upcoming training