Category Archives: Product & Portfolio Management

Another Move Back to Central IT for the Feds?

Federal Computer Week recently ran an opinion article by Michael Garland, a former BearingPoint procurement veep and currently under contract to help the government with Acquisition Reform; you can read this article here: “Why acquisition reforms fall short“.

In this article, Mr Garland states the following, “…there is no centralized, integrated strategy supported by a corresponding organizational structure. The government has been intensely fragmented when it comes to IT acquisition.”  He then purports how the Government should act as a centralized enterprise when it comes to acquisition and management of IT. He begins with a statement that the Government acts as a “holder” of a portfolio (much like a financial portfolio) and then later states the following:

“That approach lacks cohesion and inhibits the ability to develop and exploit best practices. It has been an ad hoc structure devoid of an enterprise strategy. The fragmentation also hinders the ability to develop valued expertise or deploy any of the various continuous improvement methodologies that have been so useful for the private sector.”

Having worked for many an agency as a Fed, Navy officer, or contractor, I can say that centralization causes many woes, the largest one being that no central IT strategy (acquisition or otherwise) can be attuned to an Agency’s unique needs.  Integrating custom systems of systems command and control software for a Naval ship is entirely different than acquiring a human resources application, to deploying a mortgage loan lending package, to building a custom-built analytical program for determining pesticide safety.  It appears his mental model is all about cost efficiencies and not value production.

What can be promulgated to help each agency is guidance (not rules) for helping procurement officials make the appropriate decisions on contract types so that risk can be minimized and managed effectively locally, while also producing maximum benefit/value for the Agency’s mission for supporting the American people. Central rules destroy customer experiences in almost every industry. (Actually only the most risk averse/safety-centric industries gain from central rules.)  Central rules sets are designed for cost efficiency at the expense of effectiveness in delivery; I contend this is not a strategy to pursue.

I also contend that a portfolio of holdings is EXACTLY what we want; and what we want to extend is thinking that helps our brokers (the Agencies) invest better on our behalf in ways that respect their missions.

Think alignment over control…

—–

Follow-up: a colleague passed me a pointer to an 18F article on Ghost Writing RFPs. This is a step in the right direction if this is used to enable improvement throughout agencies in how they write RFPs.  Unfortunately, at the point of writing an RFP, an acquisition strategy may already have been made and depending on the flexibility and remaining options (in terms of time) to modify these later, the various Departments and Agencies may have a tough time taking advantage of this service.

An Alternative for Identifying Classes of Service

appleorange-1

In most Kanban systems established, classes of service refer to an assessment of impact to the business.  While I personally like this approach, often this assessment technique doesn’t fit well for some teams or organizational issues.  It may also not be very informative for some work items being managed.  I have always believed in using Kanban, and particularly its associated metrics, for identifying areas to improve.  Sometimes we need abilities to slice by similar items as far as impact, but that may have other degrees in which they vary. So I’d like to present a few other styles for identifying these.  I’ll start at a team level and move upwards towards something more organizational wide.

Maintenance Activities

I often seem to find teams performing maintenance activities (upgrades, defect/bug fixes, small to large enhancements, etc.) struggling to find ways of understanding the metrics that will be useful to them.  While an Expedite class of service, with its own identifiable swimlane and corresponding WIP limit, is invaluable, a standard class of service is not when the timeframe or scope tends to skew the metrics results.  I want to be able to predict when an activity may be done with some confidence.  If I lump all of the activities into one standard class of service, the larger items will skew the average lead time to a higher number than my smaller activities and my variability will be very high.

A concrete example is an ERP upgrade versus an important (but perhaps not critical enough to go into the Expedite column) bug fix.  The ERP upgrade may fix numerous (just as) important bugs as well.  Upgrades in ERPs often can’t be broken into apples to apples comparisons as the tasks are entirely different though the lifecycle that may be managed through the Kanban process may be identical.  Additionally, the items that must be completed for the definition of done (which become cumulative entry/exit criteria along my columns) may also be different.

BTW, these types of items may be tracked within a higher level Kanban and not necessarily a team based one…

Portfolio Items

Definitely moving a level or two upward, if I have portfolio items that need to follow an identical process, but may have varying entry/exit criteria or varying typical timelines may also be worth tracking as separate classes of service though each may be more or less equally important to the business (i.e. close to the same prioritization in the backlog).  Here’s some examples: reogranizing a particular function, redesigning a business process, implementing a new application (at the highest level).  Each may follow a similar process of: Backlog -> Analyze -> Implement -> Measure Performance -> Done.  The definition of done and timelines may be quite different on each of these items.  Wouldn’t it be nice the next reorganization being proposed I understood how long my last set took in terms of average lead time and its variability so I can predictably give an answer to the board?  I don’t want to skew my data with that for my last network upgrade.

