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]

Related posts

• the Spike (0)
• one-step deployment (2)
• life as product owner (0)
• launching a beta (0)
• Atlassian Jira and Confluence (0)

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]

Related posts

• the Spike (0)
• Scrum II (0)
• one-step deployment (2)
• launching a beta (0)
• Atlassian Jira and Confluence (0)

one-step deployment has been a goal of ours for a long time. Our determination is renewed by the workshop last week. Cal shared with us a screenshot of the Flickr deployment interface which involves two buttons on an HTML page that deploy the current codebase to staging and/or production.

But, as I posed the question in my previous article, we have a bit of distance to cover.

1. put more and more emphasis on the quality of code checked into the repository. We get lots of mileage out of code reviews and unit tests, but we need developers to seek out other developers, our support team, and the rest of the company to test features and/or changes that are particularly important (arguably this is easier if deployment is easier).
2. continue to move our development process to be more agile to handle the evolution of requirements, needs identified by progress, and necessary optimization shown by customer use.
3. finally, make deployment a one-step process. Make the web servers less tied to a given backend. Ensure the process works seamlessly and quickly (and atomically).

Database changes don’t fit well with the one-step deployment. These still need to be made manually, but still get tracked in source-control.

Every day we move further in this direction.

[tags]agile development, deployment, quality assurance[/tags]

Related posts

• Scrum II (0)
• life as product owner (0)