Agile Development Blog

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.

Clippy - the ultimate bearer of redundant information

Remember this guy? He used to pop-up when you least expected him and offered up information about something you already knew.

I’m sometimes reminded of Clippy when I hear the rhetoric from some in our Agile community.

We’re at an inflection point right now. The pragmatists and the conservatives are realizing the fallacy of large upfront planning.

As teams from these later adopters are striving to become leaner and more Agile, they struggle with the inertia that is inherent in large organizations.

• They know that co-located teams are more successful but they prefer an environment that extends the benefits of working from home.
• They know that it is much more efficient to work on one task at a time but someone way above their pay grade won’t let them have such a single minded focus. This is not a battle they can win right now.
• They know that value can be delivered faster if testing can be pulled forward yet they don’t have budget to buy the tools they need.

For such decisions Clippy always knows the right answers for everybody.  But Clippy doesn’t have to walk in their shoes and it won’t be Clippy who gets fired for taking a risk.

Maybe Clippy needs to listen to Norm Kerth (from his book Project Retrospectives):

“Regardless of what we discover, we understand and truly believe that everyone did the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand.”

or as my colleague Julie Chickering says:

“I think we need to acknowledge that there are parts of organizations that will be less agile than others while moving from traditional to agile projects. That the big ole ship can’t turn on a dime. To me this is part of being a trusted partner.”

As you strive to become leaner and more agile, you don’t need Paper Clip Consulting, you need a trusted partner.  You need someone that will begin with the end in mind yet not seek to get there immediately.  A trusted partner will take the time to understand your environment, accept that there are always constraints and help you establish a cadence of continuous improvement.

About the Author: Ken Clyne is a kayaker, Certified ScrumMaster and Agile Coach at Rally Software Development. Subscribe today to get free updates by email or RSS.

Don't let this be your user!

Recently, my Rally colleagues Ben Carey and Ryan Martens delivered a great webinar about testing and quality.  What particularly struck me about the session was how Ben set up why we should, at a very personal level, care about testing and quality.

Enter Amy and her daughter Morgan.

As Ben told the story, Amy was a back office admin in a physician’s office. It was her responsibility to get billing out to insurance companies for the practice, and on one particular day, things were not going well.

She kept getting cryptic error messages. The batch just wouldn’t go through. Stress mounted. To add to Amy’s distress, it was nearing time for her to pick up her daughter Morgan at school. Morgan had just started school. Only 4 weeks in, Morgan was suffering some separation anxiety. Amy felt the urgency to be there for Morgan as soon as school let out. And yet, she was stuck at her desk dealing with these insurance issues.

Why should Ben be talking about Amy and Morgan in a webinar about testing and quality? Because Amy was Ben’s customer. Ben was on-site to see how his software was supporting the practice. And so, he personally felt Amy’s mounting stress in using the software HIS team had delivered and HER doctor’s office had paid for. When Amy started to cry, it was all over for Ben. He had to do something.

What does Amy and Morgan’s story tell all of us?

1. Users deserve better than this.

2. On an Agile team, quality is everyone’s job!

We often think of testing as an issue for the tester role alone.  But this stance sets a number of bad dynamics in motion:

• When we don’t fix defects, we declare doneness by “hiding” defects in a defect backlog
• Hidden defects accumulate into hidden technical debt
• Technical debt slows down our ability to deliver subsequent releases
• An ever-increasing defect backlog can be demoralizing for the entire team
• Engineering resents the business when being forced to deliver features when the engineers know defects exist
• Business resents engineering for not being better and faster at building features
• Testers resent testing left until the end because it puts business, engineering, and testing in a tight spot

So here is a thought: quality is not just an engineering issue; it is a systemic issue. That is, it is driven from the top down in a business not from within one part of the organization. A business policy about quality impacts our users by directly impacting their quality of life. Amy’s stress about picking up Morgan from school could be traced back to a testing and quality policy in engineering that was driven by a policy in the business: get features out.

As you adopt Agile, work vigorously to create rigor in your testing and quality goals. Why? Because your policy can hit hard in ways you don’t currently track. Pay attention to more than just the internal cost of technical debt. Let’s pay attention to the quality of life of our users.

The next time you are logging a defect versus fixing it, don’t forget about your Amy and Morgan.

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.