Agile Development Blog

On the road to Agile adoption, I often get asked, “how do you get teams spun up on Agile fast?”  The short answer is to just do it. The long answer is that I believe there are 3 options. 1) Rally and other Agile coaching organizations offer programs that place a coach in your team to help with preparation, planning, estimating, setting norms, committing, tracking, daily stand-up, demonstrations and retrospectives. 2) You can take the DIY approach,  but watch out for the unintended consequences.  3) Finally, I think there is the intensive practice approach.  Let me give you some examples:

A Sprint Per Day for the First Week

While speaking and attending Agile Vancouver in 2008, Linda Rising facilitated a fishbowl exercise with a custom development firm in Vancouver.  Given they were starting and stopping projects and reforming teams all the time, they had developed an approach to speed the team through the formation process and inculcate new team members (employees and customers) to the process.  The would run a scrum sprint every day for the first week.  This intensive process would allow them to work through tons of issues in a very intensive week.  I would call a form of this preparation over planning.

A Sprint Every 90 minutes for a Weekend

If that is not fast enough for you, how about a sprint every 90 minutes?  That is what the folks at SnapImpact did last weekend in Boulder at their SnapCamp (based on the notion of Startup Weekend).

I heard about this from one of the organizers and fellow Sprint Triathlete Dave Angulo.  Dave is co-founder of the non-profit SnapImpact, a guerrilla non-profit that has a mission to “Make Doing Good Easy.”  They developed an iPhone application and Wordpress plugin to simplify how people learn about volunteer opportunities near them.  It takes feeds from HandsOn Network and soon All for Good. It is cool, I’ve been playing with it for a year.  Anyway, ran into Dave at a CTO lunch in the TechStar’s bunker today and he told me about the wild success they had with 90 minute sprint process through the last weekend.

To give some background, SnapCamp was the kickoff effort for developing v2.0 of All for Good, the platform which powers http://serve.gov and a number of other sites. It’s the largest single repository of volunteer opportunities in the world. Version 1.x was pushed into production quickly and, while it is up and running, there have been a number of technical limitations which have frustrated All for Good’s partners and limited the platform’s usefulness. SnapImpact offered to develop v2.0 of All for Good because of the close alignment of the two organizations’ missions and their desire to have a more comprehensive list of opportunities for their iPhone app.

Dave - We started the weekend with dinner on Friday night to allow time for everyone to meet each other, learn about each other’s backgrounds, and have a shared group experience. We had people from all over the country as well as a great local contingent. Some were die-hard SnapImpact volunteers, others had only heard about us recently. The dinner allowed for folks to get to know one another in a casual setting without having to do it in between trying to get work done.

Saturday morning, we laid out the business problem, context, and goals for the weekend, then I announced we would do 90 minute sprints. The business teams (we had marketing, UI, and product teams as well), would adhere to the same schedule. The beginning of the first sprint for dev was spent laying out four areas of technical problems and having the team self select into what tickled their fancy. Everyone then got to work. I moved between the teams to discuss possible technologies for them to consider and dive deeper on the problems they needed to solve. The volunteers then took over and by the end of the first sprint everyone had a handle on their problem areas. Most even had a initial plan of attack.

Everyone has heard of Forming, Storming, Norming, and Performing. With 2 days to get work done, we had to get them to performing as quickly as possible. The dev teams were all about 3 people in size with differing skill levels and familiarity with the technology stack we were using. The 90 minute sprints forced a tempo which required the teams to get to performing quickly – no one wants to report out nothing was accomplished. Yes, some of the progress initially was small, but these were hard problems to tackle in a weekend. I had one team who’s requirements were being developed by the business team through the weekend, some sprints the deliverable was “received requirements from business and developed a response.”

By the end of Saturday, all of the development teams had produced something which was merged into mainline for the other teams to pick up. That was huge and everyone could see the bar moving.

Sunday started with a review and then everyone picked up where they had left off. The development teams reformed and started working before we even had the morning review. The pace on Sunday kept accelerating, merges occurring after every sprint, until late afternoon, when we started winding down.

I have run many volunteer projects. The SnapImpact team had actually completed one earlier in the week involving several hundred people with BDNT, and it’s absolutely critical volunteers feel like they are moving the bar. Given the scope of this project, it was going to be very easy to have volunteers lose sight of the progress they are making and give up. The 90 minute chunks with progress review and planning helped ensure the volunteers didn’t lose sight of the progress we were making that weekend. As project owners, we had goals of our own on what was going to be delivered at the end of the project. The sprints allowed us to keep moving in the direction we needed to go as well as identify trouble areas.

Dave – Training – One decision I made was to use a relatively new technology stack, Scala/Lift, for the framework. Instead of holding a formal training session for those unfamiliar with it, I made sure there were experienced people in each group and let training happen “on the job.” I think next time it would be better to do a short training session, as given the pace, sometimes that training disrupted forward progress. Just the basics, so when a concept was discussed it wouldn’t be completely foreign.

Deliverables – We got sloppy during the reviews and didn’t nail down specific deliverables for teams. At times, it caused teams to lose focus during the sprint. The reviews were every 90 minutes, so the lack of focus was caught sooner rather than later.

Insert more fun – Because the tempo was so high, I’m not sure folks had as much fun as they could have during the event. I’m a big believer in fun being central to any successful project and I think teams could have bonded a little more and we may not have been as exhausted by Sunday afternoon. There was some fun, we just needed more.

Dave – Our goal was a beta of existing functionality by the end of the weekend. We’re very close to that now, but some decisions made during the weekend prevented accomplishing that goal. The SnapImpact team is continuing development and once the existing functionality is in place we’ll start working on a host of new feature requests from the business team. We’re entering all of that information into Rally now and beginning the planning process. Folks will see v2.0 at http://allforgood.org in June.

