Video podcast with Jochen Krebs of the NYC Agile Users Group interviewing Ken Schwaber on the state of scrum and challenges for the future.  Good perspective to hear – definitely a message he likes to reiterate is that waterfall is in retreat, but agile teams are still failing in being “done done”:

I’ve been asked for my opinion on Kanban (pronounced “kine-bine”) recently, and I have to say my initial reaction when I see a Kanban board is:  “Wow.  That’s small-batch waterfall!”

Ken Schwaber (co-creator of Scrum) wrote a post in June that expands this observation:

I was told that Kanban is frequently used when an organization cannot readily adopt Scrum. Many of Scrum’s most difficult aspects are then sidestepped. Managers are still in charge of telling people what to do. People can be interrupted at any time. People are still work in functional silos, preserving the jobs of functional managers. People are not allowed to work in containers, sharing skills and knowledge to bring complexity into solutions – instead they are worked on a pull (more sophisticated than push) production line.

Lean is more productive than waterfall. Its transparencies and metrics allow frequent adjustments to optimize productivity. However, that optimized productivity is creativity when people are used to solve complex problems. People are worked like cogs in a machine, and their work is optimized at the bit level, rather than being aggregated into the value level.

God help us. People found ways to have slack in waterfall, to rest and be creative. With Lean and Kanban, those hiding places are removed. We now have a progressive death march without pause.

Not exactly something I want to get involved with nor be a part of encouraging teams to adopt.  By “slack”, Schwaber isn’t advocating being a “slacker” - rather that time-outs are important parts of being in an intensely creative and complex project.  Kanban seems to view its people as “resources” that are swapped in and out on a pull-basis through various phases.  The last refuge for those that can’t work in an empirically-based process or tolerate inspect and adapt cycles.

More importantly, what I find lacking in Kanban is any sense of purpose – with the container obliterated (ie. the “sprint”) so is the sprint goal.  So is the definition of “done”.  And thus, the “progressive death march without pause”.  I don’t know about you, but I don’t want to work that way – it diminishes the role of the team as collaborative problem solvers.

There’s a lot I want to relate about my recent Professional Scrum Master training that was delivered by Ken Schwaber– perhaps more than can reasonably fit in a blog post.  Initially, I thought this would be a refresher course for me – I’ve been an advocate for Scrum since 2002, so I knew the fundamentals.  However, to my surprise there were a lot of nuances that I hadn’t considered and some glaring gaps in my own knowledge.  For example, I have come to understand that I’ve actually been too involved with my teams, inadvertently creating a dependency on myself. I have to learn to step back and let them do their own thing more.

Below are ten lessons that seem to have “prioritized” their way to the top of my mind’s Product Backlog as I’ve thought over my experiences in the classroom.

1. Define what “done” means for your organization, team and project:  This trips up a lot of teams, including many of my own.  As a company and as a team you need a standard that clearly spells out when you are “done” implementing a feature.  Without this, teams are unable to estimate their work and say with any certainty what they can commit to completing for Sprint Review.  If you’re chucking quality under the bus every sprint, say so in your definition of “done”.  Put it on a poster in the team room in big letters to remind yourself that because you’re not doing it now, you will be doing it later.
   
2. People, not Resources:  This became a bit of a running joke over the two days of the course given how many times people would ask about how resources should be managed, resourcing issues, etc.  Ken would not-too-subtly remind us that we’re talking about people with a joke that we should go home and tell our significant others that they’re the most important resource to us in the world.  The point is that to refer to people as a resource is to try and homogenize them: They aren’t interchangeable parts.
   
3. Trust teams.  They’re adults, not children:  Non-agile software management rules attempt to corral, herd and then dictate to highly-paid, intelligent people what they should do to solve a problem – like they’re kids.  We need to trust teams to find solutions to hard problems, because they’re made up of (we hope) adults.  Let’s treat them as such.
   
