Program Managers and Decision Rights

In scrum there is no project manager role, however the function remains and is distributed across the team.  The program manager generally remains for large strategic initiatives.  This role makes sense at a portfolio level as there is more coordination across the firm with respect to large dollar investments made by the business.

The program manager is often responsible for making sure technology does not go over the budget allocated for the program.   Program budgets are often set well ahead of scrum team involvement.

When the program manager is held accountable for:

• defined scope 
• defined budget, and 
• defined scrum teams 

You have  iron triangle as defined budget and defined scrum team allocations equates to fixed timeline.  The program manager will naturally slip into driving what the team works on and in what sequence based on budgetary concerns.  This clearly breaks the rules of scrum where the Product Owner determines what is most important for the team to work on.  The team begins to regard the program manager as the primary decision maker.  This impedes the team from getting to any level of self organization or empowerment.

Program Management approached with an agile mindset looks like:

• The Product Owner has X dollars to spend on project Y
• The backlog contains the stories representing the scope of work for project Y
• The backlog is sized by scrum teams who will be doing the work
• The scrum team contains team members with all skill sets needed to deliver the business value
• The scrum team has a predicted throughput as they have been sprinting for at least 3 sprints

From a planning perspective, the program manager can use the empirical data to explore the number of sprints needed to deliver full business functionality.  At the end of every sprint, compare execution against forecast.  Inspect and adapt.  The program manager is responsible for transparently sharing the margin of error between execution and forecast to facilitate the appropriate decision making.

Why Hyper Performing Teams are so Rare?

I have seen this pattern in multiple companies.   The decision is made to improve the agile process, hire agile coaches, increase the throughput of the teams.

If the desire to improve and change is not positioned at the right level of authority in the organization, this is an exercise in futility.  There can be some gains at the team level, but without an aligned concerted effort along with a process to escalate impediments, the needle will not move forward for the organization as a whole.

Transparency and alignment of vision is the most important thing to establish at the team level.   I have however encountered layers in organizations where information can stagnate and is only shared with lower levels in the organization on a need to know basis.

This is interesting, because we know that sharing vision and driving decisions to the lowest possible level in the organization speeds everything up.  However there is often the layer of "people who know things" that have a vested interest in maintaining the position of power and authority.

I recently heard world-renowned business educator and coach, Dr. Marshall Goldsmith speak about how to motivate someone who has no interest to change.  In the interview Dr. Goldsmith says he "learned from Peter Drucker that every decision in the world is made by the person who has the power to make the decision, make peace with that."

This is extremely relevant if we consider that in the above description, the layer of "people who know things" also have the power to make the decisions, it becomes very clear why hyper-performing teams are so rare.

Something is amiss in our cross team communications.

Our teams use an invitation vs. imposition approach to process.  Meaning teams can decide what process works well for them within the guardrails of the Agile Principles:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
Business people and developers must work
together daily throughout the project.
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
Continuous attention to technical excellence
and good design enhances agility.
Simplicity--the art of maximizing the amount
of work not done--is essential.

We recently had a high priority cross team initiative bubble its way to the top of the backlog for three different teams.  We decided to experiment with a Project Inception where we invited representatives from the three teams to a 1 hour meeting to hear from the PO why this is an important initiative for the business to deliver by X date, the architect reviewed the overall design and the teams asked questions and discussed which teams were doing which pieces.  The teams were asked "should we have a Scrum of Scrums for these three teams"  They answered no, lets communicate by email.

So what happened?   As the first important milestone (checkpoint meeting to validate the approach will work in the time frames needed) approached, it was not clear what the inputs would be and how the decision would be made.  So an email thread was started and ended with a functional manager taking all the inputs and creating a spreadsheet of milestones and target dates.

Teams did not pay a lot of attention to the milestone dates or to the content of the milestones.  Totally makes sense for engineers to focus on the work captured in JIRA and in the current sprint.  Teams started to express concerns for what the other teams are committed to.   Why wouldn't they as there was no insight into how other teams were progressing.

With the best of intentions the servant leaders in the organization were actually enabling the teams to NOT communicate the appropriate level of detail around the work at hand.  Teams focused on the work in their backlogs and sprints and left the cross team dependencies to be tracked and worried about by architects, managers, and scrum masters.

