Archive

Posts Tagged ‘project management’

Perfect And Real

July 9, 2016 2 comments

In the perfect Scrum world, software is developed over time in fixed-size (ΔT) time boxes where all the work planned for the sprint is completed within the timebox. Typically ΔT is chosen to be 2 or 4 weeks.

perfect scrum

If all the tasks allocated to a sprint during the planning meeting are accurately estimated (which never happens), and all the tasks are independent (which never happens), and any developer can perform any task at the same efficiency as any other developer (which never happens), then bingo – we have a perfect Scrum world.

However, in the real world (Scrum or non-Scrum), some (most?) tasks are interdependent, some tasks are underestimated, and some tasks are overestimated:

Real Scrum

Thus, specifying a fixed ΔT timebox size for every single sprint throughout the effort may not be a wise decision. Or is it?

Categories: management Tags: ,

Front And Back


In response to my previous post, Glen Alleman pointed out that for large system development projects, the technical plan must be preceded by a higher level, coarser, activity. Glen is right.

Senior analysts and architects don’t just sit down and start designing the technical plan from scratch. They work with experienced, knowledgeable customers to develop, define, and document the capabilities that the system must satisfy in order to solve their problem. Thus, I’ve augmented my diagram to show this important activity:

FrontAndBack

We’re not done yet. There is still (at least) one more front end activity missing from the diagram: the problem definition phase:

ProblemDefinition

So, what precedes the problem definition phase? The pain of problem discovery….

ProblemDiscovery

The Agile community does a great job of defining how the back end should be managed for cost-effective product development, but IMO they are mostly silent on the much-more-important, fuzzy, front end.

What Happened Before The First Product Backlog?


Some people like to ask: “What happened before the big bang?“. Being a geeko-nerd, I like to ask: “What happened before the first product backlog?”.

The missing artifact

Regarding agile framework definitions, IMO, Scrum has the most well-documented and coherent definition of the bunch. However, since it remains silent on the issue, I still wonder: “WTF happens before the first product backlog?”.

For innately complex systems requiring a large amount of coordinated effort, here’s what I think should happen:

  • A small group of senior domain analysts and system architects should spend a fair amount of un-pressured time to develop and document the high level, technical blueprints (structures + behaviors) for what needs to be built.
  • The authoring group should disseminate and educate the rest of the development team on the technical vision.
  • The team should populate and iterate on the first version of the product backlog.
  • The team should decide on, and put in place, the development toolset and infrastructure that will be used to develop and test the system throughout the effort.
  • The team, including the technical authors, should start incrementally and iteratively building the system – revisiting/updating the plans/product backlog frequently when new knowledge is discovered as the project moves forward.

What do YOU think should happen before the first product backlog?

Checklist Of Maladies

April 11, 2016 Leave a comment

Since I can’t remember where I poached this “checklist of maladies” from, I can’t give any attribution to its creator(s). I’m sorry for that, but I wanted to share it anyway:

doing it wrong

I do, however, remember that the presenter was talking about agile processes gone awry.

It’s funny how these maladies have been around forever: pre-agile and post-agile. Resilient little cockroaches, no?

Categories: management Tags:

The Real And The FAKE

March 20, 2016 2 comments

Event Driven Behavior

February 21, 2016 2 comments

The Promotion Strategy

February 18, 2016 Leave a comment

On the left side of the following figure, we have a typical mega-project structure with a minimal Overhead-to-Production personnel ratio (O/P). If all goes well, the O/P ratio stays the same throughout the execution phase. However, if the originally planned schedule starts slipping, there’s a tendency of some orgs to unconsciously exacerbate the slippage. In order to reign in the slippage via exercising tighter control, the org “promotes” one or more senior personnel out of the realm of production and into the ranks of overhead to help things along.

moreoverhead

By executing the “promotion strategy“, the O/P ratio increases – which is never a good thing for profit margins. In addition, the remaining “unpromoted” senior + junior analysts and developers are left to pick up the work left behind by the newly minted overhead landlords.

So, if you’re in the uncomfortable position of being pressured to increase execution efficiency in order to pull in a slipping schedule, you might want to think twice about employing the “promotion strategy” to get things back on track.

The brilliant Fred Brooks famously stated something akin to “Adding people to a late project only makes it later“. In this infamous post, dimwit BD00 states that “Promoting personnel from production to overhead on a late project only makes it later“.

Follow

Get every new post delivered to your Inbox.

Join 668 other followers

%d bloggers like this: