Agile Development Blog

“You learn more quickly under the guidance of experienced teachers. You waste a lot of time going down blind alleys if you have no one to lead you.” -W. Somerset Maugham (1874 – 1965)

Filmed at Rally’s Agile Success Tour events, these videos detail the real-life agile implementations of software/IT executives who have taken the enterprise agile journey and are now realizing the benefits of enterprise-scale software Agility.

Our coaching and technical account teams (including Jean and myself) provided guidance to many of these panelists during their initial steps in their journey.  It gives me great pleasure to see them now become the teachers and share their expertise with the new generation of practitioners.

Don’t pass up this great opportunity to learn from the experiences of others!

click here if video player is not loading in your RSS reader

Catch the next Success Tour events in Boston, Seattle, Chicago and London this Fall
These events are free, but registration is required.

Never back down from an intelligent debate - or whatever these idiots are doing

The question over product management vs. product ownership is a huge issue that many companies face as they try to scale Agile. Dean Leffingwell just finished up a great series on Agile Journal in which he makes the case that the Enterprise Product Manager is Likely NOT the Agile Product Owner.

The Agile Journal article series is a great place to jump into the debate, but his blogging on Scaling Software Agility is also excellent and very deep – what Dean tends to call “pithy.” I am sure some of you will call foul with some of Dean’s points, but his methods have proven to be very effective with large-scale agility. I’d ask, are you skeptical based on personal bias or real Agile principles?

Here are four other resources that are great at analyzing product management and product ownership:

1. Enthiosys – I highly recommend their “Product Bytes” newsletter (Luke, Scott and Rich’s leadership here)
2. Pragmatic Marketing – They are shutting down my favorite Tuned In blog, but the others are also good and Tuned In has excellent archived topics
3. On Product Management – I love their lens on product management overall, not purely Agile
4. Accidental Product Manager – Very pithy blog on product management and timely topics

Final note to readers: Dean is a good friend of mine, and he helped me start Rally.  He is an investor and worked for us between 2003 and 2005.  Now he does his own consulting on large-scale Agile and continues writing for Prentice Hall.  I cannot thank him enough for his personal support in shaping my thinking around large-scale software development, building a network into some of the world’s best practitioners, and coaching me as an entrepreneur.  He is a passionate software craftsman.

Thanks, Dean, and very nice work on this critical topic.

Okay, that wasn’t exactly how it was said. However, the title of this post reflects a comment I overheard recently while facilitating an operations and architecture team’s retrospective.

We first looked at basic facts about how their quarter had “gone”: what events stuck out in their minds, what the basic acts and information were that surrounded their day-to-day work. Just the facts. From there we checked out the impact of those facts, that information, those events, on them. Was this a good thing? Was that a bad thing? Were these helpful things or challenging things? We were seeking reflection on the quarter to then help draw out some insights into trends or recurring issues and themes.

After this, I asked the group of 8 people: “What still puzzles you?”

No one had ever asked them that before. They leaped at the opportunity to express frustration about where they sit (or don’t sit) in the Agile development approach. Did they have “a seat at the Agile table” or not? Here they were, the operational experts. They held grave concerns about the operational scaffolding upon which prioritized features were being built across the multiple application teams. And yet they felt that the collective Product Owners could not see this. ‘Tis a puzzle.

Once the group had aired their puzzles and concerns, I then asked for their recommendations. And that is when, verbatim, one of the team members said, “Well, we need to push it up their backlog!” Now, as a facilitator, I am asked to write what is spoken and also to not comment. But this was priceless!

In any case, how DO we push something up someone’s backlog? And why is PUSH even considered the only way to get onto a backlog or backlogs. Here are some ideas that then swarmed around in my head:

• how do we articulate the value of operational and architectural items?

• who do we articulate this value to?

• how do we convey that value across multiple teams’ backlogs (i.e. influencing multiple Product Owners)?

• how do we then coordinate operational items being completed for the next major release across all backlogs?

So, maybe pain is the only sometimes way to help articulate the value of operational work: “It will cost our customers this much pain if we don’t do this.”

