Archive for the ‘management’ Category

Set The Price, Or Ask For An Estimate?

January 21, 2017 1 comment

This tweet from a #NoEstimates advocate is interesting food for thought:


Let’s say you are one member of a software development team of 5, and each of your salaries is $100K per year. Now, assume that an executive in your org requests that your team build software product “WhizzBang” for $500K. If your team accepts the request, then your deadline date becomes automatically set in stone as one year from the selection date. If you don’t accept the request…. well, then you and your teammates should look for other work.

An alternative approach for getting “WhizzBang” built is for the executive to ask the team for an estimate of how long it will take to get the software built.

I, as a software developer, would prefer the bidirectional “asking for an estimate” approach rather than the unidirectional “setting of a price” approach. Neither approach is ideal, but the “asking for an estimate” approach gives me the opportunity to provide information to the executive that allows him/her to decide whether or not to move forward on his investment.

In either case, history sadly shows that neither approach is likely to lead to the derived deadline being met. In those cases where the deadline is met, the team has most likely worked tons of unpaid overtime over a sustained period of time and has cut quality corners to do so 😦


Categories: management Tags:

How Agile Are You?

December 11, 2016 Leave a comment

Follow this scientifically proven method to measure how “agile” your organization really is:

  1. Printout a boatload of copies of the Agile checklist below and hand them out to all the engineers, managers, and executives in your organization
  2. Tally the results
  3. Report your findings back here


My speculative guess is that the results you get from the management/executive group will not align with the results you tally from the engineering group. However, I’ll never know if I’m on the right track if you don’t communicate your results back to me.

For the newly initiated, here’s how the Agile Checklist (patent pending!) was meticulously developed:


You Have Just Crossed Over Into…

November 10, 2016 Leave a comment

Assume that you’re actively working on a successful software development project before the Agile manifesto was created/signed and before Scrum was formally defined by Sutherland/Schwaber. The timeline and parameters of your project may look like this:


The number of managers and developers involved in the day-to-day work is most likely fixed and no executives directly meddle with the team’s internal affairs. In addition, the average number of hours worked per week per team member and the average stress level felt by the team is most likely constant. Most importantly, status reviews aren’t conducted on a daily basis. Once or twice a week is the norm. Because of the lack of a mandated daily status meeting, some healthy slack is available to the team for learning and doing things directly applicable to the project but not enumerated on the schedule/backlog. All is well, a healthy and sustainable pace is being maintained.


Now, imagine that at some point in the future of the project, someone in the executive suite decides (either rationally o irrationally) that the project is either behind schedule or over budget or, most likely, both. When that fateful day arrives, you will be suddenly transported into…. The Micromanagement Zone (TMZ):


The project timeline will most likely transition to this:


The consequences of transitioning into TMZ are never good for anyone involved (developers, managers, executives, customers):

  • The frequency of status meetings will rise – most likely to at least one per day.
  • The number of managers assigned to “oversee” the project will rise.
  • One or more executives will get intimately involved in the day-to-day execution of the project.
  • Some additional number of newbie developers may be suddenly injected into the team, bringing progress to a crawl.
  • The number of hours worked per week per developer will rise.
  • Sustainable pace” will never be uttered again. The workaholics on the team will brag about toiling late into the night and on weekends.
  • The average stress level will rise and the average physical health of the team will deteriorate.

The worst thing about entering TMZ is that it’s like a black hole: once you’re in, you can never escape. Well, that’s not quite true. You can leave of your own free will or the project may get cancelled.

So, how does Agile and/or Scrum solve this stubbornly entrenched and globally ubiquitous MZ problem? It doesn’t. In fact, every Agile/Scrum project is poised from the get-go to glide into the MZ as soon as the project is “deemed in trouble“. The fact that daily status meetings (promoted innocently in the Agile world as informally loose “standup” meetings) are required from day one points every Agile project directly toward the MZ abyss – all signed up and ready to jump. In the pre-agile days, daily status meetings were only initiated after the project was deemed in trouble, they weren’t required from day one.

The agile folks will say that the purpose of the daily standup meeting is to provide early warning detection of a project that is heading for trouble – and they can be right. They’ll also say that early detection will allow actions to be taken to get the project back on track – and they can be right. However, the specific “actions” taken to reign in the project may actually be those that will thrust the project squarely into the MZ .


Explaining Vs Training

November 8, 2016 Leave a comment

I haven’t ranted against the software con$ultant industry in a while, so I decided that now is as good as ever to do it again. To that end, I submit Twitter exhibit A to the jury:


I guess that “explaining” how to do a stand up meeting to executives in which 3 simple questions are asked/answered only takes 5 minutes, but “training” them how to do it takes an intensive, four day on-site course at $2K  per day… plus expenses.

As a general observation, consultants love to make the obvious and mundane look like a complicated and unfathomable hairball that only they can unravel for you, at a “fair” price.


Categories: management Tags:

The Reverse Butterfly Effect

November 2, 2016 Leave a comment

Lipstick On A Pig?

October 29, 2016 Leave a comment

Since the anecdotal evidence that I’ve seen over the years is overwhelming, I have absolutely no doubt that when Scrum is applied in the right context (e.g. small projects in unregulated industries), it works well for both managers and developers. However, when Scrum is either not applicable, or, more likely, starts out well and then degenerates over time into a textbook case of micromanagement, it reminds me of the lipstick-on-a-pig metaphor. When that perverse inversion occurs, the management team walks around touting “we’re agile“, and the development team simply….. walks around.


From Daily Standup To Daily Inquisition

September 23, 2016 4 comments
Categories: management Tags: ,

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:


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


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


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.

A Loss Of Heart

%d bloggers like this: