Advanced Scrum Concepts Tutorial
10.1 Scrum Advanced
Welcome to the 10th lesson of Simplilearn’s Agile Scrum training program. In this lesson, we take a slightly off-beat, critical look at adaptation of Scrum to different situations. Scrum is a very simple and light-weight methodology and realistically it can be applied in any situation. However, every situation has its own unique challenges which may not be addressed in the base guideline. Hence we talk about some best practices about how to adapt Scrum for large projects or maintenance projects (for example). These insights would be useful to have a satisfactory experience of using Scrum. Let us begin with the agenda of this lesson.
We will now look at the detailed agenda for this Chapter. We start off by looking at how Scrum works in different situations. Large projects, with large teams working on multiple sub-systems with complex integrations and interfaces presents some unique challenges. This is a challenging situation for any methodology, and so it will be from Scrum as well. We shall talk about some of the best practices that will help make this easier. We then talk about Scrum in “maintenance” projects. We then look at how to make Scrum work in distributed teams and we shall consider a few common scenarios to make it real. Then we look at how Scrum principles can be worked into contracts and how Scrum can work in different contract types. Lastly, we talk about the challenge of transitioning a team which is used to (and steeped in) traditional methodologies of Scrum. Again we look at few steps and measures that can help make this transition just a little bit smoother. In the next slide we will understand about Scrum on large projects.
10.3 Scrum on large projects
Scrum guide talks about small teams (7 + or – 2 members). So how will it work on large teams, with team sizes running into three digits at times? How does one deal with the multiple interfaces and integrations across sub-systems which are working together to deliver complex solutions? Let us try to address some of these questions. - The first step is to try and divide up the team into smaller units, each team working on a logical portion of the project. - The way to determine whether the division is “logical” or not is to ask the question – is this team capable of delivering some tangible customer value on its own? If the answer is NO, then you must perhaps think of another way. To help you think along these lines, a few examples of good and bad divisions are given. - BAD division: o Dev team and QA team: This is obviously an incorrect way of splitting up teams, because neither one can provide customer value o Regression team, Automation team: Within QA teams, sometimes there is a division created between manual and automated testers. This also does not make sense, because testers have to be savvy at both. o UI team, database team and server team: Again, this does not make sense, because having just a UI or a database does not provide any value to the customer. - GOOD division: o Platform team, Content team: While there may be inter-relationships between the two, both are able to deliver some added value to the customer o Deposits module, Advances module: Modular division is good, because each team can have their own backlog and work on them fairly independently (although we recognize there will be interfaces) - It is important to make sure that each team is cross-functional, i.e. has all the skills necessary to produce working software as only working software can provide value to the customer - There will be some stories and epics that will require work on multiple sub-systems, involving multiple teams. - Dependencies between teams have to be called out and managed carefully. We shall soon see how we can do this. - Some “look ahead planning” may be necessary, especially where there are dependencies. This means if we are likely to require some other team to deliver some functionality before we start working on it, then we need to provide advance notice to that team which needs to prioritize their backlog accordingly. Likewise, we need to recognize which other teams are counting on us to deliver something. - Let us now look ahead planning- sample in the next slide.
10.4 Look ahead planning Sample
This table provides a sample of an artifact that shows how to do “look-ahead planning”. While coming up with the release plan for any team, broad level features being delivered are shown. Also, the dependencies are called out both ways. This includes what the team depends on others for as well as other dependencies other teams have on us. This helps provide early notice to all teams about what is expected. The Product owners of the teams are expected to prioritize the dependencies ahead of others in the interest of meeting end-to-end use case requirements. We will now go through scrum of scrum, in the next slide.
10.5 Scrum of Scrum
Having identified the dependencies early through look-ahead planning, the teams still need a mechanism to make sure that those dependencies are being actively tracked and any deviations promptly attended to. The Scrum of Scrum is one such meeting. It is essentially a meeting that brings together all the scrum teams working together on the same application or product or teams that have active dependencies on each other. All the team members from all teams need not attend – just the key representatives. Typically, the product owners would attend because they need to make decisions regarding prioritization. The scrum masters may also be present, as they are aware of the status and specific challenges (if any) in meeting the dependencies. Other members who might be interested could be the architects, if the discussion is likely to be of a technical nature. The meeting need not be daily – typical frequency is once or twice a week. The focus of the meeting is on the inter-dependencies and coordination and making sure that each team is on track to meet their commitments to others. Next we will look into the Product coordination teams.
10.6 Product coordination teams
Product coordination team is another way to keep track of dependencies and interfaces. A product coordination team consists of team members drawn from participant teams who are given additional responsibility to coordinate across multiple teams. The coordination could be in the nature of: - Defining and elaborating the details of high level stories that run across multiple teams, i.e. which require work from multiple teams - Sorting out the technical details of the interfaces, defining the interfaces and potentially also the integration tests and mock interfaces to simulate the integration tests - Ensure consistency and uniformity of design and user interfaces - Get attention from the scrum masters and senior management if the dependencies and interfaces are not on track - Product coordination may not be a full-time responsibility for these team members. They may have other tasks assigned, but a part of their time is allocated towards the coordination role. - It sometimes works better than the scrum-of-scrums, because the responsibility is clearer and near real time, unlike meetings, which tend to be passive and reactive - Let us now talk about Scrum on maintenance projects.
10.7 Scrum on maintenance projects
Maintenance project is actually an oxymoron. While a project is meant to create something new or bring about a change, maintenance is all about maintaining status quo. So what is commonly referred to as a maintenance project is likely to be a combination of routine support activity and the implementation of some request for enhancements (RFE’s). Can Scrum be implemented on such projects? The answer would depend upon two related questions: - Can a clear, prioritized backlog be defined for the maintenance and enhancement requests? - Can the time required to implement the maintenance requests (which may be in the nature of triage, bug-fixing, etc.) be estimated with a reasonable amount of certainty? If the answer to these questions is in the affirmative, then Scrum can be applied in such circumstances, with the following tweaks. - While planning the sprints, allow for a larger buffer to take care of ad-hoc or unexpected events (such as a production outage which requires instant attention) - Alternately, split up the team into members who work on enhancement requests and members who take care of maintenance requests that arise on ad-hoc basis. The establishment of such a team (which may be called a resolution or sustaining team) will protect or shield the time of the team working on the new features from disruption. For more guidance, refer to the articles given. Now, we will learn about the Distributed scrum teams in the next slide.
10.8 Distributed scrum teams
Running a distributed team is a challenge. The reason to have a distributed team is often a business decision that is governed by availability of skills and/or cost. So there is no doubt that running a distributed scrum team is challenging, because: - Scrum emphasizes face-to-face communication, cross-functional team and close collaboration across teams - Some scrum rituals like daily stand-ups, sprint planning, reviews, etc. occur quite frequently and that would be challenging to organize across time zones. However: - Distributed scrum is still better than distributed waterfall - It is still possible to implement Scrum with distributed teams – with some best practices to help. - - In the next slide we will discuss on the best practices in distributed scrum.
10.9 Best practices in distributed scrum
Let us understand first of all, why distributed scrum is better than distributed waterfall. Imagine a situation where the team is spread out half way across the world (nearly 12 hours asay). In this situation, how would you prefer to work? - Give the teams large requirement documents and hope that they come up with the right product at the end of six months? OR - Build the product incrementally, with frequent checkpoints in the form of working demo of software – something tangible for the customer at the end of every few weeks that allow for correcting any miss-communications? The answer should be self-evident. Three important things need to be kept in mind while working in distributed teams and these are good practices in general (irrespective of methodology). - Apply/tailor Scrum practices to work effectively in this situation - Follow good software engineering practices to keep things tidy - Work hard on people-to-people equations. - Now, we will focus on Structure-1, that is Team in India; PO in US.
10.10 Structure 1 Team in India PO in US
To further elaborate on the best practices, let us imagine a hypothetical situation that the team is in a remote location like India and the Product owner is in the US. Suggested approach in this situation could be as follows: - Make sure the scrum master is with the team (in India) - Add visual element to meetings with the PO (web cameras or video conferencing) - Create a mailing list with the entire team and the PO. All project communications should have this list in cc. - One hour overlap is required between the PO and the team on a daily basis. During this hour, the PO should be available to the team to answer questions, etc. - Provide for a higher travel budget to allow for face time between the PO and the team members - Split up the Sprint planning into a pre-planning session followed by some offline analysis and then followed by the final planning session to determine the plan - The review and retrospectives should be conducted on Webex. - In the next slide we will go through Structure-2, that is Team split in two locations.
10.11 Structure 2 Team split in two locations
Another possible structure might be that the team itself is split up in two different locations. It could be split up along functional lines (developers/testers) or there could be a mix of resources in both locations. For example, a team that has a developer and 3 testers in India and maybe 3 developers and a tester in the US. Suggested approach in this situation could be as follows: - Appoint 2 scrum masters (one in each location). Since the teams will be smaller in each location, you would expect them to have a smaller workload - Have 2 different daily stand-up meetings with notes from each stand-up meeting read out at the beginning of the other stand-up meeting - Pay a lot of attention to people and team dynamics as distances will aggravate whatever differences and conflicts that naturally arise - Further, pick and choose the recommendations from structure-1 Let us now understand about people practices in distributed scrum.
10.12 People practices in distributed Scrum
We have been stressing a lot on people practices and team dynamics in distributed scrum. Let us now look at some best practices around these. - Developing good relations between people is absolutely critical – more so in a distributed team. People to people contact needs to be enhanced. This is more important in a distributed team than in a co-located team. - This requires “investment” on part of the management teams. It will not happen automatically. The investment is in terms of both time and money. So you need to invest in developing the relations and ensuring good communication channels. - You need to pay particular attention to conflicts getting out of hand. Disagreement is OK – even healthy. But the moment it translates into “other side is evil”, it becomes dangerous and must be nipped in the bud. - Allow for a higher travel budget (use some of the cost savings on this). Face time between team members is critical and irreplaceable. o Co-locate the key members of the teams for critical periods (like a release planning exercise or a beta test activity) o Rotate team members across locations periodically Organize cultural exchange and sensitivity programs. A good example of this is team wiki pages where people would share pictures, blogs, etc. Social networking has made this a lot easier At the end of the day, it is the people who make the project work and the people must learn to work with each other across time zones. A bit of face-to-face time, a bit of cultural sensitivity and respect, will go a long way in ensuring healthy team dynamics. Let us continue this topic in the next slide.
10.13 Practices in distributed scrum
Some more little things to keep in mind while working on distributed scrum teams. Make use of technology to increase the “touch and feel” aspect of meetings. - Invest in good web conferencing and video conferencing tools. - Make sure good speaker phones are available to make telephone conferences easier (head phones is not a substitute!). - Switch on the web cameras for any kind of interaction – even an Instant messaging conversation. Seeing somebody face-to-face makes a lot of difference to the richness of the communication channel. - Be sensitive to the timing of the interaction and vacation times of the other teams. For example expect that most of the India team will be away during Diwali or most of the US team will be away in Christmas. - Next we will learn about Scrum contracting in the next slide.
10.14 Scrum Contracting
A question is often asked whether Scrum impacts the contracting process and if the customer needs to know about Scrum at all. Alternately, how would you “sell” Scrum to a customer who may give you the freedom to choose an execution methodology? First, you ask the customer if he would be interested in these additional benefits (which Scrum will give you) - A demo of the working software every few weeks (potentially even an alpha or beta drop) - Unlimited scope to make changes to requirements as long as the team has not started working on the features Most customers would be delighted with this. However, you also need to tell the customer that: - They need to make be “available” to the team on a daily basis for interaction, clarification, etc. They may appoint a Product owner for this. - The team would be self-managing – no micro-management - They cannot expect instant gratification on change requests (for example – no changes in the middle of a Sprint). Let us now look into the figure in the next slide which will talk about the Fixed price/Fixed scope.
10.15 Fixed Pricefixed scope
Another common question that is asked about Scrum is how it would work within the framework of a fixed price, fixed scope project. While Scrum advocates being flexible and responsive to changes, these kinds of contracts actually make it tough to do that. Before we answer that question, let us try to understand what is meant by this type of contract. Basically in such a contract, the amount charged by the vendor is fixed, so his revenues are fixed. The profit reduces as the effort on the project increases, so in this type of contract the risk of cost escalation is borne by the seller. In the next slide we will discuss on Scrum in fixed price projects.
10.16 Scrum in fixed price projects
Here is the challenge: Scrum advocates being “responsive to the customer”. However, in a fixed price project, the seller needs to watch costs as the price for the project is supposed to be “fixed” (and so is the scope). Because any cost escalation will directly hit the seller’s bottom line, the seller has no incentive to be flexible with accepting changes. However, changes are inevitable and even necessary to ensure that the customer gets what he really needs. So here is how you would deal with changes in a fixed price Scrum project. - If the change requires additional time, you add more Sprints to the project and ask the customer to approve additional money to pay for it (just as you would on a fixed price traditional project!) OR - You would tell the customer can he remove some of the existing stories from scope in exchange for this new request. This would not have any cost implication. Since the Scrum team would be working on the backlog items in priority order, there would be some items that are yet untouched and therefore you can do this trade safely. Notice that in traditional projects, you would NOT have this flexibility because you would start with all requirements at once (first analysis, then design, etc.). So essentially, change management is needed even in Scrum (just as in conventional projects), but Scrum will allow you more flexibility to absorb the changes and align with the customer’s priorities. Next, we will talk about transitioning a team/project to Scrum.
10.17 Transitioning a team or project to Scrum
Let us now spend some time talking about how to move an existing team or project to Scrum. No change is easy. So we need to approach it systematically. The first step is to ask yourself the question – do you really want to do this? Ken Schwaber (who is the founder of Scrum) is known to have said “If waterfall is working for you, do not use Scrum”. He has also famously said “75% of people using Scrum are not realizing the full value from it”. What this means is – you should be clear what you are looking for by making this transition and find a way to measure it. Many teams have experienced this and potentially you can as well – that if you DO implement Scrum well, the impact on the entire organization is profound. So start on the journey of transformation anticipating that there will be some resistance, and do so only if you are convinced that this is a worthwhile journey. Let us continue this topic in the next slide also.
10.18 Transitioning a team or project to Scrum
Now we are going to discuss a simple five step process to guide you through the process of transition. Step-1: Start small. Choose a team or a set of teams who are willing to try it out and have an open mind about it. Also, do NOT start if the customer and senior management are not convinced. If you do not have these two important stakeholders on your side, you will NOT be able to make progress. It is OK if few people are skeptical, so long as their mind is open to persuasion. Last but not least, very early on the journey, try to find an influential champion or evangelist within the organization. Step-2: Understand what you want to achieve and define ways to measure it. Sell the potential benefits to the stakeholders, but do not go over-board with the selling hat. Also warn people it will be difficult and the initial stages will actually be very difficult. Step-3: Call this a pilot for as long as possible. This helps because pilots are expected to be messy and chaotic and this makes it easier to swallow the bitter pill.
10.19 Transitioning a team or project to Scrum
Continuing to discuss the five step process towards Scrum transition: Step-4: Be prepared to help. Do not expect teams to be able to resolve all the issues on their own. Give them education (trainings) and assign a coach or mentor to help them. As a mentor/coach, spend a lot more time with the people who HATE scrum. Somehow the bad vibes tend to spread a lot faster than the good ones. Try to achieve some initial successes and hype it up. Use it to gather momentum for the next stages of the journey. Step-5: Be pragmatic and understand that some people or teams will never like it. There is no point in forcing them. Be prepared to find other work for such people. Do not get drawn into lengthy battles with them, it will turn out to be a drag on your movement. Make it safe for people to admit defeat or change their mind later. Ask the question “maybe this is not what you expected, but at least is it better than before”? Now, we will move on to the next slide where we find few quizzes related to this lesson.
Let us quickly test our understanding of this Chapter through this quiz. Which of the following is NOT true about a Scrum-of-Scrum meeting? A- Scrum masters from each team meet on a daily basis B- It is a mechanism to coordinate work of multiple scrum teams C- It focuses on inter-dependencies D- It may not be restricted to the three questions that are asked in the daily scrum Answer is A: Scrum-of-scrums may not involve just the scrum masters and it need not happen daily. All other options are true. All of the following are good practices for managing distributed Scrum projects, EXCEPT: A- Use technology to enhance collaboration B- Define single point of contact for communication across sites C- Make meetings visual by using web cams D- Share time-zone pain while scheduling meetings Answer is B: Appointing single points of contact might actually stifle communication and is usually NOT a good idea. While splitting work across multiple Scrum teams, which of the following is the BEST distribution? A- QA team, Dev team B- UI team, Backend team C- Order management team, inventory management team D- Regression team, automation team Answer is C: Each team must be cross-functional and capable of delivering customer value independently. If the customer asks for a change while working on a Fixed price Scrum project, what is the BEST answer? A- Changes are not allowed in a FP project B- Changes are always welcome and free on a Scrum project C- If the change is to a feature we haven’t started, it can be free D- Ignore it as long as possible until the customer forgets about it Answer is C: If work for the feature has not yet started, then potentially it does not matter to the team and unless there is a marked increase in size, it may even be free of cost for the customer. As of now, we have come to the end of tenth lesson of agile and scrum which is on Advanced Scrum Concepts. Thank you for sitting through the whole of the agile and scrum course. Good luck in your exams!!!
About the On-Demand Webinar
About the Webinar