Agile Project Management

Agile Project Management: Embracing Change Sinaporn Suebvisai Agile Evangelist

Speaker’s Background Bachelor Degree in Computer Engineering from Chulalongkorn University in 2001 Master Degree from School of Computer Science, Carnegie Mellon University, in 2004 Joined Thomson Reuters as Software Engineer Became Development Group Leader in 2007 Led the effort to adopt Agile process into the team One of the main Agile advocates in Thomson Reuters Collaboration Team Joined Proteus Technologies as Agile Evangelist late 2008 [email_address]

What is Agile? The Agile Manifesto – Utah 2001 Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

What is Software Project Management? Software Project Management is the art and science of planning and leading software projects . It is a sub - discipline of project management in which software projects are planned, monitored and controlled . [wikipedia] We will control four variables in our projects — cost, time, quality, and scope . Of these, scope provides us the most valuable form of control. [“E xtreme Programming Explained: Embrace Change”, Kent Beck] Without management, project teams may pursue the wrong project, may not include the right mix of personalities or skills, may be impeded by organizational dysfunctionality, or may not deliver as much value as possible . [“The Need for Agile Project Management”, Mike Cohn and Ken Schwaber ]

Why are there changes? Software is a brain product only (from Philosophy of the Course, Software Project Management course at SEI). We’re implementing things that have never been done before. Project uncertainties Budget changes Market changes Resource changes We can’t predict the future

Cost of Change Curve http :// www . ambysoft . com / essays / whyAgileWorksFeedback . html

Why Agile Maybe Your Solution Agile allows you to make changes by utilizing Best Practices Evolutionary Delivery vs. All at Once Barry Boehm’s Spiral Model User Stories Kent Beck’s Xtreme Programming Short, Focused, Meetings of Cross Functional Teams Jeff Sutherland, et al, SCRUM Agile advocates Transparency Always provide information as early as possible which allows making decision faster Agile is completely Value Driven Agile focuses on Working Software at all time Agile Estimating & Planning automatically embodies uncertainties

Agile Techniques User Stories Estimating & Planning Scrum Test Driven Development Continuous Integration Iteration Close-down and Demo Retrospective

User Stories A User Story is a Brief statement of Functionality but told from the User’s perspective. INVEST in User Stories Independent Negotiable Valuable Estimable Small Testable As a <stakeholder> , I want to <goal> so that <reason> .

Story Card User Story Description http :// www . agilemodeling . com / images / models / userStoryFormal . jpg Story ID From Discussion Story Points Exit Criteria

How User Stories Help? Let the customers explain the product in the way they understand Can easily be changed, thrown away when no longer valid, and Prioritized State why customer wants the feature to make an understanding between developer and customer Leave room for discussion Can easily make sure that we finish what we are asked to do

Why Traditional Planning Fails Planning is by Activity rather than Feature Activities don’t finish earlier than planned Lateness is passed down the schedule Activities are not dependent Estimates become Commitments This has to be done by this date and with all these features. Features are not developed by Priority Uncertainty is ignored

Estimating & Planning Story Point Estimation Planning Poker Prioritization Planning a Release Burndown Chart

Story Point Estimation Measure Relative Complexity of User Stories Considers the Entire Efforts of Dev & Test Use the Fibonacci Sequence in order to prevent arguments over a 10% estimate difference. 1, 2, 3, 5, 8, 13, 21, etc… Far less likely for management to successfully play “Time Math” with.

Planning Poker Every team member is given a deck of Planning Poker cards The moderator gives an overview of a given feature The team members ask question and discuss to clarify assumptions and risks. Discussion is recorded When everyone is ready, they simultaneously vote for the estimate If estimates differ, the high and low estimators explain their estimates After another discussion, the team members revote The vote continues until the estimates converge or everybody can agree on one estimate

Prioritization Face the Fact: You may not get everything you want in the time you want BUT you can get what you really want first Prioritization is the key to getting the features that will give the most value to the product Prioritization can change as we learn more about the project Increase Value and Decrease Risks earlier in project

Prioritization in Agile Projects Prioritization in Agile projects is just where you put your story card in the stack Prioritization can be in many levels: Project, Release, Iteration At the end of each Iteration or Release, Priorities can be revised Prioritization is set by Customers with input from the team

