The first 90% of a project takes 90% of the time, and the last 10% of the project takes the other 90% of the time.

A key tension for development teams is defining what it means to be “done”.  It seems like every time we learn something new, the goal posts are changed.  This is especially true when what is being delivered needs external validation.  External validation can take several forms, especially when different parts of a business are at different stages in their agile journey:

• Quality assurance is a separate team.
• Business stakeholders don’t know what they want until they see it; then they want something different.
• Regulatory bodies or auditors must approve the results, for legal or compliance reasons.
• Competition and customer demands are constantly evolving, requiring rapid innovation.

All these challenges create a similar problem:  nailing down what it means to be done.  Agile frameworks promote a “definition of done” to guide a team’s work in small increments.  While each team may have a different definition of what “done” means, they should all have in common:

… a potentially releasable Increment of “Done” product at the end of each Sprint.

Scrum Guide

Potentially Releasable Increment

Note that the product increment — new functionality or a change to functionality — does not need to be “released” to be “done”.  But it needs to be potentially releasable.  That means, if given to customers and end users, they should be able to do something new and worthwhile with it.  If it’s a patch or bug fix, it should actually fix the problem.

The epitome of agile delivery models is continuous integration (CI) and continuous delivery (CD).  Taken together, this means that work is pushed to production as soon as it’s completed.  I can attest firsthand that for teams that embrace the CI/CD model, the benefits are huge.  Customers get what they want faster, and changes can be made much more quickly.  But sometimes this is not possible, or even desirable.

Why now might there be a delay between “done” and “released”?

1. End users may need training before new functionality is dropped on them.
2. Additional validation or approval cycles may be needed that are completely outside the development team’s control, especially for legal or compliance reasons.
3. The new functionality works just fine, but is no longer relevant.
4. The new functionality works just fine, but needs more functionality to be strategically complete.
5. Marketing strategy may combine several increments into a single release, to make a bigger splash or a dramatic “reveal”.
6. The release process may be too expensive for a continuous delivery model, so releases must be grouped.

While each of these reasons may be strategically valid, they do raise opportunities for significant improvement.

Training constraint

If user training is a bottleneck, can the product be made more intuitive?  For example, Apple insists that from the very first launch, an iPhone app should be “fast, fun, and educational“, with quick and easy tutorials.

The one time I tried to write an app for the iOS store, it was rejected for this very reason — a brand new user should understand the app and how it works in less than a minute!

Compliance and validation constraint

A distinction between “done” and “released” is critical when external approval processes are required.  Especially when the approval timeline is out of the dev team’s control, your feature tracking and task tracking systems must be set up to handle this limbo state.

The ideal resolution is to embed quality assurance into the development team, and use a test-first model, but sometimes this is impossible due to business constraints or regulatory constraints.

The business tendency is for the validators to say “it’s not done until I say it’s done and so you have to wait to call it done.”  This mindset creates two problems.  Consider a team on a 2-week sprint cycle, where their work is then taken through a 1-to-2 month approval process:

• Reports of the team’s velocity (how much is getting to done each sprint) are meaningless, because the “done” work is reported based on the approval team’s cycle, not the development team’s work cycle.
• The development team cannot celebrate the completion of their sprint goal at the end of each sprint.  Thus one of the key emotional motivators of “doing agile” is lost.

In short, the feedback loop on productivity — getting to “done” — can be kept distinct from the feedback loop on approval for “release”.

When the validation process finds a problem, a defect can be reported as a “bug” for the team to work on, most likely in their current or next sprint.  The other situation where “it’s all wrong” is when “you built what I said but that’s not what I meant” or “that’s not what I want now”; in that case, a new task (aka user story) can be created for the development team to schedule in their work.

Release timing constraint

Sometimes release timing is driven by cost constraints or other strategic considerations.  In that situation, it’s important to have a system to track what is done all the way through to final release in the product or service being delivered.

The better we get in coordinating activity between development and operations, the more our systems must handle this intermediate state between “done” and “released”.   For the technically-minded, here are some topics to track down and understand to handle this intermediate “done” but “not released” state:

• Feature toggle
• Cherry picking (not my first choice, but may be useful)

Final warning:  Don’t be a Scrum But