Dave - Preparation started weeks in advance. My role in this project is CTO and VP of Engineering. So, the 3 critical things I needed to accomplish before the weekend started was making sure I stacked the deck in my favor with some talented people, had a toolbox ready with possible solutions to the technical challenges we would face, and had stakeholders present to make decisions.

Given the new technology stack, I needed to recruit folks with some very specific skills. To enable that effort we recruited the leader and founder of the Lift project, David Pollak. He helped us motivate a few people with experience using the technology. We also had the SnapImpact team actively recruit their friends. The result was a very high quality team capable of getting the job done.

When the teams started work, they would spend too much time investigating everything unless I gave them a starting point. By bringing some ideas (not solutions) to the table to solve their problems, it helped define their playing field and allow them to make a decision quickly. Implicit in this was understanding the known business problems that needed to be solved.

We knew we would hit roadblocks during development waiting for business input on implementation details. So, we made sure to have some present the entire weekend. One of the stakeholders even brought a developer who was using the existing system. We embedded the dev in one of our teams working on implementing some external interfaces. Yes, that really accelerated the implementation decisions. Also, the stakeholders were really disappointed with certain aspects of the existing system. We had ideas to resolve those issues, but needed to ensure they met the stakeholders needs.

Thanks Dave for the great details on this event and example of agility at work!

I have been an Agile Coach for over 6 years now.  I’ve learned a lot during this time, and I’m still learning.

Here are 78 things I have learned so far:

1. Number of people to whom you ask to describe “Agile”  = Total number of Agile mental models  + or -  2
2. Distributed teams need love and a ScrumMaster at each site
3. A foosball table may be one of your best Agile tools
4. Geography is more than a timezone issue; it needs infrastructure support
5. It’s massively worth the effort to stay engaged in the Agile community through local events, online lists, conferences, and casual meet-ups
6. Having a Product Owner is non-negotiable
7. Avoid Cargo Cult Scrum at all costs!
8. Agile teams need to have fun
9. The best Agile teams and companies rely on Servant Leaders
10. Embracing a real Agile culture is often more than one team can create on its own
11. Agile development can only cut costs if you are willing to spend time and money on it
12. A great approach to agile maturing and scaling is Flow Pull innovate guidance from Lean
13. Burndown charts are about the team commitment to doneness, not about individual performance or time tracking
14. Ensure your sprint backlog reflects the delivery of product value
15. Escalation doesn’t serve either the Agile or Lean community in continuous improvement of practices
16. You need to have more than checkbook buy-in from your Executive to be successful
17. Mature your Agile team practices before attempting to scale to more teams
18. Not having a clear signal to end your stand-up can lead to problems
19. The Lean principle on Flow guides Agile teams on how to tighten up their practices
20. Get everyone in your Release Planning meetings if you want true commitment to the Release’s vision
21. Command-and-control ScrumMasters reduce the intelligence of their teams
22. Co-located teams move to being high-performing, high trust teams far easier and far faster than non-co-located teams
23. Frequent communication through site visits, IM, Skype, email, Facebook, Yammer, video conferencing and other technologies help distributed teams gel and feel the love
24. Agile teams invite healthy conflict in order to become great, enduring teams
25. Velocity: it’s about the team not the individual
26. Kanban is helping teams find new measurements for constant flow of value -  so let’s pay attention.
27. No product owner or too many product owners add up to the same Agile adoption smell: no definitive decision on ranking or acceptance
28. A Product Council is an effective way to manage stakeholders and minimize backlog churn
29. Story points help teams separate calendar hour and number of team members from the story’s complexity, effort, and doubt
30. Stories have relative sizes to one another; only tasks take on effort estimates
31. A well-written story (small, about benefit to a role) doesn’t lie; requirements do by their shear volume of content
32. A product backlog is ALWAYS ranked
33. A product backlog is not a task list; tasks only appear after estimating and planning by the team
34. Agile improves the quality of life for employees
35. Great teams are made of collaborative team members
36. Agile doesn’t create the messages it exposes them
37. Pair programming raises team awareness and code integrity
38. Use consensus, not forced compromise or command and control, to gain full team commitment
39. Effective team meetings require structure and discipline
40. Commit to Agile values and principles; your practices will follow
41. Transparency is an Agile virtue not a punishment
42. Agile is about commitment not tools; tools support those commitments and make them visible
43. Product owners who make their decisions in a vacuum are not Agile
44. Agile teams invoke respect and kindness even in stressful times
45. Teams that don’t retrospect are not Agile
46. Retrospectives are not about blame
47. Retrospectives bring continuous improvement of process and working agreements
48. If you don’t have team working agreements, create them now
49. If you don’t hang your team working agreements on the wall, put them up there now
50. Aggressively cap your utilization capacity until you know your velocity
51. Blog your Agile experiences; more people want to hear them than you think
52. Test driven development doesn’t just create better code; it creates better conversations that create better acceptance
53. Agile Architects and Product Owners work side-by-side to rank product backlogs
54. Give your Agile teams a break such as a “hackathon” built into the cadence of the team’s release schedule
55. High capacity utilization is deceptively evil
56. Quality is everyone’s responsibility
57. Small increments quickly inform us about our work and produce feature sets faster
58. Lean has had a great impact on my Agile language
59. “Hiring the best” can be yet another cliche in Agile
60. Hire wisely not cheaply
61. When hiring new members, team consensus is a must
62. Use 5 levels of planning: Vision, Product Roadmap, Release Planning, Iteration Planning and Daily Planning
63. Release planning is one of my favorite Agile activities
64. Teams and stakeholders invite release planning to see beyond the next iteration
65. FYI, good brainstorming requires lots of post-it notes and sharpies
66. Pay attention to your facilitation skills so that you don’t takeover decisions and don’t let others do the same
67. Keep Agile meetings focused, stick to the purpose and timebox
68. Turn your electronics off in Agile meetings; focused meetings are productive and end on time
69. The biggest cost cutting lever in Agile is prioritization
70. Don’t be afraid to try new practices; your velocity and quality may thank you
71. Agile is useful beyond software; take it up and out the organization
72. Old tools stand in the way of new tricks; MS project is not the way to go Agile
73. Team identity is important, individual heroics are dangerous
74. Individual appreciations in retrospectives are a great way to create space for the growth of Agile team trust
75. Agile maturity is NOT about a CMMI-like maturity model
76. The war between Agile and Waterfall is over; get on with your continuous delivery of valued items
77. Agile asks us to slow down in order to speed up; just do it
78. I love Agile.

