The figure below shows a series of “Grow And Fix” (GAF) cycles that models a software development effort. The gaps between each cycle represent external (to the team) deployment/usage/feedback periods. In practice, there usually are no gaps. After all, any upstanding org filled with managers who are paid to obsess over efficiency can’t allow for any idle machines between incremental releases.
Note that in the GAF way of doing things, the duration for producing a stand-alone increment varies from increment to increment. That’s because the GAF community thinks the act of arbitrarily setting T1 == T2 == T3 == T4 == T (like, say, T == 30 days) for every major increment is a pretty much stupid and dogmatic policy. As stated in the 16 page GAF user guide, the duration for each release is proportional to the breadth and depth of the functionality (f1, f2…. fx) allocated to the release.
In addition to the effort required for defining, creating and integrating new functionality into the growing system, the GAF method takes into account the effort required to “unbreak” existing functionality and to handle emergent, unexpected, behaviors that arise from function-to-function interactions (fix(f1,f2), fix(f1,f3)…).
For more detailed information on the groundbreaking new GAF methodology, including real success stories, endorsements, certification costs, books, T-shirts, hoodies, mugs, and upcoming community conferences, visit the GAF website. Enter the code BD00 at checkout to receive a 10% discount and free shipping on your first purchase.
In six years of blogging, I’ve never reblogged a post… until now. I don’t agree with every point made in this insightful rant, and I outright disagree with several of them, but I resonate with many of the others via direct personal experience.
Originally posted on Michael O. Church:
Follow-up post: here
It’s probably not a secret that I dislike the “Agile” fad that has infested programming. One of the worst varieties of it, Scrum, is a nightmare that I’ve seen actually kill companies. By “kill” I don’t mean “the culture wasn’t as good afterward”; I mean a drop in the stock’s value of more than 85 percent. This shit is toxic and it needs to die yesterday. For those unfamiliar, let’s first define our terms. Then I’ll get into why this stuff is terrible and often detrimental to actual agility. Then I’ll discuss a single, temporary use case under which “Agile” development actually is a good idea, and from there explain why it is so harmful as a permanent arrangement.
So what is Agile?
The “Agile” fad grew up in web consulting, where it had a certain amount of value: when dealing with finicky clients who don’t…
View original 3,303 more words
Agile, Traditional, Lean, Burndown Charts, Kanban Boards, Earned Value Management Metrics, Code Coverage, Static Code Analysis, Coaches, Consultants, Daily Standup Meetings, Weekly Sit Down Meetings, Periodic Program/Project Reviews. All the shit managers obsess over doesn’t matter. It’s all about that Jell, ’bout that jell, ’bout that jell.
First, we have VCID:
In VCID mode, we iteratively define, at a coarse level of granularity, what the Domain-Specific Architecture (DSA) is and what the revenue-generating portfolio of Apps that we’ll be developing are.
Next up, we have ACID:
In ACID mode, we’ll iteratively define, at at finer level of detail, what each of our Apps will do for our customers and the components that will comprise each App.
Then, we have SCID, where we iteratively cut real App & DSA code and implement per-App stories/use cases/functions:
But STOP! Unlike the previous paragraphs imply, the “CID”s shouldn’t be managed as a sequential, three step, waterfall execution from the abstract world of concepts to the real world of concrete code. If so, your work is perhaps doomed. The CIDs should inform each other. When work in one CID exposes an error(s) in another CID, a transition into the flawed CID state should be executed to repair the error(s).
Managed correctly, your product development system becomes a dynamically executing, inter-coupled, set of operating states with error-correcting feedback loops that steer the system toward its goal of providing value to your customers and profits to your coffers.
I recently posted a tidbit on Twitter which I thought was benignly unassailable:
Of course, Twitter being Twitter, I was wrong – and that’s one of the reasons why I love (and hate) Twitter. When your head gets too inflated, Twitter can deflate it as fast as a pin pops a balloon.