Agile Development Blog

In a continuation on my last post on Eric Ries and The Lean Startup, I wanted to share how these concepts continue to ripple through Rally. (Learn more on how to apply these topics in your business at our upcoming in-person and virtual Portfolio Management Roadshow featuring Eric alongside an awesome line-up of speakers.)

Three weeks ago while in Denmark, I had a deep dive with customers on the topic. While in Copenhagen Denmark and talking with 40 European customers at Rally’s Agile Open Forum, one of the top 5 questions that group proposed was:

“How can we develop features that give the maximum long-term value and the minimum long-term cost?”

Vist Custdev.com for this "Cheat Sheet"

I believe you will find the answer to this question in Steve Blank’s customer development approach to differentiating new products or simply in the build-measure-learn cycle of Lean Startups. For Agile teams that can already build right and build fast, this answers the question of what to build!

By focusing on the concept of creating “validated learning,” a Lean Startup team does not provide solution development teams stories that are not validated or constructed to validate a hunch.  As such, the Agile backlog becomes prioritized by learning and risk.  The result is a team that couples Agile product development cycles with customer problem discovery and customer solution validation. What is great about this approach?  It works at the whole business or product-line level, and you can also slim this down for use with A/B testing of enhancements too. Your level of application only depends upon your scope as well as the scale and maturity of your Agile efforts.  The more Agile your enterprise is the more leverage you can have with these techniques.

The result of this work allows you to determine, if there is desirability for this solution before you commit to ship it.  As a result of understanding the intersection of feasibility, effectiveness and desirability, you can be sure to deliver features that have maximum value.  And, by working with a minimal viable product (MVP) concept, you can be sure not to overbuild that solution too.  In this way you can be sure to build the features with maximum value and minimal long-term cost.

To me, Lean Startup is a method to drive continuous innovation and brutal, entrepreneurial prioritization. But taken to the extreme, Lean Startup is a way of being and acting and can become an attribute of culture. In addition to speaking and teaching on the topic, we have had some customers and partners come to learn, teach and do with us. The following efforts demonstrate how these activities can become cultural.

Act like a scientist, not a fire fighter

In a tradition of Lean companies, we had one of our largest customers come visit our office in early October.  He and his company have adopted and scaled Agile very well.  Now, they are focused on creating validated learning to do concurrent set-based development on their toughest problems. He pointed us toward this HBR Article on Decoding the DNA of the Toyota Production System.  You will notice the Lean rules and principles from Toyota support the Lean Startup approach.  This customer’s hope was to share his learning to help make us a better partner.  His trip was a true gift.  Thank you, Pat.

Two weeks prior to our customer visit, our friends George Kembel and Scott Dorsey, from Stanford’s d.school were here in Boulder. The principles and method of design thinking are clearly wrapped into the Lean Startup.  In design thinking, the iterations include practices to empathize, ideate, prototype, and test/reframe. Typically, these cycles are used to create the initial design of a new product or service, but not at the d.school. In the d.school, students take these concepts into more of a continuous cycle to help shape emerging services or social startups. Like Lean Startup, the d.school is learning to run people and teams through fast and continuous cycles of build-measure-test to create a “continuous innovation to create radically successful” efforts.

In a serendipitous way,  I taught a seminar on customer development and business model canvas approaches to fellows at the  Unreasonable Institute.  In September, Zach did a crash course on “Why Lean Startup Approaches Work” for 120 folks at the Silicon Flatiron’s portion CU Law School and Boulder/Denver New Tech Meetup.  Like my first post said, it has truly been Lean Startup everywhere at Rally.

If this post was not concrete enough for you, my final Lean Startup post is on “How to Apply Lean Startup to Your Agile Rollout.”

Ryan Martens is CTO/Founder of Rally Software, a recovering Entrepreneur-in-Residence at the Unreasonable Institute and chief promoter of the Entrepreneurs Foundation of Colorado. You can follow him on Twitter @RallyOn.

With the publishing of Eric Ries’ book, The Lean Startup, I can barely go a day without talking to someone about it. Eric clearly executed a lean startup on himself and this topic – by focusing on learning. Eric started much of his work a couple of years ago with his blog Startup Lessons Learned and by publicly speaking on the topic. I saw him first at Return Path, a local Rally customer, in May of 2010.  Since that time, he has continued to refine the principles and collected great stories for this book that speaks equally well to an new entrepreneur as a seasoned business professional.

The book is just a fantastic and hard-hitting summary of this approach to business, as well as a manual on how to teach entrepreneurial behaviors.  If Eric was a seasoned author, this would be a great book, but given the fact it is his first effort – it makes the book astonishing.  It debuted at #2 on New York Times Bestseller list!

If you do not know Eric or The Lean Startup model, it works by developing product/service in parallel with the customer in a market.  The method can be summarized by three words executed repeatedly; Build, Measure, Learn.  These cycles continue to help you assess whether to stay the course, pivot or stop.  The Lean Startup is a combination of applying Agile Development, and Customer Development methods, but draws on Lean, crowd sourcing/social and complexity to create a true collection of thinking and acting tools for today’s complex world.

Eric’s sub title really sums the book up well –

How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses

… as these ideas and thinking apply equally as well for venture-backed tech startup, impact investing, social startups or internally funded intrapreneuring efforts.  If you read his blog, you will see he A/B tested about 20 sub-titles to come to this one. So, not only is a great sub-title, but it is one that attracts the right market.

Have you clicked on the book image to buy it yet?  No?  Let me try one more thing!

For Agile teams, programs or enterprises, the message from this book should be clear: you need to start applying customer development approaches to the front-end of your Agile efforts. You can read about Rally’s latest customer development in the Making of Project Stratus; and you can see the results of these efforts at our Agile Portfolio Management launch in December.

As part of this launch effort, Zach Nies and I have been given a great gift in the last month of continuous lean startup (more on that in later posts). Last week, I found out that Zach and I will have the opportunity to interview Eric live on February 2^nd.  If you don’t buy the book, you should at least register for the 1 hour video event.

Ryan Martens is CTO/Founder of Rally Software, a recovering Entrepreneur-in-Residence at the Unreasonable Institute and chief promoter of the Entrepreneurs Foundation of Colorado. You can follow him on Twitter @RallyOn.

I love the leverage  you get when strategic planning is working well.

At Rally, I run our strategic planning process with help from Jean and others in our organization. We have experimented with many agendas, internal facilitators and guests, but we’ve found the most success when Jean facilitates these meetings and I lead them. It is challenging work and we try really hard to create a setting that leads to magic and allows the best to emerge from the group.  As you might imagine, if you know Jean and me, we never stop trying to improve the process. In addition to our desire to keep advancing, the context at Rally keeps changing. Whether from growth, hiring, market changes, maturation of agile, or changes in customer demographics; our overall setting for strategic planning keeps shifting. It is a difficulty that we wrestle with, but knowing it is ultimately unsolvable, we have learned to embrace the dance.

I do not recall what was the chicken and what was the egg, but we started working on strategic agile topics last year and it launched two efforts and blog series: N Levels of Planning, and Scaling Agile to the Strategic Level. In this post I am bringing the two series together to explore tooling the process of strategic planning in an agile context with Catherine and Ronica. Larger Rally customers and past employers have shown that managing a strategic plan in a spreadsheet creates vacuums. Through our efforts at Rally, we have learned that trying to maintain strategic alignment with our development teams without a single source of record to visualize variances on plan versus actual is challenging. (HINT: Slides are not a very capable source-of-record :)

It is difficult to integrate big-bang, waterfall planning/stage-gates and traditional budgeting with effective agile teams who keep learning and adjusting. It is even more difficult to stay on course as an agile organization without effectively closing the feedback loop on roadmap/strategic planning efforts. In the first instance, it is easy to simply be driven by a naive plan. In the latter, it is easy for the development effort to drift apart from the goals and direction.