This is far from a comprehensive list. I still have plenty more to learn about Agile. I’d love to get some insight from you about what you would add to the list.

What have you learned in your experience practicing Agile?

About the Author: Jean Tabaka is a wine enthusiast, author and Agile Fellow at Rally Software Development. Subscribe today to get free updates by email or RSS.

This is #3 in a Series on the Culture of Innovation with guest blogger Lee Devin.

Plan to do what you want. Prepare to do what you must.

Don’t get us wrong, we value planning: it’s important and highly creative work. But in the Culture of Innovation preparation means much more.  In a world that defines success as a result and failure as a step along the way , we plan regularly as we adjust to results, outside stimulus, and feedback.  Preparation marches us up the stairs faster and ensures that we’ll arrive someplace new and valuable.

Planning is an exercise for imagination and not spreadsheets.

In planning we figure out what we need to accomplish this task.  It‘s a process of creative thinking, dialogue, narrowing to convergence, healthy skepticism, and risk mitigation.  In planning we need to treat difficulties as a challenge; to resolve a creative tension between reality and what we want.  Teams brush away perceived limits as they press toward understanding by asking WHY?  Thinking in the 5 Why’s of Fishbone diagrams, these teams do not simply work with WHAT and HOW.  Once done and aligned, the plan becomes a communication of intent and result and NOT a goal or commitment.   Dependable results come from a focus on the limits to throughput, sources of failure, and lack of preparation.

In our experience with Agile teams, we see advanced Scrum teams begin to let go of some planning practices as their expertise grows. The benefits of pull-based planning and smooth flow delivery create new space for them in the market.  As a result of their growing confidence, they increase their ownership of their process, a key step on the way to a culture of innovation.   That culture creates, not just one off innovations, but an environment ready to take advantage of opportunities and happy accidents.   A big part of creating that environment comes from a focus on preparation.

Let’s consider preparation. Teams and managers must learn and practice a set of skills that taken together can help them create a culture of innovation. These skills often seem off the subject, not to the point, and therefore difficult for teams and managers to make time for. We think of preparation in three main categories: for collaboration and leadership; for comfort in ambiguity; and for daily productivity. In this brief introduction we won’t suggest a detailed program. Instead, we’ll outline an abstract of the culture, seen through the lens of preparation.

Collaboration and leadership

You can prepare for collaboration (innovative team work) and leadership (team direction and support) by learning and practicing release and concentration. Teams and their leaders need release from tension, as a way to increase available energy and flexibility; and release from inhibition and vanity for freedom, to include the work of others in their own and to regard the success of the team as their own success.

Take a look at athletes for good examples of release from tension; at actors in a play or movie for good examples of release from inhibition.

Watch Sharapova’s face as she looks up at the ball she’s about to whack; see the pitcher take a big breath and whoosh it out before he throws the ball. Look at a still photo of what the pitcher does to his arm in the delivery: it’s not hard to imagine what would happen to those muscles if they weren’t completely released, free of any kind of tension. Look at Paul Newman’s famous eyes blaze with rage (as Harry Manning, dumped in the river: Where the Money Is) or fear (Buffalo Bill astride a fractious horse: Buffalo Bill and the Indians).

We’ll use a story to illustrate what we mean by concentration. Once upon a time two students of Zen walked along the lake shore. They spoke as follows:

First Student: “I have the world’s most amazing Master.”
Second Student: “Have you?”

First Student: “He performs miraculous deeds. The other day he walked right out on this lake and spoke to us, standing on the surface of the water. Then he walked back, and his shoes weren’t even damp.”
Second Student: “That’s certainly amazing. I congratulate you. My master, however, can do something much more important and amazing.”

First Student: “No way.”
Second Student: “Yes way. My master can do one thing at a time.”

Who among us can do one thing at a time?

As you plan your week next Monday, think about these questions.

• What is the #1 Thing you have to get done right this week? Be clear about that to yourself and with your team and put your best time and focus on this one item.
• What preparation or practice can you do to release tensions with regards to this item?
• Who can you collaborate with to make this an outstanding result?
• What can you do to celebrate the results of this effort?

What might you do to prepare to execute these choices? What kinds of practice might you build into your daily, weekly, monthly, routine?

Comfort in ambiguity

Accident, serendipity, new things. Innovation confronts the team with all of these sources of ambiguity. What’s gonna happen? What should I do? What on earth is this thing? How do we know when it’s complete?

How does preparation contribute to comfort in ambiguity? It gives us grounds for confidence in our ability to manage the new, the surprising, the unpredicted. We don’t need to dread the uncertainty of innovation because we know that we can make good use of whatever comes up.

Teams and managers who do innovation find ways to live with uncertainty about the outcomes of their work. They know that outcomes will be unexpected and surprising. If they could anticipate them, how new could they be? Preparation will involve getting free of the reflexive invocation of the past: “That isn’t how we do things here”; and embracing the uncertain future: “Let’s see what happens when we do this.”

Preparation will sometimes replace planning.

Of course we plan, so that we can do what we need to do. We plan to have the materials we need, space to work in, the right people on the team, to make an efficient schedule. Planning creates sequential progress toward a known goal. Preparation, on the other hand, aims at collaborative iteration toward an emergent outcome. No one can predict the results of a true collaboration. We prepare to cope with whatever happens. In a culture of innovation, whatever happens is likely to be new. It will elude any kind of sequential progress toward a known goal. When an outcome doesn’t seem to have any immediate value, we recognize that nothing is lost: we set it aside (Might come in handy some day.) and press on.

The notion of emergent design conditions any serious innovation.  At Rally Software, we do a number of things in the context of Agile software development to keep from planning too much and to hold space for reaction to ambiguity.  First, we acknowledge multiple levels of planning with less precision as the time frame goes out.  Second, we insert free time into our schedule in the form of slack and programmed innovation time.  Third, we work “sets” of designs through a narrowing process to keep from choosing the design before we learn.  Finally, we do not plan until after we have closed the last cycle: We check the results of that last cycle and consciously review our goals.  We “Plan to get lucky” and provide room for that to affect our next cycle.

We took a young engineer to visit an acting class at People’s Light, the theatre we know best. A bunch of teenagers were practicing improvisation. One sat on a bench in the park. Another passed by, stopped to talk. A story began to develop. Suddenly from the class a third jumped up and walked into the park, joining the two. This newcomer brought an entirely new slant to the story. After a moment the first actor remembered an appointment and left the other two. Someone else from the class joined in. And so on. The story grew, got elaborate, got simple, got turned inside out: the kids never repeated themselves, never stopped. No one ever refused the new material offered by an other. The engineer turned to us and whispered: “This is exactly what my guys need to learn how to do.”

This kind of practice fairly closely resembles the desired skills. Engineers like to look for an answer in the back of the book; they need practice in making up answers out of the available material. The kind of preparation we’ll call exercise strays from the skills it prepares for; it’s off subject, away from the actual work. Athletes exemplify this kind of preparation. “The champ,” goes the saying, “is always in the gym.” Larry Byrd was famous for staying in the gym after practice. Why? To shoot 100 free throws. To build a reflexive confidence that supports the hectic innovations of the game. What’s more, the champ has decided, has made the choice, to like being in the gym; how could he do the work otherwise?

As you plan your week next Monday, think about these ways of practicing or preparing for emergent innovations:

• Schedule some creative time into your schedule to spend in a creative place and time.
• Step back from your #1 item for the week and ask yourself a question about its value: What other things could I do to deliver even more of this value?
• Find one example of yourself closing down to new solutions based on the concept that “This is the way we always do it.” Can you release that constraint?
• Ask yourself: What is the most important thing I have to do this month or quarter?  Not urgent. Important. Do I have enough time, support, and space to do this right?  Try removing less important or merely urgent things from your calendar to make room for this.

Daily productivity

In a culture of innovation, everyone chooses a professional obligation to work happily, enthusiastically and at maximum energy.

Artists and athletes again serve as models. Neither group can do what they do unless they’re totally fired up. High morale and physical readiness are basic conditions of their work and they must learn how to create and maintain them, no matter what. An actor arrives at the theatre well before the half hour call (On time is already late.), and begins the day’s work with an extensive warm up. Vocal exercises, calisthenics, stretches, lines; actors have routines they follow religiously.

An actor we know told us this story. He used the 30 minute drive to the theatre as his time for vocal warm up. One night, distracted by some domestic emergency, he only got through part of his routine by the time he arrived at the theatre. In rehearsal he had discovered a way of saying one of the lines in the 2^nd act that every one liked a lot: his voice got deep and sexy, very nice moment. On this night the performance went very well, in spite of the truncated warm up. Until that deep sexy part. He said that line exactly as he had done dozens of times before. But instead of deep sexiness, what came out of his mouth was tired little squeakiness. The audience were too embarrassed even to laugh. You can bet that actor never missed another warm up.

In software development, this is akin to doing some manual work outside the scope of your automated build, deploy, test cycle.  It can seem quicker to do a simple, one-off integration or system test outside that environment, but unintended consequences always catch-up .  In our experience, cutting the preparation corners usually costs 10X more in the whole lifecycle than it saves in the short-term. Beyond the interrupts of customer-impacting defects, the team loses a bit of the pride and belief necessary for the Culture of Innovation

Team work demands a no less total performance than acting or tennis playing. It needs, but rarely gets, the preparation of a warm-up. A basketball team combines individual warm ups (stretches, shooting around) with group work (lay up and passing drills). Why should knowledge work be any different? Imagine the energy available if your morning stand up included a vigorous warm up led by a different person each day. Jump back!

As teams and organizations reach an Innovate level of Agile adoption or Ri , they take ownership of their process and environment.  Their improved throughput, collaboration, and preparation have brought them to a place where many of the vanilla iteration, planning, and estimating practices of Scrum and XP stop serving them.  These structures helped the incremental transition down a path of increasing agility, but in a Culture of Innovation, where smooth, continuous flow of one thing at a time is the goal, the focus moves from planning to preparation.

Next up in our series – Options, Fall-back and Design Sets

About the Authors: Ryan Martens is a goat cheese maker,  founding board member of the Entrepreneurs Foundation of Colorado, and Founder and CTO at Rally Software Development.

Lee Devin is a dramaturg at the People’s Light and Theatre, a Senior Research Scholar at Swarthmore College and a senior consultant with the Cutter Consortium. These activities often interfere with his fishing, and cause him to neglect his grandchildren.

Subscribe today to get free updates by email or RSS.

Last summer, Rally started a video series called “Chalk Talks“.

I was fortunate enough to have filmed several “Chalk Talk” videos about some of the basics of Agile software development (The Agile Manifesto, Scrum Basics, Iteration Demo and Review Meeting, and other topics).

Since then, Rally’s expert team of Agile Coaches have joined the party and recorded additional Chalk Talks, again on some great basic Agile topics: Ronica Roth on User Stories, John Martin on Story Points, and Rachel Weston on Release Planning in Agile just to name a few.

We also tapped into the wisdom of some of our other Agile Coaches: Julie Chickering, Mark Kilby, and Ken Clyne.

Our Rally Chalk Talks are informal videos, typically 3 – 5 minutes long, intended to provide quick, easy introductions to Agile topics.

