Agile Learning Labs

Ah Ha! Moments from the Great Requirements Showdown

By Chris Sims

Tonight, at the North Bay Agile meetup, I facilitated "The Great Requirements Showdown!"  It's an experiential exercise that pits traditional written requirements against the agile alternative: user stories and face-to-face communication. 

During the workshop, participants wrote down their 'Ah Ha!' moments and we shared and talked about them.  Here are they are:

• Too much detail is at least as bad as too little.  Time-boxed "good enough" requirements work better.
• One group (requirements writers, in this case), trying hard to do a good job, can actually cause harm by using up too much of the schedule.
• Teams working on the requirements (upstream process) used up most of the time, leaving the developers (downstream process) with little time to turn the requirements/specs into a product.  Great requirements are worthless if there is no chance to implement and ship.
• Late commitment resulted in poor deliverable.
• Integrating even small increments of work can be more difficult than it seems, and lead to a poor quality 'whole'.
• We wish we would have used continuous integration!
• What is important is not always obvious.
• We didn't have enough context or vision to know what really mattered and what didn't
• Optimize the process to focus on what is most important.
• Ask the customer!  Find out what matters most to the customer, don't assume!
• We never thought to consult with the customer!  Why is that?
• Face-to-face communication between the developers and the requirements team resulted in much higher product quality than using written communication.
• Feedback is a good!
• Feedback is everything
• Positive feedback, especially confirmation of "done" is important.
• Without feedback, the process and the results suffered
• Use all available means to communicate (In this case we wish we could have used drawing in our requirements).
• Precision in language is really important (and really elusive).
• Verbal instructions leave open ambiguity, which sometimes gets translated correctly.
• Sometimes set-based development (working on multiple solutions in parallel) is a good way to find the best possible solution.  Watch out for emotional reactions from the people whose solutions aren't chosen. 
• I hadn't ever thought about set-based development as an alternative to pair-programming.
• Serendipity!  Sometimes you just luck out and build it right.
• Sometimes the end product matches the requirements by accident!
• Good requirements speed up development, like a good road map.
• Requirements done quickly are ambiguous.
• Perspective matters!
• Simplicity!  Focusing too much on the details can distract you from the big picture.
• Pair-programming concepts can be applied to creating requirements documents.
• Communicating only in writing leads to 'us' and 'them', collaborating leads to 'just us.'

Have a comment or question about any of these?  Leave a comment and share your thoughts.

Cheers,

Chris

Sticky Note Stop Motion

By Chris Sims

Here at Agile Learning Labs, we go through almost this many sticky notes every day.  Almost.

BTW, registration for the August Agile Project Management learning lab closes on Monday. Check it out now!

Fun & Games: Some upcoming events in SF & the North Bay

By Hillary Johnson

Children learn best by playing games, and guess what? Adults do too. No reason your agile practice should be a plodding, dreary affair with all the elan of a queue at the parking violations bureau. Lighten up and have some fun--it'll make you smarter.

Chris will be leading a raucous meeting of the BayAPLN in San Francisco on July 21st, on Agile Games & Simulations, so come out to play, won't you?

Chris will also be leading a session of the Great Agile Requirements Showdown at the North Bay Agile Meetup on Tuesday, July 28, in Rohnert Park. This is the gathering hosted by our friends Steve Bockman and Rob Myers, both of whom are accomplished gamesmasters themselves, so it should be a fun time. What's it all about? Here's the teaser: 

Agile evangelists claim that extensive requirements can be dispensed with in favor of lighter-weight 'stories'. It sounds easier, certainly, but can it really be as good?

Come find out!

Agile Adoption and Culture Change

By Chris Sims

Agile adoptions are hard, in large part because they involve changes to the corporate culture, a task requiring huge effort and significant time. At the Agile Roots conference, I met Israel Gat and he shared a different approach: work with the existing culture; don't try to change it.

There is no shortage of evidence that agile adoption usually involves culture change, and that this change is challenging. In the article Challenges of migrating to agile methodologies, published in Communications of the ACM, "Organizational Culture" tops the list of "Key issues in migrating to agile." The article goes on to say:

Culture exerts considerable influence on decision-making processes, problem-solving strategies, innovative practices, information filtering, social negotiations, relationships, and planning and control mechanisms. Neither culture nor mind-sets of people can be easily changed, which makes the move to agile methodologies all the more formidable for many organizations.

Wille Fale states it more plainly, expecting that some blood will be involved:

I would dare to say that for Agile adoption to work, corporate culture and people have to change their values, and that is certainly not an easy thing unless there is an infusion of new blood and in some cases even some “blood letting” of people who remain obstacles and stuck in their old ways.

Israel Gat knows a thing or two about this topic. He led an agile transformation at BMC Software, in which a 1000 people adopted Scrum over the course of 4 years. In a keynote talk given at the recent Agile Roots conference, he outlined his approach to agile transformation. He recommends embracing and leveraging the existing culture, instead of trying to change it. In support of this approach, Israel cited Peter Drucker, who said: "... culture is singularly persistent...changing [organizational] behavior works only if it can be based on the existing culture." For those who persist in trying to change their company's culture, Israel pointed to work by Denison suggesting that such a change can take a decade or more to realize in a large organization.

Israel presented a taxonomy that identified 4 types of cultures: Collaboration, Control, Cultivation, and Competence. A Collaboration culture, such as a family or athletic team, places a high value on affiliation. A control culture, such as the military, values power and control. A cultivation culture, such as a religious institution, values self-actualization. A competence culture, such as a university, values achievement.

Israel suggested that a company considering an agile adoption should identify what type of culture exists, and what the strengths of that culture are. A key part of this examination is to determine the data that the culture pays attention to, and the processes by which decisions are made. Once the culture, and it's strengths are identified, they can be put to work to help the organization adopt agile practices.

What are your experiences with behavioral and cultural change as part of an agile adoption? Leave a comment and share.

Lean Meetup Tomorrow: Flying Through Bottlenecks

By Chris Sims

Tomorrow evening I'll be at The Bay Area Lean Software Development User Group meetup facilitating a cool simulation that I learned from Steve Bockman.

We're going to launch a fictitious aerospace company, build and ship product, and track our financials to see how we are doing. We will apply the "Five Focusing Steps" from the Theory of Constraints, as well as other lean and agile practices to evolve and improve our operation and ultimately our profitability. We'll explore several approaches to optimizing multi-stage processes and engage in some team problem solving. There will be lots of paper airplanes, and a lot of fun.

The event is free, and hosted by Runa Corporation .  Get all of the details at the group's meetup page.

Cheers,

Chris

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,

Chris

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?