Share via

Another Agile blog at Microsoft

  • Article

I know that there a quite a few agilists at Microsoft.  In my reading over the weekend, I saw this blog (Only Passionate People Win) by Young Joo, and I had to comment.

Here are a few of his posts on agile topics with my comments:

  • Abusing Agile
    Amen. 
  • You still do not get it!
    I remember the thread on the internal mailing list that he mentions.  Wow, that was a heated discussion.
  • Starting Agile? Learn basics first!
    This is funny.  I just moved into a new team collaboration space here at patterns & practices.  We are spinning up a new project and I was trying to decide where on the wall to put a print-off of the Agile Manifesto and a few guidelines for how I want the development process to work.  These are both for the non-agile folks (to teach) and for me (as a reminder).
  • Make sure your team is jelled before starting Agile
    My first experiences with agile development and forming a high performance team was with a group of folks who had never worked together before.  We had not jelled, but we were committed to trying out an idea.  It worked for us, but I can imagine that a number of challenges we encountered would not of happened if we had been a well-formed team previous to the project.
  • Accountability in Scrum
    Again, Amen.  Scrum is not a silver bullet.  XP is not a silver bullet.  Agile is not a silver bullet.  However, these approaches will expose the problems that your current model is hiding and make you deal with them.  Young links to Doug Seven's post on Accountability in a Scrum World.  I've got to comment on Doug's post as well.  The whole team is accountable for the failure.  There should never be a resource issue on a Scrum team.  If there is too much work for the team, they should only commit to the amount of work they can actually get done, and the project plan revisited with the new estimated velocity.  This sounds like a both a team (over-commiting) and a management (demanding features X, Y, and Z by this date) failure.  The idea with most of the agile approaches is to fix quality (high), date (the iteration), and resources (the team), and vary scope.  If you fix everything (like PMs and management often try to do) something will give and the team will fail.

As I find more blogs like this, I'll pass them on.

Comments