These well-validated difficulties led to the birth of Project Stratus and the N-Levels of Planning efforts at Rally. These two initiatives are intended to help increase the effectiveness of strategic planning in an agile context.  They are helping us balance the need for forecasting delivery while also benefiting from the fast feedback that flows out of agile teams and programs. We like to talk about this process as steering realistic roadmaps to maximize the delivery of value.

To explore this problem space, we diligently carried out discovery and validation exercises that led to a working application (Project Stratus) and a service offering (Agile Strategic Planning) that we use to ensure the delivery of a Whole Solution. Through our customer interviews, we found that the most common strategic planning solution when doing agile development is a strategic planning person holding the plan of record in an Excel spreadsheet. This spreadsheet holds some form of a roadmap of releases, programs and resource allocations. It is updated on a regular cycle, typically quarterly. However, two major problems exist with the spreadsheet approach.

1. The plan is outdated as soon as the work starts because there are two sources of data; one for planning and one for tracking progress
2. Planning in a vacuum happens as correlating the empirical data into a highly customized spreadsheet leads to outdated data which tends to erode trust

As a result, this most common solution is horribly disappointing with human translations that lead to over-aggressive estimates and/or status updates progress reports. Bringing agile values into this faulty process will shorten feedback loops and bring real data effectively into the cycle.

In exploring the space, we are discovering multiple ways that organizations manage the strategic planning process. As we are still making sense of these patterns, it is early to report on our findings.  However, one approach does stand out.

The model articulated in Dean Leffingwell’s newest book, ”Agile Software Requirements: Lean Requirements, Practices for Teams, Programs and the Enterprise“ is clearly one of the patterns of agile strategic planning. You can see a snapshot of this method on his blog, but if you really want to learn it, you should get his book. It is a clear articulation of how to manage your strategic priorities as series of releases. The book breaks the problem into three agile requirements management areas: the team, the program and the portfolio. The beauty of this approach is how it trains all levels of product owners, product managers and portfolio managers to run in agile unison. Dean developed this model starting with the teams and working systematically up through the enterprise portfolio level (ie bottom to top). And, importantly, Dean worked this iteratively through a number of his consulting customers over the past decade (see the Big Picture section of his blog to the incremental progress laid out over time).

In addition, in Agile Software Requirements, Dean has described a “business epic kanban system” which he uses to make the work in process visible, understand the state of epics as they transition to development, and to get the portfolio planners on a similar agile page as are the agile development teams. He and a number of our customers have used this system effectively in a number of large enterprises, so we know it makes a good starting model for portfolio/strategic planners who run portfolios as a sereis of releases.

As a result, this model of strategic allocation and roadmap planning is proven to work well for agile teams that ship code series of releases. Here is Dean’s model from that book and his web site.

Big Picture: Scaled Agile Delivery Model by Dean Leffingwell

We have a number of customers making very good progress in developing strategic roadmap steering capabilities using this approach and Rally’s Project Stratus. If you are interested in this approach paired with Stratus, consider contacting Dean or Ronica, our services owner, directly or through your Rally Account Manager. (See Ronica’s contact information below.)

We will continue to explore hybrid waterfall/stage-gate, other hybrid agile (scrum/kanban), and continuous flow techniques for strategic planning in the coming months. Please stay tuned.

Finally, to fully explore the problem and solution space, we created the RallyON conference. We will host this conference in Boulder on May 10th and 11th. We limited the conference to 150 attendees and it has sold out quickly to our most active users and champions. Don’t worry if you are not attending as there are a number of ways to engage in the conversation including:

• Responding to this post with your challenges, ideas and comments on strategic planning in an agile context
• Sharing your opinion or challenges related to topics that Rally Coaches, Technical Account Managers and Product team members are posting for the conference on our new Coaching Blog.
• Posting your agile, scrum, kanban and xp questions on pm.stackexchange.com or programers.stackexchange.com to have a the community formulate answers to your questions prior, during and after the conference. We will have expert users from both of these stackexhanges on site at the conference to help us leverage this rapidly growing community.
• No matter what choice you make, please tweet your efforts with the #RallyOn11 hashtag. It will get the attention of the Rally coaches, technical account managers and product team, in addition to all the physical and virtual RallyOn attendees.

