Listen Now

Subscribe on iTunes

The Software Process and Measurement Cast includes three columns.  The first is our essay on managing Agile projects and teams. I often say project management is dead. That does not mean that the pressures that drive the need to manage work have gone away. In the end the “what” of project management is important because control, discipline and coordination are needed tools to deliver value; the journey toward Agile is the reframing of the “how” of project management.

This week Gene Hughson returns with an entry from his Form Follows Function column.  Gene tackles the topic of whether the application of Conway’s Law makes microservices more of an organizational approach than an architecture.   After listening, check out Gene’s Form Follows Function blog!

The third column in this SPaMCAST magazine is from the Software Sensei, Kim Pries.  Kim tackles hardcore testing.  Kim discusses the implications and uses of this aggressive type of testing in hardware, software and wetware.

A great line up!

Call to action!

Reviews of the Podcast help to attract new listeners.  Can you write a review of the Software Process and Measurement Cast and post it on the podcatcher of your choice?  Whether you listen on ITunes or any other podcatcher, a review will help to grow the podcast!  Thank you in advance!

Re-Read Saturday News

We just completed the Re-Read Saturday of Eliyahu M. Goldratt and Jeff Cox’s The Goal: A Process of Ongoing Improvement which began on February 21nd. What did you think?  Did the re-read cause you to pick  The Goal back up for a refresher? Visit the Software Process and Measurement Blog and review the whole re-read.

Note: If you don’t have a copy of the book, buy one.  If you use the link below it will support the Software Process and Measurement blog and podcast.

Dead Tree Version or Kindle Version 

Next week we will begin re-reading The Mythical Man-Month. Get a copy now and start reading!

Upcoming Events

Software Quality and Test Management 

September 13 – 18, 2015

San Diego, California

http://qualitymanagementconference.com/

I will be speaking on the impact of cognitive biases on teams!  Let me know if you are attending!

 

More on other great conferences next week.

 

Next SPaMCast

The next Software Process and Measurement Cast will feature our interview with Woody Zuill.  Some people might think “that there is no Woody only Zuul” (apologies to the Ghostbusters) when it comes to topics like #NoEstimates.  However as Woody points out, it is important to peer past the “thou musts” to gain greater understanding of what you should be doing!

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.

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.

Listen Now

Subscribe on iTunes

This week’s Software Process and Measurement Cast features our interview Anthony Mersino, author of Emotional Intelligence for Project Managers and the newly published Agile Project Management.  Anthony and I talked about Agile, coaching and organizational change.  It is a wide ranging interview that will help any leader raise the bar!   We also talked about his new venture: Vitality Chicago.

We are having a contest! Anthony has offered a copy of his great new book to a randomly selected SPaMCAST listener, ANYWHERE IN THE WORLD.  Enter between February 22th and March 7th.  The winner will be announced on March 8th.  If you want a copy of Agile Project Management you have two options: send your name and email address to spamcastinfor@gmail.com (I will act as the broker and notify the winner at which point we can deal with other types of addresses), OR you can buy a copy.  Remember buying a copy through the Software Process and Measurement Cast helps support the podcast.

Dead Tree Version or Kindle Version

Anthony’s bio:
Anthony C. Mersino, PMP, PMI-ACP, CSP is an Agile Transformation Coach and IT Program Manager with more than 28 years of experience.  He has delivered large-scale business solutions to clients that include Abbot Labs, IBM, Unisys, NORC, and Wolters Kluwer, and provided Agile Coaching for The Carlyle Group, Northern Trust, Bank of America, and Highland Solutions.

Anthony is the author of Agile Project Management, and Emotional Intelligence for Project Managers.  He is also the founder of Vitality Chicago, an Agile transformation consulting firm focused on helping teams THRIVE and organizations TRANSFORM.

Contact information:

Email:
Anthony@ProjectAdvisorsGroup.com
AMERSINO@VITALITYCHICAGO.COM

Websites:
http://projectadvisorsgroup.com/about.html
http://www.vitalitychicago.com/

Call to action!

Can you tell a friend about the podcast?  Even better, show them how you listen to the Software Process and Measurement Cast and subscribe them!  Send me the name of you person you subscribed and I will give both you and the horde you have converted to listeners a call out on the show.

Re-Read Saturday News

The Re-Read Saturday focus on Eliyahu M. Goldratt and Jeff Cox’s The Goal: A Process of Ongoing Improvement began on February 21nd. The Goal has been hugely influential because it introduced the Theory of Constraints, which is central to lean thinking. The book is written as a business novel. Visit the Software Process and Measurement Blog and catch up on the re-read.

Note: If you don’t have a copy of the book, buy one.  If you use the link below it will support the Software Process and Measurement blog and podcast.

Dead Tree Version or Kindle Version 

Upcoming Events

CMMI Institute Conference EMEA 2016
March 26 -27 London, UK
I will be presenting. My presentation is titled “Agile Risk Management.”
http://cmmi.unicom.co.uk/

 

Next SPaMCast

In the next Software Process and Measurement Cast we will feature another magazine feature.  The features in next week’s podcast include columns from Gene Hughson, discussing micro-services. Jo Ann Sweeney Explaining Change and our essay on Agile Coaching.  Coaches help teams and projects deliver the most value, however many times organizations eschew coaches or conflate management and coaching.  Both actions rob teams and organizations of energy and value. We discuss why next week.

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.

Make sure the path is clear before you embark.

Make sure the path is clear before you embark.

Rescuing a troubled project takes more than waving a magic wand and it almost never makes sense to immediately dive in and begin making changes.  As noted before, projects get in trouble one decision at a time, having a process to gather information about the project and then plan the intervention reduces the risk of adding to the burden of bad decisions.

