What practices can you adopt to help your team experience Agile?

This question was raised by a listener to the podcast we recorded on agile analysis practices with BA coach Yamo. (Find the podcast here.) The specific question that Katie Metcalf asked us was this:

“What Agile techniques would you suggest introducing to a software development team that is currently not using the Agile approach but would like to get a flavor for the methodology?”

Agile: Disciplined Discovery and Delivery

Let’s clarify. We don’t think of Agile as a “big M” methodology.

In fact, we don’t think of agile as a methodology per se. Rather, it’s a disciplined discovery and delivery framework. As we see it, the term “agile” encompasses a number of methods, including lean, Scrum, XP, DSDM, Kanban, FDD, and more.

We shared with Katie the following six points – what we believe are fundamental for doing and being agile. We focus here on agile planning and analysis practices.

1. Use Three Planning Horizons: Now-View, Pre-View, Big-View

Partition product delivery into planning horizons.

Focus like a laser on delivering the most valuable and risk-prone portions of the product as soon as possible (we call this the “Now-View”). Even if you don’t release to the customer during your shorter time horizons, you need to complete a releasable product at the end of each delivery cycle.

Don’t ignore the future time horizon (the “Big-View”). Your release plan and product roadmap are essential guidelines for continual planning and pivoting.

Keeping your day-to-day work tied to these planning horizons takes focus, discipline, and collaboration. Read more about incorporating the three views into your agile planning and analysis here.

2. Product Partners and Value

Successful products are derived through a partnership of three stakeholder communities: your customers, your business (or organization), and your technology team members. Explicitly and collaboratively identify each partner’s desired value. Remember: value is in the eyes of the beholder.

Be clear how decisions will be made—decide how to decide.

Collaborate, collaborate, collaborate. Read a briefing of tips for conducting effective collaboration/discovery sessions on agile teams.

3. It’s the Goal, Not the Role

We may sound like a broken record but it’s so important, it bears saying again: it’s the goal, not the role. The collective goal is to deliver high value product needs—not limit contributions based on titles or roles. Analysis is the entire team’s responsibility. Read more about this, and learn the value of business analysis in Scrum (also applicable to other Agile approaches) here.

4.  Explore Product Options Holistically Using the 7 Product Dimensions

As partners, explore options for product needs using the 7 Product Dimensions (users, interfaces, actions, data, controls, environments, and quality attributes). Use predefined value considerations to evaluate the benefits and risks of your options, and select the highest-value options along these 7 Dimensions.  Assemble the highest-value options into candidate solutions for your next delivery cycle.

This practice allows you to slice product needs into small, precisely understood requirements (chunks), and it takes only minutes to collaborate in this exploration and evaluation.

5. Make Models Real

Explore your product options by using a combination of analysis models and examples. You can use scenarios, acceptance tests, specs in the form of “given/when/then” (à la BDD), or data tables (which you can run using a tool such as FIT or FitNess).

Pull the “testing mind-set” forward by thinking in examples and, as Chris Matts says, “breaking the model.”

Consider using your examples and models to specify requirements instead of writing classic text specifications. Read more about agile analysis and testing synergies.

6. Focus on Finding and Fixing Flaws

Learn. Expect to “fail” to learn—it’s only a failure if you and your team don’t use mistakes as a forum for improvement. Conduct retrospectives to “inspect and adapt” at regular intervals.

Honestly and transparently reflect on both process and product.

We are putting the finishing touches on our new book , which provides specific, practical guidance and examples on all these practices. Stay tuned for the book launch this summer. Details for pre-ordering will be in our eNewsletter. You can sign up here for the eNewsletter.

Additional Readings: 

• Gottesdiener, Ellen and Mary Gorman. Numerous article on agile analysis and planning and retrospectives (description, links, and more references).
• Draft of the Agile Extension to the IIBA BABoK:

So much so, that I put together a tutorial for the April 2011 Quest Conference (Quality Engineering Software & Testing) entitled, “Requirements  Exploration with Tester Collaboration”.  Subsequently, I had the honor to work with agile testing guru Janet Gregory to present this at Agile 2011.

Next month, EBG’er Sue Burk will co-present this tutorial with Janet at the April Software Testing Analysis & Review (STAR) conference. So, you might be wondering, what are those synergies?

The Testing Mindset

Product needs evolve into requirements that define what will be built, what will be tested, and how the product needs will provide value for the organization. People with testing skills need to be involved in requirements for the same reason the other product stakeholders need to be involved: to boost the team’s ability to deliver a high-quality product.

