7 Simple Steps to Agile Transformation

I am never sure how to answer someone who says “What is agile?” After all, my mind is racing so fast that my ultimate, simple explanation – “A way to innovate and deliver products more effectively” leaves me wishing I could kidnap people for a 3-day course on lean-agile and continuous delivery.

What I can simplify (for someone who has a basic understanding of agile) are the steps in a true transformation, so that they can let me know where they are in the process.  Note that I have ordered these quite logically, while the real world is full of resistance, grey area, and co-evolution.

  1. Establish a cadence of synchronization (typically, this is scrum). Hypothesize the results of every change ahead of making it, test it, and validate or invalidate the hypothesis.  Inspect and adapt.
  2. Change from a human resource allocation mindset to a well-formed team mindset.
  3. Change from a finite project mindset to a living product mindset.
  4. Sell who you are, not what you plan to have on a shelf in X months.
  5. Change from a P&L and ROI mindset to an Economic Value Flow across the organization mindset (including upgrades in equipment, training for knowledge workers, benefits that raise barriers to exit).
  6. Change from centralized (top-down) market research, innovation planning, and risk assessment to distributed control over prudent risks.  This requires a framework for self-validation of discoveries, exploitation of opportunities, and communication of results.
  7. Change from performance tracking and formal leadership to systems optimization and organic leadership.

Hit Contact if you’d like to discuss your scenario or any of these points – I’m always available.

Do Project Tasks go in a Scrum Product Backlog?

I get this question frequently when training agile and scrum teams:

Do Project Tasks Belong in a Scrum Product Backlog?

YES.

Since answers to this question I have seen in chatrooms are typically insufficiently argued as part of a crazed political debate full of comments taken out of context, this very pragmatic question deserves a bigger picture answer – because the need to ask the question is a symptom of a stagnating transformation.

A successful shift from stage-gate or waterfall development processes to agile, Scrum, or Kanban requires a fundamental change organization-wide: from maximizing ROI and shareholder value to maximizing Economic Value Creation and sustainable competitive advantage. If this shift does not occur, the improvements gained from agile practices will inevitably stagnate.

Jez Humble refers to this state as Water-Scrum-Fall, that unfortunate state where most agile and DevOps initiatives plateau.

Most often when I talk to development teams, Product Owners, and ScrumMasters, this is often blamed on a lack of executive buy-in.

I completely disagree.  

I have also blamed a manager or two for the imperfections in the agility of a company, so I can relate to this view. To show you why you might not even want executive sponsorship, let’s revisit the view of a corporation as a minimum viable superorganism.

Complex Adaptive Systems Leadership

A corporation is not a machine with various parts to replace or maintain in isolation, it is a superorganism. It is a biological phenomenon that is not sufficiently explained by social contract theory or through monetary theories of motivation. Judgments about this reality are very easily clouded. Unfortunately, once measurement and monetary incentives change the natural behavior of the superorganism, it is difficult to change back – making it easy to fallaciously claim this as proof of their effectiveness.

Quantum physicists have suggested that undisturbed systems in the universe naturally stay in multiple states simultaneously, unless someone intervenes with a measurement device. Then all states collapse, except the one being measured. Perhaps what you measure is what you get. More likely, what you measure is all you get. What you don’t (or can’t) measure is lost.  – H. T. Johnson, “Lean Dilemma”

So when you hear “We need more buy-in from management” this is absolutely incorrect.  It is even counter-productive!  Adaptations by a complex system, that disruptive creativity and innovation agile champions desire, can only occur through organic, emergent leadership – a tribal, heretical rebellion. Adaption to a new stimulus may have a focal point, a “leader” who organically builds up energy in a new direction – but this leadership is an emergent property the complex system. In contrast, formal leadership (“management”) is a crystallization of a complex system, an attempt to reinforce a desired “normal state” – a force that exists counter to emergent leadership and adaptation. By default, formal leaders at all levels of an organism are incented (through power, money, and Agency Dilemma) to maintain homeostasis – i.e. the status quo. Even if a formal leader becomes the emergent leader of adaptation, this will be odds with her formal leadership. Unless she is willing to risk the loss of formal leadership, she will dissolve her capacity for emergent leadership and resume promotion of homeostasis – no matter how much it dampens creativity, innovation, and sustainable competitive advantage.

