- 44% ability to change organizational culture
- 35% not enough personnel with the necessary agile experience
- 34% general organizational resistance to change
Tuesday, March 8, 2016
Here are the survey results from Version One on the state of agile. A pretty good job, I think. Many interesting observations in the survey. Let me highlight one. Under "Barriers to Further Agile Adoption", the top 3 answers were:
Monday, March 7, 2016
Here are the main ones, in order.
- Joe's Approach to Release Planning
- Agile Release Planning Vision
- Agile Release Planning Product Backlog
- Agile Release Planning Business Value
- Agile Release Planning Effort 1
- Agile Release Planning Effort 2
- Agile Release Planning Risks, Dependencies, Learning, MMFS
- Agile Release Planning Completing the Plan
- Agile Release Planning Refactoring the Release Plan
Some additional related posts:Agile Release Planning Workshop Kent McDonald on Release Planning The Term 'Release Planning' Is Release Planning Worth It? Agile Release Planning is not about the Plan Release Planning with Business Stakeholders ALN RDU: Joe's Agile Release Planning Why Release Planning? Scrum and Release Planning Release Planning Release Planning & The Early Warning System Why I Prefer 'Release Plan Refactoring' to 'Grooming' Two Levels of (Agile) Planning Planning Poker - 1 Estimating Initial Velocity Wide-band Delphi Estimation for Business Value - 1
Saturday, March 5, 2016
We have a slightly improved version of our 'List Summarizing Scrum.' Not many changes, but a few minor ones. A list summarizing ScrumV6 How can this be useful? First, it is only a list, and prints onto one page (front and back). Two proposed uses:
Visit a team, and discuss the list fairly quickly.The purpose is to enable a conversation that leads to a more successful use of the lean-agile-scrum ideas. The purpose is of course to decide where to improve next. What are [they] doing? What are [they] not doing? Any ideas [they] do not understand? Which areas do [they] need the most help?
Define Agile-Scrum at your companyThe list is a start at defining what you mean by agile at your company. Perhaps you have a rule that says "If you are going to be 'agile,' you are expected to be doing the things on the list. If you need to make an exception, please speak to Dr. Freud." The notions behind this rule are several.
- Often 'agile' has no definition, and this often leads to unprofessional agile.
- Things can be crazy 'out there.' (Hence a smiling reference to Dr Freud.)
- There is a need for each team to be different, so some allowance needs to be made for that, even at the 'framework' level.
- Often teams are junior or do not understand agile fully. Or have mistaken ideas about agile. Once they talk to an expert, they see the 'errors of their prior thinking' and decide to do agile more professionally.