Randy and the Seven Habits

Randy Pausch came up at work, and he wound up giving me good advice years ago, so I added that to the discussion; while it's on my mind, here goes.

His advice boiled down to:

• look at how you spend your time, and list it out.
• prioritize that list, based on how much you and your society gets out of it.
• start at the bottom, and start cutting.
• actively choose replacements that make future-you a better human being.
• include a balance of physical, emotional, and intellectual improvements.

It's project management of yourself, your skills, your happiness and your life.  You should be doing things that make you better, instead of things that simply pass the time, with the explicit bit that passing the time is occasionally the best thing you can do for yourself.

Randy religiously recommended Covey's "7 Habits of Highly Effective People", and had hundreds of copies in his office to give away to anyone willing to read it.  That said, it's a medium-length read, and the two minute summary might give you a good bit of insight.  Paraphrasing:

1. Be proactive about what you do with your time, and who you spend your time with.
2. Know your goals before you start working on them.
3. Take care of yourself before others; put first things first.
4. Always try to create situations where everyone wins.
5. Listen and understand before moving to action.
6. Good teams are more than the sum of their parts.
7. "Sharpen the saw".  This was the advice he gave me; actively manage your life.

I'm not a rabid fan of self help books, but as far as doing more with your life?  It was good advice; it let Randy accomplish quite a bit more, and I'd like to think it helped a ton of folks he shared it with.  On my end, it got me to actively recognize time-wasting activities that could be swapped with more productive things that made me at least equally happy; thanks, man.

Management Authority

One thing I've noticed over the years is the correlation of the effectiveness of a team and the source of authority of their management.

Software development teams managed by MBAs who have no hands-on experience writing software are hit and miss. If the managers are engaged and proactive, this often works really well, especially if the team is large; formal training in managing large projects is absolutely worthwhile, especially for being able to better peg far-off deadlines or complex integrations.

The problems can occur when management wants to go in a different direction than the coders believe is correct. Maybe it's a heavy lean towards new features (with too little maintenance), or it's time spent polishing, but not making the system more robus, or any number of things; management needs to have the team believing they're working on the most important part of the software for the business. (If that's improving reliability so that the coders aren't woken up at 4 AM on a page, that's what it takes to keep those coders coming in to work.)

Software development teams managed by software developers who willingly took a promotion away from development have a different set of benefits. It's often far easier for these managers to motivate the team; they have the same mental wiring for weighing rewards, and the same wiring for feeling good about building things in general. Teams follow these managers more easily.

Peter's Principle can bite a manager here; if they were a phenomenal coder promoted to their first level of incompetence, they could be a terrible manager, misprioritizing tasks and leading the team into a hole they're not going to escape.

Overall:
- If you have an MBA, realize that relating to the developers is important.
- Have a developer you check things by from time to time.
- If developers seem to be burning out, prioritize fixing the issue.
- A $100 cash bonus might go a lot less far in their heads than taking them out to a $50 dinner. *Ask*, and don't waste money.

- If you were a developer, realize that the developers don't always have the context of the big picture.
- Look longer term.
- Spend a bit of time reading up on what you don't know from experience.
- Gant charts and other management tools for long term goal prediction and managing complex integrations are always wrong... but you'll know you're wrong *sooner* than if you were flying without these.

Scrum

So, I've used Agile/Scrum in the past, but always in a development shop that had been on that methodology for awhile. My current team is adopting it mid-project, and the results are both promising and a learning experience.

Basically, there are a few key principles:

• Change is inevitable; accept that things will change, and that other things will have to.
  
• Communication is as important as documentation. 

Every project has a product owner; someone who makes decisions on what the product should do.  It might be the head of operations, maybe the head of sales, or maybe someone more general.

The business owner creates and keeps a project backlog - a roughly prioritized list of what's being added to the application next.  All potential tasks for developers go into the backlog.  The backlog has a rough estimate on developer effort to build something, and also a rough estimate at a value to the business of having the new functionality.

The developers sit down and determine what they can deliver off the top of the backlog in the next two or three weeks, in a sprint planning meeting; those tasks move to a sprint backlog.  This meeting should include product owners, shouldn't take more than a day in total, and requires final high level requirements.  All tasks in the sprint backlog have an estimate on how long they'll take; the estimate has both management and developer approval as reasonable.  No task on the backlog has more than one day budgeted; any tasks longer than one day are broken into multiple tasks.

After this point, requirements freeze on everything in the sprint backlog, and a sprint begins.

A sprint is a short duration development cycle of fixed length.  Testable functionality should come out of the end of it.  Each day begins with a standup meeting.  The standup meeting is categorized by a few interesting quirks:

• Everyone literally stands up.  This helps keep the meeting short; it should be fifteen minutes or less.
• Anyone's welcome to attend, but the only people welcome to speak are those who are committed to the sprint.  "Committed", in this case, means that they'd be in trouble if they didn't do something *and* the sprint fails.
• Each person speaking quickly reviews what they did yesterday, what they plan to do today, and if they have any blocks in their way.
• The meeting is always in the same place, at the same time, every day.  It begins on-time, whether or not everyone's there.  And anyone late owes $1 towards donuts, or some other mutually agreed penalty.

Blocks are what they sound like; anything in the developer's way of getting the job done.  The standup meeting (and the sprint!) are run by a team member given the title of Scrum Master; it's their job to organize this, collect the dollars for donuts, and most importantly, work on removing blocks.

Two other meetings follow when a sprint ends, and they're both capped at two-to-four hours.

A sprint review (or demo) is a meeting of the team and the product owner, so that the team can show what has been completed.  Changes to the screens go into the product backlog, and if necessary, can move immediately into the next sprint backlog.  Incomplete work isn't demonstrated; it automatically is pushed forward into the next sprint.

The final meeting of the cycle is a retrospective; it's something like Toyota's kaizen, where everyone is asked to talk about what worked and what didn't in the sprint, so that the process can be improved and tweaked whereever possible.  Did some meetings have to happen earlier?  Was there a persistent block that's likely to come up again?  Does someone owe the team donuts?


Our biggest unsolved piece - the process improvement of the week - is trying to pin down which group is the most efficient at pushing out more requirements.  We've had some luck with a requirements team providing a high level document, but pinning down details requires reserving quite a few resources that are already short on hours; requirements happen when product owners have extra time, not necessarily as hand-in-hand with the developers as agile methodologies would like.


One other note of importance.  While agile, at least for us, lets good developers produce code more efficiently, past experience has demonstrated in spades that it also amplifies bad developers; it's no magic bullet, but another useful tool in the box.