One could argue that we could (or should) use separate Kanban boards for these, but I think this is less than useful. I can think of two reasons to have these on the same board.

  1. I want to understand how my organizational WIP of change affects cycle-time overall.  This would be very difficult to do if these were spread across multiple boards. (This is not to say that each effort may not have its own more detailed board.)
  2. Also if I want to also think through alternatives approaches and compare cycle-times as a magnitude of cost (since often time is money) and benefit (time to market), having these on the same board makes this much easier.  By tracking this information, I can use this information as input to my decision-making on which approach I may use.  For example, if I can use it as input to analyze whether I redesign my current business process or automate the existing process.  Knowing the cycle-time can become part of the analysis both in terms of cost and benefit

A Quick Analysis View

So how do we determine these different classes of service? Well I have already hinted at the dimensions that we will use.  We’re going to basically categorize the work item types by time it takes to get them done (just a gut feel of time) and differences in the scope of definition of done, looking for vastly large differences.  You can place these on a grid such as the one below.

Classes of Service Matrix

So even items with a similar definition of done may have vastly different timelines, knowing this keeps us from skewing the data when we want like items.  Additionally, not lumping things that have vastly different definitions of done (column(s) exit criteria) yet follow an identical process at the level we are looking at it can also be very helpful.  The bottlenecks that may occur can be different; this also makes a useful distinction.  Lastly, I can now view all of these dissimilar items on the same board and yet have a means of distinguishing them and their corresponding metrics.

When one is stuck on identifying classes of service, or the classes of service between the items appears meaningless, give this a shot and see if it helps.  I’d be interested in other viewpoints.

The Dimensions of Choosing a Scaling Approach

boy_Ladder_into_clouds

From Issue 26 of Compute! magazine, July 1982

As many folks know, I have been exploring what scaling means in various discussions. I am no fan of the Scaled Agile Framework (SAFe); I got and let lapse my SAFe Agilist certification. I chose to get it mostly as it was offered to me at extremely low cost AND it allowed me to hear about what it was about straight from someone certified in it. I am not here to bash it though; it has its place. It’s not for EVERYWHERE you need to scale as it is portrayed though. This post will explore the scaling approaches available to you and when to apply them.

Let’s start with some “definition” of what is meant by scaling first…

Generally, when folks say they want to scale something, it means they want to expand its use or its capacity. So to now to fill in the ‘it’, to expand Agile’s use is to replicate Agile teams over more of the organization and to expand Agile’s capacity is to allow what is currently working to do more. These are different classes of needs. The act of replicating Agile teams (and more importantly its benefits) is solved by “scaling out” and requires thoughts on cultural change, choices of approaches and practices, and how these teams should be instantiated and organized. The act of expanding capacity of current Agile teams to accomplish more is “scaling up”. Here the choices are how to help existing teams work together effectively and gain more product throughput. The confusion on which of these apply stems from the fact that both expand overall organizational capacity.

So I’d like to provide a means for thinking along a couple of dimensions to determine which one applies as you decide to scale up. People in an organization may be choosing different approaches based on what their needs are at any one time, but I want folks to understand when and why to choose specific approaches. I plan to apply the Cynefin framework to classify problem spaces as simply a means of determining what types of approaches may be more effective. Lastly, I want this to focus on the end result of your organization’s value stream and what it needs, not on simply making choices for your organization in a vacuum.

To do this, let’s look at the following graph; it has two dimensions, both attribute of the end product lines of a value stream. I actually use the term product lines (could also be service lines) to indicate that these have an inter-relationship. So the vertical dimension is one of interdependency among products, which formulate a product line. Let’s take a concrete example: an Enterprise Resource Planning system. There is a core product and a set of product modules; this is a product line produced by a value stream. The company may have a different product line totally unrelated; say machinery control software used in factories that may be its own product line – the end result of a different value stream.

The second dimension is how responsive a value stream (and the products produced by it) may need to be to the market. (For organizations not driven by a market, say government agencies, replace market with mission.) As the market changes, so does the needs of the resulting products (or services) the organization is providing.

Scaling_Dimensions

These two dimensions can define the ‘space’ for our organization’s business agility needs. So let’s explore this space now to understand how and when to apply scaling….

