Scrum (management)

From Free net encyclopedia

Scrum is an agile method for project management. It has been called a "hyper-productivity tool", and has been documented to dramatically improve productivity in teams previously paralyzed by heavier methodologies. Scrum was first documented by Takeuchi and Nonaka in "The New New Product Development Game" (Harvard Business Review, Jan-Feb 1986).

Its intended use is for management of software development projects, and it has been successfully used to "wrap" Extreme Programming and other development methodologies. However, it can theoretically be applied to any context where a group of people need to work together to achieve a common goal - such as setting up a small school, scientific research projects or planning a wedding.

Although scrum was intended to be for management of software development projects, it can be used in running maintenance teams, or as a program management approach: scrum of scrums.

1 Characteristics of scrum
2 Simplified Scrum
3 Adaptive Project Management
4 Scheduling Daily Status Discussions
5 See also
6 External links

[edit]

Characteristics of scrum

A living backlog of prioritized work to be done;
Completion of a largely fixed set of backlog items in a series of short iterations or sprints;
A brief daily meeting or scrum, at which progress is explained, upcoming work is described and impediments are raised.
A brief planning session in which the backlog items for the sprint will be defined.
A brief heartbeat retrospective, at which all team members reflect about the past sprint.

Scrum is facilitated by a ScrumMaster, whose primary job is to remove impediments to the ability of the team to deliver the sprint goal. The ScrumMaster is not the leader of the team (as they are self-organising) but acts as a productivity buffer between the team and any destabilising influences.

Scrum enables the creation of self-organising teams by encouraging verbal communication across all team members and across all disciplines that are involved in the project.

A key principle of scrum is its recognition that fundamentally empirical challenges cannot be addressed successfully in a traditional "process control" manner. As such, scrum adopts an empirical approach - accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team's ability to respond in an agile manner to emerging challenges.

Notably missing from scrum is the "cookbook" approach to project management exemplified in the Project Management Body of Knowledge - which has as its goal quality through application of a series of prescribed processes.

[edit]

Simplified Scrum

Many organizations are resistant to methodologies introduced at a grass-roots level. However, Scrum's adaptability allows it to be introduced "stealthily". E.g. using three steps:

Schedule a demo of the software with the customer/client a month from now
As a team, take a month to get your software ready for the demo - actually functioning, not just screen shots
At the demo, get feedback and use it to guide the next month's development work

With this process the essence of the Scrum patterns is implemented and can be built upon.

[edit]

Adaptive Project Management

It's not very common these days that a service provider specifies all the product characteristics and product requirements in a single shot. Many times it becomes an incremental delivery or the software is not acceptable by the customer. No one would want to pin down a customer because he is not clear of his requirements. Sometimes the customer might not be the end-user. In this scenario complications still result. The end user gives an "A" to the customer, and customer gives an "A+-" to service provider. In these kind of complex scenarios the only thing that rescues us is the lightweight process.

Following are just a few practices for the SCRUM :

Customer must become a part of the development team. (i.e. He is genuinely interested in the output).
Frequent intermediate deliveries with a working functionality is a MUST.
Frequent mitigation and risk plans have to be developed by the DEVELOPMENT TEAM.
Daily status discussion with the team is a MUST.
Things to include in the daily discussion are:
- What did you do from yesterday?
- What are you planning to do tomorrow?
- Do you have any problems?
Transparency is a MUST in planning and different modules.
If a feature has a problem, no delivery shall take place.
A frequent stakeholder meeting, to see the progress, is a MUST.
No problems are buried under the carpet. No one is penalized for a problem.
Energized workplace and working hours is a MUST. "More number of hours" does not mean more "output."

[edit]

Scheduling Daily Status Discussions

The best time for the daily status discussion is after lunch break. Doing it in the morning is a bad practice especially if the team is working in a company using flextime. The general idea is that these status discussions don't take long, so one way is to do standup meetings and people meet in front of a whiteboard. Because people tend to get tired after lunch, having a lively standup meeting at that time is the best thing to do. During lunch break, people already discuss general topics, so the discussions after lunch break are more focused than discussions in the morning and the people are better prepared than in the morning and give better comments. Because everybody has already been working that day, their minds are focused on the job and not on some private issues - if the meeting is first thing in the morning, they are unlikely to be as focussed as they have just arrived and not yet got into the 'at work' mindset.

[edit]