Category: Agile

Posted on by

Agile vs Waterfall vs Hybrid – choosing the right approach for your content

Woman working on project management compliance process

Few questions generate more debate in project management circles than this: should we use agile or waterfall?

And while the debate is often framed as a simple binary choice, the reality facing most project managers today is considerably more nuanced. Most organizations operate across a spectrum of delivery approaches — running some projects in a highly structured, predictive way; others in fast, iterative agile cycles; and many in a hybrid of both.

Understanding the strengths and limitations of each approach, and knowing how to choose the right one for a given context, is one of the most valuable skills a project manager can possess.

Understanding Waterfall (Predictive) Project Management

The waterfall — or predictive — approach to project management involves planning the full scope of work upfront and executing it in a series of sequential phases: initiation, planning, execution, monitoring and control, and closure.

This approach assumes that requirements can be defined clearly at the beginning of a project and that change, once work has begun, is undesirable and costly. It prioritizes comprehensive planning, detailed documentation, and rigorous change control.

When waterfall works well:

  • Requirements are well-understood and unlikely to change significantly
  • Regulatory or compliance requirements demand comprehensive documentation
  • The project involves physical deliverables (construction, manufacturing) where sequential phases are inherent
  • Contractual or procurement structures require fixed scope and price
  • Stakeholders prefer detailed upfront plans and formal approvals

Typical industries: Construction, engineering, infrastructure, defense, government, regulated industries

Limitations:

  • Less responsive to changing requirements
  • Value is only delivered at the end of the project
  • Problems are often discovered late, when they are more expensive to fix
  • Can create excessive bureaucracy and administrative overhead

Understanding Agile Project Management

Agile approaches are based on iterative, incremental delivery. Rather than planning everything upfront and delivering at the end, agile teams break work into short cycles (sprints or iterations), deliver working outputs frequently, and continuously adapt their plans based on feedback and changing circumstances.

The Agile Manifesto’s four core values — prioritising people over processes, working deliverables over documentation, collaboration over contract negotiation, and response to change over following a plan — underpin all agile frameworks.

When agile works well:

  • Requirements are evolving or not yet fully understood
  • Speed to market and early delivery of value are priorities
  • The project involves complex problem-solving where upfront planning is impractical
  • Stakeholders are available and willing to engage regularly in shaping the product
  • The team is empowered to make decisions and self-organise
  • Innovation and experimentation are valued

Common agile frameworks: Scrum, Kanban, SAFe, LeSS, DSDM, XP

Limitations:

  • Requires high levels of stakeholder engagement that not all organisations can sustain
  • Documentation may be less comprehensive, which can be problematic in regulated environments
  • Can be challenging to implement on fixed-scope, fixed-price contracts
  • Scaling agile across large, complex programmes is non-trivial

Understanding Hybrid Project Management

Hybrid project management blends elements of both predictive and agile approaches to create a delivery model that suits the specific needs of a project, team, or organization.

Hybrid approaches recognize that few real-world projects are perfectly suited to a pure agile or pure waterfall model. Most involve some elements of both — perhaps a structured project initiation and governance framework combined with iterative, agile delivery within that structure.

Common hybrid patterns:

  • Waterfall at the programme or portfolio level, agile at the project or team level
  • Agile delivery of software components within a waterfall infrastructure project
  • Fixed scope and price contract (waterfall) with agile internal execution
  • Structured initiation and closure phases with agile middle phases

When hybrid works well:

  • Large, complex programmes with multiple delivery tracks operating at different speeds
  • Organisations transitioning from waterfall to agile who need a managed evolution
  • Projects where some elements are well-defined (waterfall) and others are exploratory (agile)
  • Environments where governance and compliance requirements coexist with the need for speed and adaptability

How to Choose the Right Approach

The right methodology for any project depends on a careful analysis of several factors:

Requirement Clarity

How well-defined are the requirements? If they are clear and stable, waterfall may be appropriate. If they are evolving or uncertain, agile offers more flexibility.

Rate of Change

How likely are requirements to change during the project? High volatility favours agile; low volatility makes waterfall more practical.

Stakeholder Availability

Agile requires active, ongoing stakeholder engagement. If key stakeholders are not available to participate regularly in reviews and backlog refinement, a more structured approach may be needed.

Regulatory Environment

Regulated industries often require comprehensive documentation and formal approval gates that are more naturally aligned with waterfall or hybrid approaches.

Team Experience and Mindset

Agile works best with empowered, self-organizing teams that are comfortable with ambiguity. Teams accustomed to detailed instructions and hierarchical decision-making may struggle with the autonomy agile requires.

Delivery Urgency

If early, partial delivery of value is important — getting something to users quickly and learning from it — agile’s incremental approach is advantageous. If the value can only be realised when the full product is complete, this advantage diminishes.

Why Methodological Fluency Matters

The most valuable project managers today are not advocates for a single methodology. They are methodologically fluent — equipped with the knowledge and experience to assess a given context and select, adapt, or blend the approach that is most likely to lead to successful delivery.

This fluency is precisely what the PMP (which covers predictive, agile, and hybrid approaches) and the PMI-ACP (which focuses specifically on agile) are designed to develop and validate.

How RMC Learning Solutions Develops Methodological Fluency

Our training programmes for the PMP and PMI-ACP are designed to develop not just exam-ready knowledge, but genuine methodological fluency — the ability to think clearly about delivery approaches and make sound choices in complex, real-world environments.

Explore our training programs and develop the versatility that modern project management demands.

Published by RMC Learning Solutions — Preparing Project Managers for Success Since 1991.

Posted on by

Hybrid agile models: customizing agile to scale across complex enterprises

Business man taking notes on risk management

As Agile continues to expand in scope, organizations are increasingly adopting hybrid models that blend Agile with other methodologies, such as Lean, DevOps, and Design Thinking. These hybrid models allow businesses to scale Agile across complex and diverse environments, offering greater customization and flexibility based on departmental needs. In this blog, we will explore how hybrid Agile models work, why they are becoming essential for large enterprises, and what leaders can do to effectively manage the integration of multiple methodologies.

