Blog.AgileRaven.com

August 27th, 2014 by

This blog has moved! Please go to Blog.AgileRaven.com to see the latest and greatest posts from the Founder of Agile Raven, Scott Griffith.

The light at the end of the tunnel is a rainbow, not a train.

August 11th, 2011 by

Ever hear the expression “the light at the end of the tunnel is a train”? Well if you’re a project manager faced with a transition to Agile, it probably feels like that! The good news is that it’s not a train, it’s a rainbow.

Transitioning to Agile is a change. A big change. Change produces anxiety because our brains are hardwired to resist change. And if you’re a Project Manager who sat through a Certified ScrumMaster or Certified Scrum Product Owner class, you probably noticed that there are no PMs in Scrum. Not only that, the responsibilities of the PM are divided up between ScrumMaster, Product Owner, and Team. So now you’re probably wondering, “Will I still have a job?”

Yes, you will. Not only that, your job will change in wonderful ways, hence the “rainbow” instead of the train. Agile in general and Scrum in particular will allow you to focus on what you do best. The catch is that you will have to transition to a ScrumMaster, Product Owner, or Agile Program Manager. Which one is best for you?

The ScrumMaster helps the team help themselves. As a ScrumMaster you will facilitate the Scrum ceremonies (Sprint Planning, Daily Scrum, Sprint Review, & Retrospective), assist the team in removing impediments, create big visible information radiators, and coach the team on Scrum and Agile techniques. Instead of asking the team to do things for you, you’ll focus on how to help the team. This role is great for PMs who like to help people do the best they can do. Many ScrumMasters go on to become coaches.

The Product Owner is the sole representative of the ultimate end users. As a PO you lead the ongoing requirements discovery, elaboration, review, and acceptance processes. You will prioritize features and determine the contents of the release based on team velocity, value of features, and budget. PMs who are great at managing budgets and stakeholders do very well as Product Owners.

ScrumMasters and Product Owners work closely together. The SM is team-focused while the PO is stakeholder focused. But what about large multi-phased projects involving multiple teams, especially non-technical teams like Manufacturing & Distribution? This is the natural space for the Agile Program Manager.

Do you like bringing together disparate teams to deliver a single solution, i.e Concept-to-Cash? Working with product development, marketing, manufacturing, IT, help desk, sales, finance, legal, etc.? Then you are exactly what is needed for Agile Program Management. While the PO is working with stakeholders and the ScrumMaster with the technical teams, you’re the one to bring it all together. You’re also the one to keep an eye on the production support processes and training.

So which role appeals to you the most? In my experience, PMs already have a natural inclination towards one of these roles. There are PMs who dread dealing with stakeholders and would rather just work with engineering. I’ve known PMs who handle stakeholders effortlessly but struggle with developers. And I’ve known many PMs who are natural integrators that can see the whole better than those around them.

Given that most if not all of us, already have a natural disposition towards ScrumMaster, Product Owner, or Agile Program Manager — why not go through the tunnel and work in the rainbow? Life’s much better over here.

If you’ve read this far, you deserve a reward. When registering for any Agile Raven class, enter coupon code “Rainbow” and get an immediate $25.00 discount. Just my way of saying thanks for reading the entire post. You did read all of it, right?

If the comments are ugly, the code is ugly

November 16th, 2009 by

Over on the Great Wide Open blog by Esther Schindler, is an article entitled “If the comments are ugly, the code is ugly.” She was inspired by this quote:

Good programs do not contain spelling errors or have grammatical mistakes. I think this is probably a result of fractal attention to detail; in great programs things are correct at all levels, down to the periods at the ends of sentences in comments.

“Aw, c’mon! You’re kidding!” You might think that nit-picking like this is beneath you, whereupon I will start pointing out errors in your code. It was embarrassing the first couple times this happened to me.

— from the article “30 Years of C” on the DadHacker.com blog.

In my personal experience, I have have seen a common correlation between poor comments and poor code. I won’t take an extreme position as DadHacker or Esther but I have noticed that well thought out comments usually appear with well thought out code. Clear and concise comments with clear and concise code. Certainly there have been exceptions especially with developers whose first language is not English.  And the reverse has usually been true. Sloppy or non-existent comments with sloppy code.

Are certain languages more prone? Maybe, maybe not. However some years ago I was part of an organization that coded in Perl 3 for almost everything. We had some real gurus (“mad skillz”) on the team. One whom I hired directly that used to work with Larry Wall (inventor of Perl). Unfortunately these wizards, while some of the most expert Perl 3 developers (if the most) in Silicon Valley there were mostly very poor at documentation. Which given the nature of Perl 3 (the ability to combine multiple lines of code into a single string), documentation is even more important than with a more visually structured language like C++. I could and still do really appreciate the wizardry and elegance of writing such few lines of Perl code. It’s certainly beyond my ability. However in the end, if code cannot be maintained or understood by those that come after you then in my opinion it has failed. Not to mention that object-oriented Perl 3 development skills was (and probably skill is) hard to come by. But that rant is for another day.

