Sdec09 kick off to deployment in 92daysPresentation Transcript
Lean Software Development -Kickoff to Deployment in 92Days
Agenda• Parks Reservation Service Project - The client - The challenge - The project - The solution - The results• Lean Software Development - Principles and Practices - How Project Management and Project Leadership are different• Lean Software Development Tools and Techniques• Declaration of Interdependence - Project Manager Declaration of Interdependence• Is my client ready?• Questions?
Parks Reservation Service Project
Park Reservation Service – The client• Manitoba Conservation is comprised of 4 divisions as follows: - Regional Operations – delivers departmental programs on a regional basis (park and campground operations) - Programs – provides the policy direction and systems support for program thrusts of department (parks) - Environmental Stewardship – legislation, policies, plans, and programs to sustainably manage resources and the environment (Exec Sponsor for PRS) - Corporate Services – management of cross division services such as human resources, financial, computer and administrative support (IT support and financial management for PRS)
Park Reservation Service – The client• Dimensions of Parks and Campgrounds - 57 Campgrounds - About 5,500 campsites - 11 Campgrounds currently computerized • Bakers Narrows, Big Whiteshell, Birds Hill, Falcon Beach, Falcon Lakeshore, Grand Beach, Gull Harbour, Kiche Manitou, Otter Falls, St. Malo and West Hawk
Park Reservation Service – The client
Park Reservation Service – The challenge• Government committed to have a “ made in Manitoba solution “ for Spring 2006.• The RFP was released in early December with a closing date of Mid-December.• Protegra proposed a consortium approach to deliver the solution by the opening day of April 3rd.• Protegra was awarded the contract in early January 2006.
Park Reservation Service – The challenge• Challenges faced: - Time line - Client new to Protegra, Protegra new to provincial government - Consortium approach – time and complexity - Complex Government Environment
Park Reservation Service – The challenge Protegra Function Four IDFusion ManLab Nextechnologies Project Management Office Project Executive Project Sponsors Cheryl Hedley Wadood Terry Bunio Protegra Ibrahim Protegra Serge Protegra Scrafield GOM Dan Haughey David John Clarkson GOM Primmer GOM GOM Service Conservation STEM Finance Communications Manitoba EDS Dimark IBM MTS Key Crow Moneris
Park Reservation Service – The consortium• To address the timelines and challenges a consortium approach was created. The consortium involved the following companies - Function Four – GIS Technology and Training Expertise - ManLab – Government of Manitoba Graphics Experience - IDFusion – long time development partner of Protegra’s - NexTechnologies – Domain Expert in Reservations• This offered the team a unique balance of expertise, but also had the following implications - More time was spent early on in contract negotiations and teaming agreements - More time was spent determining how to communicate, report and work well together
Park Reservation Service – The project• The Parks Reservation System (PRS) was developed in 2006 to replace the existing campground reservation.• Scope included: - Self-initiated reservations over the Internet, - Campground attendants to make reservations on behalf of clients, and; - Call centre employees to make reservations on behalf of campers.
Park Reservation Service – The project• Project details - Project team included over 20 developers at maximum - First Phase was delivered in 3 months, On Time! - Included investigation and integration of GIS mapping technology - Phase 1 alone was over 7,400 hours of development work, all three Phases were over 12,000 hours. - Quality of the application has exceeded industry standards with only a few defects since go live - Project had to achieve PCI certification to go live. PRS was first of government applications to pass on the first test.
Parks Reservation Service – The solution Welcome Campsite Vacancy No public authentication required Facility Search Login Authenticated Users only Shopping Cart Reservation Maintenance Account Reports Payment and Campground Refunds Management Inventory ManagementLegend: A very common process flow Checkin Policy Configuration A common process flow Public and Admin functional area Exchange Rate Admin only functional area SQL Updates Maintenance
Parks Reservation Service – The solution PRS Public Web Client PRS Services Internet · View Campground and Campsite details Public and Admin Services · Create & Update Accounts · Security service · Make & Change Reservations · Campground and Campsite servicePublic Users · Image service · View Campground Vacancy HTTP · Campsite Search service S Protegra Client Frameworks · Account service · Account Search service · Reservation service · Transaction service HT · Subscription service TP Admin Only Services S · Inventory Management service Moneris · Campground Management service Internet · ePayments and eRefunds · Reporting service · Reservation History service · Admin Utilities serviceCall Center PS · Inventory Sales service HTT Staff · User Management service · Account Alert service · Daily Arrival Fax service Intranet · Moneris Reconciliation service S PRS Admin Web Client TP · Campground Mapping service HT · View Campground and Campsite details · Inventory Report caching service · Create, Find, Update & Manage Accounts · Moneris Refund service · Make, Find, Change & Manage · Cheque Refund service Reservations · View Reservation History Protegra Server Frameworks · Manage Campgrounds · Update Campground Inventory & Maps · Policy Configuration · Administrative, Inventory and Finance Reports SQL Server • Parks DatabaseParks Staff • Security Database · Vehicle Permit Inventory and Sales Database · Refund Management • Resource Database Campground • Log Database Protegra Client Frameworks • Reporting Services Attendants
Parks Reservation Service – The solution
Parks Reservation Service – The solution - Phase 1 – Public and Call Centre Focus • Duration: 3 months. • Functionality focused primarily on the reservation process and reservation maintenance (i.e. making reservations, changes, cancellation, payment, refund, etc.) - Phase 2 – Campground focused • Duration: 1 month. • Focused on management of campgrounds (i.e. check campers in, check campers out, move campers, camping permits, revenue reconciliation, etc.) - Phase 3 – Admin site enhancements • Duration: 7 months. • Focused primarily on providing more back office support to Parks head office users - Phase 4 – Application Maintenance Services • Duration: Ongoing • Provided additional functionality for public users, call centre employees, and campground and head office staff.
Parks Reservation Service – The results • Reservation Counts (Opening day to April 30) 2005 2006 2007 2008 Web 7166 7818 10794 13452 Call Centre 3976 3925 4246 3705 Total 11142 11743 15040 17157 16000 14000 12000 10000 8000 6000 4000 2000 Web 0 2005 2006 2007 2008
Park Reservation Service – The results• Benefits Realized from Lean Development Process - Client decision maker on site is key to a Lean project. - Liaise with the clients as much as possible - Empowering the development team was crucial. - Traceability of requirements is key with formal organizations - The team succeeded because they trusted one another• Potential Improvements - Quality could be further improved with the use of TDD, automated test and build tools - Form in sub-teams of 6-8 to maximize efficiency. Assign a Client decision maker to each one of these sub teams. - Leverage Visual Project Management to an even greater extent
Park Reservation Service – The results• The project was awarded the PMI project of the year (Manitoba Chapter) for 2006
Process Notes• Before even bidding a meeting was held with the project team to ensure agreement in approach and commitment to the project and approach - Everyone knew this would not be an easy project - Everyone was committed to the challenge and to success - If we did not have consensus we would have not bid
Lean Software Development
Lean Software Development - Principles • Traditional Project Management implies: - Serialization of Project Phases - Significant focus is on protection of scope - Many handoffs between different phases and departments. Many documents are produced because of these handoffs. - Delivery of working code sometime waits until just before UAT
Lean Software Development - Principles• Lean Software development emphasizes customer satisfaction through continuous delivery of functional software, unlike traditional methods, lean developers liaise daily/continuously with business clients.• Deliver working software as frequently as every two weeks during a project, and encourage changes to the requirements in response to evolving business needs• The most crucial aspect is the execution of the project in iterations which enable quick feedback loops. NOTE: The iterations apply to the following tasks: - Project Management and Planning - Analysis - Technical Design - Testing - Deployment
Lean Software Development - Principles• Iteration planning is the key planning initiative. Iterations need to be planned in conjunction with the client to accomplish the following: - Deliver functionality to define the tempo of the project - Deliver functionality to deliver real value to the client (working code) - Deliver functionality to minimize risk for the entire project - Lessons learned from one iteration must feed into subsequent iterations so that we don’t (just) execute the project in iterations with similar results, but that we execute the project in iterations with better results. • The project team executes better, smarter, and quicker • The project team goes through the process of forming, storming, and performing
Lean Software Development -Principles • Most deliverables are enhanced in every iteration • Every iteration uncovers new opportunities for improvement and learning • Opportunities for improvement are evaluated at the end of each phase and incorporated into the tool and documentation
Lean Software Development - Practices• Requirements for a Lean Software Development Project - Define Vision before iterations start. Defining the vision can be iteration 0. - Defined iteration length - High Feedback loops • Client representative on site and working with the team • Client representative empowered to make decisions • Daily project team meetings - Visual Project Management - Frequent Builds - Test Case Driven Development and Documentation. (May be TDD) - Refocus requirement discussions on how not what
Lean Software Development - Practices • Refocus requirements discussion on how not what - Waterfall (Point based) • Document the scope or the what before we start • Use the scope document to manage change control • Discussions on new and modified scope can be difficult as these requests usually occur later in the project and require additional budget and schedule. Changes are avoided for these reasons. • Discussions become adversarial - Lean (Set based) • Document the process on how we will define the scope and make decisions. Define at a high level what you need and how you will refine it. • Use the process agreement to manage change control • Joint Collaborative discussions on new and modified scope and how we can manage them in the project. Because we deliver in iterations, changes can be specified earlier and can often be accommodated without additional budget and schedule. Changes are welcomed.
Lean Software Development - HowProject Management is different • Lean Software Waterfall Project Lean Project Management Skills Management Skills Development Project Manager Detail oriented Adaptable, encourages change Characteristics Manages at a lower level Comfortable with ambiguity - Traditional Project Management manages the known, Lean or Agile Resistant to change Able to delegate Project Management manages the unknown Controlling Trust or faith in team mates - There are distinctly different ways how you manage the unknown Company Focus Client Focus versus the known Transaction Manager Relationship Manager - There are distinctly different people and styles that are more suited to managing the unknown versus the Manages Scope, schedule, Manages Value budget known Temperment: Guardian Temperment: Idealist
Lean Software Development - How ProjectManagement is different• Idealist - These are big picture people who lead followers to pursue great dreams. They thrive on people issues and gravitate toward the soft skills: conflict resolution, negotiation, team building, facilitating. Diplomacy and strategy are their strong suits• Guardian - People with this dominant temperament like to play by the rules. These are the stabilizers in the organization, working to keep the boat on an even keel. Meeting budgets and deadlines and following the plan are important to Guardians.Keirsey, D. Please Understand Me II. Del Mar, Calif: Prometheus Nemesis Book Company, 1998
Lean Software Development - How ProjectManagement is different• In waterfall projects you focus on managing people and tasks, in Lean projects you focus on leading the process - Facilitate decision making versus making the decisions• Project Managers and Project Leaders need to not solve problems for the team - Counter-intuitive - The team will own the problem more if they own the solution - This is essential for the team to self organize
Lean Software Development - How ProjectLeadership is different• Project Manager and Client Project Manager must work even more closely together than a waterfall project - Both must focus on the long term relationship - Both must trust each other - Both must encourage their companies to focus on value and the long term relationship - Both must define a common understanding together for • Escalation • Change Request Process • Issue Tracking • Reporting • Formal versus Informal policies and procedures
Lean Software Development Tools and Techniques
Lean Software Development Toolsand Techniques• How do we manage scope and change in an agile project?• There is no question we will deliver more value, but how do we provide the visibility the clients need?• A lot of the sources out there talk about looser project management with unconfirmed budget and scope. How can you ever get a project approved? - Don’t provide estimates until after 1-2 iterations - Execute the iterations until the budget is exhausted - Keep on adding scope as the project executes by trading other items
Protegra Givens:• We are a consulting company, some of the luxuries like not estimating the full project are not options for Protegra. - We need to estimate the project for the clients• We need to inform the clients of changes. Sometimes Agile proponents advocate change, but we need a process to ensure the change is communicated and approved. - Some times the change is recorded and implied that there are less formal processes
Waterfall• Provide an estimate for the entire project• Take a significant amount of time and sign off detailed estimates• Execute to that plan. Change request anything to that plan.• Scope trading usually not an option. Client not usually given option to remove items as it complicates matters• Objectives: - Minimize surprises - Minimize changes - Maximize predictability
Lean or Agile• Provide an estimate for the entire project• Take a material amount of time and produce solution and high level estimates• Refines estimates as iterations proceed• Execute to the iterations. Change request anything that cannot be accommodated.• Objectives: - Maximize Value - Encourage Change
Questions• What is a CR and what is refinement? How should we account for this time?• How do you balance Agile and change control?• What is a scope enhancement? How can we make them defendable?• What is an issue? How do you resolves issues and changes with agile practices.
Fundamental Issues1. Trading Requirements and Refinement of Requirements can lead to more changes - Hard to defend as to whether it is a change. Sometime you don’t know all the assumptions you need to make and now you have more change!!!2. Focus on Agility leads project to sometimes accept more change - Want to encourage a win-win environment. Don’t want to make it adversarial right away3. Agility sometimes leads clients to not give requirements the attention they deserve early on - They know they can change it later if they don’t get it right.
Management – Before and During • Before- Client Expectation Setting - Meet with Client and determine proper SDLC • 3 options - Lean, Iterative Development, Waterfall • Honest discussion of what value is expected • During-There are two types of scope creep - New or modified scope items that are easily defendable (NEW) • Two types: - Ones that are identified and documented by the team - Ones that are just absorbed by the team - New of modified scope items which are not easily defendable (MORE) • They are just MORE - More complex, More work, More involved
Management – Leading Indicators• Leading Indicators- We need to track proactively - Burn down charts overall - EPI – Estimate Performance Index - Time Entry - ETC 45
During Best Practices• Scope Creep – New Guidelines - All items added to or removed from the Product Backlog need to have a change request generated and approved. No exceptions. • User story name template – US ###.Date • All stories need to be estimated • Confirm all estimates with clients before start on Iteration - This gets buy-in on the level of estimates.
During Best Practices• Scope Creep – More Guidelines - Bucket that we propose and agree to manage jointly where estimates are not sufficient. - Details • CRs will still occur for obvious scope changes • To be used for interpretation issues or more issues • Can be used to manage scope when level of complexity changes • Requires trust. This may not be possible on some initial engagements
Leading Indicators Guidelines• On the weekly status report, the following leading indicators will be reported: - Estimate Performance Index = hours on schedule/hours actually spent - Overtime Performance Index = Overtime hours/normal hours• This is in additional to the weekly status report of budget, hours and general progress - These items above are meant to track the specific type of scope baby crawl that occur in some agile projects - I call it baby crawl because it is cute at the start because it shows customer interaction and engagement. But unless you set up the gates by the stairs, scope can get away on you!
Leading Graphical Indicator• Leading Graphical Indicator will be a burn up chart 180 160 140 120 100 80 features complete 60 features in scope 40 budget 20 0
Burn up chart• Unlike a burn down chart which doesn’t refer to budget, the burn up chart refers to budget and scope• This gives constant feedback on the amount of work required to finish the project
Visual Project Management 51
Visual Status Reporting• Status Report
Declaration of Interdependence
Declaration of Interdependence• At the 2004 Agile Development Conference, a number of project, product, and management experts started working together to answer the question "How would you extend the Manifesto for Agile Software Development to non-software products, project management, and management in general?" Their answer is a document called "The Declaration of Interdependence."
Declaration of Interdependence
Continuous Flow of Value• WE INCREASE RETURN ON INVESTMENT BY MAKING CONTINUOUS FLOW OF VALUE OUR FOCUS - Unlike traditional waterfall we are managing to the continuous flow of value, not to what was signed off. - This may result in delivering something totally different, but of more value to the client at no additional cost. - focus on "flow of value" (e.g., not "tracking effort")
Joint Ownership• WE DELIVER RELIABLE RESULTS BY ENGAGING CUSTOMERS IN FREQUENT INTERACTIONS AND SHARED OWNERSHIP - The key is frequent interaction and shared ownership. - We are a team solving the business problem. - engage customers in frequent interactions
Embrace Change• WE EXPECT UNCERTAINTY AND MANAGE IT THROUGH ITERATIONS, ANTICIPATION, AND ADAPTATION - We embrace change and encourage it as it adds more value for the client - This also integrates highly with the Risk Management Strategy • Do the riskier items earlier to allow for reaction time - We do this by iterations, iterations, iterations….
People• WE UNLEASH CREATIVITY AND INNOVATION BY RECOGNIZING THAT INDIVIDUALS ARE THE ULTIMATE SOURCE OF VALUE AND CREATING AN ENVIRONMENT WHERE THEY CAN MAKE A DIFFERENCE - Software Development is ultimately a creative endeavour. • Like Cooking. - People are not just cogs but can contribute to be more than the sum of all there parts - recognize individual human beings as the ultimate source of value
Empower the team• WE BOOST PERFORMANCE THROUGH GROUP ACCOUNTABILITY FOR RESULTS AND SHARED RESPONSIBILITY FOR TEAM EFFECTIVENESS - Teams can achieve incredible things when faced with the challenge. - Ensure that the focus is on the team and individual recognition - group accountability for results (i.e., the whole group is singly accountable, no in-team blame)
Customize• WE IMPROVE EFFECTIVENESS AND RELIABILITY THROUGH SITUATIONALLY SPECIFIC STRATEGIES, PROCESSES, AND PRACTICES - No solution is exactly the same twice - Even the same problem will be solved in multiple ways by the same team - situationally specific strategies, processes and practices. (i.e., no one answer, folks, get used to it)
What’s this got to do withProject Management?• Good Projects for me come down to four items: - Good People - their hearts and minds; - Good Situationally specific strategies - all recommendations are specific to the context at hand, there are very few really general strategies to follow in all cases - Frequent Feedback - close in and end-to-end. - True Delegation • True Delegation is not having someone do a task like you would • True Delegation is about trusting teammates by providing an end state and letting them determine the path • True Delegation is letting teammates make decisions, even when thier decisions do not agree with your own
Is my client ready?• Rather than consider Lean Software Development as an approach that fits every client and project, there definitely is a continuum of appropriate project methodologies - Some clients have predictability, procurement, and legislative requirements that prevent full Lean adoption - Some clients have more discretion - Almost never does a first time client do Lean fully. It requires trust to be built up! - Some projects even within the same client may be a better candidate for Lean. (business facing versus compliance)
The Test• Ask your client the following two questions and ask which one better describes them: - A successful project will be about delivering the scope and or solution we have defined in alignment with the project budget and schedule. • Predictability • purchase - A successful project will be about starting with the scope and or solution but ultimately delivering more business value and a solution we cannot anticipate currently. • Value • Partnership
Questions• Thank you for your time and interest• Any questions?