To quote Seth Godin (What to do with your ideas for other people),
“Selling ideas is a fundamentally different business than having ideas.”
“The quality of ideas is not a factor in whether or not you will be in a position to have a chance to sell those ideas.”
Seth Godin was speaking to the supply side of the idea market. What about the demand side? Where do you find great ideas?
If you wait for ideas to get your attention, the ideas you hear will be those of people and organizations that are good at selling. This is true within your organization as well as with vendors. If you’re lucky, those idea sellers will have teamed up with some idea havers, but even then, the ideas will have been run through the “will it sell” (at a profit) filter.
If you need great ideas, hang out where the great-idea-havers are, or team up with someone who does. If Seth Godin is right, there are some real bargains out there.
In his Practical Agility blog entry Embedded Collaboration, Dave Rooney tells you how to know if business and IT are really collaborating, and not just having meetings.
What’s required is Embedded Collaboration. There is no functional separation of business and IT on a project—they are living and working together, breathing the same air, meeting at the same water coolers.
How value, and business-IT collaboration, change for different types of “IT.” Software-Intensive Businesses are those with Differentiating Apps (bright red point of the pyramid).
This is especially important for application development projects—those at the point of the pyramid—in your software-intensive business.
If your programmers aren’t working, day to day, in the spaces where the sponsors and users work, day to day, why not? I’m sure there’s a reason. How much more value would you have to be getting for your software dollar to trump that reason?
Modern software development processes are moving away from legal-document-style “the system shall” requirements to less formal User Stories. Further, software users and buyers are encouraged to write user stories themselves. If they’re used to being interviewed by a business analyst and then being handed requirements to review, this can rattle them at first.
I often have to show them what I mean by User Stories, and I use a template I think I got from Mike Cohn’s User Stories Applied (It’s a great book, even if it’s not where I got the template):
As a ______, I can ________ so that ________.
As a telemarketer, I can see the customer’s last three orders, including returns, so that I don’t offer them what they already have, or worse yet, what they bought and sent back.
But I’ve also done enough requirements workshop facilitation to know that when you ask a different way, you get a different (and often valuable) perspective that would have otherwise gone missed. Not the end of the world on a well-run agile project, but it’s still beneficial to get as many of the stories as you can to start with.
To really get subject-matter experts thinking business and not systems, I’m starting to use this variant:
As a ________, when ________, I can ___________ so that ____________.
If you first have the group create a list of business events, you can use those to drive another round of story writing. Suppose we identify an event “my shift ends.” That might remind people of another story:
As a telemarketer, when my shift ends, I can review my call statistics and add notes for my supervisor, so s/he knows about any extenuating circumstances I encountered, and I still get the credit I should.
The next time you’re helping people get started with user stories, try the event-driven variant. You and they may both like it. And check out this other template for non-functional requirements.