Recommended
More Related Content
Similar to 2017 - JITF - Agile survival kit - how to save the marriage
Similar to 2017 - JITF - Agile survival kit - how to save the marriage (20)
Recently uploaded
Recently uploaded (20)
2017 - JITF - Agile survival kit - how to save the marriage
- 1. JUMP IT FORUM 2017 ZAGREB HOTEL & CONGRESS CENTER ANTUNOVIC | APRIL 11-12, 2017
- 3. OUR RECENT AGILE COACHING ENGAGEMENTS Tuesday, April 11, 2017 JUMP IT FORUM 2017 ZAGREB 3
- 5. CHAPTER ONE - “CHAOS REPORT”
- 6. be the problem? What seems to
- 7. In come the Japanese. Time is just after WW2. We have good processes in software development. Right?
- 8. In come the Japanese. Time is just after WW2. Also, we govern our projects with proven stuff: ISO, PMI, …
- 9. We know our way around top technologies: Java, .Net, JavaScript…
- 10. Yet sometimes…
- 11. Or most times
- 12. Or pretty much
- 13. All the time
- 17. But there is light…
- 19. RUN SMALLER PROJECTS RUN AGILE PROJECTS TAKEWAYS FROM “CHAOS REPORT”
- 20. CHAPTER TWO – “AGILE TODAY”
- 21. “AGILE” IS JUST AN UMBRELLA TERM FOR MANY METHODS • The term “Agile” was oined in 2001. in Utah as a common denominator • Defined by a set of principles and the Agile manifesto
- 22. STRONG POINTS OF ALL AGILE METHODS oMorale stays high for a long time oAll methods focus on result, not the by-product oFeedback cycles are faster oBetter communication is enforced oTransparency is built-in oTools for implementation are simple oHigher predictability of end-results (budget, date, scope, quality)
- 23. State of Agile 2016.
- 24. State of Agile 2016.
- 25. AGILE DEFAULTS TO SCRUM AGILE IS MAINSTREAM TAKEWAYS FROM “AGILE TODAY”
- 26. CHAPTER THREE – “AGILE SURVIVAL KIT”
- 27. “Scrum is a framework for developing and sustaining complex
- 29. LET’S PUT THAT IN PERSPECTIVE PROJECT MANAGEMENT APPROACHES PMI (PMBOK) IPMA METHODOLOGICAL LANDSCAPE IN SOFTWARE DEVELOPMENT SOFTWARE DEVELOPMENT PRACTICES CONTINUOUS INTEGRATION CONTINUOUS DELIVERY TDD PORTFOLIO MANAGEMENT PRACTICES LEAN PORTFOLIO MANAGEMENT PRINCE2 PPM (PMI) SOFTWARE DEVELOPMENT FRAMEWORKS LEAN AND KANBAN SOFTWARE DEVELOPMENT RATIONAL UNIFIED PROCESSING SCRUM AND OTHER AGILE WATERFALL V-SHAPE …
- 30. DON’T GET RID OF YOUR PMO JUST YET! JUST MAKE IT MORE AGILE
- 31. TOP 10 ANTI PATTERNS OF SCRUM USAGE
- 32. #1 NOT WILLING TO ADAPT YOUR PROCESS SCRUM IS NOT A PROCESS. IT’S A FRAMEWORK FOR EMPIRICAL PROCESS CONTROL IT’S A VEHICLE, NOT THE DESTINATION
- 33. #2 MAINTAING THE PRODUCTION SCRUM IS TIMEBOXED. IT’S YOUR FIRST CLUE ITERATIONS PROMOTE FOCUS FOR 1- 4 WEEKS. CAN YOU WAIT THAT MUCH? USE KANBAN OR WATERFALL FOR THAT.
- 34. #3 JUST SHORT OF A TEAM THERE’S 2 OF YOU. YOU ARE A COUPLE. GET A ROOM. EVEN AT 3, YOU SHOULD COSINDER ALTERNATIVE GROUPING METHODS
- 35. #4 UNABLE TO HAVE STABLE TEAMS FIRST OF ALL – I AM NOT BUYING THIS. STOP STARTING AND START FINISHING. OVERBURDERN WILL HAPPEN, THE PRINCIPLES ARE NOT ACCEPTED
- 36. #5 PROJECT TOO SIMPLE BACKLOG IS NOT LARGE ENOUGH FOR AT LEAST 3 SPRINTS? REMEMBER: COMPLEX PRODUCTS NOTHING TO LEARN ALONG THE WAY, JUST REPETITIVE WORK? USE KANBAN OR WATERFALL.
- 37. #6 HETEROGENOUS SKILL SETS 1 DEVELOPER, 1 DB GURU AND 1 SCIENTIST WALK WALK INTO A PLANNING POKER GAME. PULL PRINCIPLE WILL NOT WORK. PARTS OF THE FRAMEWORK ARE STILL USABLE.
- 38. #7 DON’T WANT TO LEARN (SCRUM) SCRUM IS NOT SIMPLE AND WILL NOT BRING RESULTS UNLESS YOU LEARN AND RE-LEARN IT. COACHING; INTERNAL TRANSITION TEMS; READING A LOT. KEYS TO SUCCESS.
- 39. #8 DON’T BELIEVE IN IT ORGANISATION WANTS THE BENEFITS, BUT DOESN’T LIKE THE PRINCIPLES. PRACTICES WILL RARELY WORK WITHOUT ACCEPTING THE PRINCIPLES
- 40. #9 SELECTIVE SCRUM SCRUMBUT CITY. YOU ARE PROBABLY RUINING IT. ARE YOU SURE YOU KNOW WHAT YOU ARE DOING?
- 41. #10 DON’T LIKE BIG CHANGE SCRUM IS OPINIONATED ABOUT ROLE NAMES. SCRUM CHANGES A LOT OF THINGS AT ONCE.
Editor's Notes
- Rational unified process Requirements first Risk analysis UML Mock up screens
- We have quality standards PMI – PMBOK in 300 pages Certification for all of these Capable project managers Training in communication and stakeholder management We have master-plans Yearly resource plans
- We are rock star software developers Even if we do not have enough man power, we can get more from vendors
- 2016 Chaos report from Standish Group – Level 2 & Level 3 projects (challenged and failed) Overall, the success rate was only 16.2%, while challenged projects accounted for 52.7%, and impaired (cancelled) for 31.1%.
- 2016 Chaos report from Standish Group – Level 2 & Level 3 projects (challenged and failed) Overall, the success rate was only 16.2%, while challenged projects accounted for 52.7%, and impaired (cancelled) for 31.1%.
- 2016 Chaos report from Standish Group – Level 2 & Level 3 projects (challenged and failed) Overall, the success rate was only 16.2%, while challenged projects accounted for 52.7%, and impaired (cancelled) for 31.1%.
- Rational unified process Requirements first Risk analysis UML Mock up screens
- Rational unified process Requirements first Risk analysis UML Mock up screens
- …says the Scrum guide, a 17-pager published and re-published by Ken and Jeff, the authors of Scrum for software development. Although this sentence serves me well for the purpose of proving my “nail and hammer” point, let’s go back a bit further.
- No more and no less
- Even if Scrum is the best for Software development, somebody needs to take care of other things
- IT'S A FRAMEWORK FOR EMPIRICAL PROCESS CONTROL IT IS HERE TO HELP YOU MAKE YOUR PROCESS BETTER AND BETTER OFTEN SEEN AT BIG ORGANISATIONS AND GOVERNMENT Have you ever heard or said any of these phrases? We are going to implement the Scrum methodology. We’re doing a modified Scrum. Our developers are using a Scrum process.
- Scrum is proud to be responding to change. The backlog is not a fixed basket. We define it and re-define it at will. We put stuff in and stuff out within Scrum. We take stuff out of it every 1–4 weeks and work on it… Wait! What did you just say, every 1–4 weeks? What if a bug happens tonight, I need to wait for 1–4 weeks for you guys to start working on it? Yep. Scrum organizes work in iterations which are time boxed. These iterations promote focus and are one of the main reasons for Scrum being successful. But Scrum does not do a good job of responding to change within these time-boxes. Sure, we can re-plan the Sprint at will, but this will start eroding Scrum if done too often. And if we are maintaining a system in production, it is going to be done hourly.
- When clients tell me that they can’t focus a team for a single product, I rarely buy that. I try to tell them that it is just a matter of deciding to “stop starting and start finishing”. I perform a lot of my Aikido on them to persuade them to create dedicated teams. But, sometimes this can not happen for a number of reasons. Perhaps the organization is too small and works on many products in parallel. What happens to Scrum when a Scrum team is not dedicated? Well, pretty much nothing works as planned. The ceremonies can’t take place and they are the core engine for adaptation and empirical process control. The focus is not there. Transparency is hard to maintain. Overburden goes bananas. Not working. If you are in that 1% of organizations that really (I still don’t buy it) can’t focus the team, use something else.
- ScrumButs are reasons why teams can’t take full advantage of Scrum to solve their problems and realize the full benefits of product development using Scrum. Every Scrum role, rule, and timebox is designed to provide the desired benefits and address predictable recurring problems. ScrumButs mean that Scrum has exposed a dysfunction that is contributing to the problem, but is too hard to fix. A ScrumBut retains the problem while modifying Scrum to make it invisible so that the dysfunction is no longer a thorn in the side of the team.