Category: News

Pree: Lead time & Flow efficiency measures a system’s Efficiency – Not Effectiveness

Authored by Preetam De, June 19, 2018, a blogagility.com contributing author.

X: We have to improve our Flow efficiency & Lead time.

Me: How come? Our Flow efficiency is around 50% which is actually better than most development teams.

X: Yes it’s above average but still not reflecting on the revenue though. We need to improve it even more, some even have 80% which I think we need.

Me: I have my doubts. We have made the system as lean as we could. If we push too hard, we will start hitting bottlenecks. Also we are not a manufacturing company so we have no choice but to keep experimenting new features.

Neither of us above were totally wrong. We simply had different opinions towards what was important for the business under discussion. “Business” – what kind and why it exists is very important here. Not all businesses can achieve high flow efficiency as they have to experiment too much and fail many times to understand the end user’s real problem. Value is what we want to focus on. To make sense of this article let me define what efficient and effective means to me: Continue reading “Pree: Lead time & Flow efficiency measures a system’s Efficiency – Not Effectiveness”

Advertisements

Self-Organization with Children

Have you ever been self-managed/organized at a pick-up game at the schoolyard when you were a kid? Basketball? Baseball? Football? Soccer? Dungeons and Dragons (j/k)?

We train our kids to do this…and they are really good at it, and they accomplish it mostly in an objective manner. e.g. – I’m a big guy, 6’3″, and so I was always picked right after the really fast smaller guys depending on the sport.

Yet somehow when we become adults…we need other adults to tell us which team to play on?

#agile #scrum #SAFe #selforganization #selfmanagement #sensemaking

The Knowledge Worker Factory

Does it really exist?

Or are we still working in the blacksmith shop? Will it take AI to bridge the gap?

In Lean manufacturing companies that build physical things have been able to improve quality consistently and dramatically since the dawn of the industrial age.

Here many of us are in the post-industrial, Information Technology or Digital Age.

When we change the channel to knowledge work, companies struggle mightily to match the pace of quality and outcomes of physical manufacturers, even to this day. Why?

XP, Agile, Scrum, DEVOPS, Kanban for Software, Scaling Frameworks

Are these practices, methods, frameworks, and guidance really helping the knowledge worker factory catch up with companies that make physical things? Perhaps there is some evidence to support the claim. Continue reading “The Knowledge Worker Factory”

Sticker Face

Certifications and Sticker Face. This is an important topic for our industry. My intent is to deliver this respectfully with a goal of driving more robust solutions in the marketplace. Continue reading “Sticker Face”

Lean-Agile Team Metrics Starter Kit

The fourth tool created to date by blogagility.com for the community!

This handy starter kit is for Scrum masters that are using the Shu Ha Ri paradigm for team development. Good coaches help new teams avoid the pitfalls of added complexity involved in “Agile Lifecycle Management Tools” and instead push for good old-fashioned manual BVIR’s, Kanbans, Scrum boards, et cetera. Change is hard enough in a CAS without adding to the problem by also complicating the way of working. Continue reading “Lean-Agile Team Metrics Starter Kit”

Michael Küsters : Things that never meant what we understood

Reblogged with permission from , the original author of
 this content. Originally published on his blog Fail Fast, Move On, June 2, 2018.

We throw around a lot of terminology – yet we may not even know what we’re saying. Here are three terms that you may have understood differently from how the original author’s intention:

1. Technical debt

Technical debt has been used by many to denote willfully taken shortcuts on quality.
Many developers use the term to imply that code has been developed with poor craftsmanship – for instance, lack of tests or overly complicated structure. Continue reading “Michael Küsters : Things that never meant what we understood”