Ah, Marketing.  Enter a world of countless project requests, numerous stakeholders, limited resources and rapidly changing market conditions.

Sound familiar?  In fact, marketers face a lot of the same challenges as development teams, and Agile can be a powerful way to alleviate those common issues and intelligently plan our work.

In steps 1-5, I’ll explain how Rally’s marketing team conducts our version of Release Planning.  In steps 6-10, I’ll explain how we run our iterations to meet those commitments. Our planning processes continue to evolve, though this method has worked for awhile now.

10 Steps to Successful Marketing using Agile and Lean Practices

1. We recognize that Marketing has challenges that are different from Development.

• There is no unique product owner.  For example, if we chose Sales, then we would always rank lead generation over branding, customer programs or analyst relations, and that could ultimately hurt our company. Therefore we have to use some best-guessing to prioritize our backlog and determine what is most important.
• We face hard event deadlines set far into the future.  Sometimes we have no choice but to commit to an event or sign a contract months ahead of time.
• Each team member has unique expertise, i.e. writing, event planning, PHP development and so forth.  So one shared backlog is inefficient.

Now that we’ve reviewed the challenges, we give ourselves permission to do what we need to do, have patience and adjust anything that isn’t working for us.

2. Conduct an ORID to learn from the past

Before planning for the next quarter, we hold a retrospective in the form of an ORID, “a means to analyze facts and feelings, to ask about implications and to make decisions intelligently”, a process created by the Institute of Cultural Affairs.  We gather as a team to share:

• Observations (O) – What do we know?
• Reflections (R) – How do we feel about this?
• Interpretations (I) – What does it mean for the organization?
• Decisions (D) – What are we going to do?

This strategic overview helps set context for us to prioritize our focus for next quarter.

3. Align ORID decisions with company strategy

At Rally, we conduct quarterly and annual planning using the Plan Do Check Adjust methodology as explained in Getting the Right Things Done.   As we look at the overall company direction and goals, we keep these in mind as we hold planning at our own level.   Ideally, our major commitments support and align with company strategy. This also helps inform our “stop doing” list.

4. Poll our stakeholders

As part of determining quarterly commitments, we poll our major stakeholders for their top requests.  We use a Google survey to rank these requests by importance, size each request and bring these epics into our release planning meeting, to be included as part of our ranked backlog.

5. Conduct Release Planning to prioritize and agree on quarterly commitments

Now that we have all of our inputs, we hold our quarterly Release Planning session.  We write each epic on a sticky note and look at all of the possible work we could do this quarter.  Then, we evaluate epics based on importance taking company goals, stakeholder wishes, market realities like conferences and our own passions into consideration. We decide what we can realistically commit to, and agree as a team.  We keep in mind that making and meeting commitments is a huge deal, and we try really hard not to over-commit.

Part 2 – Meet our Marketing Commitments

6. Create a task board

Since our marketing team is mostly co-located, we pin up several large sheets of paper to use as a task board.  This is where we review our commitments on a daily basis as a sanity check that our stories are prioritized correctly and that we are tackling the right work as the quarter progresses.

As a team, we write our quarterly commitments on the task board with the definition of done assigned to each one.  We also include our “foundational” work – recurring work like website updates, online ad campaigns, field events, press releases and other important work that we need time to do.

Note: this is not a Kanban board because we do not have a shared backlog nor do we have a team-wide WIP limit.  As we break into smaller project teams that do share a backlog, we often use AgileZen to manage this work.

7. Hold iteration planning every 2 weeks

Every 2 weeks, we hold an Iteration Planning meeting.  Each team member has her own sticky note color, creates stories on those notes and manages her own prioritized backlog using T-shirt sizing to roughly estimate each story.  In this hour-long meeting, we begin by expressing appreciation for team members who gave exceptional assistance.  Then we hold a brief retrospective on what worked and what should change for the next iteration.  Finally, we each read out our prioritized stories for the iteration, putting them on the task board’s backlog.  This gives everyone visibility to what’s happening, identifies if someone is over-committed and lets the team swarm any epics with looming deadlines.

8. Conduct a daily stand-up

At the same time each day, we hold a stand-up meeting (with a consistent conference call #) that is at most 10-15 minutes long.  We form a semi-circle in front of our task board and share no more than 2 cross-cutting significant actions or take-aways from the day before, no more than 2 that we are planning to accomplish that day, and whether our work is blocked by any issues beyond our control.   As we start working on stories throughout the iteration, we move them from the backlog into their section of the task board to show what we are working on.  When the story is complete, then we move it to a place on the task board labeled “Done”.  Once the commitment’s Definition of Done is met, we check off that commitment and feel good about completing it.

9. Be patient as things change

It would be lovely if nothing changed during the iteration, but that just doesn’t happen.  The goal is ultimately to respond to change rather than cling to an outdated plan.  As new opportunities arise, new time-sensitive information appears and new requests are made, so our iteration work changes and that’s ok.  We try to just document what we’re working on and create new stories so that we can make intelligent prioritization decisions during the course of the iteration.

10. Retrospect, inspect and adapt

As we keep running our iterations and fulfilling our commitments, we are always looking for ways to improve them.   Ultimately, we’re using Agile to improve the quality of our work life by using objective, smart ways of planning how we spend our time. And we’re learning a lot from the journey.

I am passionate about design; if it were not for the boom-bust cycles in architecture, I would have followed that education/career path.  As a result of that passion, I got really excited when I saw HiveLive four years ago.  So excited in fact, that Rally jumped in as key first customer and based Agile Commons on HiveLive’s platform.  I even personally invested in the effort led by three Kembel brothers: John, Jeremy and Geoff.  Last year, HiveLive’s  journey took another turn as they sold to RightNow. After meeting RightNow’s David Vap and speaking with a good part of their technical team,  I would say John, the VP of Social Solutions, is right that they made a great move.

John’s design-thinking approach was front and center to HiveLive.  It came from his background at Standford’s design school and a stint at IDEO.  As I got to know John, he mentioned all the great things going on with his other brother and twin George.  George was busy creating a new version of the design school, called the Stanford d.school.   The new d.school has broadened beyond just a partnership of art and mechanical engineering to become a interdisciplinary school that brings design thinking to all majors.   As I learned more about this, I started pulling on John’s shirt to get me out there so I could go see the place and meet George.  Well last week, I participated in the first ever d.social summit for two days with 15 folks focused on the intersection of design thinking and social thinking.  Twins John and George Kembel actually facilitate in stereo.  To watch and be a part of their combined effort was like drinking from a fire hose.

The event and the people were great fun to work with and pushed my limits on the overlap of design thinking and social thinking.  Working there really made me feel strong and I found myself in a flow most of the time.  It caused me to notice that I really love the expansion of design to design thinking. But for you and your agile teams, the innovations in team room furniture was really important. Creating a culture of innovation relies on creating the right environment.  If you have read Takeuechi and Nonaka’s book on Knowledge Management, you will recognize the concept of “Ba.” Ba is the shared space that creates context for the knowledge-creating company.  (See figure 4.3 on page 102 of their book for a cool illustration of the whole concept)

The d.school is full of flexible, collaborative space of all kinds, shapes and sizes.  They are constantly trying new things there.  Built for running multiple, parallel design projects in 15 week cycles, it is empathetic to extreme users.  The space is in its sixth iteration of the space.  Scott Doorley and Dave Baggeroer worked with George over the last five years to really make this place something special.   As a result of working at the extreme of rapid collaboration, they have come up with some fantastic furniture designs that you should consider copying for your team and meeting rooms.  Unfortunately, you can’t buy this stuff – you have to build it locally.

Here is a set of stackable and highly portable white boards.

Notice the Z-shaped foot that allows them to stack and move around corners.  These ideas came from retail stores.  Also notice the red peg in the whiteboard.  This is designed to hang portable whiteboards that you can take back to your own space.   It could also hold a pad of flip-chart paper.

This line is where they store the student efforts.  Notice how the hanging whiteboards are stored.  It is easy to imagine collaborating in another person’s office and then bringing the whiteboard back to your office without using tons of flip chart pads.

Below is a portable wall system built with spring-loaded feet to allow you to make semi-transparent or opaque walls by lightly snapping them into place.  You can see them used above to make the line where student’s store their work.

These cool pommel horses, pictured below, make great furniture for a team collaboration space.  You can sit, stand or work at the structures and they force you to not think in hierarchies:)

Finally, don’t miss the d.school’s blog and the coverage of their sugar cubes.

I hope some of these pieces of furniture compel you to try some new furniture in your space.  If you are not quite sold, you might read Tim Brown’s new book “Change by Design.” It is a great living example of the approaches that IDEO and the d.school use to create empathy, insight and desirable design in physical, virtual and social systems.

Do you have any experience applying design thinking in your agile teams?  Jared Spool’s talk at Agile 2009 was a great example of applying design thinking to software.

Ryan Martens is a tomato grower, founding board member of the Entrepreneurs Foundation of Colorado, and CTO at Rally Software Development.

Dear Readers,

Writing or receiving a break-up letter can be fairly daunting or shattering, depending on which end of the letter your name appears. That letter puts a pretty hard stop to a relationship. It’s communicating detachment and finality. It can create a lot of pain whether intended or not. In contrast, a love letter is uplifting. The endorphins fly! Someone is revealing their attraction for you, and their hopes and wishes for a future with you.

