Agile: What's in it for me?


Published on

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

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • First, I want to thank you all for being here. You had other options, and you chose to be at this talk.
  • The reason I’m here is because agile is a better way of working for everyone involved.
  • In traditional projects, where does most documentation take place? Why do we need that documentation? Is for evidence in a case, or for getting work done? Our documentation should be for getting work done. When do we know the least about any project? TAGRI Cowboy coding- In agile, you have more transparency. With transparency, you have more accountability, which often leads to more discipline. 3 questions during standup Agile isn’t a silver bullet, and actually exposes dysfunctions rather quickly.
  • One important thing to remember about Agile, is that there are principles and there are practices.
  • The demo has to show completed items. Meaning: the work has to be designed, coded, tested, documented, and sometimes even deployed.
  • On February, 2001, at The Lodge at Snowbird ski resort in Utah, seventeen people met to discuss what was then being called “Lightweight methodologies”. What emerged was the Agile Manifesto. Representatives from Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others sympathetic to the need for an alternative to documentation driven, heavyweight software development processes convened.
  • Time. In traditional projects, we often run out of time and something has to go. What is it? Quality, documentation, testing. In agile projects, testing and quality is a part of every iteration. What get cut is features, and that’s not necessarily a bad thing.
  • Software economics- A team of 8 -10 people costs about a million dollars a year. Decreased investment. Decreased operating expenses Increased throughput
  • The team starts to get synergy after working together for long periods of time
  • You got peeps. Story about team member’s cat. Lunch traditions A team that is cohabitating and working on the same project stay up to date through daily meetings and proximity communication better than they would if they worked in different areas. Everyone becomes immediately aware if objectives have changed. The product owner of the team speaks for the business and is in direct contact with the business and requirements don’t get muddled after going through several hands before getting to the team. People aren’t overburdened by people coming to them ad hoc and asking for help with things not related to what they are working on.
  • Benefits for owner, manager.
  • Benefits for owner, manager, end user.
  • Conversation vs heavy documentation.
  • Working software vs. project charts, status reports, timelines, etc Death marches, overtime.
  • Inspect and adapt.
  • Agile: What's in it for me?

    1. 1. Agile: What’s in it for me? CodeStock 2009
    2. 2. Adrian Carr <ul><li>Software Developer for 10 years </li></ul><ul><li>Currently work for Jewelry Television in Knoxville </li></ul><ul><li>Worked for Fidelity Information Systems in Atlanta </li></ul><ul><li>Worked for Alltel Information Systems in Atlanta </li></ul><ul><li>Worked for a large non-profit in Boone, NC </li></ul><ul><li>Founder and Organizer of Knoxville Agile Practitioner’s Group ( http:// ) </li></ul>
    3. 3. Disclaimer <ul><li>Be skeptical, but open minded. </li></ul><ul><li>This is how I develop software. Take the parts that make sense to you. Ignore the rest. </li></ul><ul><ul><li>Ron Jeffries </li></ul></ul><ul><li>If you currently have a high rate of success on your projects, then this may not be the best thing for you. </li></ul>
    4. 4. What Agile is Not Supposed to Be
    5. 5. Some Agile Myths <ul><li>No documentation </li></ul><ul><li>Cowboy coding </li></ul><ul><li>No up-front design </li></ul><ul><li>Agile is a silver bullet. </li></ul>
    6. 6. What is Agile Software Development? <ul><li>project management process that encourages frequent inspection and adaptation, </li></ul><ul><li>a leadership philosophy that encourages teamwork, self-organization and accountability, </li></ul><ul><li>a set of engineering best practices that allow for rapid delivery of high-quality software, </li></ul><ul><li>a business approach that aligns development with customer needs and company goals </li></ul>
    7. 7. Agile Practices <ul><li>Scrum- </li></ul><ul><ul><li>Small, self-organizing, cross-functional teams </li></ul></ul><ul><ul><li>Defined roles within a team. </li></ul></ul><ul><ul><li>Defined rules, based on project management. </li></ul></ul><ul><ul><li>Work in short iterations, or “sprints” </li></ul></ul><ul><ul><li>Demo progress at the end of every iteration. </li></ul></ul><ul><ul><li>Re-plan for the next iteration, always doing the highest value things first. </li></ul></ul>
    8. 8. Agile Methodologies <ul><li>XP </li></ul><ul><ul><li>Very disciplined. </li></ul></ul><ul><ul><li>Onsite customer </li></ul></ul><ul><ul><li>Pair programming </li></ul></ul><ul><ul><li>Unit testing </li></ul></ul><ul><ul><li>Refactoring </li></ul></ul><ul><ul><li>Frequent delivery </li></ul></ul><ul><ul><li>Continuous integration </li></ul></ul><ul><ul><li>Test-Driven Development </li></ul></ul><ul><ul><li>Simplicity </li></ul></ul>
    9. 9. The Agile Manifesto <ul><li>Individuals and interactions over processes and tools </li></ul><ul><li>Working software over comprehensive documentation </li></ul><ul><li>Customer collaboration over contract negotiation </li></ul><ul><li>Responding to change over following a plan </li></ul><ul><li>That is, while there is value in the items on the right, we value the items on the left more. </li></ul>We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
    10. 10. Traditional Projects
    11. 11. Traditional Projects:
    12. 12.
    13. 13.
    14. 14. IT has an Image Problem <ul><li>Typically, we’re seen as a roadblock. When we do succeed, we're viewed as too slow, too expensive, or delivering poor quality. </li></ul>
    15. 15. What’s in it for Me?
    16. 16. I Own or Run This Business- What’s in it for Me? <ul><li>What is the #1 killer of projects? </li></ul><ul><ul><li>Answer: Time </li></ul></ul><ul><li>In traditional projects, we often run out of time and something has to go. What is it? </li></ul><ul><li>Quality, documentation, testing. </li></ul><ul><li>In agile projects, testing and quality is a part of every iteration. What get cut is features, and that’s not necessarily a bad thing. </li></ul>
    17. 17. I Own or Run This Business- What’s in it for Me? <ul><li>ROI </li></ul><ul><li>There's a reason why you're paying these expensive people to do this work for you. </li></ul><ul><ul><li>You want your stuff. </li></ul></ul><ul><ul><li>You want it as soon as possible. </li></ul></ul><ul><ul><li>You'd rather not pay more for it than you have to. </li></ul></ul><ul><li>Or, since you’re going to have to pay for it, you at least want to get the most for your money. </li></ul><ul><ul><li>A team of 8 -10 people costs about a million dollars a year. </li></ul></ul>
    18. 18. I Own or Run This Business- What’s in it for Me? <ul><li>Traditional Projects and the Cost of Change </li></ul><ul><ul><li>Feature bloat. You’re paying for unused or rarely used features. </li></ul></ul><ul><li>Idea> Analysis > Development > Testing > Deployment> Return on Investment </li></ul><ul><ul><li>Most of the costs are in the Analysis, Development, and Testing. </li></ul></ul><ul><li>Reduced time to market. </li></ul><ul><ul><li>Agile teams will do the most important things first, and deploy them in production as soon as possible. </li></ul></ul>
    19. 19. I Own or Run This Business- What’s in it for Me? <ul><li>Reduced risk. You get to assess it and decide on it every few weeks. </li></ul><ul><ul><li>If you want to stop, you can. </li></ul></ul><ul><li>Changes after deployment: Agile teams can respond more quickly, assuming they have unit tests and quality code. </li></ul>
    20. 20. I Own or Run This Business- What’s in it for Me? <ul><li>Everything is just fine….. </li></ul>
    21. 21. I Own or Run This Business- What’s in it for Me? <ul><li>Reality always wins in the end, so get there sooner. </li></ul>
    22. 22. I Own or Run This Business- What’s in it for Me? <ul><li>What if the project is doomed to fail? </li></ul><ul><ul><li>If you are going to fail, do it fast. </li></ul></ul>
    23. 23. I’m a Project Manager- What’s in it for Me? <ul><li>Project Manager’s job is to create a schedule, monitor progress, control the risks, and keep people informed. </li></ul><ul><ul><li>This is very difficult to do. Especially when people are afraid to tell the truth. </li></ul></ul><ul><li>How does a project get to be a year behind schedule? </li></ul><ul><ul><li>Answer: One day at a time. </li></ul></ul>
    24. 24. I’m a Project Manager- What’s in it for Me? <ul><li>You can have people get started earlier. </li></ul><ul><ul><li>Typically, you don't give the green light for developers to actually get started developing anything until we know all the requirements. With Agile, you don't assume that you ever know all the requirements until you are done. You do need to know enough to get started, but you don't need the entire picture in detail. </li></ul></ul><ul><ul><li>When you don’t know enough about a project, you may want to go ahead and get started. Have very short sprints and get feedback early and often. </li></ul></ul>
    25. 25. I’m a Project Manager- What’s in it for Me? <ul><li>Instead of managing risk with lots of documents and contracts that create an &quot;us vs. them&quot; environment, you manage risk with real, working software, and contracts that encourage collaboration between different parties. </li></ul>
    26. 26. Typical Scrum Team Board Transparency is more evident.
    27. 27. Multi-Team Project Board Big, Visible Charts
    28. 28. I’m a Project Manager- What’s in it for Me? <ul><li>The culture of transparency makes it easier for you to provide visibility and a more realistic status up the chain. </li></ul><ul><li>Unknowns should be known much earlier in the process. </li></ul>
    29. 29. I’m a Project Manager- What’s in it for Me? <ul><li>Managing Risk: </li></ul><ul><ul><li>There are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things that we know we don't know. But there are also unknown unknowns. There are things we don't know we don't know. </li></ul></ul><ul><ul><li>- Donald Rumsfeld </li></ul></ul><ul><li>When problems pop up early, we have lots of options. When problems pop up at the end of a project, our options are very limited; work more, cut quality, etc. </li></ul>
    30. 30. I’m a Tester- What’s in it for Me? <ul><li>How is QA viewed today on most traditional projects? </li></ul><ul><ul><li>Often viewed as a roadblock, or second class citizen. </li></ul></ul><ul><ul><li>If bugs get into production, who gets the blame? </li></ul></ul><ul><ul><li>Are you ever told &quot; Don't talk to the developers while they are working. They are too busy, and I don't want you to waste their time.&quot; ? </li></ul></ul>
    31. 31. I’m a Tester- What’s in it for Me? <ul><li>Agile teams elevate the role of testing. </li></ul><ul><li>Quality becomes essential when teams are repeatedly deploying software. </li></ul><ul><li>You will be working on a close-knit team. </li></ul>
    32. 32. I’m a Tester- What’s in it for Me? <ul><li>Inspection to find defects is waste. Inspection to prevent defects is essential. </li></ul><ul><li>A quality process builds quality into the product. If you routinely find defects during verification, your process is defective. </li></ul><ul><li>If you have test and fix cycles, you are testing too late. This is churn, and wasteful. </li></ul><ul><li>Move QA people from end of process to beginning and middle of process. Find defects as soon as they are created. </li></ul>
    33. 33. I’m a Developer- What’s in it for Me? <ul><li>ROI </li></ul><ul><ul><li>Developers often don't think about ROI. They view this as a business term, and often don't care. Well, here's a revelation: Your salary is calculated as ROI. You, your benefits, your computer, are all calculated as ROI. You are being paid to do something. The people paying you want a return on their investment. The better investment you provide, the better you will be viewed. </li></ul></ul><ul><li>A better way of working. Support vs. control. </li></ul><ul><ul><li>Imagine a work situation where your manager says “ What can I do to help you ?”, instead of saying “ do this, now do that, and do it this way .” </li></ul></ul><ul><li>Trust vs. micromanagement </li></ul><ul><ul><li>The team decides the best way to reach the goals put forth in front of them. </li></ul></ul>
    34. 34. I’m a Developer- What’s in it for Me? <ul><li>You will be working on a close-knit team. </li></ul><ul><li>Can get more done together than you can separately. </li></ul><ul><li>Collaboration, support system. </li></ul>
    35. 35. I’m a Developer- What’s in it for Me? <ul><li>Increased communication. </li></ul><ul><li>Everyone on the team is working toward the same goals. </li></ul><ul><li>Laughing. </li></ul><ul><li>Sense of community. </li></ul><ul><li>Sense of ownership. </li></ul>
    36. 36. I’m a Developer- What’s in it for Me? <ul><li>You should gain skills you didn’t have before. </li></ul><ul><li>Less useless documentation. </li></ul><ul><li>Those obstacles that you tolerate now? They should become more obvious, and some of them will go away if your management is doing their job. </li></ul>
    37. 37. I’m a Developer- What’s in it for Me? <ul><li>Freedom to pick tasks. No one assigns tasks, and you have ownership over your tasks. </li></ul><ul><li>Great feeling of accomplishment. </li></ul><ul><li>Food is often involved. </li></ul><ul><li>Almost always results in higher morale. </li></ul>
    38. 38. From: “The Principles Behind the Agile Manifesto” <ul><li>Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. </li></ul>
    39. 39. Principles behind the Agile Manifesto <ul><li>Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. </li></ul><ul><li>Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. </li></ul><ul><li>Working software is the primary measure of progress. </li></ul>
    40. 40. Principles behind the Agile Manifesto <ul><li>Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. </li></ul><ul><li>Business people and developers must work together daily throughout the project. </li></ul>
    41. 41. Principles behind the Agile Manifesto <ul><li>Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. </li></ul><ul><li>The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. </li></ul>
    42. 42. Principles behind the Agile Manifesto <ul><li>Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. </li></ul>
    43. 43. Principles behind the Agile Manifesto <ul><li>Continuous attention to technical excellence and good design enhances agility. </li></ul><ul><li>Simplicity--the art of maximizing the amount of work not done--is essential. </li></ul>
    44. 44. Principles behind the Agile Manifesto <ul><li>The best architectures, requirements, and designs emerge from self-organizing teams. </li></ul><ul><li>At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. </li></ul>
    45. 45. How Do I Start? <ul><li>Ideally, get support from the top, and jump in with both feet. </li></ul><ul><ul><li>Hire a good consultant. </li></ul></ul><ul><ul><li>Get your people trained. Make sure they understand the principles as well as the practices. </li></ul></ul><ul><li>Do it “by the book” for a year, and then change parts of it only if it really makes sense. </li></ul>
    46. 46. How Do I Start? <ul><li>Start with Scrum. </li></ul><ul><ul><li>Fairly easy to implement. </li></ul></ul><ul><ul><li>Quick wins </li></ul></ul><ul><ul><li>Improved Morale </li></ul></ul><ul><li>Add XP development practices </li></ul><ul><ul><li>Continuous integration </li></ul></ul><ul><ul><li>Unit testing </li></ul></ul><ul><li>Transition to Lean (After a year of successful Scrum) </li></ul><ul><ul><li>One piece flow </li></ul></ul><ul><ul><li>Optimizing the whole </li></ul></ul>
    47. 47. How Do I Start If I can’t get support from on top? <ul><li>Stealth agile. </li></ul><ul><ul><li>Don’t mention the words “agile”, “scrum”, or anything else that would make people nervous. The last thing you want is for people to freak out. </li></ul></ul><ul><ul><li>Talk to end users and stakeholders yourself. Establish a relationship with your customers. </li></ul></ul><ul><ul><li>Ask people what they intend to do with all that documentation. </li></ul></ul>
    48. 48. How Do I Start If I can’t get support from on top? <ul><li>Stealth Agile Continued…. </li></ul><ul><ul><li>Get your team to have short daily meetings. </li></ul></ul><ul><ul><li>Talk your team into working together for one hour or more every day in a conference room. </li></ul></ul><ul><ul><li>Invite people to a demo every few weeks. </li></ul></ul><ul><ul><li>Prove the results and earn respect. </li></ul></ul><ul><ul><li>Be patient. Change takes time. Don’t get frustrated. </li></ul></ul>
    49. 49. Either Way…. <ul><li>Work towards a culture of continuous improvement. </li></ul><ul><ul><li>Work to improve your skills, your company, your delivery of software. </li></ul></ul><ul><li>Reduce complexity whenever possible. </li></ul><ul><ul><li>No one ever goes to bed thinking “ Gosh, I hope my work gets a lot more complicated tomorrow .” </li></ul></ul><ul><li>Try to make it fun. Be a part of the solution. </li></ul><ul><li>“ Don’t let your doubts tell you what you can’t do. This works against change. If you really can’t do that, you can probably do something similar. Figure it out and do it.”- Bob Schatz </li></ul><ul><li>Or, as Brian Prince said not long ago… </li></ul><ul><li>“ You can change your company or you can change your company.” </li></ul>
    50. 50. Random Thoughts for Managers: <ul><li>Create a culture of trust and transparency. </li></ul><ul><li>Good leadership will establish and communicate common goals. </li></ul><ul><li>At the beginning of any project, and when new team members come on board, the vision should be set. They should know why they are doing the work they are doing. </li></ul><ul><li>Be a coach, not a policeman. </li></ul>
    51. 51. More Random Thoughts for Managers <ul><li>The time to negotiate is before you say “yes” to a project. </li></ul><ul><ul><li>What? Scope, cost, and time are not negotiable? They will be later when the project is failing. </li></ul></ul><ul><li>Ask your teams what you can do to help them deliver software better, faster, more efficiently, then do it. </li></ul><ul><li>Be relentless about eliminating waste in the process. </li></ul><ul><ul><li>Tools, technologies, people that stand in the way, arcane rules, bureaucracy, etc. </li></ul></ul><ul><li>Do more of what works and less of what doesn’t, but get these from your people. </li></ul>
    52. 52. Acknowledgments <ul><li>Many of the ideas presented here are from: </li></ul><ul><ul><li>Bob Schatz of Agile Infusion </li></ul></ul><ul><ul><li>Jean Tabaka of Rally Software </li></ul></ul>
    53. 53. Questions? <ul><li>[email_address] </li></ul><ul><li>865-924-6319 </li></ul><ul><li> </li></ul><ul><li> </li></ul>