Agile Project Management Tracy Hoerschgen RKV Technologies Inc.

Agile Project Management Tracy Hoerschgen RKV Technologies Inc.

What do you want to know? Introduction What are Agile Methodologies? When are Agile Methodologies the best fit? How are Agile projects managed? Scheduling & Iterations Change Management & Rework Metrics Additional Considerations Estimation Project Management Frameworks What Agile Management tools are available? Conclusion

What are Agile Methodologies?

Agile Development Methodologies Are iterative Iterations are time-boxed and are typically one to four weeks Each iteration creates a functional piece, albeit small, from beginning to end Multiple iterations create a finished product Require close teamwork Smaller timeframes require project staff to communicate more frequently Based on a concept of adaptability Smaller timeframes allow more rapid incorporation of requirement changes, which Agile accepts as an unavoidable truth

More details There are several key elements that provide the basis for APM. It is important to note that these techniques can also be used in traditional software development methods to improve project performance. They are: Visual control Co-located high-performing teams Test-driven development Adaptive control Collaborative development Feature-driven development Leadership and collaboration rather than command and control Move from C (cost) to R (revenue) focus Lessons learned http://www.projectsmart.co.uk/the-blending-of-traditional-and-agile-project-management.html

Types of Agile Methodologies Agile Unified Process (AUP) Simplified version of Rational Unified Process (RUP) Test Driven Development (TDD) Agile Modeling Agile Change Management Database Refactoring Extreme Programming (XP) Encourages daily communication, simplicity, feedback, respect Open Unified Process (OpenUP) Open source process framework Contains characteristics of RUP/Unified Process: Iterative Development, Use Cases, Scenario-driven development, Risk management, and Architecture is central to this approach

Types of Agile Methodologies (continued) Dynamic Systems Development Method (DSDM) Rapid Application Development methodology Emphasizes continuous user involvement Designed for projects with tight schedules and budgets Feature Driven Development (FDD) Feature driven Five phased: develop model, build feature list, and according to that list plan, design and build ICONIX UML Use Case driven Less encumbering than RUP Noted by robustness analysis

Types of Agile Methodologies (continued) Scrum For managing complex projects Characterized by the use of “Sprints”, one to four week iterations Steps Prioritize requirements Team commits to which are to be included in sprint Team delivers demonstrable products at end of sprint

When are Agile Methodologies the best fit?

When are Agile Methodologies the best fit? Question: When can an athlete be “agile”? Answer: An athlete can be agile when they have experience and room to move. Projects can be agile when, among other things, the staff is experienced and given the room to estimate, plan and collaborate.

When are Agile Methodologies the best fit? Agile Traditional Criticality Level Low High Developer Experience High Low Requirements Change Rate High Low Number of Developers Low High Chaos Tolerance High Low

Benefits of Agile Methodologies: Iterative and incremental delivery for rapid business results Increased teamwork and collaboration for reduced waste; and increased productivity and team morale Learning and adaptation for increased quality and flexibility to change

Criticisms of Agile Methodologies: Not documentation based (does not create hearty software design) Lack of structure Not suitable for junior developers Meeting intensive Requires a high level of cultural change to adopt Adds ambiguity to the contract negotiation process, because it is difficult to develop realistic work effort estimates Can be inefficient, if improperly managed Can increase the risk of scope creep

How are Agile projects managed?

Scheduling in Agile Projects Detailed plans are only made for tasks that are soon to begin. Staff schedule their tasks with oversight only. Staff choose their tasks rather than being assigned tasks. Schedule short iterations. Schedule with requirements as the focus. Schedule tasks involving external groups. Include training. Take your environment into consideration.

Iteration Plan An Iteration Plan is a fine-grained, time-boxed plan; there is one per iteration. As each Iteration Plan focuses on only one iteration, it has a time span small enough to let the planners do a good job of detailing tasks with the right level of granularity and allocating them to appropriate team members. A project usually has two Iteration Plans "active" at any time: A plan for the current iteration, to track progress for the iteration that is underway. A plan for the next iteration, which is built toward the second half of the current iteration and is ready at the end of it. http://www.ibm.com/developerworks/rational/library/2831.html

