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]

Read more...

Introduction to Agile | EPAM Systems Russia (part 1)

Introductory course summary

1. Successful and failed projects
2. Working with requirements
3. Agile/SCRUM proper
4. Tools
5. What to start with?

Not covered by this course

• Technical practices (UnitTest, Continues Integration and other)

• Standard processes (managing quality, deliveries, configurations, risks, and so on)

•  You either already know this, or will learn it during work

• I won’t tell you how to lead an Agile project, but will explain where it is applied and mention critical points

• You won’t get any instructions or guides, you will know where to look for them

• You won’t get a ‘silver bullet’

• You’ll have to find one for the specific project and conditions on your own

Covered by this course

• Fundamental differences between standard methodologies and Agile

• Crucial points of Agile’s ‘skeleton’

• Conditions in which Agile is effective and why?

• Who and how manages requirements in Agile

• Agile manifesto

• General carcass of Scrum

• Processes, artefacts, and tools available in EPAM for managing Agile projects

• What to start with?

• Agile is like Iceberg. I will show only its top

1. Successful and failed projects

       Project definition

• Project is a unique (in contrast to operations) activity that has a start and end time, with the goal to achieve previously defined result/goal, create specific unique product or service
• Goal/Product/Schedule – what we want
• Quality/Expenses – what we sacrifice
• Satisfaction – what we get for our sacrifice
• A project, be default, has fixed schedule! And as consequence fixed budget

       Criteria of successful project 

• 5 criteria of project being successful 
• Not 3 or 4 as everyone used to think

 

       Why do projects fail?

• Everyone makes mistakes

• Customer when defining requirements

• Analyst when putting requirements together

•   Developer when implementing functionalities

•   QA when testing the product

• PM when managing work and risks

• Account Manager when managing Customer expectations

• And so on

•   But everyone is sure that it is someone else’s mistake 

 

      “Waterfall” vs Agile metaphor

• Formal methodologies are the tracks, and team is the train

• Each person has his/her own function in the “train”, the engine driver controls the train
• Agile is a raft, where everyone has an oar
   

 

 

Who is to blame is for failing – the “train”

• Not the one who made mistake (see previous slide) but the one who was made “responsible”

• As everyone makes mistake, it is always easy to find the “guilty” person

• Victory has many fathers, defeat is always an orphan

       What to do – “Train”

• Find the “guilty one”
• Replace him/her with another person
• Improve processes and control
• Start everything from scratch
• Cross your fingers 
• Maybe this “train” will be a success 

       What to do? – “Rafting”

• Joint “guilty person” is already known
• Find people who understand that they and everyone personally will be blamed for a colleague’s mistake
• Introduce simple processes that will allow making mistakes and detecting the reasons/problems on everyday basis
• Start everything from scratch
• Everyday adjust the joint movement to the goal

 

      Which way is more predictable? “Train” or “Rafting”? 

      It’s important to know initial conditions 


       1. Your project is a river with rapids, unknown turns and obstacles on the way? “Rafting” has more chances to succeed

       2. Your project is a railway with tracks? “Train” is more likely to succeed

      Quantitative and qualitative Success indicators

 
      1. Schedules and budgets have numbers
      2. 20% of tests bring 80% of quality (for example)
      3. 20% of requirements bring 80% of benefit (for example)
      4. Satisfaction is not measured by numbers
      5. Failure to meet “red” criteria increases project’s chances to fail. Flexible approach considers that

                                                Regulators of success criteria



Are you ready for Agile?

• You don’t want to share the failure
• You agree to necessity and possibility to meet all 5 success criteria
• You have the experience, knowledge, and opportunities, and you want to develop them
• You accept the boundaries, which were not set by You
• You aren’t afraid of uncertainty
• You know that uncertainty is also the source of opportunities, not only the risks
• You trust your colleagues, Customer, Management and ready to cover their risks
• You get satisfaction from joint Success
• Then Agile is for You, welcome to the Raft!

You must decide for yourself – Why you need it personally?

• It’s the management who needs success, not me, and it doesn’t depend on me
• You can’t meet all 5 success criteria
• I prefer to develop my skills without going to extremes
• When someone sets terms and boundaries, let him/her do this project
• Uncertainty is evil, which must be eradicated
• Uncertainty is only the source of risks and threats. Everything must be accurate and clear
• I’m not a coward, but I fear. Let those take risks who are supposed to by their position and salary
• I’m a pro and trust only myself. The rest must be responsible for their mistakes
• Then Agile is not for You, you’d better wait for your train

Summary – Successful and failed projects

