Downloaded 19 times
Uploaded byMatt Cowell
Agile in Action - Agile Overview for Developers
The document outlines the principles of the Agile methodology, emphasizing values such as individuals and interactions over processes and tools, and responding to change rather than following a plan. It details key components of Agile practice, including user stories, sprint planning, and the importance of communication and collaboration within cross-functional teams. Additionally, it provides guidance for developers on focusing on quality, continuous integration, and maintaining a sustainable pace in software development.
More Related Content
Similar to Agile in Action - Agile Overview for Developers
Agile in Action - Agile Overview for Developers
- 1. Matt Cowell VP ofSoftware Engineering, CSO agile in action
- 2.
- 3. the plan… • TheAgile Manifesto – Magic? • Agile Theory • What does agile mean for developers? • Agile @ Daxko
- 4. the agile manifesto… Individuals& Interactions --over-- Process and Tools Working Software --over-- Comprehensive Documentation Customer Collaboration --over-- Contract Negotiation Responding to Change --over-- Following a Plan
- 5. the magic part… •Forgo processes / tools • Make sure individuals interact • Don’t bother with documentation • No more contracts • No sense trying to create / follow a plan, just deal with change
- 6. the magic part… •Forgo processes / tools • Make sure individuals interact • Don’t bother with documentation • No more contracts • No sense trying to create / follow a plan, just deal with change Success!
- 7. the agile manifesto… Individuals& Interactions --over-- Process and Tools Working Software --over-- Comprehensive Documentation Customer Collaboration --over-- Contract Negotiation Responding to Change --over-- Following a Plan
- 8. the manifesto principles… •Satisfy the customer early and continuously • Harness change for competitive advantage • Deliver working software frequently • Business people and devs must work together • Build projects around motivated individuals • Conveying info face-to-face is most effective
- 9. the manifesto principles… •Progress = working software • Agile promotes sustainable dev (constant pace) • Technical excellence / good design enhances agility • Maximize the work not done • The best work emerges from self-organization • Team reflects regularly and tunes accordingly
- 10. the manifesto principles… •Progress = working software • Agile promotes sustainable dev (constant pace) • Technical excellence / good design enhances agility • Maximize the work not done • The best work emerges from self-organization • Team reflects regularly and tunes accordingly
- 11. sounds cool, buthow?
- 12. Large vs. smallpieces…
- 13.
- 14.
- 15. Figure out what’sneeded, when it is needed… Just enough…just in time
- 16.
- 17.
- 18. Scrum concepts… • UserStory • Product Backlog • Sprint Backlog • Release Burndown / Sprint Burndown • Sprint Planning • Daily Scrum • Sprint Demo / Review • Sprint Retrospective
- 19.
- 20. when do Iget the reqs?
- 21. when do Iget the reqs?
- 22. Source: “The NewNew Product Development Game” by Takeuchi and Nonaka. Harvard Business Review, January 1986. User stories are meant to seed conversation… when do I get the reqs?
- 23. estimation… Source: Rally How tallis the Sears Tower?
- 24. estimation… Source: Rally How tallis the Sears Tower? Info: The Empire State Building is 1250 ft
- 25. long term planning… •Size the product backlog • Measure velocity of the team size of backlog ÷ team velocity # sprints left Source: Rally
- 26. What about developers? 1)You are now part of a cross functional team
- 27. What about developers? 1)You are now part of a cross functional team 2) Attention to detail – get to 100% (i.e. DONE!)
- 28. What about developers? 1)You are now part of a cross functional team 2) Attention to detail – get to 100% (i.e. DONE!) 3) Don’t just ask the question; answer the question
- 29. What about developers? 1)You are now part of a cross functional team 2) Attention to detail – get to 100% (i.e. DONE!) 3) Don’t just ask the question; answer the question 4) Communicate with team…
- 30. What about developers? 1)You are now part of a cross functional team 2) Attention to detail – get to 100% (i.e. DONE!) 3) Don’t just ask the question; answer the question 4) Communicate with team… 5) Sustain your effort – take pride in meeting your commitments
- 31. What about developers? 1)You are now part of a cross functional team 2) Attention to detail – get to 100% (i.e. DONE!) 3) Don’t just ask the question; answer the question 4) Communicate with team… 5) Sustain your effort – take pride in meeting your commitments 6) Learn how to work in vertical slices
- 32. What about developers? 7)Focus on unit testing. QA is not there to find what you were too careless to check for…
- 33. What about developers? 7)Focus on unit testing. QA is not there to find what you were too careless to check for… 8) Learn patterns…use them
- 34. What about developers? 7)Focus on unit testing. QA is not there to find what you were too careless to check for… 8) Learn patterns…use them 9) Refactor early and often
- 35. What about developers? 7)Focus on unit testing. QA is not there to find what you were too careless to check for… 8) Learn patterns…use them 9) Refactor early and often 10)Practice test driven development
- 36. What about developers? 7)Focus on unit testing. QA is not there to find what you were too careless to check for… 8) Learn patterns…use them 9) Refactor early and often 10)Practice test driven development 11)Implement continuous integration
- 37. Matt Cowell VP ofSoftware Engineering, CSO
Editor's Notes
- #2 Thanks for the invite and hospitality… Thanks for showing up…
- #9 Our highest priority is to satisfy the customerthrough early and continuous deliveryof valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- #10 Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
- #11 Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
- #13 Break things into smaller pieces It doesn’t mean the end project gets smaller overall, just represented as smaller pieces
- #14 Timebox – fixed length iterations Same length every single time – team gets into a rhythm Change the scope, not the date
- #15 Done may contain lots of things… What if you need to be compliant? Need documentation? What if you have corporate architectural standards? Need to comply. What about security needs? Need to meet them. How do you define done for that particular feature / user story? How do you know when something has been tested enough? Do you require peer code reviews?
- #16 Just enough…just in time – may feel uncomfortable…
- #17 Get to done, and I mean done (not 80% done) First, need to define success and any applicable constraints, then get to success – RINSE.REPEAT
- #18 Explain Scrum First – Scrum is not simply a daily meeting Talk about sprint demo / sprint review and sprint planning
- #19 User Story As a software developer, I want to buy a book so that I can learn how to create applications with Ruby on Rails.
- #20 Scrum team commits to a set of features from the product backlog Business commits to leave the priorities alone during the sprint to allow the team to focus
- #21 Better yet – how do I know what to build? User Story As a software developer, I want to buy a book so that I can learn how to create applications with Ruby on Rails. Is that enough? Not likely. I need a mini-waterfall to figure this out, right? Wrong. We don’t need a 5-step process to develop working software in two weeks. We still need the content of these steps, mind you, but not necessarily so rigidly. Even within the context of a sprint, we need to get to done over and over again quickly. No “Design Phase” then “Construction Phase”…
- #22 Better yet – how do I know what to build? User Story As a software developer, I want to buy a book so that I can learn how to create applications with Ruby on Rails. Is that enough? Not likely. I need a mini-waterfall to figure this out, right? Wrong. We don’t need a 5-step process to develop working software in two weeks. We still need the content of these steps, mind you, but not necessarily so rigidly. Even within the context of a sprint, we need to get to done over and over again quickly. No “Design Phase” then “Construction Phase”…
- #23 Better yet – how do I know what to build? User Story As a software developer, I want to buy a book so that I can learn how to create applications with Ruby on Rails. Is that enough? Not likely. I need a mini-waterfall to figure this out, right? Wrong. We don’t need a 5-step process to develop working software in two weeks. We still need the content of these steps, mind you, but not necessarily so rigidly. Even within the context of a sprint, we need to get to done over and over again quickly. No “Design Phase” then “Construction Phase”…
- #24 Simple math – talk about relative estimation?
- #25 Simple math – talk about relative estimation?
- #26 Simple math Again, this is done at a high level – the closer you get to the release date, the more accurate you are…
- #27 AGILE IN GENERAL IS NOT PRESCRIPTIVE – BUT HERE ARE GOOD PRACTICES NECESSARY FOR GOOD AGILITY Meaning you have to do things outside of your role – no more – that’s not my problem
- #28 AGILE IN GENERAL IS NOT PRESCRIPTIVE – BUT HERE ARE GOOD PRACTICES NECESSARY FOR GOOD AGILITY Meaning you have to do things outside of your role – no more – that’s not my problem
- #29 AGILE IN GENERAL IS NOT PRESCRIPTIVE – BUT HERE ARE GOOD PRACTICES NECESSARY FOR GOOD AGILITY Meaning you have to do things outside of your role – no more – that’s not my problem
- #30 AGILE IN GENERAL IS NOT PRESCRIPTIVE – BUT HERE ARE GOOD PRACTICES NECESSARY FOR GOOD AGILITY Meaning you have to do things outside of your role – no more – that’s not my problem
- #31 AGILE IN GENERAL IS NOT PRESCRIPTIVE – BUT HERE ARE GOOD PRACTICES NECESSARY FOR GOOD AGILITY Meaning you have to do things outside of your role – no more – that’s not my problem
- #32 AGILE IN GENERAL IS NOT PRESCRIPTIVE – BUT HERE ARE GOOD PRACTICES NECESSARY FOR GOOD AGILITY Meaning you have to do things outside of your role – no more – that’s not my problem
- #33 Believe it or not, you have a choice as to whether or not to practice these things… Your employer can’t tell you not to practice Red, Green, Refactor
- #34 Believe it or not, you have a choice as to whether or not to practice these things… Your employer can’t tell you not to practice Red, Green, Refactor
- #35 Believe it or not, you have a choice as to whether or not to practice these things… Your employer can’t tell you not to practice Red, Green, Refactor
- #36 Believe it or not, you have a choice as to whether or not to practice these things… Your employer can’t tell you not to practice Red, Green, Refactor
- #37 Believe it or not, you have a choice as to whether or not to practice these things… Your employer can’t tell you not to practice Red, Green, Refactor
- #38 Thanks for the invite and hospitality… Thanks for showing up…