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?”
My experiences working with agile teams have taught me that agile analysis and testing ski
lls are truly synergestic.
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 Software Testing Analysis & Review (STAR) conferences. So, you might be wondering, what are those synergies?
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. 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.
By Guest Blogger Rob Elbourn, Scrum Team Lead working at a major financial concern in UK. Visit Rob’s Agile78 Blog
I recently attended the “Agile Requirements by Collaboration” presentation at Skills Matter lead by Ellen Gottesdiener from EBG Consulting. Here are some of the main points I got from it.
Ellen described how collaboration needs to happen on several different levels of granularity along the way requirements are viewed on agile projects– the product (which establishes the product or portfolio roadmap), the release and the iteration (or work-in-progress).
Exploring these views can occur in several different facilitated workshops, from the roadmap workshop, to the release workshop to iteration workshops. The corresponding requirements that are clarified or driven out from these workshops also appear on different levels – boulder, rock and pebble.
The idea is that the pebbles form your user stories and are driven out at the level of the iteration workshop. Projects can encounter rock sized requirements at the iteration level and suffer a time delay as new pebble requirements are chipped off from them. This brings to question the level of “doneness” for a user story. Continue reading
“Oh drat”, you think.
“I’ve got to do a presentation!”
Nevertheless, you smile and ask, “Oh, sure—what’s the date?”
Presentation Skills for Technical Professionals to the rescue!
Out comes Naomi’s Karten’s splendid book. You open it, eager for your sit-down with your personal presentation skills coach. You are easily captivated by Naomi’s clever style and practical guidance on presentations, and grateful for the online references and resources that supplement the text. Reading this book not only prepares you for your upcoming presentation; it also helps you get in the groove and enables you to gain confidence as you prepare. You actually enjoy the process!
I was flattered when… Continue reading
By Mary Gorman
In my Stickyminds.com column “Playing at Work: Agile Games Deliver Value” I share game ideas and experiences – the benefits games can provide, selecting an appropriate game, facilitating a game, and designing a winning game.
Designing and Facilitating Agile GamesWhen writing the column I got to thinking how agile principles could provide a basis for good game design and facilitation. I reflected on a recent experience I had at Deep Agile 2010: Empowering Teams with Agile Games. Working in a small group we created a new game, tested it, and retrospected both the game and our design process in less than half a day. We consciously (and some times unconsciously!) were being agile! (To see and learn more about our game, read Michael Sahota’s summary at The Backlog Is in the Eye of the Beholder.)
To clearly communicate the agile-ness of our work and what we learned I did a quick mapping to the Manifesto for Agile Software Development. 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
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 BeforeTwo 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. Continue reading | 1 Comment
Founder and president of EBG Consulting.
Author, trainer, mentor, agile coach, facilitator,
conference advisor,
Certified Professional Facilitator,
Certified Scrum Master