If our market (or mission) is slow to change (i.e. our demand for market responsiveness is low) AND we have few products with interdependencies, then we are in the Obvious domain (this used to be called the Simple domain in Cynefin terminology). In this space, we have a simple, stable product line. We are probably the market leaders with little competition to worry about. If this is our domain, we don’t need to worry about scaling; if we are transitioning to use Agile/Lean approaches, we are probably doing this to remain ahead of our competition as a proactive component in our strategy (or maybe we have always been Agile or Lean). The key here is few products and the need to respond to external market forces is low; our need for agility is low.

So what if the market is rapidly changing or the mission is rapidly evolving? Our need to respond is high… This is where start-ups generally find themselves; they are constantly reacting. This is the Chaotic domain. If our organizations are still exploring how to fit customer needs, there may be several competitors trying to do this as well. There are no market leaders yet. Or maybe we have a small product line and have found ourselves facing new and stiff competition. This demands agility, but not a need to scale as the product line inter-relatedness is low.

As the number of our product lines increases, so does our need to scale our Agile capacity. This may be able to first be accomplished by simply using some lightweight activities like a Scrum of Scrums to help coordinate interdependencies. Eventually though, we’ll need to think more formally about how we want to scale and when we look at interdependent product lines and whether a scale up or a scale out approach is more appropriate.

So let’s return where our now interdependent product lines have market stability; the demand to respond to market changes is low. The primary driver now for any agility is to coordinate product line activities together into cohesive releases. We may be a market leader across most, if not all, of the interdependent products that make up our line. A scale up approach can handle this need for cohesiveness via coordination. We can roll the products into a program and use it to coordinate activities, thus a hierarchical approach to organizing will work. Approaches like the Scaled Agile Framework (SAFe), Disciplined Agile Delivery (DAD), and the lesser-known Enterprise Agility framework can be applied. We can take time to analyze the situation and provide a means for gathering product needs and rolling them out to the product teams; this is the Complicated domain.

If the need to respond to the market though is high, each individual product (within the product line) needs to evolve fairly rapidly so that it can meet customer needs. This does not mean that there should not be some form of congruency among teams. Our scaling approach should be one of scaling out teams that are networked together to maintain this congruency; there needs to be allowable deviations so that we can keep pace with the market (or mission) needs. Each deviation needs evaluation to ensure this isn’t a new path for the entirety of the interdependent product line. This is where probe-sense-respond comes into play, the Complex domain.

One thing to remember here is that the organizational structure and its communication paths will create the coupling of the products. This is Conway’s Law. The result for most hierarchical approaches will have product lines that are tightly coupled, while for most networked organizations, loosely coupled product lines will result.

I’ll close this post with a final thought; regardless of the scaling need, who is choosing it? Is it your people in the organization or is it someone dictating how and when you need to scale? This is the difference I see happening is that people are not exploring how they themselves can scale, but they are being told how to do it. Use this as a tool to help your people figure out what will work for them…

ACC US Session: How to Practice Agile Scaling w/o a Condom: un-SAFe Agility

I held a provocatively titled session to explore some of the issues surrounding SAFe, DAD, and other Agile scaling frameworks that prescriptively define the structure in how they work.  I personally don’t feel it useful attacking frameworks, but understanding the context around them so that one can judge for themselves whether they will apply or not.  The path I took was to explore the problems, then the why we are scaling, then finally the assumptions these hierarchical and rigid frameworks make.  I did this through time boxed brain-writing portions and then discussion on the results.  This was to eliminate the possibility for undo influence between participants.

We had several people come and go, but my core group was Karen Spencer, Kristen Tavelli, Dave Rooney, Brett Palmer, Susan Strain, Diana Wiliams, Darren Terrell, Sameli Zeid, Patrick Wojtak, and myself of course.  Brett in particular stated he found the session useful; he had just completed his SPC and was struggling with some of the rationale behind how to apply it.

Problems created when introducing SAFe (or other hierarchical scaling approach)

