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.
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?
All agile frameworks may be examined in terms of core values. This third entry in a five-part series continues to explore agile frameworks from the vantage point of values, principles and practices. Agile’s Scrum framework in particular espouses five values: courage, focus, openness, respect and commitment. This offering looks at the value of openness to bring principles and practices into better relief.
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. The first in this series is the process flow.
Do you know what expertise you need now, as you enter into an agile development environment? Unfortunately, we use the same word (“testing”) in agile, but it means something different from what you have seen and managed in prior non-agile projects. If your testers are writing test cases, tracking testing progress and recording bugs in a separate defect tracking system, stop now; you are using the wrong people to do the wrong thing.
Question: Ah, the dreaded new boss! This organization works through other vendors to deliver our international training services. My team reviews them for longevity, education and certification of instructors, stability of organizational structure, quality and content of their materials, publicity and webpage honesty, and similar traits found in a high-value partner. The new boss has no background or understanding of our industry or training in general, and immediately wants to impose strict metrics to evaluate my team and me. This doesn’t seem like a good idea. Am I missing something?
Metrics or concrete, short-term data about the performance of each person working for an organization are crucial to make sure that team members are not slacking off and occupying a position someone else could use to bring the company more value.
The new boss is trying to make his or her mark by introducing the new metrics to have something concrete to show. These statistics will prove to not be a good idea over time, so let the organization figure it out for itself. Collecting them is the equivalent of the lion’s roar to mark this territory to all within earshot.
Only people who are fearful of what the data will show will object to having it collected, formed into charts and submitted to management. In fact, since you know what is being gathered you can change your daily performance to be sure you look good in these new metrics regardless of whether or not it is the best use of your time.
An organization should look at the need for and value received from any metrics gathered and used. Unless they are collecting data that is meaningful and will lead to better results, they are a waste of company time and resources, may be misleading and may be discouraging for the team.
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.
Agile approaches do not have risk management approaches built in as standard; they have the integration points, but not the steps required. Fortunately, with a little effort, we can fill those gaps and equip teams with the skills they need to address risks and opportunities effectively.
Question: After being team lead for our Customer Operations business unit transformation project, I’ve been offered a position to head the new department. It will now also include Information Technology (IT). Here’s my issue up front: I’m a traditional project manager and now I’ll have nine business analysts and an agile IT team to lead. Who is responsible for what on projects now? I need to figure this out fast.
Business analysts replace project managers, so once you assign a BA to a project, your work is over. All you will need to do is help referee the conflicts between the BAs and the IT teams.
If your business analysts are trained and certified, they’ll know their own roles or can adjust quickly to what you want them to do. The agile IT team should be fairly self-directed. All you need to understand is who does what, present the responsibility chart and stand back ready to support them if needed.
Agile teams do not need any supervision or direction over and above their own ScrumMaster, who is 100% devoted to one project at a time. Ask your BAs if they will cross-train as ScrumMasters to maximize the number of projects you can run at any one time.
Due to the new strategic and business requirements from PMI, project managers have now been renamed. Just have your newly christened business analysts do what project managers have always done.
This is the first 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.
With over a decade of working with cross-organizational and cross-geographical teams, this practitioner has found that “invitation” is a powerful yet little utilized technique to encourage team self-management. And self-management is not a nice-to-have, it is absolutely critical.
In the last year or so, this practitioner has seen an increasing number of project management job postings asking for agile experience. What’s driving this trend? Is this something project managers need to be aware of when considering their career development?
The purpose of this article is to guide project managers in implementing an earned value management system by following ANSI/EIA-748 guidelines in a manner consistent with agile software development methodology.
by Kevin Aguanno, CSPM (IPMA-B), Cert.APM, PMP, PMI-ACP, CSM, CSP, FPMAC, FAPM
Agile encourages project teams to work with the sponsor to understand the greater context surrounding the project. With this broader understanding, the team can look for ways of structuring the project to improve the chances that the business will actually achieve the business case benefits.
Project management tools are getting more and more sophisticated as they compete with rivals on features and spread to support more platforms. Yet sophistication has a cost. Let's explore how a combination of deliberately low-tech inputs and outputs can be used with modern tools to deliver the best of both worlds.
When teams transition to agile development and the QA/testers continue to follow the same testing processes and tools they used before joining the agile team, you're asking for trouble. In this article, we contrast agile and traditional testing--and give an example of how a mind map can facilitate the testing process.