Why hybrid models are the Future of Agile

While traditional Agile methodologies work well for smaller teams, larger organizations with diverse functions require greater flexibility. Hybrid models allow companies to combine the best aspects of Agile with other frameworks like Lean and DevOps to create a more customized approach. For example, a company might use Lean principles to eliminate waste and improve efficiency while simultaneously applying Agile methodologies to manage product development teams.

By adopting a hybrid model, businesses can scale Agile across different departments, such as marketing, HR, or operations, while addressing the unique challenges and requirements of each. This customization ensures that each team has the right tools and practices to drive success, without a one-size-fits-all approach.

Implementing Hybrid Agile Models: what senior leaders need to know

For senior leaders, managing hybrid Agile models requires understanding the nuances of various methodologies and how they can be integrated effectively. This involves:

  • Customization: Selecting the right tools and practices for each team based on their specific needs.
  • Training: Ensuring teams are well-versed in multiple methodologies to seamlessly switch between them when needed.
  • Collaboration: Encouraging cross-functional collaboration to ensure that Agile, Lean, and DevOps practices work harmoniously.

Leaders must also be prepared to invest in continuous learning and development to ensure their teams can adapt to evolving practices. This focus on learning will help organizations maintain alignment with business objectives while remaining flexible and responsive to market conditions.

Key takeaways:

  • Hybrid Agile models combine multiple methodologies to address the unique challenges of larger organizations.
  • Senior leaders must prioritize customization, training, and collaboration to ensure successful integration of hybrid models.
  • Continuous learning and adaptation are critical for maintaining the effectiveness of hybrid Agile models.
Posted on by

Master agile techniques with this webinar

Agile methods have fundamentally changed how project management is approached, focusing on adaptability, efficiency, and collaboration. This webinar provides a thorough introduction to agile techniques, making it an excellent resource for anyone aiming to improve their project management strategies. Agile promotes a flexible framework that allows teams to respond quickly to changes, making it particularly effective in fast-paced environments.

Throughout the session, you’ll discover how agile principles prioritize delivering value by breaking projects down into smaller, manageable segments. This approach not only facilitates continuous improvement but also ensures that teams can pivot as necessary to meet evolving project requirements. 

The webinar also covers the core components of agile, including sprints, stand-ups, and retrospectives, offering a practical guide to integrating these elements into your workflow. By focusing on iterative progress and regular feedback, agile encourages ongoing learning and adaptation, making it easier to align project outcomes with client expectations.

Additionally, you’ll gain insights into creating a supportive and collaborative team culture, essential for the successful implementation of agile methods. This session aims to equip you with the knowledge and tools needed to make agile work for your team, fostering a more productive and responsive project management environment.

Challenges tackled in the webinar

A consistent challenge is resistance to change, as team members may be more comfortable with traditional processes. This can hinder the initial transition to agile practices. Another hurdle is ensuring effective communication, which is crucial for aligning diverse team members towards a shared goal. Additionally, teams often struggle with maintaining productivity during the shift to agile, as the new methods may initially feel unfamiliar and disruptive.

To help overcome these challenges, the webinar emphasizes the importance of fostering an open and supportive team culture. Encouraging team members to voice their concerns and share ideas can ease the transition and build trust. The session also highlights the benefits of regular team meetings to keep everyone informed and aligned. Using collaborative tools can further enhance communication and help streamline workflows.

By addressing these common hurdles, the webinar aims to equip teams with practical strategies to facilitate a smoother transition to agile. It underscores the significance of patience and persistence, as adjusting to agile methods can take time. With the right approach and mindset, teams can overcome these initial challenges and fully reap the benefits of agile practices.

Adopting agile practices

Adopting agile practices begins with a comprehensive understanding of agile principles and how they differ from traditional methods. Start by educating your team on these principles to create a shared foundation of knowledge. Identifying areas where agile can be most impactful helps in tailoring your approach to meet specific needs.

To ease into agile, consider starting with a small pilot project. This allows your team to get accustomed to the new methods gradually without feeling overwhelmed. Clear communication is essential throughout this transition. Setting realistic expectations and encouraging open dialogue can significantly help in managing the shift.

Encourage regular feedback from your team and be open to making adjustments based on their input. This helps create a culture of continuous improvement and adaptability. Celebrating small victories along the way can keep the team motivated and committed to the agile journey.

Utilizing collaborative tools can streamline workflows and enhance communication, making the transition smoother. These tools can help in tracking progress, managing tasks, and keeping everyone aligned with the project goals. With a thoughtful approach and supportive environment, your team can successfully adopt agile practices, leading to improved productivity and more efficient project management.

Advantages of agile for teams

Agile methods offer a range of benefits that significantly boost team performance. One standout advantage is enhanced collaboration. By fostering regular communication and feedback, agile methods help break down barriers between team members, encouraging a cooperative spirit. This collaborative atmosphere leads to improved problem-solving and innovative solutions.

Agile also supports faster project completion. Its iterative nature allows teams to deliver small, manageable portions of the project incrementally. This approach not only speeds up releases but also ensures the team can swiftly adapt to any changes. This speed and flexibility help align the final product with client needs and market demands more effectively, allowing teams to deliver high-quality work promptly.

Additionally, agile promotes continuous improvement through regular retrospectives. These sessions allow the team to reflect on their processes, identify areas for enhancement, and implement changes promptly. This ongoing refinement helps maintain a high standard of work and keeps the team motivated.

Another key benefit is the ability to manage risks more effectively. By breaking projects into smaller segments, potential issues are identified and addressed earlier in the process. This proactive problem-solving reduces the likelihood of significant setbacks, making project management smoother and more efficient.

Finally, agile methods contribute to higher job satisfaction. By involving team members in decision-making and valuing their input, agile creates an inclusive environment that boosts morale and encourages a sense of ownership and commitment.

