Duncan Evans

Many teams are finding that they need to adjust to a new reality amid the covid-19 pandemic. Strategic plans lie in tatters, urgent unplanned work fills the board, stakeholders are hammering teams with requests, and routine has gone out of the window. This is a time for a Scrum Master to be pragmatic, calm, and outcome focused: providing delivery leadership without allowing process to get in the way.

Hi Duncan, I took your Scrum Training class a couple of months back. You mentioned if we had any questions, we could email you and I have an interesting situation I found myself in regarding QA’s in our Scrum teams.

Compare the use of Scrum's Definition of Done to the professional procedures in other fields such as surgery and aviation.

Don’t say this too loudly around agile conferences, but when it comes to the day-to-day work, Scrum and Kanban teams are very similar.

If you give a developer a verbal warning for surfing social media all day, you are crushing their autonomy. Insisting on core hours of 10am-4pm violates self-organisation. Personal development plans are so PRINCE II. Right? Well, maybe. On the other hand, having someone relatively experienced and influential on your side, to help shape your career and keep you off the annual redundancies list might actually be quite useful.

We regularly work with teams that see the Daily scrum as irrelevant, disruptive, and boring. They are often right. Here are three common anti-patterns and three potential solutions.

The Intent of Scrum Scrum allows development organisations to invest a little time at regular intervals to allow teams with autonomy over their work to identify and enact frequent, small improvements to the process and the plan. Over time, like regular payments into a savings account, these improvements build up and are compounded to produce high returns in the form of a mature, responsive team, building a relevant and valuable product. To achieve this, time is allocated at regular intervals to inspect and adapt the plan for the sprint; day; and release, and to improve the process: This is not free: taking a whole team away from their work for several hours a month is an overhead. The Scrum framework caps the time allocated to sprint planning, daily scrums, reviews, and retrospectives at 20 hours for a 4 week sprint (proportionally less for shorter sprints) which represents just over 12% of the entire development effort. It is also suggested that up to 10% of the capacity for the whole team may be spent refining future product backlog items so that they are well understood. These timings are maximums and in practice the actual time spent is likely to be less, but nonetheless the time all adds up: If done well, this investment pays off. New teams quickly identify and correct obvious problems, while mature teams keep themselves sharp and push the boundaries of their technical and collaborative practices. Release plans are put together quickly without undue commitment to delivering “on time, on budget” or solving all of the technical uncertainties up-front; freeing teams to make decisions at the last responsible moment and constantly re-adjust the plan to optimise value. The reality of Scrum half-implemented The trouble is, there is often very little attention paid to the effectiveness of these events. Ask yourself the following questions: What was the last tangible improvement to arise from a retrospective? How often do sprint reviews result in a revised release plan, ideas for more valuable features, or any form of change arising from new information that has come to light? During the daily scrum, are the development team truly in control of their plan for the sprint; taking pro-active steps if the plan is not going as expected? You don’t have the answers? If you struggle to find answers to these questions, then it is likely the time you are spending implementing basic Scrum practices is a waste of money. We’ve observed the following common issues getting in the way: Split accountability – meaning no single person is accountable for the present situation. Issues with your process come up time and time again, but the team has no authority or budget to resolve them. Business representatives are distant and/or stuck in traditional a project management mind set. Product owners are either constantly over-ruled and lack authority; or are senior enough to make decisions but busy running an entire department. Development teams are not trusted to own the technical implementation and, as a result, feel less accountable for organising themselves. Backlog items are regularly carried over from one sprint to the next with no questions asked, and there are no feedback loops to improve forecasting during sprint planning. The common trend in all of the above is a lack of belief at all levels of the organisation in the agile principles that underpin Scrum. Most organisations undertake an agile transformation with Scrum in order to gain competitive advantage, but unless the whole development organisation embrace the principles and not just the practices, then the results could be worse than before you started. Time spent in Scrum events, combined with the challenge of working in teams of mixed specialisms, will reduce staff utilisation without enabling positive change: What to do next? Option 1: Give up. Accept the fact that agility in not a good fit for your organisation, at least for now. In your conversation with the senior leadership team you may not convince them to accept fundamental principles – such as the advantages of responding to change over following a rigid plan. If this is the case, it would be more transparent and fair to the people doing the work to carry on with the established project management framework. Option 2: Fully commit. Organise a means of getting the Scrum team(s) together with the business and re-establish a sense of purpose. Ask questions like “should we be doing Scrum?” and if so, identify the drivers for achieving an agile capability that are specific to your organisation. Once a sense of renewed purpose has been established, the proper execution of the Scrum framework provides a foundation for addressing all of the problems outlined above. How to make it work: Build a culture of positive accountability At the heart of the Scrum framework are three roles, each with very clear accountabilities. A culture of positive accountability is built on a foundation of trust and respect; allowing people to challenge each other productively without blame. As a result, pointless meetings and long-term inefficiencies have nowhere to hide. Here’s how you can contribute to establishing such a culture: Scrum Master If you are a Scrum Master, you are accountable for managing the process and should feel empowered to draw attention to poorly performing elements. Make sources of apathy or disengagement visible and don’t allow people to avoid discussing awkward problems. Facilitate regular retrospectives to allow all elements of the process to be called into question and improved. Product Owner If you are a Product Owner, you are accountable for maximising the value of the product. Start by developing a clear vision and strategy for what your product should be and what outcomes you want to achieve in the medium-long term. Do not accept anything that is getting in the way of realising this vision. Hold your Scrum Master to account if the process is not supporting your ability to capitalise on market opportunities. Hold your Development Team to account if you are not getting good engagement from them. You should expect a collaborative relationship with good quality technical options, reasonably accurate forecasts (depending on size and complexity) and a professional approach to software quality. Developer If you are a Developer, you are accountable for building valuable, high-quality software. If you are not sure why a feature is valuable, ask your Product Owner to explain the business context and hold them to account if you feel something hasn’t been thought through. Push back with the support of your Scrum Master if you come under pressure to cut quality to hit short-term deadlines. If you see one of your team-mates cutting corners, hold each other to account within the team. Try to create a sense of pride and ownership in the product you build. Leader If you are a leader, you are accountable for the culture you promote and the outcomes that arise from it. Make it clear what you expect from people, and give authority and autonomy to the people that are accountable. Ensure that everyone has the support, training and opportunity to grow into their new roles. Demonstrate the behaviours that you want to encourage in your team such as openness and respect, while holding yourself and others to account. It is likely that it will take time to achieve high performance. Building a great team, just like building a great product, is best achieved in small, incremental stages. Scrum half-implemented in not an option! If you need help, then consider getting in touch to discuss an agile transformation package, or a bespoke engagement based on your specific needs.