The following are the problems folks have seen when implementing these hierarchical approaches. (NOTE: we are talking about actual implementations seen and/or the way the framework is being prescribed to apply.)

  • unknown needs for why certain measures or metrics are required – most of the metrics these frameworks seem to roll-up seem to be to ensure that the same items are measured across teams and not necessarily what may be needed for the individual team itself
  • these metrics also seem to be used to compare team performance in a negative manner (and thus lead to team’s gaming their metrics to keep from being viewed negatively)
  • it also seems to prescribe the same process across all teams (mostly around Scrum rituals)
  • often times the organization begins implementing SAFe without executive buy-in, in particular from the business side of the organization
  • it tends to make too many decisions upfront with the product management/program level making decisions around how work will be done and not just about the how, sometimes well before any team(s) will begin solving it
  • it also removes decisions from the team around cadences and architecture, and constrains what improvements or experiments a team may do
  • after getting agile teams to drop formal roles and promote T-shaped people (generalizing specialists); most of these frameworks and SAFe in particular, introduces unneeded roles again
  • SAFE seems to focus at driving a release (train – get that damn train off my runway says the aviator!) at the team level; they are still left to simply struggle on their own (in fact there seems no one that they can truly turn to for impediment removal either)
  • with all these new roles and early decisions, this introduces unneeded coordination overhead
  • it reintroduces big upfront requirements again, sometimes using lighter models, but sometimes favoring back towards heavier ones
  • it reinvents Gantt charts with post-its
  • for teams starting their implementation of this sort of framework, it begins to force common processes and tools onto teams that may have evolved to a different set
  • also when beginning implementation, there seems ot be a lack of communication to the teams why such changes are needed, it just begins to impose them without explaining the rationale behind them
  • and there may be some possible unsound assumptions being made as to the need to scale in the first place

Whew! That’s a lot of problems, but there must be a reason for scaling?

Why Are We Scaling? (What do organizations want…?)

So we turned our attention to why we are doing this in the first place.  Understanding the reason(s) may help us make more useful decisions on approaches and such.  Here’s our take on the why’s organizations we’ve encountered are doing so…

  • there’s a silver bullet mentality; there must be a one right way to getting consistent result from all teams
  • there is a desire to help large programs adopt Agile across the enterprise with an approach that can be easily visualized
  • the above two reasons also seem to be a means for simply trying to organize a large number of teams and the people within them
  • for programs with large technical products, it can help them coordinate their activities, dependencies, and constraints
  • there may be multiple teams with multiple dependencies
  • often ‘programs’ are defined by the organizational structure that already exists or the budget that is provided to fund the work (it’s easier to sell large programs for large budgets that will produce large benefits that than a collection of smaller products that may collectively and more loosely accomplish the same results)
  • there is a belief it will remove impediments more easily (remove an impediment for one team will remove it for all teams)
  • there is a desire on management’s part to see consistency and predictability across all teams
  • and lastly in many Agile approaches, middle managers don’t see where they fit; they feel a loss of power – these hierarchical approaches show where they retain power and control

In particular, we discussed how some of these desires to retain hierarchy for coordination produce results that follow Conway’s Law.  The resulting development may have rigid and brittle interfaces.

Underlying Assumptions

So lastly we turned our attention to the assumptions these approaches seem to be based on…

  •  belief that management has limited insight into what teams are doing; our discussion on this revealed two parts to this – management expects information to be pushed to them as opposed to pulling for it and secondly management has a belief all data coming to them should be identical for easy consumption
  • a fundamental belief that process is more important; essentially it is process that helps interactions between people
  • a belief that this is how one should scale/coordinate Scrum teams and not through simpler mechanisms such as Scrum of Scrums
  • along with the organization and budget above, BIG Budgets = Importance = Easy Approval over having to ponder each smaller need/budget request on its merit
  • that management believes they will be able to see better productivity and identify where teams need to improve their performance
  • there is a fundamental belief that all development work is the same and thus should follow the same process
  • it assumes that organizations will customize the approach and not adopt it as-is
  • for organizations where they have removed these roles, introducing new roles will be easy (or having people swap from one role to a new one will be easily done)
  • it assumes all teams can standardize on a cadence
  • it assumes we must manage complexity from a central location; I mentioned that a wonderful book that explores where complexity can be managed in a decentralized fashion is Organizing for Complexity by Niels Pflaeging
  • there is a belief that effectiveness is derived via consistency or that efficiency yields effectiveness (or that they are the same)
  • the trade space (trade-offs being made) between autonomy and measurement around effectiveness is (are) obvious
  • management should be able to continue as-is; as Agile moves out from teams, management should not be expected to change in its role
  • the architectural stuff that needs to be done does not equate to business value or is too hard to equate to business value, so we’ll manage it as separate items of work
  • and lastly hierarchies are a natural way for people to organize; people coming together for common purpose would naturally choose it as their preferred structure
  • one I mentioned at the end was that organizations (management) must start with an end structure in sight and that they don’t need to just evolve to a structure

Sameli also had an item that came up that organizations can easily change their structure to match what SAFe has.

I hope you found what we discussed useful and that it will help guide you in your decisions on whether SAFe is right for you and/or how to customize it.  Start with this latter assumptions part to help you avoid the problems that may arise, regardless of whether you use SAFe or a similar approach, how to customize it, or decide on another approach altogether.