No Guardrails Needed

Guardrails are a tool to ensure alignment with the organization’s goals and objectives and to keep people on the right path, but they are not effective in all circumstances. Three circumstances that lead guardrails to be less useful include: (more…)

Sometime you need something to keep cars off of the sidewalk!

Guardrails are a tool to ensure alignment with the organization’s goals and objectives and to keep people on the right path. Guardrails are an everyday fact of life. Several years ago, I was on vacation in Lima, Peru. During the vacation, we ventured into the heart of the city to see the sights, at the end of the day four of us piled into a cab on a very crowded street to go back to the hotel. Mass was just ending at the cathedral and there were throngs of people taking to the street. The driver inched along for a few minutes then pulled the car up on the sidewalk and began rocketing forward (the rocketing part is my recollection). I still wake up occasionally picturing people diving into doorways. Jason Bourne had nothing on this guy. In most societies, there are laws, standards or just social norms about driving on the sidewalk.  I was in India for the past two weeks. When we in touring Mysuru, several coroners had physical barriers (concrete and metal poles) to keep cars from cutting corners and driving on the sidewalk.  Both of these examples represent types of guardrails. Guardrails channel behavior for the benefit of the greater society by abridging, formally or informally, the range of action individuals can take. Breaking through a guardrail requires a conscious decision. Software development, in all of its forms, requires guardrails unless every decision made by a team is scrutinized and approved before it is made. Without guardrails words and phrased like self-directed and empowered teams are hollow.  In order for guardrails to be effective, there need to be a few simple’ish guardrails for the guardrails: (more…)

A Sweet Spot!

In the essay, Balancing Control and Self-Organization to Avoid Heat Death I said that there is a need to strike a balance between controlling how individuals and teams work and just letting people do their own thing.  Stated slightly differently, there needs to be a balance between autonomy and control.

Finding The Sweet Spot!

In a world where organizations like Theranos (over control) and the City of Flint, Michigan (laissez-faire crisis management) exist, organizations have to find a way to make sure they attain their goal without killing the company or injuring their customers. A framework that guides how workflows and decisions are made provides structure so that decisions can be made when a crisis occurs (crises are inevitable). Too much or too little control makes decision making more difficult when a crisis occurs. Every organization has to find a balance between control and autonomy. Every organization and team will have a specific Goldilocks answer. This is true for whole organizations as well as software teams that have embraced agile frameworks and methodologies.  One size does not fit all without a bit of tailoring. This premise is not the controversial part of our last essay, the problem is that the word control bothered some of the readers. (more…)

Book Cover

This week we tackle chapter 20 of L. David Marquet’s Turn the Ship Around! (have you bought your copy?). Chapter 20 completes part 3 which has focused on competence and the run-up to the deployment of the Santa Fe. The title of this chapter is Final Preparations.  We have six or seven weeks left  – Steven Adams is pushing for re-reading Release It, the other option is The Checklist Manifesto.  Both are great . . . thoughts? (more…)

Listen Now
Subscribe: Apple Podcast
Check out the podcast on Google Play Music