Testers offer important skills to any delivery team. Among other things, they expose hidden requirements (e.g., missing or unclear business rules), and verify that you’ll deliver the product correctly. We at EBG Consulting like to think of this contribution as the “testing mind-set.” It helps maximize the team’s productivity by reducing waste and handovers. Exposing misunderstandings faster early on, means it’s easier and less expensive to correct them.

Any product delivery effort needs the continual, direct, and active use of the “tester mind-set.”

“Requirements Exploration with Tester Collaboration” Tutorial

To demonstrate that, during the tutorial, we have attendees participate in a simulated facilitated workshop. During the workshop, they apply analysis modeling techniques and experience for themselves how these models can be effective for defining test scenarios, test cases, test data, and individual tests.

In the tutorial, participants are introduced to  Behavior Driven Development and Acceptance Test Driven Development (ATTD). They also explore BDD’s Given-When-Then technique, the creation of data tables, and the use of Tom Gilb’s Planguage for specifying testable quality attributes.

It’s the Goal, Not the Role

From a skills perspective, business analysis and testing complement each other – they require attention to detail and emphasize consistency, completeness and correctness. And both share a furious focus on delivering value—not only a high-quality product but also the right product. The right product is a subtle concept. It’s the product that actually address users’ problems or opportunities—as opposed to the product users may think they want at first blush.

The Product Owner (in Scrum vernacular) brings deep domain and product knowledge that guides the delivery team in deciding what to build and when to build it. Product Owners work together with the team to explore and evaluate proposed product options, and that’s business analysis work. It is best done collaboratively with the whole team. The selected product options become requirements to be developed, tested, and deployed. (By the way, in the book I am writing with Mary Gorman, we explain these practices in detail; please stay tuned for summer publication of our book.)

Key analysis skills include analysis modeling, elicitation, longer-range business planning, and techniques for looking at product options (a.k.a. requirements) in a holistic manner. The entire team needs to explore and evaluate product options including the users, actions, data, rules, interfaces, quality attributes, and development & operational environment—what Mary and I call the 7 Product Dimensions.

There’s a different, but related, type of evaluation that testing provides.  Because it is usually not possible to completely test every conceivable scenario that may occur, its necessary to identify the optimum subset of tests—out of all possible tests—to be defined and executed. This requires skills such as peeling open a product to uncover flaws, knowing smart ways to sequence verification activities, and taking the “what can possibly go wrong?” angle.

All these strengths build on each other. And the team needs all these skills in order to deliver a valued product.

It’s the Goal, Not the Role

Some people may be fearful of “role infringement.”  Testers and developers participating in requirements exploration; analysts helping with testing.  My experience has been just the opposite. In the best of situations, everyone acts as a partner, building a shared understanding of product needs.

In our practice at EBG, we focus on helping people learn to collaborate in the best possible ways—to appreciate and maximize their diverse skills and knowledge and to converge on a shared understanding of product options.

When we do occasionally notice role confusion, we surface that right away. If needed, we help the team conduct chartering activities to clarify and match up their skills and knowledge. We help them directly and transparently discuss their constraints, needs, and preferences. This is essentially social contracting.

In sum, “it’s the goal, not the role” (see, “It’s the Goal, Not the Role” ).

References and Readings:

• Adzic, Gojko.  Specification by Example: How successful Teams Deliver the Right Software. Manning Publications, 2011.
• Crispin, Lisa and Janet Gregory. Agile Testing: A Practical Guide for Testers and Agile Teams. Addison-Wesley, 2009.
• Cunningham, Ward and Rick Mugridge, Fit for Developing Software: Framework for Integrated Tests, Prentice Hall, 2005.
• Gottesdiener, Ellen and Mary Gorman. “It’s the Goal, Not the Role: The Value of Business Analysis in Scrum “, StickyMinds, (June 28, 2011)
• Gottesdiener, Ellen and Mary Gorman. “Slicing Requirement for Success”, Better Software, Feature (August, 2010).
• Gottesdiener, Ellen. “Agile Business Analysis in Flow: The Work of the Agile Analyst (Part 2)”, Modern Analyst, 2009.
• Hendrickson, Elisabeth. Driving Development with Tests: ATDD and TDD,
• Pugh, Ken. Lean-Agile Acceptance Test-Driven Development: Better Software Through Collaboration.  Addison-Wesley, 2011.
• North, Dan, Introducing BDD

