The goal of each iteration should be to provide value. This graphic illustrates it better than almost anything else I’ve seen.
Okay, that might be the oddest blog title I’ve ever written. However, I’ve found an amazing blog post that talks about the ‘smells’ of Agile done poorly.
Software Antagonistic Pleiotropy (easy for your to say) is a fantastic blog from Australia that I’ve been reading recently. Their tag line ‘Because what makes you stronger will also kill you” sort of sums up my feelings about the ‘Agile’ movement in its current state.
Here’s an excerpt from the first part of the Agile Smells series of posts that hooked me:
After seen Agile done well, and badly I started to become aware of “smells”. These smells are signs that despite of an Agile veneer, it’s not agile at all. A side point is that the word Agile has lost its meaning. It became this silver-bullet-buzzwordy thing and now it’s close to worthless. See, the point is not Agile, the point is to get better at developing software.
Here’s the link to the first in this fantastic series: Agile Smells. Read it. And go look for the smells in your organization.
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.