Welcome to the Home of Scrum! ™

Introduction I was hired by a bank to help them to get started with agile and Scrum. The department had assembled business employees to become three teams. Most people who see the value of the Scrum Master role will agree that a seasoned scrum master can support up to three experienced teams when sprinting. But is one Scrum Master enough to start up three teams from scratch simultaneously? Yes! In this article you will read a detailed review how. Startup program details The Kick-off We organised a four hour kick-off session to introduce the change. This session would inform all future team members as well as members of the works council. We chose for a physical, 1,5 meter covid-proof session with drinks and snacks. We planned this workshop just before the summer break to make sure we could inform (almost) all people impacted by this change. This would also give them some time to think about the initiative and its consequences. The head of department opened the workshop by explaining his vision and the reasons for starting this initiative. The three Product Owners, one for each team, shared their future plans by presenting their roadmaps and goals. I took the opportunity to present myself as the Agile Coach facilitating the change and explained in a couple of words the essence of working with Scrum. We concluded the workshop with a sailboat-session to collect and discuss the group’s current challenges. This data allowed us to verify if the Scrum initiative actually might solve the problems we were facing. team startup schedule, each color is a team – image roland flemm I prepared a schedule to startup the three teams consecutively (near-simultaneously). Each team follows a one-week startup program with full support, one team after the other. There were three teams which made it obvious to work with three-week sprints during the startup phase. I’d figure out a way to synchronize the teams later. Before the summer break, I asked the PO’s to prepare a vision and mission statement and create an initial Product Backlog. The agenda for the one-week startup program contained the following activities: Day1 Welcome and check-in using ESVP. Some people brought their laptops and had tasks that needed attention. I needed to make sure everybody was ready to participate and focus on the startup activities. We agreed to plan on a couple of time-slots during the day for them to work on those tasks. An icebreaker using random question cards to create some laughter and fun. I shared the agenda for the upcoming two days and asked everybody if they had any other appointments. Never assume the obvious: Some people did not have an empty agenda. I tried to accommodate our schedule where possible. (In all teams I noticed that all agendas were cleared the same day out of free will. People saw the importance of their attendance and didn’t want to miss a thing.) We did a team-member introduction round because most people were colleagues but did not know each other that well. I asked all team members to share their “best team experience ever” using the Appreciative Interview technique. This exercise makes people share positive team experiences, helps them to define what their core power and drive is and what they need from a team to perform at their best. This is a great way to get positive energy flowing. We compiled team agreements. When the team agreements did not come easily, I used the Liberating Structures Triz technique: “How can we sabotage our team success?”. The PO clarified mission and vision to ensure everybody understands why this team is being created. I noticed that in every team, the mission as proposed by the PO was reformulated with the team inputs. This made the mission statements shorter, measurable, catchy and co-owned by the whole team. The team was asked to brainstorm on a team name, which turned out to be more difficult than expected. The day ended with a Scrum simulation to learn Scrum by experiencing it. I played the role of PO and let them build a 3d city made of colored paper. In the course of the game, the team learns how the backlog is compiled, what the role of the PO is, how we define and attribute value, how sprints work and how the team can improve their collaboration. Day2 I started the day with my favorite recap-warm-up exercise: building a treasure map of yesterday’s discoveries. A lecture on Scrum theory and principles for no more than 2 hours. We agreed on the sprint schedule by planning the Scrum events and refinements. We collected impediments that hinder the team. A problem I discovered that needed to be fixed asap was that some team members were only part-time available for the team. Part-time (as in being a scrum team member and also be responsible for work outside the team) reduces the focus and transparency and needs to be avoided. We started our first refinement. By refining real work from the Product Backlog with the whole team, the team members shared knowledge. They created plans on how to get the Product Backlog Items to “Done”; i.e., we discussed all activities needed for each PBI. By doing this, we discovered the Definition of Done: the recurring activities (tasks) for many or all PBI’s, such as: “setup company communication”, “create work instructions”, “verify with legal”, etc. Refining the work for a bit more than a Sprint took more than a day. That is pretty long but is incredibly important for sharing knowledge. I ensured to continuously check everybody’s impressions, emotions and concerns during the numerous breaks. We had drinks together (to continue getting to know each other and to continue finding a team name). Day3 Explanation of effort estimation and planning poker. Pokering a small and a large story, gives us two benchmarks for relative estimation of the whole PBL using the magic estimation technique. I purposely postponed the estimation during refinement to first keep focus on sharing knowledge and then on estimating the work. Sprint planning. The teams selected the items for their first Sprint Backlog and we started the first sprint. The Po’s were understood that the teams might probably not take a lot of work in the Sprint. This is an effect of doing the Sprint simulation exercise. I also could sense the teams were playing it safe because “now things were official”. I addressed that I felt the teams were not very optimistic planners and reassured them that this is ok, “as long as we agree that new work from the Sprint is taken in we finish the work before the Sprint is over.” To get the Sprint started, we did a daily Scrum in the middle of the day, right after the planning was over. This kicked them off to start working on the work. Day 4 and 5 These days consist of Daily Scrums, refinement and the team doing the actual work. I was available to help them find answers to their questions as they were working through their first sprint on a day to day basis. I facilitated, taught or coached them during their first week of Scrumming the work. Week 4: End of Sprint for Team 1 In week 4, the 3-week-sprint of team1 ended, so I returned to team 1 to help them prepare their Sprint Review and hosted a Sprint Retrospective. The first Sprint Review session was used to help them discover and learn the Sprint Review mechanics, not to actually have a Sprint Review. We created the Sprint Review agenda which made them discover all the stuff they need to prepare each Sprint to be ready for the Review: Iterating over the team goals, clarifying the Sprint Goal, sharing their challenges, demo the result, collecting feedback, discuss metrics. This session also delivered each team a new item on the DOD: “Prepare for demo”. We looked back on the first Sprint in the Sprint Retrospective, shared experiences and closed the Sprint with a fun team activity (drinks!). The next day, I supported them with the Sprint Planning of Sprint 2. This is where the support for the full Sprint cycle support ended for team 1. Note that all Scrum events and activities in sprint 1 were not performed on the scheduled days and times and we did not adhere to their time-boxes. Everybody knew and understood the officially intended sprint schedule and that this initial Sprint was different. As soon as all teams had their Sprint started, I was free to support the teams that needed facilitation support for their refinements and randomly joined Daily Scrums of various teams. The remainder of my time I worked on removing organizational impediments: Helping to find solutions for the work no longer picked up by the new teams and informing and teaching the new way of working to the stakeholders. Synchronizing the Sprints The goal was to synchronize the three teams so that they all got into the same cadence. We wanted the group to have one Sprint Review per Sprint where all teams can collect feedback from the stakeholders. This makes things simpler and more transparent. I made sure that the PO’s understood that shorter sprints are preferred because this gives us more opportunities for inspection. With a bit of puzzling I found a sweet spot where each team had sufficient time practicing with their three week Sprint and could switch to two-week sprints. From there on, everybody started with a synchronized two-week Sprint. Coaching Most people embraced the new way of working. However, not everybody was equally happy with the new multidisciplinary teams. Friction was caused due to: responsibilities for “old” work, some people did not join the new teams voluntary, and some simply had difficulties getting used to the new team collaboration and processes. When starting up new teams, the scrum master needs to take special care of to those people who are showing signs of doubt or struggle. Keep your ears and eyes open for signals. In many cases, people who have fears or doubts will not show them directly but share them with by cracking a joke or by silently organizing “their life” around “your“ Scrum. I tend to be very cautious to intervene. Things simply need time (days, weeks) to settle in. I also want to give the team the opportunity to fix the problems by themselves. Sharing a thought with a team member about things I observe is enough in most cases. I ensured the team’s previous managers were “helping in the right direction”. If needed I sat with team members to find out what was bothering them and I coached them to set new goals that would solve their impediments and stimulate collaboration. Was it successful? The organization wanted to adopt Scrum in order to change their organization so that they would become faster and more flexible in delivering products with happier people. The teams immediately ran into dependencies on other departments for delivering Done. In the first sprint already, three capabilities were identified as main blockers for 80% of the work. We started a dialogue with these departments to agree on new ways of collaboration trough: acquiring permissions, add subject matter experts to our teams provide us with the necessary knowledge handing off responsibilities With this, the teams were able to expand their DOD, which according to me is a proof of real organizational change. The vast majority of the people were enthusiastic and delighted with the new way of working: they belonged to a real team working on a clear goal, where colleagues help each other and the team succeeds in delivering valuable results. Conclusion One Scrum Master can get three teams started with Scrum near-simultaneously (in six weeks). The degree of success depends on a couple of factors: The preparation and willingness of the team members. In my case, two of the three teams were rather easy. If there is much resistance in the new teams, they will need more coaching time than you can give. A second critical success factor is management support. Introducing a new way of working will cause friction in the organization. We need top-down management support to talk to people outside of the group who otherwise would not be inclined to collaborate. We also need horizontal management support to ensure managers of a nearby departments no longer dispatch work to Scrum team members but go to the Product Owner instead. Communication is key. Ensure that everybody in the organization gets the opportunity to inform themselves about the change initiative. We spread the news via the internal newsletter and organized walk-in sessions. The team members discovered that they are the key evangelists to explain repeatedly to their colleagues outside the team about the new way of working. We chose the first week to be physically in the same location. We did not want to take the chance of setting up the teams remotely. I think working remote makes this kind of work more difficult because it is not possible for a Scrum Master to remotely observe the new group dynamics very well. Social events matter. Have lunch, grab a beer. (The team names came easily in the bar after work ;-).

