Introducing SCRUM

Agile Project Management with Scrum

Introduction to Agile Project Management with Scrum9th August 2010 - Oliver Hankel


Official Scrum Certifications:

• 2009 Certified Scrum Master (at least I attended a course…)

• 2010 Certified Scrum Professional (at least I applied Scrum and

wrote about it)

Why am I allowed to talk about agile?

More interesting:

• Since 1999 I am involved Software (Web)-

Development

• Working in different units: From PM to QA

• Working with agile methods since 2001:

• eXtreme Programming (TDD-Lover)

• Participative & evolutionary SW-Development


AKRA GmbH & AKRA Business Solutions GmbH :

• Management Consulting & Process Consultancy

• Agile Project Management

• Development (Java, Ruby, CA Gen, .NET, ORACLE)

Whom do I work for?

Sectors:

• Energy

• Finance & Insurance

• Aviation

• Logistics

• Web 2.0


Correct approach?

• Contract specifications

• Functional specifications

• Waterfall: Point of no return…

• Now we know the future!

Understand the Pain …

Sometime it works… but mostly :

• Discussion about the scope of the contract

• Mass debatts about contracts…

• Blame Game

• High costs & change management pain

• Unfortunately, it is hard to predict the future.


Are you sure?

More control, please – Unified Processes?!?

Source: http://justaddwater.dk/2009/08/19/rup-vs-scrum-vs-kanban/


Royce, Winston (1970), "Managing the Development of Large Software Systems", Proceedings of IEEE WESCON 26 (August): 1–9,

Look back, but not in Anger: Waterfall revisited




That sounds agile!

• Use prototypes, doing more then one time

• Interact and talk to your customer

• Write tests! Don‘t forget them.




There is even a loop!Check your software requirements aftertesting, do it again, check once again…


The reduction: From Royce Model to the Known Waterfall

… but why?The reason is money! The plain waterfall creates the illusion that you know what happens at each phase and that you can calculate the costs.


But Control is an Illusion…

If you have time watch the film „Instinct“…


Why is Control in SW Projects so Difficult?

… because SW is complex! That‘s it.


Something must change…


Value-driven SW development

We are uncovering better ways of developingsoftware by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and toolsWorking software over comprehensive documentation

Customer collaboration over contract negotiationResponding to change over following a plan

That is, while there is value in the items onthe right, we value the items on the left more.


Scrum – A Wholistic Approach

Hirotaka Takeuchi und Ikujiro Nonaka, “The New New Product Development Game”, Harvard Business Review, Januar 1986.


Scrum – „coming up with some new dog-and-pony show?”

Yes and no …. Personally I like Scrum, because you find doors in its process, which let in change and it helps to find out problemsat a very early stage.

Source: http://www.astromanager.net/?p=318


• We don't make mistakes, we learn• If you don't have fun, there's something wrong

Joseph Pelrine's rules about Scrum:

Source:XP Days 2007


3 x 3 = Scrum

Three meetings• Planning• Review/Retrospective• Daily Scrum

Three roles• Product Owner• Scrum Master• Team

Three artefacts• Product backlog• Sprint backlog• Burndown/up chart


• is the motivated one. She is enthusiastic about the product.

• knows what must be delivered and when.

• knows the business value of product.

• is responsible for the financial success.

• prioritizes the product features.

• is the only one, who can adjust the features of the product.

• accepts or declines the result.

The Product Owner:


• owes the process (Process Owner)• is responsible for the compliance of the values of Scrum• ensure that the team can work• supports the collaboration of all units and roles • removes impediments

• is the friend of the team

• knows what self-organizing means and can explain it to the self and the organizers :o)

The Scrum Master:


• is self organizing (that also means that they are

allowed to use RUP within a sprint)

• is cross functional: Developer, QA, UI-Designer

• has only full-time members

• includes between 5-7 members.

• can be left or joined only at the end of a sprint.

The Team:


• takes the product backlog as an input• has a sprint backlog as an output