Major insights from the webinar

This webinar brings to light several essential skills for mastering agile techniques. A key takeaway is the importance of adaptability, allowing team members to navigate changing project requirements with ease. Effective communication also stands out as crucial, ensuring that everyone is aligned and working towards shared objectives.

Real-world examples from diverse industries demonstrate how agile practices can significantly boost efficiency and innovation. These case studies provide practical insights, showing how teams across various sectors have successfully implemented agile methods to meet their goals.

The webinar also underscores the value of regular feedback and continuous improvement. Through consistent review and reflection, teams can identify areas for enhancement and implement changes quickly. This fosters a culture of ongoing learning and development, essential for long-term success.

Lastly, the session highlights the significance of fostering a collaborative team environment. Encouraging openness and support within the team not only makes the transition to agile smoother but also builds trust and enhances overall productivity. With these insights, you can better equip your team to embrace agile techniques and achieve more effective project management.

Posted on by

Satisfying Stakeholders with Agile Requirements

People in stakeholder meeting about agile requirements

Traditional approaches to detailed requirements documents are being modified to accommodate faster, more lightweight communication methods. Business analysts must adjust their work styles and deliverables to fit into project development life cycles and methods.

As part of the process, it is important to understand if agile requirements differ from plan-driven requirements.  It’s also good to know if a mind shift is required to develop successful requirements.

Agile Requirements

  1. How Do Agile and Traditional Requirements Differ?
  2. Shift in Mindset for Agile Requirements
  3. Tips for Creating Successful Agile Requirements

How Do Agile and Traditional Requirements Differ?

Agile requirements are not as different as you would expect. In a traditional environment, BA’s create detailed requirements.  In an agile environment, the documentation becomes a lot less important.  Most of the tools and analysis techniques that BAs have in their tool kit are still valuable and applicable in agile.  In fact, having an assortment of different tools to analyze is powerful.

As analysts, it is important to be aware of how a product or service will be used. You must also know the environment the product is expected to function in. This understanding comes from doing the analysis. You can still use techniques like swim lanes, workflow documents and process models to define the value.  The difference with agile is those insights can be documented at a high level using general sketches or holding a workshop to define information on a whiteboard. The requirements documentation must be sufficient to create a shared understanding for team.

Shift in Mindset for Agile Requirements

In agile you still document your requirements, but you may document them differently using post it notes on a wall, or on a flip chart with a picture of the flip chart to share with others not in the room. In other words, think about the way you document requirements in more creative ways.  You want to retain the analytical and thinking processes, including elicitation, and collaboration.   Importantly, it is not about NO documentation, it’s about AVOIDING overly detailed documentation.

If you get push back on the level of documentation within your organization, consider asking questions as to why documentation is needed to ensure what you are producing serves the needs of the company and the project. This will help organizations let go of old habits and intentionally reduce the rigor in the requirements to bring value to the organization.

Tips for Creating Successful Agile Requirements

Here are some helpful tips to try as you document agile requirements.

  1. Agile requirements don’t need to be perfect

The key to success is agile requirements and documentation should be barely sufficient.   Your requirements do not need to be perfect.  Do just enough to meet the need and create a shared understanding.  Force yourself to let go of perfectionism when it doesn’t add sufficient value. Remind yourself as you work, is this the best use of your time.  It will help you step back and evaluate key tasks and outputs to deliver value.

  1. Understand the timing

In an agile environment, how do you deal with completed requirements at the last responsible moment?  This doesn’t mean procrastinate. What it really means is, if you define some things too early in the process, the requirements will have to change, requiring unnecessary rework.

For example, if you create detailed models of what the product will look like before you know exactly where each feature is going to fall in the release plan, you may have designed something that isn’t needed until the last release if ever. In that time, some elements will have likely changed. The idea of letting things fall into place at the last responsible moment is a great time saver.  In the meantime, you can still be creating smaller increments of value that the team can consume. Knowing what can benefit from waiting allows you to learn along the way and gain more information and perspective.

  1. Define a process to document ideas

Have an organization system for future ideas.  It’s an excellent way to capture a thought that might not be ready to explore and develop.  If you have documented the idea or an important finding at the time, you can come back to it when it may be more appropriate or beneficial.  The other benefit is that you won’t have to start from scratch. One way to keep track of these ideas is to write them down on a future date in your calendar to keep the idea of top of mind.

  1. Balancing the high level and the details

Knowing when to focus on the high level and when to get into the details is a constant challenge of a business analyst.  When working on an agile project, in the early stages when you are doing product visioning, you need to focus on a high level.

However, there are times when a topic will come up and you must let the team talk at a detailed level to make sure everyone is understanding the vision and goals in the same way.  An idea may surface, and the team needs to go deeper into the details to determine it if the idea should be a part of the vision.

Over the course of a project, you will cycle through guiding the team through the details and then back to the high level to align with the larger project vision and objectives.  Don’t be afraid to go deep when the team needs to so that everyone feels comfortable there is a plan that will work and a shared understanding of the product or service features.

  1. Be nimble

In agile projects, analysis requires you to define work slightly ahead of the development team.  You need to be able to continuously get more detail about the business needs and desired requirements.  At the same time as you are working ahead, you need to be able to respond to a change in the current iteration to help the development team adjust and prioritize.

Developing agile requirements means you have to be open and nimble to keep the present iteration moving while planning for the next set of work.

Still Interested in Developing Effective Requirements?

To help you adjust your analysis practices to a more agile style, RMC offers a case study-based course teaching professionals working on agile teams to develop effective agile requirements.

Contact us about this two-day, virtual session to learn how you can become nimbler while continuing to satisfy stakeholder needs on your next project.

You can also listen to my podcast with Dave Saboe.

Sources:https://www.batimes.com/articles/agile-requirements-documentation-what-s-really-needed

Posted on by

How to Choose a Project Management Methodology?

Close up of two business people talking about project management methodologies

