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.
Tag Archive for: agile
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.
Watch now | Why Technical Debt is an Opportunity
Roberto Bettazzoni has experience as a technical trainer and a software developer. Alessa Leuschen has experience in different Agile roles, including a Product Owner and Scrum master. Together, they share their different perspectives and experiences, outlining some effective ways to deal with technical debt, and how to use it as an opportunity.
Five key takeaways from the webinar
Technical debt is unavoidable in Agile product development.
Technical Debt is a metaphor, coined by Ward Cunningham. He explains that when we initially ship a product, we are likely to go into “debt” as we do not have all the knowledge we need yet. This phenomenon happens after we ship an easy or limited solution that may require extra-work or an additional cost later on. Roberto Bettazzoni clears up some misconceptions, saying, “Technical debt is not bad code. It’s not a bad solution. It’s not putting something in production that doesn’t really work. It’s shipping with the quality that we can do quickly and with the knowledge we have now.” Once we have feedback and our hypotheses are verified, we can “pay our debt back.” “This is in the heart of Scrum or any Agile way of building solutions,” Bettazzoni concludes.
There are different types of technical debt
The incremental nature of Agile methods allows us to keep technical debt small and deliberate, which can be continuously evaluated. However, it can also be unintentional, and this can show up in a review. In this case, these discoveries will need to be quantified and corrected. Roberto Bettazzoni says that not all types of technical debt are helpful. He explains that, “There’s another way in which it is reckless. So, when you make a big technical debt, you go quick and dirty in production.” And this is something you want to avoid if you are already deep in debt.
Technical debt can become a threat if it gets out of control
Alessa Leuschen uses a metaphor to explain how technical debt can get out of control. She asks webinar attendees to imagine that construction workers arrive at a house to add new features. Upon arrival, they notice that the house has a lot of existing problems: the foundation is missing, there are holes in the wall, and the whole construction is unstable.
The manager asks them to put a window in. The workers realize that this is going to be challenging because of the poor foundations they have to work with. This task will take longer than usual because they need to think about how they can put in a window without breaking the whole house. Of course, their morale and productivity will suffer. A manager might then put additional pressure on the workers to try to increase their productivity. To meet these unrealistic demands, the team might resort to so-called “quick and dirty solutions” that will produce even more technical debt. In this scenario, you can see how technical debt can become a vicious cycle and can be expensive in the long run. Leuschen explains, “In the beginning, you’re not going to feel it that much but at a certain point in time it’s going to grow exponentially.”
Make sure you pay back your debt
Bettazzoni sticks to the metaphor of buildings. “We need to have healthy habits to clean the house,” he explains, “don’t let the dirt pile up.” To keep our technical debt under control, we need to continuously invest in it and pay it back. We can do this by visualizing our technical debt, sharing this knowledge with the relevant parties, mapping out our technical debt, and lastly coming up with a refactoring plan. This may mean allocating a certain amount of time in your Sprint to technical debt or putting it into the product backlog. Plus, Bettazzoni recommends using one of many great tools that can help us to manage technical debt, like Sonarqube.
Our Certified Scrum Master training covers technical debt, and can equip you with the skills you need to manage it.
5. Technical debt can help us grasp market opportunities
In today’s volatile world, we don’t have as much time to develop products and bring them to the market. “A way to deal with that is to create a vision, an understanding, and clarity to find out how to serve our customers best,” shares Leuschen, “Agility can help us do this by incrementally allowing us to figure out what the best solution for the market is.”
We often do not know what the solution will look like in the end. By shipping faster, we get customer feedback faster, and we can experiment as we go. This approach means that we may need to use an easy or limited solution. “Acquiring technical debt is not only a technical topic but it’s also a design topic, because we have this uncertainty,” continues Leuschen, “we need to figure out what the solution will look like in the end.”
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:
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.
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.
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 Trainer, Certified 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.
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.”
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.
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.
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*
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:
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.
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.
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.
- 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*
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.
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.
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!
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!
I get many questions in my trainings, and one of the most common is when to use Scrum – usually preceded by utterances of “Scrum will never work in my team…” The wording of the question below comes from the Scrum Alliance Certified Team Coach (CTC) application. So this topic is relevant, and there is no one answer.
When might you advise a client to apply XP, Lean or a non-Agile approach to workflow instead of Scrum?
Let me answer this question by describing an actual situation. Read on for my thoughts.
I once coached a program of teams at a large corporate that had to automate a manual and laborious business process onto an off-the-shelf product. This program had been working in a waterfall manner for a year and had managed to automate a small subset of the business process.
A new CIO was employed and decided that this program needed to use Scrum because it would help with faster delivery. When I arrived this is what I found:
- Teams had been set up, consisting mostly of contractors from different contract houses;
- Most people had received an Agile Bootcamp training focusing on Scrum;
- Project Managers were in-house and expected to be Scrum Masters as well;
- Teams were supposedly dedicated, but the program manager repeatedly moved contractors in and out of the teams;
- The deadline had already been decided by the CIO.
It became apparent that the teams were not set up for success and that the program would revert to using a waterfall process. I thought that by helping the teams focus on some of the principles of Lean without giving their way of working a label, that it would start them thinking about bottlenecks to their workflow and identify wasteful activities.
The Rationale Behind This Approach
Major organisational impediments which due to the nature of the organisation (size, structure, and politics) were outside of the teams’ control to resolve resulted in an interrupted value-stream, but for which they were being held accountable. Here are some of them:
- Data sourcing – each business process was multi-layered with multiple data sources which the teams did not own nor have access to. Obtaining data required a long process with multiple approvals;
- Environments – development, test and production environments were being built at the same time that the team needed them to do their work.
- Teams were not stable – people moved in and out without notice to them and the Project Managers;
- No Scrum Masters – Project Managers were expected to also be Scrum Masters – this created a conflict of interest and anti-patterns began to emerge;
- Teams did not own their full value stream and yet were held accountable for delivery;
- Each business process to be automated was 1 large story because they were not easy to break down into user value items;
- Teams consisted of more than 10 people and had 3 Product Owners.
I recommended that teams adopt Lean principles and visualise their work, in its imperfect form, and start improving where they could because:
- The Product Owners were present and involved – there was a real effort on their part to help teams break their work down into manageable chunks taking into account the organisational impediments;
- By visualising the workflow as it was they would start to see where all their bottlenecks were and having the teams and Product Owners focus on customer value they would begin to identify wasteful activities;
- For me, it was also important to help teams see that their current process was not value-creating, and by regularly looking for improvements they would start to look for different ways of getting around that which was seemingly outside of their control.
There are other ways of addressing this type of problem, such as using a complexity frame and the Stacey Complexity Model. As with all things that relate to coaching, the context of the organisation and the maturity of the team are important. In order to help them become unstuck I guided them along this path and brought in the learnings of complexity later. I felt that this was, for these teams, a useful place to start.
What would you do? Please tell me below.
agile42 enables leaders and their teams to create a resilient organization and a sustainable change process. We equip them with the tools they need daily to grow the business and foster the right organizational culture.