These impediments were identified (some I think are redundant). Note that some are expressed in quite a different way (eg, some negative, some positive). Dups may indicate that an issue is very important.
Legacy Code impacts
Allocate the correct people to the team
Address Env Issues
Define scope / business ask (better)
Multiple decision makers
Need more clarity on current state requirements
Lessen the amount of requirements for MVP
Empower them to make project choice decisions What is MVP?
External influences
Failing to ask customer what they want
Defects
Communication
Ensure understanding
Team building
Clean up technical debt
Implement automated unit testing
Setup collocated team
Reduce env. setup time
Reduce approval wait time
Environment Management improvement
Documentation of hack fixes or work-arounds (technical debt)
Clear architectural picture of systems & apps & what impacts what
Bad requirements
Moved too fast
Under-estimating story
Waterfall mind
Poor planning
Lack of people
Need an account with every possible type of purchase history scenario
Need dedicated team
Waterfall mindset
Tech Debt
Missed requirements
No coffee
Team interruptions
No collaboration
Poor processes
Working as a Team.of.One
Document priority list
Get team working together on same project
Fix technical debt
Role clarification
No scope definition
Infrastructure
Less confidence
Team members boxed into projects
Wrong skill-set in Team
Too big
Remove resource sharing
Move resource to area
Unknown technology
Lack of resources
Not working together
No business direction
Fix environment
Changing direction
Silos
Scope creep
Changing teams
Lack of communication
Environments
Poor testing
Wrong stakeholders
Date of deployment changed
People allocation
Too many organizational changes
Lack of product knowledge
Poor upfront planning
Extended testing duration
Poor performing team
More defined scope
Dedicated team members
Organize a team (define key roles within the team)
Do Scrum right (daily scrum, retrospective, length of sprint)
Dependencies on other releases
Have a scrum master assigned
Have a dedicated team!
Have a daily standup
Have a sprintly retrospective
Communication from offshore team
Competing priorities
Lack of process knowledge
Unclear requirements
Lack of funding
Lack of understanding team goal
Get all stakeholders on the same team
Remove dependencies from other teams
Internal politics
No sponsorship
Improve communication with team in Chicago
Team members not focused only on our team / project
Ability to release (lack of)
Code integration practices
Reduce environments (number of)
How many impediments should a team have on the list? Well, it is important to identify the biggest thing to work on, and in that way, a list can help. But after the top 20, does a longer list help? Probably not.
If you have a group of teams, how many impediments should we have? Well, in reality, we have 900+ impediments because nothing we do is perfect. So, all 900 things might be improved. But, again, realistically, with 4 scrum teams, a manager of that group might find a list of 40 helpful, but probably not more than that.
Legacy Code impacts
Allocate the correct people to the team
Address Env Issues
Define scope / business ask (better)
Multiple decision makers
Need more clarity on current state requirements
Lessen the amount of requirements for MVP
Empower them to make project choice decisions What is MVP?
External influences
Failing to ask customer what they want
Defects
Communication
Ensure understanding
Team building
Clean up technical debt
Implement automated unit testing
Setup collocated team
Reduce env. setup time
Reduce approval wait time
Environment Management improvement
Documentation of hack fixes or work-arounds (technical debt)
Clear architectural picture of systems & apps & what impacts what
Bad requirements
Moved too fast
Under-estimating story
Waterfall mind
Poor planning
Lack of people
Need an account with every possible type of purchase history scenario
Need dedicated team
Waterfall mindset
Tech Debt
Missed requirements
No coffee
Team interruptions
No collaboration
Poor processes
Working as a Team.of.One
Document priority list
Get team working together on same project
Fix technical debt
Role clarification
No scope definition
Infrastructure
Less confidence
Team members boxed into projects
Wrong skill-set in Team
Too big
Remove resource sharing
Move resource to area
Unknown technology
Lack of resources
Not working together
No business direction
Fix environment
Changing direction
Silos
Scope creep
Changing teams
Lack of communication
Environments
Poor testing
Wrong stakeholders
Date of deployment changed
People allocation
Too many organizational changes
Lack of product knowledge
Poor upfront planning
Extended testing duration
Poor performing team
More defined scope
Dedicated team members
Organize a team (define key roles within the team)
Do Scrum right (daily scrum, retrospective, length of sprint)
Dependencies on other releases
Have a scrum master assigned
Have a dedicated team!
Have a daily standup
Have a sprintly retrospective
Communication from offshore team
Competing priorities
Lack of process knowledge
Unclear requirements
Lack of funding
Lack of understanding team goal
Get all stakeholders on the same team
Remove dependencies from other teams
Internal politics
No sponsorship
Improve communication with team in Chicago
Team members not focused only on our team / project
Ability to release (lack of)
Code integration practices
Reduce environments (number of)
How many impediments should a team have on the list? Well, it is important to identify the biggest thing to work on, and in that way, a list can help. But after the top 20, does a longer list help? Probably not.
If you have a group of teams, how many impediments should we have? Well, in reality, we have 900+ impediments because nothing we do is perfect. So, all 900 things might be improved. But, again, realistically, with 4 scrum teams, a manager of that group might find a list of 40 helpful, but probably not more than that.
No comments:
Post a Comment