Broken coffee mug with the word Trust in the bottom

Build Trust Before Focusing on Business Value

Posted on by TheSocraticPM

When coaching an organization at the beginning of their Agile Transformation, coaches turn their attention to getting the organization to focus on delivering business value. While creating a culture that focuses on delivering the maximum business value is the ultimate objective, often the organization suffers from a “trust deficiency” between the business and the IT organization.

In order to drive change, most Agile Coaches start with identifying a “Burning Platform” or the core business reason that drives the organization’s need for change. Reasons, such as market competitors’ ability to deliver and adapt products to customer changing needs faster, changes in regulations such as new tax laws, or a company merger, are the ideal Burning Platforms, there is usually a more common root cause or dysfunction that existed prior.

In my experience with IT organizations, there often exists a large “trust deficiency” between IT and the business. Usually IT has been unreliable in the delivery of software applications and infrastructure. When the IT organization delivers software it is does not meet expected functional expectations, quality standards, and at times may be of less quality than what was already in production. I have experienced some IT organizations that are unable to reliably deploy changes to infrastructure. Add to this scenario that a lot of IT organizations are still delivering software using waterfall or hybrid agile methods where the business has to wait months for the delivery of the low quality and defect-laden applications, there is no wonder why there exists a lack of trust.

. . .

Cracked steel plate with the word Trust

These environments are large part of the the reason that most Agile transformations begin in the IT organization. The CIO realizes something must be done to improve the reputation of their organization, improve the lives of the people that work there, and reduce the probability they will be shown the door.

In these circumstances, the CIO and the people in the IT organization are often reactive in their operation. The IT organization may also suffer from a demand management issue where the CIO is at such a trust disadvantage that they are unable to refuse or properly prioritize any request from the business. The CIO may even be forced into deadlines by the business that they know in their hearts they are unable to achieve. You have an IT organization where everything is the top priority because the business and the CIO cannot trust the IT organization’s ability to delivery anything. This is where the CIO turns to an Agile transformation as the answer.

When committing to an Agile Transformation, the Agile Coach will come into the IT organization and try to identify and validate the “Burning Platform” for the Agile transformation. This is very difficult when the IT organization is as dysfunctional described and there is a trust deficiency with the business. This is made more difficult when the Agile Coach comes into the organization and tries to get the IT organization to turn their attention to delivering based upon business value. Given the reactive nature of the IT organization, there is often a struggle for the people in the organization to maintain the connection between their everyday work and the business value it contributes. The push by the Agile Coach to focus on business value only exacerbates an already overwhelmed IT organization.

Rather than immediately trying to turn the IT organization to focus on delivering business value, I recommend first try to repair the trust deficiency. As an Agile Coach, focus the IT organization on stabilizing software delivery with delivering software in small increments with limited variability. Focus on delivering small sets of features often and reliably. This could mean that rather than delivering the highest business value first based on an economic outlook using Weighted Shortest Job First (WSJF), develop a strategy for delivering what is already ongoing in smaller and smaller increments in order to reduce variability. This will begin stabilize the practice of delivering software incrementally, begin to address the lack of trust between the business and IT organization, and increase the confidence of the IT organization.

. . .

After establishing some trust between IT and the business, the Agile Coach can then begin to turn the attention of the entire organization (not just the IT organization) to focus on delivering and contributing to based upon business value.

U.S. Capitol Building

Message to Congress: “Working for Grand Bargains is Antithetical to Agile!”

Posted on by TheSocraticPM

If you support government programs no doubt you have heard of or are in the midst of an agency’s’ Agile transformation. These transformations our brought on for a number reasons. Some may say the number one reason is that it just makes good business sense. Since we all know change is difficult, especially in the government, and government senior executives tend to limit pain under their watch, let’s remove this as the primary impetus for the transformations. The primary reason I see for these Agile transformations is the demand from Congress for better execution of programs, thus leading to the passage of laws and subsequent congressional oversight function.

When we continue to see Congress search for “Grand Bargains”, e.g., big government bills that include multiple legislative initiatives in order to garner as many votes as possible, they show that have little awareness of the lean/agile principles…

Laws such as the Program Management Improvement and Accountability Act (PMIAA) and the Federal Information Technology Acquisition Reform Act (FITARA) encourage the agile management of acquisition programs. These acts increase Congressional oversight and requires more frequent reporting. These are good things.

