Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

Agile Implementations - Tim FitzGerald - US Assure

•Download as PPTX, PDF•
•
JAX Chamber IT Council
JAX Chamber IT Council

The document introduces agile development methodologies and provides an overview of how to implement them in an organization. It discusses benefits like increased productivity and faster time to market. However, it also notes challenges like difficulties with estimation and working with non-agile teams. The document recommends leveraging agile best practices where possible and understanding that implementation requires requests of management and teams to change roles and processes.

1 of 15
Introducing the Agile Development Methodologies into your Organization March 2014 Tim FitzGerald US Assure
101 Agenda • Agile Techniques • Iteration Flow • What Agile Does not mean • Suggested Approach • Agile Roles • Scrum Master • Product Owner • Team • Product Backlog Cycle • User Stories • Sizing user stories • Agile Planning • Stand-up Meetings (SCRUM) • Iteration Planning Meeting • Velocity • Team Capacity • Demonstration • Retrospective
Todays Agenda – Why Agile, What to consider, Expect challenges Learn about why you should consider introducing Agile into your development organization. Participants will learn some of the benefits and challenges of implementing Agile into your Culture. Takeaways from the presentation: 1. What Agile is and why you should consider it 2. Considerations for how to modify to match your organization 3. Challenges and change management items to plan for
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individual . Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. At it’s core Agile is really 12 Principles
7. Working software is the primary measure of progress, 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity – the art of maximizing the amount of work not done – is essential. 11. The best architectures, requirements, and designs emerge from self- organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. …and a whole lot of change management
The Agile Manifesto “That is, while there is value in the items on the right, we value the items on the left more” Individuals and interactions Over Processes and Tools Working Software Over Comprehensive documentation Customer Collaboration Over Contract Negotiation Responding to Change Over Following a plan “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:” Signed by: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas © 2001, the above authors this declaration may be freely copied in any form, but only in its entirety through this notice. www.agilemanifesto.org
• Ad hoc - No planning • Constant stand-ups • Code and Go • No documentation • No Architecture involved • No process or discipline • No management What Agile Doesn’t Mean “Hater’s View” “Evolved View”
Traditional differences of Agile vs. Waterfall • Knowledgeable, collocated, collaborative developers • Customer involvement is a critical success factor • Reliance on tacit interpersonal knowledge • Empirical processes • Evolving requirements, rapid change • Smaller teams • Premium on rapid value and fast time to market • Product is built incrementally • Plan-oriented developers; mix of skills • Mix of customer capability levels and participation • Reliance on explicit documented knowledge • Prescriptive processes • Requirements knowable early; very stable, change is painful • Larger teams • Premium on high-assurance • Product delivery  all or nothing Agile Waterfall
Requirements management is very different across the methodologies • Defined in business value terms • Elicitation activities measured in hours/days • Easy to write at different levels of detail • Defined, owned, and prioritized managed by the customer • Handling Change • Change is expected (Requirements evolve as the project evolves) • Agile looks to the future for one release Agile User Stories Waterfall phased requirements • Defined at a very detail level • Elicitation activities measured in weeks or months • Heavy emphasis on getting all the requirements right the first time • Change is expensive (done all the work upfront) • Implies that the user/customer know the requirements and they will remain unchanged (unrealistic if never done before)
US Assure and many companies have seen increased productivity and reduced “time to market” using lean and agile concepts  Is about gaining speed and efficiency through improving processes  One of the major principles of Lean is to eliminate waste Lean  Is a conceptual framework for undertaking technology projects which is designed to promote “agility”  There are a number of agile methods (XP, SCRUM, Agile Modeling, AMDD, DSDM, AUP, FDD, Crystal, etc) in use today  Scrum is one of the “agile processes” that is most popular Agile  Process is open and visible to stakeholders  Focus is maintained on delivering the highest priority items first  Risk is reduced as work is produced in small batches (reducing complexity) and modifications incorporated at the start of every new sprint  Increased productivity, reduction of process inefficiencies, increased morale Benefits
Although, one size does not fit all organizations or cultures • There are now over 10+ defined “Agile” methods, and they vary considerably. (Ex: The Scrum approach is time-boxed, Kanban is buffer-based) • There are variations of extreme programming, Test based development, The Dynamic Systems Development Method (DSDM) , while the Rational Unified Process (RUP) try’s to scope an entire project before development starts. • Anyone who claim to have the unified definition of Agile, also has a “defined” Cloud based offering they want to sell you . • To me; Agile is about driving better communication, collaboration, changing cultural behaviors and creating flexibility in order to drive value to the business faster.
Try to leverage many of the Agile “Best Practices” for your project development where it makes sense for your company BEHAVIOR LEAN / AGILE STATE CURRENT STATE TARGET STATE Active Customer Engagement (Daily) Co-Location of Teams Dedicated Resources Constant Collaboration Small Batch size (Iterative Development) Incremental Delivery Adaptive Planning (vs reactive) Empowered Teams Customer Value Focused Sustainable Pace Reliable Delivery Appropriate Approval Level / Cycle Time Appropriate Documentation Types / Level Agile Engineering Techniques
Implementing a new methodology takes time and will introduce new risks and issues • You will see over-estimating and/or inaccurate estimation initially (Takes ~3-6 sprints to refine) • Efficiencies may not be fully realized due to lack of modifications in approval process • Efficiencies may not be fully realized due to lack of modifications in documentation process • Well managed controls from an audit perspective are not fully defined • Resource constraints in partner and / or support organizations can cause issues • Working with partners and other waterfall based organizations can be challenging • Limited agile coach resources may be available to scale adoption • Organizational and personal tolerance to change may create headwinds While some may think Agile is cool and cutting edge, it’s also hard at first, so remember:
Change requires requests of you, your management, and your teams • To be open to change for project operating principles: • Teams need to Commit, take Ownership for their commitments, and ask for help and guidance when they need it • Leadership needs to Trust that teams will live up to their commitments, and trust that they will ask for the help they need • Leadership needs to be prepared to provide support and guidance to solve problems when the team asks for help • News, whether good or bad, needs to be given and received in the spirit of openness, collaboration, cooperation, and without fear of retribution; the focus will be on how to get back on track • Team members will have to change the way they do their day-to-day tasks • Traditional command and control type management needs to transition to facilitative leadership and supportive coaching • Agreement on project roles • Approval to initiate next infrastructure project as agile
Appendix

