Context switching is simply working on one project, then switching to another – where neither are worked to completion. I have heard people use a figure of twenty percent (20%) productivity loss as the “cost” that is paid for working on two projects at a time but have never seen where that number came from.
In trying to come up with a better answer for how costly context switching is for team, I found the book Software Engineering with Microsoft Visual Studio Team System by Sam Guckenheimer and Juan J.Perez, in which they describe a famous proposal by Gerald Weinberg in his book Quality Software Management: Systems Thinking. Mr. Weinberg’s book proposes the following as a rule of thumb to compute the waste caused by project switching:
|Nbr. Simultaneous Projects||Percent of Time on Project(s)||Time Lost to Context Switching|
While I do not know if the above numbers are 100% accurate, there is no doubt that as a developer working on multiple projects you tend to ‘leak time’ due to having to re-establishing the current state, where you were at, what needs doing, etc. each time you change what you are working on. But the books referenced suggest that this loss is more significant than one might initially think. The cost is especially significant when a team is working on more than two projects.
It has been said that one of the integral parts of programming is the fact that you have to hold a large amount of information in your head while you craft your code – wiping this clean, as if clearing a whiteboard, and then having to effectively re-draw it all again at a later date is undoubtedly costly and difficult. A skilled, well organised software craftsman can minimize this risk so that the effort to pick up where they left off takes a minimum amount of time, but they cannot remove the cost completely.
In The Multi-Tasking Myth blog post by Jeff Atwood, the following statement is made concerning both context switching and allowing too many distractions (meetings, email, etc.) to effect the team:
We typically overestimate how much we’ll actually get done, and multi-tasking exaggerates our own internal biases even more. Whenever possible, avoid interruptions and avoid working on more than one project at the same time.
To summarize the research around this topic, people are proven to be very poor multi-taskers. Switching from project to project is an extremely costly activity and should be avoided as much as possible. The timebox of the Sprint, that forces our teams to work on an agreed upon, fixed set of activities; and the rigor put in place by the accountability of the Daily Scrum allow Agile teams to avoid context switching to an extent. But even when our teams must switch from one project to another, the practice of not allowing changes to the ‘scope’ of a Sprint coupled with the concept of ‘thin slicing’ value allows the team to focus on delivering specific user stories and therefore, value, prior to moving their focus to a new set of activities. While these techniques allow us to combat the costs of context switching, the only real solution is to prioritize the team’s work, and Sprint on that work until it is complete. Only then can the team switch to a context without a significant cost.
I collect games and activities to demonstrate Agile concepts, Scrum, Scaled Agile Framework (SAFe), etc. Since I’ve been at Rally Software, I’ve led several, of what we call, SAFe Workshops. Basically, a group activity that leads groups of teams through release planning and the activities required of teams of teams working on Features for a release.
The following is a new activity that I found on tastycupcake.org that demonstrates why teams should be co-located. Distributed teams are an unfortunate fact of life, but the make things more complex – especially for new teams.
The goal is to create a children's book of 10-12 pages within 40 minutes using 2 to 6 teams.
Timing – 40-60 minutes
-Paper (20 to 50 sheets)
-Markers or crayons (1 box of 10 colors by team of 5)
- If you have the opportunity to do so, set up the room so that teams of 5 will already be together.
- Select one person in the room to be the creator, sit him/her in front of the room. Works even better if you have somebody you can give the book after.
- Explain roles and how the game will be played.
- Walk across the room, gives advice during sprint 1 but not sprint 2.
- Ask team how confident they fell they will succeed and why they should not for retrospective.
You will recognize the analogy there with Scrum roles vs specialties vs cross functional teams.
Creator (only one creator) – The creator is the one with all the answers. He is not a member of any team and is shared.
- Wants a Story that can be read to a baby and that the kids could be reading by themselves when they are old enough to read.
- Wants only one main character.
- Wants images and texts to be on the same page.
- Does not want the book to be more than N pages long.
Writers – The writers will decide what will happen in the story and write the script.
Illustrators – They draw the images, have to be consistent with the writers and editors choices.
Editors – Editors will decide on the overall look of the book, page orientation, grammar, consistency.
Teams are distributed
They need to sit as far away from each other as possible as if they were in different countries or even timezones.
And one last tip that could be really helpful
A children’s book can be simplified as the following…
- Cover page
- Rising action
- Falling action
- Lesson learned
Part 1 - Explain the roles and how the game is played - 5-10 mins
Part 2 - Planning (10 mins)
- Give teams 10 minutes to self organize and plan the work, knowing they will have to work together, split the work and listen to the Creator.
Part 3 - Sprint 1 (10 mins)
- 10 minute sprint to create a draft
- 5 minute retrospective (internal to the teams)
Part 4 - Sprint 1 retro (5 mins)
- 10 minute sprint to create a draft
Part 5 - Sprint 2 (10 mins)
- 10 minute sprint to create a final version.
Part 6 - Demo/Review/Retrospective (15 mnins)
- Review with the Creator, what does he/she thinks of the result.
- The whole group discuss about the difficulties they’ve had.
- Teams want and need to communicate to each other even when they are not in the same team/location.
- We “may” have trust issues and that affects quality and effort.
- Not knowing what’s going on at the other end makes some team members insecure. Teams are performing better when they have better visibility (trust).
- People not familiar with Scrum understand the challenges and how deciding to work with distributed teams has an impact.
1.lose or be without hope.“we should not despair – Agile metrics can save us”
synonyms: lose hope, abandon hope, give up, lose heart, lose faith, be discouraged, be despondent, be demoralized, resign oneself
If your Agile transformation is heading for an early exit or the ‘Valley of Despair”, metrics can save you. We all know that you can’t compare teams on the basis of velocity, but metric driven, objective decision making is possible and will make a tremendous difference. Rally Software’s Insights product is the best way I’ve found so far to collect metrics and be able to make fact based decisions about your Agile teams. Click this link for more information about Insights.
We all hate working with distractions, but new research from Michigan State University shows just how bad distractions can be—even if they only take a few seconds each.
Getting distracted with a separate job is one thing, but a new study shows that even a three second interruption can cause you to make more errors in your work:
The study, in which 300 people performed a sequence-based procedure on a computer, found that interruptions of about three seconds doubled the error rate. . .
“So why did the error rate go up?” [said Erik Altmann, lead researcher on the study]. “The answer is that the participants had to shift their attention from one task to another. Even momentary interruptions can seem jarring when they occur during a process that takes considerable thought.”
This isn’t completely new information, nor is it directly translatable to your work. However, it does show how important it is to create a distraction-free environment when you need to buckle down and work. Hit the link to read more.
Brief interruptions spawn errors | MSU Today via PsychCentral
I found this image in some notes I made while at a client site. I really like the way it lays out Scrum in the form of a Plan, Do, Check, Act cycle. The image organizes a tremendous amount of information in an easy to understand format.
The creator is Zen Ex Machina, who have an awesome web site.
I spend a great deal of time helping clients and prospects understand the challenges and enormous benefits to adopting Agile at scale. Most understand that starting from a blank canvas is a costly mistake, so adoption of a existing framework is important. Below is a very high level description of the major frameworks in use today.
Scaled Agile Framework (SAFe)
SAFe: SAFe is a popular agile scaling framework for “enterprise-class,” large-scale agile projects. It has great market momentum going for it, with extensive information available in the public domain, and training/certification programs from the Scaled Agile Academy and its partners. Approximately 80% of the organizations implementing Agile at scale choose SAFe. SAFe is a proven and publically available framework for applying agile-lean practices at scale. Many agile project lifecycle management tool vendors (such as VersionOne and Rally) support SAFe.
SAFe is often criticized, rather harshly and often unfairly, as being overly prescriptive and hence not suitable for many large-scale agile projects. It is important to remember that SAFe is a framework that requires customization to be successfully implemented in any organization. But even with that effort, you are better off using SAFe, compared to developing your own set of agile processes and practices from scratch.
Full disclosure: I am a certified Scaled Agile Framework Program Consultant (SPC) and assist clients with understanding and implementing SAFe every day.
Large Scale Scrum (LeSS)
LeSS: LeSS is regular Scrum applied to large-scale development. LeSS is developed by Larman and Vodde. A key message of Scrum is to avoid a cookbook of defined process. Realize that each team and each product will have to inspect and adapt their own Scrum adoption, which will evolve sprint by sprint. Therefore, the suggestions offered by LeSS are no more than that—suggestions. LeSS is, in my opinion, the least useful of the major frameworks.
Disciplined Agile Delivery (DAD)
DAD: DAD is a process decision framework developed by Scott Ambler and his colleagues. DAD is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value delivery lifecycle, is goal-driven, enterprise-aware, and scalable. DAD leverages proven strategies from several sources (Scrum, Lean, XP, Kanban, SAFe, DevOps, Agile Unified Process or AgileUP, Agile Modeling, etc.), providing a decision framework to guide your adoption and tailoring them in a context-driven manner.
Matrix of Services (MAXOS)
MAXOS: A relatively new agile-lean framework called MAXOS allows you to scale a particular type of agile methodology called “Continuous Agile,” where teams release working code several times in a day. In fact, after each change, the code becomes releasable shortly, thanks to automated testing, continuous integration, and developer-centric teams. All teams continuously integrate their code into an enterprise-wide common code base, with a very large number of automated test sets running continuously in a cloud computing environment. MAXOS is being used at many leading high-technology companies, such as Google, Amazon, Hubspot, and Edmunds.com. MAXOS is particularly well-suited for large-scale Software-as-Service (SaaS) for consumer mass markets, and for lean startups (based on Eric Ries’ Lean Startup methodology). MAXOS offers a radically different approach to scaling agile compared to SAFe but is far less popular than SAFe and, in my experience, difficult for existing ‘non-dot-com’ organizations to adopt.
I’ve had a number of conversations with clients about Spotify’s Agile Culture recently. If you haven’t heard about it or haven’t seen the videos about it, here’s one:
Spotify Agile Culture (Part 1): http://vimeo.com/85490944
Spotify Agile Culture (Part 2): http://vimeo.com/94950270