Agile Learning Labs

User Stories and Pair Programming: Two Chances to See Us Tomorrow

By Hillary Johnson

Chris will be leading off the Agile Manager's Support Group in San Mateo with a presentation on the theme, "Help! Our user stories are too big!" As usual, there will be a raffle and free pizza, and as a special bonus, you'll get to take home a copy of our Agile Dictionary sampler, a booklet containing highlights from the new website.

Meanwhile, Steve Bockman and Rob Myers will be presenting on the theme, "Making Pair Programming and TDD Fun and Effective" at the San Francisco .NET Developers User Group's monthly meetup, which will be held at Microsoft's Market Street offices.

Which one are you going to? Life's all about making tough choices, isn't it?

Experiencing Agility at SD Forum

By Hillary Johnson

Chris will be giving a brief, experiential introduction to Agile on the morning of July 27, sponsored by SD Forum. For anyone who just wonders what the "fuss" is all about, this is a way to get a quick dose--not of lore and theory, but of what it might actually be like to live in an Agile world. One thing is for certain: there is no PowerPoint in this utopia. Also, if you're hesitating over whether or not to take the plunge and get your CSM, this is a good way to test drive Chris' material and teaching methods. This workshop will set you back a mere $35--$25 if you're an SD Forum member, and why wouldn't you be?

The Agile Dictionary: A is for Agile

By Hillary Johnson

Writing a dictionary turns out to be a fair piece of work. Who knew? We have had a soft launch this week, with Chris Sims handed out a hundred copies of a "sampler edition" at Agile Roots. And The Agile Dictionary now has a live website, with a handful of definitions, and counting. It is ready for your perusal and commentary at www.agiledictionary.com, where you can even sign up to get the Word of the Week delivered to your inbox. Don't think of it as spam, think of it as an entertaining diversion, something fun to read while you avoid answering all those other supposedly urgent emails.

Without further ado, here is an entry from the Dictionary:

Agile

An umbrella term for iterative, incremental software development methodologies. Agile methodologies include Extreme Programming (XP), Scrum, Crystal, Dynamic Systems Development Method (DSDM), Lean, and Feature-Driven Development (FDD). Agile methodologies arose in opposition to the traditional, phase-driven “Waterfall” development method, which emphasizes top-down project management, “big design up front,” silos for architecture and design, coding, and testing, and extensive documentation. Agile methodologies share an emphasis on small teams delivering small increments of working software with great frequency while working in close collaboration with the customer and adapting to changing requirements.

Etymology

The term “Agile” was first used by a group of Software pundits who gathered at a ski lodge in Snowbird, Utah for the express purpose of naming and defining the greater movement in which they deemed themselves to all be participants. The original invitation to Snowbird went out to those interested in “lightweight” development frameworks. The attendees agreed that they didn’t like the negative connotations of that term, and agreed to adopt the term “Agile.”

The June Conference Circuit

By Hillary Johnson

If you're like us, you've dialed-back your conference-going in the past couple of years, but one event that's not to be missed is the Agile Roots Conference in Salt Lake City. Both Chris and Steve will be presenting, and we'll be handing out the very first "samplers" from our forthcoming Agile Dictionary project. Why do we love Agile Roots? Because it takes place in Salt Lake City, near the birthplace of the Agile Manifesto, and opens with a keynote address by Jeff Patton titled Nobody Wants Your Stupid Process. See, you want to go now, don't you?

Steve will be presenting one of Agile Learning Labs' greatest hits, a workshop he designed called Flying Through Bottlenecks. Chris will be doing The Great Agile Requirements Showdown, which could just as easily be called Showdown at the Agile Corral. Both workshops are participatory, and a lot of fun.

On the way to Agile Roots, Chris will be making a whistle-stop at the Better Software Conference in Las Vegas, where on Thursday, June 10th he'll do a little number he picked up from Steve, Eliminating Process Bottlenecks: The Theory of Constraints. I think I like Steve's workshop title a bit better, even though it's less explanatory; who doesn't want to learn to fly?)

Somewhere between the two conferences, Chris is going to manage to stop by Los Angeles to attend my son's high school graduation. What a whirlwind. Good thing he's so Agile....

Edistorm: online stickies with dot voting! Whee!

By Hillary Johnson

I'm just starting to play around with a really cool, freshly launched product called Edistorm, an online app that features draggable stickies and dot voting. It's a bit strangely positioned, as a consumer not a business product--the example in the tutorial is about cake baking--but beneath this surface is what looks like an extremely useful tool for distributed Agile teams who find themselves longing for the chaotic simplicity a sticky wall.

