Agile Development Blog

(Note: today’s blog post is brought to you by the letter “N”)

Continuing our series on N Levels of Planning, I realize that even the usage of “N” in our definition of planning levels has been perplexing me. Sometimes, I think I get what N means. Imagine N = 5. In this context, you might do higher level planning for your product teams. Create a great product vision. Build a thematic product roadmap. Have these faithfully inform release planning, iteration planning and ultimately daily planning. Okay great. Here, N = 5.  And then I think, “But what about when I move to more continuous flow of value delivery through Agile? Now what is my “N”? I move away from iteration timeboxes for delivery, so no plan there, right? Do I still think about some sense of planning at a product vision level and a product roadmap level? Do I still have some sort product release planning but it just differs in approach in continuous delivery versus timebox delivery? Perhaps I now have N = 2; or, is it 3 or 4? And, perhaps “planning” has a different meaning as well.

We’re not done with the ambiguity yet

The N levels of planning complexity doesn’t stop at the product planning level. Think about now inviting levels of business planning as a natural part of Agile transformation and maturity. If I add in a Strategic Business plan accompanied by a Business Roadmap plan, I’ve now moved to N = 7. Or not if I am not using timebox-driven planning. What if the business uses a milestone-driven approach? For example, we know we have this conference coming up; we want a release for that date. We’ll still use a prioritized backlog for our work and we’ll declare our release based on what functionality is available by the milestone. What is “N” now?

But wait! There’s more!

You’ve brought the business into your Agile transformation. As you do so, are you transforming business with your IT organization? Or, is your Agile transformation in the context of product lines in an ISV?  Your business context may impact what and how you plan. In both contexts, you are running Strategic Business planning and Product Roadmap planning in your N-levels of planning. But what do these plans produce and how do you use them? Here, “N” now may rely on your business context. In the emerging business initiatives, have we uncovered capabilities that spread across portfolios or maybe across products? Are there initiatives that extend beyond business unit boundaries? Does this boundary-crossing work create capability-driven versus product-driven teams? Now, what are our N-levels of Planning?

I wonder if I am going to end up with some sort of quadratic equation to resolve “N”

As we continue to delve into a guide for “N-levels of Planning” in Agile organizations, I believe we are discovering the “N” is driven by the variety of taxonomies that lie in our contexts. Criss-crossing these contexts and their taxonomies, there seems to be some potential skeletal guide for “N”. At the least, consider 4 basic realms in which “N” derives definition:

1. Your level of Agile Adoption into the enterprise (product line only, one business unit, or multiple business units)
2. Your business’s technical organizational and architectural structures (e.g. ISV versus IT)
3. Your thematic (requirements) structures (themes, epics, capabilities, MMFs, stories)
4. Your delivery structures (timeboxes, milestones, or continuous flow)

“N” is a complex variable in N levels of planning. I no longer believe there is one magic formula for “N”. I know for sure “N” does not forever equal 5, something I had been so sure of at one time. I will say, I don’t think “N” is an imaginary number :-) I believe “N” reveals itself as we apply intention around the four structures above for our Agile transformations and maturity. And, your mileage may vary.

More to come on our old friend “N”. But first, what’s your “N”?

Jean Tabaka is a “why bother” latte sipper, crash skier, college hoops fan, author and Agile Fellow at Rally Software Development. You can follow Jean on Twitter at @jeantabaka

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.

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.

Introducing Rally's Engineering Blog

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

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

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

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

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

If you have ever wondered what to do with the growing number of features in your software applications, you are not the only one. There is some useful guidance from The Standish Group survey quantifing that only 20% of all delivered software features are “often or always used.” For a team under the pressure of today’s economy to do more with less, here is a way to conceptually cut 80% of your effort and still deliver the high-value essentials. But wait it gets better. If you do not completely elaborate, build, test or document these features, you save once. But you also save again: with the future maintenance costs, the training users, the bug fixing and the regressing these features would have required. This is clearly the biggest lever for cutting software development costs using Agile. And yet it seems to be the hardest to attain.