Evolution of a superorganism through disruption – whether a lean or digital or agile “transformation” – cannot occur if any one piece of the system is optimized in isolation from the whole because any superorganism, as a complex adaptive system, will exert tremendous energy to maintain homeostasis. The larger the superorganism, the more likely that optimization of one function or team will result in a net loss of desired adaptation (whether the desirable “adaptation” is called innovation, process improvement, or “growth”).

So, when a formal leader blesses a piloting of lean and agile practices by a completely isolated team, this is the superorganism equivalent of a mother’s amniotic sac – the team can establish itself as a unique complex adaptive system while in isolation, fed by the resources of the maternal superorganism but shielded from the homeostatic processes of the parent system. The moment this new team is re-integrated into the larger system, continued adaptation is unlikely. The company attempts to spread the innovation and creativity culture they achieved but instead can only formalize a shift in a subset of practices.  These practice, outside the context of psychological safety, a well-formed collaborative team, flop. No single activity of the pilot team will have the same value implemented outside the context of the pilot team’s “bubble” that safeguarded it against the homeostatic forces of the superorganism!

But wait – what about that “net loss” in innovation, creativity, and efficiency I claimed?

In practice, a company that adopts an agile process (let’s say Scrum) as a change in behaviors isolated to the teams developing software causes the rest of the system to expend energy maintaining homeostasis, and even more energy wasted by agents accommodating these homeostatic forces so that the development teams can preserve their no-longer organic place in the system.

I think you know exactly what that looks like:

  1. Updating documentation processes without seeing them as “artifacts” that emerge from an adaptive process rather than social contracts that require formal sign-off.
  2. Replacing one tool with another, causing a new set of employee workarounds to occur.
  3. Increasing frequency of software releases without changing the size of organization commitments.
  4. New meeting names that don’t change communication patterns or the homeostatic, status quo, “normal” flow of information.
  5. Continuous backlog decomposition as a manual transfer of a large-batch investment into small-batch development items.
  6. Oops! Another manual transfer at the end –  of small batch engineering back into large-batch approval processes.
  7. Changing job titles without addressing diffusion of responsibility and the lack of psychological safety inherent in the culture of the system.
  8. More overhead and forced “transparency” than if nothing had changed, through extra meetings, reports, metrics, and analysis, due to the natural distrust between formal leadership and emergent leadership, and the lack of trust in information flow between the homeostatic processes and the aberrant nomenclature of the development teams.

In the middle of all this, a large organization grabs their Project Managers and their Business Analysts, or anyone cheap who is around and doesn’t have the “status” a Product Manager, Director, or VP, and switches around their responsibilities to call them “Product Owners” and “Scrum Masters”.

What a debacle.

The newly-minted Product Owner receives Project Plans full of important tasks and milestones and big nasty Use Case document and an even bigger, unapproachable set of Technical Specifications – and is told to manage what the team delivers with User Stories.

Now in the midst of all this, should the Product Owner include Project Tasks in the Product Backlog?  Or to get down to brass tacks, could a task ever be a Product Backlog Items?

Absolutely!

But not all of them.

Some “Technical” Tasks (specifically not User Stories) are still Product Backlog Items

Technical tasks that create demonstrable economic value that the organization can capture, a known cost of delay, but are completely invisible to the user STILL NEED TO BE PRIORITIZED relative to other potential Product Backlog Items.

This, of course, is why the question of if these belong in the backlog is sign that a systemic shift in thinking has not occurred. If you are optimizing for project ROI, then these tasks just don’t have the marketable, monetizable potential of each Use Case. If you have a systems view of optimizing the flow of economic value creation, these tasks are judged relative to any other potential investment. Economic investment is continuous, the economic value created can be judged continuously, delivery and value capture is continuous, and you can prioritize based Weighted Shortest Job First or another collaborative decision making process about the of Cost of Delay.

“Artifact” Tasks are an Agile Anti-Pattern