Iterations 1st 2nd 3rd http://rup.hops-fp6.org/process/workflow/manageme/co phase.htm

Iteration pattern: Incremental Lifecycle Single Inception: establish scope and vision, and define the business case Single Elaboration: requirements are defined, and the architecture established Several Construction iterations: use cases are realized and the architecture fleshed-out Several Transition iterations: migrate the product into the user community This strategy is appropriate when: The problem domain is familiar. Risks are well-understood. The project team is experienced. http://rup.hops-fp6.org/process/workflow/manageme/co phase.htm

Iteration pattern: Evolutionary Lifecycle Short Inception: establish scope and vision, and to define the business case Several Elaboration iterations: requirements are refined at each iteration Single Construction: use cases are realized and the architecture is expanded upon Several Transition iterations: migrate the product into the user community This strategy is appropriate when: The problem domain is unfamiliar. The team is inexperienced. http://rup.hops-fp6.org/process/workflow/manageme/co phase.htm

Iteration pattern: Incremental Delivery Lifecycle Short Inception: establish scope and vision, and to define the business case Single Elaboration: a stable architecture is base-lined Single Construction: use cases are realized and the architecture fleshedout Several Transition iterations: to migrate the product into the user community This strategy is appropriate when: The problem domain is familiar: the architecture and requirements can be stabilized early in the development cycle there is a low degree of novelty in the problem. The team is experienced. Incremental releases of functionality have high value to the customer. http://rup.hops-fp6.org/process/workflow/manageme/co phase.htm

Iteration pattern: “Grand Design” Lifecycle Short Inception: establish scope and vision, and to define the business case Single, very long Construction iteration: use cases are realized and the architecture fleshed-out Several Transition iterations: migrate the product into the user community This strategy is appropriate when: a small increment of well-defined functionality is being added to a very stable product. the new functionality is well-defined and well-understood . The team is experienced, both in the problem domain and with the existing product. http://rup.hops-fp6.org/process/workflow/manageme/co phase.htm

How many Iterations? Low Typical High Very High Inception 0 1 1 2 Elaboration 1 2 3 3 Construction 1 2 3 3 Transition 1 1 2 2 Total 3 6 9 10

Iteration Length People Weeks 5 1 20 3-4 40 8

Develop Iteration Plan Determine the Iteration Scope Define Entry and Exit Criteria Specific measurements and controls Define Iteration Activities Assign Responsibilities Advice: Shorter is better. Start with an uncomfortable length. Ignore the calendar. Produce something useful. Have as many iterations as you need. You can still have a firm delivery date.

Change Management Process http://www.agilemodeling.com/essays/changeManagement.htm

Rework One of the major benefits of an iterative development is precisely to allow mistakes and experimentation, but early enough so that corrective actions can be taken. At the end of each iteration, during the iteration assessment, the team should decide what part of the current release will be reworked. Expect rework to be allocated among phases in the following percentages, relative to the total system: Inception, 40%-100% - this is where you may develop throwaway, exploratory prototypes. Elaboration, 25%-60% in early iterations; less than 25% in later iterations, or for an evolution cycle. Construction, after the architecture baseline, 10% or less per iteration and 25% total. http://www.upedu.org/upedu/process/gdlines/md itpln.htm Transition, less than 5%.

Metrics Burn Rate Delivered Functionality Velocity Defects Additional Considerations: Keep it simple. Metrics must add value. Look at trends, not absolute numbers. Combine metrics.

Agile Principles of Estimation Increase the frequency of estimation. Reduce the time between estimation and feedback. Discuss constraints and assumptions. Create multiple options. Compare estimates. Ongoing learning process.

Traditional and Agile Estimates http://www.ambysoft.com/essays/comparingEstimatingApproaches.html

Traditional and Agile Estimates Approach Advantages Traditional Generally accepted Significant work in advance can yield a good estimate Agile Stakeholders in control Combination Reasonable estimate. Stakeholders in control Disadvantages Often not effective and projects are over budget and late anyway. Not currently generally accepted by senior management Initial budget and schedule may be viewed as not detailed enough

