Scrum practitioners may notice my prior post about Planning and Pulling made strong recommendations that go beyond Scrum and the Scrum Guide.   It’s okay to add your own processes to Scrum; in fact, that’s what a framework is for — it’s a structure which provides a combination of shared clarity and vocabulary plus freedom to innovate.

When I was writing this post yesterday, I was wondering how to make that point clearly.  Today, I ran across a great article that makes the point for me:  Scrum: It’s a Framework not a Process by Krystal Ahlstrom.  Check it out.

This gives me an opportunity to pull out one of my favorite agile aphorisms….

Don’t be a Scrum But

The authors of the Scrum Guide make it clear:  if you’re going to take away an element of scrum, that’s okay, but don’t call it scrum.

“We do scrum but we don’t do daily 15-minute scrum meetings.”  That’s not scrum.

“We do scrum but we don’t have retrospectives.”  That’s not scrum.

“We do scrum but we don’t have a product owner who prioritizes the backlog.”  That’s not scrum.

So don’t say you’re doing scrum when you’re not.   “Scrum but” is not scrum.

It’s okay to be a Scrum Plus

Adding something to scrum is just fine.  What you’re adding is not scrum either, but you can call what you’re doing “scrum … plus….”

“We do scrum plus technical coordination among architect-minded people representing each scrum team.”

“We do scrum plus we track escalations on a Kanban board.”  (Yes, dev team members often wear more than one hat in a company.  That’s a scrum team member plus….)

“We do scrum plus breakfast together every Friday morning.”

You can add processes to scrum all day long, if they work with the framework.  When you do, may I suggest:

• Be careful your additional processes are consistent with the spirit of agile.
• Make clear to others that your additions are not scrum, they’re what your team has decided to add.

 

We don’t plan, we’re agile

Wrong.  Surprise!  Good agile teams spend more time planning than do teams with traditional project management.

For many, this seems counterintuitive.  Many think that a team designed for responsiveness to business changes and competitive opportunities would just get good at reacting to opportunities and new requests.  Carpe diem, seize the day; that doesn’t sound at all like sitting down and making a roadmap or laying out daily tasks for the next two weeks.

“In preparing for battle, I have always found that plans are useless, but planning is indispensable.”

– General Dwight D. Eisenhower

More planning in smaller chunks

Agile teams plan more, and they plan differently.  Agile plans are not for comprehensive documentation, not to eliminate all uncertainty, and not to avoid midstream course corrections in advance.  They are for tight team alignment on the next set of work.  The provide clarity appropriate to the distance to the next horizon, and take 10%-20% of the team’s effort.

Let’s look at three essential kinds planning for agile teams:

• Sprint planning
• Architecture planning
• Roadmap planning

Sprint plan

In the scrum framework, a development team works with the Product Owner to select and commit to specific results, an increment of potentially releasable functionality or product.  This is called a “sprint goal”.  If a team has two-week sprints, the team selects the amount of work that they can commit to complete in two weeks, from the highest priority items in the backlog.

Sprint planning turns the top items in a product backlog into a sprint backlog.  Through the course of the sprint, this backlog is converted to done work.  So how, during the course of those two weeks, do you know you’re on track to get everything done?

1. Plan for each day to get something specific done, and then
2. Each day, get done what you planned for that day.

That first step is done either before starting the sprint, or on the first day of the sprint.  If you do this planning before the sprint, you have more certainty you’ll be able to meet the goal before you commit.

If something doesn’t get done on the expected day, you re-plan in the middle of the sprint, how you will stay on track. Potential re-planning activities ask and resolve questions like:

• What tasks need re-ordered with this new information?
• If we have an unexpected wait on one task, what other task should we start sooner to make full use of the time?
• Do we need to swap work between team members?

This is the real reason scrum has a daily standup — and these could be better questions than the typical status report:  “What did I do yesterday? What am I doing today? What are my blockers?”  If you have a daily plan, the team already knows the answer to the first two questions, unless you say, “hey we must re-plan this.”

Of course, every sprint needs to have some margins for additional activity and unexpected happenings.  Most of the time, this available time is to look ahead to future activity, and resolve uncertainty in the product backlog.  But sometimes, it gets used up dealing with the unexpected happenings within the sprint.

Always, always leave a bit of room in every sprint to handle a bit of re-planning and adjustments, and if that time isn’t used to re-plan the current sprint, use it to plan ahead for the next sprint(s).  It’s great return on time invested, eliminating future problems so the team can stay productive.

Architecture plan

When building complex new systems or processes, sometimes more dedicated time is needed for architecture planning.  This can mean an entire sprint dedicated to fleshing out a proposed systems architecture, followed by another sprint creating a roadmap to implement that architecture over the next 6-10 sprints.

“What?”, you say.   “I thought every single sprint needed a potentially releasable increment of functionality or business benefit?  I can’t release an architecture or roadmap and get immediate business benefit.”

This is true.  And ideal.  And it’s possible with fully mature, experienced agile teams with a history of working together.  But sometimes — especially with new teams working on new initiatives — it takes some time to develop a shared head space, common vocabulary and common understanding of the destination.