• 1.Project is successful when ALL 5 criteria are met
• 2.Everyone makes mistakes
• 3.The price of an error is low at the start and high at the finish – in any methodology
• 4.“Waterfall” minimizes human errors by processes
• 5.Agile minimizes human errors by people and their capabilities
• 6.If nothing is changing and people don’t make mistakes then “Waterfall” is more effective than Agile
• 7.If the probability of changes and errors is high, then Agile is more effective than “Waterfall”
• 8.Agile focuses on people and creates all conditions for them to develop their skills
• 9.It’s much harder to control a river stream than be a part of the train
• 10.When in doubt – don’t go rafting, wait for your train

2. Working with requirements

His Majesty RL (Requirements List) 

   1. RL is the Bible 

   2. The Bible is worshiped by everyone, but no-one reads the original 

   3. It’s written for everyone in “strange” language 

   4. Requirements are agreed, approved, and signed (or not signed), which takes much time 

   5. At agreement stage, details, mismatches are found out, and requirements are changed

 

Reality of tumultuous river

1. Are you good at shooting moving objects? 
2. How to make an accurate plan, when nothing is accurate and everything is changing?

 

 And when the functional is ready…

•  Business folks – “this is not what we need, but… there’s no time left”
•  Developers – “That’s what RL says! We implemented what you told us to do”  

 What is “useful” feature?

 
“Useful” feature is:

• the feature, which is convenient to use
• the feature, which will be always or often convenient to use
• the feature, without which you won’t be able to use the product on the whole
• According to the statistics 20% of all features are useful
• Other 80% must be postponed, and half of them won’t be required

Who is responsible for selecting ‘useful’ features?

• Variant 1 – Customer
• Variant 2 – BA
• Variant 3 – PM
• Variant N – Someone else, but not me

Everyone makes mistakes!

• If not me, then who?
• Why exactly me?
• The deeper you hide your head in the sand, the more vulnerable it becomes….

 Who is responsible for selecting ‘useful’ features?

• Customer doesn’t yet know what feature users will be using always and what seldom
• BA doesn’t know all the more
• PM has no idea at all
• Developers… How are they supposed to know?
• Everyone hides the head in the sand
• And when the  functional is ready….

Example from real life

• Customer – a big mining company
• Dozen of subsidiaries need to purchase goods from clips to drill towers
• Purchase portal is required
• 2009 – we created a mini website 80K
• 2010-2011 – we developed “portal” 600K
• Both products allow subsidiaries hold tenders and purchase goods
• The price differs significantly

Several leading questions

1. Who needs this requirement? (users)
2. Why do they need it? (goal, effect)
3. When do they need it? (schedule)
4. What do they risk if the requirement is not implemented within fixed schedule? (risks)
5. What will they get, if the requirement is implemented within the schedule? (opportunities)
6. Can we replace this requirement with something cheaper? (alternative)
7. Everyone must run such analysis

Example – News publishing
FT1: The system must allow publishing Company news, and supporting viewing news, and searching by keywords

Solution:
Show first 10 news without paging for those who track news on daily basis
Standard keyword search function for those who are interested in news history
Paging increases number of requirements without increasing benefit

Who is responsible for selecting “useful” features?

• Who’s rowing in raft?
• Everyone makes mistakes
• Each one will have to correct mistakes made by other people
• Number of corrections increases non-linearly closer to the end of project

Task for everyone

• “Turn your head on”
• Thoroughly “filter” features from RL
• Select minimum of useful features
• Suggest technically simple solutions
• Fully implement them so that Customer could conveniently use them
• Move on

What is the measure for Benefit, Saving, Losses, and so on?

• There’s no exact measure
• You can use hours, “penguins”, “sepulkas”
• When defining the difference, number of “penguins”  and “sepulkas” decreases
• You can “measure” in expert opinion
• To be trusted – enhance your experience
• Confirm your opinion by your acts
• Every day, every sprint, every milestone, every project
• Then the time spent on “sepulkas” now, you’d spend on more important things

Feature completeness

• During implementation, a feature, as a rule, passes several stages
• Analysis, Prototype, Alfa, Beta, RTM, deployment
• Customer sees benefit only when he/she can actually this feature
• What will be its name? As you agree.
• But if the feature is 95% complete, its benefit is 0 (ZERO!)
• This zero at the start will prevent You from overtiming in the end, do respect it

Feature completeness – why?

• How come? We completed 85% of work. Why 0 benefit?

• 85% is your vision of completeness, and we remember that everyone makes mistakes

• Reality is when the team says 85% is complete, it means less than 50% (because of bugs, mismatches; oh, we haven’t thought about that; and this is like jack-in-the-box, no-one expected that)