UntitledAssess the Project: The first step is to determine whether the project is really troubled and warrants an intervention or, even more importantly, whether the project can be saved.  The process for assessment will be reviewed in the next installment.

Plan the Intervention: Once you have assessed a project and determined that a rescue makes sense, the intervention needs to be planned.  Use an Agile approach to planning the rescue process. That is, start by building and prioritizing a backlog based on the assessment.  Using the prioritized backlog the changes can be grouped into releases (a change release plan) that avoids a big bang approach. Big bang approaches might be required if the project requires a critical level of intervention, however the big bang approach requires a lot more coordination. Just like in any Agile project, the backlog is dynamic and change the intervention progresses. It is important to involve the appropriate team(s) in planning the implementation because it will help to build commitment.

JumpStartsm the Rescue: The JumpStartsm should use the following steps:

  1. The team should stop what is to be changed cold turkey,
  2. Show the team the team how to do the new technique by performing the task with the team,
  3. Gather immediate feedback and tailor the process,
  4. Transfer technique ownership with just-in-time training and coaching, and
  5. Withdraw coaching as the team gains confidence.

Coach the Team: After the JumpStartsm, you need to maintain effort to keep the project on the straight and narrow until the new set of behaviors can become muscle memory. A coach provides a constant addition of energy into the process so that the team does not revert to old behaviors. Think about any sports team you have practiced on. The coach’s role is to support the team, but it is outside of the three standard Scrum roles. One of the primary roles of coach (as opposed to the manager) is to provide training and feedback so the team members can improve.

Celebrate: Change is difficult and those doing the changing will require feedback to continue to change. Feedback needs to include both positive and negative components to be effective in the long term. Celebration is a component of the positive feedback.  Celebrate getting the project moving in the right direction; don’t wait for the end of the project or a release to provide positive feedback.

There are lots of troubled projects and there are a wide variety of reasons projects get in trouble. Before we intervene, we need to decide whether intervening makes sense, and if it does, then we need to make sure we have a plan.  A poor or unplanned intervention can lead to project failure just as easy as doing nothing will.  Most IT departments would rather avoid the black eye of a failed project. Therefore you need to have a process in place for intervention. It will pay benefits because then there will always be a bias for action.

Don't just outlaw problems, facilitate a solution.

Don’t just outlaw problems, facilitate a solution.

The difference between facilitating and enabling is at the core of the Agile concept of self-organizing and self-managing teams. An effective scrum master should be a facilitator in a well functioning Agile team. However, when there is a breakdown in a self-organizing and self-managing team, sometimes scrum masters become enablers. This makes scrum masters more like project managers. A facilitator helps to unstick something that has stopped or creates an environment where progress can be made by the team.  An enabler provides the team with permission for making a decision.  For example, I recently watched as a team asked their scrum master if they were allowed to hold an interim show and tell/demonstration to prompt the product owner for feedback. The team saw the scrum master as an enabler rather than a facilitator.

Providing permission to the team to make decisions shifts the risk and from the team to the scrum master.  In the past we had a term for the decision maker role on a team: a project manager. The enabler is someone who sees a logjam and then provides the team with a solution and then ensures that the solution is taken.

On the other hand, a facilitator helps the team to make a decision.  A facilitator uses techniques such as asking questions and then helping the team to listen to the answers. Asking questions helps the team to frame or reframe the issue so that they can develop their own solution. By finding their own solution teams increase their ownership of the solution; it is no longer the project manager’s responsibility to make decisions for the team. For example, when a facilitator observes that a team is having issues working together, he/she will make sure everyone gets their issues on the table during a retrospective. During the retrospective, the facilitator will use a technique that will create an environment that will help the team get to the root cause.  The facilitator will continue to ask probing questions until the team identifies the issues.

In the same scenario, an enabler is apt to present the team with his or her definition of the issue (and potentially with a solution). While providing the problem and solution might seem like a more efficient use of time, it will not provide the team with a learning moment.  In the long run the team will become dependent on the enabler to identify and solve their problems. Having everyone on team learn to identify and solve teams problems leads to less time waiting for someone else to solve problems.

Here’s a quick framework to use in order to decide if you are a facilitator or an enabler:

  • Facilitators ask questions. Enablers provide answers.
  • Facilitators listen to understand. Enablers listen to act.
  • Facilitators help things to happen. Enablers make things happen.
  • Facilitators make strong teams. Enablers make strong individuals.

The primary role of a scrum master is that of a facilitator. Making decisions for the team creates a dependency that defeats the whole idea of a self-organizing and self-managing team.  A facilitator makes the team stronger by helping them to learn to make decisions and find their own voice.

As a team self-actualizes the need for command and control management falls.

As a team self-actualizes, the need for command and control management falls.

As organizations transition to Agile, teams often ask about how to transition from classic command and control project 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 led to leading themselves. The concepts that need to be learned include: measuring business value, team decision making and to share 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 a unique set of skills for project planning, controlling the activities of the team and status reporting. Certifications, like the PMP, have been used to encourage this belief.  In this environment the measures of success for projects are being on-time, on-budget and on-scope.

In Agile projects, as we have discussed in earlier  Daily Process Thoughts, the roles of the classic project manager are spread across the three basic Agile roles (product owner, Scrum Master and the development team). A fourth role, the Agile Program Manager, is needed when multiple projects become a coordinated program.  The primary measures of success in Agile projects are delivered business value and customer satisfaction. (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 have consequences, and they will be wrong sometimes. 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 using time boxes. These techniques reduce risk by increasing the time the team has to gather knowledge and to elicit feedback. The organization also must learn how to encourage the team to make good decisions. 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 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 also have to unlearn habits, for example, 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 designs daily that affect the direction of the sprint and project. The faster these decisions are made the higher the team’s velocity or productivity. 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 the 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 because the organizations leadership owns the definition of career success. 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).