Brief about me before you read this post so you can understand my perspective better. I am a software developer and Scrum Teacher. I have been in software development for 23+ years and have worked on various technologies and have played the role of a developer, analyst, project manager, delivery manager, scrum master, product owner, and coach. I teach and coach teams and individuals on agile project management using agile methods, agile product development using Scrum and LeSS, and Agile Software Development using Scrum, XP, and DevOps. Hoping it made clear that I don’t teach a role-based curriculum and focus on processes, practices, and methods. For me, the role is fluid, and if I know better techniques, procedures, and methods, then I can play any role that my team expects me to play. What is business analysis? It is a discipline and very popular in the software project management field. Traditionally, there is a role called a business analyst to perform all tasks related to business analysis. Requirement analysis is a phase to perform business analysis tasks within traditional project management techniques (waterfall is the most popular framework). In this phase, analysts determine problems, identify business needs, elicit requirements, and manage stakeholders to meet business and project objectives. During execution, they facilitate the implementation of the Product, service, or result of the project. Why a business analyst? Since analysis is a phase in traditional project management and usually longer (20–30% of project duration) and determines what takes to make a project successful, organizations ensure that they have the best possible people to perform analysis to decide the project continuity during phase gate review. Such needs promoted a culture to groom people in business analysis, and a disciple became a role over the period. I still remember my early days of software developer career, where we developers analyzed requirements and managed stakeholder’s expectations. Obviously, over the period, complexity increased as software started to control many things. The level of risk increases, so the demand for experienced professional business analyst grows many folds. Later, a professional body within this disciple came and started certifying people on their skills. We have thousands of people certified by IIBA, and the demand for certification is still growing. What is the Scrum Framework? Scrum Guide says — Scrum is a process framework that has been used to manage work on complex products since the early 1990s. Scrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques. It has THREE roles, and every role has clear accountability. The Product Owner is responsible for maximizing the Product’s value resulting from the Development Team’s work. The Product Owner does this by doing: Clearly expressing Product Backlog items; Ordering the items in the Product Backlog to best achieve goals and missions; Optimizing the value of the work the Development Team performs; Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and, Ensuring the Development Team understands items in the Product Backlog to the level needed. The Product Owner is one person, not a committee. The Product Owner is responsible for managing stakeholder’s expectations and engagements during product development. Can a Business Analyst (BA) take over the role of The Product Owner? It is a widespread practice where a BA plays The Product Owner’s role while developing a product using The Scrum Framework. Does The Product Owner need to learn disciple of business analysis? Looking at the above responsibilities of The Product Owner can easily understand how important it is for The Product Owner to have an in-depth understanding of business analysis. What if The Product Owner doesn’t have these skills? Can the outcome get impacted, or does it needed for The Product owner to learn business analysis? The answer depends on how well you interpret the below line. The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable. So here comes the second role, The Development Team and the following are characteristics of this role : They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality; Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment; Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person; Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis; and, Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole. Can a Business Analyst (BA) be a part of The Development Team? There are two ways to think? We need business analysts in The Development Team, or we need business analysis discipline within The Development Team. Both options work, but I would prefer to have both. It is because of the fifth characteristic of The Development Team. Having a specialist ensures that discipline gets attention and continuously grow. But team knowing business analysis helps The Development Team not to be dependent on individuals. This approach becomes useful when multiple teams working on the same Product. One Product, one Product Owner, and one Product Backlog is the rule as per Scrum Framework, so when multiple Teams work, The Product Owner may struggle to deal with huge requirements and numerous stakeholders. The role of The Product Owner has to scale in such a situation. We have many ways to deal with depending on the context, but nothing beats having such discipline within the teams. LeSS framework talks about having area product owner, SAFe talks about having The Product Manager and group of Product Owners, and some companies have Proxy Product Owners. I can’t comment about LeSS or SAFe, but having a Proxy Product Owner will defeat the purpose of having a single Product Owner. I usually call them glorified business analyst. What can Scrum teams do to deal with such situations? Learn the business analysis discipline to support your product owner and be a cross-functional team. In such a case, teams perform better without being dependent on an individual’s skills where specialists take over the role of guardian for discipline and facilitate learning. IIBA has a couple of courses that suit such needs, such as Entry Certification in Business Analysis (ECBA) and Agile Analysis Certification (IIBA-AAC). I am not recommending to attend the IIBA program, but I didn’t find any other source highlighting this discipline as much as they highlight. Does Scrum teach all these or Scrum Trainers teach all these product owners or development team training? I have not experienced so far, but that doesn’t mean this is not a possibility. Do check with your Scrum trainer if you wish too. I wish you the best for your learning about business analysis in Agile. Connect to me if you need more information in this space.

{"preview_thumbnail":"/s3/files/styles/video_embed_wysiwyg_preview/public/video_thumbnails/vRx1Eqf_oNY.jpg?itok=ahy6myVa","video_url":"https://youtu.be/vRx1Eqf_oNY ","settings":{"responsive":1,"width":"854","height":"480","autoplay":0},"settings_summary":["Embedded Video (Responsive)."]} As part of the Scrum Tapas video series, Professional Scrum Trainer Roland Flemm explores the myth that a Daily Scrum is status meeting and reveals in 2 minutes how to make your Daily Scrum event more valuable.

What should the Development Team do when the Product Owner asks them to do work that was not planned during Sprint Planning?