Introduction to Agile | EPAM Systems Russia (part 2)

Roles – Pigs and chicks

SCRUM processes

• Everything can change in SCRUM except the schedule!
• SCRUM consists of five processes:

1. Planning
2. Implementation
3. Demonstration
4. Measurement
5. Retrospection

• Critical points:

1. All processes are strictly regulated by time
2. They follow the previously defined schedule
3. These processes are a ‘must’ for the team on the whole, but you personally don’t need to follow them

Schedule example

Planning – strategic and operational

• Before project start you should create a plan (RoadMap, Releases plan) for the whole project (stage)
• It must include dates and functional, which must be delivered by that date – project milestones
• Dates never change and under no circumstances
• The delivery list must not change either, if you have learned the first part of the course well enough
• If you grasped it not well enough – you will fail your project

Executing strategic plan

• Achievement of strategic plan results is fixed in “red” spots
• Status is delivered to Customer’s managing committee
• Binary criterion: Achieved or not achieved. The same rule of ZERO is in effect here
• If not achieved – highlight the triggered risks, suggest means to decrease risk influence and ways to “catch up” the delay
• It’s obvious that risks like “I waited for John Focker to finish that” or “we got unrealizable plans” won’t work

Generating UserStory (requirements for implementation)

• Generation of US is a separate mastery, which mainly Analysts possess
• Ability to structure the information

1. US must be useful for Customer (who knows nothing about technical details)
2. The result should be easy to demonstrate
3. US must be technically full-grown (analysis, development, testing, integration)
4. US must intersect with each other as few times as possible and be independent as much as possible

     5. US must reflect the exact user

Does it seem familiar to developers?

• Strong connectivity and weak connectivity? – this is of the main principles of Object-Oriented Programming (OOP)
• Those who can design classes well, won’t have any difficulties in generating US

The experience you get here, you’ll be able to “re-use” in design

Examples of “good” and “bad” UserStories

• “The user (visitor) fills in the form for connecting a new Client. The user creates a temporary login and password. The Company employee confirms the application. The user supplies required documents to complete new client registration.”
• Good US.

1. For Customer, this US is a complete business process of registering new client.
2. Registration process is little dependant on other processes
3. The description clearly states who is the actor and what actions to make
4. The result is clear to demonstrate

• What will developers and QA say? Can this be implemented completely in two weeks, by 100%?

• If not, what can be simplified?

• “The User (visitor) fills in the form for connecting new Client. The employee rejects the application”

• Not a good US

• Filling in the form is already covered by the fist US

• What if we put it like this?

• US1 “The user (visitor) fills in the form for connecting a new Client. The User creates a temporary login and password. Company employee performs necessary actions to confirm or reject the registration.”

• US2 “The user makes necessary actions to complete or cancel new Client registration.” 

• Bad US example
• Refactoring is required for the “MyFavComponent” component, which will make the code better and it will contain fewer errors

1. The Customer is not interested in the result. The code must anyway contain no mistakes
2.  The result cannot be demonstrated (how to show that the code is “better”?)
3.  US is not either complete technically. There’s no analysis, no QA, no benefit as such 

Where to put technical tasks?

• Try to include refactoring only in cases where you can’t do without it and encapsulate the tasks in a specific US

• Add UnitTests only where you can’t do without them and encapsulate the tasks in a specific US

• Perform load tests only for those US, which are currently implemented and encapsulate tasks into a specific US

• Work with quality and technical aspects within US, which are being developed and encapsulate tasks into specific US

Where to put stuff, which can’t be encapsulated into US?

• You can have “Regular” type US
• These include US, which have no explicitly useful result for Customer
• They have no acceptance criteria and they’re not taken into account in measurements
• It’s the time that the team has to spend without direct benefit for Customer
• Expenses for conforming to processes
• Expenses for planning, demos, general communications, and so on
• Fixing defects in previously implemented US
• Other

Acceptance and completeness criteria for US

• Each “useful” US must have acceptance and completeness criteria
• At planning stage, the team must agree with Customer how the sprint results should look like. You must match their expectations with representation of those expectations
• There are no “bad” and “good” criteria
• You will understand what your criteria are after the first demo
• If Customer expectations are not met, he/she won’t accept US

Acceptance and completeness criteria

• From experience:

1. At preliminary discussion of sprint plan, you must make sure that Customer actually expects what he/she agrees to
2. As soon as feature prototype is ready, show it to Customer (before sprint end) to make sure you’re going in right direction
3. Agree about preliminary demo during briefing. Don’t catch Customer during midday and spam with your messages
4. Customer is a very busy person, don’t distract him/her beyond the planned schedule 

Definition of Done

• Completeness criteria
• When US is considered to be done by 100%?
• “Ideal” criterion is when the feature is developed, tested, defects fixed, demoed, documented, and deployed in Customer environment
• Is it possible? It’s possible, but difficult
• In reality:

1. Feature is implemented, but not tested or deployed
2. Feature can be demoed
3. Features is tested, but not deployed 

