Agile Development Blog

In this time of “quick – figure out how to do more with less,” the ROI, work smarter message dominate the airwaves.  Back in early agile conferences “quality of life,” “fun,” and “innovation” were big reasons many teams were adopting agile. They are the main reasons that agile gets pulled into most organizations from the team level.

Pulling from her experience on Rally’s marketing team, guest poster Jessica Kahn describes the improved quality of life she gains from working in an agile organization.  This is the kind of spirit that makes agile so much more than a process fad.  It is a way of working.

Guest Post From Jessica Kahn

As a marketer, I spend a lot of time discussing how Agile speeds time to market, improves software quality and makes teams more empowered and productive.  But Agile also has a profound impact on the quality of life of people whose roles have nothing to do with product ownership or delivery.

When a company is in the pull or innovate phase of Agile adoption, the energy is different.  You join a culture of continuous learning, trust, results measurement and servant-leadership.  This energy is far more significant than the mechanics of the theory.

So, I feel compelled to share 10 ways going Agile will improve quality of life, for developers and non-developers alike.   Why should you care?  If your organization is committed to making this change, get on board.  You might see some big gains yourself.

10 Ways Agile Improves Your Quality of Life:

1.  Every team member contributes.

Since Agile empowers the delivery team, nobody can be a weak link.  They’d get exposed immediately, and they’d get left behind.  By definition, everyone has to produce strong work that contributes to project success.  And it is fun to work with people you can count on.

2.  Servant-Leadership teaches us better skills.

There is no time or place for micro-management or Command and Control in Agile.  Since servant-leadership is the goal, managers are responsible for removing roadblocks to their teams’ success.  Planning sessions prioritize the “what”, and team members are responsible for the “how”.   Do we still get lots of feedback?  Yes.  But are we told how to do our jobs?  No way.  As a bonus, you’ll learn how to be a coach and mentor for your own teams.

3.  Meetings have purpose.

We don’t meet unless we have to.  Our daily standups typically last 10 minutes.  Our planning meetings are tightly timeboxed, so we have to focus and then move on.

4.  Decisions are based on data.

We measure everything that is important to the business.   How else can you make smart decisions on where to spend your time and energy?  Rather than succumbing to the whims and opinions of a few squeaky wheels, by measuring important factors, we have the knowledge we need to back up our decisions  and stay the course, as long as it makes sense.  Therefore…

5.  Whiplash is minimal.

Have you ever worked with someone whose great ideas wagged your entire team back and forth until you could never complete a full project?  If an excited, charismatic tail wags the dog, then chaos, frustration and anger result.

In an Agile environment, you put the great project idea in the backlog, prioritize it against other initiatives, and choose whether and when to work on that project.  And you use your capacity and story sizing to manage expectations.  Which leads us to benefit #6:

6.  Politics are absent.

If you are making decisions based on quantitative results and you have a prioritized backlog, then there is no reason to make political decisions.  What’s the point?  You have the numbers, now go do your job.

7.  The bar is high.

You know how one mediocre project can take you forever to finish, but three challenging projects can sometimes energize you?  Agile sprints are more like the latter.  Sprints can be intense and challenging, and also satisfying.  Sometimes you can even point proudly to your results.  Why waste your days doing boring, mediocre work?

8.  The workday is intense and fast.

With all of that challenge, the Agile workday is short and intense.  Do you want to feel like you are always working, or like you have to hang out at work to show face time?  Work hard, play hard.

9.  Change is frequent.

We hold retrospectives frequently (timeboxed, of course).  With a commitment to changing what doesn’t work, we find ourselves altering our plans regularly, including deciding what to stop doing.  This is refreshing.  In Agile, you go along with the ride and breathe a lot, which is probably good practice for life.

10.  You’ll be smarter.

Future colleagues and partners will want to learn from you.  Your Agile skills will turn up in some unusual places.  You might start timeboxing how long you clean your kitchen.  You may choose to include words like ‘epic’ and ‘backlog’ in your everyday vocabulary.

But you also might do what I did and let go of some of your perfectionism, which has no place in Agile.  And, like me, you might pick up some better ways of structuring your work.

Most of all, you might really enjoy your days more.

The MoSCoW technique for backlog prioritization has its flaws

It’s OK Sergey and Boris. I’m not referring to the capital city of your homeland with its rich history of classical music, literature and sporting heroes.

Instead I’m referring to the technique that the DSDM consortium recommends for prioritizing backlog items – the acronym MoSCoW, which stands for:

• Must Haves
• Should Haves
• Could Haves
• Won’t Have (this time around)

There are a couple of problems with this technique, and in my classes my students spot them right away.

1. The customer always thinks everything is important, and therefore the distribution of the backlog items is hopelessly skewed towards the Must Haves.
2. Let’s say we are planning an iteration. We have only room left to take on one more backlog item, but we have two Must Haves. Which one gets planned into the iteration? Of course we should ask the customer, but what if they aren’t there?

Many customers think that promoting backlog items to Must Haves is exercising better control over delivery, but in fact it is not. A customer who cannot differentiate between the importance of backlog items is ceding control to the delivery team. Work has to be sequenced, and if the customer will not choose then the team will.

A better technique is to rank backlog items such that no two items have the same priority. In this instance, it is very clear the preferred order of delivery.

Jean in the mini-kitchen at Rally headquarters.

Jean has been doing a series of posts (What is with all the Agile process overhead? – part 1,  What is with all the Agile process overhead? – part 2, and How do you plan for unplanned work? – part 3.) on what goes in your backlog.  We have both noticed that it is really tempting to put the kitchen sink in your backlog.  At Rally, we only do progressive elaboration of stories based on subsequent levels of planning, which ends up looking a bit like this:

• Ideas and research topics managed by product line on the wall and adjusted across product lines every quarter
• Epics at the roadmap level (multiple release level) managed in a roll-up project in Rally’s Agile project management solution and estimated every eight weeks for release planning
• Stories at the release level managed in individual projects in Rally elaborated every eight weeks at release planning
• Tasks at iteration level managed by team member in Rally and elaborated every two weeks at iteration planning

As a result, we keep our backlog well groomed and do not waste time (muda) managing excess inventory or over-investing in stories that are not guaranteed to get built.  I have noticed it is really tempting to try and load all your ideas, suggestions and half-baked stories into a product like Rally.  We built Rally to make that uncomfortable – to try and discourage that.  Rally focuses you and the team on the iteration and not a big list of defects and bugs, while our coaches and technical account managers try to help folks move away from thinking of our system as an inventory manager.  We think of Rally and design it as a real-time decision support system.  (See my 2006 article in SD Times on “Kill your inventory manager” for more on this topic.)

As Jean and I were talking about this in our kitchen, I was noticing something  (see the picture). In this picture, there are no dirty dishes in the sink.  This is a relatively new occurrence here at Rally.  It happened when we moved from our old location, which had a huge kitchen and two dishwashers, to this new building. We doubled our square feet but shrunk our kitchen space in half with no dishwashers as a result of an in-house cafeteria that we share with Oracle and Quantum.

With almost no counter space and no dishwasher to batch up dirty dishes, you have to clean your dishes as you use them.  For the 150+ people who work at this office, that means a real just-in-time process of dirty it and then clean it.  As a result, we have less dishes, less wasted time and less wasted space due to managing the dirty dishes.  We also lost the typical sign that says, “Your mother does not work here! Please clean-up after yourself.”

Excess inventory leads to wasted time, wasted effort, and friction.  If you keep your backlog well groomed and focused on the valuable items, as Jean illustrates, you can keep from wasting valuable time.

This post is in honor of Greg Macaluso and Kevin Mindenhall, both manufacturing and distribution process consultants from Coopers & Lybrand.  In 1993, they taught me the way of JIT and Lean while working on an MRP project at Robinson Brick and a remittance processing project at U S WEST Communications.  In addition to tutalage, they had me read and flip the wonderful pictures of JIT, kanbans and manufacturing facilities with no horizontal space.  By removing the horizontal space to store stuff, the raw and work-in-process inventory went down and the throughput went up!

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…)

Yesterday, I mentioned a Rally client team I visited that was concerned about the Rally tool’s inability to create individual team member burndown charts.  We swam through that torrent of misperception only to enter a shark-infested tank around all of the overhead involved in adopting Scrum. Wait! Isn’t Agile supposed to cut costs, not add them? Big overhead sounds like cost and waste to me. Where is this overhead? We quickly zeroed in on their overhead: the Sprint Backlog. Specifically, what should be tracked in the Sprint Backlog?

To start the conversation, they told me that they are always 100% allocated. Huh? “What do you mean you assume 100% allocation?” They helped me understand that, in the Sprint Backlog, they assumed that they worked 8 dedicated hours everyday. For them, Sprint Backlog should reflect all of that time.

This was followed up with, “So how do we plan for work that we didn’t know would come up, like production issues?“  Clearly, they hadn’t read Slack by Tom DeMarco or heard of the Theory of Constraints and The Goal by Eliyahu Goldratt and the notion of buffer. So, we had a few things to clarify around this “process overhead”:

• What goes in the Sprint Backlog?
• How do you allocate your time effectively?
• How do you “plan” for unplanned work?

In this first post on the Sprint Backlog and using Agile to cut costs, I’ll concentrate on the first bullet:

What goes into the Sprint Backlog?

The Sprint Backlog emerges from the Sprint Planning meeting as the team:

• Identifies the highest priority value items
• Breaks them into tasks
• Determines the effort necessary to complete the value items
• Commits as a team

We cut costs by only committing to and tracking the highest priority items that deliver value in that timebox.

We cut overhead by not tracking items in the Backlog that do not contribute to the potentially shippable product increment.

So back to our overprocessed team. We opened up the Rally tool and moved to their Iteration Backlog view. I saw over 50 items, at least. And then, I understood.

The team was putting EVERY task they do throughout the timebox into the Sprint Backlog, whether it added value to the product increment or not.

Imagine having to track all of your day’s activities. Imagine having to, 2-4 weeks in advance, absolutely commit to these full days’ worth of activities. So, indeed, here was the overhead. Vacation days were in the Sprint Backlog: they had 8 hours of effort. Holidays were in the Sprint Backlog: again 8 hours of effort. The book club had to be tracked separately for each individual who attended it.

The result was that the overall team’s Sprint Backlog would show effort being completed, backlog items being marked “Completed”, the burndown chart burning down nicely, and yet no work of product value was started or in progress. This was not a tool issue; this was an Agile adoption issue.

What is the lesson in all of this?

Be careful about what you choose to track in your Sprint Backlog.

Ensure that what you commit to in that Backlog reflects the delivery of product value.

Abiding by this simple guideline will not only dramatically reduce process overhead, but it will also ensure that what we DO choose to track, whether through a taskboard or an automated tool, is work that is intended to produce product value by the end of the timebox.

Now about their allocation percentages and how it contributes to overhead. That is fodder for another post.

Further Reading:

• Part 2: How Do You Allocate Your Time Effectively?
• Part 3: How Do you Plan for Unplanned Work?

Jeff Windman posted a nice little article on TechCrunch IT about Lean, Agile, Rally and Toyota.  Please join the deep and skeptical discussion.

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.

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