we must prioritize the impediments, and keep removing or reducing the top one until velocity is doubled
Hint: We might want to prioritize the impediments by how much the removal/reduction will increase velocity. 25% here, 30% there; pretty soon you're talking a real increase in velocity.
Hint: Improving quality and reducing technical debt are almost always important keys to seriously increased velocity. Not the only keys, but very important.
Velocity is best used for long term planning. I can look at my velocity over several iterations and come up with an average (Preferably a range.) Then I can use that information to say things like: 1) Given the current backlog, how many iterations is it likely to take to complete a given set of stories? 2) How many story points, and by extension what set of prioritized stories, can I deliver by date X (e.g. in time for the trade show?)
I am very wary of anyone who suggests increasing velocity is a goal. *They are just estimates*. It is so easy to game. I've seen it happen both consciously and subconsciously with very undesirable effects.
The only measure of increased productivity is completed work. Measuring this also has the desirable side effect of encouraging people to break work down into the smallest possible deliverable units.
Helicopter Managers – who step in too soon to rescue thereby depriving the team to think and solve problems together.
Absentee Managers – who would not step in at all irrespective of whether the team has all the necessary skills to tackle the problem.
If the team has sufficient skills to solve the problem then give them space else ask questions to help them get unstuck. This would help in building the skills eventually.
When time is not of the essence give the team time to work the issue. This would improve the team feeling and collaboration.
If the solution space is limited in scope and impact, or the decision is reversible, give the team space to solve the problem, even it there's a good chance they'll get it wrong the first time.
Tolerate mistakes and allow time for learning – management should not jump in at the first problem. They should allow the team to learn from their mistakes and take corrective action on their own.
Clearly define the boundaries – Without this the team is lost on how much they can manage themselves and when should they invoke management help. Without the definition of boundaries, teams err on side of caution and do not take any decision without seeking permission.
Keep the team challenged, yet not frustrated- The manager should be aware of the team’s skill level and limitations. He should be able to provide the team with enough challenges to keep them in a state of learning and growth.
emphasis on the balanced involvement of management with the team
It is important for the managers to be aware of the skill level of the team to step in or stay back at the right moment and act as a catalyst for the team to reach a state of self organization
Coaches help teams learn Agile practices get from 'Agile seems to be something we should do' to 'we are practicing Agile development and succeeding by regularly delivering business value'.
ncreasingly there are reports of initial success followed by failures with Agile adoption.
I believe that there is a problem to how current Agile coaches - especially external ones (such as the author) - have traditionally performed their jobs. In fact, I think we are part of the problem
We do a very good job - in general - teaching the skills. That is, teaching the team to run an iteration with a kickoff, demo and retrospective. Teaching test driven development. Some of us even do a very good job teaching the team to be pseudo-self-organizing by taking a socratic approach to coaching and standing back and letting the teams make their own mistakes and learn from them.
We even do a good job - in many ways - teaching the team the values of Agile development. If we are there long enough, the values come from diligent and disciplined application of the practices.
how Kanban metaphor from Lean manufacturing and the Feature Injection template play into Behaviour Driven Development, working together to help us identify the most important software, reduce unnecessary artifacts at each stage of development, and produce the minimum necessary to achieve a vision
The artifacts signal each role to create further artifacts until the vision is implemented and the business value is earned
"Generating reports," he says, "is like lead. It's easy to work with, and it's cheap. It's also heavy, worthless, and drags you down. Developers sink a lot of time into writing report software. Why? Buy it, install it, hack it so it works. Use Excel. Don't spend money writing report software, unless you're the kind of company that sells them to other companies.