So what’s your experience? Is there a correlation between good code and good documentation? How much documentation is “barely sufficient”? Have any Perl 3 stories to share?

Scrum — it’s not just for software anymore

September 16th, 2009 by

Is Agile only for software development? Or perhaps only for product development? At Agile2009 in Chicago, Jeff Sutherland and his wife Arlene presented two papers on adopting Scrum, one at OpenView Partners Venture Capital and the other at a number of Unitarian Churches.

I attended Agile2009 in Chicago and there were two presentations about implementing Scrum in non-software development organizations.  “Scrum in Church: Saving the World One Team at a Time,” by the Rev. Arline Conan Sutherland, Jeff Sutherland, Ph.D., and Christine Hegarty as well as “Take No Prisoners: How a Venture Capital Group Does Scrum,” by Jeff Sutherland, Ph.D. and Igor Altman. I had first heard about these parallel Scrum adoptions from Jeff Sutherland himself in early 2008 and was eager to see the papers once they were formally presented. I was not disappointed.

The abstract from “Scrum in Church”:

From 2005 – 2009 the author led Scrum teams in churches in Massachusetts, Connecticut, Florida, and Delaware. Scrum was designed to increase productivity and improve quality through teamwork. This experience report shows how Scrum was implemented in non-profit organizations to break down silos of knowledge and activity, encourage communication and collaboration, improve the working environment and personal relationships, and drive higher velocity and quality throughout the organization. Non-profits have impediments that are difficult to overcome – part-time and volunteer workers, narrow specialization, little to no experience with project teams, and political problems whose roots can go back as far as 1692. Scrum as an institutional change agent is invaluable to a church.

The abstract from “Take No Prisoners”:

In 2007, OpenView Venture Partners decided to adopt Scrum as best practice in software development in its portfolio companies and Scrum as the standard practice in internal operations. It is one of the first high-performance non-software Scrums that delivers twice as much value in fewer working hours. The model at OpenView provides data and a working manual on how to do Scrum outside of software development. Their aggressive removal of impediments (take no prisoners!) distinguishes them from Scrum implementations that are unable to remove institutionalized waste.

My take-aways:

The Scrum methodology is to be adapted to the environment. One size does not fit all. Arlene wrote “each and every time Scrum is introduced into a system it has to be adapted.”

Biggest gains in productivity came from:

  1. Creation and active management of a product backlog (20% or more new features, 80% maintenance, & aggressively remove low value stories & projects)
  2. Clear definition of “done.”
  3. Creation and aggressive management of an impediment backlog combined with root cause analysis.

People who are used to working as a team generally don’t resist the Scrum method as much as those who are very independent. In fact some people are too independent to be part of a team.

When stories are broken down into tasks, it is easier to see how team members can help each other out.

Interruptions and emergencies are a fact of working life and do in fact interrupt sprints [Church]. My response to this is that the key then is to carve out chunks of protected time (c.f. Covey’s 1st things 1st and Cirillo’s Pomodoro Technique.).

Vocabulary can be a stumbling block. I think this is because vocabulary is dependent on the culture. There have been a number of blogs on the topic Agile adoption being a culture shift with the inevitable culture shock. Those of us who look to implement Scrum and Agile in non-software organizations should watch our vocabulary. We should balance explaining concepts in a language the local culture understands with retaining those parts of the vocabulary that are different enough to be retained. For example, it’s safe to call a sprint an iteration or even a fixed schedule release. Back in the late ’90s we called this a release train.  Daily Scrum, stand-up, or daily status?  Whereas impediments are impediments because they are those things which impede us from achieving our goal.

What’s also interesting is that all the teams mentioned were most productive with one-week sprints. This contrasts sharply with the accepted wisdom that novice teams start off with one-month sprints and eventually settle on two-week sprints. I suspect that the difference is mostly due to the nature of the work. In both papers the teams are not creating products, software, or any system. In fact most of their stories are so small they resemble tasks. I’m reminded of Stephen Covey suggesting focusing one week at a time instead of one month at a time. The take-away here I believe is the sprint duration must be sized to the project at hand.

While not mentioned in the Church paper, the Take No Prisoners papers discusses at length the pitfalls of estimating in ideal hours instead of points. The biggest impact is that velocity remains flat as teams become more productive. Whereas using story points shows that the team can deliver more story points over time. By focusing on ideal hours, the team has to make some guesses on increased productivity (focus factor) in order to understand just how much their capacity really is. This strikes me as a compelling argument to avoid the temptation all of us faced when first confronted with estimating in ideal days versus points. This also speaks to predictability which is critical when trying to plan a release.

At the 10,000 foot level it comes down to Four Focus Areas:

  • Direction (the backlog)
  • Speed
  • Quality
  • Sustainability and Predictability

and avoiding the “5 Dysfunctions of a Team” by embracing:

  • Trust
  • Openness to conflict
  • Commitment
  • Accountability
  • Attention to Results

Do you have any experience applying Scrum and/or Agile in a non-software development team or organization? Please let us know. We’d love to hear from you.