Sounds like a very interesting paper, would love to read it.

I ran across this post and it smells alot like what I advocated and deployed back in 2000 for a large Japanese systems integrator for the re-engineering of the Japanese Banking System. Again – $160M+ efforts do exist and seem to be a challenge for prima-facia Agile approaches. I have recently written a paper focused on the importance of going beyond the physical form of Kanban boards and leveraging common workflow technologies (that is currently creating the ALM buzz, whether it be based on the Jazz platform, or VSTS); my thought (and a point in my paper I try to make) is that form follows function, and that abstracting Kanban yields a nested state machine – a common pattern for workflow`. My concern has always been purists trying to spin their wares without understanding the core abstractions and principles behind these (somewhat) longstanding practices. I have seen some Agile purists being closed-minded to the management science behind flow and pull. My paper is titled Applying Lean Manufacturing and JIT to Software Product Maintenance. I then discovered (after the fact) that David Anderson wrote about this very topic back around the same time, but again leveraging the same physical form. I’m thinking that for reasons you describe above related to branching complexities, the industry and perhaps the Agile community needs to move beyond the “tool is a four letter word” idea and explore what “Digital Kanban” really means. Would love to share the thoughts I have packaged in my paper as they seem to be quite consistent with what you have been advocating for what looks like the past while. And some feedback would be great.

Cheers.

Great questions as always. Part of the value of MMFs is exactly that they can vary in size. Then it follows that you can use story count as a measure of size.

Now, given the chance, I prefer using a method like QFD for requirements definition. However not everybody is up to that level, so MMFs and stories are a reasonable backup method for existing Agile or other medium-capability teams.

it’s a long time I want to ask you something about MMF.
It looks like there isn’t a standard definition of MMF, expect the one that one can find in the software by numbers book that I haven’t read yet.
You write: MMFs are business-valued. User stories are merely user-valued.
And it looks like that in your case you use feature crew MMF that you split into user stories (maybe developed by one member only?) and you don’t use tasks. This is a vision that I actually share with you.
Some people though say that MMF are actually user stories, like here: http://aaron.sanders.name/agil.....-the-small .
Now let’s say that one uses the method he likes most, that in your case, if I got correctly, you use MMF split into user stories. In this case you told me that is better to try to create equal-size stories, if this is possible, is it possible to estimate the MMF size in terms of number of user stories or you think even the MMF must be equal sized?
About the branching, I agree with Brad, I think it’s better to branch by user stories, at least this is what I have done succesfully so far, even if I can understand your point of view.
Thanks for your replies

I can say that “branch by feature” only works well if you get REALLY good at making MMFs as small and minimal as humanly feasible. The longer your features branches go without being integrated with “the other stuff” the more integration complexity you are risking.

If MMFs can’t be kept down to a certain threshold size/duration, then it actually starts to make sense to integrate them anyway to avoid the impending “big bang!” at the end.

How do you do that? Well, you can create a “pre-integration” branch that integrates the features and makes sure they all build+test okay, but no one is allowed to base their changes off that branch (and if they fix any problems, they have to find a way to fix it on the feature-specific branch so that it still works there AND on the pre-integration branch.) This may not always be feasible.

Another way that is no small task but also can have big payoff is solving your problem by a means other than branching, specifically in the architecture and design of the interaction/impacts between features.

This often takes the from of build-time, install/deploy-time, or run-time configuration that can enable/disable features while still allowing you to integrate the code. This can be very hard to do, even though it can pay big dividends in the long run.

The simplest solution is to keep the MMFs “sufficiently small” (e.g, anything that goes more than #N weeks before being integrated to mainline is quite likely a significant risk. A typical range for N here would be 2-6, with 4-5 being very common.)

Just make sure folks understand that branch-by-feature-and-don’t-integrate-until-its-complete isn’t necessarily all that desirable unless the features are *minimal* sized.

If you have any ideas, or can bust any holes in the process, I invite your input!

I experience something close to this in a hybrid Agile approach. No one knew about feature crews, but the result was sub teams organized around feature completion and integration of results in an iterative process.

Nice to see a relationship to Kanban too.