Start Sooner Implement Better: Agile Principles Revisited

I can’t tell you how many times a day or in my career I have heard “Why are we not moving faster?” or the ever-popular “What has the team been doing since <insert_random_qualifier>”. Of course, those that are on the project know why things have not moved faster, because leadership has been engaged in bureaucratic administrative budgeting for six months, making sure the requirements are 100% accounted for which has taken another four months. Then final approval and sign off by a tribe of 30 or more people has taken another two months and of course a date was already committed to before the budgeting process began, so when the team can actually start work, provided other projects are not taking up their time, everyone is screaming “HURRY UP!”.  The time to hurry was months and months ago, not once the team can actually start solving the customer’s problem.

Deliver This should be self-explanatory right? I have coached teams that have argued about getting credit for a half-done story in a sprint because they got a few tasks associated to the story completed, but the story itself was not done.  If the story cannot be demonstrated or validated as a slice of the overall goal, then you did not deliver value, you just logged hours.  This is why we talk about vertical slices of functionality, INVEST criteria and splitting stories so that the focus can be on actually delivering within a time box rather than “working on” stuff for multiple sprints. 

Working Software While we want to focus on delivering as frequently as our environment and processes allow, what we deliver should actually work and moreover, solve a problem thus adding value; however, this is where it can be a bit tricky depending on how the term “working” is defined given the context.  I will sometimes refer to MVP as a vertical slice of functionality that can be validated at a defined feedback moment, such as the sprint review and will refer to a batch that can be released to customers as the MMF (Minimal Marketable Feature).  

I do this to help teams understand how much effort and complexity needs to go in each story depending on the given goal.  If we are attempting to validate a proof of concept idea, we can use a prototype, dummy data or mock details up and have a low fidelity design.  This meets the definition of “working” because we are attempting to validate a theory or conceptual functionality, not releasing to our actual customer base at this point. Before we open up the product to customers to generate incremental ROI, we would, of course, be more robust in the approach and reach a higher quality definition of “working” and “done”.  It is always best to set expectations upfront on what working means during the course of your product delivery approach. The Disciplined Agile Delivery site has a great breakdown of the different views you can take with product increments

Frequently: Shorter timelines create urgency, urgency creates action.  Delivering small, independent features are much more efficient than large, tightly coupled bundles of features.  The reasons we want to deliver more frequently are to increase the feedback cycle times and reduce the opportunities for a requirement to change, or be able to accommodate a change with little impact.  The shorter the window of time between the time a Product Owner talked to a stakeholder, created the story for the team to develop and deliver, the lower the likelihood of that requirement changing and the higher the probability we can get feedback if we are building the right thing. 

Preference to the Shorter Timescale: If you can deliver software in two weeks, then you don’t have to decide on what to do until 2-3 weeks before you deliver. If you deliver software every 12 months, then you have to take longer to decide on what to do, and that opens the opportunity for your customer to change their mind in that window of time. Shortening your delivery cycle allows you to decide as late as possible on which direction to take, which is a competitive advantage.  In 1983, Lenscrafters changed the eyewear market by having your glasses ready in an hour. This did not allow the customer the opportunity to go browsing at another company and cancel their order and it met the “need it now” emotional aspect. The timescale here needs to be understood and defined as well.  There is the sprint timescale (1-4 weeks) and there is the release time scale (3-4 months for new feature releases).  The team should set aggressive goals in improving the timescale cadence until you reach a more predictable pace.  There are practices that support a team reaching shorter timescales such as;

• Continuous Integration: The ability to automate the building and testing of code every time a team member commits to provide immediate feedback on what should be addressed to eliminate downstream affects customer experience and spend less time tracking down issues.  
• Test Automation: This really goes hand in hand with CI practices and should be a part of any development team’s practices.  I will often get teams started with just Selenium and cucumber as means to start illustrating automation thoughts and practices. While this may not address the long-term enterprise needs, it does address the question- “How do we get started”.  Start simple with a few steps until they no longer meet the needs and grow from there.

Those are only a few of the obvious practices that a team would perform to help shorten feedback loops and build in quality.  Researching DevOps would identify many more that a team should investigate into improving their environment.

What does that mean to us?

Don’t Make the Customer Wait: The fundamental measurement of a queue is cycle time.  The whole reason a work item enters a queue is to accomplish something and the longer it waits for resources to complete the work, the more time is spent waiting.  Waiting in a queue is wasted time, opportunity and revenue (Poppendieck, 2003). Customers expect rapid delivery today in all channels and if you are not meeting their expectations of that delivery cycle, there will be rapid communication of the bad experience through social channels.

Communicate Quickly To Your Customer: When you can go online and search for any amount of information that tends to increase your expectations when making an inquiry with a company on a request or product.  Customers expect companies to have data available to answer their questions as quickly as they can send a tweet out.  Email and phone calls are falling lower in the channels of communication as customers require instant answers either through chat or social channels.  Your delivery cycle should be able to address these channels quickly. 

Make Use of Gemba: The Japanese word for “the actual place” is perfect in the discovery and feedback processes of software usability as it means you are with the actual people using the product and collecting feedback. This also illustrates empathy so that customers begin to feel like they are being listened to and thus are more likely to provide feedback if they feel like they are a part of the solution. 

Principles and sensemaking #agile #change #orgdesignhttps://t.co/Mt5Qwiih1x

— John Cutler (@johncutlefish) June 26, 2017

 

Enemies of the (to be) State:

Over-Engineering:  Keep it simple.  In our second installment we touched on “Gold Plating” or putting in extra features, you just “know” the customer wants. This takes time and time increases your queue, which causes wait time.  You should be sensing a theme by now.

Over Processing: Adding additional bureaucratic gates, processes or documents reduces trust, and increases the wait time for a product to reach the market and rarely adds value beyond someone wanting to check a box.  That is not to say all processes are bad, merely, we should be inspecting whether or not they add quantifiable value or add agility to our product development process.

Point-Based Design: How many of you have attempted to schedule a meeting starting at 9 am only to get responses from people stating they can’t make it at that time, and then you start an endless cycle of emails and declines to finally arrive at an agreed upon time 3 days later.  This is point-based design.  You focus on one option and one option only which limits your choices and ability to deliver and react.  Whereas using a set-based design approach you allow options to be available and make decisions as late as possible to allow for more flexibility and to respond in a more efficient manner using real feedback.  Using the meeting example, you will get more positive feedback if you send a list of options with windows of times to schedule a meeting and you can quickly schedule a meeting based on these options rather than trying to herd folks down only one path.

If you are not quick in today’s competitive environment, then you are playing catch up to the competition instead of leading the pack and making them play your game.  However, if you hurry, you run the risk of doing things poorly, which will detract from the positive experience we are trying to build for our customers. Finding the balance can be hard, but through small batch experimentation and validated learning you can find the balance that works for you. Being able to deliver small batch experiments quickly, allows you to start sooner and allows teams the ability to respond in a leaner more result-oriented fashion.