In the previous articles in this series, we discussed how to gather the needs and requirements of the business and then articulate them into measurable goals.
We also discussed how to staff the development team and which competencies/experiences to focus on and how they are linked to the goals. The next step is to get the work started in the right way and introduce the agile principles and Scrum. This is what we will discuss in this article.
Educate the team members and motivate the choice
To ensure that the team can embrace the agile mindset and Scrum, you need to start by ensuring that everyone understands what it is and how it works in practice. In some cases, a small refresher of knowledge may be sufficient, while in other teams, more demanding measures such as formal training, workshops, literature reviews, and the like may be necessary.
Agile teams and Scrum are all well and good, but why should we actually use them? To get everyone on board, it is good to create an understanding of why we are doing it. There is nothing worse than doing things just because we have to. You may remember some unengaging teachers from your school days whom you asked, "Why do we have to learn this? What's the use of it?" And the teacher simply replied, "Because!" Or simply, "You have to learn it because you have to!"
Not particularly motivating, right? The same goes for us in the workplace. It is not very enjoyable to work in a certain way or use certain methods and tools if we do not know why we are doing it. Motivating the use of agile methods and Scrum is not particularly difficult. You can emphasize things like achieving more flexibility and being able to adapt more easily to changing circumstances. We also have closer dialogue with the customer, which allows us to easily and with minimal effort adjust our course to align with the customer's desires. This way, we also minimize the risk of wasting resources unnecessarily and before things get out of hand.
Timeboxing is also something worth highlighting. Those of you with experience from more traditional projects where various project planning tools were used, and each activity was carefully plotted in various graphical presentations, know how challenging it was when the circumstances changed or when an activity took longer than expected, throwing off the entire project schedule. Also, explain the specified ceremonies, such as daily stand-ups, sprint planning, retrospectives, and more.
Overall, it is about being more adaptable to our customers and increasing the well-being and productivity of the team.
Explain specifically how the different ceremonies are intended to function
To ensure that the work in the team runs as smoothly as possible, it is good to have an overview of the different ceremonies and their purposes. It is also important to explain the various artifacts used in Scrum. One important ceremony is the daily stand-up, which may be perceived as unnecessary time spent in the team by many. Therefore, it is important to emphasize that this is intended as short meetings of maximum 10-15 minutes and that it is one of several ways to quickly adapt and reprioritize the team's plans. Another valuable ceremony is sprint planning, where everyone in the team has the opportunity to agree on short-term goals that everyone works towards and ensures that the team achieves them and can deliver desirable products.
Sprint planning is one of the ceremonies where it can be a bit challenging to engage all members of the team. Many may just go with the flow without being fully involved. One way to address this is to initially explain that what we agree upon during sprint planning is also what we promise to deliver externally and what we commit to. This way, it increases the chances of getting everyone to feel individual responsibility for what needs to be done in the next sprint. There are many other important ceremonies, and it is good to go through all of them and reach a consensus within the team on how they should be conducted. Similarly, you need to go through the different artifacts we should use, why they exist, and how we should use them. I am referring to things like the backlog, stories, features, enablers, epics, and various types of diagrams that can be used to visualize complex data and make it more understandable.
Create understanding of the different roles in Scrum
There are several predefined roles in Scrum, and it is important that all team members understand what these roles entail concretely and what they can expect from them. The Scrum Master (ScM) is perhaps the role that the team has the most contact with, and instead of just listing what a ScM does, it's good to "bring the descriptions down to earth." Otherwise, they might as well read the list on scrum.org. The main task of a ScM is to ensure that everyone truly understands what Scrum means, both in theory and in practice. Additionally, a ScM can assist with many other tasks such as prioritizing the backlog together with the Product Owner, helping the team remove obstacles, mitigating risks, and more.
Similarly, it is good for everyone to understand what it means to be a Product Owner (PO) in a team. A PO is ultimately responsible for what the team delivers and must ensure that it is done as efficiently as possible and continuously aligned with the defined goals, requirements, and needs. The PO is also the one who prioritizes the backlog and ensures that what the team should work on next is always high up in the backlog. An important aspect that may not be obvious to everyone is that the PO is entirely responsible for the backlog. The only way for someone else to change the prioritization in the backlog is to convince the PO within the team.
Last but not least, we have the actual team where the production takes place. The team can consist of developers, testers, and others, and it is these individuals who ensure that we can actually deliver something and produce products that are aligned with the set goals.
Continuous improvement
Working with continuous improvement is not a new concept. It has been around for many years. A more structured way of working with this was introduced in Japan after World War II and was named Kaizen. What was new about Kaizen was the realization that small incremental improvements can lead to significant progress in the long run. Kaizen later evolved into the methodology of Lean Manufacturing, which is still widely used today, especially in the industry. Kaizen is also a vital part of the agile philosophy and is extensively used in Scrum.
But what do we actually mean by working with continuous improvement? Many may find it somewhat vague and elusive, but with fairly simple means, you can bring more clarity to this important work. One way to gain a better understanding of this is to introduce clear measurable goals for the improvement work. An example of such a goal could be to achieve better job satisfaction among the team members, which can be regularly measured through internal surveys that are then compiled and evaluated.
A common pitfall in improvement work is taking on too much at once, creating a high threshold to overcome and a significant risk of failure. It is better to work with small changes and ongoing evaluations of them. This makes it easier to work with more experimental things that may not function as intended but are also easy to abandon.
With that said, you should now have good prerequisites for success with your team or project. In the next article, I will discuss communication and collaboration.