Stickies and dot voting are two of of our main tools here at Agile Learning Labs. Every free wall is a colorful mosaic, and I suspect we are putting at least one Post-It Note heir through college. Every retrospective (and we have a lot of 'em) ends in some form of dot voting, to narrow down our action items.

Why online?

Online stickies would in theory allow distributed teams to collaborating using the same format tools we prefer for co-located teams. The question then becomes, what makes real sticky notes so great, and do these benefits actually transfer to an online environment?

Big and visible

One benefit is that a wall of stickies serves as an information radiator. By virtue of being on a wall, they are always visible to the team--always on the fringes of  consciousness, accessible at a glance, without booting up or drilling through a menu. This benefit is lost by putting stickies online.

What's the alternative? Chris, Steve and I hold a remote stand-up every morning, looping Steve in via Skype video. We can just make out Steve's task board in the background, and he can just make out ours. It turns out not to matter too much that we can't read each other's stickies. We watch each other move through the task board, discussing each stickie as we move it from doing to done, or from the backlog to doing. We are happy with this set-up, and wouldn't switch to an online wall, as the benefit of having the information radiator outweighs the issue of legibility by a longshot. 

But that is a taskboard. I can see other situations in which Edistorm could be immensely useful for short-term uses, such as a distributed team retrospective, or brainstorming a small project, where you don't really plan to leave the wall up as a radiator anyway. And you could get creative about sharing, by projecting them on a conference room wall or displaying them on a large monitor in each location.

It's Simple

One of our mantras at Agile Learning Labs is "What's the simplest thing that could possibly work?" And about 50% of the time, the answer is "sticky notes."

Write a sticky. Slap it on the wall. Move it around. Crumple it up and throw it away. That's pretty much all a sticky note can do. It is not programmable. And it is blissfully immune to feature creep.

Edistorm is simple now, but I'm not yet convinced that's by design. Right out of the gate there is a big red flag: it has already included a totally unnecessary feature, a "bot" that makes new "suggestions" based on your current set of stickies. The bot in the cake baking example in the tutorial creates stickies with words like "wedding" and "food" on them. You can turn the idiotic bot off, but my tender young mind should never have been exposed to the existence of such a thing. How this could ever be anything but distracting and annoying mystifies me, and it tells me the company is in danger of loading its product up with bells and whistles that totally defeat the purpose of using stickies--i.e., to keep it simple.

That said, bot aside, the product really does work like a wall of stickies. It's simple, intuitive, and it just works. It is the dot voting equivalent of my favorite online task board, scrumy.com, which has kept itself ruthlessly simple in design.

If you want to see Edistorm in action, you can watch a nice, to-the-point tutorial, and if you sign up for a free trial, you can create a wall of your own, or visit a stickie wall the company has started where users can add to, or vote on, suggestions for improvements or new features.  Several bumptious lunatics have suggested things like a chat window, ven diagrams and Facebook integration. The only feature I voted for was to make the wall itself draggable, and to create an API--my thinking being that an API would encourage people who want to cruft the product up to do so on their own.

Speaking as someone who uses stickies and dot voting every single day, my advice to Edistorm would be to resist adding any feature that isn't also a feature of a real sticky wall. No chat windows, email, spreadsheet imports, etc. Let people who want that stuff use traditional project management software like Microsoft Project. Give me a virtual version of the real thing, and let me figure out how to use it, and what to use it for.

Try it!

By Steve Bockman

"In theory, there's no difference between theory and practice. In practice, there is." - Yogi Berra

You've probably heard that before. Amusing as it may be, there's solid advice to be gained from Yogi's folksy wisdom.

Having been on a number of development teams over the years, I've heard my share of discussions theorizing about "the best way" (sometimes stated as "the only way") to accomplish a given task. In some cases, it seemed that more time was spent in discussing possible approaches than in actually implementing them.

The essence of Agile might arguably be distilled down to two simple words: "Try It!" In other words, spend less time theorizing and more time experimenting with ways to improve your work process or technical practices. "Try It!" is the "conduct an experiment" part of the scientific method. It also shows up in the Plan-Do-Check-Act problem-solving process, more popularly known as the Deming cycle. The spirit of "Try It!" is embodied in Inspection and Adaptation, two of the three legs in the Scrum framework.

So the next time you find yourself in a position where you and your teammates are unable to decide on the best course of action, think of it as an opportunity to conduct a short experiment. Here's a way to go about that:

• In 5 minutes, have each team member write down every idea for a course of action he or she can think of on a sticky note (one idea per
•    note).Put all of the sticky notes up on the wall for all to see.
• Eliminate all the redundant ideas.
• Have the team vote (you can use sticky dots for this) for their favorite ideas.
• Implement the most popular idea.
• If the idea doesn't work out as hoped, repeat the above process.

This method is almost certain to get you past any analysis paralysis. And you'll likely learn something useful along the way.

What Does Your Team Need? Girl Power!

By Hillary Johnson

Last weekend, Chris and I attended a marvelous event called Dare 2B Digital, aimed at addressing the gender gap in computer science careers, and at which 7th through 10th grade girls got to play at writing code, crafting business plans, and other techie things.

We held a session called "Teamstorming," leading a group of enthusiastic students in a series of the same learning games we use to teach teams of software developers on big, important enterprise projects to work together collaboratively.

We were completely blown away. The girls weren't just good: they were great. This was the most quick-witted, productive, outgoing and naturally cooperative group of individuals we've ever had the pleasure of teaching, by a significant margin. Chris and I have both mentioned to several people now our experience of finding the teenaged girls smarter, stronger, faster and sharper than their elders of any gender, and have heard a few theories about why this might be, the top three being:

They are unspoiled.
They are female.
They are female and unspoiled.

We laughed, too. But each of these notions has some merit. First, there is the unsullied youth theory: It seems patently obvious that many adults have a great deal of wariness, and weariness, to overcome before they are open to participating freely in a game-based exercise. Our teaching style is based entirely around games and simulations, and the younger a student is, the closer she is to the memory of learning almost entirely though play. It is not, however, particularly true that children are born collaborators, as any parent whose pre-school has a biter enrolled can tell you.

As for the gender question: Are females, by nature or nurture, better collaborators and problem solvers than males? To whatever extent our temperaments are deterministic, my hunch is that girls would respond better to the collaborative exercises, and the boys to the competitive ones. There is research-based evidence that there are gender-based differences in learning styles, but the same research indicates that the variation between individuals is greater than the variation between the genders.

So yes, the girls may benefit from being both female and unspoiled, but this doesn't mean they are superior to the male and the spoiled, it just means they're naturally suited to collaboration and have nothing to unlearn as they encounter collaborative situations.

But by adulthood, we are all engaged in activities that may or may not speak to our true natures. Girls don't tend to play with toy cars, but they grow up to drive real cars in the same numbers as men. And if you believe insurance companies' actuarial tables, they grow up to be the better drivers. On the flip side, I think this means that boys can grow up to be fine collaborators, as good as or better than their female counterparts, despite their greater inclination toward competitive styles.

I am not a big fan of determinism. Things do come out in the wash, and in the long run, even unlearning can be a productive process. As Chris will tell you, part of the reason he values Agile so much is that teamwork and collaboration do not always come naturally to him--he was once a boy who played with cars, after all. He has enjoyed being in a traditional leadership role, and can remember exactly what it was like to resist the urge to "help" a team, instead letting them solve their own problems through self-organization. Which is why he is good at teaching Agile techniques, especially to people who have a lot of un-learning of traditional top-down management styles to do.

The clear outcome, to me, is that the gender bias in the field of software development that persists today is entirely bogus. If boys have an edge when it comes to math--hence their delight in code--and girls have an edge when it comes to collaboration, then it seems stupefyingly clear to me that you're most likely to have a high-functioning team if you have both styles well represented, with plenty of room allowed for something even more important: individuality.

Better Software = Agile Software

By Hillary Johnson

This year's Better Software Conference in Las Vegas on June 6-11 is all about Agile, to judge by the program. The conference runs concurrently with the Agile Development Practices West conference (with twofer admission). Better Software is also bookended by certification courses in ScrumMaster and Agile Testing Practices early in the week, and the Agile Alliance's one day Agile Leadership Summit , chaired by Polyanna Pixton, on Friday.

In addition to the usual presentations on release planning, user stories and backlog grooming, the program has a lot of emphasis on what are sometimes termed "soft skills"--i.e., the ability of technophiles to interact with carbon-based life forms, sessions with names like: Selecting Agile Team Members, Verbal Agility and Better Decisions Through Collaboration.

There will also be fun and games. Chris will be leading a session called Eliminating Process Bottlenecks: The Theory of Constraints, which has participants building paper airplanes--and running a paper aerospace company--to explore problems and solutions.

InfoQ: Agile Coach Camp Announced

By Hillary Johnson

Chris' most recent InfoQ article is a preview of Agile Coach Camp, billed as the Open Space conference "delivering value to those delivering value." The conference, which takes place in Durham, NC next month, is a bit different than most Agile gatherings, in that aspiring participants must "audition" for admission by submitting a position paper, guaranteeing a high level of professional discourse. Check out Chris' article for a preview of some of the topics proposed so far. Last year, Chris facilitated a couple of sessions, including one on What Makes Agile Projects Succeed.

Breakfast of Agile Champions (this Monday!)

Being Agile is hard. Simple, and hard. Simple because, in theory, all we need to do to achieve a yogic level of Agility is to live by the Agile Principles as set forth in the Agile Manifesto. Hard, because the real world impinges on or impedes this effort every %$(^%&! day.

In light of this, Agile Learning Labs' own Steve Bockman has put together a workshop on the first Agile Principle, which reads, simply:

"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."

The workshop is called Continuous Delivery of Software: Maximizing Customer Satisfaction by Delivering Early and Often. The first session will be Monday, January 25, from 7 to 9 am at the Hobee's Restaurant in Redwood Shores (you can see it from the freeway). For the tuition of $50, we're throwing in a full, hearty American Breakfast is included--yep, we're talking bacon, french toast, and chorizo omelets here, not burnt coffee and a shrink-wrapped croissant. You'll also receive a certificate of completion you can use to claim 2 PDUs from the PMI.

PDUs and bacon. What more could you ask for? Register here.