Posts Tagged ‘agile team’

Collaboration Works: Ingredients for Successful Workshops

Wednesday, October 26th, 2011

I’m honored to share my podcast with Yaaqub (Yamo) Mohamed of The BACoach. We discuss ingredients for effective requirements workshops described in my first book, Requirements by Collaboration: Workshops for Defining Needs.

Share

Agile Requirements Exploration with Tester Collaboration

Thursday, July 14th, 2011

I’m thrilled to be collaborating with Janet Gregory, co-author with Lisa Crispin of Agile Testing, on a workshop entitled “Agile Requirements Exploration with Tester Collaboration” at Agile 2011 Conference and STARWEST.

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. Continue reading | 1 Comment

Share

The Product Partnership: Using Structured Conversations to Deliver Value

Saturday, May 14th, 2011

In a prior blog post, you learned about the in-progress book Mary Gorman and I are writing. We are thrilled to have our workshop proposal for the Agile 2011 Conference accepted. The workshop will incorporates elements of our book. Here’s our YouTube video on The Product Partnership submission. Continue reading | 1 Comment

Share

Are Your Software Development Practices Jumping the Shark?

Thursday, April 7th, 2011

By Ellen Gottesdiener and Mary Gorman

In September 1977, the TV sitcom Happy Days had über-hip Fonzie, clad in leather jacket and swimshorts, water ski over a shark to prove his mettle—and at that moment even diehard fans knew that the show was past its prime. They were right. After that episode, ratings plummeted, and the expression “Jumping the Shark” was born. When a TV show, or anything else, jumps the shark, you know it’s on its way out.

Our question this month: have any of your software development practices jumped the shark?

For example, are there boundaries around people’s roles? Some organizations tend to confine people to roles such as developer, architect… Continue reading

Share

Agile Product Needs book: Sneak Peek

Wednesday, February 16th, 2011

Mary Gorman and I are in the midst of writing a book.  The title is still a WIP (work in process). A couple of contenders are “Agile Product Needs: <subtitle1:> ” and “The Agile Product Partnership: <subtitle2>”.  We’ll be looking for your help on settling on a compelling title – stay tuned, we can use your creative inspiration!

Our goal is to provide practical guidance on challenges agile teams face. Wrestling the “right” user stories out of the product backlog. Slicing user stories into “right-sized” chunks so they are ready for estimating and planning. Deciding on the next high-value product needs for delivery. Planning more than two weeks ahead (realizing you need a longer time horizon). Using acceptance criteria and examples to deepen shared understanding. Exploring product needs in a holistic way. … Continue reading | 3 Comments

Share

Analysis Debt, Redux

Saturday, December 4th, 2010

Mary Gorman and I wrote an article on analysis debt Better Software. In it, we said that, like technical debt, teams can incur analysis debt by either ignoring analysis (a potential pitfall of agile teams) or overinvesting in analysis (a potential pitfall of traditional teams).

In a private exchange, one article reader took me to task. Referencing our table of Analysis Debt Causes, he wrote, “I see poor requirements work that would result in an inadequate solution, no matter how well [the product] built.” Furthermore, he said, “all the Remedies [in your article] are really requirements best practices.”

I was glad to hear his perspective because it prompted me to… Continue reading

Share

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

Wednesday, February 24th, 2010

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. Continue reading | 2 Comments

Share