Famous Last Words

Webinar Events

Join us for a live webinar:
An Introduction to ScrumWorks Pro

Wed, Jan 7, 2009
10:00 AM - 11:00 AM PST
Sign up online »

Team members in Scrum

Thur, Jan 8, 2009
11:00 AM - 11:45 AM PST
Sign up online »

→ More Webinars

Famous Last Words

Submitted by VictorSzalvay on January 11, 2008 - 4:01pm.

One of the most common problems I observe in Agile teams is their inability (or perhaps unwillingness) to "swarm" on difficult problems to ensure an adequate solution. When I use the term “swarm,” I’m referring to multiple people working jointly to solve a single problem. Too often teams suffer from fuzzy logic, thinking, "Let's divide our resources to conquer the stories in this sprint more efficiently."

What's interesting is that I see teams fail sprint after sprint by employing this strategy. Yet they can't bring themselves to take the recommended course of action and swarm on stories until they are completely done. What's even more baffling is the unwillingness of teams to apply common sense to situations when "efficiency" is at stake.

Remember how in suspense/horror flicks the characters inevitably decide on a course of action that involves splitting up the group to overcome the adversity, whether it’s brain-starved zombies or chainsaw-wielding maniacs? There’s always a pivotal moment in the movie where one of the characters utters these famous last words: "Why don't we split up, so that... (insert absurd rationale here)?" Of course, everyone watching the movie is thinking, "Bad idea, you idiots! You won't stand a chance alone!"

It's common sense that facing big, hairy monsters alone leaves no chance for survival. Yet the draw of being "efficient" seems to win this debate every time, regardless of the empirical evidence against it. I suspect that until we let go of preconceived notions of “efficiencies,” the bloodbath will continue...

Re: Famous Last Words

Submitted by Mark Jean on January 25, 2008 - 7:34pm.

"Swarm" connotes each team member has similar capabilities & knowledge. Tasks can be moved quickly from person to person.

While it may appear "splitting up the group" to attack a problem is disadvantageous, it may not really be what’s happening. What often occurs is the person best suited to handle the task is given that task.

The guy or gal with the PhD in particle physics gets the particle physics problem.

"Specialization" isn't necessary in all products/projects - but it can often be absolutely essential.

Competent companies often *do* hire individuals based on specific sets of knowledge, skill & experience. Position descriptions are nearly always (in my experience) intentionally discreet.

While it would be great if the person doing GUI work could also do back-end development – if they're particularly well suited to GUI work (& love it) - why give them the database? If they’re not good at and don’t like it – won’t tasking them with it (or allowing them to sign up for it) create risk?

People have strengths and weaknesses. Yes - teams should continue to build their member's strengths and mitigate their weaknesses. Sharing work obviously builds competencies.

However, if a key task requires 12+ years experience in guidance control systems - or genetic algorithms - or telemetry processing - or (no kidding) particle physics – a GUI person just isn’t going to hack it. You need an expert.

All of the projects I’ve worked on had experts with specialized skills. There’s no way everyone could do everything.

Also, "stars" (experts) often need to float from project to project. (that’s Agile!) Therefore, they (the person – more than the manager) need to see what their total tasking is for the Sprint – for all the products/projects they’re working on.

Scrum is an Agile process. Therefore, it's also true "People before Process" applies to Scrum. If People work more efficiently on things they're knowledgeable about & love to work on, Scrum should not stand in their way. :-)

Swarming is not about generalist skills...

Submitted by MSaw on January 28, 2008 - 12:39pm.

Hold on, “swarm” does not imply anything about specialist/generalist approach. Instead, swarming is about queuing theory, prioritization, resource availability and throughput – where throughput is measured in terms of total completion of an increment of user value. (One totally completed increment of product has actual immediate value; whereas multiple slices of partially completed work has only theoretical future value.)

Swarming might best be expressed by these simple rules:

1) Only one story at a time can be the highest priority.

2) Team members should commit to tasks based on the current and near-term opportunities for serving the highest priority story.

3) If you are capable of serving the current priority, even if it outside of your area of specialization, you should commit to the task unless there is someone immediately available that can complete the task sooner than you can.

4) Park a low priority task and switch to the current high priority task whenever there is a demand for your skills to serve the highest priority story.

MSaw has it

