Agile analysis Archives - Page 7 of 7 - EBG Consulting

Agile Requirements: Not an Oxymoron

Adult children. Jumbo shrimp. Seriously funny. I’m sure you recognize these expressions as oxymorons—self-contradictory phrases, often with an ironic meaning.

Should we add “agile requirements” to the list? Does agile development fit in with traditional requirements practices? And if so, how?

Once More into the Breach

Traditionally, defining requirements involves careful analysis and documentation and checking and rechecking for understanding. It’s a disciplined approach backed by documentation, including models and specifications. For many organizations, this means weeks or months of analysis, minimal cross-team collaboration, and reams of documentation.

In contrast, agile practices—leanLean, Sscrum, XP, FDD, crystalCrystal, and so on—involve understanding small slices of requirements and developing them with an eye toward using tests as truth. You confirm customers’ needs by showing them delivered snippets of software.

Opening Space for Passion, Energy, and Learning Part II

Last time, I introduced Open Space, an innovative approach to creating change in whole systems and inspiring the best in human performance. Also called Open Space Technology (OST), Open Space was created by Harrison Owen in the 1980s. It’s a self-organizing practice that encourages people to exchange information and ideas in informal settings.

How Does It Work?

To start, Open Space participants gather in a dynamic opening event in what we call the marketplace. Anyone can offer topics they care about, want to reflect on, and learn about with others. You don’t have to be an expert, guru, or even highly experienced or knowledgeable about the topic you convene. During the marketplace, participants create a board that lists all the session topics people want to talk about, with time slots and locations for each proposed topic.

Then each participant directs her own choices. Groups convene sessions around these topics and record their findings.

Open Space operates on four principles:

1. Whoever comes is the right people.

2. Whatever happens is the only thing that could have.

3. Whenever it starts is the right time.

4. When it is over it is over.

Opening Space for Passion, Energy, and Learning

Next week, I’ll have the honor of facilitating the Open Space at the Deep Agile 2010: Empowering Teams with Agile Games Conference May 15-16 in Boston.

If you haven’t heard much about Open Space, read on. I want to share my experiences and define this technique in detail.

My Open Space Journey

Imagine going to an “un” conference: it’s like other conferences, except that you determine the topics, interact with others who have passion, experience, and curiosity about the same topics, and cross-fertilize your knowledge by sharing with other highly engaged learners. If you’re bored, tired, or not getting value from any session, it’s OK to just walk away. Oh, and someone will record and share the findings, so you can get a flavor for any sessions you missed. That’s Open Space.

Wow.

Lessons on Distributed Volunteer Collaboration: Retrospective on Delivering the IIBA BABOK, Part 2

In my earlier post, I talked about a project I am working on: an all-volunteer effort to write an Agile-BABOK® extension (now we are officially calling it an “extension”, vs. an addendum).

I had suggested we learn from a similar effort—the development of the BABOK itself.

I figured the agile extension effort would be an ideal opportunity to document and leverage the lessons learned in conducting a project staffed by our geographically dispersed volunteers.

What works? What doesn’t? How can we adjust our practices based on our experience?

To learn about the BABOK development effort, I interviewed Mary Gorman, the person I consider the most knowledgeable about the BABOK (except for Kevin Brennan, IIBA’s VP, Body of Knowledge). (By the way, Mary’s BABOK Navigation tools are being freely provided to the business analysis community on our EBG Consulting web site.)

Lessons on Collaboration: Retrospective on Delivering the IIBA BABOK, Part 1

What are good practices for delivering a complex product for a broad global customer with a group of volunteers scattered all over the world?

This is a real-world question for me right now: I’ve volunteered to participate on the Agile-BABOK® (Business Analysis Body of Knowledge) addendum effort. Like the BABOK itself, this addendum can impact the practices of a broad worldwide community of professionals.

Learn From Those Who Have Been There Before

Two groups have tackled the problem of using volunteers to deliver an industry standard, so I figured we should “learn before we burn”. One group is the PMI Agile Community of Practice group, and the other is the BABOK Body of Knowledge Committee.