There is, however, another kind of project task in Water-Scrum-Fall that SHOULD NOT be in any development team’s backlog: artifact tasks. These are things like “Complete wireframe for new home page” and “Document Social Integration for PokemonGo”. No matter how you small-batch these tasks, these are not Product Backlog Items. These are not even artifacts. Artifacts are the tangible leftovers of the creativity and innovation of a strong agile software team. A documentation, design, or planning task is antithetical to economic value flow. It is a trap. A box you put your money in and bury. It takes all the value-add, throws it in a pile, and lets it sit there, unused, as it become gradually less valuable.

This mini-waterfall process – this outrageous, lean-agile anti-pattern – surfaces in three ways, all of which I whole-heartedly reject and will actively undermine the capacity of others to pursue it in hopes that my heretical tribal rebelliousness will gain emergent leadership support:

  1. Business Kanban and Program Increment Planning tasks that lock up all creativity and innovation prior to the development team passively receiving instructions (as you see in shoddy implementations of the Scaled Agile Framework)? FAIL! TRY AGAIN!
  2. Tasks for non-developer “members” of the development teams completed as Sprint Backlog Items separate from the User Stories, thereby formally dividing cross-functional collaboration and preserving us-them Guilds (whether in dual-track Scrum or within even the shortest sprint)? FAIL! TRY AGAIN!
  3. Sub-tasks that formally divide up User Stories into function-specific tasks to complete? FAIL! TRY AGAIN!

These are all agile anti-patterns that prioritize tools, social contracts, and “process” over collaboration, communication, relationships, and creativity. You will never disrupt your organization, and your organization will never disrupt your industry, sorry.

“Milestone” Tasks are a Continuous Delivery Anti-Pattern

Since we started this asking if the BA / PM as PO ought to put Project Plan tasks into the Scrum Product Backlog, I’d hate to leave out “milestones”. Now you may say, “Andrew, that’s ridiculous, no one would treat a dependency as Product Backlog Item!” Indeed, ridiculous. But that’s the ultimate sign of your Continuous Delivery anti-pattern. Truly optimizing the flow of economic value creation across the entire complex adaptive system would completely remove “milestones” and “dependencies”. If you can’t get rid of Project Plans completely, and continuously deliver and validate Finished Story Benefits for ALL work that the organization takes from identified pain to economic value capture, whatever you started pursuing in your agile, or digital, or lean, or devops transformation, you’ve plateaued as a company.

And this is the really the paradox that made the lengthy description of complex adaptive systems leadership necessary. This hurdle is NOT something that “Needs executive buy-in.” This is something that is accomplished through outright insurgency, tribal heresy, and fait accompli rebellion.

That’s because Continuous Delivery takes more than agile ceremonies and user stories. It takes developers who are proud of knowing business context. It takes refactoring that no one approved. It takes a team move to Git from Subversion without telling anyone. It takes a handful of people setting up a Continuous Integration server no matter how often the nay-sayers tell them it’s useless. Continuous Delivery is a change in engineering practices and development culture that tend to happen without formal leaders needing to approve anything.

It just takes the right people having enough pride in being BETTER that they draw a line in the sand and defiantly announce “THIS IS OUR CRAFT!”

A Heartfelt Epilogue: Real Creativity, Innovation, and Disruption is MESSY

Now listen, human-to-human, if all you know about “agile” comes from that one book you read, YouTube, or a two-day certification, I won’t be surprised you’re thinking, “Wait, Andrew, that’s nothing like agile! How do I report you! How do I get you stripped of all your certifications?” That’s great. That reaction means I hit a nerve. Fantastic! Contact me and let’s talk about taking agility to the next level.

Truth is, I don’t look to my four certifications, five training course, three conference, my blog, OR EVEN my five years of attending, speaking at, and hosting MeetUp’s on agile as the proof of my legitimacy on these topics. I measure my expertise in the number of experiments, including the major failures I have been through with my development teams. The reason is simple: complex adaptive system leadership is an emergent property that require deep entanglement and shared experiences in the trenches. And, as it turns out, I’ve been in the thick of every kind of good or bad lean or agile possibility, trained people in that context, debated ferociously about it in multiple companies, and I have compromised my values or experimented with teams to directly challenge every single principle your little YouTube summary glossed over.

