Tag: XP

The “Priority” field in JIRA

Leave a comment

The Legacy We Build Upon

The topic of lean metrics requires an understanding of the influence of Kanban and the Toyota Production System. Scrum, as an agile process framework, was built as a lightweight version of the TPS Kanban practices that anyone could use, while Atlassian developed JIRA to enable visualization of any process, regardless of its complexity.

The “priority” field originated as part of Jira’s oldest legacy as an issue-tracking system. Greenhopper was a plug-in that enabled the issue-tracking database and web services to be used for Lean-Agile teams. Greenhopper created a new front end for the data in JIRA – namely, the work-in-progress board and the product backlog – so that a Scrum team or Kanban team could use JIRA for agile.  Ultimately, this became synonymous with JIRA and the today it ships with the agile front end OOTB.

In Scrum, the Product Backlog is used for prioritization, so the “priority” field has little meaning. In Kanban, the priority field is used to create swim-lanes based on Classes of Service.

Expedite Anything That Blocks Value Creation or Capture

“Blocker” would indicate that WIP limits can be violated and workers should interrupt their current work in favor of Expediting the blocker through the system so it doesn’t not cause long-running damage to continuous flow. The equivalent in Scrum is building out a process for stories, tasks, or bugs that are allowed to violate the Sprint commitment. In either case, the goal is to recognize that this is costly and unhealthy, an exception to normal rules. Unless it is a production defect, some element of the expedite cost should levied against the person demanding special treatment.

Flush the System of Any Critical Items that Disturb Continuous Flow

“Critical” would indicate that a card should “jump over” all other items at each step in the process, but it should not interrupt work or violate WIP limits. These items get to cut to the front of the line, but are not allowed to interrupt completion of existing efforts. The equivalent in Scrum is building out a process for what items, if any, are immediately prioritized to the top of the Product Backlog. It is typical for this to be a “Fixed Date” class of service – because fixed dates are the most consistent destroyer of sustainable flow, we want to get those things out of the way quickly so that the system can return to normal.

Everything Else Follows the “Normal” Process

“Major” and “Minor” and “Trivial” are typically part of the same Standard (aka normal) Class of Service. If used in Scrum, it is primarily for the benefit of the Product Owner to visualize previous conclusions about prioritization. In Kanban, these are meant to respect all WIP limits and follow a First-In-First-Out (FIFO) method at each step in the process.

Orienting is Essential to Agility

Leave a comment

Responsiveness and disruptive influence are the cornerstone of agility, because change through continuous experimentation is fundamental to life. Healthy and viable systems maintain their complexity far from equilibrium, relentlessly fighting collapse and death. After all, “poised” on the brink of chaos, there is an obvious business definition for agility:

Responsiveness to signals in a market with imperfect information and imperfect competition.

This context necessitates process control that keeps identity and novelty in constant tension – even against our most brilliant ideas. Thus, our tactical principles for general preparedness, quick orientation, and powerful responsiveness will be rooted in the need to orient faster than the enemy system, our ideological competition. Only the working product of our efforts can provide a pragmatic judgment of the value we have created, so the ultimate measure of our success as a Disruptive Influence is the actual change in behavior we have caused.

Because individuals and interactions are inherently complex, adaptive, and difficult to predict in the reality of socioeconomic competition, we value knowing them directly, studying them and interpreting their position ourselves. We value this over relying on their predictability, likelihood of adherence to an agreed-upon process, or correct use of the best possible tool for any given job. Although we assume processes and tools taken at face value will deceive us into a false sense of stability, we also recognize that individuals and interactions cannot always be taken at face value either.

Because responsiveness, both in decisiveness of action in an unexpected situation and as adaptation over a long-term investment horizon, will consistently be awarded with asymmetric payoffs, we can only trust a plan to the extent it includes contingencies, delays commitment, and distributes control to the individual with the best understanding of the situation at the time a decision must be made.

Because compromise is the inevitable and unsavory outcome of “contract” negotiation, while creative endeavors in contradistinction rely on the energy of tension, cognitive dissonance, intra-organizational paradoxes, and conflicting interpretations, we invest our time and effort in social exchanges while delaying formalization. A contract relies on an external locus of control for its power and validity, whereas we must prioritize a social and socioeconomic view of the complex system we hope to lead into adaptation.

Because a socioeconomic “factor of production” is defined by its output, evaluated on how much more value “the whole” can add in excess of its “parts”, and because digital products are continuously created and maintained but never mass-produced, we take the tangible product of our endeavors as the only valid measure of its worth.  However good the product design looks on paper, however well-defined the future state is documented, only exchange in the marketplace can determine the economic value of the product we have actually created

Your ROI is Total BS

4 Comments

ROI is meaningless.  GP% is meaningless.  Signups.  Clicks.  Views.  None of these tell you anything meaningful or actionable.  None of this ensures survival.  In fact, it is through sheer mass that some enterprises survive.  It is the churn of hype cycles and perceived value that keep new customers fooled.  But it is definitely not sustainable.  Big investments end with big blunders that result in mass layoffs and enormous bankruptcies.  The name is the only thing that survives. Is that the company you set out to build?  No.

Let’s assume you are a software company selling enterprise SAAS.  Your entire company is the value stream.  The ongoing operating costs are less than ongoing revenue.  Investing in the sustainability of your model of economic value creation and capture is every dollar you spend.  Those dollars, little by little, react with the market either creating or negating value creation.

The problem is that most enterprises work from the assumption that large investments equate with economies of scale.  While this may be true of investment in automated manufacturing there are no economies of scale in software development.  It is the individual knowledge workers that create innovative software.  The velocity with which you can adapt as a system combined with superior understanding of problem-solution fit in the market is the key to competitive advantage.

The question of how to invest should be quite simple when you are a large company that has revenue growing at the same rate as costs – small investments per opportunity with maximum ability to correct an incorrect investment.

That is enterprise agility.

Enterprise Agility is the speed at which an incorrect decision is recognized corrected.  The smaller the investment decision, the faster the return is known. Lean trims the excess weight, off-balance feedback, and poor technique that undermine agility.  The effective flow of information across the creative process of knowledge workers is essential.

This is where you must realize that unless you layoff staff, you’re investing the same amount continuously.  The ROI of a project is as meaningless as the ROI of a developer day.  The input of resources is relatively static, maximizing the value stream as a system is essential.

This is why the a right-place/right-time, brilliant, socially-savvy entrepreneur-engineer is the most agile and lean possibility: perfect and instantaneous knowledge-sharing internally (in the brain), distinct competitive advantage through the extremely unique skill set (s)he has grown to master.  That is the sprinter that you want your Superorganism to become.  In the right place, at the right time, with the correct knowledge and materials, with instantaneous information flow across the value stream.

So if ROI is meaningless to decisions (because we are paying for individual pursuit of knowledge-worker-creativity regardless of rate of return), how do we possibly make rational financial decisions about innovation, discovery and exploitation of economics rents?  In fact, lean manufacturing has studied this for decades.  When the rate of investment (the cost of production) is held constant, prioritization of economic value added rather than expected rate of return should be our focus.  In a zero-sum competitive game with uncertain returns and asymmetrical information, the time between investment and value capture is the only meaningful variable we can impact.  While cost of delay versus product lifetime return on investment may be more difficult to understand when looking at Toyota and the Prius, this is easy to see with Software as a Service, because the continuous addition of value in exchange for subscription-based fees creates two roughly stable lines. The only meaningful way to improve investment is to exploit information asymmetry more effectively than your competition.  Since you are investing the same amount continuously, you must minimize the cost of delay of value capture.

