Agile Project Management. Finding the Optimal Approach

Transcription

1 Agile Project Management Finding the Optimal Approach

2 Overview Dilemmas Find the Optimal Approach Agile Defined (if possible) Methods, Tools and Techniques Agile Concepts in the PMBOK Measurements Pitfalls and Strategies

3 About Me Loren Loiseau, PMP Software Mgr, Bally Technologies MSE, Seattle University 20 years (Boeing, Amazon, GTE, MS, startups) Believer in Agile PMI NNV Policies and Procedures Director

4 References Wikipedia Lean Software Development, ISBN Agile Estimating and Planning, ISBN Practices of an Agile Developer, ISBN

5 Disclaimer Agile project management is not the project management tool Agile. If you thought this was a tutorial, sorry!

6 Dilemmas Scenario: you believe the project team is competent and works hard and yet does not know what the final product will be or how long it will take. Do you let the team work at an optimal level even though the outcome is not completely known? Scenario: estimates are considered promises or contracts. Consequence: estimates are artificially inflated. Do you want to reward good estimators or optimal work? Scenario: the original requirements are inadequate, but changes are difficult due to contractual terms or distrust of the project team. How can the customer get what they need when they don t know what it is?

7 Truths of project teams People generally want to do a good job. Change is inevitable (company, market, staff, etc.) Knowledge is incomplete Some groups can finish, some groups can t In a month, in a year, doesn t matter Some features are critical, others aren t (80/20 rule) Estimates are generally +200%, -50%. Very best is +/- 20%. You can t always get what you want, but if you try you might get what you need.

8 Finding the Optimal Approach Customer: What is the best way to get what we want for a reasonable cost. Vendor: What is the best way to deliver what we can for a reasonable profit? Agile gives us an approach to achieving optimal performance.

9 Example Requirements Get to work on time (15 min.) And within budget ($5.00) Approaches Try 1: ad hoc Try 2: brute force (water fall) Try 3: guided brute force (iterative) Try 4: flexible (agile)

10 Brute Force (aka waterfall) Plan in detail the whole trip Commit resources up front Deliver results at the end of the project. Mitigate problems by working harder

11 Brute Force on the Map

12 Brute Force Planned vs Actual Planned Total planned trip time: 11 Minutes Ferry fee: $4.50. Actual Ferry was 5 minutes late. One minute late to work

13 Guided brute force (iterative) Same as brute force, but we have checkpoints. We use the radio to monitor our progress. Unfortunately, the Ferry is still 5 minutes late, but we found out on the radio after step 2. Same result as brute force, but we knew sooner.

14 Flexible (agile) Variation on evolutionary At the beginning of each step, re-plan the entire project Requirements and priorities Rework based on new information

15 Agile on the Map The process Agile plan one: get to intersection, maybe proceed to ferry. Agile plan two: at intersection find out ferry is late. Reroute to bridge even through distance is greater. Agile plan three: need gas approaching bridge, so stop and get a few gallons. Agile plan four: need to drive a little faster to make it on time. Note that the optimal path changes over time. One possibility: stop.

16 Agile Defined Dictionary: able to move quickly and easily Manifesto individuals/interactions over processes/tools working [product] software over comprehensive documentation customer collaboration over contract negotiation responding to change over following a plan Wikipedia: group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing crossfunctional teams Mine: A set of methods and strategies optimally integrated to build momentum and achieve continuous success

17 The Agile Balance Enough planning, but not too much Enough documentation, but not too much Enough process, but not too much Enough engineering, but not too much Focus on high risk, high priority first

18 Agile Myths Agile means undisciplined Agile means no real commitment Agile belief that documentation and process slow a project down.

19 Methods/tools/techniques Scrum Lean process development Feature-driven development Test-driven development (in principle) 3 Cs: Communication, Collaboration, Commitment Good engineering Other: time boxing, agile estimating, extreme

20 Scrum Complete project in iterations Completely re-plan project at the beginning of each iteration. Focus on highest risk, highest priority Make hard decisions early Short term plans are detailed, long-term brief. Let the people doing the work define the order when possible. Assumption: the project team will work at 100% capacity during an iteration.

21 Scrum process: planning Repeated for each iteration Planning (one day, maybe two) Organize requirements in one big list, ranked 1 to N by priority. Estimate time to complete tasks until an iteration is defined. Use real estimates Base estimates on development velocity Adjust priorities based on estimates and repeat Arrive at final iteration plan: task assignments with estimates to fill iteration

