Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Agile in the Workplace

Agile in the Workplace is a brief overview of Agile Methodology in software development as well as some of the pros and cons of agile development and transitioning from waterfall development.

Ähnliche Bücher

Kostenlos mit einer 30-tägigen Testversion von Scribd

Alle anzeigen

Ähnliche Hörbücher

Kostenlos mit einer 30-tägigen Testversion von Scribd

Alle anzeigen
  • Als Erste(r) kommentieren

Agile in the Workplace

  1. 1. AGILE michael stowe in the workplace September 17, 2013
  2. 2. MIKESTOWE •  Open Source Contributor •  Author, Speaker, and Consultant •  10+ years experience hacking PHP •  Zend Certified PHP 5.3 Software Engineer •  Developer Advocate with Constant Contact .com @mikegstowe
  3. 3. IN THE BEGINNING Imagine going to the store and buying a canoe, a compass, a map, and a pack for food and water. You trek out to the river and jump in, ready to begin your journey. The only catch is once you start there’s no where to stop… so I hope you bought the right map, or that your compass works. And you better have enough food and water… oh yeah, and experience for the waterfall ahead!
  4. 4. IN THE BEGINNING This is pretty much how products were being developed. People would get together and put together requirements and then base all of their decisions off of the requirements. The project then moved forward one branch at a time. And like a waterfall, once you got so far into the project, it’s a little late to turn around and go back.
  5. 5. TYPICAL WATERFALL Image courtesy of http://www.varsys.com/knowledgecenter_WaterfallDownfall.html
  6. 6. No plan survives contact with the enemy… Helmuth von Moltke
  7. 7. To improve is to change; to be perfect is to change often. Winston Churchill
  8. 8. Want to be a web developer? Easy! First, imagine you’re a carpenter. Second, imagine that the house you’re building is made of live monkeys. David Lee, @tangentialism
  9. 9. WHAT IS AGILE Agile simply means flexible. Rather than being strict and unmovable in our processes like the Waterfall Method, Agile encourages a “take it as it comes” approach. Agile encourages the use of people over process, working software over comprehensive documentation, customer/ business collaboration over contract negotiation, and responding to change instead of following a set plan.
  10. 10. AGILE MANIFESTO We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and Interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.
  11. 11. From Wikipedia, the free encyclopedia
  12. 12. AGILE PROCESS Agile does this by first outlining the vision or general requirements of the project. This vision is then divided into smaller chunks known as “stories.” Think of the vision as a deck of cards, and each story being a card in that deck. Instead of focusing on the whole deck, we can now prioritize which cards are the most important, and start tackling them piece by piece.
  13. 13. AGILE PROCESS We prioritize our cards by putting them in iterations, or short 2-4 week development cycles. For example, we may decide that the Joker, the King, and the Queen are the most important cards, so we want them in the first iteration. We can then put other cards in future iterations, but we will focus on these three cards first, and get them ready to go before moving on (unless priorities change).
  14. 14. ITERATION AND BACKLOG Image courtesy of http://www.executivebrief.com/agile/how-to-scrum/ Joker, King, and Queen Cards All Other Cards, on the backlog for future iterations Tasks to create these three cards
  15. 15. TASK BOARD With Agile, one of the easiest ways to manage tasks is by using a task board… or in this case, a piece of paper with Post-it® notes of different colors signifying different types of tasks. The key components include Stories, To Do, In Progress, Testing, and Accepted From Wikipedia, the free encyclopedia Kanban Board
  16. 16. AGILE PROCESS Once we develop these cards, we can test them, have them reviewed by the customer or business team, and make sure that everything looks good before moving on. The following figures are good examples of how Agile Methodology works:
  17. 17. AGILE METHODOLOGY Image courtesy of http://www.mountaingoatsoftware.com/scrum/overview simplified
  18. 18. AGILE METHODOLOGY Image courtesy of http://www.varsys.com/knowledgecenter_WaterfallDownfall.html
  19. 19. THE ADVANTAGE With the Waterfall Method we would have designed the entire deck and sent it off for printing. But it turns out we can’t do rounded corners on our cards, or the colors don’t look right, or for whatever the reason the cards just don’t work. With Waterfall we just wasted work on 52 cards, where- as with Agile we would have caught this issue and been able to fix it after only working on 3 cards!
  20. 20. THE DISADVANTAGE Agile requires team members to work closely together and requires the team to innovate and problem solve. It provides greater flexibility allowing the project and requirements to evolve. It places more value on the software than it does documentation, and is driven by the customer or business unit and their satisfaction.
  21. 21. THE ADVANTAGE Agile requires team members to work closely together and requires the team to innovate and problem solve. It provides greater flexibility allowing the project and requirements to evolve. It places more value on the software than it does documentation, and is driven by the customer or business unit and their satisfaction.
  22. 22. RISK MANAGEMENT To help make Agile successful in the business it is recommended to have small, dedicated teams that can work together. The general rule is to build a team with the Product Owner, a Scrum Master, and 5-9 (or 7 +/- 2) team members. This allows the team to collaborate quickly without becoming siloed - a major risk with larger teams.
  23. 23. Image courtesy of http://www.executivebrief.com/agile/how-to-scrum/
  24. 24. RISK MANAGEMENT Because Agile requires the development team to work closely together, and with different personalities, it is recommended to have an outside “Agile Coach” who is not directly part of the team but is available to serve as a mentor. This allows the mentor to help resolve issues without members feeling that the Product Owner or Scrum Master is taking sides and/ or playing favorites.
  25. 25. RISK MANAGEMENT It is vital for your development team to grow together and work as a team in order to overcome any issues that may arise within the development cycles/ iterations. Early on one of the biggest challenges is a lack of communication or understanding of Agile, and power struggles between users. However, once the team learns to work together, they will be able to utilize all of their strengths to build an even better product.
  26. 26. AN AGILE ENVIRONMENT Unlike Waterfall Methodology which is driven by meeting after meeting, Agile relies on team members working together as needed. Because of this, it is important to provide an environment that allows team members to collaborate, such as providing team members with laptops instead of desktop computers for mobility and having a dedicated space and time for the team to work.
  27. 27. STOP WASTING TIME By providing the team with the time and resources necessary to collaborate, you can avoid lengthy meetings. In general, the team usually gets together for a quick “stand up” meeting that should last no more than 15-30 minutes in which team members discuss their progress, challenges, and goals for the day.
  28. 28. THE DAILY STANDUP - What did I accomplish yesterday? - Team members are quickly briefed on the progress being made on the project. - What will I do today? - Team members are briefed on what the development goals for the day - What obstacles/ challenges are holding me up? - Team members are alerted early on to potential issues and appropriate resources can be utilized.
  29. 29. STOP WASTING TIME By knowing the needs and goals of each of their teammates, agile team members are able to help out and assist as needed, again pulling together to use their strengths. Part of the challenge of a manager is to “let them go at it” and take charge. Because Agile is intended to be flexible, tasks can be dealt with as they come, and you can avoid scheduling long and lengthy planning meetings.
  30. 30. DO MORE PLANNING One misconception with Agile is that you do not have to do any planning… in fact it is just the opposite. Agile requires a general vision which is broken into stories. Basic requirements are then given to stories, and they are put into iterations for development. But the planning doesn’t stop there, once we get to the iteration the stories are more carefully reviewed and requirements are again discussed.
  31. 31. DO MORE PLANNING And as stories are developed, new challenges may be discovered, which may require more collaboration and planning among the team members in order to find a solution or adjusting requirements. Certain tasks may even be moved into future iterations, allowing continuous development that will have improved functionality in the future.
  32. 32. POWER TO THE PEOPLE This is one of the most powerful aspects of Agile, the emphasis of the team over processes, and working software over extensive documentation. After all, what good do processes do you if they don’t help solve the problems you are trying to address? And what good is telling people what the software will do, if the software is stagnant with problems because the requirements were so rigid?
  33. 33. POWER TO THE DEVELOPERS Because Agile reduces wasteful meetings, increases collaboration among team members, reduces documentation, and allows for immediate testing and feedback- it allows software engineers to do what they do best, Code. In fact, it let’s your entire team do what they do best… their job.
  34. 34. POWER TO THE DEVELOPERS However, it is important to make sure that your team members are being left alone and not harassed by business owners or stake holders. Remember the scrum team, the Product Owner and Scrum Master are responsible for running interference to make sure work is not being added directly to the development teams plate, and that there are no outside distractions that impede their work.
  35. 35. SCOPE CREEP One of the most dangerous forms of distractions from the task at hand is Scope Creep, or work that “creeps” it’s way into the scope of the project. All bugs, tickets, features should be assessed by the Product Owner and assigned to the proper iteration or cycle. Developers like-wise need to be careful not to start injecting new tasks or features into their work that are not directly related to the current iteration.
  36. 36. TAKE TIME TO REVIEW After each iteration it’s a good idea to take time to review what went well, and what didn’t in that iteration. This allows the team to identify how their strengths came together, and focus on how to overcome the challenges this iteration presented in future iterations. This meeting doesn’t have to be super long. A general rule is no more than 45 minutes for every week the iteration lasted (so 2 weeks = 1.5 hour meeting)
  37. 37. TAKE TIME TO REVIEW Questions to ask during the Retrospective meeting include: -  What went well during the iteration? -  What would we like to change? -  How can we implement that change? You can also discuss the results, people involved (resources), relationships, processes, tools, and overall productivity.
  38. 38. TAKE TIME TO REVIEW The Retrospective meeting is not intended to be a blame session, but rather a chance for the team to come together and problem solve as a unit. Avoid letting the meeting become personal or directed at one person. Likewise, watch out for excuse statements such as “Because…” or “Nothing we could do…” as it signifies a move from problem solving to rationalizing why things didn’t go according to plan.
  40. 40. LET’S MAKE A SEARCH ENGINE Your company has come up with a great idea for a search engine! So the Product Owner meets with the Stake Holders and Business Owners and comes up with a vision for your search engine. Together they decide the search engine should be able to: spider sites, store data to a NoSQL database, work with a third party API, allow members to bookmark favorites and/or purchase PPC advertising.
  41. 41. LET’S MAKE A SEARCH ENGINE Based on this broad requirements, stories are created for each of the tasks: -  Spidering Sites -  Store to Database -  Third Party API Integration -  Member System with Login -  Favorite Bookmarking -  PPC System – Manage Ads -  Show PPC Ads in Results
  42. 42. LET’S MAKE A SEARCH ENGINE For the first iteration, which will be 2 weeks, the team decides on doing the Spidering Sites and Store to Database stories. The team then starts planning the requirements for these features, and decides upon using MSSQL to save the data. Your developers start getting to work…
  43. 43. LET’S MAKE A SEARCH ENGINE But unfortunately your LAMP stack doesn’t support MSSQL. Your developers quickly alert the team that this requirement will not work. The team gets back together and agrees to change the requirement to be MySQL. BLAM! Problem averted.
  44. 44. LET’S MAKE A SEARCH ENGINE One week into the project your developers realize that two weeks may have been a really generous estimate, and that it is probably going to take longer. Once again the team takes a look at the iteration and requirements, and decides either to move some requirements into a future iteration as followers, or to simply push the entire “release” to the next iteration.
  45. 45. LET’S MAKE A SEARCH ENGINE However, because of your daily “stand-ups,” both the Scrum Master and Product Owner were made aware of this, and were able to relay it to the Business Owners and Stake Holders, preventing a reign of fire from coming down on the entire team. BLAM! Unhappy people… Averted.
  46. 46. LET’S MAKE A SEARCH ENGINE Great news, we just finished the first iteration. Bad news is that the Business Owners decided they want the PPC to be the next most important thing, and they have some new requirements for it. Thankfully, being agile we can simply move things around, put PPC into the next iteration, and oh yeah, we haven’t started evaluating the unique requirements for this system. BLAM! Problem averted.
  47. 47. LET’S MAKE A SEARCH ENGINE However, the Business Owners really don’t like the interface of the PPC system. So, you create new stories to make the UI look awesome and put them in the next iteration. BLAM! Yeah, you get the idea…
  48. 48. LET’S MAKE A SEARCH ENGINE Oh man! QA found a bug in the code… and it’s a doozy! Anything that depends on this code would be totally doomed to fail… But because we tested the iteration right after development, nothing is dependent on it yet. We haven’t coded all the other stuff yet, so there’s no lost work!!! BLAM! Oh yeah…
  49. 49. LET’S MAKE A WEB APP Ok, so that may seem a little too convenient. But that’s a fake scenario based on a real life one. Working with Agile saved our team HOURS and the business $$$. We were able to problem solve as we went, be flexible with requirements, and in the end turn out a product that completely blew away customer expectations. Needless to say, they were like… “Oh yeah…”
  50. 50. THERE’S A LOT MORE However, I hope you now have a basic understanding of what Agile is, and how it benefits EVERYONE from the customer to the business owner(s). Remember the key principles of Agile: Individuals and Interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
  51. 51. THANK YOU. @mikegstowe visit mikestowe.com/slides for more on PHP and Web Development @ctct_api A big thank you to Constant Contact for making this presentation possible

    Als Erste(r) kommentieren

    Loggen Sie sich ein, um Kommentare anzuzeigen.

  • jeanpasqualini

    Nov. 7, 2014
  • deniskrupnov35

    Jan. 31, 2015
  • bokor77

    Oct. 24, 2015

Agile in the Workplace is a brief overview of Agile Methodology in software development as well as some of the pros and cons of agile development and transitioning from waterfall development.


Aufrufe insgesamt


Auf Slideshare


Aus Einbettungen


Anzahl der Einbettungen