If at this point you think some teacher let me down and it’s a real shame, I’ll be happy to give you a recommended reading list and YouTube list and introduce you personally to other thought leaders that dive, like I just did, into the MUD of how you actually achieve: creative innovation, strategic and operational agility, and lean, continuous delivery of disruptive economic value.

Either way, reach out so real dialogue can get started.

Your ROI is Total BS

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

11 Steps to Revolutionize Your Career

Ever wished you knew the key to getting to the next level, enjoying your job more, or just earning the raise you deserve?  That’s what this post is all about!

11 Steps to Revolutionize Your Career, Unlock Creativity, and Prioritize Your Professional Growth & Learning Roadmap

GREAT NEWS – the same techniques used to rejuvenate enterprises and drive strategic agility can help you to improve your position in your organization, your satisfaction at work, and the career path ahead of you.  I’ll show you step-by-step how to build a prioritized roadmap for professional growth and learning, as well as the science behind the art.  This is most exciting as a group experience – with a circle of friends who share your interests.  Don’t underestimate the power of a guild! Post-It Notes and group goals can be far more effective than going it alone.  Find your love, lead a tribe!  

The overarching idea is that you need to increase how much value you add to the process, the product, and the customer (if different, via the users).

I know “maximizing total stream economic value-add” sounds ivory-tower and too academic to matter to your daily life.  It’s true, no one doing real work talks like that. In practice, it means “time well-spent fixing a pain your customer feels.”  The more you directly relieve pain, the better!  That’s why the customer pays your company and your company pays you.  More pain-killing, better company.  You want to be as irreplaceable in that relationship as possible.

Documentation does not help the pain of the customer.  Budget planning or release plans don’t make a crappy user interface more intuitive.  Even if you literally Your deliverables are not your job.  Your ability to alleviate more pain for the customer than it costs the company to pay you – that is your “job”.  In entrepreneurial lingo – the strengthening the sustainability of your salary-for-value exchange is your only job.  The title, the process and your deliverables are all derivative.  Once you see it that way, improvements to your output, your process, and your skill set are all part of one “roadmap” that keeps your salary potential growing rather than stagnating. 

Let’s take it step-by-step.  Reach out if you have a question!

1 – Narrow your focus

To start, identify the most important information or resource that you handle.  Every role centers around one “wildly important thing” that needs to be accomplished by someone who can combine information and resources with professional knowledge and tools in order to create something new.  As an accountant, role centers around knowledge of the flow of cash and others constructs that can become cash.  The expert knowledge of the law, best practices, and tailoring the visibility of a company’s slice-of-time or in-flow cash is not only a full-time job, it can take an entire team.  If you are a software developer, you combine a problem assumption with your knowledge of code to create software that solves the problem.  As a Product Owner, you prioritize the flow of information to ensure problem-solution feedback loop is as tight as possible. 

2 – Get real about your value add

The way in which you add value in your one “wildly important thing” is a workflow.  It has an input, time in progress, and an output.  The five basic phases of any process as defined by Steven Borg are:

  1. Queue – Understand what to do 
  2. Setup – Get the necessary “resources” ready
  3. Run – Complete the goal
  4. Wait – Look for feedback on success/failure
  5. Move – Find the next goal to accomplish 

The “run” phase is the activity most companies call “performance” and likely that activity is the only thing they would want to pay for you to improve.  That said, we all know that the “run” portion of our week is only 10% to 20% of our time in the office.  Embrace that hard truth here – your role is a creative process and you have to fight for your creativity.  Make the entire process visible, not just the old-school boss-whipping performance dogma that resulted in Ford laying off 20,000 people in one day.

Be honest with yourself, be heretical, be brave.  As you map your workflow, you want to very objectively understand how much of your time is fluff due to the inherent inefficiency of information flow in society and your organization.

2 – Map “The Steps”