It’s far too easy to use challenges like this to compromise on agile principles and proven DevOps practices.  Hats off to Bill Rinko-Gay of the Agile Alliance for challenging us to consider whether we’re making the tough choices we need to make to advance the cause of agility and grow toward more healthy, productive teams:  https://www.scrumalliance.org/community/articles/2013/february/you-may-be-a-scrum-but

Embrace the journey.  It may take many iterations to implement these principles.  Many agile processes and principles are designed precisely because we do not live in a perfect world.  When we set our priorities and make one improvement at a time, eventually those changes add up like a snowball going downhill.

Business and technology innovators today often debate the usefulness of project management:

1. projects and project management are still useful concepts to structure business activity
2. projects and project management should be replaced with other ways of thinking about our work, such as product management and agile frameworks.

As you might guess from my theme of embracing the paradox, I agree with both perspectives:

Projects are very useful constructs to organize our thinking, just like campaigns, initiatives, releases, versions, and other bracketing concepts.

The classic definition of “project” includes “progressive elaboration” which is entirely compatible with agile concepts.

Is it time to stop thinking about projects?  No, says agile thought leader Mike Cohn, projects are here to stay:   https://www.mountaingoatsoftware.com/blog/is-it-time-to-stop-thinking-about-projects

Some traditional project management techniques are entirely incompatible with agile concepts.

Especially around requirements management and change control, these practices have set harmful expectations for the interactions between business stakeholders and project team members.

Are projects evil?  Yes, says agile thought leader David Hawks, we should abandon project management thinking in business:  https://www.solutionsiq.com/resource/agile-amped-podcast/projects-are-evil-with-david-hawks/

The biggest risk with “project” thinking is that once the project is “done”, the team can be disbanded, and the business gets nothing more of value.  This creates risks of requirements management and change control approaches that are all-or-nothing and extremely short term, because emotionally there is no sense of prioritization.

If your team goes away at the end of the project, you either got what you wanted, or you didn’t.  Since you don’t know everything that’s important up front, you load up the requirements with everything you think you might possibly want, because if you don’t get it into the requirements, you’ll never get it, ever.

A shift to a “product” mindset shifts the focus in ways which are entirely helpful – it’s long-term thinking, designed for operations, iterative, doesn’t have to be finished all at once, and can be changed with feedback.

When a project is done, the product lives on, and businesses need to plan for that reality.

In a nutshell, the customer experience is all about the product, not the project(!).

Once those concepts are embraced, I think we can reclaim and reuse the word “project” within an agile mindset.

“If you need it bad, that’s how you’re gonna get it.”

In our microwave world, we want (or need) things done quickly.  If you rush a job, quality suffers.  How do we resolve this paradox?

Many businesses are doing something right.  Our furnace recently died in the cold of winter; the two companies with the fastest response also have top reviews for quality.  Perhaps that can be explained away with repetitive processes.  But what about quality plus innovation?  Complicated, unpredictable processes? New product development?  Complex systems architectures and design?

Submit to the Triple Constraint…?

In the world of complex systems, professional project managers for years controlled conflicting priorities with a tradeoff model.  If your project got off track (schedule, cost, or expectations), you could optimize the plan.  The project manager drew a triangle and labeled each point:

• Time
• Scope
• Cost

“Pick two.”

It’s a triple constraint.

Of course, someone realized, you could Quickly deliver Big, Cheap Junk, so they taught their protégés to write in the middle of the triangle:

• Quality

“Pick three.”

They still call it a triple constraint.

“Good enough” is better than perfect.

One day researchers and savvy marketers discovered that people don’t really know what they want until they see it, and people typically use only about 20% of new innovation anyway.

So why waste time building big, perfect things?  In fact, delivering a little bit that is “just right” might be appreciated even more by our customers.

After delivering a little bit, we have some budget left over to deliver the next little bit.  If we get it wrong, toss it.  We’ve got room to build the next thing with the money saved in this new approach.  Companies like Apple — that learned to deliver less than their competition, but deliver it extremely well — started to thrive, and then they picked up the pace.

Bonus:  Customers get their hands on our product or try out our service sooner.  We had a decent idea of what was most important, and delivered just that little bit, and quickly.  Now we’re making friends and influencing people, and getting good feedback on what’s next on the priority list.

