More Agile Than Agile

Posted on

Ok, so I ripped off the title from a Rob Zombie tune, however the point I’m making is that I’ve learned Scrum the hard way.  I knew a bit of theory and was poured into a Scrum-like environment and quickly found that a lot of what Scrum preaches is just plain common sense.

Since I’ve always taken the common sense approach to project management, even in traditional environments with strict rules, I’ve got the added benefit of being more Agile than Agile.

I’m preparing for my Certified Scrum Master training which starts tomorrow and wanted to make sure I documented a point in time to express where I’m at and what I want to get out of it.

My stance on Agile, and Scrum in particular, is that there is a framework available that you and your organization should build on to define what your project process is and that the Team should be responsible for agreeing on how that process works.  The PM or SM (scrumMaster) shouldn’t be forcing rules onto the Team.  I also believe there are some core Scrum beliefs that should be the baseline for building your implementation of Scrum:

  1. you cannot introduce new scope into a sprint.  ever.
  2. your velocity should level off after a few sprints
  3. agile is not an excuse for lack of planning
  4. the Team should be committing to the work they will complete.  The PO (Product Owner) or SM should not be telling the team what work they will do.  The PO should provide a prioritized list and then have the option of taking stuff out and putting other stuff in during planning
  5. visuals are good.  write stuff down and post it on the wall.  write notes on story cards, write down steps to demo the functionality in the story, write use cases on the card to help define your tests.
  6. the team is a democracy. if something isn’t working, find out if it’s not working because of Scrum or if it was just exposed by Scrum.  Learn what didn’t work and agree on the output.
  7. the team must agree on what “done” means (and “done” can vary by story type, just be sure to define it)
  8. The Team should be accountable for what they commit to.
  9. Above all else, communicate and be reasonable.  Nothing is black and white and stories leave room for interpretation.  You should not expect for the team to go away with their 50 stories and come back when it’s done.

What’s the hardest stuff I’ve come up against?

  1. properly defined stories: “uh, the story didn’t say turn on my computer so I couldn’t do it.”  Ok, that’s extreme, but different people interpret a story differently and it’s easy to fall off the rails when a discussion arises.  I want to learn how to handle these type of scenarios to minimize the frustration and back and forth.
  2. putting time against tasks: I believe everything should be and can be measured.  I’ve had others tell me that story points translate to effort not time.  EVERYTHING is tied to time.  If you’re velocity is supposed to level off (which according to Scrum, it should) then you roughly know the amount of time required given the points for a story. You know how much time is available in a sprint. (in an 8 hour day a person has about 5 – 6 hours of time when factoring in lunch, breaks, meetings, email etc)  You know what the sprint velocity was at the end of the sprint and you know what the estimated velocity was at the beginning of the sprint.  I was really bad at math in college but that ain’t rocket science.  Find your formula and track it.
  3. Priorities and dependencies:   Simple in Waterfall, look at the gantt chart.  If there are 2 high priority stories and 1 is dependent on the other, do I as an SM really need to spell that out?  Isn’t a team member smart enough to figure out that if they want to install this software they need to turn the computer on first?
  4. Dealing with unknown variables: in small teams where team members are responsible for customer support, how do plan?  A support case can be a simple phone call or it can be a 2 or 3 hour distraction that derails the sprint.  how do you account for it?  how can you measure and estimate potential interruptions?
  5. Team adoption: here’s a shocker, people are different.  Some are more disciplined than others and some are more ‘Agile’ than others. What are some techniques for helping the more disciplined team members be more agile while helping them self-manage more and not dictating how to work?
  6. Why, as an SM, am I ‘planning the sprint’?  Shouldn’t there just be a prioritized backlog for the team to decide what to commit to?  I find often we are trying to say “here is the chunk of work for this sprint, let’s point it.”

I’m sure I have more questions, but I’m really excited to start this training to fill in the gaps of what I’ve learned on the job and in books.  If at all possible I’ll be twittering at www.twitter.com/jasonlittle

My goal is to become a more effective scrum master and empower the team.  The TEAM should be recognized for their successes and as an SM, I should be the one to help them achieve that success by helping them work smarter and by leveraging what Scrum offers.