agile software delivery

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


The Old Way to Build Software


• 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


• 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


• 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.


Building Software is Hard!


The Mechanics of Scrum


It’s all about the Product and the Customer


Agile Software Delivery


We Need a Team


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


Delivering Software at a Steady Pace


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


We Cannot do it All


The product owner has many good ideas. She seems to come up with more each day.

Backlog


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.


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.


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.


We Have Risks


• 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


• 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”


• 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


Our Product Needs to be High Value


Given the chart with Customer Value on the y-axis and time on the x-axis ….

Value


In the beginning, the team is learning. We add Knowledge Value but not much Customer Value.

Value


As we learn, we add more and more Customer Value.

Value


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


At some point, we can stop. This can actually happen before the product tis finished.

Value


Are We Really Adding Value?


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


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


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


When Will we Get There?


Our Product Owner asked us what we can complete by the end of November. This is a Fixed Time request.

Predicting Dates – Fixed Time


Using our chart, we can see that we can deliver 300 – 400 Story Points by the end of November.



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.



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


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


We can deliver the stories with a size of about 300 by your date.

Predicting Dates – Fixed Time and Scope


We will need till about the end of December to deliver your request of 500 points.



It is better to work on the 300 points first ….



Then, do the remaining work if we have the time.



It’s All About Results and Value


Points to Ponder

Flexible Courage

Transparent

Adapt

TrustHonest

FailureConflict


• 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


• 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


• 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

http://bit.ly/T0uTU2

http://joelonsoftware.com/

http://ocambonconsulting.com/

http://www.amazon.com/Never-Eat-Alone-Secrets-Relationship/dp/0385512058

http://www.amazon.com/Never-Eat-Alone-Secrets-Relationship/dp/0385512058

http://www.mountaingoatsoftware.com/

http://www.randsinrepose.com/

http://www.youtube.com/watch?v=XU0llRltyFM


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

mailto:[email protected]



http://turnberrysolutions.com/ocambonconsulting/

http://roadmaptoagile.com/

agile software delivery

Technology