Chat with us, powered by LiveChat ASSESSMENT 3 | Gen Paper

Module 3

This is a single, concatenated file, suitable for printing or saving as a PDF for offline viewing. Please note that some animations or images may not work.

Week 3

May 24 — May 30


· Module 3 online content – Adapting Over Conforming

· Agile Project Management textbook – Chapters 5 and 6


· Discussion 3 due Monday, May 30 at 11:59 PM ET


· Assignment 3 due Tuesday, May 31 at 6:00 AM ET

· Work on Group Project


· Quiz 2: Five multiple-choice questions, available from Tuesday, May 24 at 6:00 AM to Monday, May 30 at 11:59 PM ET

Live Classroom:

Module 3 Live Classroom Session — Sunday, May 29 at 7:00 PM ET

Module 3 Introduction

msm_ad649_16_sp1_jhannon_m3 video cannot be displayed here

In this module the agile Project Manager (PM) is introduced with the key principles that are built in the new agile team. In the standard model the PM focuses in on the need to ensure the plan is being adhered to and any proposed change is dealt with from the top down. In the new agile world, the PM works with the team and they embrace change under the new agile principles.


Learning Objectives

After completing this module, you will:

1. Learn about adaptive principles

2. Learn the science of adoption

3. Explore the process

4. Learn about responding to change

5. Learn about product, people and process

6. Learn about the barriers of opportunities

7. Learn the concept of “reliable, not repeatable”

8. Learn about reflection and retrospective


Learning Adaptive Principles

Within the current environment the importance of the plan is centric to the idea of success. Managers have been indoctrinated for years that in order to achieve success they must have a plan and have a clear definition from senior management of what they see as success.

This traditional method of working on a project is built to look at changes in the plan as a negative thing. This constraint-based approach ends up hampering the PM, the team, the customer and ultimately the firm as a whole. Managers are taught that they can accept changes from the customer, but they put up all different types of obstacles. The managers also view a plan that is well-laid out as a way to reach the goals of the customer and the needed quality standards. The agile leader does do planning on the project, but they view these time-boxed series of plans drastically differently. The agile leader asks “what will bring the most value to the project? Let’s do those things first” (Sutherland, 2014, p.87).

The Teams and Agile Principles

The most important part of the whole agile puzzle is the team. In today’s world teams will ultimately adapt to the changes required. However, adaption can be much more difficult in various scenarios.
The team in the new agile world must constantly probe and evaluate if the team is improving. This evaluation method to assess improvement can be done by asking the following:

· Is value, in the form of a releasable product, being delivered?

· Is the quality goal of building a reliable, adaptable product being met?

· Is the project progressing satisfactorily within acceptable constraints?

· Is the team adapting effectively to changes imposed by management, customers, or technology? (Highsmith 2014, p. 65)


The dictionary defines change as: “To cause to be different, to give a completely different form or appearance to.” It defines adapt as: “To make suitable to or fit for a specific use or situation.” Changing and adapting are not the same and the difference between them is important. There is no goal inherent in change—as the quip says, “stuff happens.” Adaptation, on the other hand, is directed towards a goal (suitability). Change is mindless; adaptation is mindful (Highsmith 2014, p. 65).

Change is a challenge in traditional project management. In the diagram below you see the reasons why. There are many different staff with unique roles, all physically separated and involved in a waterfall project. The Business Analysts and Architect(s) are not directly in touch with the Construction staff. The business analyst should play a key role in verification and validation, but in the traditional waterfall structure interface with the integration staff implementing the requirements rarely happens.

Therefore, in the traditional waterfall project the requirements are communicated to the next team using rigorous documentation as the baton is passed further down. A change in project outcomes requires a lot of rewriting of the documentation!

Figure 3.1

This happens frequently in projects. The requirements approved by a sponsor changes due to changes in the business environment or technology. Such changes usually require rewriting the documentation and artifacts implemented. Therefore, even a simple change would result in a slippage of milestone “M1,” resulting in a domino effect and slippage of milestones “M2” and “M3.” The project schedule promised to various stakeholders is compromised with even simple changes.

In an agile environment, the BA and other team members work closely with the construction team. Due to co-location, either physically or virtually, changes are managed well. Very little documentation is involved in agile PM.

In conclusion, as Highsmith writes, “We expect change (uncertainty) and respond accordingly rather than follow outdated plans. We adapt our processes and practices as necessary.”


The Science of Adaptation

In understanding how people will adapt to moving to agile, it is wise to review some basic responses of management to various types of businesses. If a business looks at how a manager adapts to agile, they can employ similar methods to other areas of the company. If the environment is much more fluid, then the management will morph into that type of management. However, the real world is not simply black and white, but very gray. This grayness requires that people adapt to the gray view of the world.

“In an era of rapid change, we need better ways of making sense of the world around us. Just as biologists now study ecosystems as well as species, executives and managers need to understand the global economic and political ecosystems in which their companies compete” (Highsmith 2014, p. 65).

We conclude this section with a few thoughts on adapting to agile roles and responsibilities. When one transitions towards agile project management, there is a shift in roles and responsibilities. In a more traditional project, decisions are frequently made in a hierarchical manner, and the project organizational structure—as well as team roles—are specifically established to support this structure. However, in the agile world, the focus is to get people to work together every day, and the organizational structure is deliberately not hierarchical (Moreira, 2013).

The figure below illustrates the components of a robust agile organization. It assures a role for everyone. In methodologies such as Scrum, as we noted earlier in Module 2, there are three core roles. However, many other people in the organization—ranging from customers, executives and management to sales, marketing, finance and HR—must understand the agile mindset and must play a role to ensure success (Moreira, 2013).

