SPaMCAST 588 – Project Management: It’s All Bollocks, An interview with Susie Palmer-Trew and Peter Taylor

http://www.spamcast.net

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) 

 

Five Reciprocal Agreements In Agile

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.

 

Reciprocity and Reciprocal Agreements In Action

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.

 

SPaMCAST 462 – Jon M Quigley, Project Management for Automotive Engineers

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:

jon.quigley@valuetransform.com

http://www.valuetransform.com/

https://www.linkedin.com/company/value-transformation-llc

https://www.linkedin.com/in/jonmquigley

Here is a promo for my upcoming ITMPI Webinar!

 

Hatching a Catastrophe, Re-Read Saturday: The Mythical Man-Month, Part 14

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

 

Projects In Agile

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.

 

Agile Project Management: The Tipping Point (Refined)

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.

 

Project Management Is Dead (Refined)

An Eternal Flame.

In Mastering Software Project Management (J Ross Publishing 2010), Murali Chemuturi and I define software project management as the activities required to plan and lead software projects.  Historically, IT projects and most non-Agile frameworks have identified a single person to play this role.  Programs, which are made up multiple projects, include multiple project managers that report to program manager. However, many forms of Agile now have eschewed the role of the project manager and instead distributed the activities associated with project management across the core team, including the product owner, the development team and the Scrum Master. Project management as a role is dead, long live project management the concept.

The product owner is responsible for managing a number of the activities that the project manager or administrator would have been tasked with in the past.  The primary role of the product owner is to own and manage the product backlog. Managing the backlog includes the activities of prioritizing backlog items and determining the release plan (including scope and date).  Managing the backlog in many organizations also means the product owner manages the budget, communicating progress, and interacts with external the stakeholders.  The product owner acts as a leader, providing the team with a direction using the backlog. He or she manages the backlog as a tool to exhibit that leadership.

The development team members also pick up some of the project management tasks.  The development team is responsible for identifying and managing the tasks needed to deliver the work they have committed to complete. The development team roles mix creation and innovation with control and management, using techniques such as peer pressure, stand-up meetings and pair working.

The Scrum Master is responsible for facilitating, coaching and motivating the team.  Scrum Masters guide teams so that they learn and use Agile techniques, confront delivery problems as they occur and work together as a well-oiled unit. The Scrum Master also serves as a shepherd to stave off interference from outside the team’s boundaries. The Scrum Master interacts with a team or teams, and then let the team members synthesize and internalize the advice. The Scrum Master is the team’s tactical coach.

In Agile, project management is dead, at least as a single role that leads, directs, controls and administers a project team because those roles are distributed to the team. I was once asked, “In an Agile project, who is the single person I can put my foot on their throat to motivate?”  Without dignifying the question, in an Agile environment the answer is far less obvious than pointing to a project manager.  The role simply isn’t filled by a single project manager. Now these responsibilities and tasks are distributed to those who that are actually have both the authority and responsibility for project execution.

 

Negotiating – BATNA

Cabbage or Onion, Which Can I Afford?

“All the worlds a negotiation, and all the men and women merely players” (apologies to William Shakespeare As You Like It, Act II Scene VII).

When done correctly, negotiating is like a play in which the parties are still working out the final scene. Each party will have an idea of what the scene will be like; however the scene may never happen so they need to have a fall back plan. In negotiation terms that fallback plan is called the best alternative to a negotiated agreement or BATNA. The term BATNA was originally coined by Roger Fisher and William Ury in their 1981 their book Getting to Yes: Negotiating Without Giving In. Every project manager, Scrum master, product owner, developer and tester is involved in countless negotiations on a daily basis. Those negotiations can be as trivial as were to go to lunch or as momentous as whether a specific feature will be included in a release. One of most common failings of an untrained negotiator is to not identify their BATNA BEFORE they begin negotiations.

Establishing a BATNA provides a negotiator with more negotiating power. Knowing what your alternative is before you start negotiating allows a negotiator to understand what they can concede and where they have to push to attain their goals. Not having a BATNA can lead to a negotiator conceding too much or needlessly digging in their heels.

