Scrum Method-ist or Pragmatist?

I did not go to the Orlando Scrum Gathering, but fellow agile pragmatist Paul Ellarby did.

Paul regaled the work-a-day rubes back in chilly Minneapolis with several Scrum-lando poolside posts to our Practical Agility discussion board. Aside from presenting Nourishing the Agile Project, Paul reported to us about various panel discussions.

In one, panelists Ken Schwaber, Alistair Cockburn, Mike Cohn, Ron Jeffries, and Jim Coplien responded to the question

Would you hire a coach who is not a Certified Scrum Master?

Ken replied, in good humor

as what? -- but then indicated he would not.

Knowing how little effort it takes to become a Certified Scrum Master, and knowing that the Scrum Alliance will certify schlubs like this, the naive nature of this hiring question got me thinking about Scrum dogmatists and the state of this thing we call Agile.

Some in our Practical Agility group, including Paul Ellarby and David Hussman, have expressed ongoing concerns about Scrum dogmatists. Maybe that is part of the life-cycle of any cultural movement; people dig in. What was once liberating and exhilarating, degrades in the clutches of method-ists. Something that's exhilarating and reminds us we're human, gradually degrades to hollow ceremony and empty ritual.

Most everything I have learned about Scrum came from Markus Silpala. Thanks Markus. Following are some lessons I'll carry forward.

Human Lessons From Scrum

• Humans prefer democracy over dictatorship
• Humans prefer rowing in the same direction and grooving on the power of communal oar strokes.
• Humans find it easier to consume and digest a fat ham if cut it into bit-size pieces
• Humans have the intellectual maturity to self-organize
• Humans are most efficient when working with others in close proximity

Pragmatists are oriented toward the success or failure of a particular line of action, while mindfully resisting the seduction of becoming a hammer is search of a nail.

User Story a 2-bit Use Case?

A new member of Agile .Net Practitioners, a LinkedIn group I moderate, asked

When you talk about User Stories, how does that differ from Use Cases?

Alistair Cockburn said

A User Story is to a Use Case as a gazelle is to a gazebo

a catchy one-liner he later amended to

A User Story is the title of one scenario whereas a Use Case is the contents of multiple scenarios

A slightly better statement to which Jim Standley replied

...a story is a promise to have a conversation and a use case is the record of the conversation.

By all accounts Ward Cunningham coined the term User Story. By Ward's definition, a User Story is

...a story about how the system is supposed to solve a problem or support a business process. Each user story is written on a story card, and represents a chunk of functionality that is coherent in some way to the customer.

For those wondering how a User Story differs from a Use Case, see Ward's User Story and Use Case Comparison. A pithy excerpt from Ward's page comes from Alistair Cockburn:

"...Think of a User Story as a Use Case at 2 bits of precision. Bit 1 of precision names the goal of the use case, Bit 2 adds the main scenario. Bit 3 adds the failure conditions, Bit 4 adds the failure actions. Bit 5 adds data description of the in/out data. I would put Catalysis at a 6th bit
of precision, as they include a model also of the recipient of the message...."

My Story Paradigm

If a paradigm is 20 cents, here's a pair of dimes for you about user stories straight from the trenches of C-Sharpistan.

Following the advice of David Hussman, every developer's mantra could be to coax their business customers into "thinking and talking in tests".

For me, the most crucial item in a story is a list of business-stated test statements; preferably using mutually recognizable, and previously agreed upon, personae. For example, tell me, in concise, granular statements what “Albert the Anonymous Guest” can do:

1. Albert the Anonymous Guest may view a list of all groups that are internally designated as “Open Access”.
2. Albert the Anonymous Guest can filter groups by Subject Area.
3. Albert the Anonymous Guest can sort groups by Name.

These statements rapidly translate into unit tests like

• ViewGroupsByAccess,
• FilterGroupsBySubjectArea, and
• SortGroupsByNames.

What constitutes done is an ongoing challenge in agile. A list of business-stated test statements makes done rather cut and dried.

If my test harness can demonstrate and pass the aforementioned tests, the story is complete and Bob's yer Uncle.

Architects & Agile Like Zen Monks & Cell Phones?

