What They Didn’t Teach Me in ScrumMaster Training

1. What They Didn’t Teach Me in ScrumMaster Training APLN Presentation January 7th, 2009 Prepared & presented by: Phil Scott www.neudesic.com – phil.scott@neudesic.com

2. Long Term Planning Not Everyone is Agile Compatible Configuration Management Developer Practices QA Deployment Advantages of an Established Team Agenda

3. Scope Customers want to know that we’ll get “everything” done Changes continue to flow Customers may get the feeling the project is out of control “Project” scope is different than “Sprint” scope Trajectory (velocity + change control) ABC’s, Exciters & Detractors Schedule Customers like to see a schedule of work How can Agile adhere to a deadline? Can we crash a schedule with Agile? Long Term Planning

4. Customer Comfort People buy into the illusion of predictability Project control is important; the sense of a control is critical Keep a pulse on customer confidence Consider writing a project management plan Consider scheduling a scope control rhythm Long Term Planning

5. Out of Band Efforts Sometimes, we need to work on non-sprint tasks to cooperate with external waterfall groups. We may: incorporate out-of-band tasks as sprint objectives (or) reduce team velocity, and split time between sprint & external tasks Cooperating with non-Agile Groups Training departments, external QA, external Analysts, external Architects, IT infrastructure Negotiate common ground and adapt – don’t force them into Agile Not Everyone is Agile Compatible

6. Builds, Branches and Bugs Establish environments (dev, QA, staging, prod) Establish version control with environment branches Establish review & merge process Automate builds (daily or continuous integration) Centralize defect tracking For Microsoft technology projects, I like: Defect tracking: OnTime or TFS Version Control: TFS Merge: TFS and RedGate (SQL) Build: TFS/MS Build or CruiseControl Environments: VMWare, Virtual Server or HyperV Configuration Management

7. XP? If the team is not using XP practices, they’ll have to develop strong alternatives for: Testing (unit, regression & integration) Refactoring & architecture adaptability Breaking down silos (horizontal vs. vertical development) Code reviews Truck/Lottery Number (pairing vs. cross-training vs. risk) Why reinvent developer practices, when XP is proven? Lack of maturity in these areas will greatly hinder team success MS Tools aren’t well adapted to TDD – modified TDD can still work Developer Practices

8. What is Agile’s QA process? Scrum and XP touch on QA, but don’t go far enough We have to customize our test approach and tactics to the project Consider writing a short test strategy document, early on Don’t go overboard. Match the QA rigor to the project Don’t be afraid to use light or heavy QA process, as the project requires Has anyone heard of Structured Exploratory Testing? I like: Test strategy document Lightweight test matrixes Automated unit tests (UI Controller, Service, DB & data quality) Structured Exploratory Testing Punch lists or defect trackers QA

9. How long does deployment take? One sprint may not be enough to complete deployment What about deployment planning? What about infrastructure planning? What about user training and post-deployment support? We need to adapt deployment schedules for the appropriate level of rigor and support. I like to: Begin deployment planning early in the project Discuss and adjust the deployment plan throughout the project Get a head start on user training and support preparation Set expectations with users, IT and customers on deployment plans Extend the post-deployment support window if needed Deployment

10. Foundational Configuration Management infrastructure and process Testing strategy and tactics Development standards Leading Shadow Architecture Process adaptations Analysis approach QA approach Product Backlog grooming Long range planning & change control Architecture review & adaptation Developmental Advantages of an Established Team

11. Foundational Developmental Tools and Infrastructure established Developer practices that work A team in it’s groove (formed, stormed, normed, now performing) Management trust has been earned Process has been tuned (6+ months for high performance) Advantages of an Established Team

12. Long Term Planning Not Everyone is Agile Compatible Configuration Management Developer Practices QA Deployment Advantages of an Established Team Review