To put it another way: In a system with continuous investment, only the opportunity cost incurred due to delaying an investment matters. This is not first-mover advantage at the new product-market level, this most-effective exploiter of innovation as an a competitive advantage.  This requires a shift to systems thinking and investment in strength of culture. Money is not your scarcest resource. Brilliance-time (that you’re paying rent for daily) is your scarcest resource.  To maximize value capture, you must maximize the time spent in a state of market information asymmetry.  At the current pace of innovation and obsolescence, the only way to maximize value capture is to minimize cost of delay due to incorrect prioritization.

This implies three goals:

1 – Minimize the impact of an incorrect investment of system-brilliance-time by reducing size of each commitment

2 – Increase the adaptiveness of the system to maximize throughout and future adaptiveness

3 – Minimize the time it takes to receive feedback (primarily through analytics) from the market

4 – Make appropriate risk-taking and experimentation a normal part of every creative process

DevOps Athleticism

Leave a comment

Let’s face it – being small makes it look easy to be nimble.  Look at your average kindergartener: they may not always be graceful, but their capacity for unexpected action or a rapid spontaneous change in direction at full speed is frequently mind-blowing (for each of mine, it was usually a sudden jump into the risk of oncoming traffic).

So it’s understandable for the established enterprise to look at the youth (and occasional hyperactivity) of startups – and small companies who never grew up – and feel a little fat, a little old, a little bit brittle.

That metaphor doesn’t need to end there, though, because there are also large companies maintaining a portfolio that balances finding new opportunities on the one hand and exploiting new opportunities on the other.  These are two very different operations, though, and companies find balance difficult.  Just like hyperactivity is internalized in the executive function of adults who had physically hyperactive childhoods, that rebellious startup creativity can survive unscathed within the mature organization. By doing so, you can simultaneously continue category-killing through innovation despite staying the course and reaping decades of fruits on already-mature markets and products.

Likewise, to extend the agility metaphor, life is full of athletes in the top quartile of height and body mass index. They top the BMI charts compared to average scrawny-but-chubby adults despite doing it with rather lean body composition.  They are practically outliers, and definitely don’t fit the “standards” set by statistical BMI.  More importantly these individuals put “nimbleness” to shame; and just look at those kindergarteners revere them. Look at the heroes of the NFL: agility doesn’t begin to describe their mastery of movement.  Look at star hockey players in the NHL: they move with the power of an elephant, the stamina of a gazelle, and the grace of a ballerina.  The stereotypical Hollywood karate master black belt may have a very thick, potbelly body-type, but the master needs very little movement, in just the right places at just the right time, to send an opponent flying.

So it’s simplistic at best to “think like the startups” or “be more agile”.  You cannot transplant a culture.  Size alone is not their advantage, strength alone is not their advantage, tenacity alone – as much we love a good underdog story – is not their advantage.  To emulate any ONE  attribute of the lean-agile startup on the rise is foolish.

Stop talking about enterprise at-scale agility like you’re trying to be that kindergartener veering into the street unexpectedly. 

It’s more than being lean, or gaining experience or agility. At scale you need to build repertoire of enterprise-grade DevOps Athleticism!  It’s one thing to have an impressive vertical jump but quite another to jump over a fence, hurdle over a tackling safety, or parkour up a building,

Training for Obstacles

For the support engineer team, kanban looks a lot like an Olympic marathon team.  You constrain WIP (focus/movement pattern), create a sustainable pace, and fuel as you go – you train for the long haul by (basically always) running for distance.  It may be fragile spaghetti code built over the decades, but you your crack team knows it inside out.  But that’s not the majority of your at-scale enterprise.  As you get further from a continuous flow of relatively similar requests and move toward innovation and greenfield disruption efforts, kanban and even scrum are going to fail unless you include the assumption of uncertainty and churn in your overarching process.

This is like the difference between a New York marathon versus Tough Mudder or another obstacle-rich competition.  If you don’t build your capacity for speed-strength and coordination against unexpected obstacles, you’re likely fall short. The long and short of it is, if you can count on a marathon, kanban your way to glory.  If unpredictable obstacles and risk-taking for glory are fundamental, stop whining and start training. Look for extra opportunities to beat down tough challenges instead insisting on a slow and steady pace.  Speed and sustainability need to be loosely coupled in a strong DevOps process.

Jumping the Fence

I can tell you from experience that maximizing raw strength in the barbell squat does not correlate to jumping higher.  If you need to jump higher to make a layup, you do things like box jumps.  If your really daring, leverage your box jump into jumping over a 3-4′ fence (or hurdle) from a standing position.  Raw strength on the one hand and sprint speed on the other don’t give you the actual agility, coordination, and explosive power you’d need.

Similarly, coordination of multiple teams is more complex than strengthening, quickening, or improving communication with each team individually.  Establishing a cadence of synchronization and opportunities for cross-pollination of ideas – even as you increase the independence of each team  

This extended metaphor has a great caveat – go find a 3’ tall picket fence, stand in front of it, and try to jump over.  Assuming you haven’t been practicing, I bet your body stops you.  The same is true of a healthy DevOps system – when you try to launch into a painful bout of stupidity, the developers stop you.  If you’re smart, you don’t force yourself into a giant failure.  Instead, you practice a bit and ramp up your agility to get your entire body confident you won’t end up in the hospital.

Throwing a Punch

You don’t throw a punch with your arm.  You throw it from the ground up, leveraging the perfect twisting launch of one square inch of fist powered by your entire body.  If you’re the square inch that gets to land the winning knock-out blow, don’t get cocky.  You’d be nothing without the support and power of the entire body.

Measuring What Matters to Innovation

4 Comments

Competing on Innovation

The rate of technological innovation and adoption has accelerated to a level that would have been impossible to imagine centuries ago. As such, an amazing number of startups have been able to succeed from strategic position based on niche-market differentiation and a culture of passionate innovators.

Established – and well-funded – large enterprises have taken note. Adoption, disruption, and even disappointment and abandonment of products are forcing every company to tackle what cloud computing, mobile, and IoT mean for their categories.

Every company is trying to become innovative, because we are all competing based on technological innovation.

Unfortunately, building a sustainable competitive advantage around culture of innovation is far more complex than previous strategic positioning was. Nash equilibriums a few decades ago could be easily resolved with a few long-term commitments that ensured indirect competition and margins for all major players. Innovation could actually be stifled – purposefully – by industry oligarchs to minimize the risk of new entrants. The rate of innovation today has made this control impossible, to the benefit of the consumer.

However, building a culture of innovation requires an entire new way to structure the organization and reinforce its behaviors. This is made even more challenging by the abundance of data available that was inaccessible before. Measuring metrics is the formalization of what decisions are worthy of notice. Thus, to understand what to measure, a leader must know not only how to measure a metric but also why the metric matters to the achievement of long-term goals.

To explore this, I’ve been discussing the connection between individual motivation and the company’s goals as a Minimum Viable Superorganism:

‘Selfish individuals pursuing shared goals (arising from shared underlying incentives), held together by a Prestige Economy which consists of two activities: (1) seeking status by attempting to advance the superorganism’s goals, and (2) celebrating (i.e., sucking up to) those who deserve it.’

The executive and visionary of the company must be the purposeful “mind” leading the activity of the superorganism. The relationship between employee motivation and company outcomes rely on this Prestige Economy, so leading a company means guiding this economy.