While attending an Agile conference, I heard a lot of discussion about the types of project management methodology from pure agile teams, waterfall teams, and a combination of the two. Several presenters stressed the importance of being a 100% dedicated agile team. They stated that the only way to be successful is to make sure your team or company follows the Scrum/Kanban/XP/etc. methodology in its purest form. Other presenters called out these statements as false and went on to discuss numerous examples of blended approaches that have worked at their company or with their clients.

How can an organization trying to understand agile figure out the best approach when so many experts in the field have different opinions?

Best Project Management Methodologies

  1. Project Structure
  2. What About a Blended Approach?
  3. Benefits of an Adaptive Approach
  4. Choose the Methodology that Works Best for your Organization
  5. Sharpen Your Agile and Hybrid Skills Sets

Project Structure

If we, as an organization, want our projects to be more successful in our customers’ eyes, we need to start asking the right questions.  How do we create a project structure that works for our current environment, team, and clientele? Is this a product we need to get to market faster? How can we get our stakeholders/customers more involved? What really defines success?

In today’s environment, many organizations are trying to figure out how to be more “agile” or adaptable. Many organizations are transitioning to the agile approach, kicking off agile pilots, and having great success. Wonderful! But just as many are failing. This is why I’m suggesting that we need to ask the right questions to determine what will be successful within our organizations. What really is the best approach for our environment, on a particular product or project?

What About a Blended Agile Approach?

It is possible to blend agile and traditional project management practices together in the right proportions to fit your project and environment. Blending some of the structure of traditional project management with the fluidity of agile can be quite liberating. I have seen this type of approach work in organizations where there’s resistance to agile among the leaders and mid-management. Leadership support is key when making any type of organizational transition.

Change is very scary to many individuals. It is easier for leaders to buy in to agile practices when the project team is asking, not to throw out all the current processes (which usually have been in place for ten or more years), but to blend the approaches in a way that means more value, quicker release to market, and more satisfied customers and employees.

Benefits of an Adaptive Approach

If you are interested in taking more of an iterative and adaptive approach to project management, consider the following key points:

  • Collaborate daily with your key stakeholders.  Communication is critical. Consistent collaboration with your key stakeholders can only make your project more successful. Increased visibility is never a bad thing, and it enhances your ability to succeed on the next three items.
  • Emphasize maximizing business value. How can we get to the market more quickly with a minimal viable product?
  • Reduce unnecessary documentation. Using an agile approach does not mean there’s no documentation, but there is less documentation than in traditional project management. Figure out what level of documentation is necessary to ensure your leaders, team members, and customers feel comfortable.
  • Be more adaptive to change. Customers tell us they know what they want, but they discover what they want when they experience it. Using an iterative approach makes us more adaptive to change requests, but also allows the customer to experience the product as the team is building it.

Choose the Methodology That Works for Your Organization

In conclusion, with proper planning, coaching, and training, organizations can choose a project management methodology that works best for their project teams, customers, and environment. At the conference, most presenters really stressed the importance of working with a qualified agile coach to help assess your organization’s maturity and determine the best approach for your project and environment. Waterfall, agile, and blended approaches all work!

Planning, coaching, and training for any type of project transition are the key to success with any methodology. We all need to drop our preconceived notions that one particular methodology is better than another. Find the one that will make your team and project more viable, productive, and collaborative.

Sharpen Your Agile and Hybrid Skill Set

Regardless of methodology, having a comprehensive understanding of agile and predictive approaches allows you to adapt based upon the project and your business environment.

If you want to run more projects using agile practices or a hybrid approach, RMC has options for you to discover.  RMC has many offerings including our Agile Fundamentals book, available in hard copy or in an online subscription format.  RMC also offers a self-directed Agile Fundamentals eLearning Course that teaches agile project development, practices, tools, and techniques. Our Hybrid Agile eLearning course teaches you what you need to know to combine predictive and agile approaches.

Sources:

https://www.teamwork.com/project-management-guide/project-management-methodologies/

Posted on by

What is Hybrid Agile?

Close up of team using hybrid agile approach

Agile and Hybrid Agile approaches are very popular right now. As organizations respond to accelerating rates of change, they are adopting agile approaches and using hybrid agile approaches more than ever.  This post explains the difference between agile and hybrid agile approaches, what constitutes each category and why organizations are adopting hybrid agile approaches.

  1. What is a Hybrid Agile?
  2. Agile and Knowledge Work
  3. Why Agile is a Great Starting Point
  4. The Benefits of Moving Beyond Agile
  5. Assessing Your Agile Readiness
  6. Building Situational Knowledge and Skills

What is a Hybrid Agile?

First let’s define what hybrid really means. A hybrid is a combination of two (or more) different elements. Hybrid cars often combine internal combustion engines (ICE) with battery electric (BE) technology. They could alternatively combine ICE or BE technology with a hydrogen fuel cell. The type of propulsion system does not define a hybrid, only the fact it is a combination of different approaches. Hybrid vehicles can combine the benefits of low emissions with long range made possible by a large gasoline station network.

Hybrids occur in nature too. Mules are the hybrid combination of cross breeding a donkey and a horse. While both animals look similar, donkeys and horses are quite different animals. A horse has 64 chromosomes, a donkey has 62. A mule has 63 chromosomes and is a completely different animal. Mules are larger than donkeys, have more stamina than horses, along with tougher hooves, a better resistance to parasites and can eat a wider range of foods – making them great pack animals.

That’s the idea behind creating a hybrid. Combining elements to try and get the benefits from both sources. However, we need to be careful that the effort and uniqueness are worth it. Hybrid vehicles are more complex and heavier than single power source vehicles. Mules cannot reproduce, you have to cross breed a donkey and horse each time to get one. More people know how to diagnose and repair a gasoline powered car than a hybrid one. Project leaders require a working knowledge of both plan-driven and agile approaches to use hybrid agile, while teams members would benefit from a foundational knowledge or Project Management Fundamentals and Agile Fundamentals.

Agile and Knowledge Work

