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