Last weekend the company had a second Broadwick Day and discussed all sorts of desires for employee communication . . . → Read More: Scrum II]]> Scrum as much indicates the participation of the development team(s) as it does the involvement and commitment of the ‘everyone else’. Everyone must submit innovative controversial ideas, give honest feedback, and be willing to accept success.

Last weekend the company had a second Broadwick Day and discussed all sorts of desires for employee communication and involvement in the product. The opportunity is here, and in the past week we’ve bridge the gap with some education to let everyone know about their role in Scrum.

In addition, we’ve added the role of a Story Advocate who represents a given feature during development. This provides the developers a go-to person so they don’t feel lost in the sea of people who might care about a given story. In addition, we’ve created a few mailing lists for trading ideas related to user-stories. If today’s Sprint Review is any indication, I’m looking forward to far greater involvement in the development process by any and all in the company.

The development teams also met today to re-commit to reliability as the chief deliverable. A distant second is the features which are no good, and don’t Simply Email Marketing unless they work well, all the time.
[tags]scrum, agile development, broadwick[/tags]

Almost a month ago, my development manager started reading about . . . → Read More: life as product owner]]> Until recently, the decisions about what features to implement next were not always centralized. In general, the future investment and large-scale features were decided by my CEO while anything else people wanted implemented was fixed based on a ‘squeaky wheel gets the grease’ mentality.

Almost a month ago, my development manager started reading about Scrum. The Scrum development model has a number of really neat features that I won’t attempt to summarize here with the exception of the Product Owner role. Instead of the developers listening to the ‘squeaky wheels,’ the Product Owner serves as the broker in between. All of the company are encouraged to bring User Stories to the Product Owner that they’d like impelmented. The Product Owner then prioritizes these stories based on the information they have and seek out additional information to make informed decisions.

In this new role, I’ve begun to pick up new methods of teasing details out of those who need the software to do things it currently does not. I’ve gotten better at helping people realize what they need from the software, and prioritizing the needs of people here at the office, the customers, and the systems needs (typically represented by the developers and the systems team).

We’ve tried to make certain that the way in which people describe their features leads to a solution to their ultimate problem. For example, a story that indicates “make feature that can do X” might be too specific and doesn’t enough embody the goal as a story resembling “User Y can solve problem Y by doing A,B,C.” The latter specifies the goal to ensure the development team is on the same page and isn’t limited to the precise implementation discussed by the suggestor.

Considering each new feature in terms of it’s potential for revenue generation and customer retention sounds straight-forward but these are often many layers in betwen. For example, something that frustrates the support department probably also frustrates the customers. By applying effort to such a feature we can help the customers understand. Consequently, we can also help our support department dedicate their resources and energy to other customers.

The most suprising part of all of this has been the lack of resistance to this shift from the business. In fact, suggestions for features are coming in at a rate far exceeding that of the past. There’s been little/no quibbling over what is most important and why.

[tags]scrum, agile development[/tags]