Agile is important to knowledge work. Knowledge work is where subject matter experts come together to collaborate on new and unique products and services. This might involve scientists, teachers, doctors, lawyers, software developers, or web designers working with the business to build something new. Each of these groups has specialized knowledge, typically no single person knows everything needed to complete the project. What is being created is new or sufficiently different to the sponsoring organization as such previous project plans and estimates are not particularly useful to predict progress.

Unlike traditional, industrial projects, complexity, uncertainty, risk and change rates are very high. Many knowledge worker projects are working on designs and solving problems. There is no visible building or road getting created, the work product is invisible and intangible.

Without visible and tangible reference work, it is necessary to use an iterative-and-incremental approach to determine fitness-for-business-purpose. Teams could attempt to analyze and predict all features and functions, but often initial use uncovers additional opportunities and requirements.

Trying to explain the nuances of iTunes or Netflix to someone who has never seen anything like it before is difficult. Incremental trial is faster and more useful than speculative big-design-upfront that cannot anticipate every interaction with user behavior or linked systems.

Why Agile is a Great Starting Point

Agile methods provide an excellent project platform. Agile approaches have many benefits including:

1. Prioritize Business Value and Risk Reduction:

    1. By focusing on the highest business priority items first, organizations have a higher probability of realizing the major benefits of the work.  When teams actively identify and address risk early on and continuously, teams stand a greatly chance of overcoming the risk or identifying an alternative.

2. Iterative and Incremental Development: Today’s projects often produce something new that has not been done before. Building smaller increments of work and getting feedback keeps the deliverables closely aligned with consumer expectations. Taking an iterative and incremental approach helps iron out technical feasibility and performance issues sooner.

3. Adoption and Improvement: Adoption and improvement are conscious decisions to act on feedback, change design or experiment with a new process. Seeking feedback, then acting upon it in a formal, consistent manner transforms the opportunities identified into lessons to be acted upon that move projects forward towards better results.

4. Increase Drive through Empowered Teams: Agile approaches leverage a team’s ability to manage the complexity of the work and figure out the best way to organize it.  When teams are given more authority and autonomy, it creates greater ownership and a drive to deliver better results.

5. Safety: Safety is an essential ingredient in creating an environment where the team feels assured that trying and failing will not be punished.  Building such an environment allows people to feel safe to ask questions that may expose vulnerabilities and not operate out of fear.

The Benefits of Moving Beyond Agile

Agile approaches can offer a great starting point. However, they aren’t enough to deliver success most of the time.  Agile approaches work well for small projects in receptive, supportive environments, but agile is not sufficient for challenging environments.

Your industry and the culture of your organization often determines its readiness and tolerance for transitioning to agile approaches. Therefore, it is important to realize that no single strategy will be correct all the time.  Some organizations struggle to fully adapt to agile while other’s take on too many agile tools and process and get distracted or bogged down. As a result, organizations abandon agile all together a go back to using familiar plan-driven project management. That’s why your tool kit and skill set needs to have a combination of predictive, plan-based methodologies and agile project expertise to navigate context-sensitive decision points.

Watch our OnDemand Webinar Hybrid Agile: How & Why?

Assessing Your Agile Readiness

To help identify the types of projects your organization undertakes, answer the following questions about the nature of projects you execute.

If you answered more on the left-hand side of the table, it would indicate you are engaged in mainly industrial type projects. This is good news for reliable execution and traditional project management tools and techniques should serve you well.

If you answered more on the right-hand side, you are firmly in the knowledge worker domain. You should consider moving from industrial project management approaches and adopt knowledge worker agile ones.

If you answered about equally from each column, you are in a hybrid environment. Here you likely need to draw on a combination of approaches to be successful. This is one scenario where a hybrid approach might be suitable, for projects spanning the industrial / knowledge work domain. There are two other scenarios to consider also:

  1. As a steppingstone to true agile.
  2. In environments that demand additional rigor or controls.

Building Situational Knowledge and Skills

Our next article “Reasons for Adopting a Hybrid Agile Approach” explains each of these situations along with how to implement agile and hybrid agile approaches. It highlights strategies that have been proven to aid successful adoption and identifies risk areas and common pitfalls to avoid.

RMC offers several ways to learn more about Plan-Driven, Agile and Hybrid Agile approaches.  New to agile and plan-driven project management, consider Rita’s Agile Fundamentals or Project Management Fundamentals.  RMC offers a variety of hybrid agile offerings including our Hybrid Agile Instructor-led virtual course, our Hybrid Agile on-demand eLearning course and our Beyond Agile book.

We also offer two hour long on-demand workshops that introduce you to a groundbreaking Hybrid Agile model and how you can use it to apply plan-driven and agile approaches based on the specifics of your projects.

Sources:
https://rmcls.com/adopting-hybrid-agile-approach/
https://www.leadinganswers.com/2021/12/beyond-agile-relentlessly-reduce-process.html

Posted on by — 1 Comment

Contract Issues in Agile Development

Two business people review signing a contract

There has been a significant amount of discussion regarding the tension between development and agile contracts. Many see this conflict as irreconcilable, citing provisions in the Agile Manifesto favoring “working software over comprehensive documentation” and “customer collaboration over contract negotiation.”

Those who see the conflict this way claim that lawyers are operating in an outmoded mindset and need to be educated about the agile method of doing business. These same people claim that lawyers perceive many agile practitioners as unrealistic and naive.

In my view, this so-called tension is the result of a misconception of the lawyer’s role and of his or her duty to the client.

Contracts and Agile Development

  1. The Role of the Lawyer
  2. Implementing the Parties’ Intentions through Form Contracts
  3. Similarities in Agile and Other Development Contracts
  4. Agile-Dependent Provisions
  5. Similarities between Agile and R&D Contracts
  6. What Would an Agile Contract Look Like?

The Role of the Lawyer

