OnPoint, LLC

Organizing for Agility

When applying agile principles and practices at a team level, designing a project-based cross-functional team appears to be pretty straightforward. One “simply” finds some good developers, analysts and QA people, selects an appropriate product owner, assigns a scrum master, secures a co-located room and allows them to develop as a team. When organizations attempt agility at scale, cross-functional team design collides with existing organization structure, which is typically organized around function, activity, or knowledge base. How does one structure many (perhaps scores) of cross-functional teams without creating agile silos that reinforce inter-team dependencies and hand offs? Following are some general principles that can be applied to specific organizational contexts:

  • Employ a model of continuous delivery or flow of value instead rather than projects with distinct starts and stops
  • Create long-lasting teams organized around the business value rather than short-term teams organized around activity or projects
  • Seek to optimize the entire value system rather than ensuring that individual subject matter experts are 100% utilized

If you are contemplating an organization redesign, please review the book Agile IT Organization Design by Sriram Narayan, It provides analysis of factors that drive the need for organization design as well as a deep dive into organization design factors such as accountability, alignment, finance, staffing, tooling, metrics, and cultural norms. The book provides a great summary of commonly-accepted lean / agile principles and practices along with a few less-common ideas such as:

  • Those whose role is primarily planning (particularly project managers) should spend around 20% of their time actually doing work related to the product such as development and testing
  • Allowing teams to choose their own tools
  • Avoiding the use of standard templates for documents, reports and presentations
  • Making decisions based on written input rather than verbal discussions in meetings
  • Use of metrics to measure adaptability rather than those that measure predictability

Lean | Agile Means vs. Ends

I’ll start this post with a comment by Dr. Alan Weiss:
“The entire point of bureaucracy is the triumph of means over ends. The results don’t matter, only that the rules are strictly followed.”

Do those of us focused on lean | agile practices run the risk of setting up new bureaucracies to replace the old waterfall bureaucracies? Do we pay too much attention to the means (stand-ups, Kanban boards, story-points) and not enough attention to the ends (business results)? Do we focus so much on following rules that we lose sight of the external business environment, strategy and objectives? Do we understand the “definition of done” for implementing lean | agile practices?

I raise these questions because I am starting to experience déjà vu. Nearly two decades ago, a friend worked at a company that went all in for Six Sigma. The Six Sigma initiative took on a life of its own. Strong leaders were pulled out of line functions, became Master Black Belts and sponsored projects that were only loosely aligned with the business strategy. My friend, who was an English major, was required to learn Mini-Tab in order to retain his executive position. The change management program took hold and people at all levels began using acronyms such as DMAIC, DMADV, CTQ and VOC in normal conversation. Those who resisted change either left the company or their careers were derailed. The Six Sigma effort became bureaucratic and “enforcers” ensured that all the Six Sigma rules were followed to the letter. When viewed from a change management perspective, the transformation was successful. Unfortunately, the business failed and it was eventually sold to a competitor. The problem was not Six Sigma per se. The problem was that Six Sigma became the end.

As we embark on efforts to scale lean | agile principles and practices, we need to remind ourselves that we are seeking to improve business outcomes and the principles and practices are merely an effective means toward that end.

Lean – Agile Program / Portfolio Management – What’s New?

As organizations begin to scale the use of lean-agile methods, they soon identify impediments in the area of program & portfolio management.  Following are three major categories of impediments, as summarized below:

  1. Funding - Project-level budgets established 12-15 months in advance cannot accurately predict agile funding requirements
  2. Capacity / Change Management – the flexibility of agile scoping and delivery will quickly overwhelm granular resource capacity plans
  3. Governance – Traditional metrics regarding (time, cost, quality) and phase-gate reviews do not accurately depict the health of agile projects, so more meaningful metrics are needed

Clearly, the movement toward  agile development will require some significant rethinking of program and portfolio management.  The Scaled Agile Framework (SAFe) provides a unique perspective on lean-agile program portfolio management.  Among other things, SAFe proposes a continuous flow of epics rather than discrete projects with specific start-end points.  It also proposes lightweight business cases and rolling wave planning among other changes.  Following is a link to a SAFe abstract on lean program portfolio management:

http://www.scaledagileframework.com/program-portfolio-management/

The SAFe abstract also references a case study on agile portfolio management from DTE Energy.  It can be viewed by clicking on the link below:

http://www.jctnet.us/Professional/Agile/CD-ThomasBaker-EstablishAgilePortfolio-Paper.pdf

 

 

 

Risk Management and the Lean / Agile Frameworks

Here’s a link to a AgileHood KC post on the application of risk management practices within the lean / agile frameworks.

http://kc.agilehood.org/risk-management-and-the-leanagile-frameworks/

 

Rethinking the PMO Mission in an Agile World

Here is a link to an Agilehood KC blog on re-thinking the mission of the PMO to support an agile transformation.

http://kc.agilehood.org/planning-for-pmo-success-in-an-agile-world

 

 

Collaboration Issues – Is there an iceberg nearby?

