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.

New From Agilebuddy - Press Release

Software veterans go Agile, with rich collaboration capabilities for Agile and Scrum project management

Toronto — January 28, 2009 —Brightspark 3.0 Inc, Canada’s leading startup experts, today announced the release of Agilebuddy, an Agile and Scrum project management software service that guides users through the Agile and Scrum process.

Agilebuddy is a full featured web based project management application built on a rich collaboration platform, it allows for flexible, dynamic project administration and offers users an easy way to create, estimate and plan Scrum development projects.

Agilebuddy is designed to be used with any Agile process including Scrum, eXtreme Programming (XP), Feature Driven Development (FDD). These methodologies and processes are gaining momentum with software development teams around the world.

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:

Plannning a critical success factor

In a blog post today by Barry Otterholt on P.M. Hut, he talks about planning as one of the critical success factors in order for projects to be successful. According to Barry, "Planning should be on ongoing evaluation and adjustment process, not mere preparation of a deliverable"

I cannot agree more. Planning is probably the most important thing you can be doing and as this blog points out, planning is a never ending phase. You've got to be planning all the time. In Mike Cohn's book on Agile estimating there is a great quote - "Planning is everything but plans are nothing".

And this is where Agile comes in to play...

In my opinion, that's what I love most about Agile. Agile methods like scrum ensure that teams are continuously planning, grooming the backlog, elaborating and estimating user stories. Inspecting and adapting before during and after each iteration.

The sooner that Teams figure out how to do this really well the better.

My 2 cents
Jack

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.

QA - The Agile Approach

Photo by: davestfu

QA is always near and dear to our hearts. We all talk a lot about the fact that Quality is "King" but we certainly don't show it. In fact, we cut quality without even so much as a thought - "It's in our bones" (Ken Schwaber). For most of my software career, QA has always been an afterthought. Developers pushed to the limits, dates slipping, so what's the natural thing to do, cut quality, it's the easiest and quickest thing do. The problem with cutting quality and what we don't realize is that technical debt starts to rise exponentially. Eventually, and it's not even that long, 3 - 5 years for most companies, your codebase will drive you and your company into a corner. 

So how can you tell that your company is in this situation? Here are some tell tale signs:

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.