The lawyer’s duty is to protect the interests of his or her client. What does that mean, exactly? To those in the “lawyer as dinosaur” camp, it means that a negotiation is perceived as a zero-sum game, with success being defined as winning the maximum number of business points and shifting as much business risk as possible onto the other party. In fairness, I have seen negotiations go that way and, at times, lawyers take a leading role in those types of adversarial negotiations.

In my experience such types of negotiations are ultimately unsuccessful because the relationship and the business objective underlying the agreement usually fail. That doesn’t do anyone any good, and it can’t be viewed as truly protecting the interest of the client.

A lawyer’s job is to assist their client in reaching their business objective. Part of that responsibility includes reducing risk to the client. The definition of risk, however, cannot be compartmentalized into individual business points or contract provisions, and must include the overall goal of the contract.

In the end, the object of the contract is to document the intentions of the parties and to create a mechanism to implement those intentions.

Implementing the Parties’ Intentions through Form Contracts

Much has been written about the need for new and specialized modalities surrounding contracts intended to implement agile methodologies. For example, in 2008 the Norwegian University of Science and Technology conducted a detailed study of problems associated with contracts in agile development projects. This ultimately led the Norwegian Computer Society to adopt a standard form contract to be used for agile software development, maintenance, and service operations.  There are many other form contracts purporting to be agile friendly. For example, see the Draft/Contract for use in DSDM Projects (DSDM refers to dynamic systems development method, an agile methodology).

Although these form contracts can be useful, there are already existing procurement methodologies that can accommodate the iterative approach used in agile software development.

Similarities in Agile and Other Development Contracts

One reason existing form contracts can be used for agile is because agile development shares many of the same needs of other types of development. For starters, you need to identify the parties to the contract. You need to have an effective date and a start date. You need to state when and how the vendor will be paid.

In addition, as with other software contracts, there must be warranties from the vendor, such as one warranting that it owns the rights to the code it will be developing and selling to the purchaser. There should also be some software escrow provision allowing the purchaser to gain access to the code should the vendor file for bankruptcy or go out of business. These are just a couple of examples. There are many others.

Agile-Dependent Provisions

The tricky issue with contracts and agile development stems from the iterative process and the intentional lack of documentation regarding the scope of work or the performance characteristics of the product being purchased.

In a traditional procurement, there is normally a detailed specification or statement of work that sets the standard against which vendor performance will be measured and allows for a firm price. This approach won’t generally work in agile development. But there are other contract methodologies, such as those used in research and development (R&D), designed to deal with situations where detailed specifications are impossible. Such contracts may be adapted to fit into the iterative approach called for by agile.

Similarities between Agile and R&D Contracts

In many agile agreements the requirements, by design, are not well documented. The same can be said for R&D contracts. Parties often enter into R&D contracts without knowing whether the object of the agreement is even doable. One area where these contracts may differ is in the iterative methodology used in agile; however, this is not critical, and the iterative methodology can be documented.

What Would an Agile Contract Look Like?

As far as scope is concerned, both an agile and R&D contract would probably have a simple statement, not necessarily of work, but of goals. There would be provisions allowing for a re-scoping after every iteration, a process for identifying what was done and what was not done. With respect to those items that were not done, the contract would also document a decision process governing whether those pieces of work would be put into the next iteration, mothballed, or discarded. There would probably also be provisions for the re-scoping of work for the next iteration.

Payment would most likely be either on a cost-plus basis (with a fee or profit component) or for time and materials. Given the uncertainties of the project, a firm fixed price would most likely be impossible, but there could be a budget target or cost estimate that might go in at the front end, against which the project progress could be measured.

In this respect, an agile project would differ from R&D in that the end of the project would be defined as when the purchaser runs out of money, not when the goals of the project have been reached. Honestly, this would most likely be extremely dissatisfying to a purchaser, especially one that did not have a business history with the vendor.

There would also need to be provisions governing testing and acceptance, at the end of each iteration and at project completion. One issue is the criteria governing acceptance. If requirements are not defined up front, how do you determine what success looks like at the end? It could be defined by requirements set forth at the beginning of each iteration; the contract would require each successive set of requirements to be met for the project to be deemed successful. With this approach, one concern is the situation where all the pieces work, but the final product is unsatisfactory. In my view this is the largest problem with agile contracts, but in many respects it’s no different than an R&D contract where the parties have goals but no real knowledge of whether those goals can be achieved.

As long as the parties’ expectations regarding the final product are understood and documented up front, with the understanding that if the purchaser’s expectations are not achieved, the purchaser would only have limited recourse, then an agile-based contract would work.

Boilerplate provisions would be similar to those found in other contracts. IP warranties and indemnifications would be the same, as would severability, governing law, notifications, modification, confidentiality, and competition.

RMC is Here to Get You Started

In looking at agile contracts, the documentation requirements are not all that unique and can be fit into other more traditional procurement methodologies. There is no need to completely reinvent the wheel. Rather, the lawyer and practitioner need to keep in mind that they are creating an agreement in an environment of uncertainty, not unlike that found in an R&D contract.

In response to the growing relevance of Agile methodology for all Project Managers, the Project Management Institute (PMI®) has begun offering the Agile Certified Practitioner (PMI-ACP®) certification exam. RMC Project Management offers comprehensive exam preparation products, eLearning and classroom training options to help you earn PMI-ACP certification

[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section]

Posted on by

Agile and Scrum: What’s the Difference?

Woman at whiteboard working on project

In project management circles, you will hear about agile and Scrum. Agile is a philosophy – a way of thinking and being for managing projects in our knowledge economy. Today’s fast-changing technology-based economy means that a project’s scope of work is emerging – and requires flexibility – as project teams and customers work together to build that scope.

Two of agile’s four values focus on responding to change and a continuous delivery of value in the form of complete and working product increments. The other two values focus on the human interaction side of the equation. These values related to individuals and interactions, and customer collaboration underscore rather than take for granted that people working closely together is critical to producing the best work.