While encouraging the executive branch of our government to be agile, Congress continues to demonstrate its inability to be agile. When we continue to see Congress search for “Grand Bargains”, e.g., big government bills that include multiple legislative initiatives in order to garner as many votes as possible, they show that have little awareness of the lean/agile principles that express the benefits of small batches and feedback loops.

How can Congress experiment and receive direct feedback on legislative outcomes if they release a large batch of initiatives in the same bill? How can they expect the Executive branch to operate with agility when a group of initiatives with interdependencies are all grouped together?

Congress should lead by example and pass small pieces of legislation that are independent. Set outcomes targets/goals and use those for oversight matric. This will allow the Executive branch to implement and measure the outcomes of that piece of legislation.

Congress should also craft legislation so small that it is almost experimental in it implementation. For example, instead of passing legislation dictating that the Border Patrol higher 8,000 more agents, how about have them higher 1,000 agents to allow 1,000 experienced agents to be reassigned to areas of the border with the most need? Then measure the impact of this initiative on border security. If it is less than effective then we have real data regarding the implementation of 1,000 new agents on the border.

My message to Congress, don’t expect to provide oversight of successful agile transformations in the Executive branch when your whole mode of operation is antithetical to agile principles.

“Product-centricity” changes the definition of a Project

Posted on by TheSocraticPM

As we move into the DevOps world with regards to software development, the concept of a software development project has changed or no longer applies.

In the past the traditional approach to delivering a software product, Waterfall Software Develop Life Cycle (SDLC), involved one or more projects that would deliver the software product to the customers. This would take months and even years to deliver and normally result in a product that was less than satisfactory. There are plenty of writing and other blog posts that discuss the need that resulted in Agile practices and frameworks that improved the SDLC. I will not revisit them here.

What I wanted to discuss here is the change in project thinking that comes from the new way we manage produce and manage software. As we move into the DevOps world with continuous integration and continuous delivery of software, changes to software in the form of micro-services are being delivered multiple times per day. There is no longer a major delivery of software which in the past has been the major milestone or marker of a software development project. Software is now viewed as a product that has a continuous life and a set of features where each feature can be enhanced when the opportunity for additional value is identified or retired when the particular feature no longer provides value to the end user or customer. These enhancements are incrementally delivered over the course of hours or days rather than months. With this new way of thinking then, “Does the definition of a project change?”

The Project Management Institute Guide to Project Management Body of Knowledge, Sixth Edition, defines a project as follows:

“A temporary endeavor undertaken to create a unique product, service, or result”

So how do we apply this definition to the life of a software development product that is continually delivering a new or enhanced services, all the while it is in production. Are project day long or hour long efforts.

I believe that the definition of a project rarely applies to the software product management domain. BUT the Project Management Knowledge Areas (Scope Management, Schedule Management, Communication Management, Cost Management, Quality Management, Risk Management, etc.) are still important and must be applied in the management of software products. Although these processes are applied differently and in some cases with a “lighter touch”. For example, in the case of Schedule Management, a Product Manager or Project Manager may only schedule to the milestone level, just enough information to identify dependencies between the start of the development of a particular feature and the readiness of other products, services, and materials necessary for the the delivery of the feature.

So the management of product no longer fits the temporary nature of a project. A product is ongoing until it, in total, no longer provides value. Also,  product management delivery of services is too rapid for the full planning process group of a project life cycle. Therefore if one were to take the definition of a project and apply it to product management, this mean the project would last the life cycle of the product. Yes that is temporary but with product management, a product can last decades, as long as it is providing value. This relegates the definition of a project to a budget and time construct. 

Framed Home under construction

Agile Software Development and the House Metaphor

Posted on by TheSocraticPM

Earlier this summer, I had the opportunity to speak to a group of lawyers regarding Agile Software Development. This was a joint panel discussion with a couple of subject matter experts who were there to discuss the pros of Open Source software. While my performance left much to be desired, the open source subject matter experts were phenomenal in their explanation and use of metaphors. Some of the metaphors used were:

  • The German Enigma machine when discussing the concept of concealing the “how” versus concealing the “what”
  • A door lock when discussing the availability of how a lock works versus the concealment of the “key” which unlocks the lock
  • The comparison of a car with the hood sealed shut when discussing closed software versus a car with the hood that opens when discussing open software