Now, there is a reason I have these letters on my mind. I’ve just returned from Rally’s Agile Leadership Forum – a great gathering of people eager to lead successful Agile transitions in their organizations. The event included a lively presentation from Forrester Research’s Senior Analyst Dave West: “Agile Adoption – Research Findings on the Adoption of Agile.” (You can find some of Dave’s data in the “Forrester Wave: Agile Development Management Tools, Q2 2010″). We also enjoyed an inspirational talk from our CTO Ryan Martens, called “Moving Agile Beyond Software.” These great presentations were followed by breakout sessions and a panel discussion about Agile challenges. Now, how to end the event?

As emcee of the forum, I not only kicked off the event, but it was my job to bring closure to the gathering as well. How can we have people walk away with thoughts about Agile? Why are they interested in the first place, and where do their concerns lie?  I was inspired by a video I recently saw about “breakup letters.” The Breakup Letter is a design research tool that Smart Design uses to understand the emotional connection between people and their products, services, and experiences. One person broke up with his cell phone, another, her single-cup coffee maker.

Now, just how does this relate to the Agile Leadership Forum? I liked the concept of the breakup letter, but I decided to entirely flip the idea and close the event by asking everyone to write love letters instead. In the spirit of Cyrano de Bergerac, I asked each table of participants to work together in crafting a “Dear Agile” letter. In this letter, they were to convey their attraction to Agile. And, they were to reveal where they were concerned about as well. All letters were to be from a secret admirer :-)

Once the groups began to read their letters, I knew we were on to something. Though I don’t have the reading of the letters on video, here are a few examples of our “Dear Agile” love letters.

 

Run this exercise in your own group to find out what the Agile “lure” looks like and also what the “turn-offs” might be.

Breathlessly awaiting your comments,

Jean

p.s. If you want to read some of the transcribed texts of the love letters, read on!

__________________________

Dear Agile,

I have admired you from a distance for some time. Waterfall and I are in the process of an ugly breakup. There is so much about you I need to know. My friend says great things about you. You are so simple and straightforward– no mind games like Waterfall.

This won’t be simple. Waterfall still has clothes at my place. My Facebook status is confused.

In the relationship as we get to know one another, we will have to know each other carefully– co-locating right away? Are we sprinting too fast?

Be gentle with me.

Looking forward to a rapidly developing future.

xoxoxo,

Secret Admirer

__________________________

Dear Agile,

I love you because you offer quick cycles, better quality, and better teamwork. From the first time I saw you, I thought I could begin saving money and add business value.

But, fair Agile, you are not so simple. I’ve heard you are a micro-manager. I don’t totally understand you. Some people are confused by you. On the surface, you sound so perfect and simple, but the more I get to know you the more questions I have.

But, among all my choices, I choose you. You promote collaboration, and allow me to turn things around quickly. You’ve helped me trim weight and stay lean. Don’t disappointment me, I trust you!

With all my love,

Megedá

___________________________

Dear Agile,

I loved you from the first moment I saw you, I loved your fast, speedy releases and that you don’t come with a lot of baggage or documentation. You’re simple and down to earth. You are a great communicator. I always know where you are and my friends love you, too.

I am, however, a bit concerned that not everyone accepts our relationship. I am worried that as my job continually grows and my needs scale up, whether you can handle the increasing challenges. And I’m concerned whether I can afford you… Our relationship and your attachments are what intrigue me the most.

Looking forward to spending more time with you and getting to know you better.  – Your secret admirer.

___________________________

Dear Agile,

We love you, we think you are awesome – for the following (bulleted) reasons:

• Agile accepts changes and encourages frequent changes
• Agile can start implementation before full requirements are known.

We do however have a few problems with you agile –

• Handling cultural change in the organization
• Does not solve all our issues
• Makes distributed teams harder to work with

- Your secret admirer -

Matt Phillips is a Senior Project Manager who has spent the last few years helping shape the Agile development process at Lulu.com. He currently heads up the Lulu Project Management Office and has spent several months setting up Agile practices in Lulu’s India office, based in Bangalore. In advance of his executive panel discussion at Rally’s Agile Success Tour in Raleigh, NC, we sat down with Matt to ask him 5 questions about Agile.

1. How have you implemented Agile across your organization?

We’ve rolled Agile out among all of our distributed teams, which are located in Raleigh, NC, the Ukraine and India. The time zones have historically been a challenge, so we had our remote teams spend several weeks in the Raleigh office working through daily Scrums. Now, they’re essentially as included in the process as possible. We use video conferencing for daily Scrums and to schedule iteration planning. All the teams collaborate to define stories, determine velocity, and plan iterations. We use Rally to make projections, track our velocity, and get visibility into the health of our projects. The metrics have become indispensible for judging how we’re doing, making accurate projections, and delivering upon our commitments.

2. What was your #1 reason for adopting Agile development?

Lulu adopted Agile at a point where the company was very much in start-up mode. The ideas were coming at a frenetic pace and the engineering team size was poised to expand. Agile methodologies were a good fit for Lulu’s culture and environment. The concepts of short iterations and regular release cycles paired with Scrum provided a quick time-to-market period for new ideas. At the same time, by adopting Agile methodologies, Lulu gained increased insight into the development team’s progress and performance as the team grew and feature sets became more complex.

3. What has been the biggest benefit of adopting Agile?

The metrics and amazing visibility we have into development projects. This is especially important for a team that’s 9,000 miles away. We have visibility into how they’re progressing on features, what’s coming next in the roadmap, and really flushing out what the product backlog looks like and where we’re headed.  Prior to implementing Agile, it was very hard to sync-up  (because of the 9 ½ hour time difference), maintain a feedback loop and foster collaboration with teams so far away.

4. What one piece of advice would you give to new Agile teams?

My advice would be to ease into it – kind of like steering a cruise ship, not turning on a dime. Start with familiar concepts and gradually introduce Agile practices over time. We started with familiar ideas like release dates, associated task lists, estimations, and tracking criteria. Then, we used a phased approach to introduce the concepts of iterations, story points and relative sizing, velocity, and ranking. We continue to work toward more granular inputs to smoothly coordinate roles, tools and dependencies within Rally as we go along to continuously perform at higher levels and get better outputs.

5. How can you tell that Agile is successful at Lulu.com?

One of top ways I can tell that Agile is successful in our organization is that people, even outside of engineering, are speaking in story points. That tells me that Agile has really taken hold. Using story points and velocity for our release planning makes it easy to arrive at a date that everyone is comfortable with. On top of that, our track record since adopting Agile shows that we’ve been delivering on our commitments every time.

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

Do you notice a difference between problems and difficulties? A problem has a solution. When engineers solve it, the problem goes away. It’s a question raised for solution with fixes, tests, and checklist updates. In contrast, a difficulty has no solution. A difficulty wants you to sit with it, address it, not solve it. Artists know this world of the difficult very well.  No definitive fix, test, or checklist will suffice. Sitting with and playing with the difficult is simply part of the knowledge work of the artist.

For both the engineer and the artist, a difficulty is often what tangles up the solution to a problem. We see problems and difficulties all around us in the world of innovation. What’s needed to address a difficulty may not be clear at first, if ever. You may, in fact, never achieve that lovely industrial clarity. And yet, our ability to gaze unflinchingly into the face of difficulty will lead us to solve problems with greater innovation and deeper artistic mastery.

Difficulties require “AND” thinking

Difficulties are fuzzy. Improving how we address difficulties requires us to hold a large container with the word “AND” versus the word “OR.” This concept was first introduced to me in Peter Senge’s Fifth Discipline Fieldbook. I also delved into the topic in his course on Leading and Learning for Sustainability. To work with difficulties, we hold and play with a spectrum of possibilities, multiple solutions sets: this AND this AND this AND this. For the actors in a theater ensemble, AND means absorbing a variety of possibilities with the materials surrounding the play. Many innovative outcomes await based on the ensemble’s ability to hold the ambiguity of the art and embrace that sense of release.

For engineers, this might look like the following: you are solving multiple simultaneous equations for problems you see in the larger system. To be able to hold on to this container, you and the team have to feel safe “failing” with lots of little experiments. You must keep the “art of the possible” in mind. This is not an easy task for an individual, much less a group. Difficulties that accompany problems require the courage and patience to sit in a large container of ambiguity.

Consider the wicked problem example

In their book Wicked Problems, Righteous Solutions Peter DeGrace and Leslie Hulet Stahl help us delve further into problems and difficulties. Wicked problems arise out of several conditions. First, the problem domain is complex and fraught with difficulty. Then, the solution domain is similarly complex and difficult.  Finally the two overlap. That is a wicked problem. Wicked problems hold nests of difficulties. Let’s compare the wicked problem of an engineer and one of an actor.

The engineer’s work begins by reading a user story and exploring the problem sheet from the architecture council. In this assignment, the engineer must be prepared to address known and unknown difficulties on the path to a solution. The engineer recognizes that there is no one solution. How difficulties are addressed may be the key to just how innovative the resulting solution is.

This assignment is the equivalent of a script given to actors. The script is not a limit, but rather material on which to perform and interpret to create something new. There is no one solution. And so, the actors hold ambiguity as they move to the ultimate offering to their audience.  How the final play comes together may depend on the ensemble’s ability to play with and address the large realm of possibilities.

The art of the possible and innovation

Like actors, engineers and other knowledge workers need to do our homework, invite innovation and alternative solutions. We need to address difficulties not by point solutions, but by applying “AND” thinking, creating large containers of possibility. We must embrace the art of the possible. In the case of the actor, this comes in the form of rehearsal, ensemble and release that ultimately leads to the actual performance. In the case of the engineer, this work comes in the form of design spikes, set-based engineering, and tests. In both cases, experiments create space around difficulties. The art of the possible broadens the team’s or troupe’s innovative outcomes.

