Tag: agile (page 1 of 2)

Kanban > Scrum

I spend most of my time coordinating with one other human being at work. After that, I’m coordinating with a maximum of three other people internally, and then with clients.

So take what I’ve got to say about Kanban with a pinch of salt. But I’ve worked at bigger organisations, with more fancy methodologies. Still, nothing beats having a board which shows what’s to do, doing, and done (with some tweaks perhaps for ‘feedback needed’ and ‘undead’!)

Kanban board

I’m not saying Scrum doesn’t work. I’m saying the exact opposite. Scrum does work, but it works for the same reasons Kanban does. The difference between them is that Scrum is slower and more prescriptive, and thus less adaptable (or “agile”, whatever you wanna call it).


[B]ecause Kanban focuses on tasks rather than sprint-sized batches, it pushes responsibility to the edges of the team, meaning engineers are responsible for going after the pieces of information they need to move forward.

When that happens, instead of designing features by committee, which demands a significant amount of back-and-forth discussions, decisions happen locally, and thus are easier to make.

Additionally, fewer people making decisions lead to fewer assumptions. Fewer assumptions, in turn, lead to shipping smaller pieces of software more quickly, allowing teams to truncate bad paths earlier.

Source: You don’t need Scrum. You just need to do Kanban right. | Lucas F. Costa

Image: Visual Thinkery for WAO

‘Even over’ statements

Aaron Hirtenstein mentioned this post to me earlier in the week, thinking that it might be useful for a collaborative project on which we’re working.

The idea is to try and prioritise one good thing over another and, as such, seems to be influenced by the Manifesto for Agile Software Development.

[I]f everything is a priority, nothing is priority. As you’ve no doubt found from your own experience, the “we can have it all” mindset fails frequently as we repeatedly come up short trying to be the best at everything.A better approach is to make trade-offs explicit, by choosing one thing over another thing. Done well, it will result in focus, clarity, alignment, better decision-making, and competitive edge. We want to share with you a practical method that we often use with our clients: the even over statement.


An even over statement is a phrase containing two positive things, where the former is prioritized over the latter.


Here are a few examples:

Product tradeoffs
Exclusive product line even over mass market adoption
Amazing customer service even over new product features
Mobile experience even over desktop experience
Revenue growth even over user growth

Culture tradeoffs
Collaboration even over focus
Progress even over perfection
Honest feedback even over harmony
Impact even over following a plan
Quality even over volume
Hiring team players even over deep experts

Source: Even over statements: The prioritization tool that brings your strategy to life | Jurriaan Kamer

Conceptual integrity

As a project manager, as a product manager, and as a consultant, the thing that often frustrates me is the desire to go full steam ahead without a shared understanding of what it actually is that we’re supposed to be doing.

Dorian Taylor, in a wider-ranging piece about Agile, talks about this as conceptual integrity:

The one idea from the 1970s most conspicuously absent from Agile discourse is conceptual integrity. This—another contribution from Brooks—is roughly the state of having a unified mental model of both the project and the user, shared among all members of the team. Conceptual integrity makes the product both easier to develop and easier to use, because this integrity is communicated to both the development team and the user, through the product.

Without conceptual integrity, Brooks said, there will be as many mental models as there are people on the team. This state of affairs requires somebody to have the final say on strategic decisions. It furthermore requires this person to have diverse enough expertise to mentally circumscribe—and thus have a vision for—the entire project in every way that was important, even if not precisely down to the last line of code.

Source: Agile as Trauma | dorian taylor