While the subject matters experts used several other metaphors, one that resonate with me from an Agile perspective was the metaphor of a house.

The Open Source SMEs used the metaphor in terms of the public nature of the architectural plans of a house. It is as follows, when building a house on spec, the plans for that house are filed with the County where the house will be built. While the plans are owned by the homeowner, they are available and most times publicly. The public nature of the plans do not prevent the homeowner from building the home. Further, while the plans are public they do not limit the ability of the homeowner to secure and insure the belongs in the house.

So what does this have to do with Agile Program Management?

I regret not leveraging this metaphor further for Agile software development. Using Agile software development is similar to being able to live and test each room of a house as it is being built. It also allows the homeowner to prioritize the building of the rooms of a house based on the homeowner’s priority but respective of the infrastructure necessary to support the rooms. For example, if the homeowner prioritizes the master bedroom as the most important room, the builder will build the infrastructure necessary to support that room first. This may include installing the plumbing for the en suite and installing the HVAC for the heating and cooling. It may also include the installation of steps and the minimal framing of lower levels to support the master bedroom, if it were on the second floor.

The house metaphor was also appropriate as it similarly fixes cost and time as an agile software development project does. In most cases when building a house, the homeowner is bound by time for delivery and a budget. The fixtures and elements (e.g. the scope) of the house are changeable based upon the homeowner’s value selection. If a homeowner does not have the budget for that third bathroom, it will not be delivered in the scheduled timeline but a later rehab may take place. Again, this is based upon the homeowners relative value of maybe adding a walk-in closet.

The house metaphor was a great metaphor to explain the iterative and value based nature of agile software development while considering the architectural components required to deliver each room of the house. I regret not taking the opportunity to use it when it was presented.

Lean Startup Methodology

Learning from Failure

Posted on by TheSocraticPM

In March of  this year in Arizona an Uber semi-autonomous vehicle struck and killed a pedestrian. This was definitely a tragic event. A life was lost in an accident that critics feel could have been avoided. This accident should have been avoided given there was a backup driver in the car.  Uber immediately suspended all semi-autonomous vehicle testing.

As time has passed, I began to relate this accident, as tragic as it was, to Agile. More specifically I related it to the Lean-Startup cycle. Uber, Alphabet, Tesla, GM, etc. are all experimenting with driverless or semi-autonomous driving. These companies are 1.) Developing hypothesis 2.) Testing their hypothesis through experimentation 3.) Measuring the results of their experiments and 4.) Learning and determining the next step to address the market challenge/opportunity.

As these companies progress we are realizing and witnessing incremental progress toward autonomous vehicles being released for consumer consumption. Remember when lane departure systems were the newest innovation and limited only to premium vehicles.  This was after rear and forward car sensors became standard features. We now see automatic breaking systems standard features in even mid-level sedans. This is the first, third, and seventh principles behind the Agile Manifesto. The highest priority is to deliver valuable software to customers,  deliver  working software frequently and the delivery of working software as the true measure of progress are all encompassed in this innovative drive to autonomous cars.

Moreover, all of these incremental progressions and experiments are all driving to a common vision that is integrated into each of these companies organizational mission statements.

“make transportation as reliable as running water, everywhere, for everyone.” – Uber’s Mission Statement

“to make the world around you universally accessible and useful.” – Alphabet Inc.’s Mission Statement

If there was an Industry Vision it would be easy to see how all of these initiatives have been leading to a “Safer, reliable, and more efficient use of the highways.”

Now that features such as Lane Departure and Automatic Braking Systems are becoming more standard, the autonomous vehicle can sense the environment around the vehicle and stop the car. The next increments will probably include features that control the car while in motion.

The clearly avoidable failure of the semi-autonomous car striking and killing a person will place doubts in consumer’s minds and may even lead to regulation but it will not stop the progression to autonomous driving. This accident is a tragic lesson that the industry will analyze and learn from. They received instant feedback by putting the experiment on real roads and not some test track with a controlled environment. The tragic lesson learned through the death of a pedestrian is just one of the many lessons learned so far. Those companies that choose to continue experimenting with driverless and/or semi-autonomous driving will analyze these lessons. They will apply those lessons in improving existing features, such as automatic braking systems and move forward with releasing additional features. They will learn from this failure.