Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Benefits of Agile Software Development for Senior Management

1,334 views

Published on

This is a presentation to Senior and Executive Managers which is used to explain how Agile Software Development processes and practices benefit them, their organization and their customers.

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

Benefits of Agile Software Development for Senior Management

  1. 1. The Benefits of Agile Software Development for Senior and Executive Management David Updike February 2014 Agile Lean Kanban http://www.AgileLeanKanban.com
  2. 2. About David Updike  An IT veteran since 1980’s  Agile Coach since 2008  Developer for 19 years, Architect, IT Delivery Manager, Scrum Master and former Vice President of Agile Transformations  Member of Agile Alliance, Scrum Alliance, DFW Scrum User Group and Agile Leadership Network  Blogger at http://www.AgileLeanKanban.com  Certified Scrum Master (CSM) since 2006  Involved in Agile Transformations at American Airlines, Southwest Airlines, Sabre Holdings, The Broadlane Group, AT&T and others.
  3. 3. What we know  As Senior Management you don’t/didn’t pick Agile Development processes and practices because they were new, different and have cool development techniques  You have different objectives • reducing average time-to-market of software development projects • increasing return on investment (ROI) in information technology • increasing end-user effectiveness and satisfaction • lowering costs and risks • adapting to a changing business landscape • higher quality software products • and even a more satisfied work force
  4. 4. But first, how does using Agile… utilize Schedule Budget and Feature Scope
  5. 5. Traditional Development is Plan Driven FIXED SCOPE (features, functionality) FIXED TEAM, BUDGET (costs) FIXED SCHEDULE (time) With a given team you MUST complete a set amount of Scope by a fixed deadline. To do this a team executes Big Up Front Analysis & Design (BUF) Historical consequences • Inaccurate detailed early estimates & plan leading to IT Death marches at the end • IT Death marches and meeting a set scope lead to fragile code bases / bad software • All the above leads to attrition of unhappy valuable people with deep domain knowledge
  6. 6. Agile Development is Value Driven FIXED TEAM, BUDGET (costs) FIXED SCHEDULE (time) VARIABLE SCOPE (features, functionality) A given team uses “just enough, just in time” evolutionary design to deliver the highest value functionality with the best quality by the set date. Differences • The Business (via Product Owner) decides on most valuable features for each Iteration • The team proceeds at best possible speed given a very high quality bar • We deliver on time and on budget every time with the most valuable features
  7. 7. What is often heard… “But we must have ALL of our desired features.” Do we?
  8. 8. Standish Group Study on Used Features Features and Functions Used in a Typical System Lesser Value Greater Value If you really want these features that’s OK, However they probably don’t all need to be in Release 1 Maxim: Our customers don’t use everything we put in front of them equally.
  9. 9. What is ISN’T often heard IS… “When will the product have enough capability to release it to our customers.” Instead we wait for implemented scope which increases time-to-market
  10. 10. How does using Agile… reduce Time-to-Market and increase Return on Investment
  11. 11. Reducing Time-to-Market and increasing ROI with Agile 12 months Month 1 Month 2 Month 3 Month 4 Month 5 Month 6 Month 7 Month 8 Month 9 Month 10 Month 11 Month 12 VVV $$$ VVV $$$ VVV $$$ VVV $$$ VVV $$$ VVV $$$ Normal Traditional Development One Release, 9 months of development = 9$ or V Agile Development Release 1 3 months MVP V $ V $ Release 2 Reduced Time to Market Increased ROI V $ 3 months Use real customer feedback from Release 1 improve Release 2 product. VV $$ VV $$ Release 3 VV $$ 3 months = 18$ or V Use real customer feedback from Release 2 improves Release 3 product. Same 9 months of development makes 9 more $ or Value units for the company (and maybe more than that with a better product) V = a unit of Value $ = a financial unit MVP = Minimum Viable Product
  12. 12. Agile Development involves incremental delivery Agile Development Scrum Methodology Example Release X Release Planning Defined Release Features 2 weeks 2 weeks 2 weeks 2 weeks 2 weeks 2 weeks 1 day DEPLOY 1 day 1 day 1 day 1 day 1 day An option could exist allowing you to go to Production part way through a Release. D E M O D E M O 2 Week Iterations with Short Daily Planning Meetings D E M O D E M O D E M O Release Features Complete Next Release Planning Undeveloped Feature Developed Feature
  13. 13. One method using the Standish Group Studies An E x a m p l e F e a t u r e s a n d F u n c t i o n s U s e d i n a Typ i c a l S ys t e m Identify these as your Release 2 Identify these as your Release 1 (True Minimum Viable Product) Identify these as your Release 3 Identify these as your Release 4
  14. 14. Comparing the serial and incremental approaches to development Comparing the financial risk of a serial approach to development with an incremental approach (the numbers are relative). Scott Ambler http://en.wikipedia.org/wiki/Scott_Ambler http://www.agilemodeling.com/essays/examiningBRUF.htm
  15. 15. How does Agile use this to… increase end user effectiveness and satisfaction
  16. 16. Lightweight planning allows the team and stakeholders to start seeing working software sooner and improvements are made based on this data. Short feedback loops like this allow the team to improve software quicker.
  17. 17. Business and IT work together throughout the project. Changes are proposed based on visible working software that benefit a specific end user. The project flexes to accommodate the changes based on prioritization of the Business (Product Owner) ensuring development principles are not sacrificed.
  18. 18. Quick Feedback Loops, periodic Demonstrations as well as Team Retrospectives allow improvements to be made to the product and process during development. Feedback comes from… The Product Owner The Delivery Team Product Stakeholders Real Users/Customers Usability studies
  19. 19. Allowing flexibility and changes to the functionality under construction allows the team to improve the experience of the end user which increases their effectiveness and their satisfaction.
  20. 20. How are changes incorporated 1) In Release Planning they fill the Release with what they think can be accomplished. 2) Throughout the Release changes are proposed to and by the Business Product Owner. 3) It is the Product Owner’s responsibility to weigh the changes and if they are important enough they add it to the Release while they take out (or lower the priority of) something of equal size.
  21. 21. How does using Agile… lower costs and risks
  22. 22. Saving costs by not implementing what won’t be used Features and Functions Used in a Typical System You probably don’t need these features.
  23. 23. Face-to-face collaboration and close cross team communication reduce risks of miscommunication. Where co-located face-to-face collaboration is not possible, as in distributed environments, teams use other practices to overcome this obstacle.
  24. 24. Early focus on risky areas of the Product (functional and technical) enable the team to mitigate these risks early instead of late in product development which could jeopardize production implementations dates. Also, frequent demonstrations of working software exposes risks forcing them to be handled.
  25. 25. An underpinning of Agile is transparency. Incremental progress is highly visible by everyone through demonstrations of the growing software as well as charts and metrics thus allows better project governance.
  26. 26. The Defect Cost Curve shows agile techniques are less costly than traditional techniques Mapping the potential costs of addressing defects found by various detection techniques (the agile techniques are in green, the traditional techniques are in red). Scott Ambler http://en.wikipedia.org/wiki/Scott_Ambler http://www.agilemodeling.com/essays/examiningBRUF.htm
  27. 27. How does Agile… create high quality software products
  28. 28. Agile IT Teams define what the delivery of Quality means before beginning a project and call themselves out if this level is not maintained. The teams deliver software that this pace can support. All features are developed to this Quality definition (usually called a Definition of Done). Example: All code is checked in and code reviewed. Code will be covered by 70% automated unit tests. All Test Cases pass (automated where possible). All Performance Tests pass. All Acceptance Criteria are met. All code meets Coding Standards & Conventions. No Critical, High or Medium Defects exist. Functional Test Cases are fully tested by QA (automated).
  29. 29. How does Agile allow business to… adapt to a changing business landscape
  30. 30. Create the Product your customers need, not just the one that was planned at the beginning As you see the software being created you should be able to change your plan so that a better product is created. The lighter the planning method and processes the quicker changes can be made and waste is reduced. Your competitors don’t just sit there waiting for you to deploy new software. You have to have to ability to quickly adapt to a changing marketplace.
  31. 31. Change the future plan as needed With IT Teams focused on delivering software to a defined high quality bar, the business has the flexibility to change future high-level requirements to meet the needs of a changing business climate.
  32. 32. Allowing changes to the Backlog of functionality Agile Development Release X Release Planning Defined Release Features 2 weeks 2 weeks 2 weeks 2 weeks 2 weeks 2 weeks 1 day DEPLOY 1 day 1 day 1 day Change Backlog as needed Change Backlog as needed Change Backlog as needed Change Backlog as needed D E M O Release Features Complete 2 Week Iterations with Short Daily Planning Meetings D E M O D E M O D E M O D E M O 1 day 1 day Next Release Planning Can change future Stories in the Backlog Undeveloped Feature Developed Feature
  33. 33. Agile Lean Kanban http://www.AgileLeanKanban.com http://www.LinkedIn.com/in/daveupdike Twitter: @updikedave

×