Teams run into trouble when they adopt agile practices without really knowing why they are doing them. This can happen when people who’ve been told to use iterations (sprints) still don’t understand why. And when they act on these statements, they unknowingly undermine their efforts to use agile. What can we do?
In an ideal world, a cross-functional Scrum team must be fully focused on Scrum. The team is also expected to hear a voice of one customer only: the product owner. But what happens when reality intervenes and you get pulled in other directions? As our two-part series concludes, we look at the remaining two ways of interrupting Scrum sprints--and share what can be done about them.
In an ideal world, a cross-functional Scrum team must be fully focused on Scrum. The team is also expected to hear a voice of one customer only: the product owner. But what happens when reality intervenes and you get pulled in other directions?
There are great opportunities for growth and deviation outside the standard agile models for stable teams who want to evolve further. This article tells the story of one team that did just that--and what other people can learn from it.
by Kevin Aguanno, PMP, MAPM, IPMA-B, Cert.APM, CSM, CSP
The number of agile certifications available in the market keeps growing, and one must consider the unique needs of the inquiring company or individual to know what would be best for them. What factors should you consider? Do you even know the options available?
Have you ever entered a sprint taking on a user story that you later regretted? What can be done to prevent this frustration? Is there a technique that will prevent this from happening, or are these teams doomed to keep repeating their mistakes?
Question: After a recent conversion by my team regarding agile, we find that there is a mismatch between the number of hours we should have for working on stories and the amount of time we really have. So we are constantly over-committing to our Product Owner and not delivering. Where are we going wrong?
Traditional teams may have a 15-20% contingency cushion in time and cost on their project estimates. Routinely subtract a similar agile contingency from the number of backlog items you accept to make sure you finish all planned work within a single iteration.
Agile is expected to be flexible, and velocity can vary. Just complete what you can and adjust your velocity for the next sprint if you don’t finish all of the stories you committed to complete this time.
Be sure you are acknowledging hours that team members will spend in Scrum ceremonies, personal time commitments and non-team directed organizational work before calculating the capacity for this iteration.
Ask the ScrumMaster to speak to anyone on the team who did not finish his or her work during the previous iteration. This person is making the team look bad and should be disciplined if it happens again.
A retrospective is a special meeting during which the team gathers after completing an increment of work to inspect and adapt their methods and teamwork. Retrospectives enable whole-team learning, act as catalysts for change and generate action. This article presents some of the reasons why the retrospective’s efficacy can fade over time and then discusses some interesting techniques to keep them lively.
As an experienced agile coach, this writer often gets asked about agile tactics and practices--what works and what doesn’t. There are no singular answers, but there are some generative behaviors and rules for agile done well. In this article, he explores a set of common anti-patterns that he sees in an effort to share what not to do in your agile journey.
Is Scrum better, or Kanban? Which is more suitable for your project? Such questions--and sometimes the responses--put managers in a dilemma about which framework to embrace. Each has its own benefits and tales of success...
The concept of double-loop learning exemplified by the Mobius strip can be a great model for encouraging transformational improvements by challenging key assumptions and strategies. Combining agile practices and a dose of courage, learn how double-loop learning can help your organization respond more effectively to change and thrive in the marketplace.
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...
Question: Finally, we have convinced human resources that our agile team lead and our ScrumMaster need to be involved in hiring new team members. But now that we have the authority, we really don’t know what to look for in a good hire. How do we use this new power to our best advantage in choosing a fresh agile colleague?
Be careful what you ask for. Only human resource certified people are qualified to choose new employees for an organization. Revoke your participation rights in this process or you will be blamed when this new hire fails.
It’s not only the questions you ask, but what you do with the answers that will empower you to choose the best addition to your team. Create a good list of questions and know how to interpret what you hear.
Your product owner is the person on the management team and is more experienced in what makes a good agile team member. Ask him to sit in on candidate interviews and then defer to his superior judgment when making the final choice.
The person you hire must fit into the team, so assemble the entire team and have all of them work with you to interview potential candidates. Once they have agreed on a choice, they will be forced to work with the new person successfully since they have been part of the hiring decision.
Agile project management, and particularly Scrum, can become overwhelmingly consumed by methodology, jargon and rules. This is just the opposite of what was originally intended for agile-lead projects, and it is the communications part of our role that is so important.
Ever encounter people who consider themselves “victims” of the agile process? They are competent contributors, managers and project managers who never asked for agile, have had no say in its implementation and hate going through its motions. What can you do to cheer them up?
While self-organized teams are valuable and shared responsibility is the way to manage any project, it seems like a project manager is needed to steer things in the right direction--just make sure you allow them to adapt.
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?
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.
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.
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.
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.
We've covered certain challenges a project manager is likely to face when a Scrum transition is first being evaluated, and a comparison between Waterfall and Scrum methodologies. Part 2 of this article covers the ScrumMaster and Product Owner roles in the Scrum environment--and also addresses the project manager’s role during and after an organization's transition to Scrum.
In a pure Scrum environment, the project manager's responsibilities are reallocated to the newly introduced roles of Development Team, ScrumMaster and Product Owner. In a hybrid Scrum environment, the project manager role may still exist--but likely in a significantly altered form. PMs need to take the impact of this change on their role and responsibilities into consideration…and plan accordingly.
Question: I’ve just been chosen as ScrumMaster for my agile team. I know I “remove obstacles”, but I’m concerned about what I can do on a daily basis and what is overstepping my role and moving back to traditional project management. How can I make this a better team?
The ScrumMaster role is non-technical, which is a reward for outstanding technical performance in the past. In essence, you retire at full salary.
The ScrumMaster has a key role in improving team performance, so find your own way to structure the team processes and to facilitate team development.
Since the team is self-directed, wait until team members present obstacles at daily scrum meetings and then tell a manager to remove them.
Find an experienced ScrumMaster in the organization and ask if you can shadow them for two days a week. Then, follow their directions so that all the agile teams are working alike.
Life gets really interesting when we start to extrapolate the brand identity concept into our project methodologies. What drives the decisions about what different organizations use? And is there any tangible benefit to choosing a “brand label” project execution approach?