The team commits to implement the features in the sprint backlog during the next sprint and promise to deliver a possible shippable product increment.

Commitment is the hardest thing to achieve. Use planing poker to learn how to improve your estimations.

Never forget that the product increment is the goal, don‘t let yourself be distracted by some cool technical challenges.

The Sprint Planning:


• Is not longer than 15 minutes• Stand-up, because it aviods long discussions

Stand-up is not the time for problem solving.• Invite whom you want, but only the Product

Owner, Scrum Master and the Team is allowed to talk.

• It avoids other longer meetings.• Challenge for the daily Scrum:

Is each team member able to define what he wants to achieve until the end of the working day?

• Is perfect to find out problems at a very early stage.

The Daily Scrum:


• The team presents the results of the last sprint.• The product (increment) is presented and

commented by the product owner.• The review must be a demo of the software or at

least the presentation of the architecture. Get real as soon as possible!

• Retrospective: What was good? What was bad? What was really ugly and should be stopped?

The Review & Retrospektive:


• contains the requirements

• is list of all required feature

• is the answer to question why is my work useful for the company or the customers/users.

• is owned by the product owner.

• is being re-prioritized before the planning meetings.

• contains estimations for each feature made by the team during the kick-off.

The Product Backlog:


How to write a product backlog (Gherkin):Feature: Manage SC-EEN customers In order to easily control the installations of SC-EEN as a provider of SC-EEN (superadmin) I want to manage the customer installations

Scenario: Add a new customer installation Given I am on the add new customer page When I fill in "Subdomain" with "AKRA" And I fill in "First name" with "Oliver" And I fill in "Last name" with "Hankel" And I fill in "User name" with "oliverhankel" And I fill in "Email" with "[email protected]" And I press "Add" Then I should see "akra.sc-een.eu" And I should see "Oliver" And I should see "Hankel" And I should see "oliverhankel" And I should see "[email protected]" And an email with a generated password should be sent to "[email protected]"

Scenario: View details of one customer

Scenario: View list of customer installations

Scenario: Remove an existing customer installation

Scenario: Update an existing customer installation


• Define a goal. A goal which can be achieved by the team…!

• For each feature tasks are defined.

• Each team member can add, update or remove tasks.

• The remaing effort for each task is updated daily.

• Divide & conquer! In case you are not sure about how to implement a feature, break

it down in manageable pieces.

The Sprint Backlog:


The Burndown Chart:

13:00 13:15 13:30 14:00 14:15 14:30 14:45 15:00 15:15 15:300

20

40

60

80

100

120

140 Points aka Minutes

Poin

ts

• This is a simple burndown chart for this presentation• A burndown chart visualises problems very quickly.

A flat line indicates that nothing is done and the Scrum Master is required, for example.


The Scrum Process:


Applying Scrum for a Support Team:The situation:

The developers are working seperatly from each other to support several products. The support contracts also contain a certain amount of the development of new features. From time to time they have production reserves and from time to time they are not available for doing support, because they are ill or on holiday or coaching other developers.

The customers always know what time was spent, but they had no really relation to the progress of their products.

The change:The developers are building a team. Know-How is transferred. A stable

support team is set up. The developers are aware of the priorities of the customers.

The customers is more involved and starts to control the product development as promised in the support contract.


Applying Scrum for a Support Team:

The Review and the Planning:


Applying Scrum for a Support Team:

The daily day:


AKRA GmbH

Domstraße 17

20095 Hamburg

Germany

Oliver Hankel IT-Consultant

Tel. +49 (0) 40 309 535 - 46 Fax. +49 (0) 40 309 535 - 49 [email protected] http://www.akra.de

Amtsgericht Hamburg HRB 74309, Geschäftsführer: Fabian von Borcke, Thomas Ochmann, Ralf Kaminski, Jörg Krüger und Cem Basman

Contact person:

And never forget to define the term DONE!

mailto:[email protected]

http://www.akra.de/

Education

Introducing SCRUM