This is not a great model to scale, and it causes inefficient and extra communication.  A scrum of scrums allows for a light weight way to have the right conversations with the right people and removes the layer of  abstraction added when we start talking milestones that comprise multiple JIRA stories.  The devil is in the details here, and the people doing the work are best suited to discuss these details.

We will start a scrum of scrums next week.

Authenticity and Agility

From Wikipedia
Authenticity is a technical term used in psychology as well as existentialist philosophy and aesthetics (in regards to various arts and musical genres). In existentialism, authenticity is the degree to which one is true to one's own personality, spirit, or character, despite external pressures; the conscious self is seen as coming to terms with being in a material world and with encountering external forces, pressures, and influences which are very different from, and other than, itself. A lack of authenticity is considered in existentialism to be bad faith.^[2]



Today I listened to a very thought provoking sermon about authenticity.  I realized  I used to have separate lives, a work life and a personal life.  I kept my personal values separate from work, in order to "fit in" and progress my career.

I think the person who takes a job in order to live - that is to say, (just) for the money - has turned himself into a slave.

Joseph Campbell (1904 - 1987)

Wisdom comes with age and experience.   The lens through which we see the world is shaped  by our experiences.   I was lucky to have the opportunity to experience events that inevitably reminded me of the importance of my values.  Over time career goals moved  into an area very closely aligned with my personal values, Agile Coach in a organization that values invitation over imposition.


The greatest joy in life is to live authentically.

When we quit thinking primarily about ourselves and our own self-preservation, we undergo a truly heroic transformation of consciousness.

Joseph Campbell (1904 - 1987)

Avoiding the game of Telephone

I often find myself in the space between teams and executive leadership.  This is the space where transparency in both directions will catapult an organization to hyper productivity.

I have worked with different product development organizations over the years and have seen complete open transparent communication that resulted in the illusive hyper productivity.

Here are some of the key things that I attribute to the success:

1.     Visible prioritized list of areas of focus for the entire organization.  

2.     Weekly dashboard report via email and screen display around the office from each scrum team.

3.     Weekly 1/2 hour Opt In all company review of Kanban board which comprised all work in flight across the entire organization.  The board columns showed Epics from ideation through to scrum team implementation.

4.     Essentially a flat organization with an open door policy from CEO to new employee in training.  

In the absence of transparency, there are stories told at different layers of an organization to articulate the status of any given initiative.  The stories told are very rarely aligned, quite like the game of Telephone we all played as children.  

An organization relying on meetings and communication plans to propagate information, are missing the opportunity to leverage an open transparent environment where fluid status is more readily available for everyone who wants to be informed.  

My Unitarian Ulniversalist Roots

I am Agile to the core of my being!  What can this possibly mean and why did I name my blog "Agile to the Core"?

There are some truths that I just know.  There is an old saying that everything happens for a reason.  I can trace the path of my experiences and see how I landed where I am today with such a great passion to do this work in the world.

I recently attended a service at Arlington Street Chuch (ASC) where I heard Kim Crawford Harvie's sermon entitled "The Holy in Disguise"  the sermon told of the beginning of the Univeralist faith which ultimately joined with the Unitarian faith to become what is today known as the Unitarian Univeralist faith.  There was a phrase from the sermon that really stuck with me, it was "faith without dogma".

Almost every sermon I hear from Reverend Kim, starts with we are Unitarian Universalists, we believe that revelation is not sealed..  I love this line, we are all empowered to discover our own truths.

When I served on the ASC Prudential Committee, we ended every meeting by singing this lovely hymn  "Its in every one of us to be wise, find your truth, open up both your eyes, we can all know everything without ever knowing why, its in everyone one of us by and by".

The UU principles are to affirm and promote:

• The inherent worth and dignity of every person;
• Justice, equity and compassion in human relations;
• Acceptance of one another and encouragement to spiritual growth in our congregations;
• A free and responsible search for truth and meaning;
• The right of conscience and the use of the democratic process within our congregations and in society at large;
• The goal of world community with peace, liberty and justice for all;
• Respect for the interdependent web of all existence of which we are a part

I think most of these values are also embodied in the agile values.  I recently attended the Agile 2015 conference in Washington and had the opportunity to meet so many wonderful Agile practitioners, who are out in the world do this hard work to make our corporations better places to work.  I could not help but feel that I was with my tribe!