Agile - One Size Does Not Fit All
- 1. Israel Gat Alexander Kress Maurizio Mancini Agile - One Size does not fit All!!
- 2. Who We Are • Israel: Agile Coach on this gig • Alex: SCRUMmaster on the RedFlagDeals gig • Maurizio: Head of QA for YP Canada • As important as who we are, and possibly more, is the evolution of our relationships: – We became colleagues and friends in the course of the engagement.
- 3. What Our Overarching Message is • The path to Agile depends critically on the level of software maturity we start with • Picking the wrong SDLC process could be poisonous to your organization. • Specifically, for “less mature, ad hoc” software development environments there is a lot to be said for taking a two step path: – Ad Hoc à Incremental & Iterative (IID) – Incremental & Iterative à Agile • The blueprint for so doing is anchored in our 2013-2014 experience at Yellow Pages (YP)
- 4. Cutter Overview • A global think tank helping organizations forge solutions to business technology challenges since 1986 – Cutter is consistently on the leading edge of emerging ideas • Not a typical IT advisory or consulting firm – All products and services – consulting, training, and research – are supplied by internationally recognized thought leaders, expert practitioners, and top academics – In short, there are no junior staff members – every consultant carries out his/her engagements “A to Z” • The Consortium’s great strength is that it can draw on its experts to assemble the ideal team to tackle any challenge that might arise during an engagement – Approximately 200 member-experts spanning all IT functional disciplines and industries • The only analyst firm with zero ties to vendors
- 5. Cutter @ Yellow Pages Cutter was engaged for 2 mandates at YP – First was to implement Agile (training and coaching) at RedFlagDeals (RFD), a YP company. – Second was to just to do Agile training to mobile development teams at YP.
- 6. Overview of YellowPages (YP) • YP is Canada’s largest provider of full-serve digital media and marketing solutions specifically for small businesses. • Approx. 2300 employees. • Approx. 1 billion in revenue. • 2nd largest advertiser in Canada after Google.
- 7. YP’s Business Transformation Our mission is to connect businesses and people like never before: – Unlike the global Internet vendors, our focus is local – Contribute to the success of SMEs
- 8. From Print to Digital Advertising YP’s Digital Transformation 7.3 Million Unique Visitors per Month 6.5 Million Downloads!
- 9. Excellence in Software Engineering Broad and deep excellence in Software Engineering is critical to YP’s digital transformation. Why? – Window of opportunity. – Need to excel at multiple levels in the software we develop. – Customers do not possess strong brand loyalty.
- 10. Software Engineering at YP 15 Development Teams
- 11. Software Engineering at YP • Re-Engineering of Software Engineering practices at YP started 2.5 Years Ago. • Software development was being done by Contractors. • Tools à JIRA, JIRA Agile, FishEye, Stash. • Software Development Life Cycle (SDLC) – What’s that?
- 12. Which SDLC for YP? • Most projects at YP were using a either “ad-hoc” or a “Waterfall like” method. • Which SDLC is right at YP for this transformation? – Waterfall – Incremental and Iterative Development (IID) – Agile
- 13. Incremental & Iterative Development • For YP, IID means: – Plan for X weeks of Increments followed by at least 2 Iterations – Typical release is planned between 6 to 12 weeks. Increment 1 Increment 2 Increment 3 Feature Complete Iteration 1 Code Freeze Iteration 2 Ship - Increments do not go to production. - Not everything is tested within an increment/iteration - 2 PhaseGates - Last “golden” Iteration goes to production.
- 14. What’s in a Word able to move quickly and easily…
- 15. Agile Illusions and Expectations
- 16. One Step at a Time
- 17. Pilot at YPG Take one self contained group – RedFlagDeals (RFD) – The largest deals and coupons website in Canada. – Successfully delivering software using a combination of Waterfall and IID but suffering many internal challenges.
- 18. Challenges at RFD • Requirements delivered as long documents rather than “invitation for a dialog” • Timelines very strict and not realistic – Community (PM) needs vis-à-vis quality standards • No time for refactoring • Many suboptimal yet permanent design decisions to “get there” faster • Product Organization and Development not on friendly terms • Many people on the team unhappy
- 19. Approach to Pilot • Mentor is committed to spend enough time with team • Getting prior acceptance from major stakeholders in all divisions • Training in SCRUM “theory” for the whole team, including business all the way to GM • Hands on training • Flying solo with trainer’s oversight and active participation when needed for a couple of sprints
- 20. Approach to Pilot Apply Agile theory by the book – Dedicated product owners, Dev and QA resources – Co-located – 2 Week Sprints – Use all of the Agile Principals (Stories, Product Backlog, Sprint Backlog, Daily Scrum Meeting, Sprint Planning Meeting, Poker Planning, Sprint Reviews, Sprint Retrospectives) – Every Sprint is Production Ready
- 21. “RFD” Agile • Mostly by the book (minus the projects are often sprint length) • 2 weeks, deployable sprints • BDD fleshed out stories • A human readable but structured way to express user stories and acceptance criteria • Agreed on Engineering Tax per sprint to address Technical Debt • Dev and QA building automation • SCRUM master from the team (Dev Manager)
- 22. Before and After at RFD • Changed interaction with PO • The Team (Devs, QA) jelled with the PO • Predictability • Quality • Frequency of releases • Team job appreciation
- 23. What was Hard • Initial buy in • From requirements to user stories • User stories as BDDs • Getting used to the ceremonies • Settling on the new “rules”: – Engineering Tax (Address Technical Debt) – Definition of Done includes staging “UAT” by PO – Handling production issues • Working with non Agile teams • Getting used to releasing every 2 weeks (75% of the code increments were shipped upon completing the sprint)!
- 24. What was Easy • Living without the spec • Talking during the retrospectives • Getting people to enjoy the reviews • Getting rid of constant QA overtime • Having a happier (but overworked) PO
- 25. RFD ‘Secret Sauce’ • Genuine desire to deliver software by using software engineering practices. • Professional and personal maturity of team members: – GM, PO and SM in particular • Multi-level alignment: – From the lowliest employee all the way to the CTO • Strong support and encouragement by both CTO and CMO.
- 26. 1 Down, 14 more to go Wrong
- 27. 1 Down, 14 more to go • We had a corporate focus on deploying better software engineering practices across all 15 Software Engineering Teams • We did not change RFD in a vacuum
- 28. Who’s Next? • As RFD gained experience at Agile, 14 other teams were working at getting good at Incremental & Iterative Development (IID). • After 6 months of Agile success at RFD we organized Agile training for 4 other teams.
- 29. Who’s Next? • Of the 4 teams trained, only 2 mobile development teams were picked to do Agile because: – Most committed to making it work. – We thought we had committed resources. MT1 MT2
- 30. The remaining teams… • Meanwhile, remaining 12 teams did not meet the criteria above but also didn’t: • They continued with IID.
- 31. Agile Approach for Next 2 Teams • Train the people that would become SCRUMmaster’s in one session. – A.K.A à recycled Project Managers MT1MT2 • Train the whole team, including newly minted SM’s on Agile practices in another session.
- 33. Agile Approach for Next Teams
- 34. Mobile Team 1 • Key differences between MT1’s approach and RFD: – No Agile coaching – Difficult to focus – Resources were mostly dedicated… but got interrupted – Corporate priorities kept changing • The initial attempt was not completed. MT1
- 35. Mobile Team 1 • Mobile Team 1 then came back to Agile project 2 months later. • The dedication of the people on the team, including the “stand-in” Scrum master, made it work! • Team Self-Evaluation was done at the end and it was deemed a success. MT1
- 36. Mobile Team 1 - ‘Secret Sauce’ • Team’s Buy-In to use Agile. • Everyone understood their role. • Used all of the Agile Ceremonies. • Testing was mostly manual – Mobile APP. • Automation was focused on a “Smoke Test”. • Agreed on final Hardening Sprint. • Only the last Sprint went to production. (1 out 7 or ~ 15%). • SCRUMmaster from the team (BA). MT1
- 37. Mobile Team 2 A couple of key differences led to a Failed Agile implementation in this team: MT2 – SCRUMmaster (A.K.A recycled Project Manager) really struggled to understand his new role. – SCRUMmaster truly did not understand how Agile/Scrum works.
- 38. MT2
- 40. Where are the other 12 teams today? Two other teams have successfully implemented Agile very similar to RFD. Key factor à hiring of a SCRUMmaster that truly knew and understood how to drive the team.
- 41. Where are the other 12 teams today? Most of the other teams have decided to use IID. Why? – Teams are just not ready yet to adopt Agile. – Product Owner role is not always clear. – When a PO does exist, not always available. At best they attend the demos. – Resources are not committed. – No Agile Training has been provided. – No SCRUMmaster role exists on the team. – Use of traditional Project Managers.
- 42. Where are the other 12 teams today? However, the teams are still delivering good quality software on a regular basis (6 to 8 weeks on average) so IID is working for them!
- 43. YP Secret Sauce • The best sauces are the ones with simple ingredients… • The YP Secret Sauce for choosing Agile/Scrum or IID is: – Can all actors in your organization commit to meeting ALL of the principals as prescribed by the Agile Manifesto? • If Yes à Then Agile/Scrum is for you – If no à then IID is for you. • Repeatable development process that involves all key players from the start of the project. • Allows for an organizations unexpected demands. • Allows for the change of resources. • Delivers functionality that has business value at a regular predictable pace.
- 44. Retrospective The dose makes the poison Paracelsus – the founder of toxicology had the following saying… Pick a software process that fits your organizations realities today! Pick the right amount of process or it will be poisonous and lead to process failure!
- 46. Key Takeaways Training and Coaching are vital to the success of any process deployment. Have committed resources to implement and follow-up on the roll out of any process.
- 47. Key Takeaways Have an amazing SCRUMmaster! When you have multiple teams, some may be IID and some may be Agile.
- 48. Key Takeaways By implementing Agile/Scrum and IID, YP has improved Software Engineering Practices!
- 49. Will the other teams make it to Agile? See you at Agile 2015… Next Steps
- 50. Q & A