Product management is often a murky role: poorly understood and inconsistently practiced across tech companies – and often confused with program and project management. Yet done well, product management is a driver of market success and effective development.
This fourth installment of articles scrutinizing agile frameworks based on values, principles and practices focuses on commitment (following the entries on courage, focus and openness). A stated value of the Scrum framework, commitment is everything in agile.
Many organizations are obsessed with getting things done quickly no matter what. Therefore, they create reward plans that motivate this behavior. ScrumMasters gradually deprioritize promoting Scrum values and metamorphose into agile project managers. How can we prevent this?
This is the second in a five-part series of articles regarding agile frameworks based on values, principles and practices. Scrum espouses five values: courage, openness, respect, commitment and focus. In this series, each article will explore one of these values--on which a deeper discussion of principles and practices assembles.
If you are a traditional project manager practicing agile methods, chances are you don’t really “get” it. Nothing has been worse for the understanding and proper application of agile approaches in organizations today than the flawed thinking and actions of well-meaning middle managers and project managers.
These days, it takes more than project management skills to succeed. It takes a person with agility—flexibility in understanding and applying the ins and outs of any method. Let’s investigate what "hybrid PM" is all about!
Hybrid project manager roles might be the way of the future. Do you need to revisit your skills? This article provides guidelines to assist you with becoming a hybrid PM, and starts by defining their characteristics.
The risk we take in swearing allegiance to a specific approach is that following the approach often becomes more important than achieving the goal of the project. Let’s explore the merits of using the best of different approaches—and how marrying them into a hybrid model impacts the way projects are planned and managed.
Question: We have switched to agile practices and, if I do say so myself, I think we are doing an awesome job. However, even though we are carefully creating backlog lists and writing user stories, more often than not our end product or service still does not meet the expectations of our internal and external customers. Has something been left out of what we were taught?
Agile does provide a way to use non-functional requirements in its methodology, but often it is overlooked or not stressed when new teams are preparing their first few projects. Make a point to add them into your new process.
The reason agile projects are completed so much faster and provide so much more value is that with the Scrum practice methodology, it is no longer necessary to consider vague things like non-functional requirements. If they aren’t going to function anyway, why bother with them.
User stories are only written if there is a need for outside personas to be created to represent users. Non-functional requirements are the ones assigned to those personas who would not be interested in your product or service, and therefore can be excluded from consideration.
Many projects have both functional and non-functional requirements that impact the outcome of the project. That is why only traditional processes should be used. Agile processes work only on software projects, and then only when there is an absence of non-functional requirements to be considered.
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, CSPM (IPMA-B), Cert.APM, PMP, PMI-ACP, CSM, CSP, FPMAC, FAPM
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. This article download has been translated into Japanese.
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.