Acareability™... a combination of "Accountability" and "Care"

How to become Agile

You don't install Agile. You grow it — from where you already are.

Step zero: write down how you actually work today

Do not discard what is working in favor of an externally defined methodology. But do define in writing what is working before you decide to keep it as permanent groundwork. Your current state is, at its heart, a workflow. It may be Agile, Waterfall, entropic, or chaotic. If it is not defined, it is more likely to be the latter.

A starter hybrid that respects your culture

Adopt only what makes sense to your team. The following is an example to start a dialog — four simple elements that begin a journey of being Agile:

1. Commitment to iterative improvement. This is as simple as the majority of the team saying "yeah, that makes sense to me."
2. A weekly Kanban meeting. Everybody speaks for 2–3 minutes to their card(s). Cards should move.
3. Two-week sprints. Sprints deliver value (often, but not always, releases). I hold a firm opinion that sprints must be distinct from the week — weeks are habitual; sprints are considered deliverables of value.
4. The daily stand-up — with alternatives. Recognize its value, but many teams resist a daily meeting. Fair enough: invent your own alternative. Meet less frequently, let sub-groups fold the check-in into other team meetings, or use posts in a team channel visible to all stakeholders.

Within one year there are two dozen sprinted moments where the team celebrates delivered value — and countless moments where friction is named and the process improves, assuming people are paying attention and know how to solve problems. Managers begin to step back and let the people doing the work self-organize and make their work visible.

What a Kanban meeting asks

· What work is in progress, and is anything blocked?
· Are we maintaining a steady flow, or are there bottlenecks?
· Are we prioritizing tasks correctly and meeting commitments?
· How can we improve our process to increase efficiency?

Process vs. framework — and why it matters

Kanban is a process. There is no single "right" way to do Kanban. If you have visible cards, defined processes, and meet regularly to discuss and improve your work, then you are part of a Kanban process.

Scrum is a framework. There are a limited number of ways to do Scrum correctly — and many ways to do it incorrectly. If you are not following most of its defined practices, you are most likely not doing Scrum. That is fine. Grow what's real rather than performing what's prescribed.

The honest criticisms

"Faux-agile." Martin Fowler, one of the Manifesto's authors, criticizes the "Agile Industrial Complex" — imposing methods upon people, contrary to the very first value: individuals and interactions over processes and tools. The people doing the work should decide how the work is done.

The meeting load. Follow the full Scrum methodology by the book and a two-person-week sprint carries something like this ceremony schedule:

CeremonyPurposeHours/Sprint
Sprint PlanningDefine sprint work and goal4
Daily ScrumSync progress and remove blockers2.5
Sprint ReviewDemonstrate completed work, gather feedback2
Sprint RetrospectiveIdentify improvements for next sprint2
Backlog RefinementMaintain and prioritize backlog items1

That is roughly 11.5 hours of ceremony per sprint. Frankly, this needs a serious Kaizen for muda — waste. It is not aligned with the original spirit of Kanban. Adopt ceremonies because they serve your team, not because a book says so.

Distributed teams. A systematic review found that distributed Scrum has no impact — positive or negative — on overall project success. The practices don't carry the culture by themselves; people do.

What it all serves

The goal was never the board or the stand-up. It is work that feels like Flow — deep, effortless immersion where challenge and skill balance. My twelve years at Jostle and years before at Creo/Kodak convinced me that four perceptions of work matter most:

Autonomy · Mastery · Liking the people you work with · Knowing what you do is important

A simple hypothesis with significant evidence behind it: when you combine Kanban in a supportive environment — where all team members speak to their efforts in turning work into value — with effective team leads holding direct-report one-on-one meetings, a culture exists to unlock the hardest elements of flow: autonomy and mastery. Happy people do good work, and good work makes people happy.

← Back to Home

Connect on LinkedIn