Double Bonus:  We may be only a quarter through our roadmap and already getting 80% or 90% of the benefit.  Now we have 75% of our budget or timeline left.  We can proceed like we thought we would, or we can shift all that budget and people to focus on the Next Big Thing, that other big deal that wasn’t getting anything done yet.  Were we ready for that pleasant surprise?  Can our team turn on a dime?  Is anyone paying enough attention to recognize the opportunity?  Do our change management processes understand?

Double Bummer:  We’re not the only ones doing this.  Other teams and our competitors also embrace this new approach of delivering a little bit at a time, with quality embedded as we go.  So the problem doesn’t go away, it gets more sophisticated and susceptible to the process of how we and our teams do our work.

Getting things done right and getting the right things done.

In order to get the “right things done” quickly, agile frameworks use the iterative and incremental approach described in my prior Focus & Flexibility post.

If the first half of quality is based on understanding fitness for purpose — getting clarity from external feedback — the second half of quality is based on disciplines to heighten internal feedback .

In order to get “things done right”, many agile and DevOps practitioners add technical disciplines to the iterative process.  These disciplines provide feedback as quickly as possible, even before getting to done.

Immediate feedback in software development

In the software industry, several agile disciplines can be used for designed for quality and quick feedback:

Pair programming

The practice of Extreme Programming (XP) takes the feedback loop of code review to the extreme:  continuous review, in the form of pair programming.  Two software developers sit together, often sharing a single keyboard.  While immediate productivity takes a hit, the “two heads are better than one” principle leads to fewer bugs and better design.  Better quality code is easier to maintain.

Like a driver and navigator working together to make their way through an unfamiliar city, pair programming can get the solution to its destination more reliably.

Mob programming

The overgrown cousin of pair programming, mob programming gets the whole cubicle involved.  They may share a single computer with a big screen, or have multiple screens on a wall together.  The group can simultaneously work on programming, testing, and refining user stories.

Automated testing,  test driven development (TDD) and test-first

In order to validate the code, tests are created to run automatically each time the code is changed, to help make sure nothing breaks.  Test-driven development take it a step further by creating the automated tests before writing the code (or at a minimum, at the same time).  A test-first model codifies this process:

1. Write the test.
2. Run the test and watch it fail.
3. Write the code.
4. Run the test and watch it pass.

Continuous integration, continuous deployment and DevOps

When the feedback loop is truly continuous, especially when writing software that runs in cloud services, the line between developing a solution and operating a solution starts to blur.  The intentional blurring of that line creates a DevOps team.

To illustrate:  Amazon deploys new software to production every 11.6 seconds.

The result is transformational:  releasing software used to be (and many places still is) a big, scary operation.  Automating those testing and deployment processes transforms the traumatic into the trivial.

Skateboarding on the freeway

The triple constraint of old-school project management misses a major principle.

Trust = Speed

Would you ride a skateboard at 60 miles per hour on the freeway in rush hour?  Even with a helmet?  (I wouldn’t!)

How about last year’s model sedan with seat belts and airbags?  Even without a helmet?  (You’d probably speed up, because the speed limit is 65!)

What’s the difference?  Safety.  Confidence.

Seat belts and air bags

When it comes to delivering innovation:

Quality = Safety = Trust = Speed

Developers will deploy faster, businesses will upgrade more often, and customers will adopt more quickly when they trust the solution will work after each update.  The disciplines of agility (especially continuous feedback cycles) increase the confidence and speed of the entire team.  Upgrades can become non-events (except for “what new thing do we get now?”).

Together with interpersonal dimensions of teamwork and respect, agile disciplines are the seat belts and air bags that enable us to move quickly and confidently.

Quality and speed are not incompatible adversaries, they are necessary companions.

Constant change is necessary. Innovate or die.

Disrupt the industry.  Quickly respond to customers needs and desires, or else your competition will destroy you.  We know the classic stories:

• Netflix wiped out Blockbuster video with their DVD-by-mail service, and then further disrupted their market with video streaming.
• Amazon changed how people buy books, then everything retail.  Walmart and every mom-and-pop retailer — now grocers — have been trying to react and even save their businesses.
• Uber and Lyft are disrupting taxi service.
• Airbnb is changing the hotel and lodging industry.

