Agile In Non Technical Contexts - Lessons For Agile Coaches
23 likes2,636 views
The document discusses the adoption of agile methodologies in non-technical areas, driven by IT's influence and a desire for business agility among executives. It highlights challenges faced by teams transitioning to agile practices, particularly with the misuse of Scrum, leading to inefficiencies due to specialization and poor understanding. Recommendations include customizing approaches to suit different contexts, promoting cross-functional collaboration, and emphasizing the importance of product ownership.
Agile In Non Technical Contexts - Lessons For Agile Coaches
- 1. Agile in non-technical contexts: Lessons for agile coaches Antony Marsh Agile Coach
- 2. Three Waves of Agile Charlie Rudd, 2016 ● Also “viral spread” of agile into other disciplines and areas ● DevOps extending agile into production and deployment
- 3. Why is Agile spreading to non-tech areas? ● Widespread adoption by IT, and hype and marketing efforts, LinkedIn, promotion of certifications ● Other teams/areas exposed to agile through working with IT teams and want to adopt agile ● Business Agility - senior managers and executives think “we must do/be agile” (often without really knowing why) ● Synergies with other well-known approaches (6 Sigma, Lean, innovation, lean startups) ● This “viral spread” of Agile is good for agile coaches looking for work but has disadvantages - fragmentation of approach, adoption of agile for the wrong reasons, poor understanding, lack of true cross-functionality
- 4. What non-tech areas are using agile? ● Marketing ● Sales ● Human Resources/People and Culture ● Construction ● Executives trying to implement change ● Call centres ● Risk management ● Strategy ● Change management
- 5. Most non-technical teams try Scrum first, but this is sometimes wrong ● Scrum is widely known and (kind of) understood so often teams try this first - also many consultants will sell Scrum as the “solution” ● Many people think Scrum = Agile ● Scrum is great for product development, but sometimes not so good for other business contexts
- 6. Case Study - Marketing at National Australia Bank ● Already doing “Scrum”, but not really understanding why ● Agile broadly supported by teams and management ● Teams produce marketing campaigns ATL and BTL - could be brand or product-focused ● Creative work outsourced to external agencies ● Work is then collated and moved through a (complex) approval process ● Output is “assets” - eg TVC, social media posts, billboards, Google Ads - content is reused through these assets but there are no real dependencies ● Very big budgets, but most money is spent on creative agencies and to buy media time
- 7. Campaign life-cycle Product team Segment team Program s Team Ideation/ brief Creative Agency Program s Team ApprovalApprovals - Marketing, Legal, Risk, Brand, stakeholder , Other Creation of assets - digital and physical Deploym ent of assets - digital and physical Analytics /feedbac k - make changes Decomm ision
- 8. Tier 1 Brand Advertisment
- 9. Physical assets O.O.H. - “out of home”
- 10. State of Agile at NAB (when I started) • “Scrum” rituals but poor understanding • Focus on tasks not deliverables • Many tasks per worker in one day • No/limited backlogs • Long term planning disconnected from sprint planning • Specialised teams not cross-functional teams • Desire to improve practices • Open to change • Ceremonies did help their productivity • Visualisation of work (scrum boards, marketing targets • Daily scrums useful 10
- 11. State of Agile at NAB (when I started) 11
- 12. Seven Wastes of Software Development (Poppendiek 2003)
- 13. State of Agile at NAB (continued) • Agile coaches were also scrum masters for 2-4 teams at once • Coaches placed into “Performance Units” and reported to a mid/senior level manager • Over time this led to overwork and a reduced ability to change practices, process and culture • Silo-ing of coaches led to fragmentation of approach • Culture of unhealthy competition between PUs 13
- 16. Challenges ● Complex, non-linear value stream (therefore inefficient) ● Teams highly specialised, not cross-functional - therefore many handoffs ● Work is outsourced to creative agencies who work at a different cadence - so waste, waiting, re-work ● Teams then manage work through a complex approval process - waste, waiting, re-work ● Teams then pass on work to Analytics and Deployment teams - waste, waiting, rework ● Poor/no backlogs exacerbate these problems ● Weak/no Product Owners
- 17. What we did ● 90 day plans to assist with product backlogs ● Kanban and scrumban boards to suit BAU type work ● Tribes and squads to break down silos and encourage cross functionality ● Portfolio views of work ● Scaled scrum (scrum of scrums) to encourage collaboration and better handover ● MoSCoW prioritisation of work with campaigns
- 20. (Eduardo Nosfuentes, Agile Eleven,available on Slideshare ) Seven Steps to Coaching Agile in Non-Software Development Teams
- 21. Lessons for Agile Coaches “As experienced agile practitioners and as people responsible for agile change and transformation, we should recognise the importance of being agnostic with agility at any level. This means one size does not fit all, one framework is not the answer, and the ‘what’ and ‘how’ should be suited to customer context and to a wider strategic vision.” http://agnosticagile.org