Submitted by VictorSzalvay on January 28, 2008 - 2:40pm.

MSaw's response to Mark Jean's comment is absolutely right on. This isn't an attack on specialists or a suggestion that a specialist's time be ineffectively spent. Naturally, if a specialist's input is required it should be had. I once worked on a nuclear physics apps that required--low and behold--a nuclear physicist SME. Likewise, I didn't ask that physicist to code. That's not what swarming is about.

As MSaw points out, this is about queuing theory and all there is to learn from companies like Toyota (and their Toyota Production System). They've discovered over the past 80 years or so that new product dev is best when you get all the people needed to solve the problem working as single generative machine, rather than distinct stations in an assembly line.

Teams that fall into the "let's split up" trap should consider lean principles and come to understand the advantages of ditching the production line approach.

Mark, I am not recommending changing the way you are doing things to your detriment. If your teams aren't having this problem then no change is warranted. But your reaction to the suggestion is a typical one and demonstrates why this problem is so wide spread. Unless you really get lean principles, the suggestion appears to be counter-intuitive and almost scary. You feel like you're going to be less efficient individuals. That's the point of lean: sacrifice the efficiency of individuals for the effectiveness of the team as a whole production machine.

specialist twighlight zone

Submitted by CJ (not verified) on January 29, 2008 - 11:28am.

One project I worked on had an important complex feature that required new functionality on top of legacy code. A specialized programmer, artist, and designer accepted the work and they went off to make it happen. The team watched this task go sprint after sprint after sprint.

Looking back, I'd rather have seen the team gang up on this feature as much as possible. I think a) clearly defined minimum "done" goals and b) more people pitching in on those "done" required elements would have been better.

Flying & Swarming similarities

Submitted by Mark Jean on January 29, 2008 - 12:19pm.

CJ - if the SME dude was not providing visibility into individual tasks/status - he was behaving like the "very special fighter pilot" pursuing that "very elusive (difficult to bag) bogey".. "One more minute - I'll get him in one more minute....one more minute..."

When the next Sprint has come & gone & it's still a stalemate, time for the ScrumMaster ("bacon-master") to begin looking for the next dude with the high speed piloting skills (SME). Otherwise, "failure" looms on the horizon.

Looking back - each project I participated in had work requiring SME knowledge. In all of them, no one else on the project (or in two cases, the hemisphere) could hack what the SME(s) could. (Not unless they went back to school for a few years or decades.) The SMEs contributed very specific components of value (algorithms, tables, etc.).

MSaw - why shouldn't my SME dude/dudette work in parallel? EG, work on multiple tasks that require his/her specialized skills - especially if the work enables completion of components by the rest of the team? (Float like a butterfly - sting like a bee?) EG#2 - if the person with the specialized skills needs to contribute to 20 different components - and their work will not bring to completion 1 of them --- but none of the 20 can be completed without their work - and the components need to be completed in a specific order - why not allow them to "sting like a bee" on each of the components - per the priorities decided on by the team? (Timing is everything!)

Devoting the SME entirely to one story/task until completion may or may not be the optimal approach. People need agility to decide what's best. It's about balance & visibility & forethought (strategizing approaches based on what's occurring now).

Out of the blue - yet a third metaphor - "complex systems." What? Software development projects are often exercises in complex system behavior. That's what this "agile" stuff is all about - enabling better (strengthening) complex system behaviors.

Complex systems rely heavily on "feedback loops" - to enable strategizing next moves. (deliberately-humans -or- instinctively-earthworms) (Yes - worms are complex systems.) Who knows what will occur two moves from now? We have a general idea - but that's it.

It's the "orchestration" of the complex behavior that makes it work. (DNA orchestrates what occurs - but is itself adaptive) All of the components in the system work together (swarming) - based on their shared habits - for generalized & specialized behaviors (DNA).

Development methodologies (shared habits) make it possible to do a variety of things together well.

Features of complex systems - from The Oracle ;-) (Wikipedia):
* Boundaries are difficult to determine
* Complex systems are open
* Complex systems have a memory
* Complex systems may be nested
* Dynamic network of multiplicity
* May produce emergent phenomena
* Relationships are non-linear
* Relationships contain feedback loops

Mark Jean wrote: if the

Submitted by VictorSzalvay on January 29, 2008 - 1:51pm.

