Business Analysis Thought Leadership - Articles



BA ARTICLE ARCHIVE
» July 2014 (6)
» June 2014 (7)
» May 2014 (5)
» April 2014 (5)
» March 2014 (7)
» February 2014 (6)
» January 2014 (6)
» December 2013 (7)
» November 2013 (4)
» October 2013 (5)
» September 2013 (6)
» August 2013 (8)
» July 2013 (8)
» June 2013 (7)
» May 2013 (8)
» April 2013 (8)
» March 2013 (4)
» February 2013 (6)
» January 2013 (6)
» December 2012 (5)
» November 2012 (7)
» October 2012 (6)
» September 2012 (6)
» August 2012 (5)
» July 2012 (9)
» June 2012 (5)
» May 2012 (9)
» April 2012 (7)
» March 2012 (7)
» February 2012 (5)
» January 2012 (7)
» December 2011 (6)
» November 2011 (6)
» October 2011 (8)
» September 2011 (6)
» August 2011 (8)
» July 2011 (7)
» June 2011 (7)
» May 2011 (5)
» April 2011 (8)
» March 2011 (6)
» February 2011 (5)
» January 2011 (6)
» December 2010 (5)
» November 2010 (9)
» October 2010 (5)
» September 2010 (6)
» August 2010 (8)
» July 2010 (6)
» June 2010 (6)
» May 2010 (10)
» April 2010 (5)
» March 2010 (8)
» February 2010 (7)
» January 2010 (7)
» December 2009 (7)
» November 2009 (7)
» October 2009 (6)
» September 2009 (8)
» August 2009 (10)
» July 2009 (9)
» June 2009 (5)
» May 2009 (10)
» April 2009 (5)
» March 2009 (12)
» February 2009 (8)
» January 2009 (6)
» December 2008 (9)
» November 2008 (8)
» October 2008 (9)
» September 2008 (4)
» August 2008 (6)
» July 2008 (8)
» June 2008 (17)
» May 2008 (12)
» April 2008 (7)
» March 2008 (21)
» February 2008 (16)
» January 2008 (13)
» December 2007 (9)
» November 2007 (25)
» October 2007 (2)
» September 2007 (23)
» August 2007 (12)
» July 2007 (11)
» June 2007 (7)
» May 2007 (6)
» April 2007 (9)
» March 2007 (5)
» February 2007 (3)
» January 2007 (2)
Articles and White Papers
Wednesday, February 04, 2009
18263 Views 3 Comments 8 members voted Article Rating

As an agile analyst, you know how easy it is to get lost in a blizzard of project details. The way to keep focused is to remind yourself of the chief reason for using agile processes: to deliver business value for your organization. With that in mind, we’ll look at specific ways you can combine two approaches: agile and lean.

Lean Focuses on Value
Lean processes—whether you’re building bicycles, assembling TV dinners, or developing software—are all about value. Value, in lean terms, is any action or thought a customer is willing to pay for (Larman and Vodde 2009). Activities like rework, reprocessing, reformatting, storage, handling, and sign-offs are not valuable. In lean terminology, they’re waste.

Shigeo Shingo (1981) identified seven wastes of manufacturing, and Mary and Tom Poppendieck (2007) translated these into waste in software development, as shown in Table 1.

Table 1: Translating the Seven Manufacturing Wastes into Software Development

The Seven Wastes  of Manufacturing The Seven Wastes  of Software Development
Overproduction Partially done work
Inventory Extra features
Extra processing Relearning
Transportation Handovers
Motion Task switching
Waiting Delays
Defects Defects

Source: Poppendieck & Poppendieck, 2007.

For an agile business analyst with keen eyes toward eliminating waste, this list offers a goldmine of opportunity.

