TL;DR: To get started with Scrum, grab one of the popular tools (e.g., Jira), implement all the Scrum artifacts and fill your gaps with some experienced people. It is not all too important to have the right task estimates, sprint lengths, etc. from the beginning or to follow the methodology dogmatically. The crucial part is to have a team that commits to the process, reflects critically, is eager to learn, and improves incrementally.
It took us a little while to get the second part of our series about agile development done, but Andreas and I had some pretty good reasons for it (or at least we hope so). While I moved back to Germany from the U.S. and started a new position as a UX Manager, Andreas is now not only the Head of Research at DATEV, but also started as a full professor of Web Engineering at Anhalt University of Applied Sciences.
But anyway, we somehow managed to also talk a little bit about Scrum. In this part of the series, we want to specifically focus on how to get started with it. There are many tutorials and introductions describing Scrum, such as Atlassian’s brief introduction to the topic. However, some questions that both Andreas and I have encountered over and over are often poorly addressed or not addressed at all. Let’s start at the very beginning:
Max: How do you get started with Scrum, i.e., when you want to implement it from scratch?
Andreas: When starting from scratch, in my opinion you should take one of the usual Scrum-supporting tool (like Jira, Meistertask, Sprintly, or Team Foundation Server) and begin by implementing the basic Scrum artifacts. That is, establishing the Scrum roles, establishing a backlog, the meetings (or “ceremonies”, in Jira’s words) etc. Based on my experience, it is important to follow the Scrum methodology at the beginning of the introductory phase closely, but not dogmatically. However, if the budget is available, then fill the gaps in your organization now (e.g., an experienced Scrum master). Additionally, I suggest to manifest the Scrum methodology explicitly by establishing a social contract in the team as a starting point of the transition process and to get the team members’ commitment. The social contract should cover the characteristics of the team, so that they know how to behave within the Scrum process, e.g., how to estimate task efforts (Scrum poker would be one possibility). Particularly, the Scrum master is responsible for permanently training the team and refocusing the process if required.
Max: I’ve experienced situations in which the Scrum master and the product owner were the same person. Do you think this is generally a bad idea?
Andreas: It is imperative that the two roles can be executed well with respect to an impact-driven product (the product owner’s responsibility) as well as an efficient process and a happy team (the Scrum master’s responsibilities). One has to be aware of the fact that often, these goals are competing, which requires a team setting where neither the product goals nor the team values and principles are sacrificed. Of course, it is hard to ensure a balance between these goals if the jobs are done by the same person. While it is the product owner’s job to get new features on the road as quickly as possible, the Scrum master has to defend the process and the scope of the sprint. However, similar problems might occur when appointing inexperienced people or one experienced and one less experienced person. My point here is that there are many situations in which an agile team might be influenced in a bad way, and not only because one person is in charge of the Scrum Master and product owner roles at the same time.
Hence, in my experience, the key to a successful agile team is a valid setting following agile principles. Appointing two experienced people capable of executing the roles as defined might be the perfect setting. Yet, one really experienced person doing the two jobs with some additional backup by the team can lead to success as well, but should not be a permanent situation.
Max: Once you’ve committed the team to the agile process, how do you determine the initial sprint length?
Andreas: For this, I suggest to first analyze the given goal. In many cases, Scrum is causing problems when the sprint length is not adjusted well. For instance, when new requirements are brought up in short iterations and thus break the sprint often, or because of a team not yet capable of applying the vertical slicing methodology properly, which often leads to unfinished sprints. Hence, start with a best guess, then observe the rough lenght of the cycles in which new requirements appear and adjust the sprint length accordingly.
Max: You’ve also mentioned task efforts before. Many teams seem to struggle in this regard. Do you have any suggestions for them?
Andreas: Very true! I’ve also observed that teams often struggle with defining some kind of useful estimation. I suggest starting with T-shirt sizes. Often, a best practice is that, together with the team, the Scrum master defines the minimum size as “S” (e.g., 1 day), then “M” (e.g., double of “S”), “L”, and “XL”. After some time and experience, the team will recognize that this approach might not be suitable for their complex tasks and look more into, e.g., Fibonacci-based story points and other more advanced complexity measures. From time to time, the Scrum master needs to carefully adjust, thus leading the team to a method which is appropriate, efficient, and—last but not least—accepted by the management. From this point of view, an objective suggestion might not be possible, since this is strongly dependent on the team setting and product situation. However, a common mistake is to have no agile-experienced person(s) in place. More than once, I observed teams failing to improve (in reasonable time spans) due to a missing experienced “guide” leading the team towards a productive setting.
Max: Following up on this, in which cases and under which circumstances would it be justifiable to work without task estimates?
Andreas: Well, there can, of course, be situations in which effort estimations are too difficult, inefficient, or simply frustrating the team. For instance, if no resource planning is possible due to external reasons, synchronization with many other teams is necessary, autonomy of teams is not ensured in general, or, particularly, transparency and trust are not established within the team or company, then it is a waste of time working on task estimates, since they will always fail. Hence, to ensure that the team is adopting the agile mindset, it is eligible to pause the estimation of tasks, in my opinion.
However, I strongly disagree with the sometimes expressed opinion that task estimates are not worthwile to work on or to improve, respectively. For an ambitious team, it is crucial to be self-aware regarding the impact of their work and the challenges (e.g., with respect to knowledge transfer) and to be able to justify particular tasks (see, for example, our discussion about technical goals in the first part of the interview).
Max: Getting back to the role of the Scrum master: Often, they are recruited from people who were not active in software development. What does a Scrum master who is (or was) not a software engineer themselves have to pay specific attention to?
Andreas: Well, again, this is a controversial issue. I think we can agree that software development is a very specific field driven by strong individual skills and team efforts. People with a background in software development mostly have experienced the specifics of this field, are prepared for upcoming situations, and simply speak the language of software engineers. Hence, they might be accepted easier by the team members, which is crucial for a Scrum master due to the lateral leadership relation in Scrum teams …
Max: … but this does not exclude people who were not active as software engineers?
Andreas: No, absolutely not! Actually, it is sometimes better to have a Scrum master who might team up with the product owner and help steer the process more towards product-related impact rather than focusing mostly on the technology, which happens, not always, but sometimes. However, with no background in software development one has to be really careful about common mistakes. For instance, with making statements about difficult tasks and assessing them as easy (or the other way around), the Scrum master might degrade himself in the eyes of the software engineers, who are usually very proud of their skills and their work.
Therefore, my tip for Scrum masters without a software development background, who plan to work with software engineers, is to observe a software development team for several sprints without taking a particular role and to learn the language, the specifics of the field and maybe even try to do do some tasks by themselves to experience the complexity of computing in general. This way, hopefully, the foundations can be laid for earning trust and being accepted as a valid contributor to the team goals.
Max: In comparison: What do Scrum masters who are software engineers themselves have to pay specific attention to?
Andreas: In my opinion, former software engineers have a particular advantage, if and only if, they embrace their role as a Scrum master and use their software development experience for tackling the challenges of their team. In many cases, I’ve experienced that a former software engineer had fewer problems of steering the process towards iterative delivery. However, the risk of micro-discussions is high, since software engineers often have a dedication for technical issues even if they are not responsible for implementing them themselves. But if—for example—retrospectives are wasted with technical discussions, the team will not evolve with respect to the process quality.
Hence, Scrum masters having worked as software engineers should really pay attention to the main characteristics of the Scrum master role: be focused on the agile mindset, improve the working environment, identify and clear obstacles, etc. Particularly, the relationship with the product owner needs to be carefully developed to establish the necessary positive atmosphere in the team. As product owners are often (unintentionally) considered as outsiders by the software engineers, it is very important to mediate this conflict by leaving some of the software engineering background behind.
Max: Is there a threshold in terms of the number of people below which applying Scrum doesn’t make sense?
Andreas: The creation of and working with Scrum artifacts requires some time. In my opinion, you need at least five people in a team, but if the Scrum master and product owner are exclusively assigned to one team, then more software engineers might be required, so that the delivery speed is high enough and the product owner and Scrum master are actually “utilized”. Additionally, it depends on the maturity of the team members and the company. Particularly, if the culture of the company is not following the agile principles, even proven scalable agile frameworks (like SAFe or LESS) have a high risk to fail. In such a non-agile environment I would suggest having a core team focusing on the demanded functionality and additional supporters at the intersection to other teams focusing on solving the obstacles.
In general, I would like to turn the question around: Do you need a Scrum process for, e.g., organizing just 3 software engineers efficiently? My pragmatic solution would be to ensure that they are working together using direct communication. If that doesn’t work, I suggest to temporarily hire an Agile coach and help them find a suitable way of collaborating—but without aiming directly towards a Scrum process.
Max: Can Scrum work without retrospective meetings? If yes, under which circumstances?
Andreas: A core principle of the agile methodology is to adapt and to improve. Retrospective meetings are the corresponding expression in Scrum language. Additionally, retrospectives, e.g., establish an official timespan for controlled experiments that might lead to improvements, and many more positive aspects. So, on the one hand, retrospective meetings are very useful—if not necessary—for successfully implementing Scrum. On the other hand, if there is a team in which the team members are trusting each other, are experimental, challenge each other during implementation, give permanent honest feedback, are transparent to outsiders, etc., then you don’t necessarily have to establish a retrospective meeting at the end of each sprint. In short: If the team is very mature and permanently working towards improvement, then the time span between retrospective meetings can be increased. Yet, skipping them altogether is not such a good idea, from my experience. There is always something that needs discussion and is difficult to resolve during daily work.
***
This concludes our deep-dive into the specifics of Scrum, in particular, the roles of the Scrum master and product owner, task estimates, and retrospectives. The key takeaway here is probably that it is not so important to adhere to a strictly predefined process. Instead, aiming for a positive environment—with a team and leaders that are able and willing to adapt and continuously strive for improvement—will lead to efficient and happy teams.
In the third and final part of our interview, we will have a closer look at agile methodologies in the context of start-ups and the future of agile development in general. Thank you for reading and stay tuned!
2008 – Tales of Design & User Experience 