Naturally, it easiest for me to discuss this in terms of scaling agile or scrum, or technological innovation in start-ups versus large established enterprises. Discussing each, if you are hoping for very specific metrics for you company, will take the rest of my life so I will leave those conversations to a per-company basis. However, the fundamental issue confusing the connection between innovative teams and enterprise-level accounting metrics is the virtually insane forgetting of what has truly changed in our new and rapidly accelerating tech-adoptive society.

 

Market Risk vs Technical Risk

If you recall the example of the terrible metric (for innovation-based companies) “allocable resource utilization” we saw the well-established, consistent distribution – i.e. strategic trade-off – between utilization and responsiveness.

If you imagine one very capable engineer you’ll find:

  • Demands arrive to the employee at a variable rate.
  • Work is accomplished at a variable rate.
  • There is one worker.
  • The possible queue of demands is potentially infinite.

This type of queue is an M/M/1/ ∞ queue.

Whether the “1” here is a server, an interstate, a mobile developer, or a 1990’s movie hacker’s CPU, increased utilization of total potential results in rapidly-accelerating diminished returns as utilization reaches 100%. Likewise, you can occasionally “overclock” with appropriate support and recovery, but constant over-use results in chronically poor responsiveness to demands, a pile up of unmet requests, and finally, a CRASH.

HOWEVER, competing on innovation requires additional variables for our M/M/1/ ∞ queue because it treats “requests” as a discrete abstract entity. It accounts for the possibility, because it is a Poisson distribution, of requests not being the same size or difficulty – technical risk – by stating that work is accomplished at a variable rate.

What the M/M/1/ ∞ queue fails to account for is whether or not the request was the correct request. In the case of a server handling API requests, we could assume the incorrect initial request probability is zero if we believe retrieving unwanted data is the failure intuitive front end or simply user error (the API and the server is not the guilty party). If we are imagining a highway over an extended period of time, drivers who intended to take a different route and got on the highway by mistake are virtually an outlier, and an even less noticeable percentage behave in a way that would impact the flow of traffic.

In technological innovation and the development of any given software product, the risk that the request was the correct request at the time it was made and still the correct request by the time it has been fulfilled is EXTREMELY HIGH. The variable that prioritizes responsiveness over utilization in technological innovation is Market Risk.

After all, when we say “competing on innovation” what we really mean is “responding the fastest to disruptive market shifts while also creating market disruption or new demand and adapting quickly enough to capture value profitably”.

We don’t say the latter, of course, because it isn’t as sexy.

The reality is that a culture of innovation requires a few things that run counter to the leadership methods of old school consulting or manufacturing organizations. Don’t go on a request for quantifiable metrics on these, but an innovation culture requires things like:

  • Excess allocable brilliance
  • Willingness and aptitude for adaptation
  • Vigilant feedback-seeking
  • Permanent restlessness

The greatest risk of any innovation-based company is not the technical risk of learning to implement what was promised or the project risk of time-to-market or delayed advertising campaigns. The primary risk when competing on innovation is the market risk that, for any new product:

  1. The market knew what to demand
  2. Supply correctly met that demand
  3. The product still met a need by the time it went to market

In the App Store alone there are thousands of new apps per day. The market risk not only for a software product in this one market is unprecedentedly high, likewise shifting immense market risk to every feature added and every update released to your company’s increasingly less loyal consumer base. That is why Scrum works sprint-based, with increments that should always require less than a single sprint (2 weeks, ideally) of development team effort – not to mitigate project or technical risk, to mitigate the market risk that the end users or stakeholder knew what they actually wanted, knew the impact on the overall product, properly communicated it, and still want it by the time it is delivered.

 

Fail Faster to Succeed Sooner

We can see that when competing on a culture of innovation, receptiveness and relevance are the necessary compliments to responsiveness. This is the most important way in which agile delivers higher-quality software. Code quality, user testing, and market fit are all checked as often as possible. A great Scrum team fixes cosmetic, logic, and intuitive experience problems as they go, looks for feedback immediately about the demand for the feature, then enhances each tiny increment of the product prior to each release. In agile we call this “failing fast” so that we can assure we succeed sooner. The tight feedback loop means creating the right thing very well, based on the newest information available.

Time-to-irrelevance is the greatest risk to every innovation-based project. Not only the market risk of irrelevance, but also the loss of relevant context – both code and product vision – when ensuring the quality of the software and resolving defects or maximizing the return on a feature by improving it before moving on to the next feature.

 

 

Metrics that Matter

If we are driving a superorganism comprised of teams that are focused on product innovation – not only in software – we can see there plenty of metrics that will reinforce a Prestige Economy built for succeeding in innovation. I’ve described a handful below. One last note of caution here while these metrics are powerful and valuable, it will still be essential to clearly express who is accountable for each metric and empower that person or team so that they are in control of that metric. These are also defined rather philosophically. If you have a documented Work In Process flow to share, I can give you specifics.

Measurement Goal #1 – Receptiveness

Feedback-to-Answer cycle time – the total process time from the market making a demand to the market receiving an indication of response. In classic “core” Scrum, this may simply be the time from a customer making a request to the Product Owner telling that customer a valid expected release date. In a large-scale environment, this may be the time from a Tweet received by Marketing to the time Marketing announces the planned features in a new update that contains the feature requested on Twitter. To the extent your large enterprise is attempting to compete with small startups, this is the crux of your challenge. An entrepreneur leading a small team only needs manage her or his reputation for accuracy of promises and find a reliable way to ensure that single-mind heroic vision for the product becomes a reality. The cycle time from neuron to neuron is infinitesimally smaller than any scaled cycle time that includes multiple business units, functional teams, vendors, and a PMO.

The Feedback-to-Answer cycle can also be measured at the Work-In-Process level – when a card in a latter step is kicked back to an earlier step, how long does it take for that feedback to receive an answer? If it takes a long time and there is very little work-in-progress, this is a sign that receptiveness is poor. Maybe the Scrum board isn’t visible enough or the daily stand up is not as effective as it should be. On the other hand, if there is a huge amount of work-in-progress, capacity is over-utilized and responsiveness is suffering – setting WIP limits may be necessary (even if only for a short experimental period).

Feedback-to-Answer Quality – This is likely to be a qualitative measurement if used ongoing, and is likely a tertiary metric looked at only occasionally. The most relevant use for this metric is electronically documented support tickets that receive a rating by the requestor after it is closed. The problem with qualitative responses, of course is the possibility that only the most positive or most negative reviewers to surface. This makes this a poor metric for individual or team performance but should summarized more broadly for an indication of the process. Don’t set a target, just learn from the insights.

Supply-to-Demand Receptiveness – From a buzzword standpoint, this is your “Social Listening” as an organization, both internally and externally. From the time you meet a demand, how long does it take to discover that you met the right demand? How long does it take to know if you met the right demand correctly? For software, don’t leave this purely in the hands of social network listening – build into your software trailing indicators like usage analytics, product-wide ratings, and (sometimes) per-feature ratings and feedback soliciting.

In a large-scale product environment, pay attention to listening from all sources. A few new “ceremonies” are going to be needed to encourage collaboration from Epic Owners, program/division-level alignment of a shared backlog across products, and Stakeholder Gathering to solicit additional feedback.

Receptiveness is the precursor to responsiveness. If you aren’t “listening” to your market, you will never respond to demands correctly.

 

