Jim Shore on what seperates high performing agile teams from just good ones

I found a talk by Jim Shore at the Dallas chapter of the APLNtalk on what separates the great teams from the average agile teams (it is over an hour long):

http://jamesshore.com/Blog/Secrets-of-Agile-Success-Live-Recording.html

Since I had no good ideas this morning I just took notes.

1. High Bandwidth Communication

High performing teams sit together. People complain that it gets noisy. Pair programming can help with the noise because the adhoc communication is less chaotic (mostly between pairs and not cross the table all the time). They also are cross function and have an involved product owner. Get real-time feedback on features and priorities. Without one the questions take more time to get answered correctly.

Teasley study shows that sitting together doubles productivity and time to market is one third:
http://www.sciencedaily.com/releases/2000/12/001206144705.htm
If you separate a team because of convenience is it worth the cost.

2. Passion

Cult of quality: the believe they are special and are accomplishing something special.

Talks about teams forming: http://en.wikipedia.org/wiki/Forming-storming-norming-performing. In his opinion it takes months, up to and over 12, to get to performing. As teams really form they are inwardly focused and from the outside they look weird. He warns that you should use cross functional teams to prevent this teamness from harming the organization. Sometimes organization break up the team in the norming phase, before performing. The fifth stage is adjourning (breaking up) and the team members will go through some mourning. The team will be naturally self organizing (teams take ownership of work).

Someone asks if you lose one member does it take another year to incorporate a new team member. He says one of two things happen: assimilation or rejection. One person states that sitting together can speed up the time to get to the performing phase.

There is a focus on continuous improvement (much like Lean's perfection principle). They have pragmatic idealism: you don't stop doing something just because it is uncomfortable or hard. (e.g. TDD - it can be hard in certain situations, high performing teams don't give in to the desire to short cut the hard parts - reminds me of a recent Tim Ottinger post). The ideals or principles are pragmatic because they directly relate to a goal (e.g. TDD is there for the goal of high quality or in Lean terms low Muda.) Regular retrospectives are the one thing he would recommend to any agile team that isn't - not just going through the motions but selecting an area to improve each time. He conducts them for an hour.

Marick's missing motivators: Marick states that the agile manifesto (that he signed) is missing four values:

• skill - good at your job


• discipline - don't cut corners


• ease at work - don't make it hard to do the job (remove obstacles)


• joy - enjoy your work

He states Scrum is good because it focuses on ease, but not good enough to get work done (I agree of course :-). Talks about distributed teams. He recommends Pubs & Planes :-) He references some research by Monica Yap (might be this: http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel5/10705/33795/01609825.pdf?arnumber=1609825) that shows how hard distributed teams are.

3. Lash of Jeffries

Running tested features on a schedule every iteration. Ship like clockwork. Requires that done means done (or as he says "Done-Done"). He means that even though all the work is done it isn't done until it is a running tested feature. IMO: There are often gaps in a feature if it is split among people. He says the velocity is rock solid and the features are nearly defect free. They prevent defects from entering into the product. Flickr deploys software every day!

Asks the audience if anyone has gotten to this point and the room was quiet for a while. One guy says they are just now able to deliver every iteration on a Monday (with Tuesday as a back-up in case of any defects found with the push on Monday). If the user isn't ready for a feature have the ability to turn off the GUI (but deliver the feature anyway) You don't want long lived branches in your code. Sometimes the team will overwhelm the business team. Isn't that a cool place to be! He states that the business will adapt.

He tells a story from his book about a team working on an embedded application. They had 60k LOC, 51 defects (over 3 years of development) never had more than 2 open defects at a time. Delivered software after 6 months and supported engineering as well as new features. They delivered 21 defects. Capers Jones statistics said a best in class team working on this size project would have had 461 defects, found 95% and delivered 23. The team above found only 59%. They prevented defects!

4. Agile Engineering

Great teams use agile engineering. He busts on Scrum again because it lacks AE. AE Practices are TDD, continuous design, rigor & mindfulness. Software engineering practices taught in school come from large and long DoD projects doing some version of waterfall or spiral. These practices can't support weekly or even bi-weekly deliveries. Great teams avoid technical stories (taking time off to refactor). AE doesn't require an A-team. He works with ordinary people in great teams.

He does think every team needs someone who is passionate about quality and pays attention. This person doesn't need to be senior but needs courage to speak up when things are going wrong.

He didn't plug his book, but I was impressed so I will. He publishes added stuff to his book every Wednesday here: http://jamesshore.com/Agile-Book/