Partially Done Work
Artifacts such as a detailed requirements specifications, untested or undocumented code, design drafts, or other work products not implemented—all are examples of partially done work. As an agile business analyst, what can you do? 

  • Help the product owner (a.k.a. customer) develop a product backlog with minimal detail.

  • Aid the product owner and team to elaborate on backlog items only when they are to be pulled into the next iteration (a.k.a. sprint).

  • Create “just enough” analysis artifacts so that your team can estimate and define the tasks for each iteration backlog item during the planning workshop.

  • Anticipate when backlog items won’t be “ready” (not enough is known to plan them), and postpone work on them until it will produce value. 

Extra Features
A feature is waste if you capture and implement it “just in case” (overspecification) or because the customer “might want it” (gold plating). It doesn’t add value. What can you do? 

  • Operate within a delivery time box focused on small batches of requirements of about equal size.

  • Collaborate with your product owner and team to define a set of requirements that fits the team’s work capacity for each iteration.

  • Work only on requirements (a.k.a. stories) that you’ve committed to deliver in the current iteration (or in preparation for the next iteration’s planning).

  • As you elicit requirements, validate them by defining “doneness” criteria and user acceptance tests for each requirement.

  • Create, or help your product owner create, requirements documentation that provides value to someone.

  • Substitute user acceptance tests wherever possible for some, if not all, of your iteration-level requirements documentation

  • Ensure that each requirement is ranked, and help your product owner regularly re-rank changing requirements. 

Relearning
Software development is knowledge work composed of many continuous and compounding decisions. It’s difficult to remember small decisions, and their effects, as development expands. To provide a knowledge trail, many organizations try to capture decisions in documents and processes. The risk is that they become pure bureaucracy—burdensome, meaningless, and wasteful. As an agile business analyst, what can you do? 

  • Conduct your analysis as close as possible to the time when it will be consumed, such as when code and tests are built.

  • Challenge the business value, form, and format of each document and analysis artifact. Ask, “Do you really need that entire document? Why? When? What other ways can we satisfy that need?" Work with audit, regulatory, and legal to define only the necessary and sufficient documentation.

  • Help your team obtain product owner sign-off on each “done” requirement throughout the iteration.

  • Conduct dependency analysis to prevent or mitigate rework resulting from undetected requirements dependencies. 

Handovers
Handovers include moving artifacts from one team member to another. An example is a business analyst acting as translator between businesspeople and technical staff by creating requirements documents that then need to be signed off and handed off to technical staff. What can you do? 

  • Act as an aide or coach, and not a translator, to your product owner (unless you are the explicitly designated product owner).

  • Explore requirements directly with your product owner, subject matter experts, and the delivery team.

  • Use low-fidelity analysis techniques (mockups, simulations, whiteboards and flip charts, role-playing) to increase the density of information exchange.

  • Have developers and testers join you when you interact with users and stakeholders so they have a level of first-hand understanding of the problem.

  • Sit with developers as they implement and testers as they test so you can clarify and define details precisely when they are needed.

Task Switching
When a developer or tester must seek out, e-mail, or schedule a meeting with a product owner or analyst to answer questions about a requirement, that is task switching. If you, as business analyst, hunt down a product owner to clarify business rules or check with the data administrator about the sources of a data item, you’re task switching. Working on multiple tasks in a short time saps your capacity to finish a single task and delays your completion of any of them. What can you do?

  • Work on one project at a time or within one business domain.

  • If you must multitask, cluster your time for thinking and acting so it is focused on the same domain.

  • If you have rich domain expertise and understanding of business value, you may be the product owner, with direct decision-making authority about requirements priority and doneness.

  • Be available to others so you do not block their work and force them to task switch.

Delays
Whenever someone or something is queued up and waiting to be started, you have waste: time is wasted, queued items age, and downstream resources are idle. What can you do?

  • Make sure each requirement is ranked for priority with business value in mind.

  • Encourage clear decision-making rules. At the start of each iteration, the product owner must decide which work is highest priority.

  • Use collaborative techniques, such as informal workshops and prototypes, that allow stakeholders to “play” with requirements and make immediate decisions.

  • Clarify requirements by focusing on story doneness and user acceptance testing.

  • Show finished work right away to the product owner.

  • Make sure that subsets of roughly equal-sized requirements are ready to be pulled into each iteration planning workshop to provide an even flow of work.

