Agile Learning Labs

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,

Chris

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.

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,

Chris

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,

Chris

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

16

• 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.