Agile Development Blog

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

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

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

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

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

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

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

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

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

I’m traveling this week to Rally’s Agile Success Tour in San Diego.  I love attending these events because they’re a lot of fun and participants seem to get a lot of value – getting out of the office for a half day is a great way to learn and think about how you can get started or get better with Agile.  Plus, the Rancho Bernardo Inn is pretty nice place to spend a day.

The site of Rally's Agile Success Tour - the Rancho Bernardo Inn

But my day job is as a Product Owner, so I’m still trying to keep up with my team while on the road.  And this trip has been a good reminder of the challenges of working remotely.  Here are seven things I’ve remembered that make a big difference if your team has remote members:

1. Actually log in to your chat client. 
Instant messaging is a great way to quickly make contact with people on your team, but if everyone isn’t actually logged in to chat, you often can’t reach the best person.  If I want to talk to Fred, but I can’t reach him, I’ve got to make a decision – do I wait, or do I interrupt Jason, a developer on his team?

2. Dial in the bridge. 
If you’re having a meeting, and you have remote team members, make connecting to the conference bridge a habit, even if you don’t think anyone remote is going to be attending.  Plans change; something comes up such that someone who was going to be in the office is out.  If you don’t connect the conference bridge, remote employees will either give up, or frantically try to catch local participants on IM in the hopes that someone brought a laptop to the meeting.

3. Check in and out on the phone. 
Assign someone in your meeting to remember the remote team members during the discussion.   And make sure you check in with the people on the phone before you hang up at the end of the call.  (Give them a few seconds to unmute before you assume they’re gone!)

4. List your cell numbers.
At Rally, we have a Google spreadsheet that lists office and cell numbers for everyone.  I’m rarely at my desk during the workday, so cell is the only reliable way to reach me.

5. Skype your standups.  
In our team room, a couple of the machines have Skype running.  When you’re remote, video goes a long way to improving connection with the team.  Showing some video of the absurd furnishings or the view outside the hotel room makes it fun.  This morning, I had some bandwidth issues and could only use voice – it didn’t work nearly as well.  Also, with a team like mine, a remote employee who doesn’t enable video for an early morning Skype session will invariably be subject to baseless accusations of not wearing pants.

6. Leave Skype running for a few minutes after the standup is over. 
Often interesting conversations pop up in the 30 minutes following this meeting.  As a PO, I often overhear useful bits of information at this time, and it makes it easy for people to ask me questions they might have forgotten during the standup.

7. Update your stories. 
This morning, when I logged into Rally, it looked like a ton of work was in progress.  Turns out, my team just hadn’t updated their tasks and stories.  Often Rally is the window your remote team members have into what’s going on.  If you don’t update stories, you can end up with unnecessary confusion.  Fortunately, we cleared it up in our daily standup meeting.

These were the things I remembered this week.  So what tips do you have for making life easier on remote team members?

“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