Mark Jean wrote:
if the person with the specialized skills needs to contribute to 20 different components - and their work will not bring to completion 1 of them --- but none of the 20 can be completed without their work - and the components need to be completed in a specific order - why not allow them to "sting like a bee" on each of the components - per the priorities decided on by the team?

The swarming concept is not strictly defined as everyone works on one story before finishing it completely before moving on to the next thing. Rather, apply swarming principles when you need them due to a failure to execute. Don't apply them to the point of impeding yourself. This is not a defined process... so your extreme example above is not a counter-example for why swarming is bad. You're just mis-applying the principles.

Swarming is a lean concept, so here is an example using your 20 components above:

Scenario 1 is that you maximize each individual's time. In this case, you have your SME jumping between projects. You have people working strictly to maximize their individual talents, etc.

In Scenario 2, you instead ask people to focus on finishing entire components, rather than worrying about spending individual talent wisely.

What you'll likely find is that your group produces more finished, working components under scenario 2 than under scenario 1. Why? Because the individual goals are aligned with the goals of the company (producing finished, shippable product).

That's it. There's no rule about SMEs sitting idle waiting for their team to finish every last detail. These are principles and a way of thinking that has to permeate your whole dev group. But if you can refute the effectiveness of lean principles as applied to software development, I think many of us would be curious to hear about it.

The gauntlet is down...

Submitted by VictorSzalvay on February 4, 2008 - 4:05pm.

Mark,
I appreciate your posts here, thanks for participating. As a guest on the site, I was going to afford you the last word, but in the face of your challenge, I'll respond :)

Your wrote:

Nearly all the teams I know at these places work within matrixed organizations. Nearly all work on product portfolios.

We currently work with the biggest companies in the world, nearly all of which have been able to adapt their software development processes to make room for Agile principles. Your description of the problem is not anything special or unusual. This is the case everywhere throughout the world. People are grappling with the out-moded and ingrained relics of the waterfall era. Basically, you're so screwed right now that you probably can't even consider swarming. That's OK, baby steps... start by getting more Agile first.

You should also know that we honestly believe there is no one-size-fits-all off-the-shelf solutions to problems like yours. You're in a complex mess. Your problems will be different then any of our existing customers' (the point of Agile is empiricism over defined processes).

One of the best techniques we've found is to commission a "pilot" Agile project. Carve out a team or two and let them work on "stories" as a Scrum team, rather than in functional roles on numerous projects throughout the enterprise. Get them a product owner and ScrumMaster. The results should be interesting: if they truly have autonomy to work this way, they will likely produce at an accelerated rate. This will perk up attention and people will want to know how they did it. That's the crack in the door to bring more of these ideas in.

This might sound basic, but it works to the extent that your organization is interested in actually improving and changing. There are certain companies that are too far gone. Others will change for the better in the face of strong supporting evidence.

Lastly, I think you're taking "swarming" not as I intended it. Swarming is a principle Agile teams use to make sure things get done (really done). You guys aren't even doing Agile, so it's inappropriate to suggest that you swarm. You guys should first get out of the matrix, form cross-functional teams, etc.

If you're serious about having one of our consultants visit you, please contact our service sales department (contact us menu). We'd be happy to talk to you guys.

Cheers,
-- Victor

comment deleted

Submitted by VictorSzalvay on February 6, 2008 - 9:33am.

Mark, I removed your last comment since it was a ScrumWorks feature request. I've responded to your request in the feature request forum.

excellent

Submitted by Anonymous (not verified) on February 26, 2008 - 5:20pm.

I've just read this, Vic, directed here from scrumdevelopment. Great post, and great discussion following. I have nothing to add... except to agree with you :-)

example

Submitted by MichaelJames on July 22, 2008 - 8:39pm.

Here's a video of what team self organization might look like:
http://youtube.com/watch?v=q1RqhRcPJZ0

While we can't see all the team members all the time, it's easy to observe a healthy mix of collaboration and working individually while within tapping distance of other team members.

Keith Sawyer's 2007 book Group Genius: The Creative Power of Collaboration goes into depth about how teams succeed or fail at finding that balance. There is indeed some work which lends itself to working individually and other work that benefits immensely from team swarming.

Also apparent in the video is goofing off and a sense of fun, also necessary ingredients for creative teams.

--mj

Comment viewing options

Post new comment