Agile Learning Labs

Kevin Thompson: "Deep Scrum"

We'd like to welcome Kevin Thompson's Deep Scrum to our blogroll. Why do we like Kevin's blog? Because of irreverent writing like this, from a post titled When Scrum is Too Much:

Let’s think about some examples of projects for which Scrum is not particularly useful.

I don’t use Scrum to make a cheese sandwich. I use a waterfall process, following a template devised long ago: I get out two pieces of bread, slice enough cheese for the filling, and assemble the sandwich.

I also don’t use Scrum to build a set piece for a play. Instead, I collaborate with as many other volunteers as we can reasonably use, and work on the piece until we have to quit for the day, or until it is done. After one or more work sessions, we finish the piece and move on to the next. This process is neither Scrum nor waterfall in nature, but bears more of a (rather vague) resemblance to Kanban.

So what do these examples tell us? Basically, they say that Scrum is much less useful when the work is thoroughly understood in advance, or when the delivery date is not specified, and not cyclic.

CSM: The reviews are in...

By Hillary Johnson

We're blushing. Drew Powers, the new editor of the SF Bay Area Chapter of the Project Management Institute's newsletter, attended our Certified ScrumMaster workshop in September and has written a thoroughly glowing account of the class, concluding that Agile is indeed highly relevant for Project Managers:

...while migrating from a traditional PM environment may require applying Scrum‘s mantra of "Do, Inspect, Adapt, Redo" to the overall organizational culture, I believe Scrum‘s potential for faster time to market of a high quality products that better meets clients‘ needs will prove itself in a relatively short period of time.

Powers also praised our experiential approach to training, and the "give and take" between our instructors, Chris Sims and Jeff McKenna, but perhaps the most flattering part of the review was Powers' summary definition of scrum. When a student leaves your class able to articulate what he learned this well, you know you did a good job with the teaching:

Scrum is a specific methodology within the Agile umbrella of methodologies that also includes Extreme Programming which are characterized by iterative requirements elaboration and product development. Scrum is based on several principles: Iterative elaboration of requirements, self-managing project teams in which the ScrumMaster acts more of as a facilitator than a leader, and a minimum of documentation. The Scrum mantra is Do, Inspect, Adapt, Redo – that is, give it your best shot the first time, learn from what you do, then do it again. It involves three major roles: The Product Owner, sometimes thought of as the Client, the ScrumMaster, and the Development Team, which may include architects and tech writers as well as coders. The Product Owner supplies and prioritizes requirements from a list of requirements called the Backlog. The Development Team determines which of the highest priority requirements they can bring to a customer-ready state (including QA and user documentation) within a development cycle, normally about two weeks to thirty days in length and known as a Sprint. The ScrumMaster facilitates the entire process, but it is key to note that the development team makes all key project decisions and manages itself. The role of the ScrumMaster is to remove roadblocks and enable the development team to focus on the project.

Thanks, Drew!

If this makes you wish you'd been there, join us for our next Certified ScrumMaster training on the weekend of December 5-6, again with Chris & Jeff.

What we learned from (teaching) our first Certified ScrumMaster class

By Hillary Johnson

Chris recently co-taught Agile Learning Labs' Certified ScrumMaster training course under the visionary tutelage of Jeff McKenna. Jeff, as you no doubt know, was a member of the first Scrum team, and he knows a thing or two on the subject. He and Chris worked well together. One student quipped, "It's like Chris is the Mom and Jeff is the dad." If your mom is a former lounge lizard with a beard.... No, it makes sense. Chris is the nurturer who wants to provide you with a safe place to learn to crawl, then walk, then run; Jeff, on the other hand, is the wise and wisecracking veteran of the front lines, with a satchel full of war stories--and riveting delivery. Having both in the classroom made for a fun, dynamic learning environment.

The students also generated their fair share of insights. We've taken to asking them to record their "Aha!" and "Eureka!" moments on Post-It notes, where they can be shared by all. This class of 27 people generated hundreds. Here are some highlights:

"Prototype your process, not just your product!"

"Dividing work into sprints actually relieves anxiety!"

"Agile may not be faster, but you'll know why things go wrong (or right)  sooner."

"Scrum is about creating a repeatable process."

"The daily stand-up is a communication meeting,  not a status meeting."

And my personal favorite:

"Time constraints force action."

We're looking forward to scheduling the next CSM class with Jeff, which will likely be held in early December. If you'd like to know when that happens, you can sign up for our mailing list. Like this one, it will be a collaboration with the SF Bay Area chapter of the Project Management Institute. If Chris and Jeff are mom and pop, then PMI's Community Relations guru Bill Dominguez is definitely the cool uncle.

If I'm doing Scrumbut, does that make me a Scrumass?

By Hillary Johnson

