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?”
I’m pleased to share my podcast with Jochen (Joe) Krebs*, Founder of Agile NYC. The podcast was recorded on October 11, 2011, just before my presentation to the Agile NYC group.
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. Continue reading
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.
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
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
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
b
y Mary Gorman and Ellen Gottesdiener
We liked it when a good thing took on a life of its own.
We learned that it really resonated with many folks.
We lacked sharing the full understanding of the technique.
We longed for more sharing.
Liked – Learned – Lacked – Longed For
At the recent Deep Agile event, Mary briefly mentioned a 3Ls’ technique she used in a recent retrospective (Liked, Lacked, Longed For). A few folks tweeted about it, and it took off in the web’o’sphere
To fulfill our longing to share and provide some background, keep reading to learn how we use this technique.
Many moons ago… Continue reading | 8 Comments
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?
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. Continue reading | 1 Comment
Founder and president of EBG Consulting.
Author, trainer, mentor, agile coach, facilitator,
conference advisor,
Certified Professional Facilitator,
Certified Scrum Master
