Proposed Development process

Coordinator
Sep 16, 2010 at 6:52 PM

Alright, time to get this discussion started. 

I chatted with Drew Miller about his experiences running an agile team as well as a Lean team. I have experience running agile teams as well using weekly iterations.

I really like the idea of using a lean style micro-iterations, but Drew and I think that would be very challenging coordinating that with core members who are not full time on NuPack and can only contribute in their spare time intermittently. Not only that, but it’s a pretty drastic change for the core Microsofties.

I think to start, we need to ease into this new model of development. So here’s my proposal for us to discuss.

Iterations and Iteration Planning

2 week iterations.

  • At the end of each iteration, we should refresh the VSIX within the CodePlex.com downloads section as our “release”.
  • Some iterations may focus on producing a release that we push to the Visual Studio Extensions gallery or produce a release intended for our stakeholders (aka the Microsoft products that will incorporate NuPack)

Iteration Planning

  • Iteration planning should happen on Friday before the beginning of the next iteration.
  • We’ll try and schedule a recurring live meeting and anyone from the core team who wants to take part, can take part.
  • We want to streamline this so it doesn’t take too long by having
  • 50% of the items will be must have for the current iteration
  • 50% of the items will be must have for later iterations (this mitigates risk of spare time developers as we can assign these items to those developers)

 Iteration Kickoff Meeting

  • Happens on the first Monday of every iteration.
  • This should be a brief meeting where we make sure we’re all on the same page and bring up any issues that we need to resolve.
  • At this point, we should pretty much know which items are going to be in the iteration already. This meeting is not meant to define the scope of the iteration. A lot of that happens during…

Continuous Backlog Management

  • We’ll run backlog management (aka triage) on an almost continuous basis.
  • I’ll be running a small meeting where some of us go through items weekly or twice weekly.
  • At the same time, everyone is free to request triage by email for items they are interested in.
  • By running this continuously, we should avoid the overhead of large iteration planning meetings.

Let me know your thoughts.

Phil

 

Sep 16, 2010 at 7:13 PM

The part I like least about this is the iteration length; two weeks is a long time. But, like Phil said, this might be a good starting point, and we can ease into shorter iterations (or perhaps a more micro-iteraration- or Kanban-style flow) over time. Due to the internal (Microsoft) side of things, we might not be able to be as flexible and JITty as we'd like.

Also, I'd love to hear from the folks who've done distributed OOS, what do you think of this? I've led distributed "agile" teams (I hate using that word, these days), and I studied and thought a lot about OSS project management when I was on the CodePlex team, but that's not the same as extended time on a distributed OSS project. We might not get to ideal OSS project practices with the internal constraints, but I'd love to hear what you think might work better, and what your experiences have been.

And, I think we should be open to frequent and aggressive experimentation. We can pick ideas as a team to try, give them a time-box, and evaluate them at the end to see whether to adopt them or discard them.

Good times.

Editor
Sep 16, 2010 at 7:16 PM

Funny, I said the same thing folks on my last visit to Redmond. 1 week FTW!

From: drewmiller [mailto:notifications@codeplex.com]
Sent: Thursday, September 16, 2010 11:14 AM
To: Scott Hanselman
Subject: Re: Proposed Development process [nupack:227497]

From: drewmiller

The part I like least about this is the iteration length; two weeks is a long time. But, like Phil said, this might be a good starting point, and we can ease into shorter iterations (or perhaps a more micro-iteraration- or Kanban-style flow) over time. Due to the internal (Microsoft) side of things, we might not be able to be as flexible and JITty as we'd like.

Also, I'd love to hear from the folks who've done distributed OOS, what do you think of this? I've led distributed "agile" teams (I hate using that word, these days), and I studied and thought a lot about OSS project management when I was on the CodePlex team, but that's not the same as extended time on a distributed OSS project. We might not get to ideal OSS project practices with the internal constraints, but I'd love to hear what you think might work better, and what your experiences have been.

And, I think we should be open to frequent and aggressive experimentation. We can pick ideas as a team to try, give them a time-box, and evaluate them at the end to see whether to adopt them or discard them.

Good times.

Read the full discussion online.

To add a post to this discussion, reply to this email (nupack@discussions.codeplex.com)

To start a new discussion for this project, email nupack@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Sep 16, 2010 at 7:19 PM

I think 2 week iterations is a good start. I find 1 week is fine after the team does some gelling but aggressive for a team that hasn't gone through at least a few iterations together. I like the plan Phil has and no objections. For iteration planning though I would like to see if we can aim for an iteration goal rather than just a set of tasks to do in that timeframe.

Sep 16, 2010 at 8:02 PM
I'm good with whatever.  I can't compare apples and oranges. What I do at work is an entirely different animal with lots of documentation so two week iterations make sense.

We can start with two week iterations and see where we should go from there.  

Side Note: I don't carry an "iteration" schedule on my OSS projects. I carry a "feature" schedule. I make releases when I have a feature done, not on a time box.  So if a feature is not done, I don't cut it or make it less than what I was hoping so I can get a release out. I hold the release until the feature is done to the standard that I believe it should be.
Coordinator
Sep 16, 2010 at 8:39 PM

I thought about the feature schedule, but I think that can be challenging. For example, suppose I assign you a feature, but your day job heats up and you just can't get to it. I'd rather punt the feature to the next iteration than hold up the release for the feature.

I do like the feature schedule in concept, but one nice thing about the set iterations is it is very predictable. Everyone knows when an iteration starts and ends. Makes having joint iteration planning meetings easier, considering our distributed team.

Sep 16, 2010 at 8:56 PM
I think this sounds like a good process to go with.  We need to see who and how much time commitment everyone can make.
 
For my OSS projects I do follow a Feature Release process, but that is because everyone is working on the side and we just cannot commit to time boxes when we all have day jobs.
 
Coordinator
Sep 16, 2010 at 8:59 PM

If you think about it, we’re sort of doing a hybrid. I’ve never worked on an OSS project that had dedicated full time developers. So with Subtext, we do a feature driven release as well.

But maybe we simply do time based iterations but feature driven major releases. Also, we can go feature driven for non-full time developers. Just a thought.

Sep 16, 2010 at 9:02 PM
I think this whole project will be a number of experiements as the .Net side is just not used to having fulltime OSS teams.  I know the other platforms have probably worked this out and reinveted it a few times over. But, yeah, lets go with what you presented and learn from this.
Sep 16, 2010 at 9:56 PM

+1

____
Rob
"Be passionate in all you do"

http://devlicio.us/blogs/rob_reynolds
http://ferventcoder.com
http://twitter.com/ferventcoder