Recommended Reading for Agile Practitioners

Crossing the Chasm

A Product Owner's guide to bridge the gap between early adapter to the early majority

“The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment. Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.” [Scrum Guide by Jeff Sutherland and Ken Schwaber]

We curated this list of that we feel is important and useful for every scrum team member.

It is not a complete or a final list, we try to keep it small enough to be digestible but not too small so that it is missing the major things. Your comments \ Suggestions are more than welcome.

The following books are specifically for software development teams. 
Whether you are a programmer, a tester, a UX-er, a business analyst – you’ll find them priceless.

Advanced Product Owner Workshop

  • Does it seem that the team never understands what you mean?
  • Having a hard time splitting user stories to shippable items?
  • Struggling with predicting when will we reach the deadline?
  • Having a hard time with prioritization of requirements?

If the answer to the questions above is yes, you may want may want to attend this workshop
The Agile product owner workshop is 1 a day experiential training.
This workshop will provide a better and deeper understanding of the Agile Product owner role which will help the PO to improve his efficiency resulting in a better product.

Lecturer: Anat Alon


  • Knowing how to define what is the product vision, and what is it for.
  • Ability to create a product roadmap based on the vision.
  • Understanding of user-centric requirements and how to deal with them .
  • Write, analyze and prioritize requirements in the format of User stories .
  • Understand the “how” of the PO roles and responsibilities .
  • Create, Maintain and work with the product backlog .
  • Make the most out of working with Burndown charts and Metrics
  • Understand the Definition of Done

Target Audience

This workshop is for Product managers, product owners and Agile coaches who want to advance their learning further and build amazing products.

Workshop outline

  • Product roadmap
    • The Lean Canvas
  • Requirements
    • Personas as the base for requirements.
    • User stories
  • Product backlog
    • Product backlog items
  • Functional requirements.
  • Non-functional requirements.
  • Effort estimation & Value estimation
  • Creating a backlog – Backlog workshop
  • Maintaining the backlog – Backlog grooming
  • Learning to read the backlog – tips for keeping it clear
  • Prioritization techniques
  • Burndown charts & Metrics
  • Understanding the Burndown
  • Burndown smells
  • Extra data that can be added to the Burndown
  • What \ How to measure
  • Tracing project progress
  • Pricing tips for a project
  • The sprint review
  • Definition of Done
  • Acceptance criteria
  • Backlog prioritization

This is a general syllabus and in case of an in-house training, it is possible to make the necessary adjustments to make it more appropriate for your organization’s specific needs.


Unless otherwise stated, the workshops runs 1 day, 9:30 to 17:30.

What people that participated say:

  • “A Fascinating day, leaves a taste for more…” – Rami Ben Ari, Director of QA.
  • “The course was thought in a fresh way which caused the crowd to assume an active role causing me to stay alert, curious and interested for the entire workshop” – Gili Orkabi, Director Program Management.
  • “Dear Ilan, I enjoyed the workshop greatly. The knowledge delivered is practical and relevant, as is the interesting way it was deleivered” [Translated from Hebrew] – Ophir Gal-Mor, 888.
  • “Practical tools to deal with day to day challenges. Perfect balance between frontal lesson and exercise. Lesson and content delivery excellent and experiential. Thank you.” [Translated from Hebrew] – Aviv Levin, Egged.

Our Team – Lior Friedman