Over the past few years, I’ve spoken to user groups to share my experiences working with use cases, scenarios, and user acceptance tests in support of data warehousing and Business Intelligence (BI) BI analysis. Afterwards, many people ask me to summarize my recommendations. In response, I wrote a short article – Requirements Tips for Data Centric Projects. You can access it here (note: you may have to register).

In my article, I focus on analyzing the context of usage. In addition, remember this: to elicit, analyze, and specify requirements in this space, almost all of the time-tested data-centric techniques are still necessary.

People often asked me for additional tips and advice. What additional considerations for business analysis for BI?

Considerations for Business analysis for Business intelligence

Of all of those time-tested data-centric techniques, here are the ones I think are most important for this work:

1. You often need to perform data modeling (Entity-Relationship, Star Schema or both). To do this, be sure you have a sound grounding in these techniques.

2.  Your project may entail moving data to a warehouse or other data target. If so, you need to identify data sources and targets. Map your data sources to targets. Remember to conduct data sampling and use the samples to assess the quality or “cleanliness” of your data sources. Your analysis will likely include data cleansing, which requires a lot of detective work to hunt down the source of truth and structural business rules so your target data is correct.

3.  When your data will be delivered end users, be sure to analyze report content (e.g. select, sort, subtotal) and report presentation (i.e., how info will appear on a report or UI).

4. Specify quantitative information about your data. Specifically: volumes, percent growth, and which data records are likely to be accessed concurrently.

What about the International Institute of Business Analysis (IIBA) BABOK®?

The BABOK provides high level guidance on analysis for data warehousing. The BABOK includes the data techniques of Data Dictionary, Glossary, and Data Modeling.  Data mapping is mentioned as part of defining transition requirements.

Find in-depth information on analysis techniques for Data Warehousing in the DAMA (Data Management Association) Data Management Body of Knowledge (DAMA DMBOK)

I also recommend writings by Bill Inmon, Claudia Imhoff, Shaku Atre, Ralph Kimball and, for an Agile Perspective, Ken Collier’s recent book on Agile Analytics.

References:

• Brennan, Kevin. A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide), International Institute of Business Analysis, 2009.
• Collier, Ken. Agile Analytics: A Value-Driven Approach to Business Intelligence and Data Warehousing (Agile Software Development Series), Addison-Wesley Professional, 2011.
• DAMA International. The DAMA Guide to the Data Management Body of Knowledge (DAMA-DMBOK), Technics Publications, LLC, 2010.

Jennifer begins her article with the following: “With the proliferation of online articles and ebooks, old-fashioned paper books seem not to have a place in today’s world. Many experts, however, still find useful things in paperbacks and hardcovers. From technology to people and team management, these books still help developers out today. Here are what the experts recommend.”

Following are my recommendations – along with a few that didn’t make the article.

Category: Management and Career Development Books

Becoming a Technical Leader: An Organic Problem-Solving Approach

By Gerald M. Weinberg

This book was first published in 1986 and it’s still relevant today. Weinberg was the first person to write about the human side of software engineering, and I think of him as the Yoda of software development. His advice on leading software projects boils down to this: stay out of your own way, and know yourself.
— Ellen Gottesdiener, founder of agile consultancy EBG Consulting

Category: Software Methodology Books

Leading Lean Software Development: Results Are not the Point

By Mary Poppendieck and Tom Poppendieck

Leading Lean Software Development addresses one of the key issues that software development teams following the Scrum methodology tend to struggle with: how to focus on the larger organization, not just the team itself.

The Art of Agile Development

By James Shore and Shane Warden

This hands-on book deals with project management issues and offers a wealth of practical advice, particularly around test-driven development.

The ones that didn’t make the SD Times list

Food Rules: An Eater’s Manual

By Michael Pollan

Why?  Because of its elegant simplicity. 64  Rules. One rule per page, with a simple image on the opposite page. Gorgeously concise. Like software should be.

The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity

By Alan Cooper

This seminal book by the father of personas reminds us to understand the product from the outside-in. Not that we should ignore the inside-out, but it starts with the customer.

References:

deJon Lent, Jennifer. “The Best Books for Software Developers”, SD Times, December 15, 2011.

Sue Burk distinguishes between security requirements and security controls, shares four categories of security requirements, provides suggestions for eliciting security requirements, and explains why making them testable is important in her expert response.

References:

* The Software Requirements Memory Jogger