22 Scrum process: Execute Executing (daily) Each team member: Update all estimates of member s tasks Estimates in days left as of the start of the day. Describe work done since last meeting. Describe work to be done until next meeting. Identify blocking issue. Coach Capture issues that come up in meeting. Organize working meetings to address issues Keep meeting to 15 minutes.

23 Scrum process: rest Often ignored Scrum is very intense, people need time to break away. A good time for ad hoc research of new technology.

24 Managing the Triangle Cost Assumed to be optimal Schedule Fixed for Agile You can deliver or you can t 1 week iterations for high-risk, 4 to 6 weeks for low risk. Features Usually confused with quality, which is a Boolean: it s either good enough or it isn t. The only variable in Agile.

25 Lean Software Development Eliminate Waste (seeing waste, value stream map) Amplify Learning (feedback, iteration) Decide as late as possible Consider options until a responsible decision must be made Deliver as fast as possible Empower the team Build integrity in (testing, feedback, refactoring, modeling)

26 Lean Process vs PDCA Establish baseline process (plan) Deliverable-centric (deliver as fast as possible) Plan as late as possible. Use the process (do) For repeatability (amplify learning) Evaluate the process (feedback) (check) Improve the process (the lean part) (act) Eliminate waste: If it s not used, don t produce it. If it s not useful, don t use it. Identify more efficient ways to complete deliverables. Build integrity in See the whole

27 Feature-driven development Manage requirements in terms of features. Organize work around the features. Breadth first (Use cases)

28 Test-driven development Principle: represent project requirements in terms of actual tests, preferably automated. Useful Identify test cases early (simple, comprehensive list) Perform periodic test passes to establish project status. Elaborate test cases as resources allow. Automate tests as resources allow. Not-so-useful Don t start coding until the automated test cases are complete. A test case doesn t exist unless it s automated.

29 3 Cs Communication Frequent face-to-face meetings. Interview skills: open-ended questions, paraphrase, listen. Consider bandwidth issues (determines formality) Collaboration Work with stakeholders cooperatively to deliver value. Build effective working relationships Commitment To the principles To the quality

30 Good engineering Often overlooked Architecture: build up frameworks and patterns to facilitate fast, high-quality development. Model-driven, UML Code reviews (pair programming when needed) Responsible use of technology Consider costs (development and delivery)

31 Agile in the PMBOK Iterative process Rolling Wave Planning, Progressive Elaboration Re-planning Expert judgment as a technique CQI and Lean process development

32 PMBOK, Iterative Initiation process for each project phase Authorization from key stakeholders Validation/refinement of scope for phase Agile recommends relatively short iterations or project phases. Agile recommends completely re-planning the remainder of the project.

33 PMBOK, Elaboration Progressive Elaboration Continuously improving and detailing a plan as more detailed and specific information and more accurate estimates become available Rolling Wave Planning The work to be accomplished in the near term is planned in detail at a low level of the WBS, while the work for in the future is planned at a relatively high level Planning for next bit of work occurs during the executing of the current bit of work.

34 PMBOK, re-planning Executing Process Group normal execution variances will cause re-planning Monitoring and Controlling Process Group a missed activity finish date can require adjustments to the current staffing plan, reliance on overtime, or tradeoffs between budget and schedule objectives. 7.1 cost estimating Cost estimates can benefit from refinement during the course of the project. Agile assumes a significant amount of re-planning at the beginning of each iteration.

35 PMBOK, Lean processes 8.2 Perform Quality Assurance CQI: reduces waste and non-value-added activities

36 Agile measurements Days left per task aggregated for team (vs schedule) Development velocity Test pass rate (vs expected) Estimating profiles (normal, hero, over achiever) Defects found after code complete Defects found after delivery Customer satisfaction Hacking timeline

37 Agile Pitfalls Not enough planning Good judgment should still prevail Sponsors may feel alienated Customers don t always want to be in the middle of the project.

38 Agile Strategies Don t act on a hypothetical Manage Sponsor Provide enough detail on long-term plan Establish collaborative relationship Show continual progress Manage expectations Publicly reward team, not individuals Develop a simple, effective process based on the principles.

39 Bringing it together for PMs Consider where a more agile approach would be more optimal Requirements are unstable/uncertain. There are many, high-level risks. Develop an alternate way to ensure good productivity. Look for cases where more phases are better. Frequently involve the customer in a personal, interactive manner. Empower the people doing the work to make decisions within guidelines.

40 Conclusion Being agile means having a good grasp on a large number of techniques and being able to apply them in an optimal way. Agile provides tools to generate positive energy and unstoppable momentum.