For such a culture of innovation, “AND” thinking is a vital function. At Rally, we apply “AND” thinking in how we address difficulties in a variety of ways. We may take a particular problem with its difficulties and spread it across a paired team of engineers. The teams work safely in an “art of the possible” mode for addressing difficulties in a way that leads to a better solution. We eventually move through the “AND” to a final solution, having addressed the difficulties in a variety of contexts. How you invite “AND” thinking and the art of the possible into your organization may include your Chief Engineer, a Product Owner, Director of System Engineering or a peer engineer all working in a new larger container.

Say “No,” to “No way!” and “Yes,” to “Imagine if…”

Within given circumstances, which are different for each team member, and a safe container for the conversation, the group can play out the implications of a solution, and discover its virtues and flaws. As with an ensemble of actors working through the possibilities of a scene, the only rule is: Never say, “No!” Swallowing that “No” can be hard! You must fight your first response to a suggestion or proposition, which is often “No, there is no way that it will work.”

Instead, the thing you must do is think, “Wait a minute. Let’s assume it will work. Let’s find out what happens when it does.” And, you’ll find out what happens when it does by behaving (thinking, talking, deciding) as if it is in place and working. If your first response is “Oh, wow, what a great idea!” the release might be, “How do I fit myself into this? What can I do personally to make it work?” The tool here is imagination.

We must find comfort in ambiguity and uncertainty. The question is: how can you create the container that allows your team to live with this difficulty and keep from jumping to try and solve it? If we create a culture friendly enough to notice accident and serendipity, we set ourselves up for the asymmetric payoffs associated with successful innovations. Our “AND” thinking and art of the possible ferret out the wicked problems and harvest collective team creativity.

Here’s something obvious I’ve learned the hard way: delivering “potentially shippable product increments” each and every Sprint isn’t easy.  Essentially you’re trying to take all the disparate activities that occur throughout the waterfall process, focus them on just the little product increment’s functionality and then jam them into a teensy little Sprint.  Hard to do and definitely pretty unlikely to get accomplished right out of the chute. The authors of “Practices for Scaling Lean & Agile Development”, Craig Larman and Bas Vodde, forgive you in advance for not getting this done straight away. In fact they suggest that this is more a goal the team will approach over time than a rule they put in place on day one.

The authors propose something very simple but very insightful:

• Sketch out all the things you need to do to get your product out the door.
• Define “done” as that subset of those the team is currently capable of performing every Sprint.
• Use your retrospectives to challenge the team to bring more and more of the “undone” work into each Sprint.

This has already changed the way I think about retrospectives. For other nuggets from Larman and Vodde’s book, read on.

Overall a Must-Read for Agile Development Leaders

I was blown away by “Scaling Lean & Agile Development”, as you can see from my bullish review on O’Reilly.  Some time has passed since then but I still feel that it’s one of the most important development books I’ve read.  That book alluded to the companion volume, “Practices for Scaling Lean & Agile Development”, and as you can imagine I awaited its publication eagerly.  It came out in February – I’ve worked my way through it now.   It’s most definitely a worthy successor.

The first book presents theoretical and philosophical underpinnings for agile and lean development. The second book presents a survey of practices relevant to all aspects of the process of developing software at scale, presented by two guys who bring a wealth of knowledge and experience to the table.

Continual Investment in Requirements

Larman and Vodde present practices relevant to a continual investment in requirements throughout the product development process. This is done both up-front, in seeding the product backlog, and iteratively, in refining requirements to support upcoming Sprints.

I love the emphasis they place on whole-team involvement in the initial Product Backlog development effort – even for projects with large teams.  Too often I’ve seen this be the provenance of Product Owners, working in near isolation, which does little to get the project off on a good footing.  The first the team sees of the requirements is the Product Backlog itself, having been involved in none of the  discussions and thought that went into it.

The notion of requirements areas, which was introduced in the first book, is leveraged here to help parallelize the initial requirements development work.  Concurrent sizing and value estimation workshops keep the requirements work rooted in reality.  They spend some time on the problem of bootstrapping a consistent sizing process in a large scale team. The use of cross-team estimation sessions result in the development of a canonical set of sized stories used as a basis for subsequent sizing at the team level.

In Favor of Forward-Looking Requirements Refinement

The discussion of forward-looking requirements refinement really resonated with me. I’ve found in my own practice that peeking ahead at the Product Backlog items upcoming in the next Sprint and then spending time together working through them to understand what they really mean – before we get into the Sprint planning session – goes a long way towards supporting a predictable iterative process.

It also puts the requirements elaboration just barely outside the Sprint that the work is planned for.  This separates coming to an understanding about what we want from the stress of figuring out how to fit it into a Sprint, which makes for more open and enjoyable requirements development.  The authors suggest the use of examples and Acceptance Test Driven Development (ATTD) to more precisely capture the intended behaviors of the stories in a way that realizes both conversation and confirmation of the “three Cs” . Smart.

The authors show how traditional approaches to project scoping and commitment (where separate product management and development organizations act essentially as competitors) are very much analogous to the contract negotiation that the Agile Manifesto cautions us against.  I’m surprised to admit this never occurred to me – I always read that part of the manifesto pretty literally. But it’s inarguably true that the wrangling between these two groups over project scope and timelines that happens in many organizations is a form of contract negotiation, and the waste it drives can be startling.

The arm wrestling of the product management “market ask” captured in a Market Requirements Document followed by the team’s “development response” carefully defined in a Product Requirements Document is a case in point.  Weeks and months can go by during this ritual.  What are the development teams doing during this time?  Not at lot, in my experience.  Does development really “win” if they manage to push out the end date or reduce scope?  Does product management really “win” if they manage to squeeze in extra features or pull in the release date?  I’ve seen how the empowerment of the Product Owner and the establishment of the Product Backlog as the single high-level requirements and release scoping artifact helped to prevent some of these painful dysfunctions but I’ve never thought of them in terms of an imbalance of contract negotiation over customer collaboration.

Creating “Desire Lines” in Design

Larman and Vodde strongly advocate wikis as the preferred basis for the technical documentation the team develops.  They suggest a page for the overall product and pages for each Sprint. That worked for my teams as well, although there was always a certain (healthy) tension regarding what was appropriate for Sprint documentation and what should be living documentation at the product level.

They present the compelling idea of “desire lines”, which, in landscaping, refer to paths that develop naturally, as people use a given space.  Rather than guessing how people would use the area, they are observed using it and then the landscaping is designed around their actual usage.  Similarly in design, rather than trying to guess what the needs are, let them emerge and then refactor to support the emerging design tensions.  A lovely analogy, I thought, and one that will stay with me.

They suggest both a priori design in collaborative design workshops and design after the fact in System Architecture Documentation (SAD) workshops.  I like the acceptance that both approaches are going to be useful. The former stresses the need for team contribution to the design as the Product Backlog items are being developed, while the latter recognizes that team needs for technical documentation will emerge over time and so setting time aside to fine tune design documentation is both warranted and healthy.

The authors also address the question of whether and when to rewrite code – like Joel Spolsky, I personally favor refactoring to improve legacy code rather then re-engineering.  The authors present a compelling and complementary argument for refactoring and incremental improvement based on the value of instilling a notion of continual (rather than punctuated) improvement in the development teams.  They stress that the real problem isn’t the legacy code you’ve got but rather the legacy code you continue to write.  Encouraging the team to have a mindset of each check-in leaving the code base better than it was before – fixing the broken windows and taking out the trash – is a better solution to the problem of poor code quality than is carving off large sections of time for exclusively improvement-oriented work.

Acceptance Test Driven Development

The book’s worth it just for this material alone.  Larman and Vodde present a wonderful analysis of ATDD and characterize its place in the context of Scrum, including tying it into iterative requirements refinement, the Definition of Done and the Sprint Review.  I’d seen teams go in this direction driven largely by the desire to better engage testers in their teams throughout the Sprint and avoid “scrummerfall.” The authors take this further to show how ATDD, in which acceptance tests are defined and automated in advance of the development of the code that will pass those tests, does for teams in an iteration what Test Driven Development (TDD) does for individual developers in ten minutes.

They stress the need for the test automation to be a distributed responsibility shared by the whole team rather than one assigned to a specialist team.  I couldn’t agree more.  I’ve seen many attempts to establish test automation through the creation of a group apart from development and I can’t say that I’d call any of them particularly successful – at least not in the broad and encompassing sense that Larman and Vodde are envisioning in this book.

Continuous Integration at Scale

I was particularly glad to see treatment of Continuous Integration (CI) at scale. I’ve seen groups start with vanilla CI as it is described in the Extreme Programming literature and do well with it initially but then fail as their groups grew larger.

Essentially, Larman and Vodde propose a nested set of continuous integration builds, each larger one subsuming sets of smaller ones within it and each build defined for a particular concern.  Examples of these concerns include the verification of specific components and subsystems but also particular kinds of testing – including things like performance and stability testing.  One key aspect of this approach is that, at each level, you’re trading off the immediacy of feedback to the developer against the likelihood of the developer’s submission affecting quality at that level and the expense of the tests.

The Elusive Definition of Done

As noted earlier, Larman and Vodde,  suggest defining “done” as that subset of the work needed to release the product the team is currently capable of performing each and every Sprint – then use your retrospectives to challenge the team to bring more and more of the “undone” work into each Sprint.  The authors point out that there are really only two ways to extend the Definition of Done:  increase the cross-functionality of the team or increase the degree of automation the team uses.