We find this a common thread amongst our customer teams, which can be attributed to a lack of backlog refinement.

It is 1995 and Cyberdyne Systems are on the verge of launching their new automated military artificial intelligence software, CloudNet. “Come with me if you want to live!” cries Ant Schwarter, the enthusiastic Scrum Master, as he ushers the development team at Cyberdyne Systems into the conference room. Ant has been sent back in time from 2029, by the leaders of the human resistance, to save the human race from Judgement Day. Ant is no killing machine with a powerful exoskeleton, instead he has been skilled with humanity’s most powerful competitive advantage - business agility effected through behaviour driven development. “We’ve been struggling with re-work over the last three months”, explains Dyson – lead engineer on the CloudNet product. “The military say that it’s critical for maps in the war room to centre on Washington, not Greenwich. And all of the ‘fire missile’ buttons are the wrong colour. With current ways of working, we’ll never review, deliver and deploy on time.” “Glad you brought that up,” says Ant. “I’ve observed a disconnect between stakeholders from the Pentagon and the engineers building the system. I’d like to show you a new technique called Behaviour Driven Development (BDD), which can help us explore how software will behave BEFORE it’s built”. The door flies open and half a dozen men breeze in, medals gleaming on their immaculate dress uniforms. “I’ve invited the command and control team from the Digital Defence Network to our product backlog refinement session.” Ant adds. As they get down to work, Dyson introduces the first backlog item: Everyone agrees that this is a valuable feature, and that they’d all feel safer knowing that it was in place. “First, we need a list of all the scenarios that CloudNet (the product) might encounter. Then we can discuss how the system should behave in those scenarios” explains Ant. Everyone starts scribbling on post-it notes, and eventually the list is organised and de-duplicated: Ant leads the team to decide how the system should behave in each of these scenarios by breaking them down into their preconditions, the action that occurs and how the system should respond. Each scenario is an opportunity to expose assumptions and make decisions. Ant uses ‘We need to switch back to manual control’ as the first scenario. “Wait a minute” says General Buck Turgidson… “Who should have the final say over what is safe? Man… or machine?” “I just assumed you wanted the artificial intelligence to be the ultimate failsafe” says Dyson, biting his pen and gazing quizzically at a children’s playground across the road… (Note from the author: all names and references are fictional and any resemblance to persons, living or dead and/or incidents portrayed in this article are fictitious. No identification with actual persons, places, buildings, and products is intended or should be inferred)

