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.

_______________________________________

 

The Importance of Testing Plans

/in /by

Testing is often an underdeveloped part of project plans. Here are circumstances that make solid testing plans critical:

Uncharted territory. If your project is delivering a product new to your company, risk increases. To address this risk, testing should include reviews throughout the project life-cycle.

Interface complexity. As interface volume and complexity increases, so does your need for rigorous testing. In your testing plan, consider impacts to people, processes, and technology from all interfaces.

Vendor touchpoints. Integrating vendor products means more interfaces with increased complexity. Expand your normal testing rigor when vendor products are involved. Increase your testing regime with vendor products. Test all assumptions. Create a data dictionary and confirm compliance with its contents.

For more on testing, watch this LinkedIn Learning testing course.

 

Identifying the right people to provide requirements

/in /by

Having the right resources to identify requirements gets your project off to a great start.  Here are 4 steps that can help:

  • Identity the right stakeholder groups. Identify the various stakeholder groups that will be impacted by the new product or solution. Which ones are right? The ones that will be impacted by the new solution or product. These can include internal departments and external entities such as vendors, customers and consumers. Don’t forget groups such as IT support, Legal, Procurement, Finance, Safety, Security, and Compliance.
  • Acquire the right domain expertise. Ensure all representatives have appropriate domain knowledge for the stakeholder group they represent. If not, push back to get ones who do. Ideally, getting at least two representatives from each domain helps you obtain broader perspectives.
  • Confirm resource availability. The best resources are rarely idle. Negotiate with the appropriate manager to obtain the right resources by explaining the value of requirements identification.  Design the requirements identification process to maximize the value obtained from these critical resources in the least about of time.
  • Attitude matters. The right attitude is essential. Work with your designated representatives to get them excited about participating in the requirements process. Emphasize how they can influence business outcomes for the area they represent.

With the right people are engaged in the requirements identification process, you can greatly increase your chances of achieving the desired business outcomes.

For more info on requirements, check out this LinkedIn Learning course

The Right Way to Fast-track or Crash Your Project

/in /by

Fast-tracking means scheduling tasks in parallel when possible. Crashing is adding people or spending money to complete work earlier. Don’t be overly ambitious with these techniques. Here are some dos and don’ts for fast-tracking and crashing:

Do look for opportunities to fast-track or crash. These strategies can shorten the schedule, but also add risk — so make sure they’re worth it.  Fast-tracking increases the risk of rework because products developed in parallel might not integrate. Crashing increases cost, because you must obtain and coordinate additional resources. 

Do add review tasks after fast-tracking. Adding review time lenthens your schedule, but not as much as you save by fast-tracking.  Reviews mitigate the integration risk of fast-tracking. Team members who work on parallel tasks should conduct joint reviews to ensure products are compatible. 

Do use skilled resources to crash your tasks. Adding skilled team members can improve the quality of the product and save time.

Don’t add marginal skills to tasks you’re crashing. Lack of skill creates more overhead – ensure you have capable people. Also, limit the number of people on crashed tasks. Too many people get in each other’s way, wasting time and money.

Don’t compromise project integrity by fast-tracking testing. Testing tasks should be exempt from fast-tracking. Testing evaluates the appropriateness of your products. You can’t conduct high-integrity tests while product development is still in progress. If you do that, you’ll need additional regression testing, which negates the fast-tracking time savings.

Don’t apply both fast-tracking and crashing to the same tasks. This increases risk dramatically and is rarely successful. I call this “fast-crashing,” because, like a car accident, you can’t help but look, though the results aren’t pretty.  

For more on these techniques, watch my LinkedIn scheduling course