Picture of the book cover

Commitment

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

Commitment

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.

The IFPUG Board of Directors is a self-managing team.

The IFPUG Board of Directors is a self-managing team.

We use terms like self-organizing and self-managing when describing Agile teams. A self-organizing and self-managing team will determine, plan and manage their day-to-day activities rather than being directed by an appointed project manager. The critical word in those phrases that cause stress between Agile teams and project managers is ‘self’.  The word self tends to give organizations pause, because most organizations have been developed with the expectation of using command and control management techniques rather than the Agile concept of  self-directed teams to control projects.  In the simplest terms, command and control management says that a leader will tell a follower what to do and when to do it. Realistically true command and control management has NEVER worked in the IT environment, however in many organizations there is still an expectation that the project manager will control the management of a project.  In Agile projects, the expectations are fundamentally different.

Conceptually, project managers are charged with controlling the scope, schedule and cost (the iron triangle) of their project.  In controlling one or more of the basic attributes of the iron triangle, the project manager can control the quality of what is delivered.  The problem is that this view represents an illusion of control rather actual control. The project manager generally does not write and test the code, nor do they know the specific tasks to pull off that transformation.  What the project manager does, in many organizations, is the facilitation of meetings, creating status reports and administration. This misses the point of what project management should really deliver – which is leadership. Project management many times has shifted from a leadership position to one of project comptroller.

In an Agile environment, the illusion of control is debunked based on the premise that you can’t manage what you can’t control and, in reality, only the team can control its own behaviors. As we have noted, the roles of the project manager have been distributed to the team, who is better able to control scope, schedule and cost.  The team uses self-organization to plan and execute the activities required to deliver the functionality they have committed to deliver.  The team can realign its resources based on feedback as a mechanism to meet the needs of the organization.  Agile teams replace the illusion of control through a project managers with techniques of self-organization and self-management.

The seeds of stress between the PMO and project managers and Agile teams are sown in the term ‘self’: self-organizing and self-managing. Organization and control are the areas of activity that typically have fallen into the bailiwick of project management. The stress between the concepts of organizational control of team and self-management reflects a conflict of voices that will only recede as the two cultures merge and personnel are redeployed to deliver value more effectively.