Measurement Goal #2 – Responsiveness

Demand-to-Supply cycle time – This is the traditional definition of cycle time and the best metric that carries over from Lean Manufacturing to Lean Startup principles. From the moment a market demand is made, assuming receptiveness is held constant, what is the total process time until supply can meet that demand. Anecdotally, the highest performance with this metric in a Scrum team I led as Product Owner was on a large enterprise tool. We released to stakeholders twice a week and released to production weekly. A feedback feature was created that gave the users direct input into our product backlog. We were able to respond to improvement requests made on Monday in a fully-tested Production Release that Wednesday. Statistically, these wonderfully short feedback cycles were outliers and relied on circumstances more than team performance. I share that anecdote as challenge to whatever complacence you may have about That said, if average Demand-to-Supply cycle time is greater than 90 days I would challenge you to consider if you are really “listening”.

Demand-to-Supply lead time – This is the traditional definition of lead time and is the time from initiation to completion of a production process. In classic Scrum, that’s the time from commitment at Sprint Planning to the time it is called Potentially Shippable by the Product Owner. This is a once-in-awhile metric that should be checked as an indication of whether teams are sizing stories and committing properly.   Whether a team is new or old, they will need extra reinforcement from a manager when average lead time is consistently greater than the sprint length. This is a sign of over-commitment and sprint carry-over. Too much WIP, over-utilization, and poor story sizing will leave a team hamstrung. Quality will suffer, context-switching will breed deceleration of velocity, and burn out will occur. This is at the heart of Little’s Law. When lead time is consistently greater than sprint length, this isn’t a performance metric to track – it’s a trailing indication that management needs to set clear expectations around the trade-off between velocity and quality (including market fit). Set WIP limits and enforce true swarming activities. Because WIP is a leading indicator for Lead Time, reducing WIP should lower lead time back below sprint length.

There is an important call-out here. While experienced Scrum teams know all too well the relationship between team WIP and Lead Time – this only covers the process states for that team. In a scaled implementation, where the stakeholders have an internal proxy voice (imagine a product division large enough to include a Social Listening Analyst on the marketing team) WIP limits at the Epic, Feature, Theme/Campaign, and Product may be necessary. Putting too many items on the Work In Process flow of the Product Marketing Managers that must A) Add Epics to the Product Backlogs and B) Give feedback that the right thing was built and properly fits market demand will create terrible inefficiency in the overall innovative delivery process. The same is true when new Business Development or long-term relationship-owning Account Managers are part of the input and output. No amount efficiency gained by the teams building the products will EVER MATTER without tightening the every other feedback cycle. Restrict stakeholder WIP to ensure they pay attention, provide meaningful feedback, and properly communicate new features and gather end user and customer feedback of their own. If average lead time per story is 7 business days but it takes an entire quarter for a minor enhancement worth millions in revenue to “circle back” through the organization to the development team – YOU WILL LOSE. Pack your bags, a startup is about become a category killer.

 

Measurement Goal #3 -Relevance

Cycle-Time Feedback conversion – when an end user or stakeholder makes a request, the WIP cycle ought to have a traceable “funnel” for requests making it through to market. This is not a performance metric but a continuous improvement metric. If a product is in its infancy and market share growth is on the rise, but product innovation is stagnant, ask for more requests to go through. If a product is mature and market share accumulation has plateaued, but the conversion rate is extremely high – the process may be building for the sake of staying busy and a new product should be innovated.

Lead-time Feedback Quality – This is another qualitative metric that may be useful in a 360 review process. From the time a team starts working on a product increment to the time it is delivered, each time an opportunity for feedback occurs, what is the relevance and value of the feedback that is given? Putting metrics around this can be very valuable for a short period of time if approval processes and quality assurance are failing. If it is right for your scaled environment and will not cause unnecessary inefficiencies, this can even be formalized and automatically enforced (e.g. make a Resolution Type and Comment Field mandatory when the Product Owner moves a Story card to Closed, with the expectation that the quality of the feedback will be a topic of review by a manager for purposes of mentoring and career development). At scale, think very hard about the inefficiency this may create and its fairness across the organization prior to roll out.

Conclusion

These are a handful of metrics that actually matter for innovation and success. For specifics that apply to your organization, feel free to reach out to me for free advice anytime at andrewthomaskeenermba@gmail.com or Tweet me @keenerstrategy

This is part of a series!

Part 1 – Metrics: The Good, The Bad, and The Ugly

Part 2 – How to Fail at Performance Metrics

Part 3 – Rules For Measuring Success

Part 4 – Measuring What Matters to Innovation

Throughout the series I tie together ideas from two great resources:

Kevin Simler’s Minimum Viable Superorganism

Steven Borg’s From Vanity to Value, Metrics That Matter: Improving Lean and Agile, Kanban, and Scrum

Lean Principles for Agile Stakeholders

1 Comment

The Problem:

Last week, a colleague and I were discussing the gap in information and training materials surrounding a commonly reported challenge in agile product delivery: Stakeholders who have no experience succeeding with agile.

In Defense of Stakeholders:

The “stakeholder” role in Scrum has no training class.  This is because the “stakeholders” in Core Scrum is not a role, it is a symbol that signifies “that which causes demand-backlogs”.  There are multiple ways this emerges in agile processes:

  1. Core Scrum:  The “Heroic” Product Owner is also the Business Owner.  The stakeholders are paying customers.  Here, stakeholders don’t need training, the need a voice.
  2. Single Organization, Multiple Programs:  The “stakeholder” is one or more Product Marketing Manager that plans and advertises what the delivery organization with create.  The Product Owner must drive heijunka or “level loading” to balance out the demands that can be intelligently fulfilled by the teams available.
  3. Vendor Organization, Multiple Clients:  The “stakeholder” is one or more decision-makers for one or more external clients.  The Product Owner is plays a consultant role, facilitating prioritization and backlog decomposition.
  4. Large Scale Scrum:  The “stakeholder” is a business owner for single emergent product offering delivered by multiple teams.  The Product Owners either become specialists on specific features or may be responsible for specific platforms.

Why is there no “role” for the stakeholder?  Let’s define what a “role” is:

Unlike a position or a title, a role is the single-most important “thing” at the confluence of responsibility, empowerment, and accountability.

In each of the scenarios above, the stakeholder is not responsible for the product, has not been empowered to produce it, or does not have final accountability for what is produced.  However, whether one or many people play the part of stakeholder, there are several Lean Enterprise concepts that can encourage alignment and effective product planning.

Lean Concepts as a Stakeholder:

The first concept to grasp in Lean planning as a stakeholder – as I discuss at length in Applying Lean Kaizen to your Enterprise Mobile Strategy – Kaizen is the process of continuously breaking down a process, removing unnecessary effort or waste, and rebuilding it as a more efficient and effective process.  In manufacturing this progression has been underpinned by technology:  specialization around tools, mechanization of movement, automation of production.  With mobile solutions, we minimize the time and effort in turning social information into actionable data.

As a stakeholder starting the kaizen journey, use these Lean principles to guide your ongoing investment in a portfolio of mobile application programs.

Just In Time

A delivery team uses “just in time” in the Scrum framework as an approach to ensuring the most valuable features are produced “next” by delaying commitment to user stories until it is necessary (Sprint Planning).  This allows the shortest possible feedback cycle between demand and supply so that the Product Owner can adapt feature delivery to the most recent information from stakeholders.  Just-in-Time is a central concept from the Toyota Production System:

Supplying “what is needed, when it is needed, and in the amount needed” according to this production plan can eliminate waste, inconsistencies, and unreasonable requirements, resulting in improved productivity.

via Toyota

Just-in-Time (and just-enough) is not only a useful principle for the delivery team, it is central to effective feature and user experience planning, at the product, program, and portfolio level.  Conveniently, your target audience is increasingly mobile-first, but mobile solutions are fundamentally Just-in-Time!  Social information becomes actionable data on demand and on the go using a highly focused and intuitive user experience.  The ability to ignite a chain reaction from 3 taps of an iPad is an incredible time and cost saving.

PRO TIP for Stakeholders:  The most important way a great agile stakeholder can encourage Just-in-Time principles is through comfort with uncertainty and an understanding of “priorities” versus “prioritization”.

  • Don’t promise more certainty than is justified by market conditions.  The mobile strategic landscape and technological environment rapidly evolves – if you have planned ahead more than six months, have realistic expectations that some of those longest-term plans and promises are likely to change.
  • Plan to Pivot – The more short-term your commitments, the easier it will be to change the plan if market demand shifts.  Over-promising long-term plans to users may restrict the ability to pivot in the future.
  • Know your industry – What level of documentation do you really need?  Do you need comprehensive documentation at the end of the delivery process for regulatory compliance?  Do you need a user manual or should that time and effort provide training and cues in-app?

Jidoka

From the Toyota Production System, the concept of jidoka – “automation with a human touch” means that machines are “smart” enough to identify their own failure, empowering human operators to rectify the problem before faulty parts enter the production line.  Typically, these were only tested at the end of the production line, so a single machine creating bolts for engines could make an entire day’s work unshippable!  As a stakeholder, think of features that support a safe-to-fail environment rather than a fail-safe environment.  Construction workers wear helmets because the ability to create a fail-safe environment is impossible.  Instead, the helmet reduces the overall risk of failure.  Everyone has a responsibility to be careful, but the consequences are minimized.

PRO TIP for Stakeholders:  In mobile, the ability to focus a user on completing a single workflow quickly and objectively is your goal.  This creates a powerful ability to lead subjective observation into objective judgment.  Anywhere your employee is asked to supply critical information, drive what is captured toward Business Intelligence that can inform them and your organization about decisions being made and their impact on safety and profitability.

Standard Work

Because the mobile enterprise user is able to follow an established workflow of interactions, this is a time to analyze current best practices and standardize them.  Standardizing what is done, how it is done, and consistency of output not only reduces the necessity of identifying and addressing under-performers, it creates a context for the employee in which output quality is held constant for them, reducing stress.  Even more importantly, once work is standardized with a mobile application (e.g. instead of a document template) the consistency of output and capture of Business Intelligence will allow an objective review of “best” practices, removing some of the emotion and politics from the kaizen process.

PRO TIP for Stakeholders:  One changes are identified, effective MDM enables your organization to control the shift to a more effective practice by simply releasing a new version of the software.  Build any training (using interstitial screens) and feedback (with modal feature ratings) directly into the application.

Heijunka (level loading)

The Lean Lexicon, 4th Edition defines heijunka as:

“Heijunka is leveling the type and quantity of production over a fixed period of time. This enables production to efficiently meet customer demands while avoiding batching and results in minimum inventories, capital costs, manpower, and production lead time through the whole value stream.”

For an enterprise mobile solution, it is important to know a) what element of a process is most time consuming and b) when separate applications make more sense than adding features to an existing application.  In Lean Enterprise consulting, we compare the “Cycle Time” of each process block to the “Takt Time” of the workflow.  For a mobile application, cycle time is often the time spent per screen while Takt time is the total time from launching the app to completing the workflow that would need to be achieve in order to meet productivity goals.  If any step “as is” in the workflow is exceeding Takt time, its complexity must be reduced, it should be divided into separate features, or your may need a separate application.

PRO TIP for Stakeholders:  Clearly, you will not know any of this without including analytics in your application!  The testing completed by the product team and key stakeholders already familiar with the application will not show which features are causing a bottle neck for your actual users.  Use analytics!

Minimum Viable Product

While I touched on how to plan investments in the original Minimum Viable Product in Lean Startup Principles in Custom Application Development, this is narrow view in Lean Startup theory.  Once the initial release is live, the true principle of Minimum Viable Product – meaning anything that is produced by a process, not just the “product” you intend to market!  As a stakeholder, it is important to understand that you are not driving a single minimum viable product, you are part of a process that must maintain minimum viable production.  This is why we focus final testing on the user’s value from the workflow and look for sticking points in completing the desired output.  Minimum Viable Production Planning will means that throughout the delivery cycle, every increment is the confluence of minimal effort and highest viability.  In Scrum this is represented by the Product Backlog prioritized by the Product Owner.  Working software every sprint is the ultimate test and highest priority for the Scrum team, so Sprint Planning must establish the Minimum Viable Product (Increment).

PRO TIP for Stakeholders:  The goal is not to deliver less – the goal is to invest only the amount needed for any given product increment before diminishing marginal returns begin to erode the investment.  The goal is to invest in as many high-ROI production increments as possible rather than expending immense investment on process waste.  The more you are able to align with the idea of 2-week mini-projects (Sprints), the higher the overall ROI on the aggregate product.

Applying Lean Kaizen to your Enterprise Mobile Strategy

1 Comment

Kaizen:

Kaizen is a Lean principle that lays the foundation of choosing the right enterprise mobile application solution.  Loosely translated from Japanese, kaizen means “change for the better”; but this principle is bigger and bolder than tacking on an improvement to an existing structure – it is the process of continuously breaking down a process, removing unnecessary effort or waste, and rebuilding as a more efficient and effective process.  In custom enterprise application consulting, kaizen underpins the process we follow in finding the right enterprise workflow that is both proprietary to an organization’s competitive advantage while also a source of waste.  Because this seems contradictory, companies rarely ask for the application that will make the biggest difference to their organization.  In fact, the need for mobility-based kaizen is not always an easy concept to see without an outside perspective.  When a unique process is driving so much success it is often assumed untouchable and treated as though infallible.

The fear of change in an organization is powerful, especially when combined with an “If it ain’t broke don’t fix it” mentality.  Unfortunately, operational effectiveness is not strategy and either a) your competitors will overcome the learning curve disadvantage and adopt your workflow or b) a small tech-savvy startup will render the proprietary workflow irrelevant.  Adopting a technical solution to maximize your unique process will give you a proprietary edge that will not be easily copied.  Adopting an innovation mindset as a strategic position will put you permanently ahead of the pack.

So how do we find the right enterprise mobile application, even more so build a portfolio of application programs?

The 3 Gen of your Enterprise:

Lean consulting begins with finding the 3 Gen or “actuals” of your enterprise.  Kaizen is impossible without direct insight into the organization, so the three “actuals” are key in finding the right application that can succeed big and drive the adoption of innovation and mobility as a competitive strategy:

  1. The Genba – By visiting the Genba or “Actual Place” where business is done, products are built, revenue is generated, an enterprise solutions consultant can view and understand the operations that create revenue, whether in a factory, a medical facility, or a sales showroom.  Through first-hand observation, rather than conversation, so much more can be learned about what an organization does, how it is done, and why it is done.  Whiteboards and conference calls can never convey the real heart of an enterprise, the “What’s the point?” or the “What’s it worth?” so coming to the actual place is critical to building out XP User Stories that speak to the pain felt by people performing the work on account of the inefficiencies they will otherwise protect out of a fear of change.  The employees, as users, must capture real value in order to drive higher revenue and operational cost savings.
  2. The Genbutsu – If possible, a great consultant doesn’t just watch, it is even better to directly interact with the genbutsu or “Actual Thing” – the real equipment being moved throughout a hospital or the customer “hand-off” artifacts.  In Lean Manufacturing, this often focused on the actual parts being assembled, the path those parts travel in a factory, and finding ways to simplify repetitive motions, reduce unnecessary travel distances through better placement of the work stations, or reducing the complexity of a step in the process by changing the order in which pieces were added to the whole.  In enterprise mobile solutions the “actual thing” is often information and the path it takes before and after that information becomes data and drives actions that produce revenue.  Information is easily decontextualized, so minimizing context-switching in the information-data-action flow is critical.  Mobile solutions drive context-awareness that turns social information into actionable data immediately and cuts out waste.
  3. The Genjitsu – Jitsu is an art, skill, or practice, a word that evolved etymologically from the characters meaning “a step along the middle of a road”.  As a Lean consulting concept, this means we must grasp the “actual situation” as it pertains to one process as a step in an overall flow.  More importantly, we must quantify the reality as objectively as possible, separate from emotional responses due to ego, social status in the organization, or feelings of blame.  We do this by obtaining data, making hypotheses, documenting workflows, and validating assumptions.  The goal is to not only make a well-informed decision about the most valuable application that can be created, but to validate the features that will be part of it.

Once the three “actuals” are known, sources of waste can be objectively identified, solutions crafted and prioritized, and a Minimum Viable Product is determined.  For more details on delivering a Lean MVP, see my post Lean Startup Principles in Custom Application Development to see when to release and when to pivot.

Agile Priorities: Keeping Documentation Lean

2 Comments

Agile Transformation

If you want your agile transformation to fail, allow the development team and all supporting functional teams to focus on the waterfall deliverables and dependencies to which they are accustomed.

In “Fixed Budget, Fixed Scope? Be Agile Anyway.”  I argued that agilists, especially newcomers, must understand that the Agile Manifesto is a statement of priorities – at times, tools and interactions, comprehensive documentation, contract negotiation, and following a plan are all part of the product that is created by the process that keeps your teams in business.

In software development, this is the exception rather than the rule.  

For “core” Scrum, the proverbial “one-team-in-a-garage”, this is pretty simple.  Everyone you need is in one room.  When scaled, a delivery organization is often “compound-complex” – it is “compound” when two or more independent functional knowledge areas must cooperate and “complex” when at least one knowledge area has dependency on another (these aren’t fancy concepts, just basic grammar).  The moment a delivery process moves beyond one-team-in-a-garage Scrum, there is compound-complex value stream:

The web team and mobile team will build a user-facing experience, while the middle tier team provides RESTful services, only after sales executes the contract and the Product Owner builds the backlog; meanwhile, UX, BA’s, and QA’s will provide documentation.

In this value stream, the “Wildly Important Thing” is the software that a user will consume in order to drive revenue.

Because Communities of Practice have their own traditions and methods of proving extrinsic value, shifting their priorities is much more difficult at scale.  Plan to change the physical distribution in order to overcome the functional “clumping” that Waterfall encouraged.  Moreover, agile transformation will require finding and eliminating the agency dilemma of managers who built their kingdoms around waterfall values.

Resolving Wasted Effort

If agile at scale has not improved company-wide quality and velocity, it is likely due to waste in the overarching process – you must remove any activity that does not drive value creation that a user consumes and the business will capture.  This is the central rule of the User Story – if it does not make a difference to the user (and occasionally the owner) it is wasted energy, a distraction.  You find this clearly stated, often, in Jeff Sutherland‘s various descriptions of “Bad Scrum” – without delivering working software that matters to the user an organization will be stuck in a self-reinforcing cycle of inefficiency and ineffectiveness.  No one is making a difference in the world, selfishness increases, velocity never improves, no software is delivered.

For a compound-complex process to stay agile, the Lean principles of Just-in-Time and Just-Enough to must be applied to all forms of documentation – business rules, persona descriptions, wireframes, UI designs, sliced assets,  value mapping, technical constraints, market conditions – all are a means to pleasing the user, not the end goal (software that a user values).  The User Story is the cornerstone of efficient, effective product delivery because it is a “reminder of a conversation” about a result from which a user will derive value.  For some teams, a set of wireframes can all but replace “cards”.  An image of a login screen is sufficient to drive the conversations a team needs to have about client-side validation, security requirements, and authentication method.

The Product is Everyone’s Deliverable

To move to next-level agile, at scale, an organization will need to blur its understanding of “business planning”, “requirements documentation”, and “UX Design”.  While there may be a need for full, distinct teams of experts at each of these disciplines, these approaches to defining what the software will be should converge on a single goal – building great software.  A popular article on Lean for UX, Lean UX: Getting Out Of The Deliverables Business leads with this statement:

Wireframes, site maps, flow diagrams, content inventories, taxonomies, mockups […] crystallized the value that the UX discipline brought to an organization. Over time, though, this deliverables-heavy process has put UX designers in the deliverables business — measured and compensated for the depth and breadth of their deliverables instead of the quality and success of the experiences they design. Designers have become documentation subject matter experts, known for the quality of the documents they create instead of the end-state experiences being designed and developed.

Having started my career as a Business Analyst, this is painfully resonant.  It is unfortunately easy for management move from training “the tools of the trade” – spreadsheets, slide decks, requirements documentation, technical specifications – to judging the tools independent of the software to be delivered.

Here are a few rules to follow to get UX, UI, and BA’s out of the deliverable business and into the well-formed team:

  1. Never say “final sign-off” regarding artifacts – whether working for internal stakeholders or external clients, if software is the deliverable, it is the only item requiring sign-off.  Every other artifact is is a tool for getting working software in the hands of users.  Make sure you are “responding to change” at the request of real users of working software – no amount of planning or documentation will survive contact with the user.
  2. UX/UI Refinement should mirror Backlog Decomposition – Prioritizing working software does not mean there is no product roadmap, it does mean that time and resources should only be invested in the software most likely to be built in the near future.  This starts as a process diagram of all possible Epics that could be built, and how the user gets to each of these features.  The upcoming 2 to 3 features should have relatively actionable wireframes.  The team should feel certain about the UI design of the current and next sprint.
  3. Create paradigms, not screens – the most important expectation to break is the annotated UI composition per screen.  Some screens absolutely benefit, many do not.  A well-formed team should have enough shared understanding of technical constraints, design paradigm, and business context that a conversation is sufficient to drive the whiteboard-to-working software process.  Wherever possible, establish a paradigm for a product is intuitive to build.  If it isn’t intuitive to the developer without extensive documentation, how likely is is it the user will find it intuitive?
  4. Document releases proactively, but in accordance with your level of certainty – If there is a product that will require knowledge hand-off, a support guide, or other formal documentation, maintain the tension between what makes sense to proactively document (so you don’t spend a full week post-release) while wary of what will change (likely anything more than a sprint in the future).

Following these rules, the software development process in an at-scale, compound-complex organization can focus on the user enjoying a working product.  Aligning vision and expectations along the agile priorities will remove fear of failure or criticism, increase team velocity, and result in the best possible products.  Then, your team, business, and enterprise can pursue kaizen – and the real magic can happen.