We have noted that cognitive biases affect how people interpret data. One common bias that affects negotiations is the outcome bias. A person (or group) afflicted with this bias judges a decision by its eventual outcome instead of how they arrive at the decision. The single-minded pursuit of the final outcome of the negotiation, for example a new contract or a new house, leads the party with this type of bias to make the wrong concessions, often leading to buyer’s remorse. Establishing a BATNA before the negotiations begins provides an anchor (another form of bias) that can be used as a flag to indicate when walk away.

BATNA is a very simple concept. BATNA represents what you will do if you fail to get an agreement at the end of a negotiation. Simply put, BATNA is the best you can do when the other party stops negotiate and you can not agree to that position. Without a clear understanding of your BATNA, it is difficult to determine when to accept, draw the line or walk away. For example, once on a family vacation our Subaru Legacy broke down in rural New York State. We found the only person that could work on a Subaru to look at the car. Because they were the only dealer in over a 100 miles we determined that we had two options other than accepting their repair estimate. Our BATNA was either to buy a new car or have our car towed home and take the bus back to Cleveland. Neither were good options. Luckily the dealer’s estimate was VERY reasonable. However we prepared in case we had to negotiate more strenuously or had to walk away.

 

SPaMCAST 320 – Alfonso Bucero – Today is a Good Day

http://www.spamcast.net

 

Listen to the Software Process and Measurement Cast 320

SPaMCAST 320 features our interview with Alfonso Bucero. We discussed his book, Today Is A Good Day. Attitude is an important tool for a project manager, team member or executive.  In his book Alfonso provides a plan for honing your attitude.

Alfonso Bucero, MSc, PMP, PMI-RMP, PMI Fellow, is the founder and Managing Partner of BUCERO PM Consulting.  He managed IIL Spain for almost two years, and he was a Senior Project Manager at Hewlett-Packard Spain (Madrid Office) for thirteen years.

Since 1994, he has been a frequent speaker at International Project Management (PM) Congresses and Symposiums. Alfonso has delivered PM training and consulting services in Spain, Mexico, UK, Belgium, Germany, France, Denmark, Costa Rica, Brazil, USA, and Singapore. As believer in Project Management, he teaches that Passion, Persistence and Patience as keys for project success.

Alfonso co-authored the book Project Sponsorship with Randall L. Englund published by Josse-Bass in 2006. He has authored the book Today is a Good Day – Attitudes for achieving project success, published by Multimedia Publishing in Canada in 2010. He has also contributed to professional magazines in Russia (SOVNET), India (ICFAI), Argentina and Spain. Alfonso co-authored The Complete Project Manager and The Complete Project Manager Toolkit published with Randall L. Englund published by Management Concepts in March 2012. Alfonso published The Influential Project Manager in 2014 with CRC Press in the US.

Alfonso has also published several articles in national and international Project Management magazines. He is a Contributing editor of PM Network (Crossing Borders), published by the “Project Management Institute”.

Contact Alfonso: alfonso.bucero@abucero.com
Twitter: @abucero
Website: http://www.abucero.com/

Call to action!

We are in the middle of a re-read of John Kotter’s classic Leading Change on the Software Process and Measurement Blog.  Are you participating in the re-read? Please feel free to jump in and add your thoughts and comments!

After we finish the current re-read will need to decide which book will be next.  We are building a list of the books that have had the most influence on readers of the blog and listeners to the podcast.  Can you answer the question?

What are the two books that have most influenced you career (business, technical or philosophical)?  Send the titles to spamcastinfo@gmail.com.

First, we will compile a list and publish it on the blog.  Second, we will use the list to drive future  “Re-read” Saturdays. Re-read Saturday is an exciting new feature that began on the Software Process and Measurement blog on November 8^th.  Feel free to choose you platform; send an email, leave a message on the blog, Facebook or just tweet the list (use hashtag #SPaMCAST)!

Next

In the next Software Process and Measurement Cast we will feature our essay on the requirements for success with Agile.  Senior management, engagement, culture and coaches are components but not the whole story

Upcoming Events

DCG Webinars:

Agile Risk Management – It Is Still Important
Date: December 18th, 2014
Time: 11:30am EST
Register Now

The Software Process and Measurement Cast has a sponsor.

As many you know I do at least one webinar for the IT Metrics and Productivity Institute (ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI’s mission is to pull together the expertise and educational efforts of the world’s leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars. The Software Process and Measurement Cast some support if you sign up here. All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you. Support the SPaMCAST and learn from the ITMPI.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.