Lean thinking involves focusing on delivering the most value from a customer perspective, while reducing waste and fully utilizing the skills and knowledge of those doing the work. These are all relevant goals for today’s PMO, and the reason that organizations are increasingly using lean thinking to boost value and reduce waste in the PMO.
Connect In Person
New technologies, hybrid projects, the launch of a PMO—when the environment is constantly changing, how do you craft a schedule (or multiple schedules) for project success? Discover timely answers here—and only here—at the PMI Scheduling Conference 2017, exclusively for PMI members.
Advance your BA skills. Earn PDUs and more—all for free. Don’t miss the most popular Business Analysis event of the year! Over 13,000 attend. Registration is FREE. We’re sharing career journeys and talking about the hottest BA and agile BA topics. Register now to attend the only event designed with your future in mind to help you get ahead.
Is Your Agile Transformation Set up to Fail? Find out at the PMI® Organizational Agility Conference 2016, FREE and Exclusive for PMI Members. We know there are barriers that slow your organization’s ability to be agile: failed agile transformations, complex organizational processes, team dynamics and the uncertain role of the PMO in an agile environment (just to name a few). Attend the PMI Organizational Agility Conference 2016 to get help breaking down these barriers. It’s free for PMI Members.
Through this session we'll dig deeper into the Business Agility Health radar and discover the 4 critical elements needed for designing successful business agility transformations.
In this webinar, we’ll go through what the issues are when transitioning to an Agile mindset, how they present themselves and what you can do as a Project Manager to think ‘more agile’ in your projects whilst accepting and learning along the way.
In case you actually read this description, the beginning of the blog is about preparing for the PMP exam. It then evolved into maintaining my credential. After taking a break for a few years, I'm back and will be blogging about project management, in general, and probably a bit of agile on a regular basis.
The Agility Series focuses on agile and agility across the organization not just in software and product development. Areas of agility that will be covered in blog posts will include: - Organizational Agility - Leadership Agility - Strategic Agility - Value Agility - Delivery Agility - Business Agility - Cultural Agility - Client Agility - Learning Agility
This blog is a conversation between the Agile Practice Guide Team and our PMI and Agile Alliance Communities to gain insight, support and collaboration around the creation of a usable and relevant body of work that supports transition to hybrid and agile in project work.
Save Time With Tools + Templates
The Risk Management Grid is a technique to identify potential risk events that could impact one of more of the project’s Seven Win Conditions. Importantly, it also serves to decide how those events will be prevented or mitigated.
The Three-Sentence Project Skinny is a concise summary of the purpose of the project. It addresses the what and the why.
You can't do everything, nor should you. This template helps you figure out what is in and what is out of your project.
These are the do-or-die, must-meet requirements in order for the project to be considered a success. As such, they are continuously focused on by the project manager and core team.
Win Conditions address how success will be measured. How do you stack up when it comes to stakeholder satisfaction, your schedule, scope, quality, budget, ROI and team satisfaction? This template helps you rank priorities, and provides areas for metrics and descriptions.
Learn From Others
When companies move to an agile Software Development Lifecycle (SDLC), they often remove the processes and analysis of their waterfall SDLC because, as the Agile Manifesto puts it, “They value individual and interactions over processes and tools.” Some of the rigor should be removed – waterfall processes can get bogged down with gates and sign-offs. However, caution must be exercised to not go too far against processes and analysis and rely just upon backlogs and user stories. Requirements and the analysis that leads to those requirements are just as essential in an agile project as they are in a waterfall project. The difference lies in how much requirements analysis is completed and the timing of it.
Not every project involves teams with high levels of project execution experience. When low experience levels collide with agile, we need to be aware of the implications.
|A.||Since agile was conceived in 2001 in Snowbird, Utah, it is 100% American in origin. The rest of the world had never tried these practices until the results of this famous meeting were released through a series of speeches, articles and conversations.|
|B.||Agile principles rest on the behaviors Douglas McGregor believed to be basic to most workers, called Theory X. Because it suggests that people dislike work and try to avoid it, the more lax workplace of an agile team tricks them into thinking they are in management.|
|C.||Dr. W. Edwards Deming developed the earliest agile-like philosophy, which he called the Hierarchy of Needs. If a manager can meet all of the needs for the employee, productivity will soar. If even one is left unfulfilled, project outcomes will be subpar.|
|D.||Agile actually is an outgrown of the Japanese motivational theories of Dr. William Ouchi’s “Japanese Management” style from the 1980s. By now, the concepts have been well tested and proven to be effective in the modern-day workplace, first in Japan and then in other locations around the globe.|
It seems as if the larger the agile program, the bigger the planning--but that kind of planning only works for some programs. What can you do? Instead of big discontinuous planning, consider small continuous planning.
If you ask a group of individuals what benefits they expect to achieve by adopting agile methods, you’ll usually hear “faster delivery,” “higher quality,” “cheaper” and “lower risk.” Out of these, “faster” is the most common. Faster delivery can be elusive; the benefit of “cheaper,” however, may be illusory.
The use of traditional empirical project management tools can be used in a simple way to manage and control project deadlines and costs without losing the flexibility of agility. In this article, we are going to mix a traditional technique with agile management using a simple practical example.
The webinar Dude, Where’s My Control?! Transitioning from a Project Manager to a Scrum Master was packed with information, and here the presenter covers some questions and answers that came out of that session.
The words “agile project management” are being used in the industry to describe a new approach to how project management is conducted. The industry and company leaders need to fully understand how project managers can be brought into the agile world to ensure cohesion between these two disciplines.
"Hybrid agile" sounds like a great middle ground between our established ways of doing things and trendy agile methodologies. We keep our current employees happy since they won’t need to abandon their old skills and habits. The only problem? It doesn't exist.
A more nuanced approach to agile and waterfall has started gaining traction. Once referred to as “structured agile,” more practitioners are combining both methodologies. This article provides a framework for how ScrumMasters and project managers can work together using hybrid principles.
The approach to scope changes used within the agile/Scrum framework provides a stable environment so the development team can focus on getting work “done.” Frequent feedback about the product allows for less upfront planning and means the Scrum team can quickly adapt to changes. Delivering business value early and often results in increased customer satisfaction.
Agile is all about managing change, but every organization has a different rate of change. We generally think about agile as removing impediments to accelerate development and keep up with change. It also has an important role to play in placing constraints on change so that it doesn’t spin out of control. This article is a case study of how too much change can lower quality and lead to products that completely miss the mark.
|A.||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.|
|B.||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.|
|C.||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.|
|D.||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.|
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?
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.
Organizations who are now embarking on agile adoption are feeling pressure to “catch up” with their competitors. But when “late adopters” of agile try to make up for lost time, it can cause problems.
Ask a Question