Please join us online before during and after the conference to explore the topic of strategic agile.

About the authors:

Ryan Martens is a member of NRDC’s Environmental Entrepreneurs,  founder/CEO of the Entrepreneurs Foundation of Colorado, and Founder/CTO at Rally Software Development.

Special Thanks to Catherine Connor, the lead on Project Stratus at Rally and Solutions Evangelist Ronica Roth, who owns our Services strategy at Rally.You can reach Ronica at ronica[at]rallydev.com

In Boulder Colorado, it has been freezing cold and bright blue on the first day of both January and February. These 2 clear and crisp days have formed a meteorological metaphor for me about the year ahead. Let me give you some examples:

Back at 3333 Walnut in Boulder

• In early February, Rally moved our offices to one of our previous Walnut street addresses: 3333 Walnut street in Boulder. This time we are inhabiting the entire building, not just the first floor. The bright paint, open floors, wonderful art and huge windows are providing a clear and crisp view of the Boulder Flat Iron Mountains as well as Rally’s future.
• After a year of working on our Rally 2020 shared vision, starting with individual employees, moving up to groups and then into departments, that vision has now been incorporated into our 3-5 year planning. This long-term visioning has informed our 2011 planning in a way we couldn’t have imagined.  It is amazing how that shared vision exercise has put a clear and crisp focus on our planning.
• The 10 year Agile celebration that Alistair Cockburn held last week in a bright blue Snowbird Utah provided a clear and crisp view of what our industry needs to tackle in the coming 10 years. In Mike Hugo’s post on the event, we gained a clear, crisp of view of our mission: “Maximize value creation across the entire process.”
• Dean Leffingwell just published his Agile Requirements Management book.  I believe this will be the critical Agile requirements text in Universities around the world for many years to come.  Dean’s clear, crisp writing style and big picture model provide a promising vision of the value of Agile for the future of large organizations.
• Our Corporate Social Responsibility (CSR) team has recently received internal funding from Rally due to some great ideas and hard work. The CSR team’s January planning efforts will become public next week.  This is exciting. Thanks to this team’s perseverance, my early visions in this area of social responsibility are now starting to become a clear and crisp realization.
• We recently hired a new VP of Engineering and Operations, promoted our VP of Products to also be a CTO with me, and promoted a Director of Product Marketing to VP of Products.  With these promotions to support our growth and my upcoming sabbatical, 2011 is definitely looking clear and crisp for me.

What visual metaphor is becoming clear and crisp for you in 2011?

Ryan Martens is a member of NRDC’s Environmental Entrepreneurs, founder/CEO of the Entrepreneurs Foundation of Colorado, and Founder/CTO at Rally Software Development.

As a part of our series on Scaling Agile to the Strategic Level, I have invited our product lead on this project, Catherine Connor, to tell us about her experience in creating Project Stratus. Thank you for the great work and help on this series Catherine.

Project Stratus was conceived over a year ago from numerous customer discovery interviews geared at understanding the challenges of strategic planning with agile execution. From these interviews we started to form an idea of what an agile strategic planning tool could look like, but we also knew that we would need to do serious customer validation before getting to productize a solution.

We’d already selected a disciplined approach to customer validation based on The Four Steps to the Epiphany – Successful Strategies for Products that Win by Steven Blank. Although the book focuses on startups, many of the ideas, such as diligently conducting customer validation and creating a sales roadmap (i.e. a repeatable process to sell your product) can also be applied to new products in existing compagnies. The basic premise of Blank’s approach is that if you solve a problem for customers (called “earlyvangelists”) who are so acutely affected by that problem that they are willing to build a solution themselves, you are more likely to deliver a product that will solve that same problem for many more customers.

Four Steps to the Epiphany © Steven G. Blank

