Tag Archive for: #agileprojectmanagement

You are here: / #agileprojectmanagement

Posts

Managing Change in an Agile Environment

/in /by

 

Photo by USGS on Unsplash

Some people might think agile project methodologies aren’t disciplined because things change a lot. Au contraire! Agile totally supports change control and management.

  • Agile methodologies are designed for change. The scope for an agile project isn’t fixed at the start. And, the project team expects changes with each iteration. Stakeholders add, drop, and change the priority of backlog items. Changes are made with the participation of technical and business stakeholders. Bottom line, instead of trying to eliminate change, agile approaches are designed to manage it effectively.
  • Reviews are key to agile. Agile approaches encourage continuous feedback from stakeholders, which identifies and addresses changes. Features are tested as they are developed. Desk reviews and consultation are at the heart of agile processes. And stakeholders get to continually review alternatives for feature builds. This encourages useful changes, so they aren’t major obstacles down the line.
  • Stakeholders recommend and collaboratively approve changes. It’s always important to make sure unapproved changes don’t find their way into projects. In agile methodologies, frequent collaborative sessions like scrum meetings ensure stakeholders concur with changes — so changes are made transparently and effectively.
  • Change is validated with agile, because it’s based on empirical learning. The basis of agile is that stakeholders will learn from early deliverables, which then generates pragmatic improvements to future deliverables. Features can be added, adjusted, or modified as the project unfolds. These changes come about from actual experience. Changes are recommended by the stakeholders who will use project deliverables.. As a result, it’s rare that any change requests are misinterpreted or create stakeholder adoption issues.

In essence, agile handles changes easily and supports sound change control and management. Stakeholders are involved through feedback and consultation. Changes aren’t made without approval. And those changes almost always help the business.

 

Are there other ways that agile supports change that I’ve missed? Do you have questions about change control and management in agile methodologies. Join the conversation in the comments section!

 

For more about change with agile, check out Christina Charenkova’s Managing Change in an Agile Environment course.

Coming Up

On March 20, 2023, at 12PM MT, I’m joining Angela Wick to talk about how project managers and business analysts work together. It’s going to be fun and informative. Bring your questions! To sign up, click this link.

_______________________________________

This article belongs to the Bonnie’s Project Pointers newsletter series, which has more than 30,000 subscribers. If you like this article, you can subscribe to receive notifications when a new article posts.

Want to learn more about the topics I talk about in these newsletters? Watch my courses in the LinkedIn Learning Library and tune into my LinkedIn Office Hours live broadcasts.

_______________________________________

 

Is Your Project a Good Candidate for Agile?

/in /by

Photo by Leon at Unsplash

Don’t force agile onto every project you run just because agile and iterative methodologies are “in.” To succeed with agile, make sure your projects are good agile candidates. Here are questions to ask before choosing an agile approach for a project:   

  • Is the project important enough to get the right people dedicated to it? Agile produces results quickly so it’s time-intensive for your team members. Agile teams are made up of business and technical folks who are vital to your business operations. Make sure they have enough time to contribute to your project. This often requires difficult tradeoffs between project work and operations.
  • Do your team members have sufficient depth and breadth of knowledge? What makes agile methodologies agile is responsiveness to evolving needs. Business experts work closely with expert technical team members to deliver what’s needed — fast. For that, your team needs in-depth knowledge of the business and technical areas touched by the project. The team consistently reassesses the project’s product, macro and micro-level business needs, and function priority.
  • Does your sponsor have an agile mindset? Agile responsiveness to changing business conditions and its learning environment are very different from traditional project methods. Your sponsor must be comfortable with changing business needs and priorities, willing to participate in frequent reviews of the evolving product, and ready to step in to get the project the agile resources it needs.
  • Can your team be co-located or virtually co-located? Agile involves deep, interactive, and often challenging dialog, which requires the richest environment you can create. Co-locate your project team members if possible. If you can’t, simulate co-location with the best video and audio tools you can obtain.
  • Is there synergy between your business and technical team member? Agile requires dedication from business and technical experts who are open to new ideas and supporting each other. You need an agile coach who understands and can manage human dynamics, and who can foster an environment where team members readily share their ideas and concerns. An agile team has to get along well to be successful. 
  • Can the product be built iteratively? Agile’s best qualities come from delivering solutions in pieces while learning from each iteration. Although it’s most common with software products, other products can be produced this way, too. With a bit of creativity, facility moves, process implementations, and even some construction projects can be produced in iterative steps.

For more about agile methodolgies, check out the Become an Agile Project Manager learning path in the LinkedIn learning library.

Coming Up

Tatiana Kolovou and I will host a LinkedIn Office Hours session about communication on September 30 at 1pm MT.  Watch for more details in my LinkedIn feed.

__________________________________________________________________________

Want to learn more about topics like these? Watch my courses in the LinkedIn Learning Library and tune into my LinkedIn Office Hours live broadcasts.

Managing change in agile projects

/in /by

A learner in my LinkedIn Learning online project management course asked, “Is it true that agile methodologies don’t require change management to handle new requests?” Actually, change management is baked into the Agile approach. Here is how Agile manages change using the terminology of traditional project methodologies. 

There is a Change Control Board. In Agile, the team plays the role of the Change Control Board. When features are being developed and improvements are suggested, the team accepts or rejects them. When new features are proposed, the team determines whether they will be included in the product backlog. Like a traditional project approach, the team consists of both technical and business team members, so appropriate backgrounds come together to make change-related decisions. 

Change requests are received and evaluated. During each sprint, the team examines the work in progress and discusses improvements. This serves the same purpose as the submission and evaluation of change requests in traditional methodologies. Similarly, when additional features are added to the backlog, the team examines and prioritizes them. If the team prioritizes them to be completed within the project’s schedule and budget constraints, the features are delivered. 

The impacts of change are assessed. When a new feature is accepted, sized, added to the backlog plan and prioritized, the impacts on time and scope are evaluated. Sizing the feature describes the impact to cost. Adding the feature to the backlog changes the scope. If no features are removed when the new feature is added, then the scope is increased. If another feature is removed when the new feature is added because of time and/or cost considerations, that means the scope is managed according to the business value. 

Change requests are resolved and communicated. Features that are developed come from the backlog. Any feature added to the backlog during sprint cycles is the equivalent of a change. Delivery of that feature is essentially the same as resolving a change request. Communication of change resolution occurs through the backlog status boards, iteration plans and release plans.

For more about Agile projects, check out the LinkedIn Learning Agile learning path.