Ideally, learning what worked for these groups, along with their suggestions for what they would do differently were they to do this again, could help the Agile-BABOK addendum effort to start smart: leverage what they’ve found works, avoid or mitigate what didn’t work, and adjust their practices based on their experience.

How Agile is Influencing the Traditional Business Analyst Role Part 2

In my earlier post, How Agile is Influencing the Traditional Business Analyst Role: Part 1, I provided the first set of answers to questions posed to me by a Modern Analyst writer preparing a article on how Agile is impacting the traditional business analyst (BA) role.

Here I continue with the questions and my responses.

What are your thoughts? Do you agree?

In Scrum, do you think a Business Analyst could (or should) be the Product Owner, ScrumMaster, or a regular team member?

Yes, maybe, yes, maybe, yes maybe.

In Scrum, we have the product owner “role.” The PO is perhaps the most important (and burdened) role. The PO must conduct a mix of strategic and tactical activities.

Strategic activities are business or market facing—for example, analyzing the market and business case, defining the product vision and roadmap, developing requirements, adjusting the product backlog, and determining delivery plans.

Tactical activities are delivery team facing—for example, specifying the items to be delivered in each iteration, determining acceptance criteria for them, analyzing dependencies between items, and making tough decisions about what will be built to satisfy a given business need, technical risk, and requirements dependencies. Some great business analysts I’ve worked with pitch in to build and run user acceptance tests.

All this takes a lot of knowledge and many skills, and it consumes a lot of time.

On top of that, to fulfill both strategic and tactical activities on an agile project, the business customer needs experience in product development, along with deep domain and product knowledge.

I’ve coached (and trained) teams working on large, complex products, and I’ve seldom known a single business customer who can do these strategic and tactical activities.

That’s why many organizations turn to talented business analysts for help with the day-to-day, tactical decision making on their agile projects. In other cases, someone who was formerly a traditional business analyst will work out the backlog items, suggest the priorities, and then obtain validation from the business PO.

How Agile is Influencing the Traditional Business Analyst Role: Part 1

How is Agile influencing the traditional role of the Business Analyst? What will the future hold for people with business analysis skills? A Modern Analyst writer for an upcoming article posed these and other questions to me.

Because the final article will be an amalgamation of responses and not contain my full set of responses, I’m sharing them here with you, in two parts.

Let me know what your reactions are!

Since the term “Agile” is used in so many contexts, what does “Agile” mean to you?

I assume in this article you are focusing on agile practices for product development (and not “agile” as a marketing term—e.g., “we’re an agile business”). Recognizing that a product can be software, hardware, a complex hardware and software system, or business process change, I would turn to the Agile Manifesto and its underlying principles.

It is striking how humanistic and pragmatic the manifesto and its principles are: “individuals and interactions” and “customer collaboration” are valued along with “working software”; the twelve principles include responding the “changing requirements” and frequent delivery along with simplicity, technical excellence, self-organization, and reflection.

When you study the history of software engineering and software methods, you discover that many of the practices that fall under the “agile” umbrella are not new. We stand on the shoulders of those who have written, researched, and experimented with good practices. We should not forget our history.

Studying those practices and history is informative. The agile “movement” will fade, and the most useful agile practices will become mainstream. I think Alistair Cockburn was spot-on at the Agile 2009 conference, when he said his keynote was about “burying agile, not praising it”; that is, people aren’t arguing very much about agile. Most of the theoretical issues are settled. Now we’re focused on how to implement agile practices.

Remember when structured development methods, and then information engineering, and then object orientation were the hot topics and next silver bullet? Take object orientation: object technology is a common lingua franca for developers. It’s been assimilated.

The same thing will happen with agile. Iterative development, timeboxing, or kanban-like flow models for development (continuous integration, test-driven development, user-acceptance-driven development, or BDD, behavior-driven development)—all this will become common practice.

Even “classic” agile is changing. Some people are adapting lean practices, others are figuring out how to address agile/adaptive architecture, and the software craftsmanship movement is pushing for attention.

So, to sum up with the keywords that inform my work—the ones that pop into my head when I think about agile—I would name these: customer collaborative, business value, adaptive, self-reflection, incremental, and iterative.

Posts on Agile analysis