Agile Adoption Failure Mode
•Download as PPT, PDF•
1 like•1,192 views
This document discusses common reasons why agile adoption may fail in organizations. It suggests that management may not fully trust or support the agile team and process. The product owner role may not be fully committed or may micromanage the team. There could be a lack of clear vision or communication from leadership. Teams may not truly be self-organizing and self-leading. Retrospectives may not be held properly. There could be a lack of commitment to sprints.
Recommended
Recommended
More Related Content
More from Xebia IT Architects
More from Xebia IT Architects (20)
Recently uploaded
Recently uploaded (20)
Agile Adoption Failure Mode
- 1. Agile adoption failure modes Pallavi & Nancy
- 6. We need not be Agile..
- 7. Don’t trust the team or agile.
- 8. Product Owner - its my turn
- 9. See you later – I am busy!
- 11. Scrum Master of the World!
- 12. I want it That way!
- 13. A problem ?
- 14. Micro Manage
- 15. Self organizing isn't Self leading!
- 16. Who Am I ?
- 17. What Am I?
- 19. WHY-less
- 20. Scrum-but(t)
- 21. Is That a Retrospective?
- 22. Meet the NotQuite Team!!
- 23. We are different
- 26. Team’s Mission..
- 27. Poor PO
- 28. Once lost never gained…
- 29. We are a Team – one BIG Team..
- 30. Stand up
- 31. Troubles
- 32. Communication - what’s that?
- 34. No Agility
- 35. Mission Accomplished-Back to your comfort zone!
- 36. Questions
Editor's Notes
- No Preaching & praising and convincing the agile phenomenon We are here to save to ppl who are not happy with the agile hoopla.. Tips to aviod success in agile Who believe it’s a mere hype Framework of the presentation . What the slides are about and how it is divided. Moving out of their personal cubicle spaces Getting their power dissolved and tired of this one team shit We are here to save you by failing in agile and agile thing not bugging in your job So that you can move back to your cubicles Value, Skils and attitude becomes clearer in agile environment So you cannot keep sitting and boasting of things being done..and save your self from the agony of agile Booming in your enterprise. You actually have to do them…. You all of you can brace yourself to learn some tricks to fail your respective projects
- Ho wmany people have heard somewhere or the other that agile = no documentation? Well be agile tomorrow.. Lets meet up for the stand uop at 10 tmrw and make those colorful sticky in our room.
- The big picture of software devlopment with all stakeholders within your enterprise All of you can contribute at your own level to fail your projects How this whole ppt is divided into various roles. Looking at various aspect of failing the project.
- That’s the management Lets look at their ways of failing agile and the beauty.. They might not even be aware . Story of the manager not convinced of IMPOSE AGILE TO THE TEAM
- Mgmt wary of handling power frm top down to bottom up Dissolving power not wel received by some people A switch to agile often conflicts with personal goals such as maintaining the status quo, avoiding career risk, working no harder than necessary, or maintaining a large fiefdom of direct reports. Manager takes agile to just another fad but reads book and takes a training Still not convinced Imposing a process on a team As team obligation tells the team to be agile from tomorrow
- Manager not convinced so not trusting agile. Let the evangelist take a back seat in promoting agile. Attends daily scrum meetings Points to why and why nots Stand up mere procedural correctness and concise No more problems being reported anymore Agile aint silver bullet Ignore Agile practices They don’t apply to management Why for every move of tem every support required by team Make the surrounding for them and just fit them in to work let them know you think agile is a fad. Some of them will be skeptical to begin with, so it won’t take much to convince them to ignore the practices. De motivate team with your dis-belief
- Now Its product owners turn to take project towards failure. A product owner has many options at his disposal to bring an agile project to its knees.
- Avoid planning sprint planning meetings Don’t prepare clear and prioritized backlog Don’t be available when team need you for clarification Don’t pay attention to the progress of each iteration and objectively evaluate the value of that progress. Never attend a review to give your feedback As you can see, failure at the product owner level is easily achievable through miscommunication, general ignorance of the team’s progress, and lack of education.
- Don’t communicate a vision for the product to the team or to the other stakeholders. Replace a plan document with a plan “in your head” that only you know. Ask the team to change sprint goals
- As a Scrum master I will also do my part to make this project fail because I am master of agile world so lets see what wonders a scrum master can do to fail
- Don’t surrender control to the Product Owner and team. pay close attention and point out what the team is doing right and what it is doing wrong. Don’t believe in self organization of team and there decision, impose your wishes on team
- Don’t remove impediments if at all team has any Don’t Radiate information. ensure that a team’s progress and successes are is not visible to all stakeholders, including the team itself. Encourage heroism Don’t shield team from external noises. Your indifference with PO effect teams work. Don’t treat equal as team try to be there boss.
- Kill creativity and empowerment for the development team by telling them how to do and commit on behalf of team.
- often the adoption of agile will be driven by the team itself No leadership that provides a vision to work toward and motivation for achieving that vision. Freed to pursue that goal and provided with on going guidance from a product owner, an agile team can become truly high performing. Don’t give your team that opportunity!
- So who is she? A PO , A scrum master or an individual team member in the team. Role of PO balanced by scrum master Be one. PO holds the vision and looks for ROI. SM tells the ways of getting max value out of the team.
- Why not this feature in this sprint in the team Simply doubts on the estimation and planning process by the team. If a member gives 8 story points put them down to 2 by your say and conviction You think you know better about the product
- careful misapplication of process issues can bring down almost any agile project Imagine a team which started with agile They wanted to remove the un neccsary overhead with a few practices They immediately dispensed with daily standup meetings , reasoning that since the team sat in the same general area, most conversations could be heard over the six-foot-high cubicle walls. Removed automated testing as for a new application no chance to break the whole code. Embraced refactoring and collective code ownership Their new rule was that any programmer could change the code of any other programmer at any time. Without tests to vouch for stability after refactoring
- <We use Scrum, but><we have these unique circumstances><so we have had to modify Scrum so it works here> Start customizing an agile We’re small but very busy team working on up to 15 projects at a time. process before you’ve done it by the book. Drop and customize important agile practices before fully understanding Examples: -our sprints are 12 weeks long... we do two normal sprints and one bugfix sprint... we do all our planning up front... we skip the daily meeting...write the status mails or on wiki pages our managers decide what's in each sprint... we haven't read the books yet... our team has 30 people... No coomon team area No automated testing
- never held a retrospective at the end of each sprint. Tell them that it’s a waste of time to sit and talk about a project. Don’t continually improve Don’t change the technical practices.
- Make simple tasks complex and consume more time. Making your project a technical playground Introducing complex technologies for a simple task.. Adding technically incompetent people in to the team.
- Do not create cross-functional teams. Put all the testers on one team, all the programmers on another, and so on This team shows the power of consistency in bringing down an agile project.
- For its first iteration, NotQuite committed to completing six items from the product backlog; it finished four.
- For the second iteration the team again planned to finish six items; it finished five. The slight improvement only lulled the product owner into a false sense of security. NotQuite continued to chronically over commit, falling short in the third, fourth, and fifth iterations. Continually fail to deliver what you committed to deliver during iteration planning. When falling short, don’t make the
- move work forward from one iteration to the next. It’s good to keep the product owner guessing about what will be delivered. it makes it impossible for the product owner to make plans and external commitments.
- the product owner learned not to trust the team As we know trust is one of the pillar of agile
- Karl Popper's &quot;First law of collective action&quot;. You can never get more than 5 people to agree on anything.
- World cup 2006 Zidane head butting Italy’s marco matterazi Introduce impediments Do not encourage Team sprit Not trusting you fellow team members Harm the team dynamics Human nature To have difference of opinions More the merrier Promote heroism
- Stop communicating clearly with your peers Superficial information radiators Atrificial status update No pair programming Working in isolation on a user story No reviews No sharing diff and challenges No raising alarms when stuck
- Your door to non agile environment