In the meantime, however, while the Definition of Done leaves some work undone, Larman and Vodde suggest meeting that problem honestly, by doing things like defining an undone work team and pushing undone work onto the Product Backlog.  By being explicit about where the team currently stands against the goal of delivering potentially shippable product increments, this undone work can be better managed and the team’s insights can be directed to the problem of expanding that definition of done to get them closer to the goal.

For the Bookshelf of any Agile Team Member

The book isn’t without its faults.  It’s certainly long enough and some sections can be tedious (there’s a fifteen or so page section where different scenarios for story splitting are laboriously addressed – I get that this common complaint about stories needs to be put to rest but this feels like killing me with kindness :)).  The book’s organization lends itself more to use as a reference than as something you’d read cover to cover.   There are many repetitive sections that allow each chapter to stand on its own but are a bit hard to get through when you read it straight through.  But these are really just quibbles.  In all, “Practices for Scaling Lean  & Agile Development” is, just as its companion volume before it was, a tremendous book that belongs on the bookshelf of any agile coach, manager or team member.

I’d like to thank Anne Greenhaw and Selaine Henriksen for their help in developing this post.  Thanks also to Ryan Martens for inviting me to post here.

About the Author: Ed Willis has been a ScrumMaster, Product Owner, Scrum coach and trainer.  He is currently a developer in the telecommunications industry.

Last week I had the pleasure of sitting down to breakfast with David Douglas, co-author of Citizen Engineer, and Bernard Amadei, founder of Engineers without Boarders.  It was great to get them both to meet and discuss the need for global, citizen engineers in this increasingly complex and interconnected world.  If you are an engineer and you have not seen or read David and Greg Papadopoulos’  handbook for socially responsible engineering, then you are missing a great picture of the future of engineering driven by purpose and the question “why?”.

To put it simply as possible, Citizen Engineers are the connection point between science and society – between pure knowledge and how it is used.  Citizen Engineers are techno-responsible, environmentally responsible, economically responsible, socially responsible participants in the engineering community.

- Citizen Engineer

I happened to catch Bernard on the way to speak to the National Academy of Engineering on “Engineering Sustainability in the Face of Natural Hazards.”  This brought us to the oil spill in the Gulf Coast.  If you buy the tenents of the Citizen Engineer, then an engineer would be the spokesperson for BP in a situation like this.  In that role, the Citizen Engineer would talk about the situation and help educate the public on the implications of technology of deep water drilling.  At breakfast, this conversation gained a bunch of energy and stimulated me to explore this idea more completely.

Based on my experience and ideas contained in the Citizen Engineer, I believe we need to create more Citizen Engineers. If this happens, we can jump quickly past the island of blame and towards faster learning and more constructive solutions. By moving to a more visible, open and collaborative discourse, we can work together to address these global and complex difficulties.  So, my new favorite phrase is, “What would the Citizen Engineer do?”

In a world of increasing complexity, accidents happen.  This accident is a tragedy with 11 dead and 17 injured in an explosion that created the worst oil spill in the history of the United States.  Let’s start the clock over on these events and explore what a Citizen Engineer would do.

Managing the Gulf Coast Oil Spill, the Citizen Engineer way

It is April 20, just after the blow out. The Citizen Engineer, holding the title Chief Engineer at the company, was notified immediately by email, text and phone.  Right away, she started a number of things in parallel. First, her office took control and governance of the situation and began acting as the general contractor for the accident. There were four fronts to work on:

NASA photo taken May 24 - from web site http://2010gulfoilspill.com/

• Root cause of explosion and rig stability
• Continuing leaks
• Spill clean-up at sea
• Spill clean-up on land

This Chief Engineer’s office placed lead engineers on all these fronts, but to illustrate the point of our story, we will focus only on efforts to stop the continuing leaks.

In the first 24 hours, her team classified the accident as a complex situation, beyond the solution scope of past accidents. It was classified as complex due to the depth of water, pressure, size and number of leaks and the state of the well including the stuck drilling rods.  It was clear that relief wells would be the correct long-term fix, but they were months away.  As a result, her team quickly realized that this complex situation required them to learn as fast as possible from as wide group of people and as many experiments as possible. Simply reaching to internal or known experts of past solutions in shallower, more straight-forward situations would be fine in a complicated situation, but the pre-conceived solutions could actually hurt in this situation. After meeting her response team on-site, she launched the following parallel efforts:

1. Opened communications to the world via Internet to communicate video and known conditions of the accident including live underwater video feeds, movies of experiments and well configurations.
2. Called for counter-measures ideas and technologies from the petroleum engineering community with special requests to Norway and Brazil, the two leading countries with deep water well expertise.
3. Set a daily cadence for coordinating status and learning inside her team.
4. Pulled well experts from their partners, Halliburton and Transocean to staff her disaster response team.
5. Procured the submarines and well capping equipment for these depths.
6. Developed a model of the underwater site to make communication about the situation more clear.
7. Authorized the drilling of relief wells for long-term containment.

By opening communication of the situation to the world and inviting engineering help via the Internet, her team encouraged a crowdsourcing and expert sourcing approach to the problem.  As a result, they quickly received estimates on the amount of oil leaking from scientists who were familiar with measuring flows simply based on the video feeds.  Having understood the large magnitude of this flow, the response team was able to garner more dollars to expedite experiments based on simple, back-of-the-napkin estimates of costs due to fines and clean-up that would accumulate each day the well leaked.

Simultaneously, the web site was collecting potential countermeasures from petroleum as well as civil and aeronautical engineers from around the world.  These countermeasures were filtered by the web team and small groups of response team engineers were doing quick research, experiments and models to boil up the most feasible and effective ones. A web-based social media voting and comment system was allowing outside engineers to validate their thinking.  As the most effective countermeasures emerged, the team started to describe experiments necessary to learn how to evaluate the valid sets of potential solutions. Using their growing resources, the response team launched multiple experiments using models and simulations to accelerate their Orient-Observe-Decide-Act loops. Based on what they understood, they took a set-based approach to running these experimental solutions under the sea.

At the end of the first 24-hour cycle, they were clear on the first three underwater efforts.  These efforts were quick, easy and non-destructive to other efforts. Within the next three days, their first experiments did not attempt to slow the leak, but they learn much more about the actual situation of the undersea drill rig, the actual leak size and mix of gas and oil. This data allowed them to update their models and again narrow their choices, as well as feed the root cause and leak containment teams some valuable facts. They were learning and now major equipment was starting to arrive at the site.  They chose to work on the quickest solutions that had the highest estimated effectiveness and least likelihood to ruin the well site for further efforts. All of these models, experiments, and solutions sets were published on the web site in real-time.  The web site formed the basis for governmental and public communication updates as well kept the worldwide crowd of paid and volunteer engineers in the loop.

This learning-first approach led to some quick wins that started to slow the leaks only 10 days after the accident and fully contained it 14 days later.  There was now an estimated 200,000 barrels in the water.  Her attentions turned to other teams. One had the long-term, relief well underway with an estimate of 2 more months to completely contain the band-aided well from other leaks. The results of the response teams efforts kept the total spill size to less than the 250,000 barrels spilled by the Valdez in 1989 and less than the 7 million barrels spilled during Katrina. The Chief Engineer’s teams had used all the best thinking and resources from around the world to narrow to a short-term fixes very quickly.

To conceptually “pay back” the world of volunteers and future deep sea oil teams, the problem sheets, experiment results and retrospective meeting notes are all freely available on the corporate web site.  This site and content are open and shared with the world in an open source manner.  These notes provide data for future Chief Engineering teams to reference during future accidents.  They also provide an engineering case study and market data for equipment suppliers to the petroleum industry to help make these kind of efforts safer in the future. They know that by working fast and leveraging all the world’s resources, they directly attacked the highest economical, ecological and social risk quickly.

Are you a Citizen Engineer?

Things are changing, as we are rightfully blurring the lines between economic, social and environmental responsibility.  Everyone is having to become more responsible to the triple bottom line.  In this new world, the Citizen Engineer needs to be responsible to technology, ecology, society and economics.  In many cases, the Citizen Engineer must acknowledge the difference between problems and difficulties. Problems have answers, but for the difficulties we can do nothing but try to address it in our increasingly large-scale, interconnected and complex world.

Who knows if this approach would lead to a smaller spill in the future, but it would certainly lead to faster learning in the next set of accidents.

How does your engineering team behave during your organization’s accidents?

Ryan Martens is a civil engineer, founding board member of the Entrepreneurs Foundation of Colorado, and CTO at Rally Software Development.

Managing the right goals in software development can have a major impact on your team’s success. You get what you measure. In this regard, the goals you choose can be a defining factor in whether your organization’s Agile adoption thrives or dives. So, what are your choices?

A story about goal-setting

Imagine you are a runner. You have a running coach defining targets for you. Your coach chooses miles and seconds in order to measure you. These metrics turn out to be useful; they are universally understood by you, your coach and your competitors. That’s a good thing. A target goal exchange around these metrics might look like the following:

Coach: “I need you to run a 2-minute mile.”

You: “Uh, I’m not sure I can do that. In fact I don’t think it has ever been done before by any land animal other than a wildebeest, a pronghorn antelope or a cheetah. And, I’m not a wildebeest.”

Coach: “You’re not listening. I already told Sports Illustrated you will. Don’t make me look bad.”

You: “Seriously I’m pretty sure that’s just not humanly possible. I’m no Usain Bolt and I’m not sure even he could sustain a 2-minute mile.”

Coach: “Hey, I set the goals. Run that mile in 2 minutes. Just hunker down and work harder. 2-minutes is the target goal. If you don’t meet it, I’m kicking you off the team.”

