Agile Development Blog

In March, Johnny Scarborough, Area VP of Product Engineering with GlobalLogic, and I kicked off a 2-part webinar series, “Using Agile to Cut Development Costs”. We bantered about leaner, meaner and faster product development. You can view our entire 1-hour webinar here Realizing the Promise of Agile: Creating Leaner, Meaner and Faster Product Development.

In this post, I’d like to respond to some questions posed to Johnny and me during the webinar.

JET = Jean Tabaka

What is the measurement of productivity? Is it user stories per lines of code?

JET: We define productivity index with regard to the Michael Mah statistics collected over 7500 products. It is not about lines of code. Rather it is about delivered value. At a very high-level view then, a PI in an Agile team is about the amount of value delivered by a team based on value delivered over the total number of team members.

Michael Mah shows in his studies, which we referenced in our webinar, that Agile teams tend to have a higher ability to delivery value per team member than the norm across all projects he has surveyed. This supports our view that the way to project cut costs is to help team members increase their PI versus cutting team members or off-shoring work.

When you start on Step 1, one team in flow, do you start immediately with 2-week iterations, even if the teams are used to waterfall?

JET: For any team starting its transition to Agile, the important Flow guidance I give is: Choose a timebox, and stick to it. Religiously.

I give guidance that a shorter timebox is preferable to a longer one. This gives the team that moment of pause for inspection and adaption sooner rather than later.

A shorter timebox invites earlier improvements on process. It also affords the Product Owner or customer representative the opportunity to re-prioritize, add, or delete items in their backlog.

Given these parameters, the team commits to what the timebox length will be. So what do I advise? If asked, I tell teams that 2 weeks is a good starting point: shorter time to inspection versus longer wait for improvement opportunities.

How would you apply Agile, and particularly Scrum, to security related software where design and reviews typically take longer than one iteration?

JET: Agile asks us to evaluate how much design and review MUST occur before features can begin to be coded and tested. Your question is all the more important in your context.

Think of it this way: Imagine in a security software environment, you implemented something and then slammed all kinds of vulnerability tests against it to discover its actual vulnerability. Imagine that this could be in addition to, or even as a replacement to, extensive review up front.

I once worked in a security related software environment. We spent months and months reviewing documentation attempting to conduct  independent validation and verification about vulnerabilities before any coding began. How I wish we could have just conducted detailed design, code, and test on our riskiest features and applied our hypotheses against these rather than being left to hope our analysis was adequate!

If we want to introduce Agile in a certain project team, what’s the perfect ratio of Agile consultants versus our own personnel?

JET: Perfection is in the eye of the beholder ;-)

I suggest one mentor per team initially. We have also used one mentor for a team of teams, a program. That creates stability and synergy across the teams and encourages all teams to form their own Agile team agreements while also learning from what has worked well with the other teams.

One more thing: Having a mentor at the management/executive-level is also critical. It may be this same person; it may be someone who has more of an executive stature.  In the latter case, be sure the two mentors work tightly with one another.

Would you define ‘user stories’?  Similar to Use Cases?  Difference?

JET: User stories are an expression of a request from the customer or customer representative for a particular function. They are meant to be short, incomplete, and value-based.

They invite conversation and further clarification of completion: “As a < role >, I want to < action > so that I can < benefit >.”

“As a dog, I want access to ‘The Daily Woof” newspaper on my Kindle so that I can flip pages without opposable thumbs.”

This request for action and benefit is  elaborated as it rises in rank among all functions requested. We elaborate these in several ways. One way is to start writing acceptance criteria.

Another way might be to elaborate it through a use case that details actor-system interactions, extensions, and so on. A team makes agreements about how function requests grow in clarity; that is, are use cases our best way to declare DONENESS for this request? Or, in our environment, is a simple description and test case sufficient?

How can we get better reporting metrics for roll-up to the executive level? Are there key mash-ups I should/could use?