When I first learned about value stream mapping, I didn’t get it.  In fact the first several times I learned about it I wasn’t sure if I was missing something or if it was really as simple as it seemed on the surface.  Great news!  It really is incredibly simple and superficial.  It just takes a level of paying attention to mundane details we take for granted that most people just don’t take the time to do it.  Maybe quantifying how much of their job isn’t the “run phase” causes fear for their job security.  Unfortunately, companies full of people who love their work and don’t tolerate bullshit are taking down companies full of unthinking zombies every day.  Your job is not “safe” anymore.  Make yourself irreplaceable doing what you love.

Here’s what to do as you map the steps – somewhere between your job description and the “wildly important thing” you get challenged to do, you have established a routine of behaviors.  List out the steps. 

That’s it.

That’s “mapping a value stream”.  I told you it was simple.  The one difference between a to-do list and a value stream map is tacking on what you do to add value (relieving pain for a customer, right?).  For fun, write at the top of your whiteboard “The {your role} Way” – a proud tip of the hat to “The Toyota Way” that has inspired so much of Lean thinking.

3 – Map “The People”

Once you have listed out the steps you follow to create value, list out the people involved with each step.  It is possible that a department or a team is a bit of a “black box” in your process, which you should highlight!  If you know that you need information X from Susan, that is much more efficient than depending on X from “accounts payable”. 

Don’t skip this step!

4 – Map “The Time”

Go back through the steps and identify (even on average) the real minutes on the clock you spend on each step, then the calendar time waiting between each step.  If you’ve never taken the time to do this, you may find this analysis fairly emotional.  It isn’t comfortable to put on paper that you spend 5% of your time doing something meaningful and 95% of your time waiting and struggling to get “the system” to get out of your way so you can do your 5% and then go home or watch YouTube or whatever.  Do it anyway.  This isn’t about them, this is about you and how you can grow so that more of your time is more meaningful to you in your pursuit of mastery, autonomy, and purpose.  Our goal here is map out the business case for ways in which you can spend less time chasing that 95% or more time engaged in your 5%.

Caution – It’s tempting to run off and try to solve things or make a wish list or start blaming people for your problems, because time is a precious resource and “solutioning” ways reclaim your time is extremely rewarding.  DON’T.  That’s not the point of this exercise and it will ruin your reputation and you’ll miss the goal of this effort completely. 

This workshop is about how you can grow, learn, and enjoy your work more no matter what anyone else does.

5 – Take a deep breath

No really.  Take a break and relax.  You need to approach this calmly, logically, and thoroughly.

6 – Identify sources of waste

You already started this process while you mapped your value stream, but you need to go through step by step and really evaluate several things.  For one, look inward.  Which tasks do hate?  Which ones do you love?  When you feel disengaged, why?  Removing wait times and reducing task times would be nice, but the greatest source of inefficiency in your work is usually your own lack of focus or ability to “ramp up” your motivation.  Mastery requires pride in the mundane.  10,000 hours of scales as a violinist or guitarist; 10,000 hours of free-throws as a basketball player.  If your job includes something it is absolutely essential to your career and you hate it, that’s a symptom that you can grow in that area.

Now, let’s go through this very purposefully and objectively.  For every step, check if you have one or more of these sources of waste, then list it out.  Waste is anything that “adds no value” in your workflow or lessens the value that you add to the process.  Occasionally, you might even find you are, despite the best of intentions, reducing the value of information or resources.  Between us, that’s okay – there is immense wasted energy all around you.  You will be much more powerful by understanding yours.

Here are the types of evil, horrible waste you already don’t love:

  1. Waiting for input (information or resources)
  2. Over-production (doing something or making something no one used)
  3. Rejects or Defects (doing the wrong thing, or doing the thing wrong)
  4. Motion (unnecessary movement, like manually turning a Word doc into an Excel spreadsheet every week)
  5. Over-Processing (anything you do in which you “reinvent the wheel” each time)
  6. Inventory (any pile of information or resources, before or after you add value, that sits untouched for any period of time)
  7. Transport (time spent moving something of value – if it isn’t instant, why not?)

The other take-away you want to gain – for purposes of learning, growth, and personal development of mastery – is a list of any instance of miscommunication or misunderstanding, especially if there is any time when the format in which you receive information is difficult to understand without time spent interpreting it or asking for feedback.  Likewise, how much of your time is spent clarifying what what you provide to someone else?  That’s an opportunity for growth.

ONE MORE major thing to look for:

Waste of Talent or Other Scarce Resources (like your precious time) – Be honest with yourself and others (circle of trust) with this one.  When do you feel like your intelligence is insulted?  When do feel like you’re overqualified?  When do you think people around you are disengaged or wasting their real potential?  We need to find what we can do about those moments.

7 – WooHoo!!  Solve All Your Problems!!

My mentor in the App Roadmap Workshop, a variation of this process focused on enterprise mobility, always loved to say “’Magic happens here’ is okay.”  Of course, for that audience, talking about mobile, that meant “technology too advanced (or difficult for your company to implement) to assume it can be achieved now”.  When it comes to personal growth and development, you need to have the same optimistic view of all the options before the cold reality of life hits you as you struggle to learn.  Don’t prematurely rule out any resolution to any problem at this stage, because you’ll want to come back to this every three months and by then, all kinds of things – your role, your abilities, the tools available – may have changed.  For most of us, we need to just say “’future-me’ will sort out the details”.  That’s what we all do when we make bad decisions, let’s apply that same courage while making some really good decisions.

Go through each step, and every issue or waste you found.  Then do your best to identify something you could personally do differently change the inefficiency.  If people fail to provide adequate information, could you provide them a template?  Is there anything you can automate?  When you look at the situations where the most misunderstandings occur, is there anything you can learn to bridge the gap between your specialty and that other person’s?  Could you succeed more by setting better expectations? 

Put together all these opportunities.  Hopefully there are several.  I personally have more ways I could try to grow than I have time to invest in myself, but I’ve been building out this backlog for awhile and learning has a funny habit of unlocking awesome new ideas about what to learn.  Knowing all the ways you could grow is an extremely healthy form of self-understanding. 

8 – This is about MASTERY, AUTONOMY, AND PURPOSE

Mastery requires pride in the mundane and a deliberate effort to understand the periphery of your specialization.  If you are a Product Owner in a large enterprise, this could be technical training, UX or UI creation, business case building, customer interviews, or a host of other leadership, sales, marketing, development, or other capabilities.  Don’t be afraid to try new things.  Don’t be scared when your plan to try new things turns into a slap in the face about how hard it is to learn those things.  Now is a great time to decide how tenacious and dedicated to your personal development you are.

9 – Prioritize, Prioritize, Prioritize

In Lean, we know that the amount invested in a system from one day to the next is relatively stable.  Because of this, prioritizing investment of time and effort should work to reduce the cost of delaying action.  In software, this means comparing opportunity cost of two features.  If you can only integrate Twitter sharing or Facebook sharing, which one is less urgent?  Invest in the most urgent need first.  There are a number of ways Calculate the Cost of Delay for the changes you want to make, but we will customize this for your personal learning and professional development roadmap.

This is a variation of Weighted Shortest Job First which you can find at www.scaledagileframework.com/wsjf

Line up all the solutions to your problems you came up with in a list.  If you can put this into a spreadsheet, that might be handy for the purposes of staying neat, but post it notes work fine as well (and are better in a group).  This is your formula:

(Potential to Increase your Value Added + Time Sensitivity + Career Opportunity)  / Time Investment

You’ll add each of those as columns in your table.  To give an example, let’s compare two learning goals that you believe will improve the value you add in your role:

  1. Complete the entire iOS course on iTunes U
  2. Watch a GOTO Conference presentation video on Continuous Integration

Both options are money-free free, but each will consume your most precious resource: time.  We want to relatively score both of these options using each variable in the formula above.

