Thursday, December 19, 2013

Asking the Wrong Questions

Bridging two worlds is not easy. See if you can spot the non-agile assumptions in all of these questions:

  1. You find one team is only meeting schedules and pleasing customers because they have been padding schedules and cutting scope. How can you get them to plan and execute more aggressively? 
  2. One of your teams is hogging some of the QA resources full-time, and have been since the start of the project. How do you ensure you'll have a full complement of testers for your other team's testing phase? 
  3. One of your teams has stopped turning in estimates and long-range plans. They seem to be producing well enough, but how do you reign in their manager without hurting productivity? 
  4. Of your two teams, one group works overtime and weekends but the other refuses to stay late even during mid-week days. You have many projects in the pipeline. How do motivate those clock-watchers? 
  5. Your team has severe technical problems, but instead of keeping their nose to the grindstone, they have begun taking walks, working two-to-a-terminal, and going home by 6 in the evening. How can you give them a stronger sense of crisis? 
  6. Your new manager wants to accelerate delivery on all products. Of you teams, one of them has not taken advantage of the open headcount reqs. Why do they refuse to ramp up their productivity? 
  7. One of your subordinate managers has not submitted the name of a team member for recognition. You take rewards and morale very seriously, so how can you get the manager to step up? 
  8. One of your teams has only started a few project tasks, not even one task per team member. You see the team members sitting and talking and drawing pictures instead of typing. How do you get their backsides in gear? 
  9. You've noticed that almost half the team members on one team are seldom in their own cubes. How can you give them focus? 
  10. You've seated people in "pods" or "work spaces" as required by your agile coach. One team seems to have a lot of conversations and meetings, and it is disturbing people working in neighboring pods who are trying to get their own work done. How do you get the team to quiet down and write code? 
  11. Much of your "agile" team's project work is not even estimated. How do you know when they'll have their product completed? 
  12. It old days, if you said "we need X" the team would stay nights and weekends to make it happen. Now they seem to be working 40 or 50 hours a week and never jump to meet your needs anymore. How can you restore the relationship you had with them before? 
  13. Even when the team was "busy," you could always get work done by taking it to Mike or Tracy. However, now the manager of that team insists that all work assignment goes through her. This often puts your work lower on the priority chain. How can you go around the manager without getting Tracy or Mike in trouble?
  14. While the team is making their dates and have a surprisingly low defect density, you've recently found out that they're producing an average of 25 lines of code per developer per week (and sometimes negative) while other teams have 100s of lines of code per week. How can you get this team to ratchet up their output to standard levels? 
  15. You're told that all the teams need start doing "agile." However, your chosen consultants seem reluctant to take on a standard contract with you. They say that they would rather contract in some kind of pay-as-you-go plan with reassessment points at ridiculously frequent intervals. How can you get them to understand the realities of your budgeting process? 

We "old hands" at agile methods see this list of questions as obvious examples of wrong thinking about modern software process. 

We can forget that shift from the old mindset to a modern agile mindset is quite a difficult change. 

Most of us who are over 30 and in the Agile camps have done exactly that. As an official greybeard I remember the "bad old days" quite well, and as a consultant I see that we have not escaped the reach of the mainstream control-driven processes of the 80s and 90s yet.

We forget that others still work in a different world. They're successful survivors and many of them are still climbing a corporate ladder that hasn't become agile in any appreciable way.

We have to beware of telling them things that they can't hear; things that don't fit into the worldview they currently own; a world view which has been validated on a daily basis for a few decades.

Managers are being asked to deprecate the very model under which they have become successful. 
Remember these are some of the smartest people around. They think for a living. Don't even pretend they're not savvy and smart and ambitious and competent. Some of the most brilliant people I know are managers who have earned their place in their organization.

But these questions are "the wrong questions."

If they sound like reasonable questions to you, why not drop me a line? I would love a conversation with you.








Tuesday, December 17, 2013

Parkinson's Law:

We all have a convenient form of Parkinson's law.
"Work expands so as to fill the time available for its completion."
People have suggested many reasons for this:

  • People with long schedules are less careful and have more errors to fix.
  • Work seldom is given half-enough time, so it expands rather readily.
  • The longer a project goes on, the more new ideas/features get incorporated into it.
  • If a project goes on long enough, it is punished and slowed by having people added to it.
  • People are lazy and will always slow their pace if not held to task.
  • People are creative enough that they can always find a way to achieve a task faster when required to do so.
  • People will continue polishing and improving the product indefinitely.
  • "Art is never finished; only abandoned." - Da Vinci
Of these, the one most commonly heard is the one about people being lazy. 

I suppose it might possibly be true if you're painting walls and are being paid by-the-hour, or if you're being paid by-the-word to write a novel. I know my kids are never in a hurry to do unpaid work for their parents (and I was the same way).

Even then, if you are paid by the job you have a built-in incentive to complete well and move on. My kids could be happier if they would fold laundry in 5 minutes instead of 25, because they could go on to watch tv or play video games or maybe wrestle or slap box each other. It isn't always about money.

But people who think for a living, programmers and managers and authors and consultants, tend to really like working. Even when they're not "working" they are introspecting, remembering, processing, pattern-matching, reading and studying, discussing, and obsessing on their work. Time not on billable work is the time they have to process what they've been doing and look for new ways to achieve the same results. Sometimes it's time to look for signs that their personal theory of work is flawed so that they can research the behavioral or technical laws they've transgressed. 

But there is one other feature of thinking for a living that needs to be considered: it's exhausting in a non-physical way. It drains us emotionally and mentally. 

There is significant work on decision fatigue, ego depletion, and other kinds of mental fatigue. It is usually cured by a bit of exercise, a change of topic to let the brain rebound, a bit of rest, or even by time alone with music or a good book.

Sometimes, when given a slightly relaxed schedule, the knowledge worker's brain sees the chance to recover. It can be deucedly hard to force it to operate optimally when it is trying to recover. This can be misdiagnosed quite easily.

If the schedule is tight (a constant sense of crisis) then it manifests in stress and can have rather more serious physical, mental, and social consequences.  There is a reason that many consultants deal with alcoholism, divorce, and digestive disorders. It's not *most* consultants, but it's not unusual. 

At Industrial Logic, we identify overburden as one of the rampant wastes in software processes. It might be that the answer is not to work faster all the time, but to consider the mental states and pace of operation that bring us to our peak. 

An agile trick here is to build software in thin, vertical slices instead of all-or-nothing dives into architectural layers. By building a little bit that works, and doing it quickly, we are letting our mental muscle rebound more. Sometimes we forget, and do work in big, stressful steps. It doesn't go any faster, and leaves us less brainpower to think with on the other side.

The other thing we have learned is to monitor our own cognitive state and stop working when we start to detect a creeping inability to engage successfully in our work. There are times to simply "muscle through" but we know that if we're always exhausted we won't be read when those times come.

And with that note, I drop off for the night.

What do you think Parkinson's Law teaches us? Why do projects expand? What is the answer?