The Agility Series

Originally posted on LinkedIn.

In the movie Office Space, the character Milton becomes so enamored with his 'red stapler,' that when he is deprived of his cherished possession, he follows through on his threat to “burn things” – which is this case was the office building where he worked.

For Milton he let his red stapler become synonymous with his self-worth as the only thing of value he had left after all of his job functions, and eventually his paycheck, were taken away from him.

I have often used the red stapler story and analogy when delivering Agile training to describe those remnants of traditional management practice that many people want to hang onto - even when it is clear they are no longer relevant or useful, or that in many cases they are an impediment to their ability to fully embracing Agile principles and practices. At worse, our red staplers can be so destructive to a team that it can lead them to abandoning Agile practices altogether.

For many project managers and PMO's, their red stapler can be their project management deliverables. While they may say they are doing Agile Project Management (I prefer Agile Project Leadership) or have created an Agile PMO, many of them in fact have a hard time letting go of traditional deliverables, planning techniques, practices such as status reporting, or metrics that don’t reflect or support Agile thinking and delivery, to name a few.

I have worked with some teams who take a proactive approach to rooting out their red staplers. I have seen other teams who don’t understand the issue, and don’t see the destructive aspects of hanging on to them.

If you are going to truly make the transition to Agile you need to figure out where your red staplers are hiding and root them out.

What do you think? Do you have your own “red stapler” which you are finding hard to let go of?

Originally posted on LinkedIn

(This post is a bit of a rant based on recently seeing some truly disturbing and horrendous process for supposed project management improvement)

Now that's a bold statement!

But let me explain why I think project management is an upside-down concept.

This is one of the characteristics of traditional project management; The vast majority of projects are conceived from the bottom up – the idea that  you make an investment case to your organization's investment review board, and if you know what the priorities of the day for your organization happen to be, all you need to do is to attach your proposal to those priorities and you will get money. Somehow you were able to make the case that you are contributing to the priorities of the organization. Really?

That’s akin to the old joke about a cost benefits analysis. When asked to do one, you need to respond with “and what would you like it to say”? Any good writer can make the CBA go in any direction the requester would like. Like to justify that nice shiny new toy? No problem. Want to not justify the nice shiny new toy one of your colleagues is pushing? No problem. I can go either way. Likewise for saying my pet project will help the organization achieve its priorities.

So this now newly minted project that was approved by the investment review board gets assigned a PM who not only now owns but also must defend the scope.  They must also ensure their “sponsor” is identified and is also responsible for making sure the sponsor is engaged. Of course the PM also has to identify the risks for the project which invariable touches on sponsor/stakeholder ambivalence/lack of involvement, having their budget pulled, not getting the right people, and on it goes. Again, really? How the heck is the PM supposed to address or mitigate any of that?

What utter rubbish! And it's upside down.

Presumably the organization has some sort of vision and mission. Surely they talk to their clients/customers to understand their need. Surely, they develop strategies and priorities that are in line with their mission and vision to satisfy those needs. Surely they realize that as an organization all they really are is a set of capabilities that coalesce around their mission and vision to meet those needs. Surely they realize that based on that understanding of things that they should stand up projects/initiatives to start incrementally adjusting/refining their capabilities to satisfy those needs within the context of their strategies and priorities.

No? Then I guess they do upside-down project management. Which is what makes it utter rubbish and a leading cause of PM breakdown (literal and figurative and both individual and organizational).

Want some hope for project success?  You can start by not doing upside project management and do project leadership instead. Project leadership starts with doing things that are purpose-driven from priorities and strategies to satisfy the needs of your clients/customers that are also in line with your organization's mission and vision. The role of the traditional PM moves from a role that owns things to a role that's facilitating the team (see my earlier webinar)

What do you think? Still way too much upside down project management going on? In need of project leadership instead?

The Adaptive Strategy Framework is the first step in moving from upside-down project management to project leadership that is purpose-driven.

(Originally published on LinkedIn)

A number of years ago I was asked by a client to help them procure and implement a COTS product - but I had to use Scrum to do it.

That being said, when I got there I was handed a 246-page RFP that a similar organization had issued for the same kind of procurement. That did not look very like it was very agile approach to me so I said ah, I won't be producing one of those!

So how did do we do it? Here are the three steps:

1. Figuring out why the business needed the COTS product

Step 1 was to figure out why the business though they needed the COTS product. To do that I introduced outcomes mapping (which is a variant of Benefits Mapping) to help them more clearly articulate why they were needing to do the project from a business perspective rather than from a technology perspective. The 246-page RFP document I was handed was mostly technology-focused which is why I felt we needed to avoid a similar trap.

As soon as we had the first draft of the outcomes map created we printed on a 3x4 foot sheet and put it on the wall in our war room for the project (see David Maynard's excellent post on how war rooms can help any project).

Having a visible map of the “why” enabled both the business and the IT teams to add details or ask questions using sticky notes anytime they walked by the map. We would then stand around the map as a team every day and review the content of the latest stickies to figure out where we needed to update our map with our now emerging understanding of the business problem we were solving. Once we agreed on what needed to be changed, we would update the map, reprint it and put the newly revised map back on the wall.

This created an opportunity for serendipity for both the business and IT as they would walk by and study the map. As they stood there looking at the map this often led to others stopping as well which of course led to them to talk about the map together. These ad-hoc conversations led to some of the most insightful additions to the map.

Over the period of about 8 weeks or so the big visible map of the why for the project led to the identification of:

• Four major new business process areas that had to be designed, developed and implemented that the business had not previously recognized.
• The fact that the intended COTS product was only one of five different tools that were actually needed and was only one of two in the business process area where it was to be used

As you build an outcomes map there are natural structures that emerge that help you categorize different parts of the map. As this picture emerges it also helps you identify what you need to do (projects/initiatives) satisfy the why you are doing it (the outcomes)

2. Figuring out what the product to be procured needed to do

I facilitated the business groups in identifying the required business capability areas that the product needed to address along with capability statements within each capability area as to what they needed the product to do.

This enabled them to rank each capability statement according to a scale of business importance (Very High, High, Medium, Low, Very Low). This took about 8 weeks or 4 Sprints. The business was solely responsible for these prioritizations of business importance.

We created a Business Service Canvas for this step which was a derivative of the Business Model Canvas. As with the outcomes map we printed the canvas on a 3x4 foot sheet and put it on the wall for the team to use stickies to capture their additions or questions. The Services on the canvas started with those that the Learning and Development group (the business group) already provided to the rest of the organization. It then morphed into those that it would need to provide in order to satisfy the business outcomes from step 1.

We then led the business team through a series of pair-wise comparisons of "buy-a-capability" for each of the statements in each priority level within each capability area as follows:

• Let’s say Capability area 1 had 4 capability statements ranked at Very High.
• We would have them compare the first two by asking if they only had $1 and could only buy one of them, would they chose one over the other or would they say I guess I don't have enough money.
• If they chose one over the other, then the losing statement would be changed to High from a Very High.
• If they could not choose one over the other, they would both stay at Very High.
• We did this for all capability statements for all priorities for all capability areas.

Once all of the capability statements were re-prioritized, we asked them to consider the Low and Very Low ones and whether they wanted us to include them in the RFP seeing as they had already said they were not all that important based on their assigned level of business importance.

After some discussion the business decided to remove them from the RFP. This allowed us to end up with an 8-page RFP document augmented by pre-populated spreadsheets with the capability statements organized by capability area. We provided room in the spreadsheets for the vendors to fill in their actual responses which had to refer to their own product documentation that supported their statements of product fit. The vendors were not allowed to submit bound or printed responses to the RFP.

Using the Business Service Canvas also helped the business identify the need for role re-evaluations based on newly realized skills gaps as well as missing roles within their organization.

This step took about another 4 Sprints to get through.

3. Run the Procurement

Now that we knew why we were doing the project and had a solid understanding of the what the COTS product needed to we were ready to run the procurement itself which meant:

• Issuing the RFP
• Evaluating vendor responses
• Running a boardroom demo for the vendors to show how their product satisfied the required business capabilities
• Selecting a winner

Vendor responses to the RFP were received after being out for 8 weeks. The entire response evaluations took less than a week which included the boardroom demos for the top-3 ranked vendors.

The boardroom demos also led to a switching of the initial number 1 and 2 ranked vendors which rarely happens in traditional procurements. Implementation of the COTS product took an additional six months.

(Note: while some some internal delays stretched the overall delivery timeline to 18 months it was within the original expected time which was also 18 months. Without these delays we would have finished about 4 months early)

Actual expenditure on the procured software was only about 2.5% of the original expectation of expenditure as we only evaluated those things that the client really needed – the business spent a mere $25,000 of the original $1 million originally allocated for the product.

The vendor selection process also considered the ability of the vendor to help with an incremental deployment and use agile practices for developing the required integration with other corporate systems within the business.

Use agile procurement practices means being willing to rethink the procurement process itself as well as the chosen vendor's ability to support agile practices in their product implementations.

Conclusion

Scrum, outcomes mapping and the Business Services Canvas, as well other practices we introduced allowed us to:

• Realize that the “project” was actually a program of projects not a single project as originally thought. In all there were six initiatives across four major business capability areas
• Guide the business team in defining their Minimally Viable Product Features for the COTS product which saved 97.5% of the original $1M budget
• Identify a define the new services they needed to stand-up within the Learning and Development group to satisfy the four business capability areas
• Identify, design, and develop all of the required Minimally Viable Business Processes.
• Identify the new roles can changes to existing roles that would be needed to support the new and existing services based on the new capability areas ad processes

The procurement itself took less time, cost considerably less than planned (only 2.5% of the budgeted $1M), used a far less complex procurement process, and achieved the right results for the business.

The project was completed within the original overall budgeted cost of $2.5M, within the same expected time-box of 18 months, yet delivered newly identified business processes, services, and additional tools (with the money saved in the procurement), none of which were part of the original project definition and scope.

Have you used Scrum in a procurement? I'd love to hear how it went.

Previously published on LinkedIn.com

In my recent post on Strategic Planning versus Strategic Iteration I discussed three ways in which we need to adjust how we view strategy. In this short post I'll look at how we can identify the kinds of strategic changes we will need to undertake by asking four crucial questions. 

In our recent book Agile Value Delivery: Beyond the Numbers we offered up that "The primary reason for undertaking Portfolios, Programs and Projects is to enable the delivery of realizable Value into Business Operations". This is the recognition that the primary origin of change in organizations is because something in business operations is not working or that the organization is wanting to go in a different strategic direction; but it starts and ends in business operations.

We also discussed the fact that organizations now face holistic messes rather than discrete problems coupled with increasing rates of change. Leaders need to learn how to lead at the pace of change rather than trying to control change.

Strategic Iteration helps us take an adaptive approach to how we approach the resolution of these holistic messes based on an Observe-Orient-Decide-Act mindset. But how do we specifically identify what we need to change and how do we make needed refinements based on what emerges?

Many organizations and portfolio teams have figured out that you need to take a holistic view of your organization in order to identify required strategic changes. But how do they do that? It starts with asking four crucial questions:

1. Where are we intending the strategic goals to be directed? Can be geographic, customer segments, distribution channels, etc.
2. Who are the primary players for whom the goals will provide some benefit?
3. What capabilities will be needed to do this and if we don't have them how will we acquire them?
4. Which of our existing systems, processes, structures or policies may be affected?

The real fun, as they say, happens once you get started. Strategic Goals and Objectives are statements of intent not statements of a defined scope and plan that cannot be changed.

An Adaptive Strategy based in Strategic Iteration is an approach that allows us to continually refine both our strategic goals and strategic objectives as well as the strategic changes we are targeting based on what emerges once we start to execute our strategies. 

In our upcoming webinar on  June 1st at 12 noon EST we will be discussing our Adaptive Strategy Framework which organizations can use to answer these and many other questions using strategic iteration, rather than strategic planning to solve the holistic messes they now face, by continually refining their approach during execution based on feedback loops of what is working and what isn't.

The Adaptive Strategy Framework will be provided free for download from our website starting on May 25th.

What questions do you ask to identify the strategic changes you need to make to meet your organizations strategic goals? I'd love to hear about them.

First published on LinkedIn.com

In my last post I referenced Steve Denning’s Microsoft's 16 keys to being Agile at Scale in an article at Forbes.com. In this one I am going to pick up on another one of the statements from Denning with regard to how Microsoft views its people:

Agile at Scale> also rests on a deep respect for the talents and capacities of those doing the work, and the teams in which they work, not treating workers as “resources” that are assignable, optimizable and ultimately disposable.

In Section 4 of our book Agile Value Delivery: Beyond the Numbers we focused on three areas:

• Next Generation Agile which I briefly referenced in my previous post which “Suggests that the point at which agile thinking has permeated an organization is the point at which we can stop using the term ‘Agile’ and we will have achieved “next generation agile”
• Human Resources
• Finance

Under Human and Resources and Finance we discussed the challenges that agile poses for these two critical groups within our organizations, as well as how they might update their approaches to support true next generation agile and true organizational agility.

The origins of viewing people as resources or assets has a long and actually very sordid history that dates back to slavery in the southern USA.

Harvard-Newcomen Fellow Caitlin C. Rosenthal studied the meticulous records kept by southern plantation owners for measuring the productivity of their slaves, some of which were the forerunners of modern management techniques. Her findings were astonishing as discussed in her book “From Slavery to Scientific Management: Capitalism and Control in America, 1754-1911”.

The description for an account entry from the period is shown in the image below:

Account entry for “27 Negros bought this day at public sale” by Charleston, S. C., rice planter and slave owner Sampson Neyle, February 14, 1764. Volume 3. Peace Dale Mfg. Co. Records, Baker Library Historical Collections, Harvard Business School

From the Harvard Business Week article that referenced Rosenthal’s findings:

The evolution of modern management is usually associated with good old-fashioned intelligence and ingenuity—"a glorious parade of inventions that goes from textile looms to the computer," Rosenthal says. But in reality, it's much messier than that. Capitalism is not just about the free market; it was also built on the backs of slaves who were literally the opposite of free.

"It's a much bigger, more powerful question to ask, If today we are using management techniques that were also used on slave plantations," she says, "how much more careful do we need to be? How much more do we need to think about our responsibility to people?"

The concept of depreciation is also credited to the railroad era, when railroad owners allocated the cost of their trains over time, but Rosenthal notes that slave owners were doing this before then.

Starting in the late 1840s, Thomas Affleck's account books instructed planters to record depreciation or appreciation of slaves on their annual balance sheet.

In 1861, for example, another Mississippi planter priced his 48-year-old foreman, Hercules, at $500; recorded the worth of Middleton, a 26-year-old top-producing field hand, at $1,500; and gave 9-month-old George Washington a value of $150. At the end of the year, he repeated this process, adjusting for changes in health and market prices, and the difference in price was recorded on the final balance sheet.

These account books played a role in reducing slaves to "human capital," Rosenthal says, allowing owners who were removed from day-to-day operations to see their slaves as assets, as interchangeable units of production in a ledger, instead of as people.

This hit home a few short years ago for me when someone very close to me was depreciated in exactly that way and let go at the back door while their firm was hiring new grads at the front door using government grants. The software profession in particular is still ripe with that thinking. I'm sure it exists elsewhere.

So maybe it’s time we stopped referring to people as human capital, human resources, or as assets to be depreciated and discarded when they are no longer of value on a "ledger"?

We throw around phrases such as "our people are our most important assets" like its a compliment - once you understand the origins of the phrase, it doesn't have quite the same ring to it, now does it?

When we go home at the end of the day to our families, would we refer to our own children in this way? Why not? If it’s good enough for the people we work with, then why not for our 6-year old at home?

That may be a harsh way of phrasing it, but you get the point. Maybe it’s also time that we renamed that part of our organization as well.

What do you think? Time to drop the terms resources, assets and human capital from our organizational lexicon are start thinking of and  treating people, as well, just people?