Don’t skip this step.  If the team doesn’t have a shared understanding of your systems architecture, make it so.  For a new product or complex process rearchitecture, this can easily take a couple of weeks.

I’m assuming you’ve assembled a team of competent technicians who can do the work, but they don’t know the big picture up front.  They may be working together for the first time.  They must take time to get a shared understanding of the systems architecture.

Make sure every member of the team participates in the discussion.  Get into arguments, friendly fights (okay maybe intense fights) over the right way to do this thing.  Get the architecture down in a picture, a shared diagram and vision of how the moving parts fit together, how the flow will work when the whole thing is done.

You’re right, the team just lost a sprint worth of productivity, not releasing anything but a document or a medium-detailed architecture diagram.  Trust me, the next many sprints will be intensely more productive with a well-aligned team who now have shared context for every upcoming planning (and doing) session.

Roadmap and release plan

For brevity, I won’t make a clear distinction in this post between roadmap planning and release planning.  Let’s just say it’s all about “what’s next” in the product development, as well as “what’s next after that”.

Whereas the team does all the sprint planning, and usually the architecture planning, the Product Owner is the one doing most of the roadmap planning and release planning, with input from key stakeholders.

As mentioned in my prior post, having features and functionality queued up in advance lets business stakeholder relax.  They can know that even if something is not being worked on now, it’s in the backlog, and being considered alongside all the other priorities for the product.  The roadmap and release plan can make that visible.

For the team, this is an essential resource, to help them think ahead to what’s coming.   While it’s important not to over-build a solution based on features that are down the road, there are many times that consciously or subconsciously the team will make subtle design and architecture choices based on what they know is coming later.

Wow, that’s a lot of planning

Some get impatient with this much planning.  That’s understandable.  We all like to get things done.

First of all, remember that 10%-20% of time spent in planning is not a waste of time; it’s normal.  That means you should expect 1-2 days of planning every two weeks.

Compare this to a traditional product life cycle — run the real numbers in old school project management — this 10%-20% is really not as much as we think.  Consider that the value produced by agile teams is far more business aligned with tighter feedback loops, and there is less waste and rework.

The greatest risk of this much planning is when the entire team or culture falls into a trap:

full team involvement in everything
+
discomfort with any uncertainty
=
the entire team going down every rabbit trail

How not to waste the team’s time

Once the broad architecture is established, you only need to involve the team in detailed planning for the immediate work — the current and next couple of sprints.

Use selected architects or team leads to “race ahead” and figure out some of the roadmap elements in advance.   If the entire team has system architecture capabilities, you can at least send different people down different rabbit trails.

The certainty of planning (readiness for a team to commit to the work) can diminish the farther out we plan.

Consider a team planning out ten sprints in advance.  The current sprint has 100% confidence — all tasks and user stories are understood.

Different teams break down features differently, but for this analysis, let’s say a  bunch of related user stories comprise an epic.  The team does detailed planning at the story level, and selected team members look ahead to future epics, which are broken down into stories over time.  By the time a story is worked on in a current sprint, it is completely understood and detailed subtasks are lined up to do the actual work, as defined in the sprint plan.  The next couple of sprints are planned well enough that, if started today, the work could get done, though perhaps with some risk.  Further out, it’s less certain.

Sprint being planned	Level of confidence	Refinement focus	Planning Participants
Current Sprint	100%	Story	Product Owner + Team
Sprint +1	80%	Story	Product Owner + Team
Sprint +2	80%	Story	Product Owner + Team
Sprint +3	50%	Story/Epic	Product Owner + Architect + Team Leads
Sprint +4	50%	Story/Epic	Product Owner + Architect + Team Leads
Sprint +5	50%	Story/Epic	Product Owner + Architect + Team Leads
Sprint +6	20%	Epic	Product Owner + Architect
Sprint +7	20%	Epic	Product Owner + Architect
Sprint +8		Epic/Feature	Product Owner
Sprint +9		Epic/Feature	Product Owner

Note that there is no formal role for “architect” or “team lead” in the Scrum Guide.  This is simply one way to plan within an agile framework.  Feel free to use whatever vocabulary make sense for your team, and adapt this to your situation.

Of course you’ll adapt, because plans change.  But planning is essential.

Pulling well-planned stories

Well written epics and stories sit there, ready to go.  When the team is ready to build the solution they “pull” the next stories.  Because they were involved in planning the work, they can be trusted to complete the work they committed to do. And if they miss, they have a tight feedback loop to make a better plan and a better commitment next time.

This pull model is different than the “push” model of planning, with rigid milestones tied to fixed functionality.  Work is not dictated to the team, it is prioritized for the team, and they pull into the sprint, before it starts, the amount they are ready to take all the way to done.  Everyone likes to get things done.

Final note:  YAGNI

If you’re ever wondering whether to over-architect, or over-plan, or even over-deliver and you’re considering doing extra work that doesn’t provide benefit any time soon, but might be useful down the road, but you’re not sure … remember this acronym and let it be your tie-breaker:  YAGNI.

You Ain’t Gonna Need It.

Plan to deliver what’s next, plan your priorities, and plan well.  You can even plan big.  But remember, plans change.  If in doubt about something that’s not the next most important thing:  YAGNI.

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.