best practices when moving to agile project management
DESCRIPTION
Delivered to the York Technology AssociationTRANSCRIPT
Best Practices When Moving to Agile Project Management
Presented By:
Robert McGeachy, PMP
Kintyre Consulting Incorporated
February 26, 2010
York Technology Association February 26, 2010 - Markham, Ontario
Learning Objectives
• Understand the major issues teams face when adopting Agile processes
• Walk through the process to train and inspire a team new to Agile
• Learn how to transition roles from a Project Manager to an Agile Coach
Moving your team to Agile is akin to moving to a new country with
a new language and culture. No amount of training can prepare
you for every challenge.
Agile Principles
The 5 “Gotchas”
Setting up your Team
Organizational Success Factors
Agenda
Who is the presentation for?
• The people or organizations that are looking to improve on the efficiency of their development processes and the quality and alignment to business requirements
• Generally, these methodologies are applied to the software or IT project. But Agile approaches can be adopted for other types of projects.
• Some basic or general understanding of Agile Methodologies is assumed
• We wont solve all the problems, but will point out the areas project managers and teams should focus on when making a change to Agile
Agile Principles
The 5 “Gotchas”
Setting up your Team
Organizational Success Factors
Agenda
Waterfall vs. Agile
• A project is broken into releases (a release should occur no less frequently than every 4 months)
• Releases are broken into short (1-4 week) iterations
Discovery Design Implementation Manage
Waterfall
DefineRelease 1 Release 2
Agile
It 1 It 2 It 3 It 4 It 5 It 6
Release 3
It 7 It 8 It 9
Release 4
It 10 It 11 It 12
Iteration N Iteration N
MonMonLocal team: acts as interface to client, does some dev work
Local team: acts as interface to client, does some dev work
team: develops and tests team: develops and tests Fri
Fri
Mon: Iteration kick-off with
client
Mon: Iteration kick-off with
client
Fri: End-of-iteration checkpoint with client
Fri: End-of-iteration checkpoint with client
Go Live
Go Live
Agile Delivery Model
Short Iterations
(1-4 weeks)
24 hours
(1) Validate/Reprioritize scopeAt the start of each iteration,the team works with the client to validate planned iteration scope and if needed reprioritise or swap scope
(2) Build iteration planThe team works with the client to gain a deeper understanding of the iteration requirements and be able to break the work down allocated to their track. Each track uses this to create an iteration plan
(3) Daily teamMeetingThe team meets daily to report status and address roadblocks
IterationScope
(4) Deliver potentially deployable functionalityThe team performs Analysis & Design, Requirements detailing, Development and testing of the selected scope items to deliver something of value to the client at the end of each iteration
Potentially DepoyableFunctionality
IterationPlan
Checkpoint with client
Agile principles• Highest priority is to satisfy the customer through early and
continuous delivery of valuable software
• Welcome changing requirements, even late in development and focus on 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 principles (continued)• 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-organising teams
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly
The Four Main Benefits of Agile (if done right!)
• Increases Flexibility ▫ It minimizes up front investment and maximizes return
on investment (ROI) by creating an efficient IT development process
• Delivers the Right Solution▫ It aligns users and stakeholders with the right people to
deliver the solution that the business actually needs
• Accelerates Delivery ▫ Iterations get to the right solution faster
• Reduces Risk and Increases Quality ▫ Greater stakeholder visibility and control
Agile Principles
The 5 “Gotchas”
Setting up your Team
Organizational Success Factors
Agenda
The 5 “Gotchas” for the Agile Team
•Lack of discipline
•The iterative death spiral
•Changes in working styles
•The new role of testing
•Changes in responsibilities and expectations
Lack of discipline• Although it may seem counter intuitive, Agile is
an extremely disciplined approach to working
• Agile does not equal sloppiness. Most people will have a difficult time adjusting to this
• Tracking stories to closure, accounting for the velocity of an iteration, tracking one’s estimate to complete -- these are all things where every team will slip up the first few iterations
• Without discipline Agile will not work. Setting good examples and continually following up are essential
The iterative death spiral• People misinterpret the term ‘iterative’ to mean
that there is unlimited ability to revisit scope
• In fact, Agile success hinges on incremental completion of scope throughout the project
• Teams that do not effectively define their “exit criteria” for each work unit (known as “story”), will never get real closure on work in progress
• This leads to endless cycles of revisions that are really scope changes but which are not labeled so because of the misperception, causing delays, overruns, and a demoralized team
Changes in working style• Developers used to working in a solo mode will have a bit of a
hump to get over when working in small teams to complete stories.
• This can manifest itself in stalled work, as communication reverts to inefficient mechanisms such as email (instead of sitting together, or picking up the phone)
• In a typical project the pressures of learning the business, addressing technology, business, and team personality issues, will very quickly overwhelm even the most prepared person
• Add to this a major change in delivery methodology and it will lead one to revert to known approaches
• A major mitigation here is training and more importantly, effective support from someone with actual experience in the field
The new role of testing• Automated testing is fundamental to quality,
short delivery cycles, and hence the agile model
• Yet, there are many barriers: taking on a legacy application with no existing test suites; lack of tools for many aspects of an application; lack of team knowledge on how to do this
• People will want to revert to more comfortable manual testing approaches
• TDD (Test-Driven Development) will be a struggle to adopt. It is counter-intuitive unless tried
The change in responsibilities and expectations
• Given focus on transparency and on pushing responsibility to the team, the Project Lead will be less of a task manager, and more of a problem solver, and will have to “let go” of a lot of previously-held control
• Developers will work hand in hand with testers and cannot declare a piece of code “done” until the tester gives the green light
• Testers who are used to having a more clearly specified set of tasks will struggle, as the Agile tester role involves more thought, planning, and business knowledge
• For Business Analysts, working just in time on requirements will feel very unnatural. Working hand in hand with developers to define requirements and then to help test them as a developer works will feel very foreign
• This problem will be exacerbated by the multiple reporting structures that exist between team members
Agile Principles
The 5 “Gotchas”
Setting up your Team
Organizational Success Factors
Agenda
Testers
Developers Testers
Product Owner
Client SMEs
PM
Test Lead
Client Proxies
Architect
Cross-functional tracksmay vary anywherefrom 3-10 persons
Developers create thesystem. Testers own itsvalidation; the developer-to-tester ratio within each trackis typically between 2:1 to 4:1
A “virtual team” consisting oftrack leads, project leadershipand clients ensures broadcommunication of importantproject announcements
Track Lead
Track Lead
Developers
Developers Testers
Track Lead
• Project Manager▫ Scrum Master, manages issues and
removes roadblocks
• Architect▫ Responsible for overall system architecture
and development quality and processes
• Developer▫ Participates in design, creates unit tests,
builds and delivers code
• Tester▫ Dedicated testers assigned to each
track (ratio typically ranges from 2:1 to 4:1)
• Test Lead▫ Responsible for organizing and
planning testing efforts▫ Mentors testers
• Client Proxy▫ Helps remote teams clarify
requirements and run issues to ground
• Product Owner▫ Client owner who participates in
Kick-offs and Iteration closures, as well as provides feedback
Physical Space and Co-Location
• The most effective layout for the physical team location is co-located desks
• There should be shared access to plans, status, next steps, and other project planning and management tools.
• In teams that must be geographically separated, then tools for conducting virtual meetings such as conference call phones, instant messaging, shared electronic documents and tools are leveraged to minimize the distance and separation
The War Room• Team Structure - the basic "who's on the
team", including contact information
• High level plan, Mid Level Plan - The overall project milestones, and the key iterations and release dates, with the anticipated objectives or deliverables for each
• Roles and Responsibilities - A RACI style chart with the internal and external roles and the person on the team who is responsible
• Story Board - The stories for this iteration, what is complete, in-progress, and not started
• Client Deliverables - This may seem straight forward, but a reminder as too what we as a team are trying to deliver
• Client Phase Exit Criteria - What are we marching toward to complete the current phase and achieve signoff
• Story Stack - The scope of the project
• Meeting Agenda - The standard daily team stand-up meeting has a strict, short agenda so we can complete it within 30 minutes
• Issues and Next Steps - The whiteboard list of next steps, dates, owners, to be checked during each team meeting
• Risks - The whiteboard list of risks, impact, and mitigation that needs to be taken (with owner)
• Recognition Awards - Some place to call out great work by the team or individuals.
• Ground Rules - The team derived rules for respecting each other
Agile Principles
The 5 “Gotchas”
Setting up your Team
Organizational Success Factors
Agenda
Is Your Organization Ready For Agile?• Trust pervades the culture of the organization, the
interactions between its people, and its clients
• Individuals demonstrate a high level of enthusiasm for or openness toward change
• Management empowers individuals to take risks without fear of repercussions
• Disciplined execution is representative of the organization’s delivery practices or broadly viewed as a goal worth of striving for
• Teams and management alike evidence the commitment and patience necessary to seeing through changes despite challenges and disappointments along the way
• A willingness exists to make reasonable investments in tools, training, coaching and mentoring to facilitate successful adoption and sustained change.
Learning Objectives
• Learned the major issues teams face when adopting Agile processes
• Walk through the process to train and inspire a team new to Agile
• Learned how to transition roles from a Project Manager to an Agile Coach
We reviewed the major “gotchas” that can derail a project
with team members new to Agile.
