Technical stories - are they included on the backlog?

If you're not already a member of the Scrum development group on Yahoo, you really should join. There's a fortune of information changing hands and you can learn so much from the interactions. Just recently there was a huge debate on the topic of technical stories.

Sprint start and stop days - what's best

Firstly, let me state that it is imperative that sprint lengths remain consistent. By all means experiment with 1 week, 2 week or 3 week sprints but once you have figured out your sweet spot, stick to it. This is important to setup a rhythm in the company. However, the question is what days are the best days during the week to start and stop sprints. Until now, I have been a big fan of Monday starts and ending Fridays. It seems to be a natural cadence and the days are logical transition points.

However, this week, there was discussion on the Scrum development forum and a number of folks are in favor of starting on Thursday and ending on Wednesday. Reasons given are as follows:

• There are often holidays on Mondays and Fridays which interrupt the cycle and therefore the rhythm.

• If sprints are a little behind and you end on a Friday, it will force teams to work on the weekends -- generally shunned upon by the Agile community.

• On Fridays, folks generally tend to glide through the demos and retrospectives and as a result there is a drop in productivity.
• Team members work from home on Fridays.

The right answer, let the team decide.

Certainly school for thought. I have to give this a try.

What's been your experience?

Jack

Doing the Right thing vs Doing it Right

Photo by: Teuobk

In a recent thought provoking blog post by Allan Kelly titled "Requirements Come Second", Allan makes the case for resolving the development process side of the business first before addressing alignment issues with the business.

It's probably one of the most interesting blogs for a while and there have been lots of good comments made. I suggest you read the full article. I guess I can't argue with the data. However I don't think it's that hard to work on both sides simultaneously. And I truly believe that the Scrum process makes it easy to address both requirements and development process at the same time assuming you are following the prescribed Scrum practices. Let me explain....

Scrum requires that you have a single Backlog of requirements and that you have a single owner of the Backlog - the Product Owner. The Product Owner is responsible for sequencing the Backlog and therefore he can't be doing this in isolation of the business. Scrum also prescribes that teams identify Sprint goals at the start of every iteration. These goals need to be aligned with the business overarching vision and strategy.

Bottom line is that adopting Scrum is going to help your company get aligned with the business and of course will help you with the development process at the same time. Additionally, I still believe that the biggest risk of all is delivering the wrong Product so I think it's prudent to deal with this side of the business as well. Why not?

I personally don't buy doing one without the other. And Scrum really helps you to address both at the same time.

Written by Jack Milunksy - COO at Brightspark, certified ScrumMaster and Co-founder of Agilebuddy (Agile project management software that lets you easily Create, Estimate, Plan and Track your software development projects). For great Agile tips follow Jack at: www.twitter.com/agilebuddy. To get more info on Agilebuddy please visit: www.agilebuddy.com

Agile and Lean - Closer than you think

Sara Peyton published a really informative blog today on Lean Software development. Essentially it's a pretty detailed overview of the characteristics of Lean. The point of the blog however is to outline the differences between Agile and Lean. As Sara points out, "Agile has a different perspective from Lean and, generally, has a narrower focus".

Whilst I agree with the fact that Lean is much more broad, there are more similarities with Agile than one would expect. If we examine each of the 7 principles discussed in this blog, and relate them to Agile it's pretty obvious to me that Lean and Agile go hand in hand. Now when I speak of Agile, let me clarify what I mean.

Why switch to Agile - besides failure

Photo by: The Letter E

There's a thread currently bouncing around the Yahoo Agile group as to why organizations would consider switching to Agile. A lot has been said about project failures and there's debating back and forth as to what statistical data is out there to back a company's decision to switch.

The way I see things is that both Waterfall projects and Agile projects succeed and fail. So it's not just because projects fail that one should switch. Most certainly that's a big reason. But there's many other reasons why company's should switch. One only needs to read the Chaos report by the Standish group to realize that there's most likely a better way to do things than traditional methods. Lets face it. There were a lot of smart people behind the Agile movement and so there were reasons that they sought to find a better way.

So what are the other reasons to switch, there are many tell tale signs to look for in your organization for example and this is not an exhaustive list:

Significance of Time Boxing

Everything in Scrum is time boxed - assuming you go by the book of course. Did you ever stop to wonder why?  The Sprint planning meeting is time boxed to two 4 hours sessions (One to define what you’re doing, the other to define how you’re going to do it). The Sprint itself is time boxed to 30 days or less depending on how you’re structuring things. The Sprint review meeting is time boxed to 4 hours as is the Retrospective. So what’s this time boxing about anyways?

Fundamentally, it’s designed to establish a sense of urgency and to coerce the team to focus there efforts on getting something done. This is based on one of the Agile Manifesto that suggests the best way to show progress is to produce demonstrable working product, not documentation - Wow, what a concept! That’s not to say you don’t need documentation. In many cases this is required for ISO, FDA and other standards, but documentation is just one of the artifacts that needs to get produced during the course of the sprint – it’s not the bee-all and end-all.

Agile is not just about speed

Without doubt, Scrum has become a household name in Software Development arenas. Scrum as we all know it today, is not an acronym but derives from the game of rugby. A Scrum in Rugby is a loose formation of forwards designed to bring the rugby ball back into play. It was Hirotaka Takeuchi and Ikujiro Nonaka in their revolutionizing article The New New Product Development Game for the Harvard Business Review who first used Rugby as the best analogy to describe new product development. Although at the time I am sure they did not realize how much of an impact their research would have on new Software development.

It is interesting to try to understand why Takeuchi and Nonaka picked Rugby as the best analogy for describing the characteristics of competitive companies engaged in new product development.