Features used in Commercial Software - Reported by Jim Johnson of the Standish Group at XP2002

This pairing back to the simple, important few takes tons of discipline and that level of discipline is only be made easier as your agility maturity increases. Most agile books and coaches will call this the discipline of “Brutal Prioritization.” The folks from 37Signals call it: “Getting Real.” In either case, brutal prioritization means two things:

1. Not letting the fat slip into the backlog
2. Keeping the backlog prioritized by value and risk

First, lets talk about fat or wasteful features. Please note, fat or wasteful features come from all directions from the business and customers, but also from developers, support, and product owners. Your features may be fat or wasteful if they:

1. Do not help the most important user persona in your domain achieve breakthrough results or competitive advantage
2. Have not be proven to work and are based on a hopes and prayers
3. Look like pets that someone is protecting
4. Are weak features that degrade the product because they are not complete enough to meet minimum expectations

Photo © Tristan Savatier - http://loupiote.com/ - Used by Permission

So if you are in the customer role or customer proxy role such as the Scrum product owner role, the technical product management or a business analyst role, it is your job to control yourself and help the team to keep the fat off the backlog. If you are on the agile team, it is your job to keep these roles honest about WHY these features are so valuable. This leads right to ranking the items into a prioritized backlog. (A few comments in this area would be really helpful – let’s hear what you use to spot fat features?)

(more…)

When multiple teams are working together on a project, there are many cross-team issues and dependencies that need to be resolved. Significant organizational change is generally needed to support agile development; often this change is more than one team can create on their own.

A Scrum of Scrums is a scrum team made up of representatives from each of several other teams. Usually the representatives are the ScrumMasters for each team, although sometimes technical leaders and product owners also participate. An Uber ScrumMaster acts as the facilitator for the Scrum of Scrums.

Just like a regular scrum team, the Scrum of Scrums works iteratively to deliver value in the form of removed organizational obstacles. Usually this group’s meetings lag just behind the regular Scrum meetings. For example, if the Scrum teams have their daily meeting at 9AM, the Scrum of Scrums might meet at 9:15AM.

Some tips to make this group successful:
1. Remove any unintentional or intentional hierarchy or power associated with this meeting. (This is only a role!)
2. Remind people of the intent and purpose: to remove escalated obstacles or resolve dependencies between teams
3. Have the SOS team create a backlog to work through iteratively
4. Engage the team in a mission/value statement exercise for clarity when stuck
5. For Daily Scrum of Scrums Meetings, stick to the point and stay after to solve problems, just like in the other daily meetings
6. Bring an expert with you or send him in your place if he is better equipped to solve the problem; it’s all about waste and obstacle eradication
7. Make SOS progress visible to the organization via demos
8. Hold retrospectives
9. Don’t give SOS power to inflict decisions on other teams

Consider this pattern when:

• You have multiple interdependent agile teams
• You have a large backlog of organizational impediments
• You are transitioning to Agile development

One of the 7 Principles of Lean Development, “Amplify Learning”, specifically targets the agile practice around “Inspect and Adapt”. In fact, the Lean Principle “Amplify Learning” is the predecessor to the agile practice. At the project level, you can think about amplifying learning in a variety of ways. Daily, we check in with one another about, “What’s happening that could be blocking us from success, and how can we adapt in order to remove that block?” And, at the end of each Iteration, a team pauses in order to demonstrate releasable tested functions (RTFs) and determine how to proceed in the next Iteration. They base their plan on a review of their successes and challenges in the last Iteration. So, what happens at the Program level when agile is being applied across multiple project teams within a Program? How do we still inspect and adapt effectively? This is where revisiting the Lean Principle “Amplify Learning” comes in mighty handy.

“Amplify Learning” means planning to experiment, checking the data around the results, and then incorporating what is learned. For Programs, this means deriving metrics that can be cross-team applicable, not just intra-team optimized. How do we accomplish this? That may require “leaning” on another of the 7 Principles: “See the Whole”.

