Stop doing scrum; start doing agile
•Download as PPTX, PDF•
2 likes•1,884 views
My JavaOne 2015 talk about the basics of Agile.
Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (14)
Similar to Stop doing scrum; start doing agile
Similar to Stop doing scrum; start doing agile (20)
More from Peter Van de Voorde
More from Peter Van de Voorde (14)
Recently uploaded
Recently uploaded (20)
Stop doing scrum; start doing agile
- 1. PETER VAN DE VOORDE • COMMUNITY DEVELOPER • ATLASSIAN • @PVDEVOOR Stop Doing Scrum; Start Being Agile
- 2. • Big cool statistic • Add-Ons in Marketplace Stop doing Scrum? Never! BluejackBerrie (Flickr)
- 3. • Big cool statistic • Add-Ons in Marketplace IamNotUnique (Flickr)
- 4. • Big cool statistic • Add-Ons in Marketplace fortinbras (Flickr)
- 5. • Big cool statistic • Add-Ons in Marketplace ed_needs_a_bicycle (Flickr) So what is wrong with doing Scrum?
- 6. • Big cool statistic • Add-Ons in Marketplace jcbwalsh (Flickr)
- 8. • Big cool statistic • Add-Ons in Marketplace komehachi888 (Flickr)
- 9. • Big cool statistic • Add-Ons in Marketplace localjapantimes (Flickr)
- 10. • Big cool statistic • Add-Ons in Marketplace kit4na (Flickr)
- 11. • Big cool statistic • Add-Ons in Marketplace www.tOrange.us
- 12. • Big cool statistic • Add-Ons in Marketplace "Leontiy korennoj" by Babaev P.I. - Russian Museum.
- 13. • Big cool statistic • Add-Ons in Marketplace ed_needs_a_bicycle (Flickr) So what can we do about this?
- 14. • Big cool statistic • Add-Ons in Marketplace Frank Kovalchek (@Flickr)
- 15. • Big cool statistic • Add-Ons in Marketplace Joseph-Siffrein Duplessis [Public domain], via Wikimedia Commons He that idly loses 5s. worth of time, loses 5s., and might as prudently throw 5s. into the river.. BENJAMIN FRANKLIN “ ”
- 16. • Big cool statistic • Add-Ons in Marketplace www.worldsciencefestival.com
- 17. • Big cool statistic • Add-Ons in Marketplace Tom777, via Wikimedia Commons
- 18. • Big cool statistic • Add-Ons in Marketplace clearlyambiguous (Flickr)
- 19. • Big cool statistic • Add-Ons in Marketplace visualpun.ch (Flickr)
- 20. 4 values
- 21. Daniel Y. Go (Flickr) Individuals and interactions Processes and tools Over
- 23. Cushing Memorial Library and Archives, Texas A&M Customer collaboration Over Contract negotiation
- 24. Brian Rinker (Flickr) Responding to change Over Following a plan
- 25. That is, while there is value in the items on the right, we value the items on the left more. WWW.AGILEMANIFESTO.ORG “ ”
- 26. 12 principles
- 27. • Big cool statistic • Add-Ons in Marketplace Phil Dowsing Creative (Flickr) Satisfy the customer through continuous delivery of valuable software.
- 28. • Big cool statistic • Add-Ons in Marketplace ** RCB ** (Flickr) Welcome changing requirements.
- 29. • Big cool statistic • Add-Ons in Marketplace szeke (Flickr) Deliver working software frequently.
- 30. • Big cool statistic • Add-Ons in Marketplace bwright923 (Flickr) Business and IT need to work together daily.
- 31. • Big cool statistic • Add-Ons in Marketplace Warner Bros Build around motivated individuals.
- 32. • Big cool statistic • Add-Ons in Marketplace dan2010 (Flickr) Face-to-face communication.
- 33. • Big cool statistic • Add-Ons in Marketplace Atomic Mutant Flea Circus (Flickr) Working software is the primary measure of progress.
- 34. • Big cool statistic • Add-Ons in Marketplace Dejan Hudoletnjak (Flickr) Promote Sustainable Development.
- 35. • Big cool statistic • Add-Ons in Marketplace Damien (phototrend.fr) Continuous attention to technical excellence and good design.
- 36. • Big cool statistic • Add-Ons in Marketplace Jeff Kubina (Flickr) Simplicity is essential. It’s the art of maximizing the amount of work not done. THE AGILE MANIFESTO “ ”
- 37. • Big cool statistic • Add-Ons in Marketplace Create a self-organized team.
- 38. • Big cool statistic • Add-Ons in Marketplace ores2k (Flickr) Look back, reflect, adjust.
- 39. • Big cool statistic • Add-Ons in Marketplace ed_needs_a_bicycle (Flickr) How can we do this?
- 40. • Big cool statistic • Add-Ons in Marketplace "Obi-gokyū" by chris 論 via WikiMedia Commons
- 41. • Big cool statistic • Add-Ons in Marketplace dyepoi (Flickr)
- 42. • Big cool statistic • Add-Ons in Marketplace Wonderlane (Flickr)
- 43. • Big cool statistic • Add-Ons in Marketplace Universal Pictures
- 44. • Big cool statistic • Add-Ons in Marketplace Warner Bros
- 45. • Big cool statistic • Add-Ons in Marketplace ed_needs_a_bicycle (Flickr) Where do we start?
- 46. • Big cool statistic • Add-Ons in Marketplace Thomas Hawk (Flickr)
- 47. • Big cool statistic • Add-Ons in Marketplace Mountain Goat Software
- 48. • Big cool statistic • Add-Ons in Marketplace Jeff.lasovski (Wikimedia Commons)
- 49. • Big cool statistic • Add-Ons in Marketplace Ricardo Fernández (Flickr)
- 50. • Big cool statistic • Add-Ons in Marketplace x-ray delta one (Flickr)
- 51. • Big cool statistic • Add-Ons in Marketplace Mountain Goat Software
- 52. • Big cool statistic • Add-Ons in Marketplace ed_needs_a_bicycle (Flickr) What will happen?
- 53. • Big cool statistic • Add-Ons in Marketplace robynejay (Flickr)
- 54. • Big cool statistic • Add-Ons in Marketplace Christian R. Hamacher (Flickr)
- 55. • Big cool statistic • Add-Ons in Marketplace synx508 (Flickr)
- 56. • Big cool statistic • Add-Ons in Marketplace Mixtribe Photo (Flickr)
- 57. • Big cool statistic • Add-Ons in Marketplace efatima (Flickr)
- 58. • Big cool statistic • Add-Ons in Marketplace marycesyl (Flickr)
- 59. • Big cool statistic • Add-Ons in Marketplace ed_needs_a_bicycle (Flickr) So what’s next?
- 60. • Big cool statistic • Add-Ons in Marketplace kightp (Flickr)
- 61. • Big cool statistic • Add-Ons in Marketplace Swamibu (Flickr)
- 62. Real LifeMotivation Some interesting books… Change Management
- 63. • Big cool statistic • Add-Ons in Marketplace atlassian.com/agile
- 64. • Big cool statistic • Add-Ons in Marketplace clement127 (Flickr)
- 65. • Big cool statistic • Add-Ons in Marketplace Bart van de Biezen (Flickr)
- 66. • Big cool statistic • Add-Ons in Marketplace Thomas Hawk (Flickr)
- 67. Thank you! PETER VAN DE VOORDE • COMMUNITY DEVELOPER • ATLASSIAN • @P VDEVOOR
Editor's Notes
- Who am I? small introduction.
- First reaction to this talk, why should we stop doing scrum? We will never stop doing scrum you crazy man!
- but after thinking about the current state of your Scrum and how well everything is going you remember the long discussion about changes, priorities, badly defined stories, end sprint testing, long already fully defined product backlogs and so on…
- maybe I should just listen to what he has to say and make up my own mind afterwards.
- So what is there wrong with Scrum? Everybody is doing it!
- Inherently there is nothing wrong with Scrum, it can do wonderful things for your productivity, your team and your customers, but in many cases it just turns into something else…
- Scrumfall is one of the many pitfalls teams new to scrum make and it’s one I’ve made in the past. It’s when you simply start to rename all your waterfall stages into sprints or scrum related jargon.
- It turns into one big mess, because as with many things: In theory everything its easy, but in reality that’s a whole different story. It’s in the implementation that things start to go wrong…. For example:
- Another problem could be that you and your team are the only ones in your entire company who know about Agile and try to do scrum, this will lead to a lot of frustration, anger, miscommunication, wrong expectations and so on…
- There is no definition of Done resulting in unfinished work, no shared responsibility and major communication breakdown and mountains of frustrations
- Quality is treated as a second hands objective instead of the primary objective. Quality is the first thing people cut back on when they are running out of time or money. “We’ll fix this in the next release is something I overheard quite often on previous projects.” But we all know it will not be fixed in the next release, because again there will be no focus on delivering quality, just quantity at as low a price as possible. In the end this doesn’t result in an excellent product our customers love, it results in a product that our customers don’t hate enough to never use it again.
- Nobody is fighting for the users, people are implementing what they think the user wants/needs not what the users actually asks them. and there is no interaction during the development with the user.
- So what can we do about this? To be able to understand Agile and Scrum we need to get back to the roots of Agile Software Development
- To be able to understand Agile and Scrum we need to get back to the roots of Agile Software Development. Agile Software development is based on Lean Manufacturing and this all started a long time ago…
- Most of the basic goals of lean manufacturing are common sense[original research?], and documented examples can be seen as early as Benjamin Franklin. Poor Richard's Almanack says of wasted time, "He that idly loses 5s. worth of time, loses 5s., and might as prudently throw 5s. into the river." He added that avoiding unnecessary costs could be more profitable than increasing sales. Again Franklin's The Way to Wealth says the following about carrying unnecessary inventory. "You call them goods; but, if you do not take care, they will prove evils to some of you. You expect they will be sold cheap, and, perhaps, they may [be bought] for less than they cost; but, if you have no occasion for them, they must be dear to you. Remember what Poor Richard says, 'Buy what thou hast no need of, and ere long thou shalt sell thy necessaries.' In another place he says, 'Many have been ruined by buying good penny worths'." Henry Ford cited Franklin as a major influence on his own business practices, which included Just-in-time manufacturing. The concept of waste being built into jobs and then taken for granted was noticed by motion efficiency expert Frank Gilbreth, who saw that masons bent over to pick up bricks from the ground. The bricklayer was therefore lowering and raising his entire upper body to pick up a 2.3 kg (5 lb.) brick, and this inefficiency had been built into the job through long practice. Introduction of a non-stooping scaffold, which delivered the bricks at waist level, allowed masons to work about three times as quickly, and with less effort. (source: https://en.wikipedia.org/wiki/Lean_manufacturing)
- Henry Ford and his Ford production line: While Ford is renowned for his production line it is often not recognized how much effort he put into removing the fitters' work to make the production line possible. Until Ford, a car's components always had to be fitted or reshaped by a skilled engineer at the point of use, so that they would connect properly. By enforcing very strict specification and quality criteria on component manufacture, he eliminated this work almost entirely, reducing manufacturing effort by between 60-90%.[17] However, Ford's mass production system failed to incorporate the notion of "pull production" and thus often suffered from over-production. Ford also coined the term Just-In-Time Manufacturing
- Toyota's development of ideas that later became lean may have started at the turn of the 20th century with Sakichi Toyoda, in a textile factory with looms that stopped themselves when a thread broke. This became the seed of autonomation and Jidoka. Toyota's journey with just-in-time (JIT) may have started back in 1934 when it moved from textiles to produce its first car. Kiichiro Toyoda, founder of Toyota Motor Corporation, directed the engine casting work and discovered many problems in their manufacture. He decided he must stop the repairing of poor quality by intense study of each stage of the process. In 1936, when Toyota won its first truck contract with the Japanese government, his processes hit new problems and he developed the "Kaizen" improvement teams. Levels of demand in the Post War economy of Japan were low and the focus of mass production on lowest cost per item via economies of scale therefore had little application. Having visited and seen supermarkets in the USA, Taiichi Ohno recognised the scheduling of work should not be driven by sales or production targets but by actual sales. Given the financial situation during this period, over-production had to be avoided and thus the notion of Pull (build to order rather than target driven Push) came to underpin production scheduling. It was with Taiichi Ohno at Toyota that these themes came together. He built on the already existing internal schools of thought and spread their breadth and use into what has now become the Toyota Production System (TPS). It is principally from the TPS, but now including many other sources, that lean production is developing. Norman Bodek wrote the following in his foreword to a reprint of Ford's Today and Tomorrow: I was first introduced to the concepts of just-in-time (JIT) and the Toyota production system in 1980. Subsequently I had the opportunity to witness its actual application at Toyota on one of our numerous Japanese study missions. There I met Mr. Taiichi Ohno, the system's creator. When bombarded with questions from our group on what inspired his thinking, he just laughed and said he learned it all from Henry Ford's book." The scale, rigor and continuous learning aspects of TPS have made it a core concept of lean.
- Lean was based on TPS and more broadly used….
- Our highest priority is to satisfy the customer through early and continuous delivery of 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.
- 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.
- So how can we start doing this and become better at Agile? Let’s take a look at how we can achieve mastery…
- We could say that there are 4 main levels of Agile Enlightenment : novice, apprentice, practitioner and master
- The Novice: has heard about Agile and is interested has an open mind for Agile wants to know where to start learning about Agile does not know any limitations or rules
- The apprentice: - reads books about Agile follows the books to the letter has a basic understanding of the principles behind Agile will apply the same solution to any problem
- practitioner: knows what he’s doing tries his own thing know’s he still needs to learn applies a different basic solution for each problem
- As an agile master you’ll: will know which rules to bend, which to break and which to add to get the best results will know you still need to keep on learning and improving will teach the people around you about Agile and how to strive for mastery You can now decide which pill you take, the red one or the blue one?
- So where do we start?
- Let’s take a look at some of the methodologies that exist today..
- The most popular and well known of all Agile Software Methodologies is Scrum,…
- Kanban is a less known but in some areas extremely popular alternative for Scrum
- Extreme Programming: https://en.wikipedia.org/wiki/Extreme_programming As a type of agile software development,[1][2][3] it advocates frequent "releases" in short development cycles, which is intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted. Other elements of extreme programming include: programming in pairs or doing extensive code review, unit testing of all code, avoiding programming of features until they are actually needed, a flat management structure, simplicity and clarity in code, expecting changes in the customer's requirements as time passes and the problem is better understood, and frequent communication with the customer and among programmers.
- Test Driven Development https://en.wikipedia.org/wiki/Test-driven_development Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards.
- Scrumban: https://en.wikipedia.org/wiki/Scrumban
- What will happen?
- You will probably fail a few times, but don’t worry failure doesn’t really exists, it’s a lesson you haven’t learned yet and which might teach you something you didn’t know before that can help you in the future.
- You will run into walls you didn’t know existed, or had been warned about but you didn’t listen. On one of my projects I trained the team in the usage of Scrum, they loved it and started using it for all of their projects. They did ask to do one thing with the complete team (15 people): the daily standup. I told them about the ideal size of a team, about the workings of a standup and about the do’s and dont’s. They didn’t listen and started using it as a full team group meeting which could take more than 30 minutes. I actually left for a month of parental leave and told them: when I get back you’ll have hit a wall with those standups and will no longer be doing them. One month later I was proven right: They spend to much time listening to other people talk about something that had no impact on their job. Their manager used the standup to report and discuss everything that happened. In the end it took over an hour of standing and mostly listening. So we did a retrospective and talked about the lessons learned and what which actions we should take. We decided to only hold stand ups for the actual software development projects and with the manager only as an observer. This worked wonderful and took only about 5 minutes of team for each standup.
- Sometimes things will become really complex and complicated. Simply take a step back, do some brainstorming and try to find a better solution for the problem, get some outside help if necessary. One of my customers had a really big workflow that started from requirements gathering over analysis, budgeting, approvals, design, development, testing to finally deployment and support. They had put it all into one JIRA Software workflow and one gigantic Scrumboard. They had sprints of more than 2 months to simply be able to finish some issues during this sprint. They had no stand ups and people got confused when using the board. Especially because they were clearly divided into different teams with different responsibilities. They took a step back from this and created several Kanban boards and one Scrum each covering just a small part of the total workflow. This allowed them to have a Kanban for requirements gathering, one for approval and budgeting, one for design, one for testing, one for deployment and one for support. The developers wanted to keep using Scrum so they used a Scrumboard and now do 2 week sprints. The project managers that created the giant board and workflow now used a simplified kanban board to see on which step each feature is.
- But will also get to party!
- Have happy customers
- you might even reach a state of zen when working in a well oiled team/machine…
- So what’s next?
- Now it’s time to do it yourself…
- Read some books
- Experiment
- Do a retrospective
- Repeat :)