Defects
The later a software defect is detected, the more it costs to correct. Defects originating in requirements (missing, erroneous, conflicting, or unnecessary requirements) are costly. What can you do? 

  • Ensure that each story is small enough to work on in a single iteration, enabling defects to be found and fixed in smaller pieces and time scales. (This minimizes relearning, handovers, task switching and delays as well).

  • Define doneness criteria for each requirement (story) as part of analysis before or during iteration planning.

  • Create low-fidelity prototypes of stories to check for understanding and find missing requirements.

  • Conduct research on ambiguous backlog items as they move up the backlog stack (I call these “analysis spikes”).

Agile + Lean = Added Value
As an agile business analyst, you are skilled at good thinking. With an eye toward waste, you can help deliver business value to your organization by adopting lean principles in your agile projects.

References
Gottesdiener, Ellen. The Software Requirements Memory Jogger: A Pocket Guide to Help Software and Business Teams Develop and Manage Requirements. GOAL/QPC, 2005.

Larman, Craig and Bas Vodde. Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum. Addison-Wesley, 2008.

Poppendieck, Mary, and Tom Poppendieck. Agile Software Development: An Agile Toolkit. Addison-Wesley, 2003.

Poppendieck, Mary, and Tom Poppendieck, Implementing Lean Software Development: From Concept to Cash. Addison-Wesley, 2007.

Shingo, Shigeo. A Study of the Toyota Production System. Productivity Press, 1981 (Japanese), 1989 (English).

Thanks!
The author would like to thank Tom Poppendieck for his review and incisive comments on a draft of this article.

Author: "Ellen Gottesdiener, Principal Consultant, EBG Consulting, helps you get the right requirements so your projects start smart and deliver the right product at the right time. Ellen’s company provides high value training, facilitation, and consulting services to agile and traditional teams. An agile coach and trainer with a passion about agile requirements, she works with large, complex products and helps teams elicit just enough requirements to achieve iteration and product goals.

Ellen’s book Requirements by Collaboration: Workshops for Defining Needs describes how to use multiple models to elicit requirements in collaborative workshops. Her most recent book, The Software Requirements Memory Jogger is the “go-to” industry guide for requirements good practices. In addition to providing training and consulting services and coaching agile teams, Ellen speaks at and advises for industry conferences, writes articles, and serves on the Expert Review Board of the International Institute of Business Analysis (IIBA) Business Analysis Body of Knowledge™ (BABOK™).

You can subscribe to EBG Consulting’s offers a free monthly eNewsletter “Success with Requirements” offering practical guidance and requirements-related news. When you sign up, you’ll receive a free article on essentials for scoping your requirements."

 Copyright © EBG Consulting, Inc., 2009

Rate this:

COMMENTS

Posted on Wednesday, February 11, 2009 10:42 AM by
blanchard26
Ellen Gottesdiener has given another well done article! This approach is exactly what is needed, even for the most structured and politically burdened projects. You have made a difference again. Thanks for your contribution to better software.
blanchard26
Posted on Wednesday, April 15, 2009 1:08 PM by
manukonda
It was good but more information on the technology would have been better.
manukonda
Posted on Tuesday, April 21, 2009 7:27 PM by
ellengott
Thanks for your kind words Blanchard26, and also Pavan.

Pavan: please clarify what you mean when you say you want more information on "the technology".

thanks,
~ ellen
ellengott
Only registered users may post comments.

Do you twitter?: If you want short updates on what's going on in the BA world and at ModernAnalyst.com, simply follow us on Twitter: http://twitter.com/ModernAnalyst



Featured Digital Library Resources 

Copyright 2006-2014 by Modern Analyst Media LLC