Today’s business environment calls for speed but it also punishes the ‘move fast and break stuff’ model that was popular at Facebook, etc. previously. Creating the right value, at the right time is now the measure of successful, nimble organization.
Speed kills. Adapt or die. It’s the new world we live in.
I’ve been reading posts on netObjective’s blog. NetObjectives was founded by Al Shalloway – one of my favorite Agile movement personalities. I found a piece he wrote about how where an Agile transformation starts seems to influence it forever.
It’s an interesting read. I think you’ll enjoy it as well.
Based on his newest blog post, it appears that it’s time to welcome Ken Schwaber to the Scaled Agility party. Long a critic of ‘frameworks’ that provide a structure for scaling Agile processes through organizations, Mr. Schwaber’s latest blog post announces his newest offering – drumroll please – a framework.
Scrum is fantastic at the team level and Mr. Schwaber should be congratulated for driving Scrum’s acceptance in thousands of organizations worldwide. However, Scrum alone isn’t enough – simply creating Scrum teams won’t solve an organization’s largest problems (and will, in may instances, simply make the larger problem worse). Scaling Agility, via a customized framework like the Scaled Agile Framework (SAFe), will.
Agility at the organizational level allows the business, groups of development teams, and all other involved parties to understand priority, plan together, and delivery together. Scale allows organizations to focus on the creation of value – not in small, two week increments, but at the portfolio level. Ensuring that the portfolio level initiatives that make or save the most money for the organization are delivered first. It is these large, portfolio level initiatives that truly make a difference for an organization. And Scrum alone simply doesn’t address the organizational coordination that these large, multi-team, complex items require.
Setting aside all differences of opinion about Mr. Schwaber’s long held positions about frameworks, I’d like to offer him a hearty welcome to the party. Scaled Agility is a big tent – there is room for everyone – and Mr. Schwaber’s knowledge and ideas will help make Scaled Agility better for everyone.
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.