Agile is a mindset about how to think and be, while Scrum offers a framework, or more specific instruction for how to carry out the work. Let’s look at an overview of Scrum and specific Scrum vocabulary. Scrum describes specific Roles, Artifacts, Activities, Pillars and Values. Let’s dig down a little bit into each of these.

What’s the Difference Between Agile and Scrum?

  1. Scrum Roles
  2. Scrum Artifacts
  3. Scrum Activities
  4. Sprint Pillars and Sprint Values

Scrum Roles: Development Team, Product Owner, ScrumMaster

There are key scrum roles. The development team is a group of subject matter experts. Together, they have the collective knowledge and abilities to elicit and analyze product requirements, and then design and build the product iteratively and incrementally. Iterations are small time-boxed work cycles which in Scrum we call Sprints. Increments are complete and working parts of product. For example, a development team may produce an increment of product in each of several two-week iterations.

The development team’s focus is always on the most highly valued product increments. After they deliver these, they turn to a newly (and continuously) prioritized Backlog (which is a complete list of the product’s requirements). How they know what to build next is the role of the Product Owner.  The customer representative, product owner works collaboratively with the team to ensure the continuous delivery of value by prioritizing that backlog.

The ScrumMaster’s job is to help the team, including the product owner, to achieve agile product creation by always ensuring a common understanding of the product vision. They ensure the selected agile processes are understood and being followed, and they provide servant leadership for the team. The remove impediments to that steady forward movement toward the project’s end goals.

Scrum Artifacts: Product and Sprint Backlogs, and Product Increments

Now you can understand the Scrum artifacts in context. The Product Backlog is that list of all product requirements. The Sprint Backlog is the smaller subset of the product backlog that has been prioritized to build the Product Increment or increments during the current sprint.

Scrum Activities: Backlog Refinement, Sprint Planning, Daily Scrum, Sprint Review and Retrospective

You can probably guess at the meanings for these terms. Take a quick look here.

Backlog Refinement. This is also known as prioritizing or grooming the backlog. Here, the Product Owner decides what is built next, so the team always knows what to do.

Sprint Planning. The team get together and organize around the upcoming sprint.

Daily Scrum. This is a very brief meeting where team members share feedback. Specifically, the share what they each have done since the last scrum, what they will be doing next and mention any impediments they are facing. Impediments are problems to be solved but not during this brief meeting. They are for follow up by the ScrumMaster after the meeting. They are defined as a daily meeting but can take place less often, as needed.

Sprint Review. In this meeting, the team demonstrates the increment or increments built during the current sprint, to the customer. They take the customer’s feedback with them and if it is approved, the customer can take delivery of the product increment(s).

Sprint Retrospective. Yet another part of Scrum’s continuous feedback looping, this is where the team meets and discusses what went right, what went wrong, and what they would do differently, based on the current sprint. This will help in planning the next sprint and beyond through the project.

Sprint Pillars and Sprint Values

Of course, none of this would work without a set of principles the team agree to live by together. The sprint pillars are Transparency, Inspection and Adaptation. With transparency Scrum teams ensure that their work, process, and progress are visible; shared with all stakeholders at any time. Inspection involves doing regular and timely checks on product and project progress, and you can see how Scrum activities and artifacts support this. It also means inspecting each increment of the product for quality before it is considered “done” to review with the customer. In turn, adaptation is about adjusting the team’s processes according to what the team learns from inspection.

Sprint values are a team promise to each other and the organization to work for the focus, courage, openness, commitment, and respect that is needed to make a high functioning empowered teamwork. This in turn helps to deliver the promise of the Scrum framework.

Posted on by — 1 Comment

Three Ways to Lead with Emotional Intelligence

Young woman smiling over shoulder using emotional intelligence

Emotional Intelligence (EI) is your ability to identify and control your emotions to be a successful leader. Emotional intelligence is an awareness of emotions in yourself and in others.  It is the ability to develop and manage strong relationships.  Emotional intelligence uses reason to identify, understand and effectively deal with emotions. Studies show EI is a skill linked to success at all levels. Project managers with high EI are better equipped to deal with, handle and resolve conflict and change.

Leading with Emotional Intelligence

  1. What is Emotional Intelligence?
  2. Benefits of Using Emotional Intelligence
  3. Three Emotional Intelligence Techniques

What is Emotional Intelligence?

Author and social scientist, Daniel Goleman identified five categories within emotional intelligence.  They are: self-awareness, self-regulation, empathy, motivation and social skills.  These 5 categories define the ability to understand the needs and feelings of oneself and other people, manage one’s feelings, and to respond to others appropriately. Let’s walk through each competency.

1. Self-Awareness

Self-awareness is a pivotal component of emotional intelligence.   When you are self-aware, you have the ability to identify and name your emotions.  It means you have the ability to honestly recognize your emotions and the effect of your emotions.  It also includes the ability to know your strengths and limitations and having self-confidence in your capabilities and worth.

2. Self-Regulation

Regulation is the ability to manage emotions, which includes both regulating your own emotions, and when necessary and helping others to do the same.  Other aspects of self-regulation include trustworthiness, the flexibility to adapt to change and having high integrity.  Being open to new ideas and information is also a key trait of self-regulation.

3. Social Awareness

Another component of EI is social awareness.  Social awareness is mainly about empathy.  Empathy is our ability to feel what the other person is feeling.  We often describe it as the ability to put yourself in the other person’s shoes. Social awareness also includes organizational awareness.  This is the ability to anticipate and recognize customer needs, an ability to read the politics and understand the power dynamics in your organization.  Finally, social awareness includes sensing what others need to grow and develop.

4. Self-Motivation

Also called self-management, it describes your ability to demonstrate emotional self-control.  You may experience impulses or be in a bad mood, but you control those emotions.  As a person, you are interested in moving forward towards a goal or strategy.  You are also self-motivated and don’t let setbacks control the outcome.  Finally, you are able to stay calm under pressure and don’t panic in the face of a crisis.

5. Social Skills