JET: without digging into specifics with regard to mashups in our Rally tool, I highly recommend looking at a set of metrics we gathered in our whitepaper: “A CIO Playbook for Adopting for Adopting Scrum” co-authored with Ken Schwaber and Dean Leffingwell.

One appendix in the paper guides teams in a quick self-assessment of their Agile uptake. The second offers metrics both teams and executives can use as new measures of success.

Altering how we measure and guide success in Agile has a great impact on the “stickiness” and intended benefits of the Agile rollout. Rally tool mashups simply support real-time access to such measures. This “reporting” style deviates from the traditional “reporting up”. Rather, the metrics we recommend are meant to keep the entire organization informed about what is really happening. This creates organizational ownership of amplified learning and continuous improvement.

Have you integrated user centered design (usability practices) into the Agile development process? If yes, what was your approach? If no, why not?

JET: I  believe user-centered design has a place in Agile development. Design emergence doesn’t mean it can only occur in the planning meeting for the next iteration, IMHO.

At Rally, our usability expert is always working one or two releases ahead to help create urgency and clarity about where our usability issues must be addressed. She doesn’t set out a design for the next 2 years. Instead, she:

• creates a high-level vision (informed by many sources);
• collaborates with the product owners about how to incorporate this across a product roadmap;
• provides more detailed guidance about backlog items specific to the user-centered design;
• then engages actively within Scrum teams when product backlog items specifically impact user design changes (where she is tester or owner or delivery team depending on the item.)

Do Agile practices only apply to software delivery, or have you ever seen them applied to successful service delivery?

JET: Jeff Sutherland tells a great story about helping his wife apply Scrum in her life as a Unitarian minister. I also have a colleague who uses it in his volunteer organization. And there are people in my Certified ScrumMaster classes from non-software parts of software organizations eager to bring Agile in. Here at Rally, we use Scrum in EVERY department in the company, including at the executive level.

It is already challenging to obtain the time of critical resources (shared among various projects and sustaining). Are every day SCRUM meetings practically possible?

JET: Everyday meetings are faster than having to write them extensive documentation. And, they are less costly than not having them involved at all. Still, teams make agreements about how critical it is for “part-time” experts to be engaged in every meeting. They inspect and adapt.

Is Scrum mostly for R&D projects with more unknowns or is it equally effective on projects with extensive functional and technical knowledge and skills.

In other words, is Waterfall totally obsolete?

JET: Rigid methodologies don’t serve environments where any amount of change can occur. If you have projects that have no change in scope, no mis-interpretations of requirements, no defects in design, no defects found in code test or integration that would require re-work, I see no reason for you to change.  I do not know of such projects.

Using Agile to Cut Development Costs - webinar

You can also view Q&A from Ryan Martens along with Dave West from Forrester regarding their webinar at “Q&A Lean Webinar Part 2” and Q&A Lean Webinar Part 3. And you can watch their entire webinar Scaling Agility with Lean: Proven Methods of Operational Efficiency.

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!

I have a friend who was my Engineering Geology Professor and his name is Bernard Amadei.  Bernard found his “good work” right about the time I was starting Rally.  Bernard has a wonderfully friendly manner and a great French accent.

In early 2000′s, he took a trip to Mail to help a village engineer a solution for potable water.  Upon his return, he started working on Engineers Without Borders, which is now a movement.  At the beginning of this work, I collaborated with Bernard as he started the chapter at the University of Colorado and wove it into Bioneers.

At that initial collaboration, Bernard said he was forcing engineers to ask the question, Why? So often engineers just focus on how and what.  He was starting Engineers Without Borders to help give engineers a stronger sense of purpose in solving the world’s systemic problems. (Please see the YouTube video)

Bernard and Paul Hawken had a huge influence on me as I worked to draft the vision for Rally. You can read about my thoughts on the purpose of Rally on my Agile Commons profile page or listen to my BlogTalkRadio interview.