Agility requires collaboration.  You will not hear many arguments against that statement.  After all, one of the four agile values is “individuals and interactions over processes and tools (www.agilemanifesto.org).”  Collaboration enables quick feedback, allowing teams to solve problems faster, and increase velocity.  High-performing, self-directed teams cannot exist without collaboration.  And yet in many organizations, even those that have been on an agile journey for some time, there are built-in barriers to collaboration.  Here are some examples. 

  • Hierarchical organizational structures that hinder horizontal communication
  • Leaders who promote “us vs. them” inter-departmental rivalry
  • Managers who behave as if their sole mission is gatekeeping
  • Office floor plans that prevent team co-location because they were designed to allow line managers to “keep an eye on” their developers
  • Line managers who insist on “no surprises” and being the first to know everything

 

These barriers are remnants of the command and control culture in which many of us built our “pre-agile” careers.  Some barriers are so ingrained in our thinking that we may not notice them anymore, but they will manifest directly or indirectly in the form of impediments raised by our teams, such as:

  • Product owners who are disengaged, delaying needed decisions on priorities or sign-off on completed deliverables
  • Toxic behavior (e.g. back-biting, gossip, emotional outbursts) by team members
  • Miscommunication regarding success criteria, resulting in challenges integrating deliverables from other teams
  • Subject matter experts who do not have sufficient band width to consult with the team when needed

 

So what can we do to remove barriers to collaboration? We can chip away at the problem by attempting to remove impediments as they are raised up by our teams, but that will be not be sufficient.  Since these impediments exist because of legacy beliefs, values, and behaviors, the real solution lies in the cultural change that must accompany any agile transformation. The subject of changing culture is beyond the scope of a single blog post (or even an entire book) but for now it is helpful to understand that collaboration barriers are merely the tip of a pretty large iceberg.

Product Development – “Are we there yet?”

Those who sponsor software product development are frustrated by the time it takes to go from a great idea to the first trickle of revenue.  The months slowly pass and the sponsors adopt the refrain of children during a long road trip, asking “are we there yet?”  The product development team provides the parental response, “we’re almost there” and continues the usual product development practices.

The book, “The principles of Product Development Flow” by Donald G. Reinertsen, proposes that the sponsors are justified in their complaints that teams are taking a long and tortuous path to market.  Specifically, he points out that product developers focus too much on capacity utilization and not enough on cycle times.  As a result, the developers create large batches of work that result in large queues of work that are invisible to the product developer’s dashboards.

Reinertsen proposes a new flow-based product development framework, adapted from lean manufacturing, that seeks to measure and reduce the size of queues by reducing batch sizes and applying WIP limits. He proposes a prioritization method that takes into account cost of delay and the size of the job being scheduled.  Underlying this framework are some 175 principles that complement those of agile software development.  The book is quite deep and may require a couple of re-reads before the concepts settle in fully.

Per Reinertsen, this framework results in product development process improvements of 5 – 10 times, thus allowing product development teams to honestly tell their sponsors that, “we’re almost there.”

Agilists – watch your language!

It appears the agile principle that “business people and developers must work together daily throughout the project” is often not followed in practice.  When practioners share their experience with agile transformation they frequently complain that the business is not fully engaged.  Perhaps we agilists are complicating matters unnecessarily.  We produce metrics that describe things such as story point velocity and wonder why our executive sponsors appear catatonic.  We schedule meetings with odd names like “scrum of scrums” and wonder why business people do not attend.  We have developed language and ceremonies that are completely foreign to the business and have therefore created the impression that this agile thing is for IT.

If we are serious about agile at scale, we need to adapt our communications to the needs of the business.  Don’t make them learn our secret handshakes and gang signs.

Respect – it goes both ways

At a recent workshop, the instructor noted an animus among agile teams towards managers and executives.  Perhaps it is inevitable that, with the focus on self-managed teams, agilists would discount the importance of those outside the teams – particularly “management types.”  After all, managers are the ones who set impossible deadlines, implement bureaucratic controls, and resist change.  However, it is also helpful to remember that managers fund projects, help remove impediments, and sign paychecks.  If we agilists like these things, we should begin to appreciate the people who provide them.  Otherwise, the agile movement could stall at the team level and fail to achieve its full potential at the program and enterprise levels.

We should approach managers with at least the same respect that we demand of them.

 

 

 

It’s a tough life for a purist

As the agile movement has grown, there has been a corresponding growth in the lamentations of agile purists.  They weep over teams that perform manual acceptance testing, saying that they are not “truly agile.”  They grieve over teams with programmers who are split between new development and production support duties, and call them “scrum-buts.”  They mourn over organizations with formal change control processes, labeling them as “waterfall clingers.”

Perhaps it would be helpful for the purists to cease rending their garments, relax a bit and remember that the transition to agile should be driven by the needs of the business and will be constrained by existing culture and processes.  A mature organization in the financial services sector will transition at a different pace than a start-up software firm.   The agile principles (www.agilemanifesto.org/principles.html) should provide the vision for the transition and the practices should be allowed to evolve at a reasonable pace.

The agile purists will persist in their anguish while the rest of us find our own path to success.

Next Page »

OnPoint, LLC