The core to social skills is relationship management.  It covers abilities such as influence, conflict management, teamwork and leadership.  You use emotional intelligence to create and nurture relationships.  Your ability to influence comes from a strong ability to communicate clearly and persuasively.

Benefits of Using Emotional Intelligence

Emotional intelligence is important as our teams are more global. It is also important as more of our work is online.  Our environments are more intense, but they’re also more distributed and remote.   This means we have fewer opportunities for in person understanding.  We all have emotional intelligence skills.  The big benefits come from understanding, managing and using EI competencies to perform our work.  The benefits of emotional intelligence are far reaching:

  • Ability to actively listen and restate what you have heard .  This helps you clearly understand expectations and builds trust. You’ll find you are better aligned to the goals of the organization.
  • Improve the ability to develop ourselves and develop others. You are able to provide feedback effectively and are comfortable building the skills and abilities of others.
  • Helps with managing and resolving conflict. You need to be in touch with your emotions and to see another’s point of view to get to resolution.
  • Builds appropriate reactions within the context of your organization.
  • Helps you tailor your communications to influence stakeholders in our work environment, projects and day to day work.

Three Emotional Intelligence Techniques

By increasing your emotional intelligence, you can better connect and collaborate with others. You become more resilient and help motivate and lead others.  There are many things you can do to increase your emotional intelligence.  Here are three ways to lead with emotional intelligence:

1. Practice Recognition

  • Analyze your interaction daily.
  • Journal or note emotions as they arise.
  • Watch response in others. Notice body language. Notice when people are not engaged.

2. Use Empathy

  • Identify the emotion you are feeling, or the emotions others are exhibiting. Identify when you have experienced similar.
  • Note differences in how others respond. Your emotions may be different than others and that is good information to have in order to read the situation.
  • Tailor your responses by being aware of yourself and others. Then, adjust appropriately to the situation and respond intentionally.  This will prevent you from trying to tell another person what they should be feeling or to dictate a response.

3. Respond Intentionally

  • Stop reacting immediately. Not every thought in your head needs to be shared.
  • Ask yourself if this is the right time to respond? Or do you need to take more time to think through your response?
  • Ask yourself what is the appropriate response and how much information do I need to share?

Final Thoughts

As a project professional, applying your emotional intelligence skills to increase your organizational awareness, identify opportunities to use the appropriate level of empathy, and enhance your self-awareness of your emotions helps you be an effective leader. You’ll be better able to deliver project objectives and deliverables with less conflict and a more cohesive team.

Posted on by

Reasons for Adopting a Hybrid Agile Approach

Two team members using hybrid agile on a project

If you are curious about hybrid agile, it may be helpful to examine a few instances where you might want to consider a hybrid approach. The first is hybrid agile as a stepping stone to true agile. The second is hybrid agile in environments that demand additional rigor or controls. 

 

Hybrid Agile Approach

  1. Hybrid – A Stepping Stone to Agile
  2. Environments Requiring Additional Rigor or Controls
  3. A Reason for Hybrid Agile

 

Hybrid – A Stepping Stone to Agile

Making the shift from a traditional waterfall approach to agile can be a large adjustment for some organizations. One school of thought is to just commit to it.  Adopt agile approaches whole scale and abandon your old way of working in a burn-the-boats style of never going back. This is simple to explain and easier to achieve when there is top down support for the adoption of agile.

 

However, when the desire to adopt agile is bottom-up or department based it may not be possible to fully abandon the old way of working. Some interface points to other departments might need to be maintained. Also, reporting or governance frameworks outside our sphere of influence may still be needed. In these cases, a Hybrid Agile or “Agile + Traditional Stuff” might be required. 

 

Many organizations have been successful in adopting agile approaches in an iterative and incremental fashion. In fact, Kanban suggests “start with what you do now.”  Then, “agree to pursue incremental, evolutionary change” that “respects the current process, roles, responsibilities & titles”. Begin by using the core properties of Kanban.  This includes visualizing the workflow, limiting the work in progress, managing flow and improving collaboratively. 

 

Using this approach, during the transition period from traditional methods to Kanban or agile methods, organizations use a hybrid approach as a stepping stone to their end state. 

 

Environments Requiring Additional Rigor or Controls

Some highly regulated environments like pharmaceutical or aerospace demand additional rigor and validation before allowing products to market. This is a good thing, it reduces the likelihood of shoddy or poorly tested services causing injury or death. 

 

These safety critical projects typically need to demonstrate traceability from requirements through completed designs and then successful testing. The idea being this audit trail of documentation helps ensure due diligence and proper care has been taken in the design, build and testing portions of the lifecycle to assure quality. 

 

By default, Agile approaches take a lightweight approach towards documentation. They prefer face-to-face communication where possible over documentation.  This approach gets questions answered quicker and conveys more information such as enthusiasm, confusion or conflict. 

 

When describing documentation on agile projects, the maxim “just enough, just in time, and sometimes just because” is sometimes used. It summarizes the guidelines to employ the minimum amount of documentation, when required (to avoid waste due to changes).  In fact, sometimes it is easier to provide the documentation than argue about it.

 

The challenge for safety critical projects is that “just enough” can be a heck of a lot. Plus, once produced, we cannot continue changing things and enhancing the solution because that would trigger a new round of testing and documentation. So, to avoid these issues, teams in safety critical environments often wrap the core agile development process in a more traditional wrapper. 

 

The start and end points of their projects are traditional. It provides the rigorous vendor selection, planning activities and the documentation needed for acceptance and approval for use. However, in the middle they use agile approaches to iterate quickly on building their product or service. It provides the benefits of early feedback, risk reduction and learning as they go. During execution they also wrap the process with additional governance and supporting activities.

 

This is an example of hybrid agile in the form of encapsulation. The agile component is encapsulated in a wrapper of more traditional operation. If you operate in a highly regulated environment it allows the benefits of agile to be used while still satisfying regulatory controls. There is a price for adding the extra processes, but those activities would have to be done in that safety critical environment anyway.