The presentation, entitled, Power Up Your Agile Planning and Analysis: Deliver Value via Structured Conversations describes how product stakeholders partner to develop a shared understanding of the product needs. I discuss how the partners gain a focused yet holistic understanding of the highest-value requirements and plan the project so that the delivery team builds the right product, at the right time.

In the podcast, I discuss with Joe the metaphor that Mary Gorman and I have been using, “structured conversations.” Structured conversations are used to explore and evaluate product requirements and clearly identify what to build and when to build it. These conversations fuel daily work on agile/lean product teams, enable them to populate and groom their product backlog, and to quickly analyze requirements so requirements can be allocated them to delivery cycles. These practices are described in the book Mary and I are in the midst of writing.

I hope you find the podcast interesting!

Resources that extend the concepts and practices I presented at Agile NYC on 18 October 2011:    

• Podcast with Agile NYC founder Jochen (Joe) Krebs – recorded just before my presentation
• Agile Planning and Analysis – Synergizing to Deliver Value Better Software, May/June 2011 [note*]
• Slicing Requirements for Agile Success Better Software (feature), August 2010[note]
• It’s the Goal, Not the Role: The Value of Business Analysis in Scrum StickyMinds.com, June 2011
• Harvesting Stakeholder Perspectives to Organize Your Backlog StickyMinds.com, January 2011

[note*]

You’ll find the slicing narrative tracks to what I shared in my presentation. Since Mary Gorman and I wrote the article last year, we have adjusted our use of some terms.  You can equate:

Article term = Training term

Expand-Then-Contract = Explore and Evaluate

Element = Dimension

Object = Data Dimension

Business Rule = Control Dimension

*Joe Krebs books:

Agile Portfolio Management, Microsoft Press, 2008

IBM Rational Unified Process Reference and Certification Guide: Solution Designer (RUP)

The ingredients are:

Ingredients about the People

• The Right People
• Wise Groups
• Trust

Ingredients about the Collaborative Process

• A Shared Purpose
• Shared Space
• Focus Questions
• Serious Play
• Process Variety
• Flexible Structure
• Frequent Debriefs
• Collaborative Closure

Ingredients about the Products

• Pre-Work
• Doneness Tests
• Using Both Sides of the Brain

As I listen to our discussion in this podcast about these ingredients, I am reminded that these ingredients are core to great teams (not just great workshops). Why? Because these ingredients engineer and sustain good collaboration.

Collaboration works. Good collaboration results in people who do quality work, delivered to agreed upon acceptance criteria. As I discuss in the podcast, trust saves time. Visualization enables shared understanding. Transparent decision rules and process are efficient. Teams that slow down to reflect on their products and processes improve, continually.

Requirements by Collaboration was published in 2002; the year after the Agile Manifesto was published. I had by then a few years working with agile teams (at the time, we referred to it more as iterative development). Back then and still today, one of my coaching responsibilities is to help agile teams collaborate effectively. Good facilitation practices are essential for agile (and really all!) teams. I draw on these ingredients constantly as a coach.

In the book, I wrote about “doneness tests.” This same expression (“done” or “doneness tests”) is now commonly discussed in the agile community. In the context of having people collaborating in a facilitated workshop, I wrote that you need to “establish a set of criteria…to judge whether each deliverables is complete, clear, and correct enough to be acceptable” (page 58).

This same ingredient is crucial to continual flow of business value on agile team. When we at EBG Consulting coach agile teams and are facilitating product backlog grooming or agile planning workshops, we facilitate processes so the team defines unambiguous acceptance criteria for each requirement (often in the form of user stories). We also use “doneness tests”—acceptance criteria—for Big-View, Pre-View, and Now-View plans. We teach these practices in our collaboration for agile teams training.

I hope you’ll find the podcast useful.

What ingredients for good collaboration would you add or amend to my list above?

Resources:

• Assets from Requirements by Collaboration
• Amplifying Collaboration with Guerilla Facilitation
• Three types of trust I mention in the podcast (contractual, communication, competency) originate with the Reinas. I highly recommend their book:
  Trust & Betrayal in the Workplace: Building Effective Relationships in Your Organization, Second edition by Dennis Reina and Michelle Reina

This year’s conference, held August 9-12 2011, was attended by 1,600+ people. It was jam-packed with morning-to-night activities. The conference also included events to reflect and celebrate on the 10th anniversary of the Agile Manifesto.

We at EBG Consulting were pleased to have been selected (from over 900 submissions) to present three sessions.

Here are some of highlights and trends:

