TeamClock- Tastes Just Like Chicken

FaceBook has attracted pretty much the entire Class of 1973 for Rich East High School (Park Forest, IL). So I found the student director of the Spanish National Honor Society play I was in, only two suburbs away.

Steve Ritter is well and living in Elmhurst. Or Lombard. One of those two- the ones you can't get there from here.

Steve was one of the cool guys in high school, pretty much fit in every where and everyone liked him. Including me.

On re-connecting, we cautiously approached the other. Just to make sure the other guy hadn't weirded out. We're children of the 60s, remember.

Didn't happen.

So I invited him over for a music jam. He plays a mean guitar, much better than me- he's a little better than me on mouth harp and I'm a better singer- but he's the better overall musician. He politely refused the offer to join Acme Plumbing and Music (now called West Wind- I don't know what it means either and it's not half as funny as the original name...but I digress). Turns out he has his own band. Go figure.

Anyway...

Steve's doing a lot of consulting and has his own firm. He's even URL'ed himself: Steve Ritter. If I did that, my wife would stomp me. The best I can get is a subdomain: www.scot.witteweb.com.

It's my blog.

I can shamelessly promote myself if I want to.

Steve's been researching a book on team excellence. It comes out November 12th.

Now, I assume it's not a dreary textbook from his promotional tweets. It sounds much more like a cross between a motivational speech, The Agile Manifesto and a Team Dynamics For Dummies Book.

Tell me I'm wrong:

• Anyone still interested in following my tweets should begin following me at TeamClock. My work on breakthrough teams will be featured there.
  
• "Strong teams not only accept change, they expect and manage it in a proactive manner." (p. 53, Team Clock: A Guide)
• How, specifically, would you invest in your team if you wanted to increase trust and promote cohesion?
• Good enough or amazing? Breakthrough teams reach beyond the comfort of good enough to find new ways to invest, trust and innovate.

Steve hasn't sent me a review copy, and I'll have to wait until I get a job and bring the finances into alignment with the Age of Aquarious (it still is the Age of Aquarious, isn't it?), but it looks like Steve's years of research is going to support most of what we know and do in Agile Methodology:

1. We produce business solutions, not paper and documentation.
2. We find the hidden requirements by putting the product right in the business' hands so they can tell us what they want.
3. We expect and manage change up to and including implementation. Heck, sometimes we do it afterward even if we don't have a real iteration going.
   
4. Every member of the team is empowered to repair, suggest, assist and even clean up the war room.
5. The end of each requires the team to reflect and suggest changes to improve the process and the product.
6. Each team is self-managed. The Project Manager or Scrum Master's job is to remove obstacles from the team's way- not to manage. This eliminates a lot of chickenshit.
7. Agile development is test-driven. Our developers, business team members, design team members and management know when a feature is complete or issue resolved. It's done if it passes the tests the business imposes (and later on, the integration testing- after all, when coders change stuff, putting it all back together may create a new problem). This eliminates scope creep and finger pointing.
8. Agile team members 'parallel program.' That is, two developers grab a feature or part of a feature and work together for at least part of the workday. This isn't just a bonding experience- it enforces the sharing of knowledge and improves the end product. Heck, even us members of the Design Team (Business Analysts, Information Architects and Web Masters/Designers) can parallel program on GUI, wireframes and functionalities.
9. This may be the one place I'm betting we won't agree with Steve: Agile does 'good enough' development and documentation rather than superbly done. That's because the other methods have resulted in thousands of failed projects. Since we use working code and stakeholder/end user requirements from the beginning, small and medium sized projects are more likely to succeed, And if the business really wants 'superb,' we can do it, but we'll point out that two sides of the Project Manager's triangle will be out of proportion: Time and Money.

'Course I'm guessing what Steve's come up with and won't be able to read it until the 12th when he starts selling it.

But I'd watch his tweets if I were you. And buy his book when it comes out. Demand a copy at your local bookstore.

Steve's pretty damn smart.

I know.

We went to the same high school.

Powered by ScribeFire.