4. Always make risks transparent. Always.  We blew what should have been a simple exercise on Day 2 of training that distilled down to not making our customer aware of risks in delivering a mission-critical application inside of four months.  We all chose trying to provide certainty where there were actually a lot of hidden assumptions. To illustrate our error, Ken related the story of going to a doctor to get guided through a surgical procedure.  The doctor would explain the procedure and the risks, options and alternatives allowing the patient to make an informed decision about whether the risk was worth it.  We should do the same for our customers – the risk is theirs to take, not ours.
   
5. The Product Owner is more involved than you think:  They just come in for the first part of Sprint Planning and Sprint Review, right?  Actually, they should be involved in all parts of the project except for Daily Scrum.  Sprint Planning? Yes.  Decomposing backlog items into tasks?  Yes.  Sprint Review?  Yes.  Sprint Retrospective?  Of course!  A more involved customer is a happier customer.  Conversely, Scrum may not be a good approach for customers who are disengaged.
   
6. Don’t ignore or dismiss team formation:  Set aside at least a day for a new team to get acquainted, set up their environments, pick a team name, establish rules for development and interpersonal etiquette and understand what it means to be “done”.
   
7. Scrum is a shovel that uncovers problems in an organization.  And then some:  It’s been said that because Scrum makes everything transparent, it causes pain when it surfaces everything you’re not doing well.  The good news is that allows your teams figure out how to address the pain and resolve it.  The bad news is that you can expect Scrum to uncover bigger problems down the road.  By itself, Scrum offers no solutions – only teams can do this.
   
8. Sprint Review is not the place for applause:  While many teams may take some joy in getting an increment in front of their customer for Sprint Review, this isn’t the time or place for adulation and “corporate applause”.  Sprint Review is an important part of new product development and planning, allowing both customer and team to inspect and adapt their work.  Treat it as such and go out for beers afterward.
   
9. Empirical process frameworks, like Scrum, require courage:  Kent Beck established “courage” as one of his fundamental principles behind his eXtreme Programming engineering framework.  The same holds true for Scrum.  Think carefully on this – it has more levels than an M.C. Escher drawing.
   
10. Teach teams to resolve conflict:  Teams working in an iterative/incremental way with Scrum will inevitably come into conflict.  Rather than avoid conflict at all costs, teams need to learn how to resolve their conflicts.  It’s not bad to have a passionate fight about something.  It is bad to take it to a point where feelings are hurt or a physical fight is about to break out.  Get them professional training to learn how to take the temperature down and resolve their issues.  This doesn’t mean a group hug or other kumbaya moments – it’s serious, bare knuckles, coming to better understanding with others.

Indeed - I had no idea this existed and from what Jeremy Miller notes, neither did a roomful of Microsofties:  Another secret from within the Halls of the Mountain King, I suppose - and a bit of the left hand/right hand syndrome. ;)

First glance, I like what I see:

• P&P "dudes" are actively involved in the site and development of materials, labs, articles and the like;
• The Agile Manifesto is mentioned front-and-centre - wow, I NEVER thought I'd see that happen. 
• Other community-driven tools are prominently featured on the front page, including CC.NET, NAnt, NUnit, NMock, RefactorPro!, etc. - Now, they do have to dedicate some space to shoehorning TFS into doing some continuous integration, which I'd never do - but it is a MSFT site;
• There's a link to material written by Venkat Subramaniam on agile design (he's the co-author of Practices of an Agile Developer: Working in the Real World) which is a positive vote for the Pragmatic Programmer community;
• Scrum and XP are featured prominently - and well they should be, beyond the fact that Ken Schwaber has authored a book for MSFT Press on Scrum which is in its second edition.

This is pretty cool to see - I'll have to sift through the materials before giving a final thumbs up or down, but if first looks are any indication it's a positive step in the right direction.  What I sincerely hope to find is a broader acceptance of Scrum, XP and the agile community-driven practices, and not the first step in trying to co-opt and coerce bastardized flavours of them into the MSF (yuck!) or somesuch.

Finally, I find it gratifying to see this on a personal level as it vindicates the tools and practices I (and many others) have advocated for years in the face of hostile opposition.  Memo to my former colleagues and bosses:  I hate to say "I told you so", but... :D