Direct Playback
Subscribe: Apple Podcast
Check out the podcast on Google Play Music

The SPaMCAST 588 features our interview with Susie Palmer-Trew and Peter Taylor.  We discussed their new book Project Management: It’s All Bollocks!  It was great to meet Susie and renew our conversation with Peter. We talked about the assumptions that the profession of project management makes and why we should challenge those assumptions. The episode has the subtitle (you will discover it ½ way through the interview)  (more…)

Five Color Highligher

Five Different Colors!

Reciprocity is a social norm across societies and in all age cohorts, where a recipient responds to a positive action with another positive action. The concept of reciprocal agreements is part of our socialization that teaches us to share, take turns and give back to those who give to us.  Reciprocal agreements are part of working and playing well with others that we begin learning on the playground and then bring to the office with us. There are many types of reciprocal agreements in a typical agile project. Agreements between the development portion of the team and the product owner(s), between a scrum master and the product owner, between the scrum master and the development portion of the team and finally between the whole team and the stakeholders.  Most of these agreements are informal or are inherited from the twelve principles in the Agile Manifesto. Reciprocal agreements impact how every member of the team and the broader organization interact. There are five common examples of reciprocal agreements that illustrate how important the idea of reciprocal agreements is to a Scrumy version of agile. (more…)

Baby You Can Drive My Car

As an employee, I get up in the morning and after a time I locate my key fob and company ID then go to work. I get to help people deliver value and engage customers. I like what I do, however, I have an expectation that if I do my job, the company I work for will pay me what we have agreed upon. We have a reciprocal agreement: we will share resources to achieve a common objective. Reciprocal agreements, formal and informal, are at the heart of many behaviors in software development (including development, enhancements, maintenance and all of the support roles). All reciprocal agreements are at least in part based on a very basic human behavior: reciprocity. (more…)

The Software Process and Measurement Cast 345 features our essay on Cognitive Biases and two new columns. The essay on cognitive bias provides important tools for anyone that works on a team or interfaces with other people!

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

SPaMCAST 462 features our interview with Jon M Quigley  We discussed his new book Project Management for Automotive Engineers. Jon co-authored the book with Roopa Shenoy. The book and the ideas in the book are relevant to all types of projects whether they use Agile or not!  A fun and informative conversation!

Jon’s Bio:

Jon M. Quigley PMP CTFL is a principal and founding member of Value Transformation, a product development training and cost improvement organization established in 2009, as well as being Electrical / Electronic Process Manager at Volvo Trucks North America.  Jon has an Engineering Degree from the University of North Carolina at Charlotte, and two Master Degrees from the City University of Seattle.  Jon has nearly twenty-five years of product development experience, ranging from embedded hardware and software through verification and project management.

Jon has written or contributed to a huge number of books, presentations, and articles including:

Project Management for Automotive Engineers ISBN 978-0768080773

Configuration Management: Theory, Practice, and Application ISBN 978-148222935

Contact Jon at:

Here is a promo for my upcoming ITMPI Webinar! (more…)

The front cover of The Mythical Man-Month

The Mythical Man-Month

Hatching a Catastrophe is one of most quoted of essays from The Mythical Man-Month by Fred P. Brooks. In this essay, Brooks makes the point that projects get behind one day at a time. Rarely, if ever, does a project go from being on time to substantially behind schedule overnight; even though we have all seen projects go from green to red at the blink of an eye. The slow erosion of schedule performance is often very hard to recognize even when a catastrophe is in progress. We often use the example of the metaphor of the frog and the pot of water to illustrate this problem. If a frog is placed in a pot of water that is slowly brought to boil, they will not try to hop out because they don’t recognize the problem until it too late. Whether true or not, the metaphor illustrates one of the main points that Brooks makes in this essay. However, as with most catastrophes, there are mechanisms to avoid disaster with a bit of structure and discipline.

Milestones or Millstones: Brooks proposes that big project on a tight schedule require control. I suggest that any project that is important enough to fund (even in blood, sweat or tears) requires control. Milestones are an action or event marking a significant stage or event in development. For example, the completion of testing or acceptance in a demo is a milestone. Milestones, when defined correctly, provide a tool to help evaluate whether a project is drifting off course. The fifty dollar phrase in the last statement is “when defined correctly.” In order to be useful, milestones must be concrete, specific and measurable in order to be crisply defined.

