It is that time of year again – waiting to see if your submission has been accepted to Agile 2010.  This year, it seems that stage producers are bit-by-bit releasing proposals that were accepted.  Since I did not get my magic email I can only presume that my submission was one of the ones left in the rubbish bin.  So, in effect I have been given a de fecto rejection letter because I am hearing about all the other people that are being accepted.

I am bringing this up because from my perspective parts of the process still needs to be worked out – especially how people are notified.  It is disrespectful to have different timing for proposals that are accepted versus proposals that were rejected.  The producers care enough to send acceptance notice, but not a rejection notice.  Is that the message the Agile Alliance wanted to send?  The only reason why I am complaining about this topic is that I care.  I care about transparency, respect for the individual and that the process adheres to its vision.  In my opinion, the process and the way its implemented doesn’t represent the values I tend to think of as Agile.

What burns me the most, when I tried to provide feedback to some participants of the review process, some reviewers got defensive and challenged me to do better.  Hold on there – I’m a stakeholder in your process and I’m dissatisfied with the execution.  It is not my responsibility to fix your process, that is the job of the Team.  Stakeholders just provide feedback and guidance on what our expectations are.  Don’t hand me a squirrel burger and tell me it’s a Big Mac – I’m not going to buy it no matter how great you tell me it tastes.  I am not sure if I had the expectation of getting a Big Mac, but I am not pleased that I am being told this squirrel burger is all I get.

Update: Eating a bit of humble pie served to me from a number of my peers.  I apologize for my words since they may have come of for being disrespectful of the time and commitment many volunteers put into building these stages.  That was not the intention, but I was offering feedback in the spirit of continuous improvement and inspect-and-adapt.

Just wanted to let folks know that I will be speaking at the PMI San Diego 2010 conference.  I will be running a full-day seminar on May 13th and a 60-minute tutorial on May 14th.  I am very excited about this opportunity and encourage folks to attend either day.

• Leaping to Success with High Performing Teams – in this May 13th seminar, I will be running a SIMSOC.  This is a great opportunity to participate in this exciting and interesting simulation to earn about what factors help teams self-organize and that high-performing state.  The last time I ran this class, it got great reviews and was a lot of fun.
• Agile Playground – on May 14th, I will be leading a tutorial which uses games to help people experience Agile principles.  I have found to really begin to understand Agile, one needs to experience the principles and values at an emotional level, rather than an intellectual level.  The exercises I will be using in the tutorial will open your mind to what Agile is all about.

That is what I have scheduled for the month of May, I have more exciting stuff planned for June.  Stay tuned, in the meantime, please register for the PMI San Diego 2010 conference today.

I recently encountered what I call a Scrum microteam – just two Team members, a Product Owner and a ScrumMaster.  Out-of-the-book Scrum provides guidance that Teams should be 6±2 people, not including the ScrumMaster and Product Owner.  I have been intrigued by such a small Team (glad they are filling all the roles) and these are my thoughts why Scrum suggests 4 to 8 people after understanding the forces which created this Team.

• Overhead – Scrum impose a fair amount of overhead on Teams – planning meetings, reviews, retrospectives and daily stand-ups.  I like all the pieces of Scrum and consider them essential.  Yet, I am not convinced it is worth the effort for just two people.  Could a good project manager be sufficient?
• Work-In-Progress of one – This might seem like a benefit, but I believe it actually increases the risk the business will get nothing of value at the end of the Sprint.  When you have microteams, you can only effectively work one story at a time.  Any delay, change in scope or discovery of emergent tasks, puts the Sprint Goal at risk.  Further subdividing the story into smaller (technical) pieces just atomizes the work, not the risk.
• Missing cross-functional skill set – with a team of 2 to 3 people, you typically have only one functional area represented, usually programmers.  Since Scrum is framework for cross-functional teams, why use the process if you are not meeting one of the preconditions?
• Handoffs within the Sprint – suppose you are lucky enough in your microteam to avoid all programmers – your Team has a software developer and a graphic designer – now you have the problem that their skill sets do not overlap.  When skill sets do not overlap, that creates handoffs, handoffs are a form of waste and the whole point of cross-functional teams is to eliminate handoffs.
• Narrow Definition of Done -  when the Team is so small, they must reach out to the rest of the organization in order to get anything really done.  This is a problem on any team, but when the Team is so small, the Definition of Done only includes things within the skill set of the individual members.  The amount of undone work is significant on a microteam. Entire Sprints can be dedicated to making sure this work is done and not delivering additional value to the organization.
• Limited impact – if your microteam is a pilot effort of Scrum for a larger organization, then the impact of Scrum will be quite limited.  Small teams work on small problems that are not that important to the organization.  There will be strong inertia to adapt Scrum rather than fix the underlying obstacles and dysfunctions – why change your organization to make life better for just two people working on a pilot?