You begin by choosing the lowest score and the highest score.  In a group, this is done typically with a predefined fibonacci (this is a useful number set primarily because it makes equal WSJF scores unlikely. Since there are only two items we are considering, we can just score with 1 and 5.

Let’s say, as a Product Owner, that although iOS products could be in your future, the company right now is making a push toward Continuous Delivery as a major lean process initiative.  Clearly, the additional value you can expect to add after the iOS course scores a 1, while the value of knowing what people mean when they voice pains in their Continuous Delivery initiative is the 5.  Remember, this isn’t about what could be the most valuable thing ever, this is about prioritizing your continuous investment in yourself.

Time Sensitivity, do the same.  It’s another clear win for an hour YouTube video. 

Career Opportunity – Maybe knowing how to code in Objective-C give you better prospects in your career.  Give the Continuous Delivery video a 1 this time.

Time Investment – the testing ground of every great idea.  It will take you several days of ongoing effort to make it through that entire iTunes U course on iOS development, especially if you really take notes, do the exercises, and learn to actually code.  The YouTube video and a follow-up conversation with someone you trust, plus a blog post about what you learned?  Let’s 4hrs.  At the end of the day though, you don’t need an actual estimate of the time you’ll spend, you just need to know what’s bigger and smaller relative to your most important options.

Now we can score!  I’ll send you an example of my own current learning goals.  Just contact me.

  1. Complete the entire iOS course on iTunes U (1+1+5)/5 = 2.4 #FAIL
  2. Watch a GOTO Conference video on Continuous Integration (5+5+1)/1 = 7 #WINNING

10 – The highest score wins. 

If you have several items, you order them from highest score to lowest.  Go watch that video and write about what you learn!  Your time is a river, keep repeating this process so that it flows beautifully and the water of insight and innovation is always fresh!

11 – Final Step: Tell people about it.

Learning is more difficult in a vacuum, because the occasional plateaus and time in the trough of disillusionment make it easy to quit once you find out how hard a new skill is.  That’s why you want an accountability partner, mentor, or community of practice leader who you trust for bouncing ideas, sharing goals, and tracking your insights.

BONUS SUDDEN DEATH ROUND

Just kidding, no sudden deaths here.  The bonus take-away from Lean that I’ll give you is the challenge to move from old ideas of quality – “no one complained about a problem” – to the idea of TOTAL QUALITY.  What if everything in your product solved pain for the user?  What if everyone involved added value to solving the user’s pain?  Quality isn’t “less than 1% crash rate”.  Quality is “I gave the right thing to solve pains, at the right time, and it changed someones life quickly and easily because their was no filler, fluff, or distractions.”

ENJOY!

 

Featured image via Liane Metzler

What Westside Barbell has taught me about Scaling Agile

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.

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.

FREEDOM: How using Scrum un-impedes our full potential!

Scrum frees teams from the tyranny of the urgent:

A key goal of the Scrum transformation is breaking the parent-child relationship between “business” and “development”.  Technical planning, implementation, commitment, and delivery is in the hands of the team while the Product Owner provides a single priority-order backlog of consolidated items from stakeholders, users, and the developers, for the team to plan around.  Once a well-formed-team finds the right mix of XP and Lean practices (especially continuous integration and frequent releases) the pressure of “we have to do this now” is easy to manage.  If major items frequently pop up mid-week on a “release train” that deploys weekly:

  • The team leaves room in their commitment for these items
  • The Product Owner sets realistic expectations with stakeholders on which release will include the request

This is part of the power of Lean planning for making strategic product and release decisions – once the Minimum Viable Product is in the open market, data from the users can determine urgency of backlog items.  Frequently, this is a point where a pivot is desirable.  Through frequent releases, the users, stakeholders, and the team can relax and look at the big picture, free from the fear arbitrary deadlines and urgent scope “creep”.

Scrum frees teams from the fear of making mistakes:

While the extreme co-dependency that drives the tyranny of the urgent is overcome by putting an end to arbitrary deadlines and poor scope decisions, the fear of making mistakes is overcome through the key roles defined by Scrum.  Note, these are roles and this label is intentional – these are NOT by necessity positions or titles.  As I describe in Why Product Owners? a role is the confluence of empowerment, responsibility, and accountability for One Big Thing that rests on the shoulders of a single person.  Teams are free to voice ideas because the Scrum framework encourages collaborative implementation planning, cross-functional brainstorming, and constant discovery of best practices.  With XP Pair Programming, this becomes even easier as a single screen and keyboard gets two minds and four eyes that can converse on best practices, mitigate against knowledge silos, and build team relationships.  In the end, all of these adults acting brilliant and mature, huddled around a problem still have the Product Owner as the proxy to the users and stakeholders.  The team is free to determine one small solution at a time, just-in-time, and just-enough – then iterate or pivot.  When tough decisions need to be made, the Product Owner makes the call, relying on the expertise of the team, sets expectations, and maintains accountability.  Moreover, the user story – as the building block of incremental product delivery – isolates risk of mistakes to the smallest valuable user interaction and continuous integration ensures that when a new increment is not “potentially shippable” it can be easily taken out until additional iteration is completed.

Scrum frees organizations from business as usual:

When things go wrong in a large Waterfall project, multiple helpless Project Managers ask for updates but are unable to check boxes, development teams are powerless to drive the direction of the product, and stakeholders become progressively frustrated by the unfinished pit into which money is being thrown.  Then they cancel the project!  What is missing here?  JOY!  Menlo Innovation’s Richard Sheridan and author Joy, Inc. describes the importance of team joy in an interview with InfoQ:

There is in fact tangible business value to joy. But understand this: our focus is external to the organization. What we want more than anything else is that the work of our hearts, our hands, and our minds gets out into the world and delights people. That’s our definition of joy. We want somebody to stop us on the sidewalk and say, “That thing you built, I love it. Thank you. You made my life better.”

When I build a new Scrum team, guiding them with the help of my Scrum Master through the process of forming, storming, norming, this is the number one fear I must guide them through:  I say “Yes, the requirements will change.  Yes, what you build today will be modified tomorrow.  What matters is that you are a creator, people will actually use what emerges, and it will make a difference to them.”

The move from cancelled projects to meaningful user feedback has an incredible impact on an organization.  The drive to constantly improve, tighten feedback loops, and evolve through empirical process control will make disruption the norm and remove the fear of inevitable change and new ideas.

Scrum frees organizations from process rigidity:

There are three overarching goals driven by the roles, ceremonies, and artifacts in Scrum:

  1. Notice ineffective processes, workflows, or behaviors quickly and cease them.
  2. Notice effective processes, workflows, or behaviors communicate this knowledge
  3. Recommending new processes or practices that can be tested for the length of a sprint

At the organization level, the same process should occur.  While the empirical methodology monitoring “the process” – a mix of lean, XP, and other function-specific practices – is held constant, the practices that are monitored within “the process” are under constant review at the team and organization levels.

At this year’s ScrumAlliance Global Scrum Gathering in Phoenix, Arizona, I attended a terrific session  “Scrum at Scale – Free yourself from the myth of one-size-fits-all scaling led by Scrum Inc.’s Alexander Brown.  Look for an upcoming post on his argument that Scrum is by definition modular and object-oriented, such that organizations scaling Agile, Scrum, Lean, and XP can utilize empirical process control and a mix-and-match approach to the various frameworks most appropriate to the unique needs of each team.

The one outcome you MUST achieve in Sprint Zero

Scrum, Lean UX, & Extreme Programming Sprint Zero:

The length of sprint “zero” for a new product and the (debatable) necessity of common sprint zero expected outcomes may vary, but there is one task that must be completed, or the full benefit of your Scrum and XP practices will suffer:

Complete setup of the repository and automated build server – and send a build.

This is a critical step in establishing team transparency and Product Owner accountability – frequently delivered builds, even with mid-sprint potentially un-shippable product increments – are the exclusive insight of the PO into the progress of the product.  It is the Product Owner’s responsibility to determine the worthiness of the stories delivered and whether additional iteration is necessary; delaying this feedback loop robs the PO of crucial insights and undermines the team’s ability to gain fast and honest feedback.

The longer the team waits to send the first build, whether due to a still-emerging architecture or lack of finalized copy and assets, the more perfection becomes the enemy of the good (or in this case, the deliverable).  Scrum requires transparency and accountability:  remove dysfunctional Hawthorne Effect as early as possible by setting the precedent – from Sprint Zero – that the build is delivered to QA and the Product Owner early and often.