Wednesday, November 26, 2008

Productivity of distributed teams

Jeff Sutherland and Guido Schoonheim recently gave a presentation on the experiences on forming a team for Xebia distributed between Holland and India. Their shocking conclusion: a fully distributed scrum team has more value than a colocated one.

They claim the benefits of distribution are cost reduction, availability of talent, and scaling up/down with knowledge retention.

They claim their approach accomplished the following results on a relatively complicated system with 100k+ lines of java code.
  • 95% of defects found within the iteration a feature was developed
  • only 50 defects found in acceptance phase
  • less than 1 defect for kloc
  • 15 function points delivered per developer per month. Note that Mike Cohn has published results of a small co-located team that achieve 16 FP/dev/month
How did they accomplish this state of hyper-productivity, as they call it? Here are some of the highlights.

  1. Bring the Indian team to Holland for 2 iterations starting the 2nd iteration. Establish personal relationships, shared agile value system, common mindset, mutual respect. My team at Envysion successfully used a similar approach; we had the Chinese team members on-site with the client for 2 months at the beginning. See my previous post for more info.
  2. A few people from each site travel to the other location every 2 months or so to maintain the bond.
  3. Staff with equally skilled people in all roles in both locations
  4. Use video conferencing for daily stand-up meetings, retrospectives and planning meetings. The sprint demo was done only by the Holland team because stakeholders wanted it presented in Dutch language.
  5. They started with a single team, then when they expanded to multiple teams, they seeded those teams with people from the first team to maintain the culture.
  6. They maintained discipline to follow XP practices, including pair programming
  7. Had a clear and disciplines Definition of Done for each sprint, which included 90% unit test coverage and fully automated functional and regression tests

Tuesday, November 18, 2008

Independent test teams

