Fri, 09 Mar 2012 00:22:52 -0800WeeblyWed, 15 Feb 2012 11:57:50 -0800http://www.kphutt.com/1/post/2012/02/pair-programming.htmlOn a new scrum team, we've been assigning a task to two people.
The first person who is very qualified to do the work, and a second person who
is new to that area. We did this for knowledge transfer purposes mostly, and to
have two people potentially working on two different areas of the task.


Sure enough, this week we have numerous people out for various reasons for
  various lengths of time. We've been able to keep nearly all of our tasks moving
  forward without any slowdown. I was quite impressed with how well this worked.
  If none of our tasks were "doubled up", our two week sprint would have been in
serious trouble.

From attempting pair programming at previous companies,
there can be a lot of resistance to it from the developers, who find it annoying
to have someone looking over their shoulder. Management can be uncomfortable
with pair programming, since they may see it as getting half of the productivity
and not realize the quality, communication, and rich mitigation improvements.


In most of the situations that I've seen pair programming fail or not be
useful were when it was forced for many tasks. My current team just allows
anyone to sign up for a task that someone else has signed up for. I'd say about
25% of our tasks are done through pair programming, usually the more challenging
  tasks.

I encourage people to not be shy about pair
programming, especially if it's a complicated area or just an area that you'd
like to learn more about.

]]>Tue, 14 Feb 2012 19:46:51 -0800http://www.kphutt.com/1/post/2012/02/all-legacy-software-sucks.htmlOn various projects, I've heard various people complain about
maintaining old/existing code. I've done my fair share of complaining myself, as
I'm sure whoever is reading this has as well. A co-worker and I were doing the
typical. I realized, I don't think I've ever witnessed someone talk about how
great an "old" piece of software is, even when talking about their own
software.

I don't want to be too cynical here, but it is interesting that
we focus on writing great software but never actually find "great legacy
  software". By legacy software, this includes code written even a few days ago.


I'd love to find some examples of code/software, that is say over a year
old, and the team agrees that it is excellent code. I'm not saying this doesn't
  exist, but by everyone's own complaints, it doesn't sound like anyone writes
  "good" software? ]]>Tue, 14 Feb 2012 19:35:42 -0800http://www.kphutt.com/1/post/2012/02/new-scrum-team-observations.htmlAfter having the training, a few point that has stuck out in my
mind, and that I've observed on my own team:

The team decides what it
does and doesn't need to get done. Everyone else needs to get out of the way. If
the team isn't trusted to decide for themselves how to operate, then management
should fire the team and hire a trusted team. If management doesn't trust anyone
to operate in this manner, then they'll always have a crippled team not
operating at full capacity.

While operating on a very new scrum team, I
noticed that even after the team is "empowered". Some team members push for the
same business regulations that they were complaining before using scrum. After
living in a corporate world for so long, I think it can be hard to realize that
you can decide for yourself, and not wonder what a different sprint team is
doing, what a different project is doing, if managers will approve of it or not.


The single best thing you can do on any team (agile or not), is to
realize what you need to do to get your job done. Do that, and don't worry about
what others think. That will allow you succeed.

A large part of the role
of the scrum master and product owner is to "support the team". These are fairly
well understood roles. One aspect of their role, that I don't think is
discussed, is to make the team look good. I've heard a number of arguments, that
the team can't do what they want, because it politically won't convey to the
"company" that they are getting work done. If the scrum master and product owner
are excellent, they'll allow the team to operate in what works for them, and
present the team’s progress in whatever makes sense to management. In
programming terms, there should be a layer of abstraction between how the team
is functioning and how the team’s progress is reported to management. This
shouldn't be any lying, just a different perspective on the same
work. ]]>Tue, 17 Jan 2012 19:11:21 -0800http://www.kphutt.com/1/post/2012/01/first-post.htmlAgile training starts today. It's being presented by Bob Galen, so far so good.

http://www.rgalen.com/about.html
]]>