Are you using Agile methods? If so, do you model?

Are you using Agile methods? If so, do you model? Does modeling work in an agile environment? Are models effective when dealing with clients in an agile context?

As part of a research effort supported by the Agile Alliance’s Academic Research Program, we are investigating whether (and how well) software development models work in agile environments. If you have experience or would like to provide a point of view with respect to modeling in any agile environment, we would like to hear from you. You can complete the questions pertinent to you and/or provide your opinion on this topic at
http://www.surveymonkey.com/s.asp?u=607293384759
Thank you in advance for you participation in this study,

Don Duffie
c/o Faculty of Business Administration Memorial University of
Newfoundland St. John’s, NL A1C 5S7 P.O. Box 4200 CANADA
don.duffie@gmail.com

Pulling XP. From Scrum

Scrum and Extreme programming are the two most popular agile software development methods. Both ideally end in a situation when the team working in a short cycles iteration by iteration delivers the DONE features to the customer. Customer is ideally always available for consultations and team is adjusting its practices sprint after sprint.

What Scrum and XP mostly differ on is the adoption focus. Scrum is focused on the project management side and expects the self-organizing team “pull” any needed practices into the process via the mechanism of adaptation. XP is on the other hand more focused on a concrete set of mostly engineering practices to choose from and to comply to. In a way the known best practices are pushed to the team and team is expected to strive for adopting them.

See more in Differences between Scrum and Extreme Programming by Mike Cohn and especially in the comments to that post.

Product backlog

Update: See also section added

Product backlog in Scrum is simply a list of things needed to be done. As such it is a little different from many other to-do lists. The difference comes from the small peculiarities of the way you handle the backlog. Here some some things to note about the product backlog.

  • Product backlog always lists items adding value for the customer. It includes functional requirements and non-functional requirements. It can also include items required by the team, but only the ones that will eventually bring value to the customer, e.g. taking into use a continuous integration server in order to guarantee the continuous end product quality.
  • Product backlog cannot include concrete low level tasks and requests for building the intermediate artifacts. For example, it cannot include request for producing the design document unless customer has to ship it further for some purpose.
  • Product backlog utilizes the simplest and the most effective way for prioritizing requests – a simple list. Such a method does not allow for having 100 absolute max priority features and forces the product owner to actually make decisions about the feature priorities.
  • The higher the items are located on the product backlog, the more detailed they are. Items for the closest couple of months are usually quite detailed, while items that will be worked on in some 6-12 month can be defined very broadly and imprecisely.
  • When there are several interdependent teams in the company or department, typically they all have a single product backlog and pull their work from it.
  • Product backlog does not typically include the detailed requirement information. Usually the final requirement details are figured out with the help of the customer, when the requirement is being implemented.

Ease of use, clear and transparent purpose is what makes the product backlog so useful for seeing into the project status.

See Also

Do you agree with the properties above? Or are there any other important product backlog properties worth mentioning?

Disconnected scrum

Daily stand-up meetings play an important role in the agile processes and especially Scrum. The purpose of the daily meeting is simply a team synchronization – letting everybody know what happens where, and what problems arise around. Daily meetings are so simple and effective that whenever team members don’t see value in it there has to be a problem to be solved.

No link

One of the possible reasons for not seeing a value in the daily scrum might be a lack of connection between the team members actions. A lot of teams start trying Scrum while being overspecialized – each team member might be responsible for the separate component, some team members might also work remotely and participate over the phone. In this kind of a situation some team members might not feel too much benefit from knowing what happens in the other corners of the team – why care if it does not touch you and you anyway are unable to help.

Whole team commitment plays an important role in agile processes and over time agile teams members tend to become less specialized and are able to help the struggling neighbors. What helps the team to feel the daily synchronization usefulness is to create circumstances, when it will be beneficial for the team to help each other and listen to the neighbor problems.

Cut the cycle in half

One of the natural ways to create such situation is simply to start with shorter sprints. 14-day sprints with two day weekends, one or two days spent on sprint planning, review and retrospective and some time spent on the sick leave or on various trainings leaves only 7-9 working days for the actual work. The time pressure makes it very transparent that overspecialized team has difficulties with delivering the stories prioritized by the product owner. Over two-three sprints most of the teams usually develop a feeling of common commitment, start devoting committing together to the product backlog items and start getting value from the daily synchronization rounds.

Don’t worry too much if the daily standups don’t work quite yet. Just stand for several iterations, listen carefully to the team feedback on retrospectives and adjust if needed.