I declare a prejudice traceable to my insecurities – I don’t favor organizational titles; in particular, the moniker Software Architect. When I read or hear Software Architect, I snicker.
“Are you too special to roll up your sleeves and get your hands dirty?” I sat in on a talk by David Hussman that was followed by a panel discussion. The talk was centered on one of my interests, evolutionary design (see my musings on evolutionary design and agile ennui).

David’s excellent talk was given in the context of agile and directed toward a large organization transitioning from waterfall to agile. The subsequent panel discussion consisted of 3 proclaimed Architects and 1 proclaimed Developer.

I was taken aback when evolutionary design was followed by a panel Q & A dominated by Architects.

Is Architect an anachronism in agile development like a Zen monk on an iPhone?

I asked the panel “Are Architects still relevant in agile development?” and “If so, what is the role of Architect in agile development?”

What I is learned is

Architects DO have a role in agile development.

The Role of Architects in Agile

Systems Integration - One compelling role is the need for someone to stitch together the over-arching quilt; particularly in organizations with distributed agile projects that have cross-project, cross-functional, and cross-departmental considerations. In that scenario, architects would track and plan - to use an old term - "systems integration".

Removing Technical Hurdles - It was pointed out that an architect might spike on upcoming technical challenges or potential blocks. I wondered why a team developer wouldn't do the spike, but it's a plausible role for an architect particularly if the spike has cross-project or cross-functional considerations.

Seed & Feed Backlog - The answer I liked the most was from an architect who said he believes his role in agile is to work with the business on seeding and feeding the backlog. For example, he might suggest the infrastructure that would need to be built to accommodate upcoming stories. I don't know how often architects work on backlog seeding, but I like the idea. Cultivating the backlog is one of the best ways to motivate and guide an agile team to commit to that proverbial drive toward the final destination.

Viewed in this light, an Architect is not gazing down on us from such a lofty perch.

Of course I would prefer more of an "elbow-grease" moniker for them like Systems Integrator, but I can live with Architect as long as I'm convinced they're rolling up their sleeves with the rest of us lunch-bucket developers.

Nuke and Pave Information Technology

Information Technology in your organization is like Homer Simpson.

Homer is too self-absorbed to fathom the depth of his deficiencies.

Homer has a fragile ego that makes him defensive about his capabilities. Homer is evasive and has redefined the term CYA.

As organizations realize new revenue from building information products for external consumption, and realize savings by building information and automation products for internal consumption, it is evident to most who rely on IT "services" that information product development does not belong in IT.

Product Development Doesn’t Belong in IT

There's a one-liner about the nose-to-the-grindstone students at University of Chicago in The Insider’s Guide to Colleges that says, The University of Chicago, “Where fun goes to die”. Information Technology, like students at The University of Chicago, has lots of hard workers, but

Information Technology is where what's possible goes to die.

IT is a place where professional naysayers gleefully inform you what can't be done. IT is the scourge of software product development in organizations throughout the world.

Software development in IT is like a fish in outer space.

Most IT departments can't - or refuse to - support continuous integration. As such, rapid product development is an ongoing frustration for business customers. In defense of IT, budget cuts probably preclude most IT departments from delivering acceptable customer service. That said, in the information product development space, there's no excuse for the turn-around time to push a build to any environment, including production, to be more than 2 hours.

Nuke And Pave

The term Nuke and Pave comes from an approach to product deployment made popular with continuous integration. It's the ultimate expression of a development team's confidence in its automated builds that it can instruct a server to deconstruct and construct the underlying database schema and data at a moment's notice.

If only we were as nimble with our organizations.

Following is nuke and pave fodder vis-à-vis the role of IT in information product development.

• Translate IT governance into an organization-wide agile governance for information product development.
  
• Move information product development out of IT and into a more suitable home like marketing. Or perhaps into a department called, eh, product development? Information product development would flourish in an environment that's creative, forward-thinking, and closer to the money-making part of the business (i.e., a what's possible environment).
  
• Focus IT on making sure everyone has a working PC with the applications and security access they need to do their jobs. This is a big enough job. Leave it at that.
  
• Decide what your IT organization can and cannot deliver. If your IT department can't deliver the hardware and services for your product development within a reasonable time, go outside. Vendors provide many of the services and hardware configurations your IT department monopolizes (e.g., servers, databases, source control, build and deployment tools). The difference is you've got leverage with vendors.