SPaMCAST 494 features our interview with Alan Mallory.  We discussed his book The Family That Conquered Everest (  The book provides strong lessons on leadership and teamwork in an environment where failure can lead to death or worse!  Danger, mountaineering, and leadership in a single interview; a first for the Software Process and Measurement Cast.

Alan’s Bio

Alan Mallory is an international speaker, author and performance coach who is passionate about leadership and human performance. A graduate from Queen’s University, he has worked internationally with large organizations as a professional engineer and project manager. Living and working abroad has given Alan the opportunity to deepen his understanding of individual and team challenges, better appreciate cultural diversity and successfully adapt to different organizational structures. Through his work and life experiences, he has discovered that his true passion is helping people reach new heights by cultivating effective ways of thinking and taking action. Building experience through a lifestyle of adventure and challenge, in the spring of 2008 Alan embarked on the journey of a lifetime: to attempt to reach the summit of Mount Everest. Along with three members of his immediate family, Alan climbed through some of the most challenging yet exciting conditions imaginable and set a world record when all four of them set foot on the summit. The expedition involved two years of planning and two months of climbing through immense challenges but they were able to overcome these obstacles through strategic planning, healthy team dynamics, self-awareness and perseverance. Alan delivers a number of exciting presentations and training programs designed to help individuals, team members and organizations reach new heights in the way we think and the actions we take in order to achieve breakthrough performance. For more information, visit

Phone: 647-388-4044



Re-Read Saturday News

In week nine of the re-read of L. David Marquet’s Turn the Ship Around! we discuss chapters 12 and 13, titled Up Scope! and ”A New Ship”.

Current Installment:

Week 9: Up Scope! and ”A New Ship” (more…)

Picture of the book cover


Staff liquidity takes a central position in this week’s installment of our read of Commitment – Novel about Managing Project Risk by Olav Maassen, Chris Matts and Chris Geary (2nd edition, 2016) .  Chapter 5 is a relatively short chapter, but exposes one of the critical mechanisms for how Agile teams are able to self-organize and self-manage.  If you are an Agile coach or involved in an Agile transformation, once you recognize the concepts in this chapter you will be surprised how many times you use them.  If have been struggling with the concept how Agile teams can handle the need to shift roles to address changes in needs with management intervention this chapter provides you with the knowledge you will need.    (more…)

Picture of the book cover


This week we are back to our read of Commitment – Novel about Managing Project Risk by Olav Maassen, Chris Matts and Chris Geary (2nd edition, 2016) .  Chapter 4 introduces more agile techniques, including work visualization, staff liquidity and a focus on outcomes. (more…)

The dwarfs of self-management are Committed-y, Hardworking-y, Assertive-y and Doc.

The dwarfs of self-management are Committed-y, Hardworking-y, Assertive-y and Doc.

Effective teams are self-managing. Self-managing teams plan and manage their day-to-day activities with little overt supervision. In order for teams to be self-managing individual team members have team have to be committed to the team, have a clear understanding of roles and capabilities, understand the concept of deadlines and be effectively assertive.

  1. Commitment: Team members must be committed to the team. All teams will go through periods of stress and conflict, committed team members will stay with the team and seek to work through issues. Commitment can only occur if team members believe that the team can succeed and that membership will have value to the individual.
  2. Clear Understanding: The ability to self-manage requires an understanding of the roles that individuals can and do play and their capabilities. For example a business analyst that does not understand how to read C++ can’t be asked (or volunteer) to review C++ code. An understanding of roles and capabilities allows the team to plan effectively, to evaluate performance and provide feedback to fellow team members.
  3. Deadlines: One of more important features of Scrum is the public affirmation to complete the stories accepted into a sprint. The affirmation is a commitment that the team must strive to meet. When teams commit to a specific delivery deadline they need to strive and strive hard to meet those goals.
  4. Being Assertive: Team members need to be assertive enough to initiate action, provide feedback, communicate and coordinate activities between team members. Every team member has the authority and responsibility to get the job done.  The ability to be effectively assertive means that team members have to interact so that communication occurs and does not actively to cause conflict.

In order for a team to self-manage, the team will need to exhibit all four attributes, failing any of the four self-management becomes difficult. All four attributes are a reflection of team self-knowledge. Teams that stay together and successfully deliver value to the organization tend to form bonds based respect and mutual support.

Religion is just one way people learn ethics.

Religion is just one way people learn ethics.

I recently overheard an offhanded comment that went something like, “if you aren’t cheating, you’re not trying hard enough.”  What are ethics?  What is the purpose of ethical frameworks?  Why should they matter to those who manage process improvement?

Wikipedia defines ethics as a branch of philosophy that addresses questions about morality—that is, concepts such as good vs. bad, noble vs. ignoble, right vs. wrong, and matters of justice, love, peace, and virtue.  Hardly the stuff of project management or process improvement, however there is a branch of ethics called applied ethics (doesn’t that sound much more practical?) that seeks to address our daily business lives.

Interest in ethics waxes and wanes over time; they tend to wax when things go awry.  Obvious examples abound, like when Enron  went up in flames, ethics became a hot topic, at MCI during their accounting debacle and even during the BP Oil well crisis. But there are less obvious examples such as the spin to under play a risk in a status report or when someone occasionally conflates effort and progress when a project is behind.  Unless a framework or code is in place to highlight these transgressions, large or small, they go unnoticed and nothing can be changed.

Most ethical frameworks serve two common purposes. The first purpose is to guide behavior so that it is predictable.  Codes of conduct provide a path to guide both the organization’ and the individual’s actions (to an extent they can be different).  Codes of ethics, codes of conduct and the effort to enforce them help to identify deviant behavior before it can injure the organization. The second purpose is as an announcement to the larger world of the higher order rules an organization intends to follow.

The ethics enshrined in these frameworks evolve to guide behavior and provide all affected parties with an understanding of how people (and people proxies) should act.  Rules, laws and manifestos (statements of principles and ethics) are how ethics are applied in the real. The rule, “Thou shall not install un-unit tested code” creates a set of expected behaviors and a set of obligations on all parties.  Living up to the rule is a matter of ethics.  The translation of ethics into codes of conduct, rules, laws or other codes provide a line in the sand so that you can judge whether an action is ethical or not.  The more black and white the ethics rule is the easier it is to follow in real time.

Most corporate codes of conduct or ethics do not address some of the more specific issues with which a project manager of a process improvement projects will need to wrestle.  What can be done?

I begin my process improvement projects by establishing a process improvement manifesto.  The exercise has many benefits; however the primary goal is to help empower the team to make the decisions without having to get permission.  The manifesto acts a basis to form very specific code of ethics to shorten the decision making loop which will improve efficiency for normal IT projects and process improvement projects.

He's looking at you...

He’s looking at you…

Who is responsible for results on a sprint team? I was once asked “whose throat I should step on when the project is in trouble?” In a classic project, the answer would be the project manager (or a similar position). In an Agile project that is living up to the principles espoused in the Agile Manifesto, the answer is a bit messier and that messiness makes a command and control leader very nervous.

Agile projects using Scrum as their organization and management framework have three basic roles: product owner, scrum master and team. If we were looking for a throat, which one would we select? The product owner owns the backlog, the budget, is charge of prioritizing the work and provides leadership. The scrum master coaches, teaches and generally facilitates the team while removing barriers to performance and provides leadership. The whole team plans the work, tackles issues and swarms to problems and individuals provide leadership when necessary. Agile teams are self-organizing and to an extent self-managing (the organization generally decides on which projects get done based on strategic plans). The whole team is involved in planning the work and, at least at situational level, everyone on the team can provide leadership. If you were to ask the members of an Agile team to point at who is in responsible, you might not have many people pointing in the same direction. Therefore is the answer that no one is responsible?

No, rather everyone on the team is in charge.  Everyone on the team is accountable for meeting the goals that the organization sets out as interpreted by the product owner (through the backlog) and accepted by the team.  The planning activities of public acceptance and commitment to the goals and stories of the sprint creates a pressure to do what has been committed. Demonstrations act as the bookend to the public commitment with the team publicly showing how they performed against the goals they committed to attaining. If we assume that the team is empowered to attain the goals they have committed to attaining, then the team truly is responsible as a whole.

Answering that the team is responsible sounds way too squishy for some organizations. In the end, whoever controls the budget is the person that should be accountable. This suggests that the product owner should be responsible or IT management if the budget is allocated as overhead. Neither of these scenarios is conducive to empowering a self-organizing team.

Who is in charge of a typical sprint team? Every person on the team is responsible for holding each other accountable for meeting their goals. The product owner and scrum master have a direct hand in setting and facilitating the goal, therefore everyone on the team is both accountable and responsible. The layers of interlocking responsibility produce significant peer pressure. That means that every team member can truthfully say that they ARE responsible for the project.