... or, enough already! Is Agile dead, alive, stagnant, the future, the past, the ultimate, the end, the Will of God? Am I doing it right, wrong, backwards, sideways, on a boat, with a goat? Should I get certified by the Scrum Alliance, or the Scrum Horde? And should I even care?

Let me back up a moment, to an aha I had a couple of days ago, while attending the Agile Alliance's reception in San Francisco, which was fun and interesting. The Alliance asked us to form small groups and lob suggestions at their draft roadmap. They were serious about it, too: each group had its own board member to listen and facilitate, and the groups' maps were collected to be used in the planning session on the 'morrow.

One fellow in my group worked for a company that is a leader in successful agile practice and has been for years. He said he wasn't going to Agile 2009 this year, nor was anyone else in his company. The main reason he gave was his feeling that the content of past conferences had been pitched too much at entry level practitioners and the adoption process, and that the cultivation of an expert community of practitioneers (as opposed to a community of consultants), wasn't given priority.

At the Orlando Scrum Gathering, the Scrum Alliance took a lot of well-deserved audience heat for making  "Scrumbut" a featured theme on their new website, including scrumbut curriculum (to their infinite credit they listened and acted, and the Scrumbut content is now gone). Meanwhile, the Scrum Trainers had their own, separate conference after the Gathering--but maybe they should have blended in for the benefit of all. Don't get me wrong, I loved every minute of the Scrum Gathering (full disclosure: Chris and Ainsley Nies organized the Open Space). My point is that I think that talking up to the audience, and thus raising the bar, is important to obtaining true buy in, and solves the same problems scrumbut is aimed at addressing. Think about it: when was the last time you listened to someone who was talking down to you, even if they were right?

Everyone wants to be a part of something cool that works. People sweat for two years to get an MBA because it offers them the path to a bright future, not because someone told them they were an ass if they didn't; likewise, when all is said and done, people will learn to practice agile because it makes them better, faster, stronger, smarter, not because it fixes something broken. Accordingly, I think that the conference that sets aside the corrective, remedial tone and charges forward into the truth, beauty and complexity of a brave new world is the conference we all want to go to.

Diana Larsen said we'd all be bowled over by the program at Agile 2009, and I believe everything Diana says, so it's possible I'm just talking out of my scrumbut and this has already come to pass.

