When you’re building toward an agile culture in your team or organization, what are the core principles that you should have in mind as part of your overall goals and philosophy? While perusing some older InfoQ articles on this topic, I came across this one by Darren Hale from last October:  Building an Agile Team.  I like the four key principles or characteristics his team laid out as important to the organizational culture they wanted to build:

1. A customer perspective;
2. Collaborating effectively;
3. Managing by fact;
4. Focusing on execution.

I think these points could be extrapolated to almost any organization that is trying to transform toward agile project processes.  Darren expands on these points:

A team that embodied these principles would be well positioned for success. Members of a team that embody these core principles exhibit a number of good behaviors. Some of those good behaviors are asking questions of customers, thinking like customers, being willing to ask for help, being willing to help others, making decisions with concrete facts instead of personal opinions, and striving to ship finished code.

Excellent observation.

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.

As mentioned in my post some weeks back, I’m now attending my Professional Scrum Master training course here in lovely Burlington, Mass. and have completed my first full day of sessions.  For the curious, here’s a few of my observations about how it’s gone so far.

First, if you ever do the PSM course in Boston with Schwaber, get in a day earlier and leave a day late.  The traffic up the I93 and over the I95 is horrendous.  And I don’t know what I’d do without a GPS – seriously.

Schwaber now has a permanent training room in a facility on 15 3^rd Ave. – you can tell by the “Scrum” lettering on the windows near the door.  Each day starts at 8:30 sharp, and in keeping with the philosophy of the Daily Scrum, if you are late you get to pay into a “Cup of Absolution” that is later donated to a charity of the group’s choice.

My session is well-attended, with fifteen attendees from all over the US, and one fellow from Sweden.  A common thread is that almost everyone has been using and applying Scrum within their organization and have their own stories about what’s been going horrendously off the rails for them.  It’s good to know that you’re not alone and have people who “speak the language” of a shared struggle.

We’re divided into “teams” seated at three tables – first exercise was to choose a team name, get to know each other and provide definition of Scrum and what we wanted to get out of the course.  Good as an ice-breaker.

After this we covered the basics of Scrum:  What it is, where it came from, the theory and first principles, how teams are composed, the key artifacts (Product / Sprint Backlog), Daily Scrum, product increment and transparency in project activity.  Interspersed throughout are exercises that help to emphasize the key values and illustrate good and bad approaches to the problem solving that Scrum requires.

Schwaber’s delivery style is definitely of the Socratic vs. Didactic approach, which is to say he doesn’t stoicly lecture, but introduces a topic, tells supporting stories and engages everyone.  Every so often you can expect to have a short, five-minute exercise to do with your team that usually sets up a topic that Schwaber expands on with some great anecdotes.  This opens the door for people to add their own experiences and gives the material greater context.

What’s impressed me most is that I’ve actually been learning new things about Scrum that I didn’t anticipate.  For example, we had a really interesting exercise that asked us if it was appropriate for a CEO to start a round of applause during a Sprint Review (it isn’t).  This brought to mind a story I often tell about one of my more successful Sprints where just such a thing happened, and it set the groundwork for actually demoralizing the team later on as they tried to get ever more adulation, but failed.

However, I think the most revealing thing I’ve learned so far is that I need to trust my teams more and that by interfering and helping them too much, I inadvertently create a dependency on myself that gives them an easy out.  It’s critical to let teams organize on their own and devise their own solutions – this cannot happen if you are continually holding their hands.  In fact, the team should be able to do almost all of the Scrum ceremony and practices without the Scrum Master.

Tomorrow we cover more in-depth details on planning, reporting, total cost of ownership, dealing with change, scaling Scrum and the Scrum Master role.  I’m looking forward to it – this is definitely the most worthwhile course I’ve taken in some time.

Yeah, I knew this would be the case:  I was just waiting for the other shoe to drop, and via the SharePoint PG’s Tweets, it was confirmed earlier today.  So here’s the juicy bit from the PG Blog:

Please note the important change from the 3:06PM update to this blog post.  We originally stated that SharePoint Server 2007 and Windows SharePoint Services 3.0 did not require the workaround to be applied, however, we have recently discovered through testing that a variant of the issue does affect SharePoint Server 2007 and Windows SharePoint Services 3.0 and also requires extra steps in the workaround for SharePoint Server 2010 (Steps 5-9).  Customers with these versions should refer to the relevant workaround below.  We will continue to keep this post updated with the latest guidance.

The workaround involves changing your error page .aspx and your web.configs and for 2007 an httpHandler.  Pretty serious stuff – ultimately, it’s about configuring your sites and farms correctly.

For more information:

Microsoft Security Advisory (2416728) - Vulnerability in ASP.NET Could Allow Information Disclosure

Security Advisory 2416728 Released – Microsoft Security Response Center Blog

Understanding the ASP.NET Vulnerability – Microsoft Security Research & Defense Blog

Important: ASP.NET Security Vulnerability – Scott Guthrie’s Blog

Frequently Asked Questions about the ASP.NET Security Vulnerability – Scott Guthrie’s Blog