• Keep “ZERO” in mind

1. Documentation can be “delayed”
2. Deployment – when the environment is set up
3. Testing? Very dangerous to be “delayed” 

• Generate PO expectations about completeness criteria at planning stage

Planning – operational level

• Goal – To clarify Customer expectations for the current day and match them with forthcoming defined point and team capabilities

• Task – To select critical requirements for the next iteration, suggest them to Customer, agree on them, and estimate them in any units

• Artefacts

1. ProductBackLog – the list of requirements to be implemented within the whole project
2. SprintBackLog – the list of requirements to be implemented within the current sprint

• These are not analytical documents but operational plans

How does SCRUM plan differs from a classic one?

• Classic planning implies

1. Work
2. Assigning Executor for performing that work
3. Start and finish date when Executor must complete the work
4. Dependence of work on each other

• Agile planning implies

1. A set of requirements for product (each includes work, but the plan doesn’t take that into account)
2. Start and finish date for these requirements to be implemented (all that are planned)
3. Joint team of executors who implement these requirements during iteration/sprint

• What does Agile plan not include?

1. Specific work
2. Specific executors for that work
3. Specific dependencies between works 

How to do tasks not reflected in the plan?

• Specific tasks are offered when communicating with each other.
• When and how to do that – as it suits the team

1. At lunch during easy conversation
2. In smoking room (though smoking kills!)
3. At the time specifically scheduled for that
4. Any other variants

• Tasks and assignments each one suggests on his/her own
• Dependance between tasks are corrected during daily briefings

1. Who and what finishes and whom he/she can show the result to in order to do further tasks
2. When this is expected
3. Who can help someone who is in trouble
4. Any other coordination

Planning – from experience

• To planning session, where estimates will be provided, you must come with the understanding what needs to implemented
• You should start “pre-planning” between yourselves a day before the iteration end
• Then the one who more often communicates with Customer (it could be BA, PM, Lead, anyone delegated by the team) – preliminarily discusses the suggested list (better via GoTo) and shares Customer comments with the team
• At planning session you need to estimate tasks as a team and fix the iteration start date
• In your team you can have a completely different approach – suggest your variants, try them, and analyse the effect

Planning – how to estimate

• There are too many practices available
• Decomposition
• Expert estimates
• Poker planning
• FocusFactor estimates
• Relative estimates in “penguins”

Planning – if you want to develop your Logic

• Decomposition
• Each “cow” is detailed into small tasks (as many as possible)
• Each small task is estimated
• Risks are evaluated (as much as possible)
• Each one must calculate the amount of hours he/she has available during the sprint
• Then sum up the tasks
• In general, as it’s done in standard planning
• But all this activity must be done outside the main carcass of processes.
• You should go to Planning session with one number per each requirement

Planning – if you want to develop your Intuition

• Expert estimates: if you have no expert experience for such requirements – just any number in man-hours. If you have the experience – then give the number, which will “come up” in your mind relying on that experience
• At sprint end actually spent hours will be measured and you’ll be able to check how far you were from the correct number. And you will know what you didn’t consider and where you played too safe
• So, you’ll be gaining expert experience from sprint to sprint
• Poker planning: Each one provides his/her expert estimates for implementing the whole US (for all)
• Then cut off minimum and maximum from all estimates
• If variation is still big – then discuss what they had in mind when providing estimates
• Reach joint estimate and fix it
• After sprint ends, analyze the measurements
• It’s difficult to use in distributed development

Implementation agile Russia

• Daily briefings – 15 minutes time limit
• Goal is to coordinate all participants including Customer
• Each team member answers three questions in turn

1. What was accomplished yesterday?
2. What will be accomplished today?
3. Are there any blocking problems?

• Product owner and “visitors” listen to and specify their available time for today
• Briefing is not a report for management
• Briefing is the time when you agree with everyone about:

1. Time when all dependent tasks will be ready
2. Time, agenda, discussion list, intermediate demos, other operational events
3. Status of open problems
4. Obstacles that prevent the team from advancing further 

Implementation – timesheet

• After planning is done
• ScrumMaster submits US to system #9
• Each one creates tasks for himself/herself
• At the end of the day, each one submits his/her time to time journal
• Per each task

1. How many actual hours were spent on it today
2. Remaining hours to implement it

• Remaining hours is daily expert estimate of the time “leftover” for this task taking into account the information that was found out today, and the work that was done today

Implementation – burntout diagram

• Burntout diagram shows the progress of work within each sprint
• Each one fills in his/her time journal, but sees the overall picture
• It’s difficult to change the remaining hours, if tasks are team-wide

Demonstration

• The last day of each sprint is demonstration of achieved results
• Each one must prepare a slide for his/her US:

1. The responsible person
2. US description
3. % of completeness (according to team’s opinion)
4. Acceptance criteria
5. What missed the deadline

• ScrumMaster joins slides into joint presentation, where he/she:

1. Specifies joint sprint goal
2. US list for this sprint and states % of completeness (according to team’s opinion)
3. Defects state (when they appear)
4. General measurements for sprint results
5. Plans for the next sprint (direction) 

• Each responsible person shows results for his/her US
• Product owner must answer clearly: Does the team achievement meet his/her expectations made during sprint planning?
• Provides his/her comments that must be considered in the next (or future forthcoming) sprint
• Team fixes the comments and adds them to ProductBackLog for further planning

Demonstration – from experience

• Before demo, each one must open all documents, applications, and so on, which will be demonstrated
• Before demo itself it’s better to show intermediate results to Product owner in order to get some feedback
• During demo you should try to minimize the time
• You should plan separately demonstrations of huge functional blocks, which will interesting to representatives of other divisions
• You should agree about such demos at planning sessions. This can be a separate US

Measurements

• Each team can measure what they are interested to measure
• The only measurement is obligatory – achieved benefit
• Number of US planned for implementation * Value
• How many US were accepted by Customer
• Relation of fact to the plan is the share of achieved benefit
• Each measure separately must help develop specific skills

1. Planning accuracy
2. Deviation of planning accuracy
3. Share of useful US
4. Degree of US with normal estimates
5. And so on

• Dynamics of average values of measurements shows Customer the team state

1. If the team is “tired”, or “didn’t tune in”, or “something else” – the measurements will have ragged dynamics; there will be ups and downs without objective reasons
2. Dynamics of average value of measurements is the source of early indication of team risks, when there’s still time to fix something 

Retrospective

• This is “self-analysis” and “reflection”
• This is team discussion of the finished sprint. Time limit is two hours
• Each one in turn mentions (in his/her opinion) what was useful and effective from practices and processes
• What didn’t work, and what stood in the way
• Why you failed to achieve something. What can be done to be in time in the next sprint?
• What other practices can be used?
• Why estimates were wrong? What risks were triggered? Could you foresee them? What can you do in future to foresee such risks in advance?
• Any other analysis and corrections in processes, measurements, practices

agile CIS

Tools

Deming cycle (PDCA – Plan-Do-Check-Act)
P: Planning – Excel, #9
D: Implementation - #9, PMC
C: Demonstration, measurement – PPT, Excel
A: Retrospective, process fixing – e-mail, Wiki
Rhythm: Daily briefing – e-mail

P: Planning – process

• Team generates it in Excel
• Product Owner:

1. Makes changes in the plan
2. Organizes priorities
3. Defines urgency
4. Clarifies acceptance and completeness criteria

• Team:

1. Estimates features
2. Selects most critical and urgent in accordance with available hours

• Product owner and team approve the sprint plan
• SCRUM-Master creates plan in #9
• SCRUM-Master notifies about planning finish
• Time limit – from two to six hours
• Before sprint start the team spends some time on plan creation (in operational mode) 

D: Implementation – process

• Team creates specific tasks in #9
• Developers, Analysts, QA create tasks independently
• They coordinate the tasks on daily basis via email
• Update documentation in PMC
• Submit defects in PMC (or in #9)
• Submit risks, problems in PMC (or in #9)
• Plan builds in PMC (or in #9)
• Close actually spent hours in #9

C: Acceptance – process

• Team creates a presentation in PPT
• QA report on defect statuses
• Product owner reports on measurements
• Team shows the achieved results
• Product owner accepts or rejects the implemented requirements
• The results are distributed via e-mail, presentation is uploaded to PMC, link to Wiki is provided

A: Retrospective – process

• Organize it via GoToMeeting
• Use GoogleDocs
• After it ends, send the text via e-mail and publish it to Wiki

Rhythm: Daily briefing

• Use GoToMeeting
• Each one fills his/her own columns, preferably before DS
• Use GoogleDocs
• Send the results via e-mail

What to start with?

1. Daily briefings
2. Each day at 10:30 we have daily briefing
3. Information to join it:
4. Phone:
5. Extension: _________
6. PIN code: ___________
7. docs.google
8. Everyone interested is invited
9. Time limit 15 minutes

Skype channel

1. Each new group member is included into joint skype channel
2. This channel is used for broadcasting messages that are important for the whole group
3. Try not distract the whole group without necessity
4. For your personal communication create your own mini-channels for a more focused communication
5. But… a smile won’t harm anyone

Quotations from everyday work

1. We won’t breathe before our death??? [VB] I suggest stopping breathing on Thursday evening) [TP]
2. Don’t even try to say “I don’t know why it is not generated" [MZ]
3. Deleting DB on Customer side. Everyone out from test environment! [AK]
4. Restored actual DB on test environment. Now you can’t blame the DB [AK]
5. We have two day to finish that, why is tomorrow missing??? [VB]
6. You should warn in advance, and not half way through of not-checked line [AK]
7. Don’t try to make jokes about weekends, when you work on weekends! [VB]
8. I’ll rephrase that, who made that bug? [MZ] ball is yours, no-one else’s...[VB]
9. We did it! :) Alfa is on the way)) meaning it’ll be on the way in half an hour :D [MZ]