• Agile Requirements/Agile Business Analysis Time has Come: There was much interest in this topic. The half day workshop Mary Gorman and I presented on slicing agile requirements entitled “The Product Partnership: Structured Conversations for Delivering Value” was well attended and highly evaluated. It was generally acknowledged that even when agile teams finely tune and execute core development practices, they often hit the proverbial wall – deciding precisely what to build (the hardest part of software development, to paraphrase Frederick Brooks). That’s exactly where agile business analysis can play a vital role!

• Value of the Tester Mindset: Growing practices in the testing community using examples and scenarios. This is tightly aligned with what we at EBG Consulting have been doing; in fact, I co-presented a workshop “Requirements Exploration with Tester Collaboration” with Janet Gregory, co-author of Agile Testing.

• Business Rules Rule: The testing community and business analysis community are starting to collaborate on specifying and validating business rules. Mary Gorman led an open space session at the pre-conference Agile Testing day on business rules, examples and tests and had a lot of agile testing thought leaders thinking in new ways about this! Mary also presented a conference session entitled “Business Rules Essentials for Quality Software.”

• Pull Production and Customer Support Forward: there is growing interest in the round-trip engineering by pulling production support forward by releasing the product frequently, putting the release into the hands of the customer. This is enabled when teams practice continuous integration—frequent integration of code verified with automated tests—and take it a step forward with continuous delivery.

• Numerous good sessions on large-scale/enterprise adaption (and organizational change management implications)

• Integrate Lean Startup Practices: Growing emphasis on integrating lean start-up ideas on agile projects, especially the need to identify you are solving a real problem for the right customers e.g. Customer Discovery) and then validate that you can sell your product to that target customer (e.g., Customer Validation). Throughout, you do this using very short delivery cycles).

• Kanban has Charisma: More and more teams are adapting kanban (flow vs time-boxed) agile practices, or combining scrum with kanban. (An aside: several of our new clients are using kanban.) These client experiences further testify to the value of EBG’s agile requirements slicing practices for ‘pull’ as well as time-boxed delivery models.

Resources:

• On continuous delivery:
• Continuous Delivery: Reliable Software Releases through Build, Test and Deployment Automation by David Farley and Jez Humble
• Selected online readings on continuous delivery:
• Jez Humble’s blog
• Deployment pipeline (chapter from Continuous Delivery book)
• On lean start-ups:
• Four Steps to the Epiphany: Successful Strategies for Product that Win by Steven Gary Blank
• The Entrepreneur’s Guide to Customer Development by Brant Cooper and Patrick Vlaskovits
• Selected online readings on Customer Discovery and Validation:
• Steven Blank’s blog
• Eric Reis’ blog
• Ash Maurya’s blog
• Applying the lean startup model to the enterprise (Jez Humble slides)

Yamo’s interview got me thinking and reflecting on my own professional learning journey and dig into the two books I’ve written (so far ).

Writing a book is a daunting task. It is a learning journey in and of itself. When I began my first book, Requirements by Collaboration, I had no idea how much I’d learn from the writing process.

Listening to this portion of the author cast reminded me how grateful I am to all the mentors—accidental and intentional—I have learned from. And, those I continue to learn from.

One of my first mentors, Donna Dean, started a Quality Circle in our analyst/programmer group and entrusted me with a leadership role. That was 1981. It was my first exposure to lean, kaizen, and TPS. Donna was ahead of her time, in many ways. I am grateful to her.

How is your learning journey going? How do you learn and grow?

I believe that there is a lot of cross-fertilization benefit to be gained when people with skills in different disciplines collaborate closely toward shared ends. This is very true for the disciplines of testing and business analysis. The tester mind-set is crucial for verifying requirements. The business analysis mind-set is crucial for validating requirements.

By incorporating analysis practices into the testing discipline and testing practices into analysis, we collapse the traditional “V” model of verification and validation. This enables development teams to more efficiently and effectively identify the right requirements, and get the requirements right.

Agile practices, when done well, focus on delivering value and provide the freedom for the team to collaborate toward that shared end. As Mary Gorman and I have been saying, “it’s the goal, not the role.” By that, we mean that teams need to focus on delivering value each and every day, and not on who does what.

I hope you can join us for one of these events.

Resources:

• Acceptance Testing: Elicit and Validate Requirements for Success
• “Slicing Requirements for Agile Success“
• “It’s the Role, Not the Goal: The Value of Business Analysis in Scrum“
• Specification by Example