WEBIT 2016 - Stop Doing Scrum; Start Being Agile!
•Download as PPTX, PDF•
1 like•340 views
The slides from my WEBIT 2016 talk titled: Stop Doing Scrum; Start Being Agile!
Recommended
More Related Content
Viewers also liked
Viewers also liked (19)
More from Peter Van de Voorde
More from Peter Van de Voorde (14)
Recently uploaded
Recently uploaded (20)
WEBIT 2016 - Stop Doing Scrum; Start Being Agile!
- 1. PETER VAN DE VOORDE • COMMUNITY DEVELOPER • ATLASSIAN • @P VDEVOOR 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 The Agile Manifesto
- 15. 4 values
- 16. Daniel Y. Go (Flickr) Individuals and interactions Processes and tools Over
- 18. Cushing Memorial Library and Archives, Texas A&M Customer collaboration Over Contract negotiation
- 19. Brian Rinker (Flickr) Responding to change Over Following a plan
- 20. That is, while there is value in the items on the right, we value the items on the left more. WWW.AGILEMANIFESTO.ORG “ ”
- 21. 12 principles
- 22. • Big cool statistic • Add-Ons in Marketplace Phil Dowsing Creative (Flickr) Satisfy the customer through continuous delivery of valuable software.
- 23. • Big cool statistic • Add-Ons in Marketplace ** RCB ** (Flickr) Welcome changing requirements.
- 24. • Big cool statistic • Add-Ons in Marketplace szeke (Flickr) Deliver working software frequently.
- 25. • Big cool statistic • Add-Ons in Marketplace bwright923 (Flickr) Business and IT need to work together daily.
- 26. • Big cool statistic • Add-Ons in Marketplace Warner Bros Build around motivated individuals.
- 27. • Big cool statistic • Add-Ons in Marketplace dan2010 (Flickr) Face-to-face communication.
- 28. • Big cool statistic • Add-Ons in Marketplace Atomic Mutant Flea Circus (Flickr) Working software is the primary measure of progress.
- 29. • Big cool statistic • Add-Ons in Marketplace Dejan Hudoletnjak (Flickr) Promote Sustainable Development.
- 30. • Big cool statistic • Add-Ons in Marketplace Damien (phototrend.fr) Continuous attention to technical excellence and good design.
- 31. • 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 “ ”
- 32. • Big cool statistic • Add-Ons in Marketplace Create a self-organized team.
- 33. • Big cool statistic • Add-Ons in Marketplace ores2k (Flickr) Look back, reflect, adjust.
- 34. • Big cool statistic • Add-Ons in Marketplace ed_needs_a_bicycle (Flickr) Where do we start?
- 35. • Big cool statistic • Add-Ons in Marketplace Thomas Hawk (Flickr)
- 36. • Big cool statistic • Add-Ons in Marketplace Mountain Goat Software
- 37. • Big cool statistic • Add-Ons in Marketplace Jeff.lasovski (Wikimedia Commons)
- 38. • Big cool statistic • Add-Ons in Marketplace Ricardo Fernández (Flickr)
- 39. • Big cool statistic • Add-Ons in Marketplace x-ray delta one (Flickr)
- 40. • Big cool statistic • Add-Ons in Marketplace Mountain Goat Software
- 41. • Big cool statistic • Add-Ons in Marketplace ed_needs_a_bicycle (Flickr) What will happen?
- 42. • Big cool statistic • Add-Ons in Marketplace robynejay (Flickr)
- 43. • Big cool statistic • Add-Ons in Marketplace Christian R. Hamacher (Flickr)
- 44. • Big cool statistic • Add-Ons in Marketplace synx508 (Flickr)
- 45. • Big cool statistic • Add-Ons in Marketplace Mixtribe Photo (Flickr)
- 46. • Big cool statistic • Add-Ons in Marketplace efatima (Flickr)
- 47. • Big cool statistic • Add-Ons in Marketplace marycesyl (Flickr)
- 48. • Big cool statistic • Add-Ons in Marketplace ed_needs_a_bicycle (Flickr) So what’s next?
- 49. • Big cool statistic • Add-Ons in Marketplace kightp (Flickr)
- 50. • Big cool statistic • Add-Ons in Marketplace Swamibu (Flickr)
- 51. Real LifeMotivation Some interesting books… Change Management
- 52. • Big cool statistic • Add-Ons in Marketplace atlassian.com/agile
- 53. • Big cool statistic • Add-Ons in Marketplace clement127 (Flickr)
- 54. • Big cool statistic • Add-Ons in Marketplace Bart van de Biezen (Flickr)
- 55. • Big cool statistic • Add-Ons in Marketplace Thomas Hawk (Flickr)
- 56. 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
- 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 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 you 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 :)