Agile Learning Labs

ACM Says: Agile Changes the Project Manager's Role

By: Chris Sims

In my research for an upcoming article, I ran across this tidbit that I just couldn't wait to share. It's from Challenges of migrating to agile methodologies a paper originally published in Communications of the ACM.

Agile methodologies require a shift from command-and-control management to leadership-and-collaboration. The organizational form that facilitates this shift needs the right blend of autonomy and cooperation to achieve the advantages of synergy while providing flexibility and responsiveness. The project manager's traditional role of planner and controller must be altered to that of a facilitator who directs and coordinates the collaborative efforts of those involved in development, thus ensuring that the creative ideas of all participants are reflected in the final decision. The biggest challenge here is to get the project manager to relinquish the authority he/she previously enjoyed.

Find out what this really means, and what it feels like to do it, at our upcoming Agile Project Management learning lab, presented in cooperation with the San Francisco Bay Area Chapter of the Project Management Institute.

Cheers,

Dogs learn agility with tennis balls; so do we

by Hillary Johnson

The very first exercise of our two day Agile Project Management class on Monday taught me a few things about optimization. It's a ball passing game, where the group is tasked with devising a system for passing balls around such that every ball is touched by each person, and has "air time" in between--ie, it's tossed, not passed.

On their first try, this group passed a whole mess o' balls without error. In their second iteration, they did even better--better than any prior group, and we'd run this game a lot. Could they improve on what I percieved as perfection?

They could. Chris tasked them with achieving "revolutionary process improvement," which proved the spur--and as the product owner, he "invested" an extra two minutes in iteration planning. They doubled their productivity in the third and final iteration. Still no errors, I might add. If anyone is looking to hire a crack ball-passing team, I've got one for you.

What did they do so right?

They didn't mess with what worked. "Let's stay in our positions, as we're used to the behavior of the person we've already been passing to."

At the same time, they did not settle for incremental improvement, but looked for the leap--"Can we keep our process the same, but pass two at a time instead of one?"

During their planning phase, they did more than they talked, trying things out. "Talk is cheap," one of them said.

When they did talk, it was to inquire. "What are the questions we should be asking," another said at the outset of the third planning round.

The debrief elicited a lot of good stuff, too:

"Since we had no drops, I wonder if we weren't being too risk-averse. We might have had more productivity if we'd allowed more error."

"Haven't we all been in places where a lot of attention was given to optimizing writing code, when people spend 5-10% of their time writing code, and the rest looking for bugs."

"It's exhausting to work on a project when your sense of owner is greater than the owner's."

"We all spend a lot of time grousing about what the people upstream are doing, and seldom give any thought to the people downstream from us."

"Is there such a thing as too much optimization?"

Sound fun? Come play on August 3 & 4, when we'll be running the same class at the Alliance Francaise in San Francisco--vous etes tres agile, non?

Ruby on Rails for Beginning Brain Surgeons

By Hillary Johnson

I've been teaching myself Ruby on Rails of late, and as such am getting a good dose, right here in the Learning Lab, of what it's like to learn something new at the ripe old age of 45. I'd say half our clientele is my age, so this is especially useful data.

I started, of course, by struggling through all manner of introductory texts and video tutorials, and I finally re-learned something I'd always known: When you undertake to aquire a skill, any skill, it's not necessarily a good idea to start with an "introductory" text. Why is that?

