If we are limited by the triple constraint, how do we as project managers lead with agility and embrace change? If projects are all about needs and values, then project management should be the tools and techniques to achieve this value. Is it time to redefine project management? Should we move away from the iron triangle to the value triangle?
Question: We are now part of a project that will use both an agile and a traditional waterfall team. As our British associates say, “It’s like chalk and cheese.” Is there a smart way we can work with this other group since none of our processes will match, none of the timing will be the same and, frankly, we each believe that the others are seriously misguided in having chosen their approach to project work?
There is a reason for the “chalk and cheese” expression. When you mix them you either forfeit a beautiful drawing or you miss a delightful appetizer. While multiple teams can work successfully on a common deliverable, it is vital that all teams are using exactly the same approach.
By now, 15 years after the meeting to create the Agile Manifesto, all teams should be aware that in today’s marketplace the only way to keep your organization competitive and protect your own job is to work in an exclusively agile environment. Most of the newsworthy business closings or serious curtailing of products are in industries that refuse to go agile.
It is not only possible for an agile team and a traditional team to work together successfully, it’s probably going to become the norm for more and more projects in the future. The secret it to understand where you can sync your work and where you need to use the parts of your preferred approach freely in order to have the best end outcomes.
While agile works situationally in software, the traditional methodology espoused by A Guide to the Project Management Body of Knowledge (PMBOK® Guide) has the advantage of a 55-year history. The knowledge amassed within that length of trial and error makes waterfall the preferred approach for all industries that want to make projects successful.
This series provides valuable information for the product owner community to use additional good practices in their projects. In each installment, we take one of the most commonly used visual models in agile and explain how to create one—and how to use one to help build, groom or elaborate your agile backlog. This is the last paper in this series and covers decision models, which include both decision trees and decision tables.
In this article, we will review the contentious topic of how the BA role varies and overlaps with the product owner role. We cover the similarities and differences, including danger signs (such as the “BA as PO Go-Between”) and positive patterns (such as the “BA as PO Supporter”).
Testing at the end of a development cycle is a common practice in traditional approaches. Unfortunately, it becomes an obstacle on your path to agility, slowing down your ability to deploy to production faster. Let’s take a look at what goes on in this testing phase, some potential causes and ideas for getting unstuck.
This series provides valuable information for the product owner community to use additional good practices in their projects. In each edition of this series, we take one of the most commonly used visual models in agile and explain how to create one—and how to use one to help build, groom or elaborate your agile backlog. This installment covers state models, which include both state diagrams and state tables.
Have you been thinking about getting your PMI Agile Certified Practitioner (PMI-ACP)® credential but are put off by the agile experience requirement? Fear not, you might have the experience you need even if you have not been working on a pure agile project. This article explores the prerequisites elements and explains what you need to qualify.
Agile self-organized teams come up with a wider variety of options and better solutions than you ever could alone. And there are a number of things you can do as an agile manager to help create the work environment for a self-organized team, be it co-located or distributed.
Agile approaches promote development teams comprised of generalizing specialists and seem to ignore the BA role. This begs the question: Do BAs have a role on agile projects? And if so, how do their functions change? This article examines their new role, what changes and what stays the same.
Following installments on the other four stated Scrum values (courage, focus, openness and commitment), this concluding entry focuses on respect. It offers techniques to scrutinize agile project management frameworks based on values, principles and practices.
If you adopt the agile approach, it will affect every aspect of your work. Learning it will be challenging for you, your team and your organization. The learning process will take months or even years; during this time, you still need to produce results. After 20 years of agile’s existence, do we know of a reliable, effective way of learning it?
To rise above the competition requires tenacity, veracity and intangibles that organizations need to respect, comprehend and practice. Business success is cultivated through sound project management practices, which include business rhythm, organizational intangibles, organizational development, project production, project delivery and a project management team. These key ingredients, when working together, guarantee project success.
This series provides valuable information for the product owner community to use additional good practices in their projects. In each installment in this series, we take one of the most commonly used visual models in agile and explain how to create one and how to use one to help build, groom or elaborate your agile backlog. This installment looks at business data diagrams.
Is agile the tsunami of change? Not necessarily, but the wave of change is coming to our profession. This practitioner warns that it won’t hit us like a waterfall—it will hit us like a tsunami. Will you be ready?
The agile approach needs to be understood thoroughly before it is introduced to a company. This explanation will give leadership the information they need for deciding if agile project execution is right for their organization by discussing key points including core framework, high-level benefits, and risks in the project-based environment.
When should you use waterfall and when should you use agile? The usual answer to this question is vague: Apply each approach according to circumstances. This article discusses the main positive and negative aspects of the waterfall and agile approaches, deconstructing some of the myths behind them and suggesting where one could be used over the other according to different factors.
This series provides valuable information for the product owner community to use additional good practices in their projects. In each installment in this series, we take one of the most commonly used visual models in agile and explain how to create one—and how to use one to help build, groom or elaborate your agile backlog. This edition looks at the business objectives model.
by Kevin Aguanno, CSPM (IPMA-B), Cert.APM, PMP, PMI-ACP, CSM, CSP, FPMAC, FAPM
For many, the concepts of agile are distinctly related to software development. But there has been a trend over the past 15 years of agile approaches taking root outside of software development and systems integration projects. Agile has not only appeared outside of its usual places, it has thrived in many of these new areas.
Today, roles have changed. As a project manager, you must keep your projects (and developers) on the right track. It doesn’t matter how many languages or platforms you know. This seasoned practitioner explores two different approaches and applies them to a complex IT scenario, looking at the best of both worlds.
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?
Most organizations struggle to engage their workforce to its potential. This is not through a lack of planning, technical skills or resources, but instead effective tools for dealing with typical project problems. Fortunately, agile practices hold many practical solutions for solving the classic five dysfunctions of a team.
This series provides valuable information for the product owner community to use additional good practices in their projects. In each installment, we take one of the most commonly used visual models in agile and explain how to create one--and how to use one to help build, groom or elaborate your agile backlog. This entry looks at the feature tree.
What does “scaling agile” mean to you? There are two ways to think about scaling: one is moving from one project to a program, the other is sharing agile across the business. Here we talk about moving from a one-team project to agile programs.
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.
Today’s project delivery environment is more complex than ever—more projects, more complex projects and more varied projects than ever before. Does this environment still lend itself to a single methodology? And if not, what should an organization’s approach be?
"Humanity has advanced, when it has advanced, not because it has been sober, responsible and cautious, but because it has been playful, rebellious and immature."