reviewing an old case study of mine where I used lean (not Kanban or Scrum to solve a problem). It occurred to me that had I known Kanban at the time I would have tried that and not gotten a good solution that coming from scratch, not preset, et me get a better solution. 1/
i can see a high level way of navigating can be good. Not unlike the DIsciplined Agile Lifecycles.
3/3
just jotting down some ideas on twitter for a blog.
When designing a future value stream (or most any design) constraints are good. But they must be the right constraints. Scrum/Kanban/etc. are patterns. they are solutions. They should not be your constraints to thinking. 3/
see Framework Tunnel Visionhttps://www.linkedin.com/pulse/framework-tunnel-vision-al-shalloway/
thinking of these two and making a hybrid leaves a lot out. must come from the foundation - lean/flow/ToC when they don't fit. 4/4
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Iterations are fine within Lean thinking if doing so reduces delays and is the best way to manage queues. But any approach where iterations are an end goal is not based on lean.
You don’t measure if you’re doing Lean by if you’re doing a practice. You see if you’re doing lean by the frequency of your learning opportunities. Whatever speeds up learning is almost certainly Lean.
Icebergs in a river improves flow the way immutable practices improve effectiveness – they don’t. We need flow of ideas for improvement as much as we need flow of work. While constraints in our design process are useful, constraints in our implementation limits innovation.
@AgileCabane this is a common anti-pattern- ppl attending to their performance & not the overall flow. It's a common challenge with any team-centric approach. You need to cultivate a entire value stream perspective.
1/
And, for all the focus on "self-organization" it doesn't apply when that impedes overall value delivery.
2/
@AgileCabane self-organization, btw, is not why scrum works (see Challenging Why (not if) Scrum Workshttps://bit.ly/36XWW1g )
it's eliminating delays, handoffs and handbacks. ber
3/
in the implicit vs explicit agreement discussion, it should be mentioned that implicit does not really mean you can not follow an agreement when it doesn't make sense while explicit means you must. You can just add to your explicit agreement - only do this when it makes sense. 1/
you might also add "when you don't do it, let someone know because it might make sense to improve the agreement."
Implicit merely means we've not explicitly discussed what we're doing. Why would you not want to explicitly state the groundrules of you working together? 2/
the idea that explicit means written down or hard to change is one of the great misunderstandings of Kanban still in the Scrum community. Explicitly stating how a team works together is one of the cornerstones of Lean. 3/
i love it when i find the integration process of DA with FLEX finds errors (yes, something wrong) in FLEX and not just improvements to it. Finding what's wrong with your approach is something to look at.
1/
I tend to think of DA FLEX like I would a service. When I tell a service provider something's wrong I expect them to listen and say "oh, we'll fix that. Thanks for your input." 2/
I don't expect them to tell me "ah, you're just bashing." Or, "well we could do that, but then it wouldn't be our service."
The first means that they're not listening, the 2nd means i should look for another provider.
When you hear people tout the simplicity of an approach, it is often an indication that they've lost sight of the goal - the effectiveness of the approach.
how something is defined and how something is used may be quite different 1/2
Things often start simple (1 gear car), turn more complicated (multiple gears), then become simple to use (automatic transmission).
Use a DA consultant to help you figure out what's simple for you. Then use that. A little foresight goes a long way. 2/3
Maybe the understanding in "simple to understand, difficult to master" is the wrong understanding. We need to understand what works for us. Then it's not so difficult. Choice is power. Choice is fit for purpose.
3/3
when your problem is simple, basing a solution on specific practices may work. But when the problem is complex, more of a thinking and education approach is required.
our approaches should be about teaching us how to improve our results. Not presume following them provides us good results.
in '00 a framework within which to figure out what to do made sense because we didn't understand the theories under software development. Now we do. Using those theories directly is more effective. You can start with a set of often useful practices if you want to. then adjust