Here are seven practices that “Amplify Learning” for Programs:

1. Use coordinated Iterations across teams to increase inspection and adaption

   Project teams within a Program manage their integration risk and sub-optimization issues by setting a common rhythm across all teams: one common Release Plan with the same number of Iterations, all of the same fixed duration, for all teams. All teams commit to the common plan in a Program-wide Release Planning meeting. Thus, at the end of each Iteration timebox, the Program Manager, Product Owner, representatives from each team, and stakeholders inspect the overall flow of the Program: Where are the bottlenecks? What resource constraints continue to grab us? What Program risks persist? Where are we slipping in quality or in function delivery at the Program level?

2. Increase osmotic communication

   Group programming and pair programming within each project team creates flow for each team. Optimizing flow for the entire Program relies on this team-level engineering discipline. When team members amplify their learning in this way, they promote rapid osmotic emergence and convergence of the useful Program-level standards and best practices. Norms across the teams buoy the stability of the overall Program.

3. Create total transparency across teams everyday

   Backlogs, burndown charts, and resource loading must be tooled and completely visible across the entire Program, regardless of the number of teams or locations of teams. A common automated Product Backlog coupled with an automated Iteration Backlog for each project team is a must. Programs require nothing less if they are to be able to amplify learning daily, from iteration to iteration, and from release to release.

4. Apply tools to maintain information and create visibility

   Programs must collect data (metrics) and incorporate learning across all teams in order to take advantage of the common rhythm of the team iterations. That means implementing tools that can manage the data, distribute the data, and then track the trends of the data iteration over iteration across all teams. A team-level dashboard as well as a Program-level dashboard has to be visible to all stakeholders across all teams. QA and documentation must have high visibility across all teams in order to plan aggressively and integrate fully for product release.

5. Hold daily Scrum of Scrums across teams

   Once each project team has had its Daily Standup, it’s time to check-in across projects via a meeting of the ScrumMasters or Coaches. In the Scrum of Scrums, a representative from each team checks in with the pulse of the team and turns to the other participants for assistance in removing impediments. Each day, the participants check-in with one another on their action commitments from the previous day. They amplify learning across teams in the Program by rigorously checking in with one another and upholding their commitments.

6. Hold a weekly MetaScrum across stakeholders

   Issues that extend beyond the authority or “radar” of the Scrum of Scrums elevate to a weekly meeting of the Program stakeholders. So, not just inter-team issues, but high-level Program-level impacts are addressed. The stakeholders commit weekly to the gnarly issues that can extend beyond the teams, the IT organization or even across divisions. Each week, each stakeholder is held accountable for having resolved the issue for which they took ownership in the previous meeting. No excuses. In this way, stakeholders inspect and adapt in an urgent, virtuous cycle, setting and meeting audacious Program goals.

7. Hold a Program-wide Release Retrospection at the end of each product release

   Once the set of Iterations timeboxes have completed, the entire Program must pause to evaluate the load and flow of the previous Release: What did we plan during the Release Planning meeting? What did we manage to accomplish by the end of the Release? What new practices did we invite during the Release? What worked well during the Release? What challenges hampered us during the Release? What trends in metrics did we notice over the course of the Release? What issues and concerns still exist? Given the Program team responses to these questions, the entire group then determines: What new practices should we implement in the next Release? What new priorities should be addressed in the next Release? How should we re-shuffle resources across teams? What goals should we set for the Release? What “inspect and adapt” practices need to be amplified?

Amplifying learning means attacking any issue, any risk, any impediment, any waste with a vengeance at any time. A Program that implements the seven practices of “Amplify Learning” listed above will reap the benefits of more reliable product releases through better planning and better responses to the uncertainties that may arise. Pause, refresh, retrospect, go. Do this daily, every Iteration, every Release across all teams and all stakeholders.