Filmed in a short, tutorial format, these videos are great to share with your team as they are getting up to speed on Agile.

To get a feel for our latest work, here’s Rally Agile Coach Ronica Roth in her great Chalk Talk on User Stories. ( during which you can find out why a dog would want his own laptop :D )

Be sure to check out our entire catalog of Chalk Talks and subscribe to our YouTube channel if you’d like to be notified when we publish new videos. We already have two more Chalk Talks queued up: “Kanban and Scrum” and “Agile and Lean”.

As you look through our current catalog of talks, be sure to let us know what other topics you’d like us to cover in future talks.

About the Author: Jean Tabaka is a wine enthusiast, author and Agile Fellow at Rally Software Development. Subscribe today to get free updates by email or RSS.

This is 1st post in a series we’re working on with guest blogger Lee Devin:

How to Foster A Culture of Innovation

“It took me more than 53 years to understand that culture isn’t just important, it is everything.” -Lou Gerstner

In the coming decade, software and product teams must provide the critically needed innovative approaches to organizations throughout the world. The visual metaphors and practical, hands-on ideas in these posts will give executives, managers, and engineers ways to speed up this evolution. Starting on Monday.

To make and maintain a culture of innovation requires a team to consider that task as a part of their work, complementary to, and as important as, the commercial task. Work on the culture must go forward during the workday. We’ll suggest, for example, that you include a warm up as part of the daily stand up. The team leader will lead this at first, but when it has become part of the routine, leadership will rotate among the group. Team members who learn a new exercise somewhere else will bring that to the stand up. You won’t tack this on to the day as something extra: it’s central.

As well, on analogy with the public schools, an executive or team leader might propose in-service learning requirements. Normally schools don’t require that teachers take specific courses. They demand instead a required number of course hours per year or other interval. Such courses include learning new techniques applicable to the work at hand; but, more important, they can be general—education rather than training.

Google is only the most well known of modern corporations to suggest that workers spend up to 20% of their work time on personal projects. Google encourages personal projects that have no readily discernible connection to current work, and imposes no requirement that such projects result in marketable outcomes. Now and then, of course, they do. And they’re a main reason why the competition has such a problem keeping up with Google. Not even Google knows what the next thing will be. More important, they serve as practice in innovation: people discover and refine their skills in a no-stress situation. They are free to be wildly creative.

In colleges and universities a similar situation obtains, though with considerable pressure attached at certain times in a professor’s career. We mean the custom called “Publish or Perish!” To achieve tenure or to be eligible for promotion, a teacher must make a contribution to the field. Mostly this means publishing the results of research.

Some places, Harvard Business School among them, grant tenure only to men and women who have achieved an international reputation within one or more fields. While this requirement weighs heavily on young faculty, the purpose is clear: research offers faculty an opportunity to practice the skills they teach.

More important, though less observable, accumulation of knowledge beyond what’s needed for tomorrow’s class supports a career after the initial thrill of teaching wears off and interest wanes. Of course these are ongoing programs; they have their true effect over the long term, as they become embedded in the company tradition and in an individual’s sense of work.

But, you say, “How do we have time to do this?”

Turns out that a reasonable amount of time spent in these pursuits increases productivity. When Frederick Taylor began his time and motion studies of workers shoveling coal at the steel mill, they balked at his requirement that they take breaks on a schedule he devised. They were paid for piece work, and feared that Taylor’s breaks were a management device to reduce their paychecks. Taylor insisted, and the workers discovered to their amazement, that their pay went up noticeably.

This notion of pay for story points has not caught on in the software field.

Many folks in the Agile community would argue that Agile is all about culture change. As you know, we do not see Enterprise Agile adoption as solely about anything. For most teams it starts out as a process change, runs headlong into weak testing technology and then confronts some major cultural elements as the scaling or replicating come into play.

Our Flow-Pull-Innovate approach can be mapped into a state transition diagram that blends changes on all these fronts.  It is our experience that teams neither have nor take time to appreciate these cultural items until they have shown some improvement. At this point, it becomes easier and paramount to reinvest some of these gains into continuing the journey. This can be in the form of slack time, schedule time for innovation, or new infrastructure in building, testing, or planning.

Now once teams get to the benefits of pull at a program level, the focus of adoption needs to move towards organizational culture.  I believe the transition from traditional to Agile, involves quite a shift in infrastructure, methods and guiding ideas.  The awareness for the changes in Guiding Ideas seems to come primarily from bottom-up adoption or occasionally from a new senior level executive who was brought into drive change.

Making changes of the magnitude we’ll suggest won’t be fast and easy. If you want to move fast, you’ll want to get help. This can be tricky. Consultants are typically a quick-fix; this won’t do in the long-term, but they can help with a push. However, a culture lasts, and work to create and maintain it should last as well. The consultant’s techniques stop lasting all too soon. We suggest that you find ways to learn about companies and teams that can become role models. This can be difficult. You’ll need to take time to build ongoing relationships of trust and reciprocity.

You can also consult people who routinely work in a culture of innovation. These include (but aren’t limited to) three groups.

(1) Actors make a new thing each night they perform the play, and their rehearsal processes are a compendium of good ideas for innovative agile teams.

(2) Theatre directors are a great source of method and lore for team leaders in an innovative culture. They every day address the difficulty of supervising men and women who have skills that they do not. They can’t bark out orders, but must find ways to encourage constant innovation.

(3) Painters (not house painters) in their work interact with an emerging form, the key element of collaboration, as they create a new and unique thing each time they make a picture. They can be especially persuasive and helpful on the question of replication: since they can’t do it (Every painting they make is new and unique, even if they try to copy themselves.), they have developed views and attitudes that software development teams and their leaders can use to advantage.