Lior Friedman (, is a full-fledged Agile Coach, co-founder at Practical Agile and co-founder at Practical Software. With more than 15 years as an IT professional, he promotes agile values helping companies adopt these principles and adapt such practices into their own local context. After leading the development of cutting edge testing tools at Typemock Ltd. and helping numerous companies with their TDD implementation; he currently provides training, mentoring and high end consulting services to clients, (specializing in AUT, TDD and general agile transitions)

twitter: @imistaken

Our Team: Ilan Kirschenbaum

Ilan is a seasoned software professional with more than 20 years of experience in development, design and architecture and product management. Having discovered SCRUM and agile a few years ago, Ilan has learned why previous Waterfallish implementations failed to deliver. Ever since he is advocating agility through coaching, training, and assisting teams and individuals implement SCRUM and agile in their organization.

twitter: @kirschi_

Our team: Elad Sofer

Elad Sofer

Elad SoferElad is first and foremost a SW engineer, Several years ago he was infected with the agile virus and has not been able to “shake the disease” ever since. He is now traveling across the IT industry with a mission to infect other people.He is now helping software projects, teams and organizations, varying from small to big, from lightweight startups to government Offices in Israel.

twitter: @eladsof

Some Useful Tips for Online Retrospectives

Last week, on May 5th, 2020, we held an online retrospectives meetup. Effectively we took our Retrospectives Retreat and transformed it to an online format.

Following the meetup we wish to share tips for online retrospectives, including specific learning points from this meetup.


If there is one important thing to share, this would be it. Of course we had our share of technical and facilitation glitches, of course there were things that didn’t go as expected, and yet, preparation was the one superpower that helped us successfully holding the meetup to the end and keeping participants engaged.

So here are a few tips for preparing for your next online retrospective:

  • Begin with the end in mind.
    What would you like to harvest from the retrospective?
    During the break there was a discussion on whether to decide on the retrospective theme in advance. My preference is a clear Yes – this will influence on the structure and the practices you choose for the session.
    Which leads me to:
  • Decide on the retrospective structure.
    We have prepared two retrospectives for the meetup (ended up completing one of them).
    Decide on the supporting tools.
    In our meetup we’ve used Mural , which proved highly effective.
    We’ll be happy to share the Mural templates we made for the meetup.
  • Within the Murals we’ve included facilitation guidelines. This has worked so well that I want to keep doing it for onsite retrospectives using guidelines on flipcharts.
  • Practice session. We’ve tried out multiple technologies and concepts to enable this meetup. So we held an internal practice session. Here are three of the key findings from our practice session (and yours will probably be different!):
    • Choice of colors: Some of the colors in the Mural were invisible for a teammate with shade-blindness. e.g we had to change the default yellow sticky-note color
    • Links on Zoom chat sometimes show as text and not a clickable link. A meaningful shortened url pointing to a google document was a constructive solution
    • Some descriptions were unclear. For example, we changed all the descriptions on the Team Radar to be clearer and more relevant for the task.
  • Plan to work as co-facilitators. So you can divide the effort between you, and have each other’s back during the event. Before the retrospective we have practiced our parts and gave feedback to one another to sharpen our performance.

During the session

Online encounters require more time than onsite ones, as we’ve indicated in our recent WFH tl;dr post

Here are some tips relating to what to expect and what to do during an online retrospective

Most of these tips are significant for the preparation, too.

  • Allow for more slack time than usual. As mentioned above, we planned to have two retrospectives and ended up doing one.
    In a team retrospective, you want to end with some actionable items, such as experiments to take forward.
    That calls for shorter activities and plenty of slack time. Participants will be happier with ending early rather than ending with no actionable outcome or having to continue beyond the scheduled time.
  • Allow time for orientation. In our online retrospective retreat we’ve used Meca Bricks https://mecabricks as a studio for making Lego farm animals, based on Liz Keogh’s Lego Kanban Game (CC-BY-4.0)
    As an orientation and a short get-together for the work teams we had a 5 minutes slot just to play with the studio.
  • For larger groups (5 and up), use breakout rooms for check-in and connecting to one another.
    When onsite, large group characteristics can emerge in groups of 10-12: little to no interpersonal conversations, silent members not being heard, vocal members taking center stage, etc.
    When online similar characteristics emerge in much smaller groups, as little as 5-6.
    So plan for breakout rooms of up to 5 members.
  • Opt for short activities. Online meetings consume much more mental capacity than onsite meetings.
  • Have small groups in breakout rooms manage their session on their own. The pre-made Mural templates were very helpful on the facilitation and on the recording on decisions and outcomes. There are numerous tools that can be used, so experiment with what you feel comfortable with.
  • Invite participants in small groups to take roles. In our retrospective retreat we invite groups to choose a facilitator to observe the iteration and to assist on time-keeping, leading the retrospective activities, and so on.
    In your retrospective you may choose to delegate facilitation tasks to the small groups according to your own preferences.
    In Don’t Just Do Something, Stand There, chapter 4, Let People Be Responsible, Janoff and Weisbord recommend having in each small group a Discussion Lead, a Recorder, a Reporter (to the large group) and a Time Keeper.
    It’s a good idea to add such roles to the instructions on the retrospective Mural/s.
  • Be patient with the pace. Teams unfamiliar with online facilitation tools will take longer to get orientated. For your first times use simpler tools, such as Padlet
  • For longer sessions (longer than 90 minutes) include a break.
    It’s a good idea to have the break between Generating Insights and Deciding What To Do. This may give participants the opportunity to let the retrospective harvest to sink in, and ripen in time for coming up with actions.

What surprised us

  • Even with the orientation exercise, some people expressed a wish for a softer check-in allowing them to get familiar with one another. You should sense what would make more sense to your team. And, as always, experiment with various check-in techniques.
  • Even with a step by step introduction to technologies, some participants felt it was too much at once. Did I mention that the pace of online retrospectives is slower?
  • The directions included within the Mural proved even more helpful than we anticipated. That was my A-Ha! moment to include more how-to flipcharts when we go back to onsite retrospectives.

Concluding comments

In most retrospectives we use the 5-step facilitation techniques, as masterfully explained in the book Agile Retrospectives, Making Good Teams Great .

This is reinforced for online retrospectives, where such a structure helps moving forward with little effort from the facilitator/s.

In the shift to virtually 100% virtual teams the importance of retrospectives is multiplied. Soccer teams spend 95% of their time practicing and improving and 5% of their time on matches. In software development teams we’re lucky to have the reverse percentage.

An online retrospective can be a wonderful way to to sharpen your teamwork skills and to come up with improvement experiment.

Compared to an onsite retrospective, preparation and practice as facilitators is paramount.

What is your experience with online retrospectives?

What have you learned that worked and what learning can you share?

image: by teegers0

Deliver working software frequently, tl;dr

Of all the principles of the agile manifesto, this is the most outdated one.

Back in 2001 the authors of the manifesto defined “frequently” as two months to two weeks, with a preference to the shorter timescale.

And Working Software means just that – a product increment that is deployed in whatever production environment it is intended to work on.

A truly agile organization is capable of a software delivery frequency of minutes, hours or – at most – just a few days.

This, BTW, has nothing to do with iteration length. A team can work in a 2 week iteration and still release software dozens of times per day.

If you’re already practicing continuous delivery and are able to deploy new features to production multiple times a day, read no further.

If, however, you wish to increase the number of deployments per day or even per month, this post is definitely for you.

This post is the 4th in a series on Agile Manifesto tl;dr. Click here to go to the first post including an index to the others posts.

Why shorter releases?

Many organizations that operate on long releases (say 3 months or more) find themselves struggling to enjoy the benefits of their agile journey:

They want to have shorter releases to reduce the TTM – Time To Market.

By shortening the release cadence they often find that they deliver less content while keeping a large overhead each release.

Less content builds pressure, which, in turn, increases errors and people’s burnout, which, in turn, reduces content even more, which, in turn, builds more pressure etc.

What’s holding them back from enjoying the fruits of their efforts?

Typically it will involve some kind of disconnect between development and operations.

And it’s a vicious cycle:

OPS experts don’t trust Dev teams to keep a healthy production environment. So they block access to critical systems.

Dev teams don’t have access to the critical systems, so they release substandard code to OPS due to ignorance to the implications.

Mistakes prove OPS experts’ point, so they keep Dev teams away from production.

And on it goes.

It’s no one’s fault, and yet this is a great recipe for blame culture.

Dev + Ops === DevOps

In a nutshell, to enable continuous deployments the following groups of experts must be able to work directly with one another:

  • Developers (aka programmers, testers, DBAs, FEDs, etc) and
  • OPS people (aka infra, ITS, pipeline group, etc)

If you are struggling with the idea of dev and ops people working together without boundaries, I have tl;dr-ed for you the now seminal DevOps talk – “10+ Deploys per day”:

They – Dev + Ops – should be able to seamlessly do:

  1. Automated infrastructure – an orchestrated collection of tools to automate where you want to deploy to
  2. Single shared version control – so everyone knows what “trunk” means, and everyone means the same thing.
  3. One step build – so everyone builds the same way
  4. One step deploy – so as to remove all manual and error prone deploy activities
  5. Feature flags – so everyone can ship changes over trunk with minimal risk of side effects.
    That means you can do private betas and dark launches to get confidence in the field with new features prior to enabling features to the wild.
    This also means that you can quickly and risk-freely switch on and off any feature that misbehaves.
  6. Shared DevOps metrics – so everyone is aware of the impact on runtime of whatever is running at the moment
  7. Alert robots – so no one has to sift through logs to find or to understand known problems

Succeeding in achieving this list is made possible through encouraging an organizational culture that is based on:

  1. Respect – A culture that appreciates that everyone wants the success of the organization and that respects differences between people and does not stereotype.
  2. Trust – A culture that encourages transparency, visibility, honesty
  3. Healthy attitude towards failure: A culture that is forgiving failure while encouraging technical and operational excellence. This is made possible by learning, deliberate practice
  4. Responsibility – A culture that encourages responsibility and discourages blaming.

What to do next?

If you are currently struggling to figure out how to do a release cycle that is shorter than a work week, I have no silver bullet to offer.

It will be a long journey.

But it will be one that will quickly bear sweet fruit. Typically quicker than you imagine.

Here are some useful resources to take with you on your journey:

Where to begin?

Of course, none of this is mandatory or essential.

A long release cycle may not be what you need. So maybe it’s not worth the effort.

However, recent history teaches us that changing priorities quickly is becoming ever more critical for business success. Some of the most pressing requirements became irrelevant when COVID-19 surprised all of us. And new and unexpected ones became critical to the business.

Organizations with a robust deployment pipeline change priorities almost instantly. As recently done by scores of companies.

Also, nothing here is new: Toyota has developed SMED (Single Minute Exchange of Dye) between 1945 through to the 1990s, and reducing dye change time from 12 hours (or up to 3 days) down to 180 seconds.

Software organizations reduce build times from around 12 hours to a few minutes in a matter of months or weeks. Sometimes a few years. So your prospect of developing your own SMED is far greater than that of Toyota. And, in contrast to Toyota, most DevOps problems don’t need reinventing a new technology. It’s mostly a people problem, not a technology problem.

This is just to say that one must begin somewhere.

Address low hanging fruit and high impact steps first, and perpetually progress towards perfection.

And keep telling yourself: There is no Dev vs. Ops, and there is no Dev vs. DevOps vs. Ops. There is just DevOps, and the various disciplines must be able to work together as a team.

Image source: by kropekk_pl

WFH tl;dr

Like many countries, Israel abruptly changed to almost 100% WFH (Work From Home). For us this began on March 15th.

Since then we have collected for you useful practices that teams actually do that help them be proactive and productive.

I find it important to note that nothing here is theoretical or a nice idea. Everything from this list has been tried and tested and found useful by teams.

So, here goes, in no particular order, albeit divided to practices, tools, and useful lists by influential experts


  • Have two daily standups: morning and evening.
    Frequently these teams have the morning standup for daily planning and the evening standup for socializing
  • Have two zoom rooms open 24/7: The kitchenette and the corridor. HR opened these rooms for the company. And people drop in when they take a break.
  • Open each meeting with a short check-in. Sometimes a simple “how are you”, sometimes a game, like throwing an invisible ball.
    I invited people to share on video an object you’d never see in the office, and that brought cheerful smiles.
    Sometimes check-in as a group, and at other times in pairs or threes.
  • Which leads me to:
    Breakout rooms.
    Zoom has a nifty feature for choosing who goes in what room or randomly letting zoom assign people to rooms.
    Some teams use zoom for the whole team, and slack for breakout sessions during the meeting (and then the large room is muted)
  • Liberating Structures.
    We’ve tried this week 1-2-4-all; What? So What? Now What?; 9 Whys?
    Many structures are “onlineable”.
    There are numerous resources for highly experienced online LS practitioners. Here’s one example:
  • Periodically replace the regular retro with a Happy Hour with alcohol and music and stuff.
    A practical Zoom tip here is that you can share your music player and have the audio streamed to everyone (instead of a speaker playing to the mike which kills the audio quality)
  • Book a No-Meeting-Zone when no one is allowed to interrupt the team
  • Agree on the office hours, when no one is allowed to interrupt family time
  • Team lunch and team coffee break shared on video
  • Teams that typically do not update their online tool (Jira, Rally, …) feel a greater need to keep them updated.
  • Mid-sprint / Weekly planning. That’s like a longer, 60-90 minutes daily, for the new week.

Update, 2020.04.05

  • Work with multiple displays, having a video-call on one display and content-sharing apps (miro, padlet, …) on the other.
    Teammates that didn’t have one at home told me they popped into the office to bring an extra display over.
  • The bottom of the coffee mug became suddenly so visible on video! Place a sticky-note with an insightful or another nice message at the bottom of the cup

Online tools

Use online tools for planning, retro and ad-hoc meetings. Here the list is endless, and most teams we encounter are still experimenting with what works better for them.

Sharing here’s only a list of tools we’ve seen used or experienced ourselves these two weeks:

Tried and tested lists from additional influential experts

What tips would you add?

What other lists worth sharing have you found?

Looking forward to reading your insights in the comments.


Virtually Together – Reconnecting Work in a Time of Uncertainty

Reality brought us more than ever into the virtual world. Our conventional ‘sense of place’ in work and in the world, our relationships with team members, and our workflows have been severely disrupted. 

Creating an optimal virtual work environment means that we need to not only adopt the best tools and practices available out there – we’ll be covering those – but also invest in increasing the experience of our virtual interactions (via Zoom, Webx, etc.). 

By enabling a higher engagement level of team members through a multi-sensory experience, we can increase the quality of the interaction, the sense of wellbeing, and overall productivity. 

Let us dive into practice, and skip most (if not) all of the soul smashing lectures or webinars – 

Let’s walk the walk virtually speaking and ‘workout’ together how to make things work best. 

Done right, we can have more energy at the end of the meeting than when we entered it.

Four Elements

  • Environment – how to make the space around you most productive
    • Placemaking
  • Technical – how to make the tools do the work their suppose to do
    • Hardware
    • Software
    • Practice
  • Individual – how to be present and effective – practices of tuning ‘in’ and leaving ‘out’
    • Preparations
    • Tuning in – being present
    • Creating experience
  • Group – increase the efficacy of communication and relationships within the group  – practices of virtual engagement 
    • Crossing the screen – ‘un-seeing’ the virtual – warmups 
    • Check-ins, Intros, going “glocal”
    • Breakout sessions and Keeping it Together
    • Checking out

Mode of work

The mode of work oscillates according to need between:

  • Modeling: We will facilitate an online meeting so you can experience it
  • Shadowing: You will join us to plan an online meeting, and observe us during the meeting
  • Mentoring: We will guide you to facilitate a meeting on your own
  • Reflection: We will jointly reflect on how a meeting went and inspect and adapt towards improvement
  • Learning: Online workshop to learn and practice practices and tools

What you can get from our online services

  • Online meeting etiquette 
  • Practices for meeting preparation, and time allocation required for preparation
  • Practices to break the boundaries of the screen to feel together
  • Practices to be more present – physically, emotionally and mentally 
  • Practices to overcome the effects of long sitting periods
    • For example, make sure to break often to avoid “screen fatigue” 
  • “KPIs” for a good meeting: e.g. number of smiles 
  • Cheat Sheet for online meetings
  • The “VHO” – Virtual Happiness Officer – how to make online meetings happy 
  • Tools to use before, during and after the meeting
    • Breakout rooms
    • Content sharing tools, such as shared whiteboards
    • Meeting facilitation practices tools, such as Liberating Structures
    • Use of visual elements such as planning poker cards, voting cards, etc.
  • Breakout sessions in online meetings – keep people engaged, energized, feel physically together, 
  • Start with why: Why we use practices that generate a multisensory experience?
    • Mirroring neurons in action 
    • Create the experience as if I was in the other person’s room
    • Generate a better presence during meetings 


Our Highest Priority… tl;dr

It is a common mistake to think of agile as a set of practices for software development teams. But it’s not – at least not in the commonly interpreted manner – as indicated by the first principle:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

The majority of development teams practicing agile are – in fact – not agile teams. It’s a harsh statement, I know.

This is for the simple reason that, most so-called agile development teams are locally-optimized to create software. Some of them create working software.
And fewer than those are creating software that customers can actually use, in a true continuously delivered software.

The flaw is in what customers get, not in the fact that they get working software.

This post is the 3rd in a series on Agile Manifesto tl;dr. Click here to go to the first post including an index to the others.

Let’s break this principle to smaller pieces:

Our highest priority

The word ‘priorities’ is relatively new – it virtually didn’t exist until the turn of the 20th century, aka birth of the Science of Management. Before that, there was only Priority – singular, as in Information or Knowledge. A person or organization can hold information and knowledge, not informations or knowledges. In the same token, until c.1900 an organization could only have a Priority, not a set of priorities.

With the growth in size, organizations began to manage multiple priorities, leading, ultimately, to loss of focus.

So, our highest priority – The Priority – is to satisfy the customer though early and continuous delivery of valuable software.

Agile processes guide us to work on OITO, as Asad Safari notes:

…is to satisfy the customer

A customer, any customer, exists in both ends of the software development process: In requests coming in, and in valuable offering coming out.

This is borrowing directly from Open Systems Theory.

If our Priority – The Priority – is to Satisfy The Customer, we will be most effective and efficient when we will all be working on the same thing, regardless of our role, team, group, department, etc.

…through early and continuous delivery

Early – deliver something as soon as we can

Continuous – deliver also the next thing as soon as we can

So to be in our most efficient and effective form, we should work on the smallest chunks of work possible.

To do that we should be aligned on what we do regardless of role, team, group, etc.

Noting also the implication of the word – delivery.

When I shop online for groceries, the delivery is accomplished when the goods are received at my home, to my satisfaction. If the provider delivered the wrong or substandard goods – I expect it to be rectified ASAP.

The same goes for delivery of:

…of valuable software

Whatever the output is, it should be of value to the customer.

Let’s take a quick look at what we do in software organizations to determine what falls into the category this principle:

More of Less of
Understand (what generates value to customers) 

Learn (what makes value to customers)

Code (what makes value to customers)

Deliver (what makes value to customers)


Write specifications

Code (other or additional stuff)

Test (other or additional stuff)




Make generic/infrastructure/core solutions

Report progress

That is, there is more value on the left

’nuff said

What to do?

This whole principle leads to one major kind of action – simple to explain and extremely hard to master:

Reduce the WIP – Work In Progress.

That mandates to align on what people work on.

This can be working on the very same feature. But, more often, this means doing multiple things that all align to the same OITO. For example, running multiple experiments for a similar goal, or multiple product-teams working each on a different feature for a collaborative business goal, etc.

Other principles of the manifesto guide us how to do it.

But the Priority is – align our work on what the customers need and want, and work relentlessly to get it out as quickly and as frequently as you possibly can, while not disrupting the incremental value of the product or service.


Agile processes promote sustainable development – tl;dr

I recently published a blog post on Agile Manifesto tl;dr
One of my readers suggested I make it into a series, going through the agile manifesto principles. Great idea – I thought – where do I begin?
In the end I chose this one:

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Here’s why: If the Agile Manifesto is tl;dr for you, chances are you have no time to spend to read it thoroughly.
If that is the case, chances you are in, or en-route to, a state of burnout.
Not wishing to stress you out, but you should know that burnout can have catastrophic consequences:
The term burnout is borrowed from rocket technology. Yes, it’s rocket science, but you don’t have to be a rocket scientist to understand its implications.

What is Burnout?

Burnout rate is how fast a rocket is burning fuel. In normal rocket launch fuel burnout of one stage triggers separation and the start of the next launch stage. 
When, however, an airplane reaches burnout, people physically die. As in the Chapecoense Crash

In humans, burnout, or occupational burnout, is a condition in which a person is depleted of energy, efficacy and empathy. Since WHO’s ICD-10 (released 1994) and in more detail in ICD-11 (To be released 2022) Burnout is classified as a disease, although not a medical condition.

In medical care, burnout has been identified as a major problem. In “Physician Burnout: A Serious Symptom, But of What”, by JAMA, The Journal of American Medical Association, the authors conclude: ״The profession has violated the very way it has taught, and been taught, to approach the care of patients. The profession can and should do better.״

Why does this matter?

At the end of the day, a CEO cannot be held responsible for the well-being of each and every employee, right?
Not so.
In a “A Message To Our Fellow Health Care CEOs”, a consortium of CEOs of the leading U.S medical institutions say that “Physician Burnout Is A Public Health Crisis”. They concluded that:
“The consequences of physician burnout are significant, and threaten our U.S. health care system, including patient safety, quality of care, and health care costs. Costs are impacted by burnout in direct ways (e.g. turnover, early retirement, less than full time work) and indirect ways (e.g. poor quality , including medication and other errors, unnecessary testing and referrals, greater malpractice risk, and possibly higher hospital admissions/readmissions).” emphasis added.

Just substitute health-care with customer care, medication with h/w & cloud resources and hospital admissions with unplanned support calls. There is an almost 1:1 analogy to software development groups.
In Agile Manifesto speak that’s like saying that burnout eats all other principles for breakfast, leaving behind a mush of formerly brilliant employees and a trail of occupational-hazard lawsuits and other social benefit liabilities.

Note that the authors are not doctors or other medical practitioners. These are not CEOs of some dollar hungry, revenue driven institutions. These are the CEOs of the world’s forefront institutions of medical care: Mayo Clinic, Cleveland Clinic, Johns Hopkins, Duke University, etc. If you’re an executive of a medical-care organization, you cannot choose anything more prominent that one of these.

Imagine what Colombia’s football, journalism and national history would look like if flight 2933 would have taken off with enough fuel, and Chapecoense team would survive the flight? This specific flight would have been a non-event, just like any of the other ~100,000s commercial flights taking place every day.
But it didn’t. And as a direct result it crashed.

Back to the agile manifesto

Sustainable pace means that “The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” 
That is, you must refuel. Regularly.
Otherwise, the results may be catastrophic.

What is Sustainable Pace?

So far I’ve discussed unsustainable pace. 
What is the desired state? What is sustainable pace?
Think of the difference between commuting to work on a highly congested day, during a good flow of traffic and on Boxing Day.
When traffic is flowing you feel you’re making progress, it feels healthy.
On a highly congested day you feel stuck and frustrated.
And driving to work on Boxing Day you know you’ll be alone at work, under-energized.

A Sustainable Pace means you could work at this pace indefinitely – it’s not overly frustrating and it’s not below your skill-level. 
It’s just right, most of the time, as in 90% of the time.

What to do?

You don’t have to do anything. Quoting Prof. Deming: You don’t have to change. Survival is just an option.
If you do plan to change, here are some ideas what you can do to bring yourselves from a collision course towards burnout back to a state of sustainable pace:

  • Hang out with people who maintain a sustainable pace, and learn what they do. Copy their behaviors until you master them yourself. There is (almost) nothing more impactful than being “infected” by people who respect their right to be healthy
  • Ask people who maintain a sustainable pace how they do it? What do they practice daily to maintain that state?
  • Read The Four Fold Way by Angeles Arrien. Or better – listen to it
    Or read/listen to The Four Agreements.
    Or The Power of Now.
    Any book that helps you internalize the importance of being mindful.  
  • Practice mindfulness, meditation, Tai Chi or any activity that soothes and suits you to refuel your mental capacities
  • Under commit
  • You probably spend a lot of time in meeting.
    Read Don’t Just Do Something, Stand There by Marvin R. Weisbord and Sandra Janoff. In particular, pay attention to “Learn to say No, if you want Yes to mean anything”
    And then practice their teachings.
  • Find and develop your own path to sustainable pace

So before attending to any other principle of the agile manifesto:
If you don’t have the privilege to take the time to study what “sustainable pace” means, consider the alternative.


Agile Manifesto tl;dr

The Agile Manifesto, authored in 2001 by 17 prominent software practitioners, consists of 4 values and 12 principles.
Probably any introduction to agile refers to this document.
The manifesto consists of 267 words across two web pages.

That’s it.

And yet, as agile coaches, we sometimes encounter agile practitioners who are not well versed in the agile manifesto.
What follows is a simple practice to increase your familiarity with it.

Update: One of my readers suggested I turn this post into a series. Over the coming months I will publish more tl;dr posts around the agile manifesto and update here.

Not too long ago I ran an agile refresh workshop. 
Some participants raised an eyebrow as we walked through the principles of the manifesto. For some, this turned into a surprise during a follow-up dead-simple exercise that had them deepen into the principles in a way that they didn’t experience before.
Here’s the exercise:

  • Form small groups of 3-6 people
  • Pick one principle
  • Read it aloud
  • On an attribute scale, place two dots:
    a) where are we today? and
    b) where we wish to be in 12 weeks time
  • Individually write on sticky-notes what actions will bring you closer to the target state
  • Discuss these actions in the group
  • Choose 1-3 actions to take to your next iteration
  • If you’re part of a larger group, share your learning with the entire group

Typically participants tell me that they never had to focus intently on the manifesto like in this exercise.

At this specific workshop, one of the participants, an orthodox Jew, told me: I now know what’s wrong with Scrum and why people fail at implementing Scrum. The missing part is the equivalent of Amidah, or Shmoneh Esreh Prayer (Eighteen Prayer). During this prayer we verse the same prayer three times every day. As a youngster you don’t understand why. As you age, you begin to internalize the meaning of the text. What’s missing in Scrum is taking a principle of the manifesto every day and learning it in depth. This is the first time I really studied the text and its meaning after many years of practicing agile.

I am not sure about changing Scrum to include this practice. For sure, this person had a profound moment by deepening into the meaning of the agile manifesto.
Either way, the entire manifesto 267 words. It is not too long to read for virtually all people.

I think that if practitioners will take the manifesto to their retrospective from time to time, this alone can help a better understanding of the meaning of being agile.