Milestones that are unambiguously defined with a crisp definition of done provide a mechanism for measuring whether a task or a set of tasks are complete. The ability to know that a piece of work is done is empowering. Who does not like to check something off as done? Failing to define a crisp definition of done does a disservice to everyone involved in a project. The most precise definition of done for a milestone is that the tasks that are linked to the milestone are ALL 100% complete (not just really close). The crisper the definition of done is for the milestone, the less chance that we can deceive ourselves or rationalize that not being exactly done is close enough. The process of deception or rationalization is demotivating to the team and the organization.

Milestones are a tool to establish discipline within the team. Without the discipline provided by milestones, it is easy to rationalize slipping the schedule just a little bit (slipping the schedule is the same as not meeting commitments in Agile). One classic rationalization that Brooks points out is using the excuse that another piece of work is late, so we do not need to be on time. While one would not expect this type of behavior amongst professionals, it occurs. I once sat in a meeting where a hardware manufacturer announced they were over a year late, but since another firm was even later, it did not matter. Interestingly the other firm turned out not to be as late as it was perceived, and significant problems ensued.

As noted earlier, projects become late a day at a time. No one gets overly excited about getting behind a few hours or a day. We can easily rationalize that we can make up the time. Software engineers are trained problem solvers who can easily rationalize the slip until it is too late. How often have you seen a task or story that is nearly completed day after day? It is easy to sweep being late under the rug until it can’t be hidden.

Brooks describes several solutions. One example is generating PERT diagrams that identify critical paths and the slack any task might possess. More interestingly, Brooks describes how the team member/manager tension can be defused. For example, not having the leader act on issues that the person having the problem can solve, thus empowering the team member. Concepts in use today that help prevent hatching a catastrophe include servant leadership, self-managing teams, short time box and daily stand-ups. Including techniques that generate early warning signals that illuminate the true status of work and prevent problems from getting larger.

Previous installments of the Re-read of The Mythical Man-Month

Introductions and The Tar Pit

The Mythical Man-Month (The Essay)

The Surgical Team

Aristocracy, Democracy and System Design

The Second-System Effect

Passing the Word

Why did the Tower of Babel fall?

Calling the Shot

Ten Pounds in a Five–Pound Package

The Documentary Hypothesis

Plan to Throw One Away

Sharp Tools

The Whole and the Parts

The definition of slippy doesn't change depending on if your Agile or not...

The definition of slippery doesn’t change depending on if your Agile or not…

The construct of a “project” is embedded in the DNA of most development and maintenance organizations. That is regardless of whether a project is the best mechanism to group work, because, in one form or another, it is a nearly universal concept. Developing a common understanding of what a project means in an organization is an important if you want to discuss how work is done.  Often people believe, falsely, that he adoption of Agile has disrupted this common touchstone so that communication between Agile and non-Agile groups is problematic.  The Project Management Institute (PMI), which provides a common project management certification, defines a project on their website as:

“… a temporary endeavor undertaken to create a unique product, service or result. A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources.”

Agile adherents might use different words in their definition, such as substituting the term time boxed for having a start and end date and aimed at a specific goal for the term defined scope, but these substitutions do not materially change the concept of a project. The concept of a project seems to be independent of whether a team is using Agile or not. To test this hypothesis, I asked a random group of colleagues the following question:

I know there are technique differences, however do you see any conceptual differences in the definition of a project if you are using Agile or not?

The typical answer was that there should be no conceptual difference. However that “no” was almost always followed by a “but”. For example, Mary Prendville (SF Federal Reserve Bank) responded, “Conceptually no, but culturally yes.” Generalizing Mary’s response in light of the majority of respondents: there should be no difference in how a project is defined between Agile and non-Agile on a theoretical basis, however practitioners perceive that there is a difference between theory and reality. The respondents “buts” were centered on two ideas. The first was the perceived flexibility in an Agile project’s treatment of scope and the second focused on project management attributes such as transparency.

The first “but” was that Agile projects can have a less defined scope than projects following the more classic PMI definition. For example, Mauricio Aguiar, President of ti MÉTRICAS, responded “I would say not having a fixed scope in Agile is a conceptual difference.” The basis of this perception can be traced to one of the two primary release management strategies typically leveraged in Agile. Agile projects often leverage a release strategy in which the team size and release duration are fixed. Therefore scope is varied. A simple example of this strategy can be seen when a Scrum team deploys functionality into production at the end of each sprint. A specific example might be when team of 7 people release completed functionality into production at the end of every sprint. Because team members are not machines and work items vary in size and complexity, the amount of work that is completed will vary. The second release strategy fixes scope and team size while allowing duration to vary. The use of the first release strategy feels like a deviation from the classic PMI definition of a project; however when Mauricio and I discussed his response we ended up recognizing that in reality we had seen many standard projects use far less transparent techniques to vary scope. These techniques often include quietly cutting scope or spinning work off into follow-on projects. I suggest that scope is often varied to meet dates regardless of the framework used to deliver business value. This perception could be construed as difference in the definition of a project, albeit the difference is not huge.