Agile Projects and Fixed Price Fixed price contract guarantee cost. Agile fixed price contracts deliver: Earlier results Greater flexibility Same price Customer must invest more effort: Test features regularly Give timely feedback Be available for questions Project Manager Frequent releases Frequent follow up Frequent planning Requires constructive, honest and trusting working relationship between customer and provider.

Project Management Frameworks Two Options: 1. Specific Agile Project Management Methodology (APM framework) 2. Fitting agile methods under the Project Management Body of Knowledge (PMBOK framework)

PMBOK - APM http://www.12manage.com/methods pmi pmbok.html

PMBOK - APM Integration Management: low detail, integrated change control Scope Management: scope planning at beginning of each iteration, scope verification during, adjusting for changes Time Management: high level estimates at release level, detailed estimates at iteration level Cost Management: cost fixed, cost control at the end of each iteration Quality Management: begins at beginning, critical Human Resource Management: onus on management to run interference, breed motivation among team, co-location, reward group success Communications Management: constant contact, metrics in place Risk Management: focus on qualitative risk, at iteration planning and review Procurement Management: purchases at beginning of project, consider contract alternatives, involve team in contracting

Special Considerations Scope Iteration level scope control critical for agile projects Consistency with PMBOK clear when iterations are considered projects in themselves Iteration planning and iteration review allow course corrections to overall scope Planning Planning essential to agile projects Reject scope-based planning with Gantt and PERT charts in favor of feature-based metrics like velocity Planning at the release, iteration, daily levels rather than at the project level Decomposition into Tasks PMBOK’s emphasis on the WBS perceived as antithetical to agile methods Emphasis on features over tasks distinguishes agile Documentation Depth of documentation not mandated, but PMBOK equivalent exists for all types Critical, less formal: feature backlog, velocity charts, burndown charts, iteration planning cards

Agile Management Tools

Can I get a little here?!

Important Features Iterative, Feature-driven Development: traditional tools do not enable easy changes Integrated Agile Lifecycle Management: high-level feature planning, detailed task planning, and overall project tracking Cross-Functional Teams: consolidated functions in a single environment Flexible Configuration: scalable, configurable Simplicity: should be easy to use Enterprise Scale: robust support of thousands of items with minimal overhead

Agile Management Tool Checklist http://www.versionone.com/pdf/AgileToolEvaluator.pdf

Additional Features to Seek Test Driven Requirements Test Driven Development Evolutionary Design Continuous Integration Automated Developer Tests Automated Functional Tests Collective Code Ownership Regular Refactoring

Popular Agile Management Tools Team Foundation Server: A commercial suite of Application Lifecycle Management tools from Microsoft that facilitates collaborative development. It allows teams to customize the processes for their individualized implementations of Agile or SCRUM software development practices IBM Rational Team Concert and the Jazz platform Jazz is IBM Rational’s new technology platform for collaborative software delivery. IBM Rational Team Concert provides real time collaboration, SCM and build management in addition to all the capabilities of the Jazz platform AccuRev: A commercial Agile SCM, version control and change management tool Agilebuddy: A commercial Agile project management tool, built with rich collaboration features for Scrum teams Anthill Pro: A commercial build management and continuous integration tool Bugzilla An open source change management tool Cruise Control An open source continuous integration tool Electric Cloud A commercial build management and continuous integration tool OutSystems The industry leading Agile Platform for rapid delivery and management of web business applications built for continuous change Rally: A commercial Agile project management tool Subversion (Software) An open source version control tool VersionOne: A commercial Agile project management tool WorkLenz: A project portfolio management tool that supports agile development

Some signs that you are not agile You haven’t seen or spoken to a coworker about work for at least a day. You email a status report to your manager, attend weekly 1-2 hour status meetings, and you and your coworkers still have no idea what each other is doing. You write a 30-page specification (which the customer signs off on) and still don’t build the right thing. Your project schedule contains 6 months worth of fine-grained tasks, but no one knows who estimated the work. (Or the person who made the estimates isn’t doing the work.) You can’t remember when the last build passed without manual intervention. You think unit testing is QA’s job. Every time you make a relatively small change, it takes days or even weeks to integrate and regression test. You think quality is QA’s responsibility. You are not allowed to refactor. We are shipping release in 3 month, refactoring is too risky.

This presentation will be posted on the GovTech website following this event.