• And the team counts on those 15%

• And in practice it turns out that all 50%
• When do we finish that? Schedule can’t be changed? Too late to add new people.
• Who will answer this question from your experience on other projects?
• 85% of completeness threatens the whole team with overtiming and working weekends
• Overtime won’t be paid!
• It’s not because the management is saving, but because the one who “is not rowing in raft” endangers the rest in it.
• Everyone makes mistakes. 85% is also mistake
• From the first sprint, try to complete User Story (US) by 100%
• This is very hard to do technically, especially in the beginning
• It’s better “be late” in the beginning as you still have time to catch up
• It’s much worse when the wave of unimplemented percent falls upon the team in the very end

Summary – Working with requirements

1. RL is not the Bible, but just a guiding line
2. Only 20% of features in reality are critically useful to clients
3. Don’t try to implement the whole iceberg at once, even if the Customer, Manager, King or God insists on it! Shift the mOst part till later
4. Useful feature is such a feature, which is convenient to use and brings effect
5. Turn your head on. Everyone is responsible for selecting “useful” features, it is in your interest
6. Feature, completed by 85%, has ZERO benefit
7. Do respect this zero, it is your friend!

Working with requirements.

3. Agile proper

Agile manifesto

• People and their cooperation are more important than processes and tools
• Working software is more important than extensive documentation
• Cooperation with Customer is more important than discussing contract terms
• Reacting to changes is more important than following the plan

Four “double standards”

• There are wars around this manifesto, which are akin to religious wars
• What is more important, one side of the moon or the other?
• What is more important, soup or pan?
• What is more important, black or white?
• Either is important and depends on a specific day in project, specific person, specific task, specific conditions, specific…

What is on the painting?

• Who do you see on this image?
• And now?
• What if you turn your head?
• Try and tell what is more important, the Man or the Horse?
• And the main thing – if one part is more important, then how to remove the second part, that is less important?

Manifesto is not the Bible as well

• Manifesto is just an attempt to show the people who have been formatted under “RL” for years, that there’s the other side that is based on cooperation and not submission.

• This is not an “alternative Bible”

• This is the other side, but of the same moon: Project success

• The team mastery is to find the balance between the both sides of the manifesto each day

• A real master is like a bartender who professionally mixes the ingredients of a cocktail in the way that the Client is expecting

Scrum principles – Cooperation

• Communication
• Simplicity
• Mutual assistance
• Feedback
• Courage, spirit
• Trust
• Respect
• Tolerance
• Mutual benefit

Scrum terms
SCRUM is one of Agile approaches. There are many of them. (agile Russia)

Base elements

• UserStory (requirement, function, feature) – user scenario that brings benefit to Customer
• Sprint – an iteration, in which UserStory is implemented
• ProductBackLog  - List of UserStories for a visible project part
• SprintBackLog – List of UserStories that should implemented during the sprint
• DailyScrum (briefing) – daily 15-minute meetings

Roles and functions

• ProductOwner – is responsible for functional System development
• ScrumMaster – is responsible for driving all UserStories to acceptance
• ScrumTeam – is responsible for implementing all UserStories
• StoryOwner – is responsible for driving his/her UserStory to acceptance

Roles - Product Owner

• Product Owner (PO) – the Owner of the product who:
• Knows that business required
• Knows why business needs this
• Knows when business needs this
• Knows what business can do without
• Knows who or what this “business” is
• Doesn’t know how it should look like
• Doesn’t know what technically can be done and what not
• Doesn’t know what from the list that business requires is more difficult and what is less difficult
• Is ready to share the knowledge
• Is ready to accept the team’s knowledge
• Cooperation between team and product owner is the key success factor

Roles - Scrum Master
Scrum Master (SM) is team leader who:

• Starts the scheduled events and tracks the regulations
• Makes changes in processes and regulations
• Helps to change priorities
• Creates atmosphere of trust
• Visualizes problems and open questions
• Eliminates external obstacles
• Is responsible for conforming to team practices and processes
• Has the goal to drive all UserStories to acceptance by the Customer
• Doesn’t set tasks
• Doesn’t control implementation
• Doesn’t kick your bottoms

Roles – Scrum Team
Scrum Team (SM) is the team that:
Implement US to the full extent, in accordance with acceptance criteria
Set their own tasks, register them in #9
Estimate labor input for implementation
Suggest making some tasks simpler, quicker, and more effective
Work independently, agree and coordinate with each other
Their goal is to plan, implement, demonstrate and delivery US within the schedule and sufficient quality. 

more about agile Russia and agile CIS 

Read more...