Project Stratus was drastically accelerated in April 2010 at the LeanSSC conference in Atlanta, when one of our customers unveiled the agile product portfolio scheduler application they’d built to solve their own strategic planning needs. Not only did the application visualize where we were heading, it also happened to be built on the Rally Platform. We’d just found our first earlyvangelist.

Four months later, at Agile2010, we privately introduced Project Stratus to a handful of industry analysts and customers to gauge their reaction. Based on their overwhelming excitement, we proceeded in identifying additional earlyvangelists from past customer interactions. An earlyvangelist is like a P1 defect, when you find one, you know right away. These customers are so excited to see a provider like Rally think up a commercially supported solution to the problem they have been trying to solve themselves, they are anxious to guide you, and some are even irritated by the fact that the product is not out yet; when all along we’ve been thinking not to deliver such a thing! I could tell when I first engaged with Paul, Dale, Nina, Christophe and others, that they would be partners in shaping Project Stratus to become a valuable product. The beauty of Blank’s technique is in its reciprocity. We, the solution provider, get to build a product that solves real needs, earlyvangelists get to shape a supported solution to replace their manual solution, and customers get to benefit from their peers’ expertise.

With earlyvangelists on hand, we sat down to define the set of hypotheses to validate. This is an important step to ensure that interviews provide meaningful outcomes. Nothing is more deflating than spending an hour with a customer only to find yourself with no good answer to “exactly what did I learn from this call?” Listing hypotheses is also a great way to communicate to yourself and others in your company what you are trying to find out and what you are purposefully setting aside for another time. This is very much like “theory-based decision making”, one of Rally’s corporate core values.

Since August, we have been incrementally evolving Stratus, one weekly build at a time, diligently validating our hypotheses one at a time.  Earlyvangelists’ real-life experiences combined with our coaches yearning to apply agile and lean principles to the strategic level are informing the direction of Stratus. I feel really good about where Stratus is going.

As an agile product manager who has seen several projects being productized prematurely, I am truly enjoying following Blank’s rigorous Customer Development approach and definitely would recommend it to my product manager comrades. You do need executive support which thankfully Rally provides me. Following Blank’s technique is no small feat however, it is hard and diligent work with no guaranteed productization plans until you pass his customer validation final exam: “you have proven you have understood customer problems, found a set of earlyvangelists and delivered a product that customers want to buy, developed a repeatable and scalable sales process and demonstrated you have a profitable business model.”  Then, and only then, will we graduate to Blank’s customer creation step, aka the delivery of an official Rally offering for Strategic Planning.

The customer validation step for Project Stratus is going full steam. We welcome more earlyvangelists to partner with us in this exciting endeavor. The more input we receive, the more valuable the product will be. If you have strategic planning challenges and a passion for applying agile principles for solving them, I invite you to reach out to us at stratus@rallydev.com. – Catherine Connor

The work done by Steve Blank on this method is fantastic. In addition to Project Stratus, I have used it with our large on-premise customers and with TechStars companies in order to keep from leaping to conclusions and trying to by-pass the customer creation stage. I hope many of you can empathize with the discipline required to do both of these things in the world of product development.

Ryan Martens is an Epic Pass holder for 2010, a school board member at Friends’ School Boulder and CTO at Rally Software Development.

Catherine Connor is a Product Manager at Rally Software Development. She focuses on the product manager role in our customers’ agile transformation endeavors.

It’s shaping up to be a busy November for us here at Rally with conferences on both coasts. We’re a Silver sponsor of Gartner’s Application Architecture, Development & Integration (AADI) Summit November 15-17 in Los Angeles. For Agile Development Practices (ADP) East November 14-19 in Orlando, Rally is the Conference Sponsor and once again I’m honored to be presenting. We’re coast to coast, and we’ve got discount codes for both conferences (see below).

Rally on the West coast with AADI

Rally is excited to be a part of Gartner’s AADI Summit that focuses on powering the Agile enterprise. The summit includes a key conference track on Agile and highlights three critical building blocks of a successful applications strategy—Cloud, SOA and the overhaul of existing Applications. Stop by the Rally booth to talk with one of our Agile coaches or other team members to learn how we can help move your organization into the next phase of Agile adoption.