You: (muttering under your breath to self, “I can’t do it, you aren’t listening to me, and you are a moron. Why do I even bother to open my mouth?”)

Why goals matter

Get the idea? I’ve been reading John Seddon’s Freedom from Command and Control: Rethinking Management for Lean Service. My colleague Alan Atlas recommended the book. Then my manager Ryan Martens became very interested which led to a book appearing on my desk. Soon after, Karl Scotland mentioned it in an informal conversation about Lean and Kanban. Time to pop it to the top of my reading stack!

Seddon sets a context about Purpose driving Measures that then drive Methods. The combination of purpose and measures start to look like goals. And Seddon breaks goals into two types: Target Goals and Capability Goals. While John’s book is not specifically about software, I could see how we use and abuse goals in our software world. So I decided to delve deeper.

Target goals are arbitrary and doom-laden

Target goals are set to measure hopeful results, often an arbitrary number. Think about our runner story and the 2-minute mile. That target goal was  set by someone else. A target goal typically does not account for your strengths, capabilities , availability and skills. Target goals don’t serve you. They don’t serve organizations either. And yet we cling to them. Consider if, as a developer, I hear the following from my manager:

“Jean! You missed the release deadline we gave you. We told marketing and sales who then told our customers that dev would deliver this specific functionality on this specific date. You’re ruining everything. We’re doomed I tell you, doomed! And all because YOU didn’t hit YOUR deadline.”

Uh, it wasn’t my deadline. And yet, missing that goal is now rippling negatively through the organization. This is a lose-lose situation all due to expectations hinged to an arbitrary target goal.

So why do target goals exist?

In many hierarchical, command-and-control software organizations, target goals are how deadlines are set. As Seddon points out, use of ineffective target goals usually arises due to an impossible purpose coupled with non-value add methods. The measures (or goals) are meant to drive teams to the impossible purpose. A command-and-control organization believes that goals must be set top down. The negative impact of these goals is inextricably woven into unrealistic expectations, death marches, and non-value add methods for controlling the work toward the goals.

Enter the capability goal

Let’s replay the runner scenario again.

Coach: “There is a race coming up, a half marathon. That means we need to start training now. What is your time currently?”

You: “I haven’t been really running lately. Rather than guess my times, I’ll start running now. Do you want to know in terms of how long it takes me to run a mile, or how far I can run in a specific timebox?”

Coach: “Let’s start with how you finish a mile. What is your typical way of getting going?”

You: “First, I do a walk/run combination. Then I can give you my actual mile capability in a week.”

Coach: “Okay, let’s set up a plan and together set some sort of goals based on your capabilities. That will help me guide you and figure out when we are faltering. I know you can do this. I’m going to work with you starting right now.”

You: (muttering under your breath, “This is amazing; yea me! I am going to finally put my passion for running to work, keep improving, and run my first half marathon. I love my coach!)

Capability goals are based on real data

Together, the runner and the coach watch the capabilities of the runner to define goals. The purpose of the goal is clear. Measures are set up that usefully help determine the runner’s progress. The method (or running regimen) for attaining the goal is then applied. Simple.

We use this same approach in Agile teams. A team lead or project manager does not set an arbitrary target goal. Rather, the Product Owner sets an overall purpose/vision. The Agile lead, often referred to as the ScrumMaster, works with the team to assess what goals can be reached based on a team’s capabilities and availability. From iteration to iteration, the team provides feedback on what it is able to complete based on its capabilities. The Product Owner absorbs this information and sets expectations outside the team. The process of continuous improvement continues. The team declares, “Based on what we tend to complete, and given the purpose from the Product Owner, we are going to improve our methods in the following ways.”

When good capability goals go bad

There’s a Gary Larsen “Far Side” cartoon of an open refrigerator with a bowl of glop inside holding a gun. The caption? “When good potato salad goes bad”.

Unfortunately, I’ve seen good capability goals go bad in a number of organizations. Listen to this conversation:

Program Director: “I see that our Agile teams are all now using these things called story points to track their work.”

Me: “Yes, it’s working well. Each team has a good sense of what it is capable of delivering iteration over iteration. That helps me figure out how to help remove impediments, where bottlenecks are, and where any team may need us to better resource them. It’s great!”

Program Director: “Hmmmm.”

Me: (muttering under my breath: “That ‘Hmmmm’ just doesn’t sound good. I think I’m about to get sick.”)

Program Director: “So, what’s the highest story point commitment a team has made?”

Me: “27.”

Program Director: “Great!  I’m setting 27 points as the target goal for all teams to commit to for each iteration. Every point will represent 3 hours of work. This precision will help me calculate exactly what we’ll deliver when. Plus, I’ll know which teams are really working and which ones are slackers.”

Me: “Hmmmm.”

Program Manager: “So, let’s get out there and commit! This Agile stuff is great!”

Me: (muttering under my breath, “We’re doomed, I tell you doomed!”)

What just happened must not be allowed

As you roll out your organizational Agile adoption, you’ll encounter many challenges. Pay attention to the usefulness of capability goals. Insist on using them.  Non-Agile organizations won’t like this. At times, you may feel like Sisyphus pushing a rock up hill for all eternity. Be strong. Don’t allow Agile measurement abuse. Create team and organizational trust.  Remove target goals and embrace the incredible value of capability goals. And, don’t allow any backslide. Don’t let your capability goals devolve slowly into target goals in sheep’s clothing.

You: (muttering under your breath, “You know? This MAY just work. Capability goals versus target goals. For the sake of my team, our organization, and the value we deliver to our customers, I’m going to do it!”)

It’s clear, there is not a one-size-fits-all way to define Agile success. Every organization is different, every Agile team is different, and every software development project is different. Each organization has to figure out how to pilot, extend and excel at Agile. Distinct Agile teams within the organization also have to determine how to move to performance in their own ways and make the most effective use of team members to meet their commitments. Full participation from everyone involved is critical to move the organization, process and infrastructure to a better place. The successful approach to adopting Agile acknowledges Agile is not just fad or a quick fix, it is part of an ongoing dialogue of what’s working, what’s not and what are we going to change.

Bringing the Agile community together is a great way for both new and mature Agile teams to share best practices, pain points and success stories. Rally hosts regional events, called Agile Success Tours, to bring the Agile community together for just this purpose. At a recent event in Dallas, we asked participants how they defined Agile success and posed the same question to Twitter. We caught some great answers on video and got some nice, succinct tweets defining Agile success:

These answers illuminate that Agile is a different way of thinking and working for organizations. It’s a smarter, more skeptical and fun craft that addresses the systemic issues found in our increasingly complex and interconnected world. Through Rally’s work over the years helping organizations both large and small adopt Agile, we’ve come to figure out some fundamental components of what success looks like. Agile success comes down to creating the yearning to continue to ratchet up your agility and discipline as a team.

There truly is a simplicity behind Agile adoption when you create the shared commitment and vision that drives your organization – then you begin to see the beauty and the possibilities attainable in an Agile business.

Ryan Martens is a skier,  founding board member of the Entrepreneurs Foundation of Colorado, and CTO at Rally Software.

Brad Murphy, CEO of Gear Stream, gave a keynote presentation at last week’s Agile Success Tour. Brad’s vision includes helping organizations transition from project-driven governance to Lean, continuous flow, product line execution. We sat down with Brad to ask him 5 questions about Agile.

1. What’s the most valuable thing you’ve learned by helping organizations adopt Agile practices?

The dynamics surrounding the adoption of Agile practices are changing in ways that are very different from even two or three years ago. In parallel with implementing Agile practices and establishing effective Agile teams, we’re helping organizations connect Agile philosophies and values to vital stakeholder groups. We’ve recognized that actively involving all stakeholders early in the process is key to ensuring that core Agile teams are able to achieve expected results. Gaining the support of all collaborators in the organization dramatically helps core Agile teams successfully transform and deliver outcomes. Involving the following stakeholders is vital, including:

• The core Agile team
• Tooling, Infrastructure and Release Management – the architecture side of the equation.
• Governance and PMO groups – more than half the time, this group builds the roles of the project managers, Agile teams and the Scrum Master. They consider how Agile teams work off backlogs. There’s huge potential for misalignment here.
• Product Management – since this is frequently a group that doesn’t exist, the responsibilities here aren’t well defined. Loosely, I’ll describe this as a group of individuals responsible for defining business value. This group has to be aligned with the way Agile works.
• Executive Management – all of the focus on Agile change with the groups listed above must be explicitly aligned with the strategy and values articulated by senior executives. Too often, Agile is pursued based on “generic” benefits like speed, responsiveness, quality… while these are “good,” they’re not explicit enough.  We must challenge executives to express exactly how they will measure/recognize their own corporate goals and then map these back to the things we choose to emphasize in an Agile transformation.

2. What do you see as the #1 reason for adopting Agile?

Responsiveness would be #1. Having the ability to course-correct and change directions quickly in light of new mandates and directions. A close #2 is innovation.  A distant #3 is productivity.

3. What are the biggest benefits of adopting Agile?

Gear Stream’s clients are realizing compelling organizational realignment by refocusing the entire value chain on external customers, as opposed to the often dysfunctional inward focus of many organizations.  By aligning the entire value chain on external customers, our clients are able to more predictably influence customer satisfaction and marketshare objectives.

4. What one piece of advice would you give to new Agile teams?