We remember a teacher who told his classes, “The way to improve your writing is to apply the seat of your pants to the seat of your chair.” The way to get started is to get started. Make the commitment. This can be a top down or bottom up movement, but support from above is key to a good beginning and to ongoing success. The budget for subsequent projects should include time and funds for preparation and team building of the kind we’ve described. Team leaders and managers should commit to constant reinforcement of the aim, and to vigorous support of performance by individuals and particular teams.

Keep an eye out for upcoming posts on this theme, where we will cover many of these concepts in greater detail.  But, as always, your feedback in the form of comments would be tremendously valuable in shaping our ultimate path and conclusion.

An Introduction to Lee

Jean and I, along with other Rally coaches write on the concepts of Agile Enterprise Adoption and our recommended approach called Flow-Pull-Innovate; however, most of that copy has been dedicated to the first two states of Flow and Pull.

Personally, I have struggled to write about Innovate because our language seems to be all-wrong. So we recruited a friend to help, his name is Lee Devin. With Lee’s help we are going explore the state of Innovate with words and stories that will help us understand this advanced state of Agile adoption. There are a number of topics that we have discussed in this collaboration and we plan to share all of them through this first quarter of 2010 (see How to Foster a Culture of Innovation)

Lee fishing in Colorado's 11mile Canyon

I met Lee Devin through my next door neighbor Gordon Wickstrom.  Lee was a colleague of Gordon’s in theater and a fellow fly-fisherman. Gordon is an old school theater professor, he believed in structuring the performance to give the actors a place to create. He like Lee has a passion for his craft and feels absolutely fortunate to have been able to work in the theater profession his entire life. Gordon and I have shared many a lively conversation about theater and software and it was one of those conversations that led me to Lee.

According to Gordon, Lee has a more creative approach to theater development; one that is more emergent than Gordon’s. After numerous professional interactions and three fishing trips, Lee and his family are good friends. And his son, Sean has got to be one of the best anglers on the planet; fishing with him is like fishing with Yoda.

Now into Lee’s book with Rob Austin, Artful Making.  This book blends Rob’s research into innovation and agile product development with Lee’s mastery of theater; it is a real joy to read. It conjures up some of my best memories of creating beauty and greatness in software. Their contribution to our profession is to help us break our mental models or metaphors around the work of software development. You can let go of your mechanical metaphors and let Lee give you a complete vision of software as a creative and messy design process for conjuring up real beauty and innovation.  After a fishing outing last summer in Boulder, Jean and I had breakfast with Lee and decided to collaborate with him on work around the topic of innovation. You can read Jean’s words about Lee and Rob, in her post  “What do Actors and Programmers have in common?”

Next up In our series – Reconceiving the Notions of Success and Failure

About the Authors: Ryan Martens is a goat cheese maker,  founding board member of the Entrepreneurs Foundation of Colorado, and Founder and CTO at Rally Software Development.

Lee Devin is a dramaturg at the People’s Light and Theatre, a Senior Research Scholar at Swarthmore College and a senior consultant with the Cutter Consortium. These activities often interfere with his fishing, and cause him to neglect his grandchildren.

Jean Tabaka is a wine enthusiast, author and Agile Fellow at Rally Software Development. Subscribe today to get free updates by email or RSS.

Over the last several months, I led four breakout sessions on Agile quality at our Agile Success Tour and in the process I heard these troubling comments:

“We don’t have enough time to test, because the developers give us working builds way too late in the cycle.”

“I wish our quality was better, but it’s out of my control to change anything.”

“Poor quality must be our fault as testers, since we are the ones responsible for testing.”

“We should test more, or we should develop slower, or we should specify our requirements better – that should improve quality.”

Agile development advocates that the whole team owns quality, but clearly many teams face barriers to accomplishing that goal. I’ve been thinking about these comments a lot lately, and I think the problem is that basic and predictable human responses are getting in the way of achieving higher quality.

You can certainly improve quality through changes in process (and many of those changes are at the center of Agile adoption), but more often when people ask me process questions, I hear teams struggling with the human aspects of those process improvements. By paying attention to the ways everyone naturally avoids responsibility, you will be able to move past the barriers that contribute to poor quality.

The best model I’ve seen for how to do this is Christopher Avery’s Responsibility Process. The basis of this model is that when problems arise, every individual goes through a very predictable series of thoughts that allow him to cope with what just happened, but also block him from moving into a mindset of learning and improving.

It starts with blaming someone or something. When you move past blame, then you justify the event with a story you tell yourself. Once you move past that story, then you turn the blame to yourself and feel shame. Acting on that shames often leads to feeling a sense of obligation. If the shame and obligation become too unbearable, then you will quit or detach to escape from those feelings.

All of these thoughts prevent you from taking responsibility and ultimately moving into a mindset of learning and acting. Sound familiar?

This same pattern subtly plays itself out every day for you and your team around you, especially with issues of quality. According to the Responsibility Process, there are three keys to taking responsibility: (1) intention, (2) awareness and (3) confront.

To learn more, I encourage you to join me and Christopher Avery for our January 12th On Demand webcast, The Best Kept Secret in Agile Quality, where we will talk about :

• the relationship between quality and ownership
• the difference between accountability and ownership, and how this difference affects quality
• how the Responsibility Process can be used as a framework to continuously improve quality through a focus on people and interactions
• how to apply the Responsibility Process to your development team

I’m really excited about what we’ve put together for this and would love to see all of you attend.[Reserve your spot now by CLICKING HERE]

About the Author: Zach Nies is a golfer, expert on Agile quality and VP of Products at Rally Software Development. Subscribe today to get free updates by email or RSS.

This week, I had the pleasure of attending the seminar “The Way of Artful Making” presented by Rob Austin and Lee Devin , co-authors of the book “Artful Making”.

While I have met both gentlemen separately in the past and heard them both speak, this was one of those golden moments when I was able to hear them co-present. And for me, I loved the odd mixture in the audience: MBA students, MFA student actors, and software engineers. (Okay, guess which group I was in?)

