Archive for the ‘roles and responsibilities’ Category
Friday, March 16th, 2012
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?
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. Continue reading
Tags: Agile, Agile analysis, Agile BA, Agile Business Analysis, Agile Business Analyst, agile requirements, Agile tester, Agile testing, ATDD, BDD, Business Value, collaboration, Facilitation, leadership, Planguage, Product Owner, requirements, Specification by Example, Tester Mindset
Posted in Agile, Agile Business Analysis, Agile Business Analyst, agile requirements, Agile tester, Agile Testing, Books, Business Analysis, Business Analyst, collaboration, ellen gottesdiener, mary gorman, Product Owner, requirements, roles and responsibilities, Scenarios, Specification by Example, Sue Burk | No Comments »
Tuesday, January 10th, 2012
This winter, SD Times editor Jennifer deJong Lent asked me to contribute an SD Times article on recommended books for developers. Jennifer and I agreed my list would exclude books about languages, databases or IDEs. I was pleased to contribute.
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.” Continue reading
Tags: Agile, BABOK, Books, leadership, Personal Development
Posted in Agile, Books, Career, Communication Skills, ellen gottesdiener, Learning, roles and responsibilities, SD Times, Software Development, Writing | No Comments »
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
Tags: Agile, agile team, Business Value, Documentation, leadership, product needs, Product Partnership, Product stakeholders, requirements, retrospectives, Stakeholders
Posted in Agile, Agile Business Analysis, Agile Business Analysis Flow, Agile Business Analyst, agile games, agile manifesto, Business Analysis, Business Value, collaboration, Communication Skills, Documentation, ellen gottesdiener, heavyweight team, leadership, lean, mary gorman, Product Partnership, requirements, retrospectives, roles and responsibilities, Stakeholders, Waste | No Comments »
Friday, June 18th, 2010
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. Continue reading | 1 Comment
Tags: Agile, Agile Planning, agile requirements, Analysis, Business Analysis Training, Business Value, collaboration, Dependencies, Facilitation, requirements, roles and responsibilities
Posted in Agile, Agile Business Analysis, Agile Planning, agile requirements, Agile Workshops, Business Analysis, Business Analysis Training, Business Value, collaboration, Facilitation, requirements, roles and responsibilities, Workshops | 1 Comment »
Friday, May 14th, 2010
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. Continue reading
Tags: Agile, agile games, Business Analysis Training, Deep Agile, Deep Agile Games, Facilitation, Learning, Open Space, OST, retrospective, roles and responsibilities
Posted in Agile, Agile Business Analysis, agile games, Business Analysis, Business Analysis Training, Deep Agile, Deep Agile Games, Facilitation, Learning, Open Space, OST, retrospectives, roles and responsibilities | No Comments »