Your average introductory text says things like, "All you have to do is put tab a into slot b--but be extra careful while short-tacking not to overhaul the sheet or you'll be late flopping the genny and end up in irons." Whaaa? (If you'd taken sailing lessons from me years ago, you might have suffered such advice) The problem with "introductions" is that they're always authored by experts whose expertise does not extend to explaining things. So you get dumbed down instructions with no rationale, often using opaque lingo. They're always bizarrely over- and under- pitched. If you want to learn from the experts, read what they write for each other.

Pick up a text aimed at the "expert" level, and suddenly you find yourself eavesdropping on the real thing, and if you listen patiently, you can learn why something works, which for me is the only way to remember how to do it.
I finally got a sense of the why and how of Rails reading the first chapter of Obie Fernandez's The Rails Way--which a lot of people warn beginners not to attempt. This after several frustrating attempts at self-education through primers and introductions that left me feeling like Ben Stiller in Tropic Thunder when Robert Downey Jr. clued him in about how it's never a good strategy to go "full retard."

Similarly "above my head" are Ryan Bates' Railscasts. I learn maybe 10% of what he's saying each time I watch one, but they're so dense that 10% is quite a lot.

We've talked and thought a lot about the problem of teaching to all levels here in the Lab, and part of the reason Chris has evolved his teaching style to rely on exercises and simulations over lectures is that every level of participant gets something out of the interactive experience, while lecutre material is always either over the student's head, under it--or more commonly, both.

Postscript:

The title of this post is a bit of an homage to one of my favorite texts, Baseball for Brain Surgeons by Tim McCarver, a book that conveys utterly the mystery of baseball by delving fearlessly and lucidly into the mechanical and dramatic intricacies of the sport. The reading of it is punctuated by ahhh!s and ohhh!s and tingly now-I-get-it!s.

Story Sizing: A better start than planning poker

By Chris Sims

I've helped several teams adopt the practice of planning poker. It's a good and useful practice, but it’s about as beginner-friendly as Badugi.

The problem is that planning poker is a lot about numbers: “Is this feature a '5' an '8' or maybe a ‘13’?” New teams have no reference for what these values mean, and it leads to confusion. As they try to figure out 'how big' a story point is, teams frequently give in to the temptation to map a story point to some unit of time. I've heard: “Let's have our 'story points' be the same as days!” or “How many hours should a 3 point story take to complete?”

So what are story points, if not units of time? They are units of work. We count them and size them precisely because we don't know how long it takes to complete a point's worth of work until we have history and data that we can measure. This measured rate is referred to as the team's velocity.

Here is a super-useful technique for bootstrapping the sizing process. Steve Bockman taught me this approach, and I have used it with new teams ever since:

Start with a pile of stories, each written on an index card or sticky note. Have the team identify one story that is of roughly “average” size, not one of the biggest stories, nor one of the smallest.

Now find a wall that’s long enough to line all of the stories up from left to right in a single row. Take the “average” story and stick it on the wall, right in the middle. Pick up a second story—any one will do—and if it’s bigger, stick it to the right side, and if it’s smaller, stick it to the left. Keep doing this with each story, swapping them around and putting them in size order, until you’ve got them lined up like the Von Trapp Family Singers, smallest to largest.

This process usually involves some interesting discussions, and stories will tend to move about until the team is happy with the ordering. Sometimes you’ll identify a story that needs to be broken down into smaller stories, or find one that must be rewritten in order to be sized. All of this discussion is valuable; the team is learning and sharing important information. Still, in order to keep the process moving along, stop the discussion as soon as you’ve decided on a story’s rank. It's time to pick up another story card and find its place on the wall. It really helps to have someone acting as facilitator, to keep the process moving. Yes, you can hire me. ;-)

Once the stories are ordered, start at the far left and ask: “Is this the smallest story we’re realistically going to encounter?” If the answer is yes, mark that story as a 'one'; its size (or estimate) is one story point. When I’m facilitating this exercise, I start walking down the wall and have the team stop me when I reach a story that seems about twice the size of our one-point story. I stick a vertical stripe of blue tape just before it, to mark off where the one-point bucket ends and the two-point bucket begins. Similarly, I get the team to identify where the three-point stories start (they are three times as big as our smallest story), and so on.

I like to use Fibonacci numbers for story sizes, because they grow at about the same rate at which we humans can perceive meaningful changes in magnitude. Using this sequence, you can divide the rest of your wall into buckets of stories sized: 1, 2, 3, 5, 8, 13, and so on.

This approach to story sizing gets a team up-and-running. You won't get bogged down in philosophical discussions about the meaning of a 'story point', or whether or not a story point has a Buddha nature. It's expedient, engaging, and yes, even fun.

Try it out, and let me know how it works for you.

Cheers,

The Great Agile Requirements Showdown!

By: Chris Sims

Agile evangelists claim that extensive written requirements can be dispensed with in favor of lighter-weight 'stories'. It sounds easier, certainly, but can it really be as good? Won't all of the important details get lost?

This Thursday, I'll be staging a participatory showdown between traditional and agile requirements at the East Bay Innovation Group's Project Management SIG Meeting. The event is free for eBig members, and $10 for guests with advanced registration.

May the best requirements win!

Yes you are comprehensively documenting your agile project--just not in English

By Hillary Johnson

If I were re-writing the Agile Manifesto and I wanted to express agile values in terms that spoke positively to the project manager's realm, rather than defining agile in opposition to it, I'd state the third value ("Working Software over Comprehensive Documentation") like this: The best documentation is the product itself.

How did I get here? We had a fantastic yesterday, delivering our Agile Project Management workshop to 13 quite knowledgeable individuals from all sorts of backgrounds. When the group is this experienced, we always learn as much as they do, and one of my "ahas" came when Lisa Winter expressed a pain point PMPs often experience during agile adoptions, especially when the organization is large and long in the tooth:

What do you do when you're caught between the rock and the hard place? ie, you need to run an agile project in an agile manner, but you also need to provide traditional reporting upstream. Do you make like Allen Stanford or the Mafia and keep double books? Or clone yourself and give the waterfall stuff to your evil twin? I hope not!

What Lisa wanted to know was, how can I cut down on this particular form of overhead? Where do agile metrics map to traditional metrics and where don't they?

So how do these things map? Take documentation. A great deal of confusion surrounds the nature of requirements and documentation in Agile, and it’s often put forth—mistakenly—that Agile eschews documentation. While it is true that in Agile development, working software is favored over extensive documentation, this doesn’t mean you don’t document requirements—it means that you and your team document these requirements quite comprehensively indeed at the end of every sprint--but you document them in Ruby, Perl or C++, not English!

This isn't some crazy cowboy agilista indulgence. In fact, there are industries built upon this notion of product as documentation, aka copyright law. And with the recent extension of copyright law to cover software it's no longer mere analogy. The code itself is the sole document on which basis protection is granted--just as the text of The Shining is the only documentation Stephen King produced to obtain his copyright. This is why I think that, while I heartily endorse it's intended meaning, the agile manifesto's implication that comprehensive documentation is frowned upon isn't an entirely accurate statement--what more comprehensive documentation is there, after all, than working software? And if it's proof enough for Uncle Sam, it might need to be proof enough for the VP of Product Development.

But, you say, this isn't documenting requirements exactly, because it comes after the fact. Does it really? Your first working software will be delivered months, possibly years, before a traditional requirements document would have, so maybe the working software really does fulfill the requirements model after all.

Maybe the answer to Lisa's question lies in translating Agile concepts and mapping them to traditional values, if not practices. It might be worthwhile to demonstrate to people who are, quite reasonably, invested in their own histories and bodies of knowledge, that despite radically different approaches, the actual values--quality, timeliness, transparency, value, etc., are the same.

Or am I getting it all wrong by implying that Agile means wrapping your ankle behind your ear to make a point?

Comments (4)

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!

Scott Ambler Revisits Agile Process Maturity Models

By Chris Sims

Scott Ambler, who once wrote 'Has Hell Frozen Over? An Agile Maturity Model?', has started writing about something that he is calling the Agile Process Maturity Model. The discussion around Scott's model has uncovered another model by the same name, and renewed the debate over the usefulness of a maturity model for agile.

Frankly, I found Professor Juliano Lopes de Oliveira's Agile Process Maturity Model more interesting than Scott's. In particular, I like that it is proposed as a starting point for discussion.

You can read the whole article I wrote on InfoQ.

Cheers,

Agile Games Par-tay! Yes siree...

By Hillary Johnson

Think we don't know how to have fun here at Technical Management Institute Agile Learning Labs? Oh yes, we do! We're throwing a wild party on Wednesday, April 29th at Ristretto Roasters in Portland, OR with our pal and test obsessed training partner Elisabeth Hendrickson of Quality Tree Software. It's a warm-up for our day-long class May 1st for Agile coaches and consultants on how to create agile games, but it's also a stand-alone event. There will be coffee, pastries, and the opportunity to have some geeky fun playing Agile learning games with your compatriots. It's free, so come on down!

Agile Games Party
Ristretto Roasters
3808 N Williams Ave
Portland, OR 97213

6pm-9pm, April 29th

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.

Comments (2)

Standard Work?

By: Chris Sims

One component of the Toyota Production System is the concept of standard (or standardized) work. A recent post on the Kanban Development list asked if this concept carries over when TPS and lean are applied to software projects.

The original poster's position was that the notion of 'standard work' did not apply to software development:

For me, the breakthrough that Agile made, was acknowledging that software development was not a deterministic process and that there is no "standard work".

At first blush, I agreed. However, after doing more research on the topic of 'standard work', I came to understand that today's practices are the 'standard'. This is the best way the team currently knows how to do the work. With the standard established, the team is encouraged to experiment and find ways to improve. The idea isn't to use the standard way as something to limit the team. Rather, the standard is to be used a baseline for continuous improvement.

Read the article I wrote about this for InfoQ.

Cheers,

Comments (2)

Attention Job Seekers! Special Training Opportunity...

By Chris Sims

Recently, I've been hearing this a lot: "I'm between jobs. I've got the time to work on my professional development, but now I don't have the money." Talk about frustrating! Hillary and I had a long talk about what we could do to help; here is what we came up with.

We are holding a few seats in each of our upcoming workshops for folks who are currently unemployed. Those seats will be made available, at a very steep discount, to the first few unemployed folks who contact me and ask for them. To claim one of these seats, send me an email indicating which workshop you are interested in, and I will send you all of the details.

If you are currently between jobs, we hope that this will help you take advantage of the time that you now have available. After all, time is generally much harder to come by than money. The improved understanding of agile that our workshops provide should help in landing that next job. We figure that what we give up in revenue, we'll more than make up for in karma points. Hmmm, I wonder what our karma velocity is?

Cheers,

What I learned at Startup Weekend SF: Agility is the state of nature

What's a good mother/son spring break activity? Why, going to Startup Weekend and spending 50 hours building a company with ten total strangers. Perfect because my 17 year-old vastly prefers the company of adults to that of other teenagers, and because he's been on the high school treadmill for so long that I thought it would be nice for him to see what the light at the end of the tunnel might look like--that the world of work can be a rather thrilling place.

Several years ago, I visited the very first Y Combinator class of college-age founders when they were only six weeks into their startups and was astounded at the number of fully functioning products. Turns out six weeks is an eternity, way more time than you need to build and launch a startup!

This weekend, 150 of us crammed into a giant room in Microsoft's Market St. facilities. We were given lots of food (thanks to Sana of Women 2.0) and very little direction. After a free-form round of idea-pitching, with coaching from the lovably dyspeptic Dave McClure (our team-member Han Pham describes his style here), we were cut loose to self-organize into teams.

Tyrone and I were interested in Connor Lee's idea for a venue-rating site for event planners (easy to build in a weekend), and Julian Bryant's pitch for a site that would allow people to intereact around pending legislation. As it turned out, Connor, who had legislative experience Tyrone and I all joined Julian, along with developers Marcus Phillips and Philipp Pfeiffenberger, SEO/Social Media/Web Marketer Aris Vlasakakis, marketing gurus Sherbeam Wright and Mariam Ishpahani, journalist Han and a couple of others who came and went over the weekend. Julian emerged as the natural leader, as well he should being a former Senate intern and Georgetown Law grad with a startup around language learning.

I have worked as an employee or long term contractor on three tech startups, one VC funded, one angel funded, and one bootstrapped. This team outshone them all in terms of raw talent, intellectual horsepower, organization, distribution of skillsets, commitment and efficiency. And we were not alone. In all, 23 teams had working demos or prototypes to share on Sunday evening, and a couple had actually launched fully functioning products (I was using Snoozemail in my gmail inbox before the evening was out). There could be no better demonstration of the power of self-organizing teams than this display of exponential creativity and productivity.

Marcus and Philipp--both Y Combinator alumni if I'm not mistaken--were curious about Agile, and we talked about it a little bit, but there really wasn't time to talk about anything but pushing our product out the door. What I found enlightening was that their native values, instincts and practices were inherently Agile. Being Web 2.0 guys who work in Ruby and Python, they have never been exposed to Waterfall. (The only team that did anything resembling a Waterfall process was the one team that had absolutely nothing to show on Sunday, having spent all their time creating specs.)

This makes me think that perhaps the best way to promote Agile is to take a cue from crime prevention and literacy drives: don't focus on reforming those who have already been "lost" to Waterfall methods; focus instead on preventing the destruction of our talent pool in the first place!

Our team, christened "Democlarity," divided rather quickly into two right-sized sub-teams (also quite Agile). Tyrone went with the bus dev side, working on business planning, market research and content creation, while I went with the development side--the first time I've ever worked on a project and not been the writer/editor. I did some HTML wireframing, then turned my attention to CSS styling while the devs blasted in the functionality.

We had technical difficulties here and there--the wifi broke, version control broke, my host account where I was hosting images while designing went down at a critical point. Marcus and I paired on merging the disparate html files, then Philipp and I paired on some last minute CSS (he is 10x faster than I am, so my main contribution was saying things like, "Can you make that greener?").

Everything got done, and Aris and Marcus had time to practice their demo pitch. We weren't live online, but we were certainly way too cool for powerpoint, and were able to show a site with functionality and an amazing amount of depth.

Aris and Marcus rocked the demo, with Phllip driving the mouse so they wouldn't have to break their patter, and we disbanded feeling like we'd accomplished something fairly spectacular and been a part of something pretty important. The Democlarity team is looking forward to a reunion in a month, and plan to continue developing what we started in an open source-ish sort of way. In the meantime, a demo of our site should be up on www.democlarity.com fairly soon.

Tyrone went back to swim team practice today, and I'm back at work too. But I learned more about teams and teamwork this weekend than I did in the previous year--and that's a year in which I wrote an Agile training manual and helped organize the Orlando Scrum Gathering's Open Space Conference. I'd highly recommend the startup weekend experience for anyone who is seriously committed to working on or with software teams--the pressure of an insane deadline like that compels you to strip everything down to the purest, simplest form: communication, decision making, work flow, product features, everything, and conversely, it also leads one to discover the enormity of one's own personal resources. We were like those people who, in a crisis, lift a car off of a person. Heady, empowering stuff.

This weekend was Startup Weekend World, with 50 cities participating. There will be another soon enough. Hope to see you there!

Microsoft's Anand Iyer has written a superb overview of the event on his blog, along with descriptions of all 23 companies.

Kanban is not Waterfall!

By Chris Sims

In my most recent InfoQ article, I write about someone's approach to making a kanban flow look less like a waterfall process. The result is a workflow with new names for the steps. That's fine, but it misses the point that even if the steps are the same, an agile kanban system is far from, and far better than, a traditional waterfall process.

Waterfall is a batch-and-queue process. All of the work in one phase, say requirements gathering, is done before the next phase begins. In this way the requirements work is done as a batch. The output from this batch is then queued up waiting on the next phase to begin. The problems with this are many.

First off, this batch-and-queue builds up a lot of unfinished work-in-progress. Each piece of work-in-progress represents time, and thus money, invested. The work-in-progress is not shippable product, and so earns the business no money. The more we pile up work-in-progress, the more our investment increases, while our return stays at zero.

Another problem with the batch-and-queue waterfall process is that we are unable to get meaningful feedback from our customers until very near the end. We don't know that we misunderstood some of the fundamental requirements until it is very difficult, and expensive, to make corrections. We also don't find out about quality and performance issues until late in the game. Finally, accommodating changing requirements is notoriously difficult.

A kanban system, by contrast, is a single-piece-flow (AKA continuous flow) system. A single piece of work moves through all of the steps from start to finish, resulting in finished product. The whole point of a kanban system is to minimize the amount of unfinished work-in-progress. Even if a given kanban process has steps that look exactly like waterfall, there are huge gains simply from avoiding the batching and queuing. The team will produce their first bit of finished product dramatically sooner. The business has the opportunity to start earning a return right away. The customer can give feedback. Misunderstandings can be addressed. All of the additional goodness that comes from short feedback cycles happens.

I'm not saying that the best way to do an agile kanban system is to take each feature (or story) through a mini waterfall; there are better ways. I am saying that even if a kanban flow looks superficially like waterfall, the fact that it is a single-piece-flow system makes it fundamentally better.

Peak Bagging at STPCon

By Hillary Johnson

Today at STPCon Chris led two interactive sessions, one on Most Effective Ways to Improve Software Quality, and another on the Makings of a Great QA Leader. Both sessions used the Group Wisdom Without Groupthink method to brainstorm and then rank ideas based on the collective experience of the participants.

For me, the unexpected highlight of the day was the lunchtime keynote speaker, chemist and adventuress Arlene Blum. She described her all-female ascent of Anapurna, and her crusade to remove toxic fire retardants from children's clothing, claiming that the latter was the more difficult project by far. As she told stories from the various phases of her life, I kept having to pick my jaw up off the floor. The STPCon organizers are to be applauded for such a breathtaking choice of speaker. Just the kind of stimulation one needed to dive back into afternoon sessions.

As promised to the participants, here are the results of both workshops, ranked by how many votes they received:

Most Effective Ways to Improve Software Quality

Test environment that resembles production

10-14

Understanding high level business needs before development starts
Clearly document requirements

5-9

Agile--Involving customer early and often
Group effort, teamwork
QA and dev pairing and collaborating through design
Communication between business users and development
Opt-in for project teams
Finding champions for the product (end users)
Good simulation tools

0-4

Sprint review demo
Detailed info on defects/review with developers
Thinking about testability early
Avoid requirement creep
Knowledge-based testing by QA
Dev spec process
QA & Dev reporting to same manager
Recognizing impact of architectural decisions
Investing in analysis of automation
Clearly defiined mission statement and ccollective buy-in
Not caring about test results (bad/avoid)
IT governance process to oversee development

Chris led the same session last year, so it is interesting to compare those results.

Makings of a Great QA Leader

6-7

Balance of work and fun
Effective communication
Empowerment

2-5

Understands the big picture
Personal integrity
Trustworthy advocate
Respect

0-1

Effective and informed questioning
Customer focused
Keeps their cool
Remains impartial in problem solving
1:1 peer focus
Recognizes strengths
Hiring better people
Open to suggestions
Attention to details

Compare these results to those from the same presentation at STPCon 2008.

Focus Improvement on Bottleneck Constraints

By Chris Sims

In My Framework is More Productive than Your Framework, Ken DeLong examines approaches to making software projects more productive. He finds that despite the hype about frameworks, languages, and project management tools, these tend not to be the bottlenecks. Ken believes that the largest productivity gains are likely to come from improved communication, code readability and debugability.

Read the whole story I wrote about it on InfoQ.

Cheers,

Notes from PCamp: Agile 101, more Learning Games & World Cafe

Chris led three sessions at PCamp the day before we left for the Scrum Gatheirng: Agile 101, the ever-popular Agile Learning Games, and a new session with Ainsley Nies called "PM Principles, Values and Practices," a World Cafe session that delved into ways for PMs to apply the Agile Manifesto to their roles and areas of expertise.( I stayed home with a sore throat, bleh.)

This was Chris' first time running a World Cafe session, and it sounds like we'll be using that format more in future. The World Cafe website looks like it was designed by someone wearing a Che t-shirt and crunching loudly on GORP--so to spare you the kumbayaa lingo, I'll summarize the process:

World Cafe

First, the facilitator breaks the room into groups of three or more, then sets them to exploring a set of related topics, one per table. Each table/topic has a "host" whose job it is to stay with the table and provide continuity, which the others rotate between tables every 20-30 minutes. Each round lasts 20-30 mintues at a time (three rounds is about right for a 90 minute session). The idea is that those who travel between tables will cross-polinate ideas between the topics and bring fresh perspectives. In the last round, people have the option of returning to a previous table or continuing on, so that there is opportunity for closure and continuity.

I can see this working well when all groups consider the same topic, too, as it's interesting to see the variation in people's answers on a single question.

As promised to the participants, is the slide deck from Agile 101 session. Also posted on the PCamp Wiki. Enjoy!

And if you want to learn how to build Agile learning games, Chris and Elisabeth Hendrickson will be teaching a class in Portland May 1st.

Creating Agile Games for Coaches & Consultants

Yesterday Chris and Elisabeth Hendrickson led a day-long dress rehearsal for a class called Creating Agile Games for Coaches & Consultants. The idea for the course grew out of various experiences: Chris has led sessions on Agile learning games at several conferences, and they've always been hugely successful, and Elisabeth has taught learning games, and held "game days" for coaches at her Quality Tree Software offices in Pleasanton. She's also done a lot of work deconstructing games, and building a set of principles and processes for how to create or adapt them to target specific learning objectives, as well as amassing an amazing array of boards, markers, spinners, dice and the like.

The day began when David Chilcott walked into the room and wrote on a flip chart: "Do not think that you will necessarily be aware of your own enlightenment." Which proved true more than once.

At the beginning of the session, one of our 14 testers asked, "How would you like to receive feedback, in the moment, after the fact, verbally, in writing?" To which we said, "Yes, please." I mostly lurked throughout the day, taking copious notes so that we might capture the goodness and update our program and class materials for when we offer the class fer real in Portland on May 1st.

To kick things off, Chris and Elisabeth discussed various game elements like chance, choice, turns, roles, winning, etc., and how to select elements to match different learning objectives. Then they laid out a basic set of steps and broke everyone into teams. Most of the day was spent devising games, while Chris and Elisabeth floated from group to group, jiggling them when they got stuck somewhere, but trying to stay out of the way of the creative process. Some phases ran long, and others we didn't get to, and we learned a lot from that about how better to calibrate the day.

We've always found dress rehearsals immensely helpful in developing classes, and this time was no exception.The opportunity to have an iteration 0 helped us immensely in shaping the future class. Going in, Chris and I were a bit worried that we didn't have enough structure mapped out, while Elisabeth, who has taught a similar class before, was more sanguine. We were wrong and she was right; starting with the minimum necessary framework was absolutely the right approach. I commented to Chris as we were packing out, "We learned where we needed more and where we needed less, and with more structure and planning--we would have learned where we needed more and where we needed less."

The same pattern emerged in the four groups collaborating on building learning games: The more talking a group engaged in, the less progress they made. The groups that shifted to a trial and error approach and started playing and iterating made more progress sooner. A group working on a game illustrating the value of TDD got bogged down in too much up-front planning. Rob Myers, a well-known TDD advocate, summed it up neatly, observing dryly, "We've spent half the day to arrive at the realization that test-driven development works!"

Over the years, I've grown to take more pleasure in being proven wrong more than I do in being right, as it means I've learned something new. I think Agile values and practices speak to me because they encourage that mindset, and I observed the same at work in the group of stellar minds who honored us with their presence.

Jeffrey Fredrick observed that learning games are quite fundamentally different from recreational games, which are most often about winning and losing.

Jeff McKenna remarked that it was hard to remember to think like a participant and not like a coach, but that one had to step out of the coaching role and think like a player in order to do the work of designing a game. He also questioned the term "game," suggesting that much of what was being created could better be described as "simulations," which speaks to Jeff's point about the characteristics of learning game objectives.

Three of the four teams ended with finished games: a poker-based card game, a game with dice and story cards, and a kinesthetic game where people went on a kind of treasure hunt for balloons. The fourth group worked on a complex game-in-progress Cesar Idrovo brought with him to the workshop, and they had some good ahas around that. Some groups built their success slowly and steadily, while others made progress in big, sudden leaps.

In all, the level of engagement was extraordinarily high, which is remarkable considering that game design appears to be composed of 90% frustration and 10% exhileration. "You need to bring in lunch when you run this workshop instead of having a break," Steve Bockman said, "We just wanted to keep working on our game without disruption."

Many thanks to everyone else who turned up, including Mack Adams, Daniel Bols, Peter Dean, Don DeCosta, Rich Gierak, Ed Kraay, Craig Sakowitz and Joanna Zweig.

We've turned on registration for the May 1st workshop in Portland. And ff all goes well with Chris and Elisabeth's submission, you'll be able to catch an abbreviated three hour version at Agile 2009.

Comments (2)

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.