The Johannesburg Siebel User Group was held once again at the IS chillroom located in Bryanston. The turnout was rather good and this would be a good thing in my opinion, if you consider how much value was given in the presentations. The first of the two presentations was given by two speakers Tania van Wyk de Vries and Kevin Trethewey from the Scrum User Group South Africa and thier presentation was on SCRUM.I can already see the enthusiast’s having flash back of the weekend rugby, but it’s not quite the same thing. Interestingly enough they call scrum the ‘rugby approach’ , as the whole process is performed by one cross-functional team across multiple overlapping phases, where the scrum (or whole team) “tries to go the distance as a unit, passing the ball back and forth”.
What Is SCRUM?
Scrum is an iterative, incremental methodology for project management often seen in agile software development, a type of software engineering. It uses the real-world progress of a project — not a best guess or uninformed forecast — to plan and schedule releases.
Many of us would probably try and figure what word is the acronym (my best was Schwaber’s Cunning Response to Unmanageable Members). Sadly though it’s not an acronym and the only reason most companies spell it with capital letters is as a result of Schwaber’s early paper where he probably forgot the caps lock on when he wrote the title, but I stand to be corrected.
A brief history lesson is that in 1986, Hirotaka Takeuchi and Ikujiro Nonaka described a new approach to commercial product development that would increase speed and flexibility, based on case studies from manufacturing firms in the automotive, computer, photocopier, and printer industries. In 1995, Sutherland and Schwaber jointly presented a paper describing the Scrum methodology at the Business Object Design and Implementation Workshop held as part of OOPSLA ’95 in Austin, Texas, its first public presentation. Schwaber and Sutherland collaborated during the following years to merge the above writings, their experiences, and industry best practices into what is now known today as Scrum.
A product owner creates a prioritized wish list called a product backlog.
During sprint planning, the team pulls a small chunk from the top of that wish list, a sprint backlog, and decides how to implement those pieces.
The team has a certain amount of time, a sprint, to complete its work – usually two to four weeks – but meets each day to assess its progress (daily scrum). Along the way, the ScrumMaster keeps the team focused on its goal. At the end of the sprint, the work should be potentially shippable, as in ready to hand to a customer, put on a store shelf, or show to a stakeholder. The sprint ends with a sprint review and retrospective. As the next sprint begins, the team chooses another chunk of the product backlog and begins working again. The cycle repeats until enough items in the product backlog have been completed, the budget is depleted, or a deadline arrives. Which of these milestones marks the end of the work is entirely specific to the project. No matter which impetus stops work, Scrum ensures that the most valuable work has been completed when the project ends.
The One aspect that stood out for me was the Daily meeting. Each day during the sprint, a project status meeting occurs and they are called daily scrums/standups. The guidelines are that
•The meeting starts precisely on time.
•All are welcome, but normally only the core roles speak
•The meeting is timeboxed to 15 minutes
•The meeting should happen at the same location and same time every day
During the meeting, each team member answers three questions:
•What have you done since yesterday?
•What are you planning to do today?
•Do you have any problems that would prevent you from accomplishing your goal? (It is the role of the ScrumMaster (person responsible for the Scrum process) to facilitate resolution of these impediments, although the resolution should occur outside the Daily Scrum itself to keep it under 15 minutes.)
Something that was appealing was that in some companies they have a team work from the same room or area to improve communication and let’s face it things would get done much faster sitting in the same room rather than you having to rely on “John” to (if he ever does) read your email asking him to restart your Dev environment.
I recommend you have a closer look at SCRUM and the value it could add to any business!
Well, I hope this helped wet your appetite (not to mention the cold beers and pizza) for the next user group on SIEBEL EMAIL RESPONSE ARCHITECTURE to be presented by Swapnil Walse.