User>Driven

A colleague at work sent this send up of Scrum and other development methodologies of the moment. I couldn't resist sharing.

Recently I've been writing about issues arising as we explore Agile principles within the more traditional scheduling environment of ATG. As we talk about how to schedule sprints in a Scrum pilot project, we've been debating key principles and how they might apply to our projects. The latest is sprint length. Should the length of your sprint be fixed or should it flex in response to the size of the tasks in it?

It's second nature to the experienced program managers I work with to break projects into milestones, so the idea of breaking a project into sprints seems easy to adopt. According to what we've read, sprints are supposed to be a short (2-4 week) cycle of work kicked off when the team agrees on a list of tasks to be attempted and finished off with a review (usually a demo) of what's been completed.

We've been used to determining the milestone schedule according to the size of the tasks on our list, though. A related set of large, complex tasks should require a longer time frame than a single simpler task, right? Makes sense. Scrum says you ought to be able to break any task down into component tasks that would fit into a sprint, but why force different size tasks into an arbitrary schedule? Why try to demo something that's only half done? Is there any reason we couldn't have a sprint of 2 weeks followed by one of 4 and then one of 8 for a really big task?

I've heard a few reasons that sound credible and that we plan to test.

1. Accountability - Have you ever seen a feature stay at 90% complete for weeks with no apparent progress? Have you ever seen developers procrastinate on work with a long deadline? Rapid-fire deadlines force people to get things done efficiently for fear of looking bad at the demo.
   
2. Course corrections - There's always some gap between what product manager asks for and what the engineers deliver. Frequent reviews minimize that gap by bringing the two parties together regularly even when features aren't done. It's easier to make changes before the feature is done, tested and documented. And without the discipline of regular check-ins it would be easy to wait until back-tracking feels like more work than it's worth.
   
3. Rhythm - I've heard people experienced in Scrum say that a regular schedule puts them into a productive rhythm. It's like exercise, I gather - once you get to doing it regularly you begin to expect it. It's self-reinforcing. Developers look forward to the sprint reviews and to kicking off the next round.
   
4. Attaboys - Steve Johnson from Pragmatic Marketing mentioned this effect when he spoke at the BPMA recently. He likened it to the increased desire of a husband to tackle items on the "honey-do" list when he gets praise from his wife for doing them. The regular demos provide an opportunity not just for feedback on direction but for positive feedback. "Cool!" the product owner will say when they see something working (even partially), and cool the developer will feel hearing that. Will developers respond to that kind of thing. Are developers human? It's in our nature.

It's still under discussion but I'll push for fixed-length sprints, the shorter the better. It seems to me the chief value in Scrum is the visibility that frequent check-ins afford, facilitating accountability, course corrections, rhythm and morale-boosting attaboys. I'll let you all know how it goes as we dig in.

Next time I will try to write a bit about coordinating sprints and releases for an Agile project with the longer release cycle of an underlying platform.

As I mentioned previously, we are investigating Agile principles at ATG. We're doing a pilot with one project now and planning for another, larger one. I thought others might be interested in the issues we're working through as we experiment with Scrum. The first issue I want to cover is about just getting started.

Many of the problems we are grappling with seem to stem from trying to plan an Agile effort within a more traditional development organization. At my company, for example, projects can last for many months and doc and QA usually join a project already in progress and stay with a project after feature work is done. And unlike most developers, doc and QA folks (especially doc) are often split among several projects at once. So while some team members are ready to start daily scrums, it has been hard to include these disciplines. Our first pilot began scrumming with only the developers and a program manager turned scrum master. The doc person has since joined but is still splitting her time between two projects.

There is a general feeling of wanting to do Scrum "right" with this next pilot, so we've decided to wait until doc and QA can at least be part of the project kickoff where the team is supposed to review requirements and decide which features they can take on in the first sprint. Even then, commitments to other projects will mean the first few sprints in that project will have to consist of tasks not requiring doc or QA, things like tech spec writing and UI design.