As Agility in Mind launch our new training course designed to help distributed teams work effectively, we share our experiences on the reality of remote working, offshore development and virtual teams. Real life is about compromise Designing an effective IT product delivery capability is a complex problem involving compromise. It will never match up to the perfect world described in the training course or the management book. The system you end up with is the result of multiple conscious or unconscious compromises, evaluated on the basis of benefits or drawbacks weighed up against the cost and difficultly of not compromising. One such compromise is the decision to surrender the ease of communication and collaboration that comes with co-located teams. Some examples of trade-offs we’ve seen from our clients in this scenario include the following: Benefits Reduced operational costs. Proximity to customers or internal business units. Access to a wider range of people and specialist skills. Time zones allowing “follow the sun” support. Drawbacks Loss of spontaneous face-to-face communication. Distance to customers or internal business units. Time zones reducing time for whole-team collaboration. Meaning can be lost when discussing requirements. Difficulties and Costs in avoiding the need to compromise Teams are already in place and would be highly disruptive to move. Space is running out at the main site, putting pressure on desks. Compromise is only effective with accountability Crucial to making remote teams working effectively is to consider the whole picture and avoid optimising isolated parts of the system. We’ve learned from our work with Scrum that having a product owner with both the autonomy and the accountability to make decisions leads to the best overall outcomes. When making decisions about an organisation's software delivery capability, the best outcomes are likely to arise when decision making and accountability are not split across functions such as engineering, QA, facilities, and product management. The risk is that each specialism optimises their output: providing the required headcount in development; the most cost-effective office space; leaving product management constrained in optimising delivery. We’ve seen product managers unable to procure high quality video conferencing equipment as it would exceed the facilities budget; hiring decisions and team composition optimised to make line management easier; and many other examples where simplifying the reporting lines would lead to more cognisant compromise. How to make it work In practice, the following three simple steps represent the work required to achieve high performing offshore development teams: Presented as a hierarchy to highlight that unless the fundamentals are in place, processes and tools are unlikely to be effective. 1. Invest in people During a recent trip to Hyderabad in India we had the pleasure of working with a highly effective and disciplined software engineering department. An enviable characteristic was their staff retention: the office spaces were decorated with numerous five- and ten-year long service certificates, which matched the sense that people were happy to be there. Digging deeper, we found: A programme of regular technical and non-technical training A strong social element supported by company events Effective technical and people leadership by senior staff on-site By investing in this development office as a long-term strategic capability, this organisation developed an asset of significant value. When deciding upon how your development capability should be realised, think about how the people doing the work will become engaged and committed to your organisation. A significant advantage in geographically distributed teams is that you are no longer constrained to the skills available within commuting distance of your office. Investing in people starts with attracting the right people, and then setting up a working environment that allows them to thrive and want to stay. Consider which of the typical models might work best in response to your particular set of challenges and constraints: Home or remote workers Virtual teams distributed across multiple sites Individuals, teams or functions provided by a vendor or consultancy Partial offshore development teams staffed by full-time employees Complete offshore development teams including all skills and product leadership Each of these models has benefits and challenges – consider these as part of the whole picture. 2. Establish Purpose Teams are more productive when they understand the business context of the task at hand. It is obvious when working with engineers that care about the product they are building, through their interactions with the business, the quality of their work, and their ability to overcome problems. Teams that are simply given requirements to “code up” tend to be the same teams that spend a lot of time re-working features and fixing bugs. This effect is amplified when communication and visibility are made more distant. Remote teams with a sense of purpose will seek out and eliminate sources of ambiguity, whereas remote teams that are disconnected from the business risk becoming increasingly isolated and mistrusted. Decide for yourself which feedback loop will lead to the most effective delivery capability for your business: Establishing a sense of purpose should be led by product management in whatever form that takes in your organisation. Establishing a vision and communicating it to the team is a great first step. A sense of purpose is kept fresh through regular updates on changing market conditions, competitor activity, and the impact new features have had with customers or users. 3. Experiment with processes and tools There is no standard package that allows effective collaboration across time zones and locations. The only way to find the best available set of processes and tools to support your particular set of people, products and challenges is to experiment. Here are some of the immediate challenges to deal with and some of the tools that we’ve had success with: Talking to each other Google Hangout, Apple FaceTime, Skype are free services allowing video conferencing between two or more computers. We’ve observed laptops using these services being used to conduct daily scrum or stand-up events with varying degrees of success. Pitfalls to watch out for include low bandwidth, wasted time setting up calls, people forgetting to talk to individuals. All of these services have the facility to share screens, allowing planning tools or other artefacts to be worked on remotely. Cisco teleconferencing seems to be the established market leader in hardware based video conferencing. It provides the best experience we’ve observed for group-to-group scenarios in meeting rooms. The setup costs are likely to be of similar magnitude to funding one medium development team for 2 weeks. Other drawbacks include a lack of portability compared with a laptop, and the likelihood of contention over this limited resource. Slack is a modern chat application with a number of features designed to allow remote collaboration, some of which are free and others requiring a subscription. Some teams love it, others find it distracting. Managing work and storing requirements Trello is a free, lightweight tool allowing teams to collaborate around lists of things to do. Very easy to set up and use with no technical knowledge or training, but has no forecasting functionality. LeanKit is a subscription-based work tracking system built with lean and Kanban processes in mind. It is simple to use but provides many features for planning, forecasting and capacity reporting. Jira and TFS are subscription-based work tracking systems that support agile ways of working and are the most commonly used among our clients. The advice we most frequently offer in both cases is: keep it simple, and don’t waste valuable time creating complex custom workflows. Collaborating effectively Behaviour Driven Development (BDD) is a way for technical and non-technical people to speak a common language when deciding what to build. This technique is at the heart of our training course for effective distributed teams. Online Whiteboards such as Realtime Board can enhance collaboration by providing a visual stimulus during discussions on planning, design, analysis or retrospectives. Three Simple Steps? Invest in people, establish purpose, experiment with processes and tools. It should be that simple, so why is the reality so difficult? Compromise. In the hands of a pragmatic and accountable leader, compromise is a powerful approach that allows good solutions to surface quickly at the expense of time-consuming perfection. Most of the problems we’ve seen in practice with our clients arise from compromising the delivery capability in favour of politics, historic practices, or making sure middle management have something to do. The tools themselves are rarely the differentiator; more critical is the ability for everyone involved in product development to feed back into refining the best working arrangement for the situation at hand. It is likely that distributed teams will rely more heavily on process and tools, as spontaneous interactions need to be replaced with formal catch-ups. As we’ve seen, it’s important to get the fundamentals in place before defining the process: for the feedback loop to be established, people need to be engaged in a problem they want to solve.