I’ll give the advice I’m most passionate about. Agile teams need to challenge the rest of the organization to rethink and reconsider how work happens up and down-stream to them in order to fully exploit what they’re capable of achieving. It’s really about how Agile teams can actively promote, influence and change an organization beyond just what they do as a team. They really can – and do – influence and engage the rest of the organization. The failure pattern of Agile is almost always the same: we’ve built an Agile team, but failed to build the adjacent stakeholder teams in the process – then, the Agile team gets frustrated and the organization loses momentum and enthusiasm for Agile. Agile teams must have the ability to influence stakeholder teams, and ultimately, the baseline infrastructure of the entire organization.

5. How do you define Agile success? (Can you do it in 113 characters?)

Building, delivering & sustaining outcomes that customers r continually thrilled by, driving profit & value 4 all

I would like to welcome Ed Willis to our blog, as a guest blogger.  I spent a couple of days with Ed and his team of internal coaches this Winter and I am glad to have him share some of their lessons from the field of large distributed Agile – Ryan

Question: What are we, as Scrum team members, committing to in a sprint?

The higher-level Sprint Goal or the more detailed set of selected Product Backlog? If you are a customer of the team, what is the team telling you it will do?

I recall being pretty confused about what the team was committing to in Sprint planning after reading Agile Software Development with Scrum, by Ken Schwaber and Mike Beedle, for the first time. There seemed to be some ambiguity around whether the Scrum Team commits to the set of selected Product Backlog items or to the Sprint Goal, which is a higher level and less precise concept. A couple of quotes from that book will help illuminate the situation:

“A team commits to achieving a Sprint Goal.”

“The Scrum Team commits to turn a selected set of Product Backlog into a working product.”

And this from Schwaber’s The Enterprise and Scrum: “… the team selects as much Product Backlog as it believes that it can transform into a completed increment of potentially shippable product functionality by the end of the Sprint. The team commits to the Product Owner to do its best to complete that amount of functionality.”

From the first book again, “The Sprint Goal is an objective that will be met through the implementation of the Product Backlog … The reason for having a Sprint Goal is to give the team some wiggle room regarding the functionality … If the work turns out to be harder than the team had expected, then the team might only partially implement the functionality. “

Note that that last quote appears nearly verbatim in a recent (Feb 2010) version of the Scrum Guide published on scrum.org.

Between the current Scrum Guide and 2001’s “Agile Software Development with Scrum”, Schwaber’s Agile Project Management with Scrum presents an overview of Scrum in its first chapter which does not discuss the Sprint Goal at all – similarly, “The Enterprise and Scrum” provides a summary of Scrum in an appendix that does not talk about the Sprint Goal.

So what are we, as Scrum team members, committing to: the higher-level Sprint Goal or to the more specific set of selected Product Backlog? And why am I so focused on Sprint-level commitments? I focus on commitments because my stakeholders and customers value them. Their plans are in part based on my team’s delivery and so being able to make and meet short-term commitments makes us a better partner to them – “don’t trouble your customer”.

Can You Commit to an Incomplete Sprint?

“Agile Software Development with Scrum” states, “Sometimes only a partial Sprint Backlog can be created … define the initial investigation, design, and architecture work in as much detail as possible, and leave reminders for work that will probably have to be done once the investigation or design has been completed.”

Both that quote and the earlier one on the purpose of the Sprint Goal suggest that the Scrum canon allows for both incomplete Sprint planning and a mechanism to de-scope the Sprint if the team falls behind. If you find yourself in a situation similar to mine (and I suspect many, many of us find ourselves in this situation) where your customers and stakeholders really do value the ability to make and meet high-level commitments in terms of working software that will be delivered at Sprint’s end, then I think that finding a way to do this more regularly is a path you can and should pursue. And it’s one my colleagues and I have embarked on wholeheartedly. All you really need to do to become a better partner in this regard is advance your Sprint planning practices and adapt the strategies you use when you discover you’ve fallen behind.

Reliably Committing to the Selected Product Backlog – One Group’s Perspective

Being able to reliably deliver against Product Backlog commitments isn’t hard conceptually – it starts with doing a better job in Sprint planning. There are probably many ways to do this but I thought I’d share what we’ve done to accomplish this.

Capacity Planning

Our Sprint planning starts with a detailed view into capacity. Is anyone on the team going to be away on training or vacation during the Sprint? Will the remainder of their time be focused on the Sprint? If not, how much do time they think they’ll have to spend in the Sprint? Knowing the total capacity of the team in the coming Sprint is the foundation of a solid Sprint plan.

Ideal Time Estimation

To estimate our Sprint Backlog tasks, we use “ideal time” as it is described in Planning Extreme Programming by Beck and Fowler: “Ideal time is time without interruption where you can concentrate on your work and feel fully productive.” Ideal time on any given task is in essence the answer to the question “how long would this task take you in a perfect world?” Ideal time is then converted into real time in a very similar manner to how story points are converted into expected duration for stories – you measure the velocity of the team. For example, if ideal time velocity of a team is measured at 0.66, then two ideal days of work has been seen in the past to be about three calendar days.

That use of past experience is critical because it rolls up estimation error, overhead, interruptions et al into a single factor used to improve the accuracy of the task estimates while only requiring of the people doing the estimates that they do so consistently. We’ve found it useful. Conceptually I also like it because, along with the use of story points and their corresponding velocity, it increases Scrum’s fractal, self-similar nature.

Assigning Tasks

Typically we assign all the tasks in the Sprint Backlog during the planning meeting. There’s probably enough divergence of thought on this point to warrant its own post, but to stick to the matter at hand, we do this for reasons relevant to the goal of producing more reliable Sprint plans. One major motivation is the fact that estimates provided by the person who will actually do the work are demonstrably more accurate. The second major motivation is our observation that, when trying to achieve greater work sharing and improve the flow of value to the customer by avoiding bottlenecking through specialists, we do a better job of supporting people who are branching out into unfamiliar territory if we know they’re going to do so a priori. Specifically, we can build time into our Sprints for the people who are more knowledgeable in a given area to mentor or review the work of those who are working in areas less familiar to them.

Spikes

We make frequent use of spikes to allow us to develop a better or more complete understanding of what a given story will entail thus giving us the insight needed to build more complete Sprint plans.

Reviewing the Sprint Plan

We review our Sprint plans to look for mistakes we commonly make. We’ve gone as far as enumerating the mistakes we make most often to help us look specifically for those as we do Sprint planning. Most of these are different flavors of not applying our “definition of done” and thus ending up with incomplete plans. If your goal is to develop challenging plans but plans that you’re likely to deliver on, then trying hard to ensure your plans are complete is important.

Note that none of the above should be intended to suggest that we value immutable Sprint Backlogs or task assignments. We can and do frequently grow and shrink the Sprint Backlog as the team uncovers more information about what’s needed to deliver the committed Product Backlog. Similarly, we shuffle (and re-estimate) tasks regularly. What we don’t do is allow significant parts of the work to go unplanned or unassigned at the point we decide what we’re committing to deliver.

Beyond Yes or No

Beyond improved Sprint planning, the second critical aspect for us in delivering committed Product Backlog in a Sprint is how we deal with falling behind. I frequently say in delivering Scrum training that if someone comes to you asking if a bunch of features can get done given fixed resourcing by a given date, that the best of all possible answers is “yes”. The worst of all possible answers is “no” – but not because you’re delivering bad news but rather because saying “no” reinforces the fallacy that that decision is really binary in nature and ignores the great value to be gained by digging into the details to see what’s actually possible.

Similarly when Scrum teams fall behind, they frequently see their choices as being to either: stick with the plan or remove lower priority Product Backlog in consultation with the Product Owner. Those are reasonable choices but I much prefer a third option: work very closely with the Product Owner to find an easier way to deliver the committed Product Backlog items in the time remaining – essentially, use the combined talents and insights of the Product Owner and the team to find simpler, cheaper ways to get the selected Product Backlog done. Honestly, it can feel like magic when it happens.

We once had a Sprint on a tool development project that had fallen far behind – it appeared that no amount of plan scrubbing or task shuffling would allow us to deliver the committed Product Backlog by Sprint’s end. We met with the Product Owner with the intention of choosing Product Backlog to remove from the Sprint. In the course of conversation though, the Product Owner got a better feel for the approach the team was taking in developing one specific item – the item that was driving most of the over-run. Collectively, they realized that the approach was fancier than was really required and in short order sketched out an alternative. We immediately revised our Sprint Backlog to remove the old approach and built a plan for the new one – in about an hour, we went from hopelessly behind with no chance of delivering the complete set of Product Backlog to being close to on schedule. I think having a strong team desire to deliver the whole of the selected Product Backlog was key to making this happen.

Anecdotally, I can say that my colleagues and I worked hard to improve our Sprint planning and replanning practices and pretty quickly found ourselves doing much better in meeting our Product Backlog commitments. For example, during one ten month stretch, I counted 93% of Product Backlog items delivered on time in the Sprints in which they were planned. This isn’t the only thing that matters but it made a big difference to us and our stakeholders: it gave us confidence in the team.

Conclusions

• Use the Sprint Goal to capture over-arching but incremental project goals if this concept is meaningful to you and if goals like these are more meaningful commitments than would be the selected Product Backlog – but definitely don’t use the Sprint Goal as a crutch to support poor Sprint planning practices.
• Don’t let the Scrum canon hinder your team’s thinking when tuning your process to better satisfy your business needs – the canon wasn’t created to limit your thinking.
• And above all, don’t believe that your team won’t be able to reliably commit to the selected Product Backlog Sprint over Sprint – you almost certainly can and, if your team and your stakeholders value this, then by all means pursue improvements in this area.

I’d like to thank Anne Greenhaw, Selaine Henriksen and Ryan Martens for their help in developing this post.  Thanks to Ryan also for inviting me to post here.

