Archive for the ‘roles and responsibilities’ Category

Rope Your Scope: Reining in Scope Creep (Part II)

Wednesday, June 19th, 2013

Slide1Last time, I told the story of a team that experienced a breakthrough after clarifying the scope of a stalled project. Noting that scope creep—the unrestrained expansion of requirements as the project proceeds—is cited as one of the top project risks, I promised to describe some of the good practices that help product partners manage product scope in a disciplined way. With clients, I always stress the importance of developing a product vision, identifying goals and objectives for the product, and clarifying the product partners’ value considerations very early in the project before development proceeds. Let’s look at ways to do that. Continue reading | 1 Comment

Rope Your Scope: Reining in Scope Creep (Part I)

Thursday, May 9th, 2013

scope creep image 2- contextRecently I worked with a project team developing a software product under grant from four entities, with a government agency as their ultimate customer. They called me in because, three months into a four-month project, they were desperately behind. Why? They’d been spinning in circles, trying to satisfy diverse stakeholders who had overlapping as well as conflicting requirements. The funding was split among several competitors, each with its own competencies, and there was a sense that the government agency was playing favorites based on its own preferences in the domain. Continue reading

Cure Your Agile Planning and Analysis Blues: The Top 9 Pain Points

Tuesday, March 5th, 2013

frazzledproductchampionIf you’re on a team that’s transitioning to lean/agile, have you experienced troubling truths, baffling barriers, and veritable vexations around planning and analysis? We work with many lean/agile teams, and we’ve noted certain recurring planning and analysis pain points.

Mary Gorman and I shared our top observations in a recent webinar. Our hostess, Maureen McVey, IIBA’s Head of Learning and Development, prompted us to begin by sharing why we wrote the book Discover to Deliver: Agile Product Planning and Analysis and then explaining the essential practices you can learn by reading the book. Continue reading | 2 Comments

Agile Analysis, Agile Testing: Synergies for Successful Software Solutions

Friday, March 16th, 2012

My experiences working with agile teams have taught me that agile analysis and testing skills 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

Best Books for Software Developers

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

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

Agile Requirements: Not an Oxymoron

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

Opening Space for Passion, Energy, and Learning Part II

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