Experimenting With Scrum Part 4

This is the last post in my "experimenting with scrum" series.  After our bug smash time, we went into a period of more serious product development.  Recall that we were not implementing all of scrum but rather just the scrum meetings portion.  This works acceptably in the development scenario, but not optimally.  We didn't break each task down into 1-2 day work items.  This meant that often when we met to talk, there was very little to update.  A person might come in for several days or even a week with the same status.  "I'm worked on the Widget interface yesterday.  I'll still be working on it today."  That is not terribly useful status and makes the meetings less interesting for all involved.  I did find that the cross-polination I had noticed in my earlier experiments continued.  Often something said in the meeting would spark one team member to interject with useful ideas for another.  This is conversation that often would not take place.  It is easy for a software developer to get lost in their office (or cube) and shut off the outside world.  While this allows for high-intensity coding, it doesn't vet the ideas very well.  Forcing people out of their offices, even if for only 15 minutes a day, encourages bouncing ideas off of each other.  This has beneficial effects on all involved.

I've talked to most of my team members about the experience.  Most liked it.  Some tolerated it.  No one had serious complaints about it.  I think I'll stick with something like this for a while at least.  I'll reflect on my experience and refine what we're doing.

Experimenting With Scrum Part 3

  Our first attempt at using scrum came during what we call a bug smash.  That is a time when we focus solely on fixing bugs.  No work is being done on new features.  This seemed like a logical time to implement scrum meetings.  I chose to meet once a day for 15 minutes.  We met at around 11:30 each morning.  I chose the middle of the day so that everyone could attend and maintain their same schedules.  Each meeting I would have our bug database open.  On my white board I tracked the number of bugs we had fixed in the previous 24 hours as well as the number of outstanding bugs.  When people arrived, we would go around the room and everyone would talk about what bug(s) they were actively working on and what they expected to fix that day.  If someone had no bugs left in their queue, we would reassign them bugs from someone else's queue.

   There were at least three good things that came out of these meetings.  First, it gave me a good opportunity to gauge our progress.  Each day I saw how we were progressing.  Admittedly, I could have done this myself by spending a few minutes in the bug database, but this was a forcing factor.  I also was able to hear how people were doing.  When they were stuck on a bug, I knew about it quickly.  Second, it allowed the team to see where we stood.  They knew where we stood as a group with the numbers on my white board.  They also knew how their teammates were doing.  Hard work is contagious.  The third, and mostly unexpected, benefit was the cross-pollination that took place.  One team member would say they were working on a bug and someone else would speak up with suggestions for solutions or places they might look for code doing something similar.  We ended up being much more efficient as a team because of these short meetings.

   For this bug-fixing stage of the product, small, short meetings on a daily basis proved very useful.  It is not fully implementing scrum and not even really fully implementing the scrum meeting portion of scrum, but it was useful.

Part 1

Part 2

A Few Points Of Interest

A few interesting articles I've found on the web recently:

Advice for those thinking about starting a company.  From someone who did it and came back to the corporate world.  If you want to read more about startups, I suggest you check out Paul Graham.

Joel Spolsky writes about the dangers of teaching Java in schools.  I find his thoughts on this subject similar to mine.  You need to learn the hard languages first, even if you don't plan to use them much.  It's easier to learn Java if you know C++ than to learn C++ if you know Java.  Kinda makes me want to go learn Lisp.

Avi talks about a new method for estimating project costs.  It is intriguing because it takes a middle-ground approach.  It doesn't just guess and move on but it doesn't try to plan for every detail either.  I'm really not a big fan of the "we can understand the project fully and thus know the costs" mentality which has left me often in the WAG department.  This new approach may be a good compromise.

I'm also becoming a fan of memeorandum.  Unlike Del.icio.us and reddit, this one seems to have a pretty high signal to noise ratio.

Experimenting With Scrum Part 2

   It occurs to me that some of those reading this blog will not be familiar with Scrum.  Before I go into any details about what did and didn't work about my experiments, I'll take some time to give a quick overview of the process.  For more information, check out the book or Ken Schwaber's web page.

   In a nutshell, scrum is a workflow methodology for developing software.  It is most often associated with practices such as eXtreme Programming but could really be used with any set of programming proactices.  The basic premise is that work cannot be scheduled far in advance.  Instead, it must be handled in discrete chunks and corrections to the course made regularly.  The tools for this are threefold:  the product backlog, the sprint, and the scrum meeting.

The list of potential features for a product is kept in ranked order in what is called a "product backlog."  This list could contain new features, modifications to features, bug lists, etc.  Everything that needs to be done goes on thsi list. 

Next is the sprint.  This is a defined period of time (the authors suggest 30 days) for work to be done.  During this time, no course corrections will be made.  If there is a new feature to be added, it will be handled in the next sprint.  At the end of a sprint, the features set aside for it should be complete and shippable.  The idea is that the product is ready at the end of each sprint.  By "ready" it is meant, the features are complete, not that every feature is there.  It might not be ready for cursotmer deployment yet.  There will not, however, be partially-implemented features and things checked in that don't work.

Finally there are the scrum meetings.  These are daily meetings of the team.  They should be short.  Each person in the room should basically give a quick status.  "Here is what I did in the last 24 hours.  Here is what I am doing in the next 24 hours.  Here are the items that are blocking me."  The purpose of this meeting is to provide visibility into the progress toward the sprint.  At this meeting, work items may be reassigned to others but new items are not added.

The idea behind Scrum is that software development is not like manufacturing.  It is more like original research.  We don't know how long something will take.  We don't know what roadblocks will be put in our way.  We don't even really know what the end product needs to look like because requirements change so often.  The response to this, rather than hiring 14 people just to maintain your Gantt charts, is to do away with them.  If the environment is always changing, the best response is not to plan better up front but rather to learn to react to those changes.  Scrum is one methodology to do this.

As a test development team working on disparate projects, this model doesn't fit perfectly.  I started with just the scrum meetings.  How that went will be described in my next posts on this subject.

Part 1

Part 3

Making the Media Center Remote Keyboard Work

   When Microsoft released their remote keyboard for Media Center, I was excited.  Here was a wireless keyboard, including mouse and MCE-specific functionality.  As an added benefit, it uses the Media Center IR receiver so you don't have to connect another one.  It seemed to be exactly what I was looking for.  I bought one early but was very disappointed.  While I like the eraser-style mouse on a laptop (it's a shame they are disappearing), this one didn't work right.  It was very difficult to control.  It seemed that I could only get it to move a short distance with each push and it was really hard to center on anything.  Despite my wife's request that I return it, I kept it just for the keyboard part.  Now, I'm glad that I did.  I finally figured out the secret of using the mouse. 

There are two things I found make it a pretty decent mouse.  First, you need to turn down the pointer speed a lot.  This can be done via the Control Panel.  This allows for better control and centering.  Without it, I overshot the buttons a lot.  Second, you have to have the keyboard aimed directly at the IR device.  Anything in between, and it responds terribly.  With a remote or with the keyboard keys, you don't notice because you are usually only sending one command but with the mouse, you are sending a stream of commands.  This seems to make a huge difference.  With a good line of sight, and slow pointer speed, it's pretty useful.  I can even navigate the small buttons found on regular windows applications.

The one thing I still can't figure out is how to get the keyboard to work with my motherboard's BIOS.  I have USB keyboards turned on but no luck.  If anyone has this problem solved, let me know.