About the Author: This is the first guest blog post of Ed Willis. Ed was a soldier, a cab driver, a security guard, a tree planter, an auto glass installer and shop manager, an employee of several bookstores, a house painter, a dish-washer, and a foot messenger, among at least a few other things before buying his first computer. Since then he has worked as a research assistant at Queen’s University, driven a data mining company into the ground and ridden Nortel Networks nearly all the way down. He currently works for company in telecommunications. Born in NY, NY, he now lives in Ottawa, Ontario.

Yesterday, the Agile Journal posted their May edition of the online publication with the above focus.  To support their release, they asked us to share our opinion on the topic.  Here is our response:

Ryan Martens: Age of Reconsideration, Reform and Regeneration

The last decade marshaled in a new empirical way of working with increasingly complex, interconnected and highly-critical software-based systems – Agile.  We are entering a period of reconsideration, reform, and regeneration in software, systems engineering and project management.  Agile is working, Lean Software and System is working, and the combination is starting to prove very powerful with regard to throughput and workers.  The benefits of autonomous work, engagement and mastery are driving systemic improvements in our way of working and growing to meet complex challenges of our world.

These results illuminate a future vision that has the potential to expand our current notions of Lean and Agile from software teams and into real organizational agility.  As a result, there is a chance to unite and unify many communities under the guiding ideas of flow, pull, and value.  All of these communities are being drawn in and starting to play well.  These are beautiful days with all the implications to CMM/SEI, Agile, Scrum, Lean/LEI, and PMI/PMBok communities yet to be determined.

In the first half of this decade, look for collaborating across boundaries, seeing larger systems and groups working hard to create their future realities.  Following that period, look for messy consolidation as the winners of this new platform emerge for a new golden age of networked, software product and system development. Together we’ll be focused on the problem domain of global scale difficulties in governance, cyber-warfare, energy, water, communication, commerce, medicine, climate, transportation and nano-technology.

Ryan Martens is an amateur triathlete,  founding board member of the Entrepreneurs Foundation of Colorado, and CTO at Rally Software Development.

Jean Tabaka: Let the System Talk

Thinking about our path with Lean, I’m compelled to draw upon research I’ve been doing in Systems Thinking and, more recently, what I’ve been learning in Systems Engineering.

In Systems Thinking, we recognize a world of system archetypes based on the dance of balancing loops, reinforcing loops and the outside agents that may cause them to transition. Lean, as a system of thinking, has certainly responded to systems that rely too much on take-make-waste. A set of negative reinforcing loops: the more you waste the less you have to take and make. Outside agents, the scarcity versus abundance of materials, has led us to Lean. Lean principles and practices create a positive system wherein the more we reduce waste the more value we get which in turn reinforces more waste reduction. It is a reinforcing loop propelled by continuous improvement.

Recently, I attended the Lean Software and Systems Consortium’s 2010 conference in Atlanta. What a revelation. From James Sutton’s talk on Lean Systems Engineering, I added new vocabulary that I think will become critical to Lean’s future.

Will Lean be our best source of practices and principles in the future? That depends on what will be guiding our systems:

• Scarcity
• Abundance
• Desperation
• Conformity

Once we have clarity about what guides our system, we can understand more about the system in which we are operating:

• Simple
• Complicated
• Complex
• Chaotic

Lean has steadfastly addressed pressures of scarcity and hence a system of complexity. That brings me to Dave Snowden’s work captured in Cynefin, a Welsh word he has used to describe a framework of problems, situations and behaviors in these four systems. For our world of complex systems, Lean provides the perfect high-level thinking for what we must embrace: emergent practices informed by, as Snowden puts it, “sense-making”

As we move into the next 10 years of Lean, I fervently believe that our sense-making must inform us about what supports emergence that responds to complexity. The practices will follow. For now, let us concentrate on the systems in which we operate, what outside agents or pressures are guiding our systems, and how we can best continue to formulate and hold dear the practices that will naturally emerge.

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

Scott Killen is an Agile Practice Leader at PayPal and the President of Agile Austin. He has extensive experience managing all aspects of the software development process, from a twinkle-in-the-eye to final release. In advance of his participation as a panelist at our upcoming Dallas Agile Success Tour, we sat down with Scott to chat about Agile.

1. How have you implemented Agile across your organization?

We have a three-year vision for PayPal to implement Agile development across our enterprise. In year one, we are focusing on basic practices. The idea is to lay a solid foundation for building mature teams. In year two, we’ll focus on making teams successful. That is, using the practices in a reinforcing way to build teams that predictably deliver acceptable products. In year three, we want to focus on optimization. That is, aggressively practicing incremental and continuous improvement of our Agile practices.

To baseline practices and measure improvement in year one, we have a metric that we call “Team Maturity.” This is a weighted score that reflects the number of fundamental practices a team employs and their longevity in terms of iterations completed.

We are in the process of defining the metrics we wish to use to define a successful team. It is important to us that these metrics be methodology neutral. Although not formalized, I expect that some measure of time-to-market and released-defect counts will be used.

2. What was your #1 reason for adopting Agile development?

We want more flexibility in our development process.  We seek flexibility to make late-cycle changes to develop the best product and to decrease time-to-market for those products.

3. What has been the biggest benefit of adopting Agile?

We’re looking forward to receiving the big payoffs. But, surveys generally indicate that we are more effective when we develop in Agile projects, our quality is higher, and our developers are happier.  Cross-functional communication is cited as the big win in these surveys.

4. What one piece of advice would you give to new Agile teams?

Be sure to properly set management expectations. You will not get productivity or quality gains at first, and, in fact, your productivity will decline for about six iterations until everyone begins to learn how to work collaboratively within the Agile framework. Agile development does not come without pain. I’m reminded of the expression “Pain is weakness leaving the body.”  That’s Agile – painful, but the results are worth it.

5. How do you define Agile success? Can you do it in 113 characters?

Happier customers measured by Net Promoter scores. Happier developers measured by lower turnover.

Follow this thread on Twitter - We asked Scott to define Agile success in 113 characters or less as part of a challenge we’re hosting on Twitter. What is your definition of Agile success in 113 characters or less? Tweet your answer to @RallySoftware using #AgileSuccess. The top five tweets received by May 17th will be featured in a follow-up blog post.

Yesterday Forrester Research, Inc. issued the most comprehensive, independent analysis of the Agile development tools market and 10 Agile ALM providers.

The Forrester Wave: Agile Development Management Tools, Q2 2010

Here are some highlights but what I really recommend is that you read the report titled “The Forrester Wave™: Agile Development Management Tools, Q2, 2010, Forrester Research, Inc., May, 2010″ 

• The report says, “Rally offers the best combination of capability and strategy.”
• It goes on to say Rally “has a strong services group with lots of experience around enterprise Agile adoption, benchmarking and assessment.”
• Thanks to Forrester’s deep analysis, there is a lot of other great information on Agile adoption (currently at 35%) and where this market is headed.

See the full report for details.

For me, this is a culmination of 6 years of hard work building a great product, roughly 32 product releases (that’s just on our core ALM product),  countless demos to our now 96,000 users to get the features right, and the company evolving from just me to 165 phenomenal team members at Rally. Wow, I am a proud Rally-er today.

Ryan Martens is a skier,  founding board member of the Entrepreneurs Foundation of Colorado, and CTO at Rally Software.

Last week, 10 of us from Rally product development, sales and coaching attended the Lean Software and Systems Consortium’s 2010 conference in Atlanta.  For me, the learning highlights of the conference were in the Systems Engineering track  led by James Sutton. To kick-off his talk on Lean Systems Engineering, James used a number of compelling stories around different systems and what guide them.  As part of his introduction to systems, he played this hilarious Dave Snowden video about how you plan or act based on one of 3 systems in which you might find yourself -- Chaotic, Ordered and Complex.

www.youtube.com/watch?v=Miwb92eZaJg

David Snowden -- Cognitive-Edge -- Ways to Plan a Party

James, a Systems Engineer, Principal with Lockheed Martin, is an invested member of the Lean SSC board as well as a technical advisory member.  He is the deepest expert that I have ever met in the field of systems engineering. And he has a wonderful gift for bringing multiple resources to bear in helping people understand and care about systems. For a Civil Engineer and Computer Science major like myself his talk and track were the definition of a prop-spinning geek nirvana.

Systems are guided by the pressures that form them

The point of view that James imparted on us was to understand that there are fundamental systems in which we operate. They are not value-based; one is not better than the other. They just help us set context and inform us about the world around us. Why should we care about this? How you approach your product and project development depends on which system  you find yourself in. And, as it turns out, the system you find yourself in is largely guided by one of four compelling pressures. That is, you will recognize the system in which you operate based on what is driving you to act.

There are four fundamental pressures that guide us: abundance, scarcity, desperation, or conformity. And each leads to a different system context. To illustrate this, James led us through the story of four different nations following the second World War.  Each nation, responding to different drivers, led to advances in different types of systems management approaches in use today.

• United States -- Abundance -- Systems Engineering

• Japan -- Scarcity -- Lean

• England -- Desperation -- Chaos Theory

• USSR -- Creativity and Conformity -- Patterns of Inventiveness
  

The Four Systems

Given this sense of what guides particular systems, James explained that we live in a world of four fundamental systems: Simple, Complicated, Complex, Chaos.

Cynefin

Once you recognize what system you are in, you discover what principles and practices will best serve you in that system. But systems tend to not be static. So, James presented what agent or pressure might cause you to move to a different system and therefore what tools and practices would guide your thinking and actions for transition.