Lee and Rob have a great “pairing” style in presenting. For those of you who don’t know them, Lee is a professor emeritus in Theatre from Swarthmore College. And Rob is a former associate professor at the Harvard Business School and is now full professor at the Copenhagen Business School.

In co-presenting, Lee and Rob take turns applying their perspectives about the look and feel of artful making. For Lee, this is about life in the theatre. For Rob, this is about great product development and, in particular, software development. So two great tastes that, as it turns out, taste great together (sorry, a reference to an old candy advertisement :)

So, what do actors and programmers have in common? Well, some amazingly fundamental things as it turns out:

• Iterative work
• Collaboration
• Innovation

Theatre work and product development both thrive on iteration and collaboration. Lee described this in terms of rehearsal and the emergent look of a play leading up to and even after opening night. Rob affirmed the value of a collaborative and iterative approach in product development and provided videos from Boeing and Bang and Olufsen showing how both companies take advantage of this approach.

What do these practices have to do with innovation? Well in both theatre and product development, Lee and Rob encourage us to embrace what should be the glaringly obvious; that is, iteration and collaboration invariably produce innovation .

What happens when you put iterations and collaboration together? Rob introduced us to a term he had learned during his study of Boeing’s use of iterations: “try-storming”. That is, instead of just brainstorming ideas (whether in theatre or in product development), take your brainstorm and try it.  Find something out about it as soon as possible. Then “try-storm” the next idea. (I think I am going to have to steal that term from him!)

I was also very fortunate to be able to sit next to Pete Behrens of Trail Ridge Consulting during the evening. Talking with him afterward, he reminded me of a few more similarities between theatre and product development:

• You need to be able to surprise people in order to create value
• If you don’t know in exact detail where you are going, it’s okay
• The ideal play/product you hold in your head is very limiting; let go of it
• In iterations, like rehearsals, each iteration may be or even will be significantly different from each other
• We’ve been able to move to being more iterative these days, more Agile, because of technology making it cheap enough to iterate
• Nothing is lost and wonders never cease as we build up each iteration from all the iterations before

Artful Making through iterations, collaboration and try-storming—all are important if you intend to be a theatre or product development organization that is truly innovative in the 21^st century. And THAT is what actors and programmers have in common.

About the Author: Jean Tabaka is a wine enthusiast, author and Agile Fellow at Rally Software Development. Subscribe today to get free updates by email or RSS.

At Rally, we are always working on both maturing and growing our use of Agile. We started with a single development team and over the past 6 years have been through the process of splitting, growing, partnering, and acquiring.

We did this while continuing to inspect and adapt our development and our strategy execution processes.  We have teams in various stages of maturity using Scrum and Kanban to run all parts of our company.   As the CTO, I have my focus on our strategic planning and execution process.

In 2008, I started to focus on maturing our annual and quarterly planning.  To do that, I used Pascal Dennis’ book titled “Getting the Right Things Done” to structure those efforts.   (See related post about Learning from A3’s a story of 2009 Quarterly Planning at Rally.)

As part of that effort, we worked to change our quarterly and annual planning process to specifically follow a Plan-Do-Check-Adjust model. (Note that I like Pascal’s use of Adjust, not Act which is typically quoted in the Toyota models.)

Prior to 2009, we were simply using an inspect and adapt process to determine annual and quarterly priorities, aka quarterly rocks, based on feedback from last quarter’s results and the corporate roadmap.

This process worked well, but we had some issues including:

• A moving definition of done based on different standards of work (research, implementation, campaigns..)
• A delay in the feedback loop on strategic efforts made it hard to check and close well
• Too many efforts in a quarter lead to poor quality (We found 5 rocks to be too many for us during a quarter)

None of these are different than what most teams experience with going Agile.  So we (1) adjusted and moved to limit our WIP to three rocks, (2) focused on inspecting the definition of done in the meeting, (3) used company wide survey’s to keep from developing group think and (4) chose to do company celebration based on quarterly metrics and not the completion of quarterly rocks.

These all helped make the current process work, but the process was still frustratingly unpredictable, semi-random and always left something to be desired.  Many of the reasons for this are explained in Alan Shalloway’s and Don Reinertsen’s posts on PDCA and types of process The Difference Between “Inspect and Adapt” and Plan-Do-Check-Act (PDCA). Unlike Alan, I do not see or perceive a big issue with Scrum.  Based on my previous post around the roots of agile; Dean Leffingwell and I are in the same camp; Scrum is Lean.

As a result of moving to PDCA approach, we created a single “True-North” goal for the year and drove our quarterly rocks  towards that goal.

Now in Q4 of the year, we had some new changes to our process. By following the PDCA cycle for the year, we put a fine point on CHECK in this final quarter; Subsequently, we have a  Q4 quarterly rock focused solely on checking our Q3 and annual work to fine tune it based on real output.  This is an example of where PDCA cycle is more intentional than basic inspect and adapt at forcing the discipline of checking.

We focused a quarterly rock on checking  to make sure that we are done-done-done with our True North goal for the year.  We also have another Q4, cross-functional rock team focused on preparing for Q1 and 2010 annual planning.  This PDCA-driven rock is a major milestone for me personally.  It moves annual planning solely from my shoulders to a team effort; this pushes ownership of strategy down to the extended management team.  As a result, I am very happy with the move to PDCA for our 2009 strategy execution process. In Don Rienertsen’s terms,  our PDCA-driven process is more defined, while still with un-predictable output and governed with lots of feedback.   This was simply an increase in process maturity that was mandated by our continuing growth.

To do this, we create a team, called the Mountain team, to help the company transition our strategy execution process.   This team steered the transition and proposed our quarterly rocks based on the PDCA process.  And thanks to the ego-less and steady hand of our CEO, we have a very collaborative culture that quickly converge on these changes and quickly put them into action.