In addition, one of Rally’s high-profile, enterprise customers will be speaking about how their adoption of Agile practices in an 800-person development organization (within a $15 billion division) has delivered:

• 3X better throughput
• an 89% bug reduction
• the elimination of over 180,000 hours of development time in one quarter

For more news and information about the summit, follow the #GartnerAADI hashtag on Twitter. Also, stop by the Rally booth (F) to pick up a hat, register for a chance to win an iPad, and to learn more about how we can partner with you in achieving Agile success.

Rally on the East coast with ADP East

Once again, Rally is proud to be the Conference Sponsor for ADP East. This conference is a great opportunity to dive into both Agile basics and the latest trends in Agile. Participants will gain guidance in testing, development and organizational best practices.

I always love the ADP conferences because of the energy of the participants and the variety of topics. The conference is a great venue in which to share new ideas and experiences. This year I’m excited about exploring new trends in Kanban as well as revisiting Agile basics such as story writing.

Be sure to check out my two sessions on Monday and Wednesday along with these other opportunities to join with us at the conference:

• Monday, 11/15 at 8:30 am – Writing Great User Stories 1/2 day tutorial
• Tuesday, 11/16 at 4:30 pm - Welcome Reception, sponsored by Rally
• Wednesday, 11/17 at 12:45 pm – Lean, Kanban and the Art of Flow regular session with Bill Wake, Senior Coach at Industrial Logic, Inc.
• Wednesday, 11/17 at 2:45 pm – Agile with the Right Tools can Maximize Developer Productivity with Collin O’Brien, Technical Account Manager and Sean Billow, Major Account Manager at Rally Software
• Visit the Rally Software booth # 7 & 8 to chat with Agile coaches and other Rally team members about how we partner with organizations through tools, coaching and community to help achieve Agile success. Rally is also contributing an iPad to the conference Passport game, so be sure to stop by to get your passport stamp.

For more information and updates about the event, follow the #ADP10 conference hashtag on Twitter.

If you’d like to join us for either of these events, use the following registration links and discount codes: Gartner AADI use code ADRD to save $300; ADP use code RAAV to save $200

Jean Tabaka is a wine enthusiast, author and Agile Fellow at Rally Software Development. You can follow Jean on Twitter at @jeantabaka

Please help us find qualified candidates for an exciting new opening at Rally’s Boulder headquarters.  With compounding user growth, seven agile teams, four product lines, two development locations, as well as multi-tenant SaaS and on-premise deployments, it is time for us to hire a VP to help us continue to grow and thrive.

We have managed with various folks playing parts of this role over the last seven years, and now we need to add a skilled, servant leader and operator to our senior team to enhance functional management across the software value-delivery chain.

This person will be part of our senior management team and be responsible for all technical engineering and operations. As a peer to our VP of Products and supported by Zach’s four product line managers, you and your teams will collaborate with these managers to advance the product portfolio components and overall strategy.  This person will work with a world-class team of software, systems, operational engineers and scrum masters.   Service Level Agreements (SLA) with customers will measure success in this role with the goal of increasing overall engineering resource development, mentorship and flexibility to meet evolving products, features, and architectural needs.  Our intent is to continue growing this part of the business through organic, development partners and acquisitions.

A major part of personal success in this job comes from thriving in our culture of team collaboration, personal responsibility, high ethics, social give-back and intrinsic motivation.

If this sounds like you, we would love to hear from you via the career section of our web site. There you will find a detailed job description as well as other benefit details.  (If you are not quite ready to apply, but want to have a quick confidential conversation with the management team, please send email to vpengops@rallydev.com. No recruiters please).  If this is not you, but you know someone who might be interested, please share this with your friends and with your networks using the “ShareThis” button below or through our LinkedIn post.

We are very excited to find the right addition to this agile engineering and operations group.

Ryan Martens is a the CEO of the Entrepreneur’s Foundation of Colorado, and CTO at Rally Software Development.

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.

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!”)

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.