For instance,  if you are in a Simple system and are moving into a Complicated system, Lean Manufacturing and Analytical Systems Engineering are your best tools and guides. If, however, you are in a Complex system verging on Chaos, you’ll work best relying on the perspective originated by Dave Snowden: Cynefin, the Welsh word for “the place where you hold multiple things.” Cynefin serves Complex systems well as it emphasizes emergent behaviors and, what Snowden refers to as “sense-making.”

The history and vision from this talk became almost a grand unifying theory for me. It all made great sense. If you are a  systems engineering fan, do not miss the recorded version of this talk when it becomes available.

Thanks Lean SSC

While 6 speakers and several attendees from Europe were prevented from attending the conference due to the Icelandic volcanic ash cloud, the Lean SSC rolled with the punches and pulled off an excellent event. The folks able to attend and the over 40 sessions offered created an electric buzz both in the air and on Twitter. Given the caliber of sessions, hallway discussions, and Open Space,  I am sure there will be many posts that emanate from attendees. And no doubt new ideas will be growing that were nurtured by the conference. Kudo’s to the Lean SSC board for creating a space for this excitement and emergence.

About the Authors:

Ryan Martens is an organic gardener,  founding board member of the Entrepreneurs Foundation of Colorado, and CTO at Rally Software Development. Jean Tabaka is a wine enthusiast, author and Agile Fellow at Rally Software Development.
Tag for LeanSSC automated collection of blog posts -- #lssc10

My name is Jean Tabaka.

I live in an Agile and Lean world where we take a “stop the line” mentality for granted.  I am encouraged to give my observations and recommendations about continuous improvement. I’ve been learning to create my own reality, to continue learning and to find my strengths in cross-functional work. I passionately read about, talk about, and practice Agile and Lean principles. These principles continually inform how I can create benefit for my company and how I derive benefit from my company.

I’m the lucky Tabaka.

My father, Jim Tabaka, was a life-time white collar worker for GM, starting fresh out of University of Illinois with his mechanical engineering degree.  He worked 12 hour days, on his feet the entire time, walking the plant floor, making sure cars kept coming off the line at all costs. He retired at age 55 with a great pension and unbelievable health benefits.

My brother Tim Tabaka is a retired GM blue collar autoworker. Well, retired is the euphemism for, “Would you please leave early so that we can bring in a younger, less experienced, cheaper workforce?”  During his time at GM he worked any shift he was told to work. He even moved to a different, older plant. Why? He needed the job and they wanted to replace the older workforce with a cheaper, younger workforce.

My nephew, Andrew Tabaka is a current GM autoworker. He came in under-skilled and now works a night shift for a GM subsidiary building brake assemblies. Andrew is one of the people Tim trained on his way out. Andrew is 24 and this is his first job. I suspect he intends it to be his life-time job. Well.

I’ve never worked for GM but learned to drive a stick-shift on a Chevy Corvette (yes!) And, while growing up, my dad used to take me to visit the plant where he worked in St. Louis. The acres of parking lot outside the plant were for all the cars that had rolled off the line but could not be shipped to a dealer. Too many defects.

Get the picture? We have been and are a GM family.

And I’m telling you this for a reason.

In 1984, GM and Toyota entered into the NUMMI (New United Motor Manufacturing Inc.) agreement to co-run an auto plant in Fremont CA. NUMMI made big news at the time. It took an existing, highly dysfunctional GM workforce and turned them into one of the most productive auto plants in the US. A documentary about this recently aired on Ira Glass’s “This American Life”. What a story, too fantastic to be made up: the complete turn-around of a failing GM plant to a thriving joint venture. The documentary recounts 30 disgruntled, unmotivated GM employees traveling to Japan to work with Toyota employees to learn “The Toyota Way”. It features commentary from Jeffrey Liker (author of “The Toyota Way”) John Shook (author of “ Managing to Learn”) as well GM line workers and GM management. The power punch of the Ira’s story? GM never replicated the success at the NUMMI plant.  Several theories about this failure are postulated at the end of the documentary. It is up to the listener to form their own conclusions.

Two weeks ago, as a coda to the documentary:

The Fremont NUMMI plant had its last Corolla roll off the line. NUMMI was shut down, this time for good. It was the first factory ever shut down by Toyota.

I care both personally and professionally about that darn NUMMI plant. The Ira Glass documentary about NUMMI’s turnaround and GM’s failure to replicate struck a deep chord for me. I called my brother Tim that evening to get the real scoop. I had heard him recount what his life was like in a GM plant and I wanted to hear it from him again.

The truth is the NUMMI success DID have an impact on GM outside the Fremont plant. Prior to the NUMMI conversion, life in the Oklahoma City plant where Tim worked was miserable. As in the story “Rivethead” by Ben Hamper about GM plant life in the 1970’s, alcohol abuse, absenteeism and nervous breakdowns were common place at Tim’s workplace. He lived the life documented about the Fremont plant prior to the Toyota venture.

Life with the Andon.

In the late 1980’s though, Tim told my about how things were changing, amazingly so. A “stop the line” mentality was adopted at their plant. Use of an “andon” was introduced. One tug on the andon was the alert to call over for some help; a second tug was “stop the line” we need more time to fix this. Tim was one of the people who roamed the plant floor prepared to assist when the andon was pulled once so that it wouldn’t have to be pulled again. Every station had its own andon “song”. (Apparently the “Baby Elephant” song became the bane of my brother’s existence.)

Life was so much better (the “Baby Elephant” notwithstanding). Workers were encouraged to stop the line and fix problems versus pushing cars through. Teams were brought together to offer suggestions for how to improve the work processes and the flow within the plant. Quality went way up and defects went down. Morale and motivation went up. Alcohol and drug abuse went down (this is anecdotal from my brother, not based on an actual study.) And for Tim personally, plant life improved dramatically. The new system played into his strength: being a cross-functional team member, challenged and rewarded for doing his work.

Back to the NUMMI story and what GM ultimately adopted.

Fair enough. I have my brother Tim as an example of an autoworker who benefited (well, except for the darn “Baby Elephant” team’s issues). But I also have a father who, as a GM executive was expected to tirelessly follow and communicate the GM line. It took its own deep toll on him. And I have a nephew who continues to work as a very replaceable night shift cog in a different plant in the GM machine. GM has declared bankruptcy for any number of reasons. And now, my mother’s benefits, my brother’s pension, and my nephew’s pay are in peril.

My name is Jean Tabaka, daughter of Jim Tabaka, sister of Tim Tabaka, and aunt of Andrew Tabaka. My father never benefited from Lean thinking. My brother had a wonderful brief taste of it. And my nephew is now somewhere in an odd stew of Lean and non-Lean practices.

I’m the lucky Tabaka. Lean has brought me a lot and taught me a lot in my Agile world. While Lean may be most closely affiliated with the Toyota Production System; and while it may be assumed that failure to adopt the TPS was GM’s ultimate demise, I believe the Lean lessons have continued to grow, spread, and morph as a result of both success and of failure in Lean adoptions.

GM, Toyota (yes Toyota), NUMMI, the Oklahoma City plant and others all have their stories of success and failure. Each had their approach to Lean adoption. Like Tim Tabaka and NUMMI, we have our lessons to learn from Lean in our software world. Lean is not the panacea. The TPS cannot tackle all issues. Agile is not the panacea. No one methodology can guarantee product success in all situations. Our continued belief in checking the value of our adoptions is critical. Our conviction to pay attention to failure modes as well as success is key. If you don’t believe me, ask my brother Tim.

Today we announced Rally’s acquisition of AgileZen, a visual project collaboration tool that manages work using the Lean concept of Kanban. AgileZen is a simple, elegant project collaboration tool that supports software development by providing a Web-based Kanban board.

Our definition of Kanban

If you aren’t yet familiar with Kanban, there are lots of great resources out there. The simplest description we could come up with for Kanban and Scrum is in our press release, but we welcome your thoughts and additions:

Kanban literally means “sign board,” and in Lean it is the signaling tool for visualizing and tracking work as it flows through various stages of a process. A Kanban board does this by exposing bottlenecks, queues and waste in a process so that teams can deliver high quality, high value work. Both Scrum and Kanban methods focus on early value delivery, and both provide transparency into the work in progress.  But Kanban can operate with a different planning and delivery cadence than Scrum and emphasizes different metrics.

What does this mean for Rally and the industry?

We believe that Kanban is a simple but natural extension of Agile software development. It will invite more teams into Agile and provide more runway for mature teams. But most importantly, it will help us extend Agile beyond development teams to create an Agile business. The AgileZen team has been effective in all of these areas. We are in heavy learning mode and, at least in our view, the entire industry is still figuring out how Scrum and Kanban work together and which methodology is better fit for various projects.

Welcome Nate and Niki Kohari!

Nate and Niki Kohari, co-founders of AgileZen, have built the best Web-based Kanban board out there, and we have the utmost respect for their product, company and brand. We are incredibly excited for them to join our North Carolina office.

What does this mean for AgileZen?

First, you should read Niki’s blog post. Not much has changed for AgileZen users. Together, we’ll continue to support the AgileZen solution as a low-cost Kanban-focused project collaboration tool, and users can access support as they always have.  If you aren’t familiar with the AgileZen product yet,  check out their free product.

Join us at the Lean SSC Conference in Atlanta next week!

The Rally and AgileZen teams will present our products and coaching services at the Lean Software & Systems Conference 2010 in Atlanta April 21-23. Ryan is also speaking on Plan-Do-Check-Act. We look forward to seeing you there!

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. Jean Tabaka is a wine enthusiast, author and Agile Fellow at Rally Software Development. Subscribe today to get free updates by email or RSS.