Speaking of conferences and smart people, I get to see Kay Johansen tonight at our Agile Games Party (If you're in Portland, come join us!), and I'm looking forward to talking to her about the AgileRoots conference she's co-organizing in Salt Lake City in June, which also sounds packed with top-flight talent. Good times!

Do talentless hacks make the best leaders?

By Hillary Johnson

Journalism is a lot like software development (or anything else for that matter) in that it's common practice for top performers to eventually move into management, in large part because that also happens to be the path to financial well-being. The worst editors I've ever worked for, and I've worked for a lot in a 20 year freelance career, were genius writers turned editor. The best editors where those who had experience working as writers, but never felt that role was a good fit. Sometimes they had even failed as writers. As editors, these people appreciated and respected their writers precisely because: 1) they knew how challenging the job was, 2) they were never inclined to think they could do a task better themselves, 3) they didn't perceive themselves as having risen "above" those they managed, but as having taken a different path.

The point being, we're all talentless hacks at something, and the sooner we recognize it, the better we'll each be at what we're actually good at.

I was prompted to reflect on all of this by Alistair Cockburn's post about a recent discussion at the Salt Lake City Agile Roundtable where everyone offered up advice to a new team lead, ie, one promoted from star programmer to manager. It's a great collection of thoughts, listed as bullet points, including "In almost any high-skill arena, taking the top performers and making them coaches/managers is almost always a disaster." And, "How can we make it acceptable to promote the people who may not be the top technical performers?!?" Another mentioned the need for companies to create technical tracks that don't require one to move into management to move up.

All of this leads me back to the notion that hierarchy is a poor framework for knowledge work. The native structure of a productive creative team is the network, a system comprised of various nodes, gaining strength through interconnectedness. Think of it as a geodesic dome, rather than a skyscraper. A team need people in roles, rather than positions. What we have a hard time wrapping our minds around is the concept of manager as an equal, not a superior.

It strikes me that the role of Scrum Master is designed to function in this way, and it's interesting that one of the challenges people trying to grasp Scrum for the first time is wrapping their minds around the idea that the Scrum Master isn't a leader in the traditional sense, but a facilitator. Maybe it's the rather unfortunately macho term itself--anyone who calls themselves "master" anything can quite naturally be assumed to be a bit of an assclown. 

The notion of servant leadership is also aimed at correcting that very imbalance, but fails because it merely inverts the hierarchy, rather than dismantling or de-emphasizing it--it's still a hierarchy, and worse, it's phony. The only thing more arrogant than someone who calls themselves a "master" is someone who calls themselves a "servant." Sheesh!

What teams need are "peer leaders," those with a talent for human interaction who can be charged with maintaining the flow: a "Scrum Keeper" if you will.

Agile Ontologies: Why the customer is always right, even when they're wrong

Craig Brown voiced a common concern project folks have in "A Downside of Agile Development?" on his Better Projects blog, writing about his fears for his company's proposed transition to Agile:

I use a few online services, and you can tell which ones have adopted the philosophy of incremental product roll-out.

Just about every time you log in, there is another feature being promoted and presented to you for consideration.  Sometimes things you were used to have moved or disappeared.

This constant change makes some products less appealing than something that is more reliable.

There are valuable lessons to be gleaned here about what Agile is failing to communicate to customers. I like to think that the customer is always right, even when they're wrong, and if they're having a problem, then there is a problem. Brown is making visible a world view problem that is hindering agile adoption.

I left a comment on Brown's blog trying to reframe the question. Here it is:

This seems more like a web design  problem than a development problem to me. A product can be designed from the outset so that you can add to it without disrupting the work flows users have established. A top level menu system whose categories are general enough that you can fit almost any new feature under them, for example, allows you to release new features iteratively and allow users to discover what they need as the need arises. The problem may lie in treating each new feature as a "release" by shifting features around and making big front page announcements ala "Now with extra cleaning power!!!!" Constant improvement is not a series of events, and every addition doesn't need to be celebrated. Most of the time, it's enough to blog the new feature and move on. This is better than saving up features and doing a faux release. Why would you make an innovative new process mimic an obsolete process? Better to adapt how you think about the product instead.

I think I only captured part of my thought process in the comment, so here's the rest of it:

The takeaway is that often the resistance to Agile, or any other new way of doing, working or living, springs from underlying assumptions that aren't being unearthed and challenged. These assumptions are not ignorant--they are unconscious, and based on experience. As change agents, it's our job to challenge and persuade, not the other way around. For a customer who has lived through Vista or iTunes 8, and maybe a buggy beta or two of their own product, announcing happily that Agile will allow you to release every week will justifiably cause panic and soulful dread. Better to say, "We can make it so you never do releases. We build and test constantly behind the scenes, and add new features without disrupting your users' workflow. You'll never have a beta or a bumpy release to contend with."

Paul Graham wrote years ago that "...designing Web-based software is like designing a city rather than a building: as well as buildings you need roads, street signs, utilities, police and fire departments, and plans for both growth and various kinds of disasters." This high-level re-imagining is what Brown really needs to hear--he needs the shining city upon the hill, and for the leap of faith we're asking him to make in joining the revolution, he ought to get it.

Someone in the audience at the Scrum Gathering keynote last week reminded us that "A good trainer can lead a horse to water, but can't make them drink. A great trainer can make them want to drink." It's not enough to offer the customer better solutions and value, we have to offer them a vision of a better world; we can't focus on delivering processes and tools; we must focus on individuals and interactions.

All the Open Space topics @ Scrum Gathering Orlando 2009

Here, just to incite envy among the far flung, is a list of all the sessions posted on the Open Space market wall in Orlando. Disclaimer: These were handwritten, and often hard to decipher, so some titles and names are my best guess at spelling, and some sessions  may have been added or changed after I took my notes. Feel free to amend in the comments if you know better!

• How to size the backlog with diverse product and team member skillsets - David Fox
• Backlogs aren't perfect! Use story maps - Andy
• Discuss issues in multiple distributed offshore teams with FTE - Anon
• Dual Managers vs. IPM and ICSM on teams. Does it work? - Deb C
• Empowered scrum teams - Lee Heuser
• Transformation (what does this mean to an organization and culture) - Anon
• Scrum metrics and myths - Pete Behrens
• Fixed Price! Is it me or Agile/IP is a different thing altogether? - Anon
• Scrum and large number of external dependencies - Jorge Hernandez
• How do you coordinate large projects? 1st steps in scaling scrum - Dan LeFebre
• PMI (a pre-set session)
• What is the best way to organize your backlog? - Grover Trunell
• Scrum Anonymous - Steve Fram
• Where is QA gone? Regression platform test - Philippe Huert
• Applying scrum frameork  to solutions that aren't software exclusive - Anon
• Scrum Must Die! - Tobias Meyer
• How do you manage managers that are die-hard micromanagers? - Alfred Kauser
• Need feedback on design visions for releases - Raffi
• What are right sized user stories? - anon
• Beyond open space: what else can we do to innovate scrum gathering formats? - Krishan
• Virtual online scrum training and conferences - Dan Greening
• Wht is a certified scrum coach? - Roger Brown
• Creating executable specifications - Warren Elliott
• Interactive games for teams - Tobias Meyer & Chris Sims
• How I found Courage as an agile coach - Siraj
• How to incorporate front end/user interface design into scrum planning - Michelle J
• Anti-PMI - Anon
• Is the burden of technical debt dragging you down? - Philippe Kruchten
• How do you handle daily scrums when daily attendance isn't realistic? - Ram Bhat
• Effective approaches to sizing work across projects - Luis Morgas
• Sprint Artifcats - Denise Richards
• Secret Scrum (when the customers don't know) - Jody
• How can you capitalize software development costs with scrum? - Jason
• Sprint reviews: who are they really for? - Bob Schnitz
• Scrum and HR/Organizing for Scrum - Marites & Mikael Boman
• How to be a good scrum master? Boris Gloger
• SW Engineering in the 21st century - Alistair Cockburn
• Discuss and help improve small companies using scrum and CMNI - Anon
• Testing (traditional QA/QC) When does it happen? - Anon
• I want to learn how to tell if my product's enterpise quality within scrum - Ken
• Product owners: representing a diverse stakeholder community - Lowell
• Impelenting scrum.com using comic strips to start tough conversations - Mike Vizdos
• How to write agile contracts? - Anon
• Becoming a certified scrum practitioner - Anon
• Scrum on the boundaries - Michael Madden
• Backlog granularity and business value - Anon
• Scrum tools - Jody
• Use cases vs stories - Luis Morgas
• Games creation session - Alan Cyment
• BV engineering - Joe Little
• Agile analysis (grooming backlogs) - Luis Morgas
• Meeting others: Let's play werewolf! - Anon

People are tweeting the conference with #scrumgathering, and they're being pretty good about posting their notes on the conference wiki.

That's all, folks! Having a wonderful time, wish you were here!

This week on InfoQ - Information radiators: Is low-tech really better?

In this week's InfoQ article, Chris covers the debate over high tech vs.low tech toolsets (what Alistair Cockburn refers to as information radiators) for managing agile projects: eg, which is the lesser evil, killing a tree and taping its carcass to the wall one notecard at a time, or clicking through an annoying heirarchical menu every time you want to see your data?

The focus of the article is a discussion thread on the Xtreme Programming Yahoo Group, where topic is being contested with a great deal of heat.

There is a natural tendency among technologists to prefer technological solutions, but many of the debaters claim that experience has shown the low tech solutions to be best. Ron Jeffries says:

Display important project information not in some formal way, not on the web, not in PowerPoint, but in charts on the wall that no one can miss....A web site doesn't push information at us; we have to go look. A slide show always comes with a meeting and a lecture. A wall chart is there when we are, in our face, always visible.

This makes intuitive sense to me. I think there's something important about making the whole visible at a glance. Imagine how hard it would be to read a novel if there were one word printed per page--we read words in context, not in isolation. I think we experience projects much the same way, and it's important to always have a view of the gestalt.

The Agile Tools blog has an archival post that features pictures of several examples (as pictured) of both virtual and physical task boards. It's interesting to look at them and see which ones make you want to be on that project.

Don't talk about Scrum Club

This week Chris wrote his Monday morning InfoQ Article on Scrum Club, which organizes software developers to train in scrum practices (which can be applied to their Certified Scrum Practitioner requirements) by working on projects for charity. Their promo video looks eerily like something written by Chuck Palahniuk and directed by David Fincher. To call it irreverent is a drastic understatement:

How often do you see non-profits that are this in-your-face and edgy? And with no corporate constituencies to please, why shouldn't they be? I'm tired of charity work being seen as weak and warm and fuzzy. Clearly these guys are too!

Bees, Butterflies and Ultralight Backpacking: Thoughts on Creating Open Space for the Orlando Scrum Gathering

We met Ainsley Nies for corned beef hash and crab cakes at Peter's in Millbrae this morning. It was our second planning session for the Orlando Scrum Gathering in March, where Chris and Ainsley have been invited to host an Open Space for 300 agile souls, based on the strength of their performance as organizers and facilitators of last year's Agile Open California. I'm helping--well, mostly I'm sitting at Ainsley's feet in rapt attention, soaking up all I can about Open Space Technology, which I find fascinating.

A thought occurred to me while we were drafting the description for the conference website: how many structural parallels there are between OST and Scrum. Both have ceremonies. Scrum has roles, while OST participants may be described as "bees," "butterflies" and in some versions as "groundhogs." Scrum has artifacts, eg, the product backlog, the sprint backlog and the burndown chart. And OST has the Marketplace. Structurally, both are lean frameworks--they put me in mind of ultralight backpacking tents made with light, flexible but strong kevlar poles.

Ainsley and I had an interesting side discussion about the meaning of the word framework: We both think of a framework as providing strength and creating and holding space (like a tent), but it's a tricky word to use in a piece of writing, because many think of a framework as being rigid and restrictive.