The moral of this story: Pushing things up your (or someone else’s) backlog sounds painful; find another way.

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 we started with Scrum at Rally years ago, we used to just do a design meeting every few weeks with a couple of key stakeholders to talk about what was coming up and prepare the backlog.   This worked relatively well, but as we added more discipline to our release cycle, the ad-hoc backlog planning our Product Owners were used to started to break.

If you want your team to be able to make a commitment around 8 weeks of backlog, you need to do somewhat more prep than you would with vanilla Scrum.  And if you want your team to meet that commitment, you need a mechanism to manage your stakeholders to minimize backlog churn.

About a year ago, we chartered a Product Council to solve this problem.  The Product Council is led by the uber Product Owner for each product, and consists of stakeholder representatives from all interested departments.  This team operates as lightweight Scrum that grooms the backlog for the next release, working in 4 meetings that are 2 weeks apart.

Meeting 1: Retrospective on the last Release

The first meeting falls about a week after the engineering team does Release Planning.  The Product Owners review the plans for each Scrum, talking through the stories for the stakeholders.  We’ll also highlight the work that definitely does not fit into the release.   Usually we have commitments from the development team as to what will be delivered.

We then ask people to rate how they feel about the product (what we plan to deliver) and the process (how we decided).  We tabulate these numbers, and then move on to a regular retrospective on the process – what went well over the last 8-week cycle, what didn’t go well, and what should be changed going forward.

Meeting 2: Bring Your Ideas

In the second meeting, we hang the roadmap and various backlogs on the walls – usability, platform, deferred defects, technical debt, customer requests, etc.  The Council spends about 20 minutes “walking the walls” – reviewing the roadmap and various backlogs.   People add items they think are missing, shift items forward where necessary, and talk about issues and concerns.  The purpose of this meeting is to identify those items the Product Owners should research for the next release – we usually leave with about 10 epics that need investigation.

Meeting 3: Presenting the Design Continuums

The Product Owners spend about 2 weeks researching those key epics, and come back with rough design continuums (backlogs) for each one and high-level estimates.  In Meeting 3, they present these ideas.  Sometimes an epic is too complex or unknown to be considered for the next release, or perhaps it’s too expensive to build given it’s value.  The Product Council votes to rank the different epics.

Meeting 4: Presenting the Detailed Backlogs

Based on the voting from the last meeting, the Product Owners go off and begin blending the strategic epics from the Product Council with small customer requests, deferred defects, and other small items.  In Meeting 4, we present the detailed, forced-rank backlogs that we intend to present to the development teams in Release Planning.   We talk about what’s changed and see if there are any last-minute, “Stop the line” type shifts that have to happen.  We get a fist-of-five commitment from the Product Council to confirm their support for these backlogs.

Moving forward, I’ll post more details about how these specific meetings work.

As I watched the Rockies sweep the NLCS I could not help but to think that the Rockies took advantage of Rally’s professional coaching services to help the team achieve success with their agile rollout. Let’s analyze baseball in regards to agile…

During the regular season baseball teams play in 3 or 4 game series, which can be thoughtof as an agile release. Each game in the series can be thought of an individual iteration with a timebox of 27 outs. The user stories don’t really change, a typical baseball iteration has 9 user stories (innings) with 3 story points each. The velocity of the team
really depends on the pitch count. If the pitch count is low we could consider the story to be completed faster than other stories in terms of relative sizing.

Similar to agile, the size of the team is nine players on defensive. These nine players work very closely together to complete each story and focus all of there energy on the current iteration (game). A team member grabs tasks (outs) when they feel they are able to take on more work. Team members regroup in between each inning for a quick stand-up meeting to discuss the next highest priority story (ok this is a long stretch but maybe they have a stand-up).

After the completion of the iteration there is always a retrospective (post game
conference). During the post game press conference (retrospective) the team manager acts as a scrummaster or coach and shields the team from media controversy. The manager is ultimately shielding his team from stakeholders (fans, media, owner) and focusing them on the current iteration (game).

At the end of a game (iteration) the team has completed 9 user stories and the team owner (product owner) either accepts the game or does not accept it (win/lose).

To end this fairly useless analogy we have to consider the post game celebration. Trust me the Rockies had one heck of a release party last night.

GO ROCKIES!

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.