Category Archives: teams

5 Reasons Scrum Helps Teams Become High-Performing Faster

Scrum masters and product owners know how hard it is to get their team to become high-performing. They can rest assured that they’re on the right track. Scrum helps teams become high-performing faster than other work methods. The reason is simple. Becoming high-performing is baked into the scrum recipe. In my experience coaching agile teams, I have observed over and over that teams that use scrum go from forming, storming, norming and ultimately to high-performing more quickly and reliably than teams that don’t. Here are five reasons why:
Read the full article…

Share it!

Agile in California with QA in China?

After visiting a start-up that is adopting scrum, I received the following email from “B” and I’d like to share the answer here. As you will see, they are trying to be more agile, and wondering how to deal with their remote quality assurance team.

Hi, Chris,

Great agile session today. I learned a lot from you. Here are my two questions:
What is the impact of agile to the remote team? We have an outsourced QA team in China.
For the QA testing, how often should developers deliver a stable build to QA for testing?
Thanks,

B.

With part of the team in California and part in China, the biggest source of trouble will be communication. Of course, this is true even if you are not trying to work in an agile way.
Read the full article…

Share it!

What’s An Agile Paycheck Look Like? A glimpse into Agile Learning Labs’ new compensation model

What kind of agile training company would we be if we didn’t try to build our company from the ground up using agile methods for everything from team decision making to hiring to how we pay ourselves? Here’s how we arrived at a radical new way of paying ourselves. (Hint: if you’ve seen the heist movie Ocean’s 11, our team compensation model is a lot like theirs.)
Read the full article…

Share it!

Performance Review Pain Relief – The Agile Way

Performance Review Pain ReliefTake a piece of yellow paper, a slice of pizza, and a couple of guys with clipboards – and what do you have?

Last week – it was the latest gathering of the North Bay Agile Meetup group. The topic was “Performance Review Pain Relief.” So what would you do with that piece of paper –- write a performance review –- or make an airplane? At this Meetup –- we did both.

Led by Chris Sims of Agile Learning Labs and Harold Shinsanto –- we formed agile teams of expert paper airplane manufacturers. And in the course of producing some of the most embarrassing paper airplanes in aeronautical history –- the group explored what works and doesn’t work with performance reviews.
Read the full article…

Share it!

5 Agile Ways to Rock the Boat with Eric Ries

Eric Ries Interview by Lara Druyan at Hackers and Founders, July 2011According to Eric Ries, another way to say “agile” is “extreme troublemaker.” If you think you know what’s given, constant, and unchangeable — think again.

In an interview with Lara Druyan at a recent Silicon Valley gathering hosted by 106 Miles and Hackers & Founders — Eric poked holes in the foundation of entrepreneurial sense and sensibility we all “know” so well.

From his interview, my favorite five agile ways to rock the boat of status quo are:
Read the full article…

Share it!

Totem Poles, !Kung bushmen, the Love Economy, and you

Chris, with the Raven-Whale-Eagle team

Chris tweeted a picture of a totem pole this weekend, pointing out (via a link to Wikipedia) that the term “Low person on the totem pole” is a bit misguided–the figures on a totem pole are not, in fact, arranged hierarchically. Wikipedia also points out that the figures aren’t “idols” either. Both concepts, that of hierarchy and that of idol-worship, are but assumptions we bring to what we see.

This got me thinking: if we naturally assume that anything arranged vertically is a hierarchy, and that any figure is an “idol,” what other assumptions are we bringing to the teams we work in?
Read the full article…

Share it!

Does your office have a “living” room?

Our Conference Room