What Westside Barbell has taught me about Scaling Agile

Leave a comment

Agile Portfolio Management:

There is a new way of doing things in delivering a complex product portfolio.  It focuses on delivering value both incrementally and iteratively.  It utilizes empirical process control and hypothesis-driven planning.  It utilizes test-driven development in both convergent and emergent delivery, even when budget and scope are fixed.  It utilizes a Lean kaizen approach to maximize velocity.

This philosophy is by nature, object-oriented and modular.  No one framework is right for every product, so it is highly customizable.  It may sound new to you, but it has been around for quite awhile.  But wait – I’m not talking about Agile, Scrum, or Lean software principles – I’m talking about Westside Barbell’s approach to powerlifting.

Waterfall Weightlifting:

Powerlifting is a sport in which the lifter competes for the highest single-repetition maximum in the Squat, Deadlift, and Bench Press for their weight class.  The traditional approach to training powerlifters relied on linear periodization – a method still very valuable for beginning athletes because each phase builds on the last while progressing toward competition-specific strength.

At a basic level, here is a 12-week competition plan:

3 Week Hypertrophy Phase (muscle size, stamina): Sets of 12 to 15
3 Week Strength Phase (movement form, ability to move weight): Sets of 5 to 7
3 Week Power Phase (Explosive speed, maximum weight at progressively higher volume): Sets of 1 to 3
3 Week Peak & Rest (Highest weight, lowest volume): Sets of 1 to 3, tapering off to a few rest days
Competition: Three chances to get three lifts correct, competing against others who are doing the same

As agilists, this correlates perfectly with the “waterfall” approach we try to leave behind:

Hypertrophy phase: Business planning, creative design, and thorough documentation
Strength phase: Database layer, middle-tier
Power phase: Client-side logic, front end development
Peaking phase: Testing, beta release, focus group and stakeholder reviews
Rest days: Code freeze and marketing
Competition: Release to the market, in which you may not recover from failure

Then the lifter starts over.  If there was a big loss (e.g. an injury) pre-competition, the weight lifter might not compete at all – just like software project that gets cancelled after key engineers leave or technical debt gets too high to meet the release date.  More problematically, if there is a big loss or injury at the competition, the lifter may never compete again- just like the software team with a botched release that gets “reassigned” or laid off.

Repeating the Cycle:

The weightlifter who perseveres, win or lose, still has big “waterfall” problems.  The lifter rests a little and repeats the linear progression cycle, an exercise in bodily context-switching.  When the next hypertrophy phase starts post competition, most of what was developed in the previous cycle is gone!  The same is true of each phase.  When the lifter resumes focus on 3-rep max, some hypertrophy and stamina is lost.  As the lifter peaks for competition, the 1-rep max may increase but the 5-7 rep range decreases.  Studies show that after a few weeks in the subsequent hypertrophy phase, up to 15% of single-repetition strength is lost.  The disconnect between foundational planning (by increasing stamina and size) sacrifices a considerable amount of value captured (ability to perform the same single-rep max).

What does this specificity-switching cost the lifter?  As a beginner, not very much – any work will improve size, conditioning, and maximal strength, and fantastic progress can occur.  The discipline of repeating the movement pattern likewise increases maximal strength even with little planning.  However, once the lifter goes from a beginning athlete – a time when nearly anything will improve the lifts – to an intermediate athlete – subsequent peaking phases will see little or no increase.

The process requires disruption if total stagnation is to be avoided.

If this sounds like delivering software in waterfall, it is!  As you read this quote from a strength coach describing the “waterfall” lifting approach, think about the Waterfall PMO:

Having now gotten away from this type of training and looking back as an outsider, I can see where the program is lacking and why I had so many problems. I used to feel it was the only way to train (mostly because it was all I ever knew). It was also the only type of program for which I could find a lot of research. Some of the limitations to this linear style of periodization include:

  • It’s a percentage-based program
  • It starts with a high volume
  • It only has one peak
  • Your abilities aren’t maintained
  • The program has no direction to the future

– Dave Tate via T-Nation.com

Here are the parallel problems we see with waterfall:

  • “It’s a percentage-based program” – accounting-based statistical process controls are applied to an emergent system
  • “It starts with a high volume” – a significant portion of the budget is spent planning, designing, and fighting about features that no user wants (and if the project is cancelled, 100% of this sunk cost never drives user- or owner- value capture)
  • “It only has one peak” – A major release attempts to market itself to all segments simultaneously and a flop may kill the product line completely
  • “Your abilities aren’t maintained” – once the waterfall project plan is set in motion, market evaluation, user feedback, and stakeholder review is non-existent
  • “The program has no direction to the future” – a waterfall project plan is delivered based on the knowledge available at the beginning of the project when the least is known and has no intrinsic method of looking to the future relationship between the user market that might exist and the software that could be produced.

Westside Barbell’s “Conjugate Method”

The Conjugate Method attempts to balance all phases across preparation for competition. At the “enterprise level” three movement patterns are continuously tested as the measure of the process. At the “business level” a new variation of a similar movement may become the focus for 3 to 5 weeks (e.g. training rack pulls instead of full deadlifts when “lock out”, the upper portion of the movement, is the weak link). At the “team level” (the lifter + coach), the two-week sprint has a consistent set of ceremonies and artifacts (workout plan, workout log, the workout, etc).

Here is an example:

Week 1
Monday – Max effort lower body day (squat + low back + hamstrings), focus on strength and power
Wednesday – Max effort upper body (bench press), focuses on strength and power
Friday – Dynamic effort lower body (squat, deadlift), focuses on speed and hypertrophy
Sunday – Dynamic effort upper body (bench press), focuses on speed and hypertrophy
Week 2
Monday – Max effort lower body day (deadlift + low back + hamstrings), focus on strength and power
Wednesday – Max effort upper body (bench press), focuses on strength and power
Friday – Dynamic effort lower body (squat, deadlift), focuses on speed and hypertrophy
Sunday – Dynamic effort upper body (bench press), focuses on speed and hypertrophy

This correlates nicely with “core” Scrum concepts:

  1. Maximal strength is tested every week – working software every sprint
  2. The metric (1-rep max / story points delivered), is improved (strength / velocity over time), through hypothesis and experiments (empirical process control)
  3. The entire body is trained for size, stamina, strength, and power per every week – vertical slicing and user stories
  4. The lifter gets to experiment with new exercises without fear of wrecking a 15-week cycle – sprint retrospective, sprint planning
  5. The coach focuses exercise planning on addressing weak points – a ScrumMaster, removing impediments
  6. The Power Lifting competition is not a unique event with a long lead time – working software every sprint, TDD, XP, continuous integration and release

Now the lifter, like our Scrum team, gets to plan, experiment, and deliver often.  The overall roadmap (Lean + Scrum) might have a basic end-game or vision (increasing 1-rep competition max performed on 3 lifts the same day is equivalent to convergent product delivery), but planning only looks forward up to 5 weeks, commitment at 1 to 2 weeks.  Likewise, the lifter and coach is always looking at the most recent data, the newest lessons learned, and quickly reacts to whether a behavior, practice, or process should be continued or not – just like the Product Owner, ScrumMaster, and Team are always planning and executing based on the most recent market and team data.

Applications to the SDLC:

Now we can extend the metaphor and draw conclusions.  The powerlifter’s body equates to a complex large-scale digital portfolio.  The lifter needs to increase value three programs that focus on convergent product delivery while also developing several programs that utilize emergent product delivery.  In waterfall these two program methods are separated by functional division and project lifecycle, in conjugate (Scrum) these two are handled in tandem.

