If we are going to create an environment that is open to change, interactions and collaboration, then we also have to be prepared to deal with difficult emotions and decisions. And managing people in an agile environment requires social acumen...
This second article continues the discussion by looking at the second group of factors related to the readiness (and willingness) of the project team to adopt agile best practices. As with sponsorship factors, we need to consider cultural, structural and management aspects.
Most of us work on projects where we know the end date or the budget--or both. But there is a category of projects where we might not know either: emergent projects. Emergent projects are change projects such as your agile transition or any other project that you have no control over. Can you apply agile to those projects? Yes. Carefully.
Question: Is there a way to improve velocity of an agile team? There seems to be a lot of advice not to change estimates, overpromise and not to overwork team members. But sometimes there just needs to be a way to jump start productivity.
| A. | There is no sense in “falsifying” estimates to give the appearance that you will increase team velocity. It just moves you back to more traditional practices where you don’t meet the project timeline goals. Velocity cannot be improved. |
| B. | Even though you don’t want to change estimates arrived at honestly, there are some team tune-ups that have a good chance to increase agile team velocity. |
| C. | Since velocity is based on the performance of team members, if you reduce each person’s estimates by the square root of the velocity of the last iteration you will eliminate slack and increase motivation, resulting in increased velocity. |
| D. | Add 15% to the velocity each sprint or iteration. That way the team slowly learns to work faster and the speed with which projects are completed will be affected positively. |
Is your agile team’s velocity constant from sprint to sprint? No? That’s not a surprise. Many teams assume that their velocity will be constant. In this article, we’ll see why that’s not the right expectation--and how that affects how you use this metric.
Question: Today a person appeared at my desk saying he was the new Business Analyst for the team and he set up a meeting with me for next Tuesday. I didn’t want to appear stupid, so I just said okay. We’re an agile team, so is he replacing me as ScrumMaster, or what? Should I be worried about my job?
| A. | The Business Analyst (BA) certification is the replacement credential for the old Project Management Professional (PMP), but with an agile flavor. Check online to see how quickly you might get this new certification if you hope to continue on with your organization. |
| B. | Rather than replacing a project manager or ScrumMaster, the BA is the representative of the Customer or Product Owner who is funding or authorizing your project. He will benefit the team, as he may have more availability than the actual Product Owner. |
| C. | The BA is a junior version of a Quality Assurance team member, and can help you finish your projects more quickly since he does not have the test backlog of a seasoned QA person. |
| D. | The ScrumMaster reports to the Functional Manager whose department will benefit most by the completed project deliverable. Perhaps the BA made an error in contacting you. |
Custom software development is notoriously difficult to estimate. We start with vague ideas of what we want, expecting to fill in the details later. We’re usually doing something a little different than what we’ve done before, or completely different. How can we act more productively?
Many organizations have struggled with their early agile experiments. Due to the issues faced, they typically cannot answer the simple question: “Are we ready to go agile?” This first article examines the factors that indicate whether the sponsoring organization is ready (and able) to modify the way it works to increase the chances of a successful agile project.
For agile teams, a traditional PMO can seem to Present Many Obstacles--but it does not need to be that way. With some alignment and time invested, they can be useful advocates.
Are agile practices themselves ever so rigid that they become stifling rather than liberating? Sometimes, strict adherence to an agile framework can cause problems for project teams. Be on the lookout for these issues...
Should an agile team begin with requirements documented as use cases or user stories? Proponents from both sides of the debate make good arguments, leading to confusion for many who are just getting started with agile practices.
|
"In the beginning, the universe was created. This has made a lot of people very angry, and is generally considered to have been a bad move." - Douglas Adams |
PMI Team Member