At first I was uncertain about this approach. I thought one of the key principles of Scrum was that all disciplines were represented and that features were supposed to be really "done" at the end of a sprint - done as in shippable - which would, of course, require they be tested and documented. Some smart folks at Cyrus Innovation told us, though, that at least in their approach to Agile, it was more about commitments and checking progress on a regular basis than about "completing" features in each sprint.

What you put on your product backlog (the prioritized list of work for the team) doesn't have to be limited to features. The list can include anything the team needs to accomplish to meet the goals of the product. And that can begin with designs and specs. It can also begin with only part of the team represented, it seems, though we do plan to fold all disciplines in as soon as we can.

I'm still not sure how I feel about this, but it seems in resolving the tension between two principles, one sometimes has to take precendence over the other. I will revisit this issue as we move forward with the project and let you all know how we do. 

Next time I will try to talk about scheduling sprints and releases for an Agile project in a traditional organization. 

Barb Nelsen at Pragmatic Marketing writes on the politics of agile, outlining the frustrations many product managers feel when their development organization begins adopting agile methods.

While developers sprint through development cycles, one of three things happens to product managers. 1) They are ignored. 2) They are dragged deep into the development cycle. 3) They lead the team to build products people want to buy. The first two situations are lethal to a product manager’s career. The third alternative can lead to successful products and successful careers.

She says that "the problem seems to be that everyone is trying to wrestle control from the other" but I think the destabilizing effects of a move to agile on an organization just reveal long-standing tensions between developers who want certainty about what they are supposed to build and product managers who want flexibility to respond to changing market conditions.

In the end, she says that agile doesn't really change the product manager's role. They still need to "lead the team to build products people want to buy."

A key concept is that the product manager must become the market expert and the single voice of priority on the team. Rather than just reacting to the list of requirements submitted by everyone (customers, sales, support, development, executives), the market-driven product manager visits a representative set of people in the market (including non-customers) on an ongoing basis. He keeps the team focused on the targeted market segments, buyer and user personas, and problems worth solving. He conducts surveys periodically to quantify the inputs and a keeps a prioritized list of open problems to solve.

Go Barb!

I mentioned recently that we are exploring Agile development techniques at ATG. As we work through how to adapt these techniques to our organization and project realities, I thought it would be useful to jot down our experiences, issues and solutions, both so readers increase their understanding of what issues may come up with Agile, and also to solicit advice and ideas.

In this post, I thought I'd outline our current understanding of Scrum. Briefly, Scrum is an Agile software development methodology designed to produce higher-quality output that is more responsive to market needs. it is focused on constantly delivering value rather than on meeting a specific date with a pre-determined set of features. It is characterised by:

• Work periods called "sprints," usually of 2-4 weeks, wherein the team attempts to complete some segment of work such as a short list of product features.
• An agreed-upon definition of completeness for the work, such as that it is functional, tested, documented and otherwise "done" enough that it could be shipped to the customer as is if required. Usually this requires a demo of the work at a meeting called the "sprint review" at the end of the sprint.
  
• A list of features and other work to be done called the "product backlog," maintained and prioritized by the "product owner" (the representative of the customer, usually a product manager) and updatable between sprints.
• "Just in time requirements" that are specific and detailed for what is being worked on in the current sprint but less well-defined for work that is further down the road.
• An agreement among the team members on what features will be attempted for a given sprint, and joint responsibility for delivery of that fixed list of features.
  
• Daily quick meetings run by the "scrum master" to review what's been done in the last 24 hours and what each team member intends to do in the next (called "stand-up meetings" because they are supposed to be held standing up to motivate people to finish quickly), designed to uncover issues that need immediate resolution among team members.

The team is independent during a sprint, dividing up and and completing work as they see fit, but they must demonstrate the results of their work to the product owner at the end of every sprint. Despite the autonomy of the sprint, this increases transparency and accountability. Flexibility is also enhanced by allowing the product owner to continuously adjust the priorities of the features on the backlog for the following and later sprints in response to changing market conditions and knowledge.

There is a lot more to it, but I suggest people view Ken Schwaber's video or read some of the other great material available on the web about Scrum rather than me summarizing it all here. In my next post, I will try to summarize some of the early concerns and issues raised by folks at ATG as we talk through piloting Scrum on a project or two.