RefineM - Agile - 1 day course€¦ · AGILE&Fundamentals NK Shrivastava, PMP, RMP, ACP, CSM, SPC...
74
9/16/15 1 AGILE Fundamentals NK Shrivastava, PMP, RMP, ACP, CSM, SPC CEO/Consultant - RefineM www.RefineM.com Agenda 1. Introduction – You 2. Introduction – Myself 3. Agile Concepts 4. Agile Methodologies 5. Agile Teams 6. Agile Planning & Estimation 7. Agile Project Execution 8. Q&A 2
Transcript of RefineM - Agile - 1 day course€¦ · AGILE&Fundamentals NK Shrivastava, PMP, RMP, ACP, CSM, SPC...
9/16/15
1
AGILE Fundamentals
NK Shrivastava, PMP, RMP, ACP, CSM, SPCCEO/Consultant - RefineM
www.RefineM.com
Agenda1. Introduction – You2. Introduction – Myself3. Agile Concepts4. Agile Methodologies5. Agile Teams6. Agile Planning & Estimation7. Agile Project Execution8. Q&A
2
9/16/15
2
www.RefineM.com
∗ What would you like to share about yourself?ü Your name, your current role, your favorite hobby, your favorite food, your dream vacation..
∗ What is your exposure/experience with Agile?ü Have you worked in an agile project? ü What role(s) did you play in your recent project?ü Do you want to share anything else about your recent agile experience?
∗ What are your top 2 challenges related to Agile?
∗ What is the 1 thing that you want to take away from this course?
About You
www.RefineM.com
NK Shrivastava, PMP, RMP, ACP, CSM, SPC∗ CEO/Consultant since Dec 2011
∗ Agile Coaching/Adoption∗ Project Management/ Process Improvement
Consulting and Training∗ Project Management Products (for PMs, Executives
and Agile Practitioners)
∗ Former Board Member – PMI SWMO Chapter
4
Helping organizations turn their project management capability into a competitive advantage
My professional journey b/f RefineM ∗ 20+ years of Successful Project Leadership∗ Led 100s of projects of all sizes, successfully∗ Recovered many projects, saved millions of $∗ Implemented numerous process
improvements∗ Coached/mentored 100s of PMs, and some
executives
9/16/15
3
• Software Development• What is Agile?• Agile Vs. Waterfall• Agile Manifesto• 12 Agile Principles • Challenges in Agile Adoption
Agile Concepts
www.RefineM.com
Software Development
6
In grandpa days…
9/16/15
4
www.RefineM.com
Issues with Waterfall Methodology
∗ No value delivered until the end∗ Heavy upfront planning∗ Enormous documentation∗ No customer involvement during
development∗ Numerous change requests∗ QA/testing – a sticker shock∗ Cost overruns, delays resulting in project
failures (70%)
7
www.RefineM.com
AGILEA new way of developing software
8
9/16/15
5
www.RefineM.com
Agile
9
How is it different than Traditional?
www.RefineM.com
Waterfall Vs. Agile
9/16/15
6
www.RefineM.com
AGILE ContractsFlexible on scope/features
11
Traditional Agile/Time-boxed
www.RefineM.com
Manifesto for Agile Software Development
12
We are uncovering better ways of developing software by doing it and helping others do it. Through this
work we have come to value:
Individuals and interactions over processes and tools Working software over comprehensive documentation
Customer collaboration over contract negotiation Responding to change over following a plan
That is, while there is value in the items on the right, we value the
items on the left more.
Was developed in 2001 by 17 agile advocates in Snowbird, UT
9/16/15
7
www.RefineM.com
Agile Twelve Principles1. Satisfy the customer thru early and continuous delivery
2. Welcome changing requirements even late in development
3. Deliverworking software frequently a couple of weeks to a couple of months
4. Work together daily (business people and developers)
5. Motivated individuals, build projects around them, and give them freedom
6. Face-‐to-‐face conversations is themost efficient and effectivemethod
7. Working software is the primary measure of progress
8. Sustainable development i.e. maintain a constant pace indefinitely
9. Continuous Attention to technical excellence& good design enhance agility
10. Simplicity – the art of maximizing the amount of work not done – is essential
11. Self-‐organizing teams deliver the best architectures, requirements, and designs
12. At regular Intervals the team reflects on how to becomemore effective
13
www.RefineM.com
Agile Principles
1) Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
9/16/15
8
www.RefineM.com
Agile Principles
2) Welcome changing requirements, even late in development. Agile process harness change for the customer’s competitive advantage
www.RefineM.com
Agile Principles
3) Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale
9/16/15
9
www.RefineM.com
Agile Principles
4) Business people and developers must work togetherdaily throughout the project
www.RefineM.com
Agile Principles
5) Build Projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
9/16/15
10
www.RefineM.com
Agile Principles
6) The most efficient and effective method of conveying information to and within a development team is face-‐to-‐face conversation
www.RefineM.com
Agile Principles
7) Working software is the primary measure of progress
9/16/15
11
www.RefineM.com
Agile Principles
8) Agile process promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
www.RefineM.com
Agile Principles
9)Continuous attention to technical excellence and good design enhance agility
9/16/15
12
www.RefineM.com
Agile Principles
10) Simplicity – the art of maximizing the amount of work not done – is essential
www.RefineM.com
Agile Principles
11) The best architectures, requirements, and designs emerge from self-‐organizing teams
9/16/15
13
www.RefineM.com
Agile Principles
12)At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly
www.RefineM.com
Challenges in Agile Adoption∗ Mindset/Cultural transformation to become “agile”
ü Value focus, deliver value fasterü Fix cost and time, scope can be flexible ü Deliver most high value items within the fixed cost & timeü Deliver working software at the end of each iterationü Self-‐managing teams, don’t need any managers Jü Delivering faster with self managing teams does not mean chaos or poor quality product
26
Mindset/Cultural Changes are not trivial L
9/16/15
14
www.RefineM.com
Challenges in Agile Adoption∗ Mindset/Cultural transformation to become “agile”∗ Dedicated, co-‐located team is not today’s “reality”
ü Team members work on multiple projects (multi-‐tasking)ü They switch among the projects to fight firesü They are not co-‐located, and may work remotelyü Communication/collaboration is constrained
27
www.RefineM.com
Communication is the key
28
9/16/15
15
www.RefineM.com
Challenges in Agile Adoption∗ Mindset/Cultural transformation to become “agile”∗ Dedicated, co-‐located team is not today’s “reality”∗ It is a slippery slope, as some teams may think that
ü Planning is not required in agile projects so they may skip it altogether inviting disasters
üMeeting everyday for 15 minutes (daily scrums) will make them agileü It is only the development team (including QA) that needs to follow agile, other teams (sales, support etc.) can keep doing what they have been doing
29
Avoid Slipping
www.RefineM.com
Challenges in Agile Adoption∗ Mindset/Cultural transformation to become “agile”∗ Dedicated, co-‐located team is not today’s “reality”∗ It is a slippery slope ∗ Alignment of Customer contracts/agreements with agile methodology ü A very high level of customer involvement/collaborationüMore flexible contracts that focus on delivering value earlier in the project life cycle
ü Time & material contracts preferred over fixed cost.ü They could be fixed time and cost but some flexibility in scope is highly desirable
30
Customer Collaboration is THE KEY in Agile projects
9/16/15
16
www.RefineM.com
For Successful Agile Adoption
Everyone needs to be on the same side
31
• Scrum• XP (Extreme Programming)• Lean• Kanban• Other Agile Methodologies
ü AUPü RUPü DSDM
AGILE Methodologies
9/16/15
17
www.RefineM.com
Agile Methodologies
Scrum LeanXPKanban Other
www.RefineM.com
Software Methodologies
28%
39%
7%
12%
2% 12%
Software Methodologies
Waterfall
Agile Scrum
XP
Agile (other)
No methodology
Cow Boy Coding
9/16/15
18
www.RefineM.com
Scrum
www.RefineM.com
ScrumScrum is an iterative and incremental agile software
development framework that focuses on delivering the highest business value in the shortest time. ü It has been around since early 1990s.ü Its primary champions and creators were Ken Schwaber and Jeff Sutherland.
ü It is built upon the three pillars of Transparency, Inspection and Adaptation.
ü It is a highly iterative methodology. üWhile things may repeat, that does not mean that they are identical each time. Rather, the team makes small improvements and changes throughout the project life cycle.
9/16/15
19
www.RefineM.com
Scrum Rolesü Product owner -‐ represents the stakeholders and is the voice of the customer. He or she is accountable for ensuring that the team delivers value to the business. Develops and maintains product backlog.
ü Scrum Master -‐ Scrum is facilitated by a Scrum Master, who is responsible for helping the team follow the Scrum process. He/she is also accountable for removing impediments to the ability of the team to deliver the sprint goal/deliverables.
ü Agile teams -‐ are formed (mostly) of generalizing specialists. A generalizing specialist, sometimes called a craftsperson, is someone who has one or more technical specialties.
What about other roles such as BA, QA and PM?
www.RefineM.com
Scrum CeremoniesSprint Planning:
If sprint duration is 2 weeks then sprint planning meeting is 2*2 = 4 hrsIf sprint duration is 4 weeks then sprint planning meeting is 4*2 = 8 hrs
Part 1 focuses on what the team is being asked to build and is attended by both the product owner and the team. Part 2 focuses on how the team plans to build the desired functionality. Although the entire team must attend Part 2, attendance by the product owner is optional.
Sprint Review: At the end of each sprint a sprint review meeting is held. During this meeting
the Scrum team shows what they accomplished during the sprint. Typically this takes the form of a demo of the new features.
38
9/16/15
20
www.RefineM.com
Scrum Ceremonies
Sprint Retrospective:The sprint retrospective is usually the last thing done in a sprint. Many teams will do it immediately after the sprint review. The entire team, including both the Scrum Master and the product owner should participate.
Daily Standup Meetings:Scrum daily standup meetings are strictly time-‐boxed to 15 minutes. All team members are required to attend the Scrum meetings including the scrum master and product owner. Everyone needs to respond to three questions;
1. What did I accomplish since the last meeting?2. What do I plan to accomplish today?3. What obstacles I am encountering?
39
www.RefineM.com
XP: Extreme ProgrammingüXP: Extreme Programming is a software-‐development –centric
agile method, which focuses on software development good practices.ü It was developed by Kent Beck.ü It is “a light-‐weight methodology for small to medium-‐sized teams developing software in the face of vague or rapidly changing requirements.”
ü In XP, software developers work in pairs. One programmer writes code and the second programmer actively watches. The second programmer is focused on higher level issues such as integration and functionality.
üThe iterations are typically shorter than Scrum iteration; theymay vary from 1-‐3 weeks.
üOne principle of XP is that a team member can not take on more story points in the current iteration than he or she was able to complete in the last iteration.
9/16/15
21
www.RefineM.com
XP Extreme Programming
www.RefineM.com
XP Extreme Practices∗ Planning Games
∗ Small Releases
∗ Simple Design
XP has two primary planning activities, or planning games – release planning and iteration planning. Requirements are recorded on Story Cards developers break these Stories into development ‘Tasks’.
The minimal useful set of functionality that provides business value is developed first. Releases of the system are frequent and incrementally add functionality to the first release.
Enough design is carried out to meet the current requirements and no more.
9/16/15
22
www.RefineM.com
XP Extreme Practices∗ Test first development
∗ Refactoring
∗ Pair Programming
An automated unit test framework is used to write tests for a new piece of functionality before that functionality itself is implemented.
All developers are expected to refactor the code continuously as soon as possible code improvements are found. This keeps the code simple and maintainable.
Developers work in pairs, checking each other’s work and providing the support to always do a good job.
www.RefineM.com
XP Extreme Practices∗ Collective Ownership
∗ Continuous Integration
∗ Sustainable pace
∗ On-‐site Customer
The pairs of developers work on all areas of the system, so that no islands of expertise develop and all the developers own all the code. Anyone can change anything.
As soon as work on a task is complete it is integrated into the whole system. After any such integration, all the unit tests in the system must pass.
Large amounts of over-‐time are not considered acceptable as the net effect is often to reduce code quality and medium term productivity
In an extreme programming process, the customer is a member of the development team and is responsible for bringing system requirements to the team for implementation.
9/16/15
23
www.RefineM.com
XP Extreme Practices∗ Start-‐up XP Practices – Because not all XP teams are ready to follow all XP practices, it may be best to begin with these 6
1. Planning Games2. Small Releases3. Testing/Test Driven Development4. Pair Programming5. Refactoring6. Continuous Integration
The more mature practices may be implemented as the team matures and adapts to XP
www.RefineM.com
XP Roles∗ XP Coach – is the one who ensures that the team adheres to the XP
process and helps the team get better. XP is a disciplined methodology, the Coach will take a more active role in making sure that XP principles are followed. At the same time the Coach should be a supporting role on XP projects and not a top-‐down leader.
∗ XP Customer– is the product expert. He/she makes sure that the right product is built and prioritizes the features. He/she participates in planning and also determines the acceptance criteria to determine “done”.
∗ XP Programmers – work in pairs. The XP pairs makes up the backbone of the team. The are self-‐organizing, self-‐managing component that work on user stories and convert them into working software.
9/16/15
24
www.RefineM.com
XP Roles∗ XP Tracker – evaluates and communicates progress against the plan.
Following are the three basic things that the XP Tracker will trackü The release plan (user stories)ü The iteration plan (tasks), andü The acceptance tests
∗ XP Tester – helps the Customer take the acceptance criteria and translate them into acceptance tests. The Tester is responsible for executing these tests and communicating the results to the entire team
XP means FAST PACED
www.RefineM.com
LEAN
9/16/15
25
www.RefineM.com
LEANü Lean: The Lean Software Development was derived from the
production processes adopted by Toyota. It focuses on a demand-‐driven approach with an emphasis on:üBuilding only what is needed üEliminating anything that does not add value üStopping production if something goes wrong
www.RefineM.com
LEAN – Types of WastesThree types of waste
ü Waste in code development
ü Waste in project management
ü Waste in workforce potential
9/16/15
26
www.RefineM.com
LEAN – 7 Principles
1. Eliminate Waste – ruthless about eliminating it
2. Amplify Learning – continuous learning and improvements
3. Decide As Late As Possible – keep more options open
4. Deliver As Fast As Possible – to the customer
5. Empower the Team – to make decisions
6. Build Integrity In -‐ refactor7. Optimize the Whole – one solution rather than ten
separate solutions cobbled together
www.RefineM.com
Kanban
∗ Kanban: Kanban literally means “visual card,” “signboard,” or “billboard.”ü Toyota originally used Kanban cards to limit the amount of inventory tied up
in “work in progress” on a manufacturing floor
ü Not only is excess inventory waste, time spent producing it is time that could be expended elsewhere
ü Kanban cards act as a form of “currency” representing how WIP is allowed in a system
ü Kanban reveals bottlenecks dynamically
ü Limiting work-‐in-‐progress reveals the bottlenecks so they can be addressed
9/16/15
27
www.RefineM.com
Kanban
www.RefineM.com
Other Agile Methodologies
RUPThe Rational Unified Process (RUP) is a software engineering framework, created and maintained by the people at Rational Software (now owned by IBM). It is a commercial product delivered as a more detailed version of the Unified Software Development Process (which is presented as a generic public domain process). This also means that the RUP suffers from the same problem as the USDP, being bloated and too costly to customize for small projects.
54
9/16/15
28
www.RefineM.com
Other Agile Methodologies
AUPAgile Unified Process is a simplified version of Rational Unified Process (RUP). It describes a simple, easy to understand approach to developing business application software using agile techniques and concepts yet still remaining true to the RUP.
55
www.RefineM.com
Other Agile MethodologiesDSDMDynamic Systems Development Method (DSDM) is a agile project management methodology, created and maintained by the UK-‐based DSDM Consortium.It was originally based upon the concepts of Rapid Application Development. DSDM finds itself on the same level as Scrum, meaning that it lists a small number of practices for project management of software development, while leaving the details of the real work (building a product) to be filled in by the development teams.
56
9/16/15
29
www.RefineM.com
∗ Total of 3 iterations∗ In each iteration (5 minutes duration), each team makes a tower of cards
∗ Scoring1. Floor 1 cards – 1 point each2. Floor 2 cards – 2 points each3. Floor 3 cards – 3 points each4. Floor 4 cards – 5 points each5. Floor 5 cards – 10 points each6. Floor 6 cards – 15 points each7. Floor 7 cards – 20 points each
Let us start…
https://www.youtube.com/watch?v=mFotFKvUgB0https://www.youtube.com/watch?v=ivgKaQanz5k
Power of Iterations – A Team Exercise
AGILE TEAMS• Self Organizing Teams• Team Size, Selection & Participation• Colocation• Empowered Teams
9/16/15
30
www.RefineM.com
Self Organizing TeamsWhat is a self-‐organizing team? A group of motivated individuals, who work together towards a goal, have the ability and authority to take decisions and readily adapt to changing demands. Characteristics of a self-‐organizing team:ü They pull work for themselves and don't wait for their leader to assign work. This
ensures a greater sense of ownership and commitment.ü They manage their work (allocation, reallocation, estimation, re-‐estimation, delivery,
and rework) as a group.ü They still require mentoring and coaching, but not "command and control."ü They communicate more with each other, and their commitments are more often to
project teams than to the Scrum Master.ü They understand requirements and aren't afraid to ask clarifying questions.ü They continuously enhance their own skills and recommend innovative ideas and
improvements.
www.RefineM.com
Essentials of Self Organizing Teams∗ Competency
∗ Collaboration
∗ Motivation
∗ Trust and respect
∗ Continuity
9/16/15
31
www.RefineM.com
Team Size, Selection & ParticipationTeam Sizeü Agile teams are small. The recommended size is 7 + or – 2. (5 to 9).
Team Selection ü Be versatile and willing to work as a part of a teamü Plan a sprint and self-‐manage around that plan.ü Understand the product requirements and provide effort estimates.ü Provide technical advice to the product owner so that he or she can understand
the complexity of the requirements and make appropriate decisions.ü Respond to circumstances and adjust processes, standards, and tools to
optimize performance.
Participationü Positive, measurable contribution to the overall success of the projectü Team participation visible to entire teamü Team motivation increases with successful contribution
www.RefineM.com
Colocation∗ Agile advocates team co-‐location like no other methodology.∗ Co-‐locating the process of bringing all of the team members together at one place.
∗ Ideally configured Agile space not only has everyone in the single room, but also removes any barriers in the room.
∗ Co-‐location increases the sense of a single, cohesive team, and the possibility of increased distractions are offset by the richer flow of information.
∗ Co-‐location is just one way in which Agile practitioners seek to do away with silos. Team are not segregated by specialty.
∗ Since the entire team is together, wall space is used to help with collaboration.
Co-‐location & Collaboration is the key in Agile projects5 common communication challenges with virtual teams
9/16/15
32
www.RefineM.com
Empowered TeamsLeadership Stylesü Traditional -‐ “Command and Control”ü Agile -‐ Self Organizing and empowered team
Empowered Teamsü Make and implement decisions to add value to the customerü Set the priority of work, timeframes and make up the teamü Are motivated by how much value they bring to the project
www.RefineM.com
Empowered Teams
ü Organizational buy-‐inü Alignment with corporate
goalsü A shared visionü Clear communication ü Customer involvementü Team accountability to
achieve the agreed upon goals
What is needed to create an empowered team?
9/16/15
33
www.RefineM.com
Feed Forward – A Team ExerciseRulesü Everyone participatesü Talk to as many people as you can ü About 1-‐2 minutes w/each personü Talk only about future/possibilities/ideas or how can you help othersü No talk about the past/no criticism of other’s ideasü Remember or note down 1-‐2 great ideas gathered during your conversationü Total time 15 minutes… but wait …
Your time starts now
AGILE PLANNING & ESTIMATION
• Stakeholder Analysis• Agile Analysis Tools & Techniques• Agile Planning• Agile Estimation• Agile Release Planning
9/16/15
34
www.RefineM.com
Stakeholder - Definition
67
∗ A Stakeholderü Is someone affected by the project outcomes or project activitiesü Is someone who can influence the project outcomes or project activities
∗ Primary vs. Secondary Stakeholdersü Primary stakeholders have a stake in the project and are involved in all aspects of the project
ü Secondary stakeholders have indirect impact on the business operations or growth
www.RefineM.com
Stakeholder - Best Practices∗ Define WHO is a “Stakeholder”
üWho has a stake or üWho has ability to influence
∗ Identify ALL the Stakeholders
∗ Develop Stakeholder Register
∗ Perform Stakeholder analysis to develop∗ Stakeholder Influence Matrix∗ Communication Plan
68
9/16/15
35
www.RefineM.com
Stakeholder - Tools and Templates
69
∗ Stakeholder Register∗ Stakeholder Influence Matrix
www.RefineM.com
Stakeholder Register
70
9/16/15
36
www.RefineM.com
Stakeholder Influence Matrix
71
www.RefineM.com
Agile Analysis Tools & Techniques∗ Brainstormingü Getting input from many
participants in a rapid fire round and allowing people to speak when they have a idea until all the ideas are captured
ü Fosters creativity, and involves the entire team
ü Ideas are evaluated based on merit and not based on who suggested it
When was your last Brainstorming Exercise?
9/16/15
37
www.RefineM.com
Agile Analysis Tools & Techniques∗ Innovation Gamesü20/20 Vision -‐ All the features are posted as postcards, and the facilitator helps to sort all the cards according to their importanceüThe Apprentice -‐ one of the team members sits back and observes how other team members interact with the systemüBuy A Feature -‐ Estimations (effort & Price) are shown to stakeholders. Based on the available cash, the product owner & teams work towards developing those selected by the stakeholderüProduct Box -‐ Stakeholders design a retail box with most important features to entice the buyers üPrune the Product Tree -‐ product is mapped onto a wall whose trunk and limbs represent larger components, and smaller branches represent features. The finished features are removed logically by pruning the branches
www.RefineM.com
Agile Analysis Tools & Techniques∗ Root Cause Analysis: Root cause analysis (RCA) is a method of problem solving that tries to identify the root causes of faults or problems that cause operating events.ü Root cause analysis aims at finding the core issue that is
causing the problemü Through cause and effect diagrams / Ishikawa diagrams /
Fishbone diagramsü Answer five Why’s? To get to the root cause by the fifth
iteration
9/16/15
38
www.RefineM.com
Agile Analysis Tools & Techniques∗ Root Cause Analysis Example
ü Effect: The vehicle failed its annual emission testü Why? Check engine light was onü Why? The oxygen sensor had failedü Why? The fuel injectors had not been properly cleaned, resulting in an
improper burnü Why? The staff was not factory trained for maintenance ü Understand the real underlying issues at work
Statement of the Problem
(Production Errors)
Manufacturing Inspections
Assembly Packaging
www.RefineM.com
Agile Analysis Tools & Techniques∗ Force Field Analysis
ü Tool provides an objective way to analyze the forces for and against change to make a more fact based decision about whether or not to proceed with a decision
Restraining Forces
Driving Forces
Existing server hardware is old
Lower overall costs
Increased platform stability
Initial conversion cost
Data security concerns
Integration concerns with existing products
ExerciseCreate a Force Field Analysis for “Moving from Waterfall to Agile” in your company.
9/16/15
39
www.RefineM.com
Agile Analysis Tools & Techniques∗ Parking Lotü Piece of paper posted onto the
wallü Used in requirements gathering
when stakeholders bring up a point that may be important but off topic
www.RefineM.com
Agile Planningü Accuracy of estimatesü Customer valueü Product vision statementü Product roadmapü Personasü Wireframesü Agile themesü Epic stories (capabilities)ü User storiesü Story cards
ü Story mapsü Featuresü Minimal marketable featuresü Tasksü Value stream mapping ü Progressive elaborationü Rolling wave planningü Test-‐first development ü The definition of done
9/16/15
40
www.RefineM.com
Agile Planning∗ Accuracy of estimates
ü They vary over time and also known as cone of uncertaintyü Estimates should get sharper over time towards the end of the project
www.RefineM.com
Agile Planning
∗ Customer valueü Delivering value to the customer trumps most other things on
an agile projectü Agile projects perform exceedingly well than other
methodologies to deliver customer valueü Planning is done so that customer value is delivered at the end
of each iteration
9/16/15
41
www.RefineM.com
Agile Planning
∗ Product vision statementü Vision statement sets the direction for the business planningü It does not tell you how to get there but creates an idea of
where to reach
www.RefineM.com
Agile Planning∗ Product Roadmapü A product roadmap is a high-‐level plan that describes how the
product is likely to grow. ü It allows you to express where you want to take your product.
Sample product roadmap that shows the anticipated development of a virtual shopping assistant
9/16/15
42
www.RefineM.com
Agile Planning∗ Personas
ü Personas are fictional characters created to represent the different user types within a targeted demographic, attitude and/or behavior set that might use a site, brand or product in a similar way.
www.RefineM.com
Agile Planning∗ Wireframes
ü The wireframe is usually: black and white,
ü accompanied by some annotations to describe the behavior of the elements, their relationships and their importance,
ü often put in context within a storyboard (a sequence of screens in a key scenario)
ü refined again and againü used as a communication tool
serving as an element of conversation and confirmation of ”agile” user stories
9/16/15
43
www.RefineM.com
Agile PlanningUser Stories∗ A User Story is a requirement (business function) that adds value to the userü Scenario (clear and adds value)• “As a loan officer, I want to know a credit rating, so that I can approve a loan”
ü Captured on a Story Card
www.RefineM.com
Agile Planning∗ Story Cards
ü A user story card has 3 partsü Card: A written description of
the user story for planning purposes and as a reminder,
ü Conversation: A section for capturing further information about the user story and details of any conversations.
ü Confirmation: A section to convey what tests will be carried out to confirm the user story is complete and working as expected.
9/16/15
44
www.RefineM.com
Agile PlanningAttributes of a User Story∗ XP advocate, Bill Wake, describes six attributes of a user story.
ExerciseWrite 2 user stories from your current project on the index cards provided.1 story per index card.
www.RefineM.com
Agile Planning∗ Agile Themesü A set of related user stories ü Ideally user stories are broken down as small as possible, whilst
also trying to minimize dependenciesü Breaking the user stories down smaller can make them more
interrelatedü Themes are used to categorize these related but small user
stories under one label and keep them together
9/16/15
45
www.RefineM.com
Agile Planning∗ Epic Storiesü An Agile Epic is a group of related user stories. ü It is unlikely to introduce an Epic into a sprint without first
breaking it down into it’s component user stories to reduce uncertainty
www.RefineM.com
Agile PlanningStory maps
ü Story maps are great to elicit the core functionality of a product from a user-‐centric point of view. It gets the stakeholders to focus on what the customers or users must do in order for the product to be useful
9/16/15
46
www.RefineM.com
Story Mapping
www.RefineM.com
Agile PlanningFeatureü Is something that adds value to the customerü It is a small, client-‐valued function expressed in the form
action, result, object. ü A feature is a set of related storiesü For example• Change Sale Quantity• Apply Discount• Show Sales Price• Add Shipping• Add Taxes• Complete Transaction
9/16/15
47
www.RefineM.com
Agile PlanningMinimal Marketable Featureü Minimum set of features coupled together that are
independently deliverable and marketable, offering value to the end customer.
ü The "Minimum" represents a point beyond which if the feature is split will no longer be marketable to the end customer.
ü An MMF doesn’t decompose down into smaller sub-‐features, but it is big enough to launch on its own.
www.RefineM.com
Agile PlanningTasksü During the Iteration Planning meeting, stories and sometimes
defects are broken down into tasksü The tasks are all the work the team must complete to develop,
test and accept the story as “done”. ü Tasks typically range in size from 1 hour to 2 days, depending
on the length of the iteration. ü Two-‐week iterations ideally have tasks of 8 hours or less, and
four week iterations have tasks sized at 2 days or less. ü Tasks larger than these guidelines should be broken down
further to allow the team to incrementally complete the work and show progress.
What is the average size of tasks in your Agile projects?
9/16/15
48
www.RefineM.com
Agile PlanningProgressive elaboration & Rolling Wave Planningü The terms progressive elaboration and rolling wave planning
are used interchangeably as both the processes acknowledge the fact that the scope is variable within specified time and cost constraints and thus speculating too much into the future may be an wasteful effort
ü Under progressive elaboration, the characteristics of the product emerge over a period of time, “progressively”.
ü Rolling Wave Planning is a technique that enables you to plan for a project as it unfolds.
ü Rolling Wave Planning requires you to plan iteratively. ü Essentially, when you use Rolling Wave Planning, plan until you
have visibility, implement, and then re-‐plan.
www.RefineM.com
Agile PlanningTest First Development or Test-‐Driven Development ü Is a novel approach to software engineering that consists of
short development iterations where the test case(s) covering a new functionality are written first.
ü The implementation code necessary to pass the tests is implemented afterwards then tested against the test cases.
ü In this approach, writing the code is done with a greedy approach, i.e. writing just enough to make tests pass, and the coding per TDD cycle is usually only a one-‐to-‐at most-‐few short method, functions or objects that is called by the new test, i.e. small increments of code.
ü Defects are fixed and components are re-‐factored to accommodate changes.
9/16/15
49
www.RefineM.com
Agile PlanningDefinition of Doneü Deliverables that add verifiable/demonstrable addition of value
to the product are part of the definition of done, such as writing code, coding comments, unit testing, integration testing, release notes, design documents etc.
ü Definition of done helps frame our thinking to identify deliverables that a team has to complete in order to build software.
ü Focusing on value-‐added steps allows the team to eliminate wasteful activities that complicate software development efforts.
ü It is a simple list of valuable deliverables
What is definition of “Done” in your Agile projects?
www.RefineM.com
Agile Estimation
∗ Relative sizing∗ Wideband Delphi estimating∗ Planning poker∗ Affinity estimating ∗ Ideal time
9/16/15
50
www.RefineM.com
Agile Estimation
∗ Affinity EstimatingüSilent Relative SizingüEditing the wallüPlacing items into relative sizing bucketsüProduct owner challengeüStoring the data
www.RefineM.com
Agile Estimation∗ Relative sizing
ü Relative story point estimation is a consensus based technique that is applied at the product backlog level
ü The measurement unit utilized during relative estimation is not time based but rather, size based. Size in this case does not have a direct relationship to a specific time duration but instead, it is a function of three factors: effort, complexity and risk.
ü These sizes are measured in units that we call ‘story points’ and typically, a slightly altered Fibonacci sequence is used as the point system: 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞
ü The reason for using the Fibonacci sequence is to reflect the inherent uncertainty when estimating larger items.
ü Comparing a story to a previously estimated user story to obtain an estimate
9/16/15
51
www.RefineM.com
Story Point Estimation – Group Exercise ∗ Estimate the size of following stories in Story Points
1. As a user I would like to register and login so that I can purchase the products.
2. As a user I should get email notifications whenever a transaction is successful and products are shipped to my address
3. As a seller I can register & login to provide my information & place ads on my login page visible to the USERs, and able to upload any number of products to do my business online.
4. As a seller I want to see all the orders that are processed for the day along with the shipping information in one page.
5. As an administrator I should be able to login to the site backend to monitor the fraudulent activity of buyers and seller so that I can edit/delete/restrict any account access as a master administrator
Keep these #s, we’ll need them for another Exercise
www.RefineM.com
Agile Estimation∗ Wideband Delphi Estimating
ü Wideband Delphi is a process that a team can use to generate an estimate. ü The project manager chooses an estimation team, and gains consensus
among that team on the results. ü Wideband Delphi is a repeatable estimation process because it consists of a
straightforward set of steps that can be performed the same way each time.• Kickoff meeting – issues regarding estimation are discussed not the estimates• Individual prepare their estimates• Manager gathers all the estimates and lists/plots them, showing the distribution of values without putting names against them.
• Team discusses the range and try to reach a consensus.• This continues until the range of estimates become acceptable or time limit is reached.
9/16/15
52
www.RefineM.com
Agile Estimation∗ Planning Poker
üMeeting(Product Owner, Team , Scrum Master)üRequired: deck of cards with Fibonacci for each team member
Steps:üEach team member is given a set of cardsüProduct Owner: reads & describes the product to the team and a discussion can be held for few minutes until each one is clear with the requirement of the story
üEstimate: when the estimate is done each team will pick an estimate and other will not see it
üReveal: all the team members when finish picking up and cards are turned at the same time
üDiscuss Differences: from outliners (high low)üRe-‐estimate until the agreement is reached or time out.
www.RefineM.com
Let us play Planning Poker
∗ Let us play planning poker to estimate following tasks1. Mow the lawn2. Weekly grocery shopping3. Take the kid to the ball game4. Do the laundry5. Plan for the birthday party
9/16/15
53
www.RefineM.com
Agile Estimation
∗ Ideal time üOne management practice in waterfall is that you might estimate everything you do in ideal time.
üIdeal time is how long a task takes if there were no interruptions. And when you plan you don’t plan that all work is 100% focused and non-‐interrupted.
üInstead one can calculate with a velocity. Velocity is the number of user stories (or user story points) you can do in one iteration (or sprint). In Scrum this is known as the focus-‐factor.
www.RefineM.com
Agile Release Planning
∗ Releases -‐ are deliverables of features, benefits and value to the customer.
∗ Iteration – An iteration is a smaller than a release and is more technically oriented
∗ There are usually multiple iterations that make up a single release.
∗ It is important to stress that release plan is neither a directive by the product owner nor a firm contract with the team.
∗ It is a plan and plans can be very fluid in Agile world.
9/16/15
54
www.RefineM.com
Your challenges?
∗What kind of planning and estimation challenges do you face in your Agile projects?
Some Fun J
Are you agile?http://www.youtube.com/watch?v=4IJYveGZLUc
7 Red Perpendicular Lineshttps://www.youtube.com/watch?v=BKorP55Aqvg
9/16/15
55
Agile Project Execution• Agile Backlogs (Product Release
Backlog & Iteration Backlogs)• Agile Metrics (Velocity, Cycle Time, • Burn Rate, Escaped Defects etc.)• Information Radiators
www.RefineM.com
Agile Backlogs∗ Product Backlog contains
ü Themes-‐ very top-‐level requirements or objectives e.g. A new websiteü Epics – very large user stories e.g. A new website sectionü User Stories – an Independent, Negotiable, Valuable, Estimatable, Small,
Testable (“INVEST”) piece of functionalityü As items rise to the top of the product backlog i.e. become higher priority,
the Product Owner will work with the team to break Themes and Epics into User Stories
ü Once broken down into User Stories, the Team will provide delivery estimations and commit to delivering a number of these stories (in line with pre-‐defined priorities) in the following sprint.
ü The Product Owner will then begin to define, prioritize and add additional User Stories to the backlog in preparation for the next sprint – this might include new requirements or changes emerging from the previous sprint.
9/16/15
56
www.RefineM.com
Product Backlog
www.RefineM.com
Release Backlogs∗ Release Backlog
ü A Release Backlog is a limited set of items from the Product Backlog selected for a specific release. While the product backlog may contain all of the wish list for the product without regard of time-‐frame, the release backlog is focused to specific objectives or goals identified for a specific time-‐frame.
9/16/15
57
www.RefineM.com
Release Planning meeting duration ü If Project duration is 1 year then Release planning should be completed in 1 month approximately
ü If Project duration is 6 months then Release planning should be completed in 15 days approximately
ü If Project duration is 3 months then Release planning should be completed in 7.5 days approximately
Release Backlog & Planning
www.RefineM.com
Agile Backlogs (Product & Sprint)∗ Sprint/Iteration Backlog:ü The Sprint Backlog is the output of the sprint planning meeting.ü It is essentially the list of tasks that the Scrum team needs to
complete during the sprint in order to turn a selected set of product backlog items into a deliverable increment of functionality.
ü Unlike product backlog items, sprint backlog tasks have a time-‐based (hourly) estimate.
ü Since the core scrum team is doing the work, they are responsible for keeping the Sprint Backlog up to date.
9/16/15
58
www.RefineM.com
Key Agile Metrics∗ Sprint Backlog:ü During a sprint, new tasks may be discovered and adjusted.
This is perfectly normal behavior. ü The Scrum team simply adds the new tasks to the sprint
backlog or adjusts the wording for tasks in progress. ü As the Scrum team completes tasks, they should be marked on
the sprint backlog. ü The sprint backlog shows the scrum team members what is
complete and what remains. This data will help team members run an effective daily scrum meeting.
www.RefineM.com
Key Agile Metrics∗ Velocityü Velocity is a measurement of how much the team gets done in
an iteration ( called as Sprint in Scrum ). It is the # of features or user stories that a team delivers in a fixed iteration.
∗ Cycle Time ü The amount of time needed to complete a feature or user story
∗ Ideal Timeü The amount of time an assignment would take if there were no
interruptions or distractions
∗ Burn Rateü Burn rate is the cost of the Agile team, or the rate at which it
consumes resources.
9/16/15
59
www.RefineM.com
Key Agile Metrics∗ Escaped Defectsü Escaped Defects are those defects reported by the Customer
that have escaped all software quality processesü They should then be treated as ranked backlog work items,
along with other project work items
To be able to calculate that metric, it is important that in your defect tracking system you track:üaffected version, version of software in which this defect was found.ü release date, date when version was released
www.RefineM.com
Information Radiatorsü An information radiator is a large display of critical team information that is
continuously updated and located in a spot where the team can see it constantly.
ü Information radiators are typically used to display the state of work packages, the condition of tests or the progress of the team.
ü Team members are usually free to update the information radiator. Some information radiators may have rules about how they are updated.
ü Whiteboards, flip charts, poster boards or large electronic displays can all be used as the base media for an information radiator
ü Information radiators help amplify feedback, empower teams and focus a team on work results.
ü In keeping with the agile value of Communication, agile teams often place large charts and graphs in their workspaces to radiate important information such as defect rates, rate of completion, and measures of code goodness (CRC, bugs, test counts).
9/16/15
60
www.RefineM.com
Information RadiatorsBurndown Chart
Ever heard of Burn Up Charts?
www.RefineM.com
Information Radiators
ü Task Boards
ü Flip Charts
ü Poster Boards
9/16/15
61
www.RefineM.com
Agile Retrospectives
121
∗ “An Agile Retrospective is a meeting that is held at the end of a iteration in the Agile Software Development. During the retrospective, the team reflects on what happened in the iteration and identifies actions moving forward.”
“A retrospective is an opportunity for the participants to learn how to improve. The focus is on learning, not fault-finding.”
Norm Kerth
www.RefineM.com
Basic outcome of Agile Retrospective:∗ There are three basic questions asked to everyone in a Agile Retrospective:üWhat went well?üWhat did not go well and could be improved?üWhat action should be taken to improve?
9/16/15
62
www.RefineM.com
When the team conduct a good retrospective following positive outcomes are normally expected:
üAbility to develop and deliver software steadily improvesüTeam grows closer and more cohesiveüMore transparency among team members, which helps team members understand and respect issues other team members face
üHonest and open about success and failureüMore comfortable and flexible towards positive change.
Benefits of Agile Retrospective
www.RefineM.com
1. Set the Stage
2. Gather Data
3. Generate Insights
4. Decision on Change/Action
5. Close Retrospective
Agile Retrospective Basic Process
9/16/15
63
www.RefineM.com
Agile Retrospective Duration
This is for a general idea, time can vary based on different variable factors
If my sprint is this long….
My Sprint retrospective meeting should last…
One week 45 minutes
Two weeks 1.5 hours
Three weeks 2.25 hours
Four weeks 3 hours
www.RefineM.com
Let us do retrospective for today’s session
üWhat went well?üWhat could be better?üWhat are the action items?
Agile Retrospective – An Exercise
9/16/15
64
Last, and Lasting Thoughts?• Is AGILE a silver bullet?• Most suitable candidates for Agile• Agile/Scrum Steps• Agile Tools
www.RefineM.com
Is AGILE a silver bullet?Organizational Context/Environment
128
Stacey Diagram
9/16/15
65
www.RefineM.com
Most suitable candidates for Agile1. Projects where the leader/sponsor has a clear vision but all
the requirements can’t be spelled out upfront2. The requirements are evolving, things become more clear
with time (cone of uncertainty)3. Changes are expected, even late in the project life cycle4. The time and the cost are fixed, but the scope is flexible5. Sponsors, customers and stakeholders are anxious to consume
the low hanging fruits ASAP without waiting for entire project to finish.
6. Customers are highly involved in the project
129
Any project that has such attributes is a good fit for Agile, Otherwise NOT
www.RefineM.com
Agile/Scrum Steps1. Develop product vision/roadmap2. Budget time & cost for the project (time-boxed, fixed cost)
3. Identify the Product Owner (PO), Scrum Master (SM) and the TEAM Project Sponsor/Executive/Department Head may perform steps 1-3 above
4. Develop product backlog and prioritize it with highest value items at the top – PO working with stakeholders and customers
5. Create release plan – SM working with the PO and the TEAM
6. Start Sprints – TEAM working under guidance of the PO and the SM
130
The project is finished within the given time-frame & cost starting with highest value items delivered first.
9/16/15
66
www.RefineM.com
Agile Tools1. MS Office 2. JIRA/Greenhopper3. VersionOne4. Almost all PPM vendors support Agile
RefineM’s new toolkit – Essential Gear for Agile Teams
131
www.RefineM.com
Recommended ReadingMike Cohn. Agile Estimating and Planning.
Mike Cohn. User Stories Applied: For Agile Software Development.
Ken Schwaber.Agile Project Management with Scrum.
Alistair Cockburn. Agile Software Development: The Cooperative Game, 2nd edition
James Shore. The Art of Agile Development.
132
9/16/15
67
www.RefineM.com
Let us become AGILE
133
www.RefineM.com
__________________________________________________________________
NK Shrivastava, MBA, PMP, RMP, ACPCEO/Consultant, RefineMNixa, MO 65714, [email protected], www.refinem.com
http://www.linkedin.com/in/nkshrivastava @justrightpm
Questions?
134
9/16/15
68
Additional Slides
www.RefineM.com
Waterfall Vs. AgileFactors Waterfall Agile
Size Large projects and large teams Small projects and small teams
Mission-‐Critical Long history of use in such implementations
Untested ; no prior organizational assets or documents
Stability & Complexity of the software
Static & complex environments
Dynamic & simple environments
Skills High skills in initial stages and low skills in later stages
High skills in all the stages
Organizational culture Structured Chaotic
PM Command and control Participative management
Optimize Productivity & Quality Customer Satisfaction, Project success, and Risk-‐reduction
Customer Takes backseat Actively involved
Communicate Slow Quicker
Decisions Emphasized presence of customer
Decision making data/“on the fly”
Change Resist change Embrace change
Deliverable At the end end of each sprint
Retrospectives/Lessons Learned At the end After each iteration136
9/16/15
69
• Value based Prioritizationü PV, NPV, IRR, ROI
• Chartering• Project Charter
Project Justification
www.RefineM.com
Value Based Prioritization∗ Every project is evaluated through decision criteria to guide the decision of whether or not to pursue it. Some of the criteria are: ü Importance of the project to public benefitü Stakeholder decision to take up the projectü Heuristic approach to evaluate all the choices and select an optimal choiceü Economic benefit analysis
• Present Value (PV)• Net Present Value (NPV)• Internal Rate of Return (IRR)• Return on Investment (ROI)
9/16/15
70
www.RefineM.com
Present Value (PV)
139
∗ Present Value – is based on the “time value of money”. It is the current value of future cash flows discounted at the appropriate discount rate.PV= FV / (1+ r)t PV= Present Value ; FV=Future Valuer = Rate of Interest; t = Time period
RuleWhen deciding between projects in which to invest, the choice can be made by comparing respective present values discounted at the same interest rate, or rate of return. The project with the least present value, i.e. that costs the least today, should be chosen
www.RefineM.com
Present Value Example Suppose you need $400 to buy textbooks next year. You can earn 7 percent on your money. How much do you have to put up today?We need to know the PV of $400 in one year at 7 %.
Present value $400 (1/1.07) = $373.83
Thus, $373.83 is the present value. Again, this just means that investing thisamount for one year at 7 percent will result in your having a future value of $400.
140
9/16/15
71
www.RefineM.com
Net Present Value (NPV)
141
∗ Net Present Value – is the same as Present Value except that you factor in the costs. NPV is frequently estimated by calculating the present value of the future cash flows (to estimate market value) and then subtracting the cost. NPV= PV-‐CostPV= Present Value ; FV=Future Valuer = Rate of Interest; t = Time period
RuleAn investment should be accepted if the net present value is positive and rejected if it is negative.
www.RefineM.com
Internal Rate of ReturnIRR: The discount rate that makes the NPV of an investment zero.Rule: An investment is acceptable if the IRR exceeds the required return. It should be rejected otherwise.A project has a total up-‐front cost of $435.44. The cash flows are $100 in the first year, $200 in the second year, and $300 in the third year. What’s the IRR? If we require an 18 percent return, should we make this investment? The NPV is zero at 15 percent, so 15 percent is the IRR. If we require an 18 percent return, then we should not make the investment. The reason is that the NPV is negative at 18 percent (verify that it is $24.47). The IRR rule tells us the same thing in this case. We shouldn’t make this investment because its 15 percent return is below our required 18 percent return.
9/16/15
72
www.RefineM.com
Return on Investment (ROI)ROI: It is a commonly used ratio that measures the returns generated by a particular amount of invested money, based on business liabilities.
ROI = Earnings – Initial InvestmentInitial Investment
Rule: the bigger the return on investment, better it is.
For example, if you invest $100,000 to buy cooking equipment for a new restaurant that generates $40,000 after one year, the ROI is 40 percent (40,000 divided by 100,000 times 100).
www.RefineM.com
Chartering∗ Chartering -‐ is the most important process of developing a Project Charter, which establishes vision, defines purpose/goals & objectives and constraints, and captures project scope & customer expectations. The key chartering activities, from an agile perspective are;ü Establishing Vision, Mission and product roadmapü Establishing a view towards a Minimum Viable Product (MVP) or Minimal Marketable Product
(MMP)ü Running Sprint #0’s as needed; when your project and/or your team needs “directional
alignmentӟ Establishing effective release plans that align the Product Backlog with the Mission & Vision
The charter should be written as part of Iteration Zero if it does not already exist
9/16/15
73
www.RefineM.com
Project Charter
www.RefineM.com
Kanban
9/16/15
74
Some Fun J
Are you agile?http://www.youtube.com/watch?v=4IJYveGZLUc
7 Red Perpendicular Lineshttps://www.youtube.com/watch?v=BKorP55Aqvg
![1 Abstract0 0 2 Introduction0 3 Requirements0 · Version:4.2.2" Effective0Date:"October"27,"2010"" " " Posted"on"theDACC"websiteon"[date]"by"[username]" Page7"of"14" " Supplementary](https://static.fdocuments.in/doc/165x107/60113ff7cca9491d3c5898ba/1-abstract0-0-2-introduction0-3-requirements0-version422-effective0dateoctober272010.jpg)
![Macbeth Introduction0[1]](https://static.fdocuments.in/doc/165x107/577d228f1a28ab4e1e97b965/macbeth-introduction01.jpg)