Planning a Release A Release (Customer decides what makes a Release) User Stories The one higher to the top has higher priority Iteration Length = Shovel size Velocity = The average amount of sand you can carry in the shovel Release Length = How long it takes to get the sand out with the shovel (DISCOVER)

Burndown Chart 150 125 100 75 50 25 0 1 2 3 4 5 6 7 8 9 10 With estimated velocity, we can estimate how long the release may take. The Burndown chart needs to be updated every iteration to reflect the actual situation.

Burndown Chart (later) http :// www . mountaingoatsoftware . com / system / asset / file / 65 / PredictiveBurndownChart . jpg

Planning an Iteration Start every iteration with an iteration planning meeting Decide on what the team will focus on: We should not move stories in and out during an iteration  Distraction: only 2 hours is never 2 hours Usually, the highest priorities from the Release Split stories to smaller stories if they cannot fit within an iteration The team makes the commitment and sets the expectation for customer

Why Agile Planning Works Instead of creating the perfect plan, create a plan that is useful right now BUT update plan when necessary Effort Size and Duration are separated Duration estimate is harder to match Plans are made at different levels: Project, Release, Iteration State Uncertainty in no Uncertain terms Tracking is at the Team level, not Individual Plans are by Features, not Tasks Transparency Builds Trust and Credibility!

Scrum http://www.mountaingoatsoftware.com/system/hidden_asset/file/17/ScrumLargeLabelled.png

Daily Scrum Meeting Status update from team member Development, QA, Project Manager participitate Customers and users can attend, but cannot speak Start at the same time everyday Keep it short Not more than 30 minutes Stand-up helps to keep it short Each team member: What have you been doing since last SCRUM meeting? What are you doing next? Are there any issues?

Special Thanks to K.Kulawat W. & K.Werachai P. from Thomson Reuters

How Scrum Helps Small Releases Learn before your budget is used up Give your customers a chance to change their mind  They will love you for this  Transparency of Project Status Everybody knows what everybody else is doing Shippable Product at All Time

Test Driven Development Developer is responsible for Unit Tests Testers/QAs also write tests  Functional Tests Encourage developers to make changes without fears The changes that come into the project will require you to make design improvement (refactor) often People like to pay technical debt by hacking things in If you have unit tests, you will feel more at ease in moving things around Refactoring should be every developer’s job and should be done ALL THE TIME

Continuous Integration Continuous integration makes sure you find problems faster In every change that developers make (into the source control system), Continuous Integration must be run If the Continuous Integration fails, the developer MUST fix it immediately Take out the code or Fix the code to pass the fail tests Automation is the KEY

Continuous Integration Unit Tests Functional Tests Integration Tests Deployment Tests Coding Standard Check Code Coverage Notification on Failure and Success

Iteration Close-down meeting Conclude the Iteration Look at the stories that have been closed in this iteration (in the storyboard) Everybody in the team and Customer see the same picture of the project Team feels accomplished Update the Progress in relation to the Release Update Burndown Chart Demo Shippable Software Customers are happy when they see progress Early feedback from customers, which can be used for the next iteration planning

Retrospective Meeting At the end of each Iteration and Release The only way we know where we are is that we know where we’ve been Learn from mistakes, Learn from success Gives a chance for people to speak up Do not let problems pile up Time to Eliminate Wastes Time for Improvement Stop to Breathe

Do s and Don’t s Do s Create Safe Environment Identify Wastes Define Improvement Goals (prioritize your goals also) Define Tracking Method for Improvement Goals Assign the person to track the improvement Don’t s Find people to blame for failure Only a few people speak Not including everybody in the team Do not have any improvement goals at the end of the meeting Decide that the problem is outside the team

Adopting Agile Start with adopting practices that are easier to bring into the project Understand what your goal is in doing each practice before you start doing them Start with a smaller team, and expand to more teams later Each team may not need the same Agile practices Keep improving and adjusting (through retrospective) to find what’s best for your project

References Agile Estimating and Planning Mike Cohn Principles of Software Engineering Management Tom Gilb Agile Retrospectives: Making Good Teams Great Esther Derby, Diana Larsen, Ken Schwaber Extreme Programming Explained: Embrace Change Kent Beck Many other websites, just search for it 

Q&A Thank you ka’  Does anybody have any question?

Agile Project Management

More Related Content

What's hot (20)

Viewers also liked (12)

Similar to Agile Project Management (20)

Recently uploaded (20)

Agile Project Management

Editor's Notes