Without a clear vision and mantra , it is hard to answer the question, Why do you develop and operate software?

As you and your software team/organization undoubtedly ask the core versus context questions in your business, I have been providing thinking tools for analyzing your portfolio in these turbulent times.  As Israel Gat pointed out in his recent post, “Can you afford the software you are developing?“

You do not need to take a long time to do this work, but it does provide a checklist of things to ask before you decide what product/code lines you might STOP DOING:

Things to ask before you decide what to stop doing:

1. What are your core values and vision?
2. What is your core purpose – Why? (this post)
3. What is your receipt for sustainable shareholder value?
   
4. What is your approach for getting your software organization leaner and getting stronger in 2009?

Once we have taken all the costs savings from distracting/mis-aligned efforts out of the portfolio, it is time to figure out how to increase the performance of your software development organization.  Jean and I will dedicate most of February to making the “Agile development cuts costs” case for groups that are working on core/mission critical efforts.

While you think about those arguments, I ask you to reflect on Bernard’s point:

Have you found your “Good Work?” and does that match up with your core work?

Today at Rally, we completed a redesign of Agile Commons and changed a number of other things in our online communities.   As a result, you are now receiving RSS updates from the AgileBlog instead of the Commons Blog in Agile Commons.  If you would like to continue following RSS feeds from Agile Commons, please take a look around the redesign and subscribe inside the Commons.

To understand all the things we are doing with regard to this blog and Agile Commons, click on More.

(more…)

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

There are several problems with traditional requirements formats

• They cost a lot of money to produce and yet you can’t sell them to your customers (waste)
• They can be monolithic (90 page use cases) and so they’re hard to manage when different pieces have different importance.  The desire to make them comprehensive loads extra work onto the development team. (strain)
• They take a long time to produce, holding up the development process and delaying the feedback that comes when users get to see working software (wait time)
• The more detailed they are, the more the team thinks they’re complete and the less critical thinking gets applied to them, leading to more defects (waste)

User stories are designed to address these issues.  A user story represents a small piece of business value that a software team can deliver within an iteration.  Here’s one:

As a customer, I want to check my order status online so that I can know when to expect my package.

There’s actually a lot in that little line – we know who the user is, what’s the activity they want to do, and what’s the underlying goal.

Ron Jeffries has said that there are actually three parts of a user story:

1. Card - the part we wrote in italics above.  It’s just a placeholder – a project management mechanism that we’ll use to remind us that at some point we probably should get around to building an order status thingy.  This part should be short enough to write on one side of an index card with a sharpie marker.  You could even word it “Order Status Checker Thingy” to emphasize that it’s a placeholder, not a requirement.
2. Conversation - When this card comes up in the stack as the top priority, the team will talk during iteration planning about the acceptance criteria that will need to be met to satisfy the customer or Product Owner that they built the right kind of “Order Status Checker Thingy”.  Sometimes the criteria are noted on the back of an index card or in an agile tracking tool.
3. Confirmation – The detailed acceptance tests that the team writes during the iteration to define exactly how an “Order Status Checker Thingy” should work, in excruciating detail

A user story is unlike regular requirements because the requirements aren’t specified in detail until the tests are written, around the same time as implementation.  Benefits of this approach:

• No inherent waste.  We’re only writing down as much as we need to document our conversations and make sure we’re all on the same page
• Encourages discussion. Your developers and testers know a lot about what they’re building.  They’re capable of thinking of important details and preventing defects and other bigger mistakes, if the process encourages them
• Easy to manage.  If you’re used to use cases, break down your scenarios and steps into stories.  You can do the important parts early and postpone the less important parts later.
• Easy to manage scope creep.  If you think of new things to do, create new stories and add them to your list in priority order.  Since you’re always doing the most important things first, you’ll end up naturally managing scope in a way you can’t when you’re working off of requirements documents.

(This is a draft – please add comments or edit the pattern itself)