For the powerlifter, the three convergent products are squat, deadlift, and bench press.  Quality must stay constant or the increase in value does not qualify.  The same is true in software products – adding a high-value feature while allowing a 50% increase in crash on launch is absolutely unacceptable.  Your users will disqualify you!  Whether your have a three-application enterprise CRM program or a three-iOS app consumer program (see LinkedIn or Facebook as examples), adding an exciting feature to an app that causes mass user drop out is a risk no business can tolerate in today’s market.  The competition is too fierce, barrier to entry too low; someone will blow you away.

At the same time, the powerlifter needs to maintain several emergent delivery programs, some for function (increasing grip strength), some for fun (increasing bicep size).  Ongoing workout plans, building size, stamina, and maintaining joint health, addressing weak points by focusing on a new accessory exercise for 5 weeks – all of these priorities must be balanced and evolved.  Keeping a workout log is the only way to be sure that exercise volume, intensity, and density are increasing.  The relationship between the convergent product value and the emergent product investment is the only metric rationally applicable.  The same is true in software delivery.  Emergent-delivery programs like R&D, marketing, UX, product planning are all critical to the health and success of the portfolio as a whole – but the end goal must be clear.

  • Over-planning and under-delivering is not acceptable.
  • Over-researching and under-user-pleasing is not acceptable.
  • Over-designing and under-testing is not acceptable.
  • Over-marketing and and under-releasing is not acceptable.

Conclusion:

The Conjugate Method as an analogy for Agile, Scrum, XP, and Lean at scale works for me because I love lifting.  I realize it may not be right for you, especially if neither agile or weightlifting are familiar territory.  So, like everything, find how this applies to your life so that you can find inspiration in ordinary – then start a conversation about it.  I’m happy to discuss anytime:  224.223.5248

Fixed Budget, Fixed Scope? Be Agile Anyway.

2 Comments

Innovation is Sexy:

Scrum is typically taught with its most innovation-focused form as the example, born from fast-paced software companies who disrupt markets and kill categories.  This is the sexy version of Scrum: a highly elastic process for delivering complex products with emergent design.  In the real world this is not the only context in which Agile, Scrum, Lean, and XP principles can and are utilized to increase quality and velocity.

If you are a newly-trained Scrum professional, bright-eyed and full of hope, do not get discouraged by convergent, fixed-budget, fixed-scope, fixed-timeline projects – be agile anyway!  This is how to do it.

The Agile Manifesto:

It is important to remember that the Agile Manifesto is a set of priorities, not a set of laws. To any extent we can, we strive to prioritize in the direction of team collaboration, continuous improvement, and emergent value creation.  However, there are some occasions when you will have to put additional energy in the secondary priority.  Strategy is the art of trade-offs, so make sure your organization is aligned and the strategic vision is deliberate:

  1. Individuals and interactions over processes and tools – Never lose sight of prioritizing the people who huddle around your solution, never stop collaborating.  Encourage face time and green time.  However, there are highly regulated industries with static expectations, accounting control benchmarks, FDA guidelines, or stable dividends paid to investors for decades.  A well-documented, repeatable process for how software, hardware, or other product will be delivered over the course of a long-term project will assist tremendously with stakeholder confidence.  Make priorities clear on all sides of the contract, set the expectation that communication and availability are mission-critical, but understand that there will be little risk tolerance for out-of-control processes.  Maintain your agility by keeping your document alive and lean, maintain elasticity, but make sure the tools used and the processes adopted, and the pace of process change, gives your fixed-scope, fixed-budget project a stable context for predicting delivery and ROI.
  2. Working software over comprehensive documentation – Delivering builds early and often is the best way to be truly certain of product status.  In emergent product design with incremental feature addition this feels natural.  There is an MVP planned so an opportunity to pivot is assumed, the feedback loop on the progress of high-quality incremental delivery is the best way for stakeholders and users to see and feel the value that is emerging.  When working with waterfall-minded stakeholders – especially if they are an external client – fixed scope, fixed budget, and fixed release dates cannot always be avoided.  However, convergent delivery does not preclude the XP and Scrum best practices of well-formed agile teams and an openness to documentation-heavy products will drive velocity and success waterfall organizations have never seen.  Instead of negative reactions to the expectation of comprehensive documentation, approach documentation as a secondary product and maintain the same expectations of prioritization, collaboration, and responsiveness.  Moreover, a convergent, finite project likely came to you with extensive documentation.  This documentation will require some additional work, but it should not be ignored.  Even though this is a source of waste that is removed during agile transformation and lean consulting in “sexy” emergent product delivery, handling waterfall requirements as documented stakeholder demands can be incredibly helpful in convergent product delivery.  The Product Owner still must aggregate, consolidate, and complete backlog decomposition with the team.  The XP user story and a prioritized backlog should still set the delivery cadence.  Be open to documentation and transparent to stakeholders about its actual ROI after it is delivered.
  3. Customer collaboration over contract negotiation – Good fences make good neighbors.  Some large companies simply cannot risk an open-ended and loosely-defined relationship, especially with vendors or contractors.  If you’re competitive strategy relies on these types of contracts, inspect and adapt.  Find how negotiation can be expedited, build in the process of collaborative relationship change, and build well-formed teams that are as adept at ramp-up as they are at innovation.  The capacity of a Scrum team to quickly assimilate a knew business and architectural context will drive success in products and relationships of all types.  Answering the internal needs of various business functions or developing solutions in new industries requires a team aptitude for understanding new contexts effectively and efficiently.
  4. Responding to change over following a plan – Change is inevitable in product delivery – the demands of the market, the technological tools available, and the state of the product being developed are a state of continuous evolution.  New requirements previously unnoticed will surface in the course of a project.  Even in a mostly-waterfall project, a great Product Owner will apply XP and Lean principals to minimize waste and maximize up-front value.  Great Scrum teams will perpetually improve, increasing velocity.  We often talk about “waterfall projects” versus “scrum projects” when we really mean emergent versus convergent delivery – fixed budget, scope, and deadlines do not preclude scrum, lean, and XP practices, they constrain them to a known outcome.  The difference between delivery by a helpless group of Project Managers and Business Analysts disengaged from team performance versus delivery by a powerful Product Owner and kaizen-crazed ScrumMaster and team is not dependent on emergent product delivery!  Collaborating around the highest value backlog items up front, swarming impediments, and tracking the variance of forecasted-to-actual product-level burn down will allow fixed dates to be met appropriately.  Responsiveness to change needs to be supported by a strong relationship of trust, which must earned.  If you are in a custom software shop, responding to RFP’s and entering into fixed projects is often the inevitable first step to earning the trust that will lead to a more agile relationship, so make efforts to meet the comfort level of the customer’s stakeholders while including a healthy process for addressing requirements changes.

Conclusion:

The values, practices, and behaviors of agile, scrum, lean, and XP have wider applicability than open-ended emergent product design.  Staying open to the unique lessons that can be learned in seemingly less-than-ideal projects will be a terrific opportunity for the kaizen-driven team to grow.  If a rigid process and convergent projects have caused the shine on your Scrum mindset to dampen, step up or step out: don’t let the context defeat you, stay true to your agile values.  On the other hand, if you find yourself in a long-term no-win situation in which you cannot drive change for your team(s) and users, maybe a sexier career path is out there for you to consider.