Upload
scott-ocamb
View
130
Download
1
Embed Size (px)
DESCRIPTION
This presentation discusses the delivery of software using an agile approach. We open with the Agile Manifesto followed by a discussion of the mechanics of Scrum. We then discuss an agile team, how the backlog fits into the picture, risk and how we can predict dates. This was presented to the Emerging Technology Class at Temple University on April 3rd, 2013.
Citation preview
Agile Software DeliveryScott Ocamb, Turnberry Solutions
2 Agile Software Delivery
• Agile Manifesto and why it is important• Introduction to Scrum• Agile Software Delivery• The Team• Delivering Software at a Steady Pace• The Backlog• Risks• Value• Output vs Outcome• Predicting Dates• Closing Thoughts• Questions Anytime!
Agenda
3 Agile Software Delivery
The Old Way to Build Software
4 Agile Software Delivery
• 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.
Agile Manifesto
5 Agile Software Delivery
• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Agile Manifesto - Principles
6 Agile Software Delivery
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity--the art of maximizing the amount of work not done--is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Agile Manifesto - Principles cont.
7 Agile Software Delivery
Building Software is Hard!
8 Agile Software Delivery
The Mechanics of Scrum
9 Agile Software Delivery
It’s all about the Product and the Customer
10 Agile Software Delivery
Agile Software Delivery
11 Agile Software Delivery
We Need a Team
12 Agile Software Delivery
Agile Team
• The Product is what the team is delivering
• The Customer is paying for the product and is typically comprised of a number of stakeholders
• The Product Owner knows the most about the product and has a passion for it
• The Agile Coach is an expert in the practice of agile and acts as a servant leader for the team
• The delivery team is a self motivated group of experts whose goal is to deliver high quality software
• All of this is tied together with communication that agile practices reinforce
13 Agile Software Delivery
Delivering Software at a Steady Pace
14 Agile Software Delivery
Delivering Software
• A User Story is a feature that resides in the Backlog
• There are Small and Large user stories
• This “size” is determined by the team with help from the Product owner and is measured in Story Points or Ideal Hours
• Over time, the number of user stories the team can deliver in a sprint is predictable
• Communication is always key
15 Agile Software Delivery
We Cannot do it All
16 Agile Software Delivery
The product owner has many good ideas. She seems to come up with more each day.
Backlog
17 Agile Software Delivery
It is up to the Product Owner to work with the customers to decide what the team should and, more importantly, should not deliver. These decisions are made at Release Planning.Being a Product Owner is hard. She must build trusting relationships with the Customers so when difficult conversations occur, they are easier.
Backlog Cont.
18 Agile Software Delivery
All features are not the same. Some have more value than others. They have different sizes as well. If a feature has a high value and small size, we build it early.
Backlog Cont.
19 Agile Software Delivery
The stories we plan to deliver are kept in the backlog. The most understood and defined stories are in the front of the backlog ready for sprint planning. The others are kept toward the back and will be defined later.
Backlog cont.
20 Agile Software Delivery
We Have Risks
21 Agile Software Delivery
• Business Risk – Are we building the right product
• Skills Risk – Does our team have the right skills
• Cost / Schedule – Have we defined a proper release schedule and is there flexibility in our budget
• Technical – do we have the proper architecture for what we need to deliver
Risk
22 Agile Software Delivery
• You can have it Fast and Good, but it won’t be Cheap
• You Can have it Good and Cheap but it won’t be Fast
• You can have it Cheap and Fast but it won’t be Good
A Mentor of Mine Said “You Can Have Two”
23 Agile Software Delivery
• The Product owner will want all of her features and to Build the Right Thing
• The development team is technical and wants to Build the Thing Right
• The Agile Coach wants to deliver the product as soon as possible and wants to Build it Fast
• Considerations:– Fast Time to market– Fixed set of features– Scale up
Trade Offs
24 Agile Software Delivery
Our Product Needs to be High Value
25 Agile Software Delivery
Given the chart with Customer Value on the y-axis and time on the x-axis ….
Value
26 Agile Software Delivery
In the beginning, the team is learning. We add Knowledge Value but not much Customer Value.
Value
27 Agile Software Delivery
As we learn, we add more and more Customer Value.
Value
28 Agile Software Delivery
Eventually, the law of diminishing returns sets in and most of the high value features have been added. Remember, the Product Owner has prioritized the Backlog.
Value
29 Agile Software Delivery
At some point, we can stop. This can actually happen before the product tis finished.
Value
30 Agile Software Delivery
Are We Really Adding Value?
31 Agile Software Delivery
Over time we can calculate pace or rate of delivering features by graphing our velocity. Velocity is typically measured in Story Points delivered per Sprint.
Velocity – The Start to Prediction
32 Agile Software Delivery
It is important for us to deliver the right thing. We can deliver many User Stories, but are they really what we need? The Product Owner working with the Customer will identify the Proper Outcome we need.
Outcome vs Output
33 Agile Software Delivery
Since we are delivering features in short sprints, the Product Owner and Customer can pay close attention to the emerging product. This allows them to make decisions about the product and ensure the Outcome is proper.
Outcome vs Output Cont.
Value = Knowledge Value + Customer Value
We need both
34 Agile Software Delivery
When Will we Get There?
35 Agile Software Delivery
Our Product Owner asked us what we can complete by the end of November. This is a Fixed Time request.
Predicting Dates – Fixed Time
36 Agile Software Delivery
Using our chart, we can see that we can deliver 300 – 400 Story Points by the end of November.
Predicting Dates – Fixed Time
37 Agile Software Delivery
So we say we can deliver stories with a total size of 300 and 400 points by the end of November. It will be up to the Product owner to Prioritize the backlog and thus select the stories that will be delivered.
Predicting Dates – Fixed Time
38 Agile Software Delivery
Our Product Owner may ask when we can complete a specific set of stories. This is a Fixed Scope Project. Using our chart, we say we can deliver your stories between November and December.
Predicting Dates – Fixed Scope
39 Agile Software Delivery
Our Product Owner may ask if we can deliver stories with a total size of 500 on November 30th. This is the Fixed Scope and Time request. We look at our chart and say, “Sorry not possible, But…..”
Predicting Dates – Scope and Fixed Time
40 Agile Software Delivery
We can deliver the stories with a size of about 300 by your date.
Predicting Dates – Fixed Time and Scope
41 Agile Software Delivery
We will need till about the end of December to deliver your request of 500 points.
Predicting Dates – Fixed Time and Scope
42 Agile Software Delivery
It is better to work on the 300 points first ….
Predicting Dates – Fixed Time and Scope
43 Agile Software Delivery
Then, do the remaining work if we have the time.
Predicting Dates – Fixed Time and Scope
44 Agile Software Delivery
It’s All About Results and Value
45 Agile Software Delivery
Points to Ponder
Flexible Courage
Transparent
Adapt
TrustHonest
FailureConflict
46 Agile Software Delivery
• The global middle class will triple by 2030
• Hundreds of millions of smart people will compete for a limited and ever changing set of high paying jobs
• The lucrative job of this decade will not be the lucrative job of the next
• It is easy to become complacent
Challenges
47 Agile Software Delivery
• Do what you love• Build a network• Start your savings today so you can be
financially independent (Retire)• Save one year’s worth of expenses• Adjust your standard of living• Goal – Have job offers come your way
when you do not need them• Understand that your learning starts the
day you graduate. It does not end
How to be Successful
48 Agile Software Delivery
• The Cost Of Waiting - demonstrates the cost of waiting to save for retirement
• JoelOnSoftware.com - blog on all things software• OcambOnConsulting.com – My Blog• NeverEat Alone – Book on Networking• Mountaingoatsoftware.com - reference on Scrum and Agile
by Mike Cohn• RandsInRepose.com - light hearted and irreverent look and
working with people• Scrum in 10 Minutes – Fast paced introduction of Scrum
Useful Links
49 Agile Software Delivery
Scott OcambTurnberry Solutions, [email protected]@hotmail.com 484-467-8541 (m)Blog: OcambOnConsulting.com Website: RoadmapToAgile.com Twitter: @scottocamb
Scott Ocamb
This presentation is available on Slideshare. Go to RoadmapToAgile.com and look in the New and
Noteworthy section for the link