I hope this was helpful for you to learn about our experiences with continuous process improvement and our step-function transition processes.  Please note that we are not a perfect comparison to larger organizations trying to transition to large scale agility.  In addition to doing lots of growing, we have another difference that started when we began back in 2003.  We built Agile and Lean principles into our core values.  You can see the difference this might make in my comments to Israel Gat’s post More on Agile Social Contracts.

Specifically our core values are:

• Create your own reality
• Make and meet commitments
• Theory-driven decision making
• Treat people with respect
• Support our community and give back
• Maintain a healthy work/life balance

This is the social contract that we keep with employees. During transitions like this you need culture or a social contract to reinforce your moves toward Agile and Lean behaviors.

About the Author: Ryan Martens is a telemark skier,  founding board member of the Entrepreneurs Foundation of Colorado, and Founder and CTO at Rally Software Development. Subscribe today to get free updates by email or RSS.

Sarah: “Walter, I just want to check in with you following the team demonstration and see how you are doing with the new Agile approach”

Walter: “Sarah the results were thrilling for the customer and the team.  Everyone seemed engaged and the dialogue was very healthy. I see it, but it does not make sense.  We are moving features through the team faster, but I had to do this with dedicated resources.  I am sure this is costing me more.”
Sarah: “Walter, this is totally normal.  You are seeing the difference between single tasking and multi-tasking as well as optimizing the whole versus a certain roles or steps.  We can do a little model to show you that this Agile approach is better, faster and cheaper.”

Walter: “Well that would be very good because it is very counter-intuitive to me and all my management tools and tricks seem to run at odds with this approach.”
Sarah: “Great observation, Walter!  As you told me earlier, you tend to focus on fully allocating engineers.  In Agile we focus on increasing the throughput of value by optimizing the whole flow through all roles.”

Walter: “Right now I just want to stay out of the way, because I do not know how to help.”
Sarah: “Walter, let’s spend some time to get you comfortable with the impacts of batching, queuing and task switching.  Once you see the math, we can talk about how to serve the team by proactively clearing impediments to smooth flow and taking some savings to invest more in them.  The team will love you for this commitment.”

What benefits will you see when teams are in Flow?

As we described in “What so Great about Flow?“, we think of attaining Flow as the first step in our recommended approach to enterprise Agile adoption.  For this step, we focus groups on adopting agile by the book by team; thus the impact from Flow is only incremental and isolated to the specific team.  However, this does not mean the results of this effort are not noticeable and infectious.

Foremost, groups that attain Flow make changes on the way to becoming a team.  When given space and dedicated members and short time box, new agile teams take three key steps:

1. First the collection of individual contributors comes together to plan a limited portion of their own work. 
   
2. Second they set norms and limits that lead to common commitment to deliver working, tested increment. 
   
3. Finally, they open their increment up to feedback and open themselves and their process up to feedback, introspection and adjustments for continuous improvement. 
   

The benefits seen from doing this are many:

• A team is forming and that makes work more fun and easier for them to manage
• Work-in-process is getting reduced by focusing the work on a small increment of functionality
• Testing is coming forward in the process and quality is beginning to become a team issue
• Hand-offs and delays are declining by dedicating a cross-functional team to working on one thing at a time
• Feedback loops are shortening in the demonstration and review process helping to prioritize the next step

Typically these benefits take one to three iterations to manifest themselves and translate into incremental productivity increases of 15%, 25% faster cycles and a reduction in downstream defects (See the Agile Impact report for more details of business improvements from Agile).  Most of these teams are reporting the benefits of flow.  Teams in Flow settle into a predicable pattern of delivery.  They are not perfect, but you can count on them and estimate based on their historical velocity. We look for these metrics to know if a team is in the state of Flow including:

• a rate of 90% or greater of Story Acceptance per Iteration on an iteration over iteration basis
• an average of zero net, new Defects added to Defect list across iterations
• A reduction in 1/2 of the amount of stories that are in-process across iterations
• A continuous build success rate of 90% or greater for the team’s isolated code base

In general, they are starting to do things in a more lean and less wasteful way.  By working together on a small batch of work with a clear definition of done, it allows the team to focus and reduce the task switching.  To understand why multi-tasking and task switching do not work, you should read this post from Mark McGuinness at Lateral Action or check out Tom Demarco’s book “Slack” and specifically pages 16-21.

However, the most important benefit is the positive feedback from the team members with regard to forming a team and working in this intuitive and social approach.   It is this positive feeling that propels teams to move past Flow and into Pull.  Congratulations if you have the continuous improvement snowball beginning to roll downhill at your organization.  Building the trust and capabilities of the team is the most effective path to more value delivery.  (See “The Scrum Picture is wrong” and the comment/link about the Lean Journey from Jason Yip.)

If your team does not find this benefit, it is clear that there is a fundamental issue that needs to be resolved.   This is a great time to bring in an outside coach to help the team retrospect and give them space to form.  In these situations, it is easy overlook the fact that teams need to go through the process of of forming, norming, storming as they reach toward performing.  Remember this is a journey and you can not go there without building the team.

About the Author: Ryan Martens is a fly-fisherman, founding board member of the Entrepreneurs Foundation of Colorado, and Founder and CTO at Rally Software Development. Subscribe today to get free updates by email or RSS.

Introducing Rally's Engineering Blog

As some of you have already begun to notice, the Rally Engineering team is now in full effect with their very own Blog.

This blog provides a great opportunity to (1) gain further insight into Rally’s development environment, (2) ask questions and interact with a high performing Agile engineering team and (3) learn tip’s and tricks from the team’s experience working in a wide variety of technologies.

I have read all their posts and there is something in there for all the rolls and levels of experience on agile teams.  It is unique because of the open authoring model for all members of a fast growing set of agile teams.

With 15 posts published, and many more regular contributions on the way, I invite you to join me as a new subscriber to Rally’s Engineering Blog (click here to subscribe and here to visit the blog)

About the Author: Ryan Martens is a fly-fisherman, founding board member of Entrepreneurs Foundation of Colorado, and Founder and CTO at Rally Software Development.