Agile Learning Labs started out as a home office, but as we’ve grown, I’d have to say that it has evolved into what I can only call an office home. Having started out with Chris and I occupying a two-desk office in what used to be a den, our workspace has now taken over the entire downstairs of the house, and we have several delightful people who join us here every day (some in person, some via web cam). I’m the resident interior designer, and when I first started laying out our expanded workspace, I envisioned a sea of desks and conference tables. But then during one of our company retrospectives, which we had been holding in our living room, I noticed how well everyone responded to getting to walk away from desks, phones and computers and sit in comfy armchairs while having a lively conversation in a humanistic setting, the way people do when they are just socializing. So I polled everyone, and it was unanimous: the sea of desks could take over the dining room, and any other available space, but the living room was a vital part of our office, the place for reflection and communication, and it would stay.
Read the full article…

Share it!

What Does Your Team Need? Girl Power!

By Hillary Johnson

Last weekend, Chris and I attended a marvelous event called Dare 2B Digital, aimed at addressing the gender gap in computer science careers, and at which 7th through 10th grade girls got to play at writing code, crafting business plans, and other techie things.

We held a session called "Teamstorming," leading a group of enthusiastic students in a series of the same learning games we use to teach teams of software developers on big, important enterprise projects to work together collaboratively.

We were completely blown away. The girls weren't just good: they were great. This was the most quick-witted, productive, outgoing and naturally cooperative group of individuals we've ever had the pleasure of teaching, by a significant margin. Chris and I have both mentioned to several people now our experience of finding the teenaged girls smarter, stronger, faster and sharper than their elders of any gender, and have heard a few theories about why this might be, the top three being:

They are unspoiled.
They are female.
They are female and unspoiled.

We laughed, too. But each of these notions has some merit. First, there is the unsullied youth theory: It seems patently obvious that many adults have a great deal of wariness, and weariness, to overcome before they are open to participating freely in a game-based exercise. Our teaching style is based entirely around games and simulations, and the younger a student is, the closer she is to the memory of learning almost entirely though play. It is not, however, particularly true that children are born collaborators, as any parent whose pre-school has a biter enrolled can tell you.

As for the gender question: Are females, by nature or nurture, better collaborators and problem solvers than males? To whatever extent our temperaments are deterministic, my hunch is that girls would respond better to the collaborative exercises, and the boys to the competitive ones. There is research-based evidence that there are gender-based differences in learning styles, but the same research indicates that the variation between individuals is greater than the variation between the genders.

So yes, the girls may benefit from being both female and unspoiled, but this doesn't mean they are superior to the male and the spoiled, it just means they're naturally suited to collaboration and have nothing to unlearn as they encounter collaborative situations.

But by adulthood, we are all engaged in activities that may or may not speak to our true natures. Girls don't tend to play with toy cars, but they grow up to drive real cars in the same numbers as men. And if you believe insurance companies' actuarial tables, they grow up to be the better drivers. On the flip side, I think this means that boys can grow up to be fine collaborators, as good as or better than their female counterparts, despite their greater inclination toward competitive styles.

I am not a big fan of determinism. Things do come out in the wash, and in the long run, even unlearning can be a productive process. As Chris will tell you, part of the reason he values Agile so much is that teamwork and collaboration do not always come naturally to him–he was once a boy who played with cars, after all. He has enjoyed being in a traditional leadership role, and can remember exactly what it was like to resist the urge to "help" a team, instead letting them solve their own problems through self-organization. Which is why he is good at teaching Agile techniques, especially to people who have a lot of un-learning of traditional top-down management styles to do.

The clear outcome, to me, is that the gender bias in the field of software development that persists today is entirely bogus. If boys have an edge when it comes to math–hence their delight in code–and girls have an edge when it comes to collaboration, then it seems stupefyingly clear to me that you're most likely to have a high-functioning team if you have both styles well represented, with plenty of room allowed for something even more important: individuality.

Share it!

InfoQ: Estimating Business Value

Chris' lastest InfoQ article surveys several other writers' methods for bringing business value to bear on Agile Estimation. Pascal Van Cauwenberghe points out, usefully, that Agile estimation techniques that put the user story first may be putting the cart 10 or 15 degrees askew of the horse: "Pascal proposes that a better starting point is with the question: 'How
do we find the User Stories that deliver the Business Values?'" My favorite, however, is Brandon Carlson’s application of Thin Slicing, a concept he discovered while reading Malcolm Gladwell’s Blink. Carlson writes:

The book cites an example of how doctors at Cook County Hospital
improved patient care and throughput using the technique. I thought to
myself, if doctors at Cook County Hospital can use a small subset of
relevant attributes to effectively prioritize patients in life or death
situations such as an ER, it could certainly be applied to even more
important decisions such as the prioritization of features, right?

Carlson describes how he turned a "sick" 90 minute weekly meeting into a hummingly efficient 30 minute process that got better results and left all the stakeholders more satisfied. The idea of looking to the Emergency Room for for triage practices that can help other businesses keep an eye on the vital signs is a brilliant example of the value one adds by reading across other disciplines.

Chris' article also has goodness from James Shore and Mike Cohn. Check it out.

Share it!

What Makes Distributed Agile Teams Succeed – At Agile2008

Greetings from Agile2008 in Toronto!

To say that I have been overwhelmed by the conference would be an understatement. With 1600+ agile folks here, I am constantly running into old friends, people that I met at previous conferences, and my agile heros. The sheer volume of knowledge and expertise that is being shared is beyond my ability to describe. Wow!

Tuesday, I facilitated a session titled:
What Makes Distributed Agile Teams Succeed (or Fail)?

The session drew about 15 people, almost all who have significant experience on distributed agile teams. As was the case at Agile Coach Camp, the level of experience in the room led to some rich discussions. In 90 minutes, we generated and ranked 25 success/failure factors for distributed agile teams. We used the Group Wisdom Without Groupthink process, which was fitting, as the keynote speaker at the conference was James Surowiecki, author of The Wisdom of Crowds.

Here is the ranked list of success factors for a distributed agile team, as determined by the group.

Tier One – The definition of “done”
This was brought up as the number one thing that derailed projects, or kept them on track. Having a well-defined, well-understood, and well-enforced definition of what it means to be ‘done’ with a story, can keep a team from getting mired in unexpected work near the end of the development cycle, and prevent the accumulation of technical debt.

Tier Two
Demos early and often
Onsite training
Executable requirements
Pride, ownership, and initiative from team members

Tier Three
Avoid “West vs. The Rest”
Daily standups – Doing whatever is needed to make them work for the team
Remote pair programming
Design for Conway’s Law
Everyone is present at iteration planning

Tier Four
Cultural training, including on your own culture
Determination to be remotely visible
Team task selection, just in time instead of ‘assigned’ at beginning of sprint
Video conferencing
Mixed experience levels on all teams
Awareness of cultural norms
(Hmmm, perhaps this and cultural training could have been combined. Perhaps they could have even been grouped with ‘West vs. Rest’)

Tier Five
Avoid time-zone blocks
(e.g. the Pune team can’t move forward because they need something from the Chicago team)
Some co-location, especially at the beginning of a project
Have the right team (hire people who will fit into the distributed environment)
Time-boxed stand-ups
Attention to iteration length
Daily, time-boxed design discussions
Don’t pretend the distance isn’t there
Give the ‘remote’ end of the conference call priotity in all discussions
(The idea is to pause all ‘local’ conversation whenever the folks on the conference call speak. It sounds simple, but it can have a powerful effect on how included they feel)
The “Buddy Concept”, each person has a remote ‘buddy’

You may find it interesting to compare these results with those for groups who have considered the question: “What makes agile teams succeed (or fail)?”
Dr. Dobb’s Architecture and Design World
Agile Coach Camp
The BayAPLN
The 2008 Chicago Scrum Gathering
P-Camp, a gather of Agile Product Managers
Silicon Valley Code Camp 2007
Agile Open California 2007

Cheers,

Chris

Share it!