Figure 3.2



We have discussed in great detail the need for teams to adapt to change and take risks by exploring new and different ways to complete their work. The agile model change factor puts the firm on the offensive, and this gives a distinct advantage to the firm.

The effort to make teams explore more and take needed risks can be intimidating for a lot of people. People usually shy away from being overambitious when it comes to taking risk, and this will ultimately impact your project. In the move to agile it is essential that management fully understand they need to foster this habit of exploration. In a majority of agile conversion efforts one of the predominant issues of failure is that management does not stand behind the needed efforts.


Responding to Change

As Highsmith notes in your textbook, “In Artful Making, Harvard Business School professor and colleague Rob Austin and his coauthor Lee Devin (2003) discuss a $125 million IT project disaster in which the company refused to improvise and change from the detailed plan set down prior to the project’s start. …Every project has knowns and unknowns, certainties and uncertainties, and therefore every project has to balance planning and adapting” (p. 70).

“Balancing is required because projects also run the gamut from production-style ones in which uncertainty is low, to exploration-style ones in which uncertainty is high. Exploration-style projects, similar to development of the Sketchbook Pro© product introduced in Chapter 1 (of the textbook), require a process that emphasizes envisioning and then exploring into that vision rather than detailed planning and relatively strict execution of tasks” (Highsmith 2014, pp. 70-71).


Product, Process, People

Faced with major redirection in release 2.0 of their product, the Sketchbook Pro© team delivered the revised product in 42 days. As Jim Highsmith quips in workshops, “I know teams who would have complained for 42 days with comments such as: “They don’t know what they want. They are always changing their minds.” In the terms of adaptability, it has three components—product, process, and people (Highsmith 2014, p. 71).

In adapting to agile it is crucial you have a team that truly believes in the agile process. The team will need the ability to work with tried and true processes that can support it. The team must also be using an inexpensive process that can quickly show it the impact of the change. The team will leverage this model with more enthusiasm.


Reliable, Not Repeatable

The ultimate goal of every sprint is to provide a releasable product. The team has spent considerable time in planning, communication and ensuring they meet the requirements of the prescribed user stories. The team, though agile, still needs to have some level of a repeatable process that can support the creation and delivery of a good. However, the team must look not just at the user stories presented but also the full product vision in order to ensure they present a reliable view of the delivery of products.


Reflection and Retrospective

All agile methodologies provide a mechanism for reflection and retrospective. This, in effect, is a process for continuous improvement and assures successful project outcomes.

A team that is effective will ensure they fully use the change for a retrospective. The team will look at key areas, product, technical and process. The team will closely review their own performance and critically identify areas where it can improve.

Figure 3.3


The Takeaway Chapter 5 – Sutherland’s Red Book

Scrum – The Art of Doing Twice the Work in Half the Time

Multitasking Makes You Stupid. Doing more than one thing at a time makes you slower and worse at both tasks. Don’t do it. If you think this doesn’t apply to you, you’re wrong—it does.

Half-Done Is Not Done. A half-built car simply ties up resources that could be used to create value or save money. Anything that’s “in process” costs money and energy without delivering anything.

Do It Right the First Time. When you make a mistake, fix it right away. Stop everything else and address it. Fixing it later can take you more than twenty times longer than if you fix it now.

Working Too Hard Only Makes More Work. Working long hours doesn’t get more done; it gets less done. Working too much results in fatigue, which leads to errors, which leads to having to fix the thing you just finished. Rather than work late or on the weekends, work weekdays only at a sustainable pace. And take a vacation.

Don’t Be Unreasonable. Goals that are challenging are motivators; goals that are impossible are just depressing.

No Heroics. If you need a hero to get things done, you have a problem. Heroic effort should be viewed as a failure of planning.

Enough with the Stupid Policies. Any policy that seems ridiculous likely is. Stupid forms, stupid meetings, stupid approvals, stupid standards are just that—stupid.

No Bad Behavior. Don’t be one, and don’t allow the behavior. Anyone who causes emotional chaos, inspires fear or dread, or demeans or diminishes people needs to be stopped cold.

Strive for Flow. Choose the smoothest, most trouble-free way to get things done. Scrum is about enabling the most flow possible.



In Agile Project Management (APM), we are not obliged to rigidly and perilously stick to a plan. Be open to change—it is inevitable in a project. “Without the changes there wouldn’t be any value in the project” (Sutherland, p. 146).

The following thoughts communicate how the APM discipline is different (Langr et al, 2011):

· Work on one thing at a time – Tackle one tiny feature a step at a time.

· Shorten feedback loops – Aggressively simplify your process to shorten feedback loops.

· Continuously reflect and adapt – Deliver a quality product via continuous improvement.



Highsmith, James A. “Chapters 4, 5 and 6.” (2014). Agile Project Management: Creating Innovative Products. Upper Saddle River, NJ: Addison-Wesley.

Langr, Jeff, Tim Ottinger, and Susannah Pfalzer. (2011). Agile in a Flash: Speed-learning Agile Software Development: Agile Cards for Agile Teams. Raleigh, NC: The Pragmatic Bookshelf.

Moreira, Mario E. (2013). Being Agile: Your Roadmap to Successful Adoption of Agile. New York: Apress Publishing.

Sutherland, J. (2014) Scrum: The Art of Doing Twice the Work in Half the Time. Crown Business.

error: Content is protected !!