More Related Content

Agile Implementations - Tim FitzGerald - US Assure

  • 1. Introducing the Agile Development Methodologies into your Organization March 2014 Tim FitzGerald US Assure
  • 2. 101 Agenda • Agile Techniques • Iteration Flow • What Agile Does not mean • Suggested Approach • Agile Roles • Scrum Master • Product Owner • Team • Product Backlog Cycle • User Stories • Sizing user stories • Agile Planning • Stand-up Meetings (SCRUM) • Iteration Planning Meeting • Velocity • Team Capacity • Demonstration • Retrospective
  • 3. Todays Agenda – Why Agile, What to consider, Expect challenges Learn about why you should consider introducing Agile into your development organization. Participants will learn some of the benefits and challenges of implementing Agile into your Culture. Takeaways from the presentation: 1. What Agile is and why you should consider it 2. Considerations for how to modify to match your organization 3. Challenges and change management items to plan for
  • 4. 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individual . Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. At it’s core Agile is really 12 Principles
  • 5. 7. Working software is the primary measure of progress, 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity – the art of maximizing the amount of work not done – is essential. 11. The best architectures, requirements, and designs emerge from self- organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. …and a whole lot of change management
  • 6. The Agile Manifesto “That is, while there is value in the items on the right, we value the items on the left more” Individuals and interactions Over Processes and Tools Working Software Over Comprehensive documentation Customer Collaboration Over Contract Negotiation Responding to Change Over Following a plan “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:” Signed by: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas © 2001, the above authors this declaration may be freely copied in any form, but only in its entirety through this notice. www.agilemanifesto.org
  • 7. • Ad hoc - No planning • Constant stand-ups • Code and Go • No documentation • No Architecture involved • No process or discipline • No management What Agile Doesn’t Mean “Hater’s View” “Evolved View”
  • 8. Traditional differences of Agile vs. Waterfall • Knowledgeable, collocated, collaborative developers • Customer involvement is a critical success factor • Reliance on tacit interpersonal knowledge • Empirical processes • Evolving requirements, rapid change • Smaller teams • Premium on rapid value and fast time to market • Product is built incrementally • Plan-oriented developers; mix of skills • Mix of customer capability levels and participation • Reliance on explicit documented knowledge • Prescriptive processes • Requirements knowable early; very stable, change is painful • Larger teams • Premium on high-assurance • Product delivery  all or nothing Agile Waterfall
  • 9. Requirements management is very different across the methodologies • Defined in business value terms • Elicitation activities measured in hours/days • Easy to write at different levels of detail • Defined, owned, and prioritized managed by the customer • Handling Change • Change is expected (Requirements evolve as the project evolves) • Agile looks to the future for one release Agile User Stories Waterfall phased requirements • Defined at a very detail level • Elicitation activities measured in weeks or months • Heavy emphasis on getting all the requirements right the first time • Change is expensive (done all the work upfront) • Implies that the user/customer know the requirements and they will remain unchanged (unrealistic if never done before)
  • 10. US Assure and many companies have seen increased productivity and reduced “time to market” using lean and agile concepts  Is about gaining speed and efficiency through improving processes  One of the major principles of Lean is to eliminate waste Lean  Is a conceptual framework for undertaking technology projects which is designed to promote “agility”  There are a number of agile methods (XP, SCRUM, Agile Modeling, AMDD, DSDM, AUP, FDD, Crystal, etc) in use today  Scrum is one of the “agile processes” that is most popular Agile  Process is open and visible to stakeholders  Focus is maintained on delivering the highest priority items first  Risk is reduced as work is produced in small batches (reducing complexity) and modifications incorporated at the start of every new sprint  Increased productivity, reduction of process inefficiencies, increased morale Benefits
  • 11. Although, one size does not fit all organizations or cultures • There are now over 10+ defined “Agile” methods, and they vary considerably. (Ex: The Scrum approach is time-boxed, Kanban is buffer-based) • There are variations of extreme programming, Test based development, The Dynamic Systems Development Method (DSDM) , while the Rational Unified Process (RUP) try’s to scope an entire project before development starts. • Anyone who claim to have the unified definition of Agile, also has a “defined” Cloud based offering they want to sell you . • To me; Agile is about driving better communication, collaboration, changing cultural behaviors and creating flexibility in order to drive value to the business faster.
  • 12. Try to leverage many of the Agile “Best Practices” for your project development where it makes sense for your company BEHAVIOR LEAN / AGILE STATE CURRENT STATE TARGET STATE Active Customer Engagement (Daily) Co-Location of Teams Dedicated Resources Constant Collaboration Small Batch size (Iterative Development) Incremental Delivery Adaptive Planning (vs reactive) Empowered Teams Customer Value Focused Sustainable Pace Reliable Delivery Appropriate Approval Level / Cycle Time Appropriate Documentation Types / Level Agile Engineering Techniques
  • 13. Implementing a new methodology takes time and will introduce new risks and issues • You will see over-estimating and/or inaccurate estimation initially (Takes ~3-6 sprints to refine) • Efficiencies may not be fully realized due to lack of modifications in approval process • Efficiencies may not be fully realized due to lack of modifications in documentation process • Well managed controls from an audit perspective are not fully defined • Resource constraints in partner and / or support organizations can cause issues • Working with partners and other waterfall based organizations can be challenging • Limited agile coach resources may be available to scale adoption • Organizational and personal tolerance to change may create headwinds While some may think Agile is cool and cutting edge, it’s also hard at first, so remember:
  • 14. Change requires requests of you, your management, and your teams • To be open to change for project operating principles: • Teams need to Commit, take Ownership for their commitments, and ask for help and guidance when they need it • Leadership needs to Trust that teams will live up to their commitments, and trust that they will ask for the help they need • Leadership needs to be prepared to provide support and guidance to solve problems when the team asks for help • News, whether good or bad, needs to be given and received in the spirit of openness, collaboration, cooperation, and without fear of retribution; the focus will be on how to get back on track • Team members will have to change the way they do their day-to-day tasks • Traditional command and control type management needs to transition to facilitative leadership and supportive coaching • Agreement on project roles • Approval to initiate next infrastructure project as agile