The agileprojectmanagement discussion group on yahoo has a recent thread titled "Testing Sprint Advice" that caught my attention. (Note that you'll need to be a member of the group to follow the link.)

I believe the ultimate goal of agile testing/QA should be the complete and unambiguous definition of acceptance criteria. The ultimate manifestation of that would be executable requirements defined by the product owner. Of course the product owner would create these in collaboration with testers, and including developer input as appropriate.

There is often debate over whether test teams are more effective when they are independent from the development effort or when they actively collaborate with developers. I personally believe the collaborative approach is better. If the product owner and QA collectively define unambiguous acceptance criteria, then the developers are usually in the best position to automate the validation of those criteria through automated tests of various kinds. Since it's hard to formally define every single acceptance criteria, testers can focus much of their effort on exploratory testing - which of course may leading to a better understanding of additional acceptance criteria.

Steven Gordan makes some great points in the post, arguing for the collaborative approach which I'll summarize below..

1. If the testers effectively come up with their own version of the requirements based on an "independent" understanding of the product, then inevitable disputes over the actual requirements for the iteration ameliorate much of the potential value of independent testing....

2. If the testers actively participate in the development of the acceptance criteria for the iteration, then where is the independence? If they are going to actively collaborate with the team and customers from day 0 of each iteration, everyone would be better off if they were actually part of the development team.

3. If the testers passively utilize the acceptance criteria for the iteration without actively voicing their independent opinion about what is missing from the acceptance criteria, then we get the worst of cases 1 and 2. The testing is not truly independent, yet what independence remains is not being leveraged to improve the acceptance
criteria.

Inevitably, independent testing finds problems later than
collaborative testing would.
Thanks to Steven for the great insight.

Saturday, November 15, 2008

The SEI addresses Agile

The SEI recently published a paper that asks the provocative question: why not embrace both agile and CMMI? In an earlier post, I wrote that Perficient achieved level 5 using an agile approach, so I know it is possible.

Both CMMI and agile have a long history, it turns out. Although modern agile methodologies mostly emerged in the 1990's in the context of small teams, maybe the origins of agile and CMMI really weren't so different after all.

The paper traces the roots of agile back to Iterative and Incremental Design and Development (IIDD), a technique developed more than 75 years ago by engineers including W. Edwards Deming. It's also noteworthy that Demind is one of the fathers of the lean movement who is credited in part for bring lean to Toyota many decades ago.
An early progenitor of IIDD was Dr. W. Edwards Deming who began promoting Plan-Do-Study-Act (PDSA) as the vital component of empirical engineering. Early adopters of Deming’s teachings in the aerospace industry include NASA (National Aeronautics and Space Administration) and the US Air Force, each of which developed entire systems using time-boxed, iterative, and incremental product development cycles.

Origins of CMMI
everyone working to develop the initial CMM was looking for the solution to the “software problem” from the perspective that software is a component of a larger system and that if it failed, lives would be lost (e.g., aircraft, ships, weaponry, medical devices).Systems were evolved using careful and deliberate development paths according to lower risk,standardization-heavy and contractually-driven relationships between the developer and the customer.
The paper does a good job of explaining some of the reasons why the 2 camps are often at odds, which includes the fact that both approaches are often misused, which adds fuel to the fire.

Here's a paragraph that summarizes the paper's conclusion.
Agile methods provide software development how-to’s, purposely absent from CMMI, which work well on small co-located projects. Meanwhile, CMMI provides the systems engineering practices often required on large, high-risk projects. CMMI also provides the process management and support practices (and principles) that help deploy and continuously improve the deployment of Agile methods in an organization regardless of organization or project size.
I tend to agree, except that agile approaches can also be successful when small teams aren't co-located; I know because I've done it.

A final quote, reminiscent of Rodney King's famous "can't we all just get along?"
If those of us in both the Agile and CMMI camps would understand and accept our differences and explore the advantages of the other, we will find new ways of combining the ideas of both to bring improvement to a whole new level. Our challenge to CMMI and Agile proponents alike is to learn the value of the principles and technology of the other and begin to use them in their work
In my opinion, CMMI is too often misued to force a heavyweight, waterfall methodology on an organization for the primary purpose of marketing the organization's supposed capabilities rather than truly improving the organization's capability to sustainably produce business value for customers. That's why I will probably always be leary of any CMMI initiative started by non-engineer management folks.

Tuesday, November 11, 2008

Can a customer support team be agile?

Mattias Skarin recently posted a useful 2-page summary of his approach for managing a support organization using agile techniques and a kanban board.

I recently led a team of Solutions Consultants (who supported our customers development efforts) at IP Commerce. The challenge we had was that there was ALWAYS a full backlog of customer support tasks, and those tasks are virtually always a higher priority than project-based work that the team needs to get done - stuff like improving the process, creating sample applications, writing documentation.

What I did to solve this dilemma was to allocate 20% of each person's time for project work, with 80% for ongoing customer support. The team members scheduled their time to carve out 4 or 8 hour time blocks during the 2-week iteration where they could focus on project work.

For iteration planning purposes, I kept a backlog of project-based user stories only - no customer support tasks - and the team planned how much of that backlog they could knock out in 20% of their time. The customer support stories/tasks weren't considered during planning - we knew those would flow in steadily.

This worked well for us, but let me know if you have other advice on managing support organizations.

Wednesday, November 05, 2008

Agile in the Extreme

What happens when you take agile techniques to the extreme? At the Agile 2008 conference, a couple of Aussies, Paul King and Craig Smith, gave a presentation titled Technical Lessons Learned Turning the Agile Dials to Eleven. You gotta love the reference to Spinal Tap!

Back in my days at BoldTech Systems (now Perficient), we did hard-core XP. I mean hard core. We all had tables on wheels, no cubicles, no walls - the whole team in a "bullpen". We strictly followed all of the XP practices, and if we didn't, the VP of Engineering who was the uber-XP-Coach, would quickly swoop in and set you back on the straight an narrow path.

Some valuable lessons we learned:
  • Pair programming for 100% of production code isn't optimal. Many programming tasks are just too routine to justify it. For those, do frequent (at least daily) code reviews. Save pair programming for the tough stuff.
  • 100% pair programming can be exhaustively intense. How many people in this world do you really want to sit shoulder-to-shoulder with for 8 hours a day? Or 4 different people for 2 hours per day? Most developers I know need some time to work alone to keep their sanity.
  • Continuous integration requires an enormous amount of discipline. If you have to stop everything whenever a single test breaks, and you're writing lots of tests, you better not have very many tests fail.
  • Don't forget to do design. XP doesn't emphasize design, but it doesn't preclude it, either. Do just the right amount of architechture and design - at the beginning of a release and each iteration.
  • Test driven development is good. Period. Go ahead an turn the dial to 11 on this one!