First Things First: Agile Principles Revisited

As an organization begins its journey to a more nimble way of delivering quality products that customers love, it is important to know the underlying pinning of an agile mindset as a reminder of why you are starting this voyage and also how to use the principles as a litmus test against how well are you actually progressing towards a new way of working.  Taking the 12 Principles from the Agile Manifesto is the simplest approach to conducting an assessment of your teamwork, collaboration and user-centered approach to product development.

To that end, I will be posting a different principle to use as a foundation of discussion to grow a community and challenge how products are delivered.

Innovations in technology and delivery platforms are rapidly improving and the expectations of customers are increasing and competitors are looking for an opening to disrupt any slow-moving behemoth that has not realized that slow and perfect will put you into early retirement. Speed, with a focus on value-added outcomes and quality are required to keep pace with marketplace and economic demands.

We have to look at ways to optimize our environment and capabilities to decrease lead times and increase customer satisfaction.  There are standard practices that help meet these objectives and while it is important to understand and engage in foundational practices (TDD, DevOps, XP/Scrum, etc.), it is more critical to keep a keen eye on the principle and then adjust your practices as you mature and as the environment changes, as long as the principle remains intact.

There are four key points of this principle that I feel can be broken down to:

Our Highest Priority: Not “my” multiple priorities, not “your” lowest priority, “our highest priority”.  It is a collective and agreed upon initiative that will move the needle for the business.  This takes discipline and focus, which is hard, which is why it easier to put 50 projects in flight so people look busy, but are they productive? Are they moving the needle?  

Enterprise leaders must set the tone to prioritize the portfolio on a frequent cadence so that teams are executing on the most important strategic initiative and leadership is giving the team what they need to move as quickly as possible and not overburden the team with activities and administrative overhead that adds no value.

Satisfy the Customer: Rid yourself of the “I Think” mode in trying to identify customers’ needs and utilize something the Japanese refer to as “gemba” or “the real place” of where the problem exists.  Usability practices fall into this realm in making sure what we deliver is actually meeting the needs and delivers real value that will solve a problem the customer was having and do it in the shortest cycle time possible to start the feedback loop.

Getting out and talking with your customers and observing the real issues will give you a much better insight into what work needs to be prioritized to meet the minimal viable product in solving the problem.  Until you get a product in customers hands it is all just assumptions, and only the customer can tell you if they are satisfied with what you delivered.

Early and continuous delivery: Learning fast is critical in experimentation and feedback gathering. Getting to a point where we can do multiple releases a day should be our target. Is it hard? Yes! However, if companies do this already, what is keeping you from doing it?  One approach to achieving this is Preserving options through set-based design which will reduce variability by looking at more than one option that can meet the need and defer a final decision until enough data is gathered that will allow the right decision point to release. Another is the more familiar building incrementally to start the feedback cycle.  Faster the cycle, faster is the learning and lower is the risk of delivering something that does not meet your customer’s needs. 

Valuable Software: This really goes hand in hand with satisfying the customer, because if it is not adding value it is not going to satisfy your customer, and the only person that can decide the true value is the customer.  Of course, the value can extend beyond your typical “customer” such as if we are delivering a module that will keep the company in compliance which will eliminate fines, adds value and the enterprise is the customer in this scenario.

Value can be finicky based on the particular customer and timing as well and as such it can fade quickly which is why we have to deliver fast to capitalize on the value quickly as the image below illustrates:

What can we do to support this principle?

Decrease the time from Identity to Satisfy: When a customer identifies a problem to the time we can satisfy that request is the critical path in our world—the shorter the lead time the better the outcome (at least we hope so), at least the quicker we can learn.  We can do this by leveraging micro-services, APIs and other lean processes, such as paper prototyping or interactive prototypes to help us deliver quicker and frequently to satisfy a customer’s needs and meeting them where they are in their customer journey.  Inspecting every step of the customer journey to identifying potential waste is a job each of us must do daily.  When we encounter a process or step in our cycle, we should ask ourselves the following questions:

• Does this help make us more agile?
• Does this help us learn quicker?
• Does this help deliver more value?
• Does this increase quality?
• Who is it for?
• Who Cares if it we remove it or leave it?

Build Small, Deploy Fast, Learn Quickly: There is generally always a discussion on “How Big Should a Feature Be” and from my perspective the answer is “The smallest amount of value to generate feedback”.  Waiting too long because you think you need all the features before you can release, will delay the feedback cycle starting, which is how you will actually learn if what you are building is what will solve the customer’s problem.

What Doesn’t It Support The principle?

Overproduction (Extra Features):  Building in too many features that don’t meet the minimal marketable feature definition will cause delays in getting to the marketplace.  In every sprint you should be asking yourselves the following questions- 

• What problem are we trying to solve?
• What is the smallest amount of functionality we can deploy at the end of the sprint and start a feedback cycle on?
• What is the worst that will happen if we don’t put this feature in?
• If we take time and effort to work on this, will this solve the customer problem?
• If we take time and effort to work on this, what will the ROI be?

Remember the saying, 20% of features create 80% of the value.

Wait Time (Delays): Large tightly coupled features require long wait times for development, testing, and validation, which in turn increases defects and you run the risk of what you deliver no longer actually solving the problem. This also means our customers are waiting longer for their problem to be solved and that will cause them to look elsewhere.   

To determine where your longest delays are, you should start measuring lead time, response time and cycle time and use your retrospective to determine areas and steps to reduce these delay points. Focus on increasing your throughput through smaller batches.

If you are dogmatic about your practices and “checkboxes”, that will always be your focus rather than solving the problem at hand.  Don’t get me wrong, you should stand up for what you believe in but keep an open mind towards thinking about what you feel is right and will it actually solve a problem or will an experiment with a different practice be better served as long as the principle remains intact?  
Let us know how you are supporting this principle today.

Start your journey to success with our comprehensive PRINCE2 Foundation certification prep course. Become a project management expert through our online training!