The second perceived type of difference identified in the responses focused on project management attributes. Chris Vedete of The Carlyle Group stated his perception of the differences specifically, “Conceptually it is the transparency, feedback and tangible software.” Scrum, the most popular Agile technique, is built on the three pillars of transparency, inspection and adaptation. While classic project managers would argue that all project management techniques include those components, it should be noted that Scrum and other Agile techniques identify these attributes as core principles rather than outcomes of other attributes. Focus generates, at the very least, a perception of difference in behavior. The second category strays away from illuminating precise differences in the definition of a project to highlight differences in how people act when leveraging Agile techniques. This second type of differences, those related to project management attributes, does not reflect a difference in the definition of the word project.

In the end most of the difference is perceived. Where there are differences, such as different release strategies, these are often more a transparent reflection of how all projects really work. Kristie Lawrence, President of IFPUG, put it succinctly, “Conceptually no (there is no difference – ed.) – they both deliver working software, they both have teams of people working on them, they both have customers.” In Agile the definition of a project does not substantially differ from most common definitions. Therefore practitioners – whether using Agile, scaled Agile or some other set of techniques – should be able to develop a common language using the concept of a project.

One Side Or The Other!

One Side Or The Other!

As organizations transition to Agile, teams often ask about how to change from classic command and control project management methods into self-organizing teams. Self-organizing and self-managing teams do not just appear magically. Both the project teams and the organization have baggage that needs to be rationalized and unlearned to progress from needing to be lead to leading themselves. The concepts which have to be learned include the following: measuring business value, team decision-making and sharing the real goals of projects.

Classic command and control project management (which I would classify as minimally collaborative) is based on the premise that the project manager has both unique knowledge and a unique set of skills not held by members of the team.  These skills are thought to revolve around project planning, controlling the people, office politics and status reporting. Certifications, like the PMP®, have been used to encourage these belief.  In this environment the measures of success for projects are often delivering on-time, on-budget and on-scope.

In Agile projects, as discussed in Project Management is Dead, the roles of the classic project manager in Scrum are spread across the three basic roles (Product Owner, Scrum Master and Development Team). A fourth role, the Agile Program Manager (known as a Release Train Engineer in SAFe), is needed when multiple projects are joined together to become a coordinated program.  The primary measures of success in Agile projects are delivered business value and customer satisfaction.  These attributes subsume the classic topics of on-time, on-budget and on-scope. (Note: Delivered value and customer satisfaction should be the primary measure of success in ALL types of projects, however these are not generally how project teams are held accountable.)

As teams learn to embrace and use Agile principles, they need to learn how to make decisions as a team. The decisions that teams need to learn how to make for themselves always have consequences, and sometimes those consequences will be negative. To accomplish this learning process in the least risky manner, the team should use techniques like delaying decisions as late as is practical and delivering completed work within short time boxes. These techniques reduce risk by increasing the time the team has to gather knowledge and by getting the team feedback quickly. The organization also must learn how to encourage the team to make good decisions while giving them the latitude to mess up. This requires the organization to accept some level of explicit initial ambiguity that is caused by delaying decisions, rather than implicit ambiguity of making decisions early that later turn out to be wrong. The organization must also learn to evaluate teams and individuals less on the outcome of a single decision and more on the outcome of the value the team delivered.

Teams, on the other hand, have to unlearn bad habits. For example, teams need to unlearn the habit of relying on others to plan for them. In order to do that, all leaders and teams must have an understanding of the true goals of the project (listen to my interview with David Marquet) and how the project fits into the strategic goals of the organization.

Teams make decisions daily that affect the direction of the sprint and project. The faster these decisions are made the higher the team’s velocity or productivity, and having a solid understanding of the real goals of the project helps the team make decisions more effectively. Organizations need to learn how share knowledge that today is generally compartmentalized between developers, testers or analysts.

The process of learning and unlearning occurs on a continuum as teams push toward a type of collective self-actualization. As any team moves toward its full potential, the organization’s need to control planning and decisions falls away. If the organization doesn’t back away from the tenants of command and control and move towards the Agile principles, the ability of any team to continue to grow will be constrained.  The tipping point generally occurs when an organization realizes that self-managing and self-organizing teams deliver superior value and higher customer satisfaction and that in the long run is what keeps CIOs employed.