This is especially true in technology industries, where disruption is the norm.  Stay flexible, responsive, ready to change course and turn on a dime.  But when it comes time to execute on constant change, we hit a wall.

Constant change kills productivity.

Innovation is hard work, and hard work requires focus.  This is a problem:  the more dynamic the environment, the more interruptions and distractions sabotage the necessary work we must do to make the change happen.

This is not just theory; current research highlights constant change as one of the biggest barriers to actually getting things done:

• American Psychological Association (APA):  Multitasking and “goal shifting” can decrease personal productivity by 40%.  (It can also kill you! Avoid the multitasking of texting and driving.)
• Psychology Today:  Multitasking is actually a myth.  It’s really task switching, and that is highly inefficient.
• New York Times:  Fixing this problem of mental juggling tops the list of things to deal with to improve personal productivity.

Focus v. Flexibility for Teams

How do we embrace this paradox?  Constant change is what every company must simultaneously embrace and avoid in order to get the right things done.

Agile frameworks tackle this issue head on, and in different ways.  Scrum is an agile framework used most often by development teams, and Kanban is an agile framework used most often by operations teams.

The Scrum approach:  sprints

To move a team quickly in the same direction, Scrum uses sprints.

The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.

Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.

During the Sprint:

• No changes are made that would endanger the Sprint Goal;
• Quality goals do not decrease; and,
• Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

In my experience, the most common duration for a sprint is two weeks.

Two weeks is enough time for a team with uninterrupted focus to get something substantial and beneficial done.

A two week cycle allows frequent, meaningful course correction so market opportunities and changing business needs are not missed.

The Kanban approach:  work in progress (WIP) limits

To prevent bad task switching, Kanban uses work in progress (WIP) limits.  With Kanban roots in lean manufacturing, WIP limits started out as an inventory management concept.  By minimizing the number of units in production queues, a manufacturing system could reduce waste, eliminate bottlenecks and increase efficiency.

The concept translated quite well into knowledge work.  Limiting the number of tasks being worked on helps individuals and teams “get to done” more rapidly, and — bonus —  eliminates some bad multi-tasking.

The Docks Metaphor

One of my favorite ways to illustrate this concept is to draw a picture of five docks on a whiteboard.  Picture yourself running a shipyard, with room to dock five ships.

Monday morning you arrive to work with five captains eager to get their ships unloaded.  Each ship takes one worker five days to unload, and you have five workers.   How do you partition the work?

The captains will be happiest on Monday if you put one worker on each ship, and they will be ready to pull back out to sea at the end of the week.

But suppose you put five workers on one ship, and it gets unloaded in a day?  Unloading one ship per day will get all five back out to sea by the same time, but one ship is making money four days sooner, another three days sooner, two days sooner, and one day sooner.

The team focus buys you flexibility to hire a team to clean the docks or even dock another ship to unload.  But it also means thinking of a good way to calm down the captain who sees his ship sitting with nothing happening for four days.

Finding ways to integrate focus and flexibility takes conscious work.  Just like the shipyard manager, agile practitioners often need to explain their focus and why they do it differently.

 

​Agility is a paradox — many paradoxes. Unlike command-and-control systems, which give managers the illusion of knowing where they are going and how fast, agile systems require a coordination of teams living on the edge of the known and the unknown, the controlled and the uncontrollable.

Aristotle taught that virtue lies in the balance between two extremes. Courage is neither foolhardiness nor fear, it’s found somewhere in the balance or integration of the two: taking bold, risk-aware action even when you’re afraid.

Agile people and teams live between extremes. This blog explores the virtues of agility and life in the balance.

Focus and Flexibility

Quick and Quality

Done and Delivery

Strategic and Self-organizing

Distributed Collaboration and Direct Connection

Planning and Pulling

In the world of personal productivity, there is a treasured state called “flow”. It’s a mental place of relaxed alertness where you lose track of time and suddenly realize how much you’ve accomplished in a few hours. Teams delve deeply into the virtues of agile to achieve the equivalent of “flow” as a team.