Harold Campbell, Shane Ferley and Brain Leke What’s the current problem? Non-agile delivery methods are costly, slow and often deliver software that requires expensive rework. Additionally, these delivery methods often don’t deliver the expected customer and business value. Bummer. Some common problems that affect organisations that use non-agile delivery methods include: Expensive project deliverables Expensive re-works Delayed Projects Missed market opportunities Being unable to deliver meaningful value to clients Lots of “Accidental” Complexity Ballooning of costs Inherent “Waste” embedded in rigid processes, re-enforced by organisational culture Silo-ed teams Poor collaboration between teams “Code then Fix” approach to delivery Difficult to respond “Quickly” to market changes Long feedback loops between product delivery and expected customer value Phased SDLC Little to no predictability (e.g. quality, schedules, risk, costs, value, etc.) Strong focus on process and tools, over delivering “actual” business and customer value What is Agile? Hmmm. So what’s this thing then? Agile Agile is a group of delivery methods, principles and practices for effectively delivering software that leverages collaboration and customer feedback. There are various Agile Delivery Methods, like: XP Scrum/Kanban/Scrumban SAFe/LeSS/DAD FDD Crystal Adaptive Software Development Lean Software Development At its core however, Agile is about four things really: : Focus on Income and Learning Delivery : Focus on Trust and Team collaboration Collaboration : Focus on Insights, Improvements (and celebrating success) Reflection : Focus on Experimentation and Change (which includes Data-driven decisions and Hypothesis validation) Improvement actual Alistair Cockburn (Co-author of the Agile Manifesto) referred to these four principles as . The Heart of Agile See: http://heartofagile.com/expanding-the-diagram/ Additionally, when using Agile Delivery methods, we use iterative processes to deliver small increments of value at short and regular intervals (AKA sprints, or iterations). These iterations are typically either 2 or 4 weeks long. Steven Thomas: Iterative Incremental See: http://itsadeliverything.com/revisiting-the-iterative-incremental-mona-lisa However, just having short iterations where no business or customer value is being delivered at the end of each iteration really doesn’t help. We need both: An iterative process incremental delivery of value. and Henrik Kniberg: Iterative Incremental Also see: https://www.mountaingoatsoftware.com/blog/agile-needs-to-be-both-iterative-and-incremental What do the delivery teams look like? Short answer: It depends on the “flavour” of Agile that you are using. For instance, Kanban is structure agnostic. While Scrum, another popular methodology, has the following structure: 1 x Product Owner 1 x Scrum Master Development Team (the people that produce the actual product): QAs, Analysts, UX, Developers, etc. Going back to that iterative process and sticking with Scrum, their process may look like the figure below. Scrum’s delivery process Why Agile? Staying relevant, innovating and increasing shareholder value are some of key reasons why companies undertake delivery transformation, with Agile. The benefits are similar but more wide-reaching. Additional benefits of adopting Agile Delivery methods include: Happier and more productive employees “Healthier” delivery teams and work environments Fast feedback from customers Early validation of business and market assumptions Increased innovation More predictable product delivery costs Shorter delivery cycles Less risky product delivery More predictable cycles/cadences (e.g. releases, inspect and adapt, etc.) Continuous focus on improvement Agile Delivery Values There are only four values that guide Agile Delivery methods. The four values are: A focus on delivering working software A focus on customer collaboration A focus on individuals and their interactions A focus on responding to change See: http://agilemanifesto.org These four values relate directly to the four principles that are at the Heart of Agile (described above). Scrum, Kanban, XP, SAFe, , (etc.) are all just frameworks/methods that build on these four values. Different methodologies (or the various combinations) will be better suited for different types of teams , or organisations — There is NO ONE TRUE WAY! insert-shiny-new-agile-thing-here Once your delivery methodology is based on the four values above, there is a deliberate focus on delivery, collaboration, reflection and improvement, . and you will become agile What’s required from Executives? A shift in the organization will require a shift in thinking and most likely changes in organizational structures and processes. Executives need to lead the transformation. This is done by: Changing mindset Shifting from Command-and-Control to Mutual Learning Being courageous (by being vulnerable) Adopting the Agile values and principles Focusing on delivering value vs. meeting deadlines and plans Being transparent Learning from “Short” failures Embracing the fact that the adoption of some Agile delivery practices require structural changes within the organization (e.g DevOps). will How do you adopt Agile Methods in your organisation? Again, like with most things Agile, it depends. Adoption can be seen as a two-pronged transformation initiative — it will require changes in cultural principles and delivery practices. Cultural Principles Culture is that intangible thing that resists change within your company. It is thing that embodies the ethos of the organization. As such, it is critical that a systematic, from the inside-out approach, is taken to change cultural norms, assumptions and beliefs. This is where the “radical shift” needs to happen. the To achieve this, there are a few core principles that should be adopted and promoted within the company. Specifically, these include: Servant Leadership Coaching — Process, technical, leadership and behavioral Continuous learning — Promoted at the organization, team and individual-level; and is budgeted for and factored in during planning Frequent reflection — Retrospectives, Sprint/Iteration reviews, etc. Individual feedback — Effective/impact feedback, speed-dating feedback, etc. Estimations as guides not commitments — shift from date-driven planning to value-driven planning. Engineering effort estimates seen only as guides and not “holy” commitments that can’t be changed. This promotes transparency and ensures that any change in facts, assumptions and dependencies, or knowledge and experience (e.g. changes to the team), that will impact delivery are shared as soon as they are known should be Harold Campbell and Brain Leke: All Estimates are lies! Data-driven decisions — PDCA/Build, measure, learn/OODA models Incremental delivery of value — see above Delivery Practices At the other end of the spectrum are delivery practices. These changes refer directly to how we deliver software. These practices typically include: Engineering practices — adopting Test-driven development, Pairing, having a code repository were developers commit code frequently (e.g. daily vs weekly), etc. DevOps — Practices that focus on getting fast build feedback, reporting, automated testing, improving code quality, continuous integration and continuous delivery of software Co-location — As much as possible, having the development team together or being able to collaborate easily Small batches in queues Work-In-Progress limits Self-organising teams Continuous team/self assessments Transparency over Cover-Your-Ass Iterative software development — see above Delivery team provides estimates for engineering effort — The people doing the work make the estimates Empiricism — Data-driven decisions using hypothesis validation (e.g. with Plan-Do-Check-Act/Build-Measure-Learn) Next Steps Pick a method and start. It’s doesn’t really matter if you start with Scrum or Kanban or whichever. Simply start. What is important however, regardless of your organisation’s maturity, is that you have a process that is focused on consistently improving your delivery, collaboration and reflection processes. Special thanks to Shane Ferley and Brain Leke for their contributions and feedback in creating this piece!
