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.
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.
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?
We've already traced the genealogy of Kanban. It’s now time to start looking at the evolution of Kanban from its manufacturing roots in the automobile industry to its current widespread use in software development. This will ultimately allow us to see where practices and tools like Lean and Kanban go to the “beyond”.
by Kevin Aguanno, PMP, MAPM, IPMA-B, Cert.APM, CSM, CSP
New ScrumMasters may understand the “what” and the “how” of their new practices, but they often don’t understand the “why”. Here we look at two common problems: project managers not creating the sprint burndown charts and teams not participating in the daily standup meetings.
Kanban has been synonymous with Lean since its origins were from that movement, but we have also witnessed a spawn of new iterations. These are all testaments to its growing popularity and influence. This article will be the first in a multi-part series that will cover Kanban in terms of its origins and genealogy, current use in the software development and project management industry and the possible future trends of this very interesting workflow visualization tool.
As our look at agile development concludes, we will take a more in-depth look at Scrum, XP, Flexible Project Management, the Agile Leadership Model, Agile Project Management, Adaptive Project Framework and Scalable Delivery Model.
What is agile project management, and what are its origins? And don't agile methods address the challenges of 21st century systems, like high-risk, time-sensitive, R&D-oriented, new product and service development projects? One expert takes a look back at the history of this rapidly growing method.
Aren’t resolutions just mini-projects you want to accomplish? What better way to do that than by leveraging agile! The Scrum framework is best suited for this. Let’s look at how to hack Scrum for personal productivity…
One of the secrets of a practitioner's success is that I he has varied from the traditional burndown chart and sprint estimation suggestions that are taught when a person learns about Scrum. If you have had issues with making accurate burndown charts that reliably tell you when your sprint will finish, then perhaps his suggestions can help.
Working with iterations does not automatically make you an agile team. It doesn't even necessarily mean that you are using iterative development. Paradoxically, it is possible to be agile without use of iterations. Let’s get into details...
You've probably read many articles on the difference between traditional project management and agile (specifically, Scrum). One practitioner has been surprised with how established agile practitioners don’t want to let project managers into their “club”. Why can’t project managers become agile?
Part 1 of this series discussed the background environment and philosophical divergences that caused agile to establish itself as an alternative to traditional project management. With that background established, it’s now time to start thinking about the where agile is headed and how it will get re-contextualized for the 21st century.