HARDCORE SCRUM. Focus shift to 4 P s Upping your game Copyright mxm9.com - Maxime Groenewoud

Transcription

1 HARDCORE SCRUM Focus shift to 4 P s Upping your game

2 Introduction Why - for whom? About me Straightforward process - why so many broken implementations? This Scrum stuff is really good, but I was expecting more from it. Tailoring Scrum - how? Entry - Mid level Scrum/Agile practitioners. Seems to be holes in most implementations 14 years IT experience: BA, Web Dev, SM & PM Instinctive early Agile adopter ScrumMaster since 2009 I just get it, OK! This attempts to identify these holes

3 Where things get messy Main themes from personal experience: Desperate attempt to keep the requirements up to date No documentation myth Prominent roles for BA s and PM s in Agile teams Proxy Product Owners - run!! Traditional test management in an Agile team Growing testing backlog Big bang implementations Silos in the team Stringent framework and implementation policies in highly regulated environments IT says: The business is not ready for Agile delivery No Architecture/Design myth Holding on to the Scrum framework and in the process losing what it s really about

4 Introduction to the 4 P s Some additional structure for assessment & improvement People Power Product Platform Process Progress Questions: collect and discuss during group discussions

5 People All people involved in delivering business value Key elements: Multi-disciplinary team - what does this mean? Business Product Owner Hierarchy for mentoring and guidance only Direct comms with and access to PO the Developer is BO$$ New Project Manager: mix of SM and PO New Business Analyst: key role during Project vision definition - Support during development New testing function Power: To self organise - determine how to deliver PO budget owner PO is representative - delegate of the business

6 People - group discussion What s wrong with your people? What have you seen wrong with people in other teams? People: how do we get it right? Ideal Product Owner skills

7 Product Business need translated - creating business value Key elements: Business relevant product Constant business verification DELIVER early - DELIVER often TEST early - TEST often (automate) Done is done Less products in development at a time Prioritise - avoid the never ending project Faster product turn-around

8 Product - group discussion Group discussion: How do we avoid the never ending project?

9 Platform Your flexible delivery framework, environments, dev practices, etc. Key elements: Enablers for the Product, allowing you to deliver often. Dev techniques/principles that work in this context: TDD, BDD, pair programming & testing Less environments - easier delivery Upfront design & architecture to the right level Break the back on IT delivery policies Architecture & Design: Dev Framework Side note: layered development - independant layers - flexible product - adaptable to change - multi-disciplined team

10 Platform - group discussion I m not a developer - What have I missed? What makes for an Agile Platform? How do you break the back of IT delivery policies?

11 Process How your team self-organises and structures for Agile delivery Key elements: Prepare for Agile delivery - inception - definition Agile framework - doesn t matter which one Planning Backlog of prioritised products to deliver Continuous adaption to business need Business acceptance - often Continuous Improvement Progress: Ensure you are continuously delivering working products Fast delivery!

12 Process - group discussion Often missed: How do you prepare for Agile delivery? How do you get ready for doing Sprints? What are the minimum requirements to start your first Sprint? What s the continuing need for the Project construct?

13 Closing Notes This is based on personal experience - feel free to disagree or add! Valuable reading: