When Should Waterfall be Used Instead of Agile?

March 9, 2010 1 Comment

I just read a thread on the Scrum Development yahoo user group about when it would be appropriate to use agile and when waterfall would be better.

This brought to mind all the conversations I’ve had over the years regarding “when to use agile”. There are many folks in organizations that believe that waterfall is best suited for some projects.

So, I’ve been searching for those “types” of projects.

Now, let’s be clear. I am using the term “waterfall” in the strictest sense which means that:

  • Requirements have to be complete and signed off before technical design begins.
  • Technical design has to be complete before development begins.
  • All coding has to be complete for testing begins.

If we “kind of” follow this, then it is chaos.  The question we have to ask is … is it even possible to meet the strict requirements of waterfall?  My answer is NO for software projects, or any projects with a large amount of unknowns or required creativity and flexibility.

Can you ever successfully elicit and document a complete set of requirements at the most granular level?  This is what waterfall requires after all. If there is even a remote chance that a) the customer isn’t sure what they want, b) the customer may change their mind on what they want, or c) there is even a small amount of complexity, then it is very, very high risk and just not very smart to use waterfall. You just can’t…stop kidding yourself.

So, is there ever a reason why you would want to use waterfall? Sure! Here they are:

  • The culture is not ready to work cross-functionally.
    • Any agile methodology requires a cross-functional team. If the culture cannot sustain cross-functional work then you are forced into communication by documentation. Yeah, good luck with that. You should think about coming up with a strategy to make people hunger for cross-functional collaboration.
    • Not everyone “wants” to work in a cross-functional team environment. They need to either be coached up or coached out.
  • Management makes you use waterfall.
  • You can confidently define everything up front, there is little or no chance there will be changes, and there are no unknowns.

Let’s not pretend anymore that waterfall is actually appropriate for any complex software project with humans working on it.  With complexity come unknowns, and with unknowns, the amount of bureaucracy necessary to handle “change management” is ludicrous.  I have yet to experience any software development project that did not have at least some kind of complexity.  If you say “agile doesn’t work for all software projects”, then you have a misunderstanding of what agile truly is.

Advertisement

Filed under Agile Tagged with ,

Expiring CSP (Certified Scrum Practitioner)…Do I Care?

February 28, 2010 5 Comments

Scrum Rocks

I love Scrum.  It’s freakin’ awesome. It is simple and yet wonderfully challenging. When implementing for the first time, impediments (of which most have always been there) smack you in the face, and you are forced to make a decision…knock them down or ignore them.  Sadly, the path of least resistance is to ignore, so that is what tends to happen.

Scrum makes you focus on empowerment and value.  Scrum also forces “the business” to be a part of the process with the Product Owner.  Scrum forces you to deliver potentially shippable code at regular intervals.

One of my favorite things is the “chicken” and “pig” thing.  The pigs are the ones whose neck is on the line to deliver value, i.e. the Scrum Team.  The chickens are the ones whose neck is NOT on the line.  You know those folks…the ones who distract the team from focusing on the goals at hand.  I’ve had lots of those back in the day…and they sucked.  With Scrum, we can draw a line in the sand.  We can identify those who have skin in the game, and those who don’t.  Now, we shouldn’t just flip the bird (no pun intended) to the chickens…they may very well have very good input and feedback.  However, this information must be funneled through the Product Owner, not directly to the team.  Of course we could have made this delineation with our traditional methods, but the methods never clearly called out this distinction so people had to rely on their common sense, which meant that it never happened.

Scrum, But…

I am so sick of hearing this. People continuously ask themselves “Are we doing Scrum or not?”. That’s not the right question! The question should be “Are we improving in our ability to deliver value to the customer or not?”.

Scrum is empirical. It is meant to change. What are the non-negotiables? Ummm…I’m not really sure. Some people say the daily scrum. However, I’ve seen times when the team is all in the same room and highly functional, and the daily scrum is completely unnecessary since communication is organic.

What about the retrospective at the end of every sprint? Ummm…I’m not really sure. If you have 2-week sprints, wow, do they get stale. What about at the end of every other sprint? Shouldn’t the team decide? Are we “doing Scrum” if we decide to do them every other sprint? Well, I guess it depends on who you talk to.

What about the burndown chart? It’s in the Scrum Guide, right? It doesn’t say that it’s required, but it doesn’t say it’s not. Okay, so we don’t have a burndown, but we meet our sprint goal, and have potentially shippable product at the end of the sprint…so are we “doing Scrum”? I guess it depends on who you talk to.

Uh-oh, what if we have more than one Product Owner? Well, I’ve seen it work for some teams very well. But, Scrum says you have only one. Are we “doing Scrum”? I guess it depends on who you talk to.

My point is this, Scrum is a light framework that supports the agile (and lean) principles. If you know what you’re doing, go ahead and do what is right for you team…making sure to not lose sight of continuously improving, and delivering high quality value to the customer. Don’t worry if “your doing Scrum or not”.

Now, if you are new to Scrum, or agile in general (i.e. don’t know what you are doing), PROCEED WITH CAUTION! Spend LOTS of time digesting information, reading blogs, books, etc. before you start. I’ve seen many folks attempt to adhere to a book after a quick skim and fail spectacularly when trying to implement Scrum. You should seriously consider getting someone in to help you.

To Renew my CSP, or Not to Renew? That is the Question!!

I have a confession to make. The only reason I got my CSP was purely a PR move. I had been practicing “real life” Scrum for some time. However, for some reason corporate America cares about certifications. I’m starting to believe that certifications, ALL certifications, are purely marketing tools, and nothing else. Why is it that all of the absolute worst project managers that I have ever worked with had a PMP certification? Or, why is it that some of the absolute worst system admins that I’ve met had a MCSE certification. Even some of the worst Java programmers I have met had a Sun Certified Java Programmer certification. Hrmmm…I think I’m starting to see a trend. Typically, at least in my small part of the world, the truly talented folks rarely have any certifications.

Okay, so let’s get real. It’s the game you have to play. Right now, I’m not in a place where I have to play these kinds of games. I’m employed full time in a great company, so I don’t have to worry so much about “PR” moves such as certifications.

Okay, so I think I’ve answered my question. No, I don’t care about the CSP right now. So no, I’m not going to renew my CSP.

Filed under Certifications Tagged with , , , ,

Process is Not a Four Letter Word

January 20, 2010 3 Comments

I grew up as an only child.  I had no brothers or sisters to “share” anything with.  It was all MINE.  When I became a teenager, I completely rebelled against all authority.  This probably had something to do with my only child-ness, but probably had more to do with me being a spoiled jerk.

I hated all authority…teachers, parents, pastors, police, you name it.  How dare they tell me what to do!  I felt that their only purpose was to make sure everyone followed arbitrary rules that MADE NO SENSE, and they were determined to make my life hell.

As the years went by, I calmed down, settled down and became a family man.  But, I don’t think I’ve ever shaken off that old “to hell with authority” attitude.  I’ve just learned to live with it 🙂

I think this is one of the reasons that I fell in love with Scrum, and agile in general.  It had that familiar aroma of my old days of rebellion.  Agile ideas came about really out of necessity and a spirit of rebellion.  There were arbitrary rules that were imposed on organizations about how to build software that MADE NO SENSE!  So, how about we rebel, and do things OUR way, i.e. the way that makes sense.

Now, let’s consider the word “process”.  Over the last several days I’ve realized the profound effect this word has on people.  People immediately cringe.  For some reason, the word “process” paints a picture of arbitrary rules that MAKE NO SENSE that we have to follow.  It implies bureaucracy and micro-management.

Now, let’s set something straight.  “Process” is critical to the success of any endeavor.  If you let the process “evolve” without paying attention to it, it will cause chaos.  One thing that people don’t understand is that a process always exists, whether it’s documented or not.  It may feel like “free-style”, but it’s a process.

I’ve been involved in some conversations recently about role definition.  This is a classic problem that plagues every company…not having a clear definition of roles.  Here is the problem; without a clear understanding of a PROCESS, you will never be able to clearly define ROLES.  The first thing that should happen is to clearly define what the process is in how to deliver software (or anything).  I’m not talking about creating artifacts.  Documentation does not equal process.  It supports the process, and may be a by-product of the process, but documentation alone is not the process.  But be careful.  I’ve seen to many times a “process” created that people end up slavishly following without ever even attempting to improve it.  A process must evolve along with the changing culture, technology, and business needs.

To some extent, Scrum practitioners discourage defining processes.  It appears to me that maybe this whole “stick it to the man” gets a little too out of hand…even for me!

If you don’t control the process, the process will control you, and it won’t be a good thing.

Filed under Process Tagged with , , ,

Agile – It’s All About the Principles

December 6, 2009 Leave a comment

I’ve been talking with a lot of folks lately that claim to have been working with Agile for a long time.  When I talk with them, they boil agile down to a few things such as; delivering faster, iterations, and stand-ups.

What troubles me is that very few people talk about the principles.  I like focus on the principles first, and look at the practices (retrospectives, stand-ups, iterations, etc.) as “how” to bring those principles to the forefront of everyone’s mind.
You aren’t “doing agile” because you put index cards on a wall, or because you stand up for 15 minutes a day in a meeting, or even if you have iterations.  Practices without focus on the principles will get you nowhere.
As teams inspect and adapt, new practices will emerge.  As these new practices emerge, we need to do our best to make sure they don’t impede the agile principles, which are honestly good principles no matter what approach is used.

Filed under Agile Tagged with ,

Just in Time or Just in Case?

December 3, 2009 Leave a comment

A huge form of waste that many people don’t talk about are those things that are built “just in case” we might need them some day.

I think that those involved in building a product often times forget that everything that is built costs something.  Nothing is free.  Who’s paying for it?  The customer is.  Everything we do must deliver some kind of business value, either by reducing risk, meeting compliance, cutting costs, increasing revenue, etc.
There are certain phrases that I listen for like “it would be cool if…”, “someday we  might want to…”, etc.  Some tend to want to build to accommodate edge cases that are (many times) so ridiculous that they would never happen.  Now what gets really tricky is when there is only one SME in the product group, and no one else really knows that domain.  In those cases, God help you!  That SME has the power to make you do things that you look back on and say “WHAT HAVE WE DONE?!?!?”.  The only way to get around this is to fearlessly and relentlessly ask “why?”.  In these situations, there is typically a touch of fear that compels the team to bow down and say “yes master, whatever you wish” instead of asking probing questions.

There are some Scrum Masters (and Project Managers) that typically stay out of those kinds of details.  Yes, the team is self-organizing.  Yes, the team has to learn by making mistakes.  However, the Scrum Master has to be involved enough to not allow the “just in case” methodology from taking hold.  If it’s allowed to go on too long, you will have found out that what you have delivered in the end is not what is  valuable now.

Filed under Agile Tagged with ,

Bringing Agile to the Organization

November 16, 2009 Leave a comment

Almost all of the literature out there recommends the first step being finding a “pilot” project where you can use an agile methodology.  The project can’t be too complex, too simple, too large, too small, too critical, or too unimportant. 

I’m starting to wonder if we’re over-thinking this.  Why don’t we decide what to use depending on the project?  If RUP fits REALLY well, then why don’t we use that?  If Scrum fits REALLY well, then we should have the option of using that…right? 
In reality, the only thing that will ever hold back a true agile adoption on a project or an organization is the culture.  And, the other reality is that most organizations have a culture that does not support an agile framework.
But, how do we change the culture?  Do we change the process first and hope the culture changes with it?  Or, do we try to change the culture ahead of a process change?
At my current place of employment, agile methodologies are accepted, along with any methodology that makes sense.  There isn’t a “corporate” methodology.  I really like that.  Imagine if a company was by-the-book Scrum.  No other options.  Imagine having to beg for permission to “pilot” Kanban…ugh.
My point is this…maybe we should stop the notion of “piloting” Scrum, or Extreme Programming with the intention of rolling it out and making it the “approved” delivery methodology.  Maybe we should instead focus on sound principles that we know are true, universal, and also happen to be highly valued in agile and lean.  Principles such as:
  • The primary measure of progress is working software
  • Business and IT working together daily
  • Face to face communication
  • Reducing waste
  • Building quality in
  • Delivering as fast as possible
  • Delivering working software frequently
  • Self-organizing teams
  • Welcome change
  • Sustainable development
  • Technical excellence
  • Keeping it simple
  • Continuously improving the process
 As long as we let these principles drive our process, and people are empowered and allowed to make mistakes which will in turn promote learning, the process will work.

Filed under Agile Tagged with , ,

Up Front & Iterative Planning

November 8, 2009 Leave a comment

You know the question…”what kind of projects are best suited for agile?”.  To me, this is the same as asking “what kind of projects are best suited for empowered teams, technical excellence, servant leadership, reducing waste?”.  Would there ever be a time when you would not want these things?  I know, that is a very smart-allec response, but I just can’t help myself.

I then ask “what’s the other option?”.  This surprisingly stumps people when I ask this.  We all know there is no such thing as “true” waterfall in software.  So, to help them along, I clarify what I “think” they are asking which is “what kinds of projects are best suited for big, upfront planning and design vs. iterative & incremental delivery?”.  People almost always agree with the restatement of the question.

I believe that everything can and must be done iteratively and incrementally in software.  However, the level of “up front” may change with the type of project.  Gutting out an old accounting system and replacing it with an Oracle or Great Plains solution will require more up-front planning and analysis than a green-field Web 2.0 social networking application.

So, fellow agilists, “up-front” is not a bad word, it has to be done.  We know this already with release planning, and even sprint planning, we just don’t call it “up-front”.  Just be careful…VERY careful.  You run the risk digressing into waterfall.  At times, there will need to be more “up-front” than other times.  Always be asking yourself, “what is the soonest we can deliver value to customer?”.

Filed under Agile Tagged with , , , , , ,

What makes a successful waterfall project?

July 25, 2009 Leave a comment

I recently posted a question on linked in wanting to hear from people who have either led or been a part of a successful waterfall project.

Here’s the link. There a some awesome answers. What’s interesting is that what is required for a successful waterfall project is clearly defined scope, engaged sponsors, and a great, empowered team. Sadly, I rarely see all of these occur in the wild. And, these are the primary elements of what’s necessary for an agile project, explaining why there is a higher success rate with agile projects.

Filed under Agile Tagged with , ,

Scrum Documentation

January 2, 2009 Leave a comment

If you are on an agile team, and you are telling your team that you don’t need to document because your “agile”, stop it. Stop it right now!! You’re making my life difficult!

There is a strong stereotype out there, and its that with agile, you don’t document. Arggghhh!!! I’m sure some of you have experienced it.

Here is what I tell people when they ask about the documentation requirements on an agile project…”If the team needs it, then they will create it”. Now, I’m not talking about documents that are delivered to the customer, like help documents. I’m talking about documents such as architecture diagrams, “requirements” documents (eww), process flow diagrams, diagrams, and more diagrams.

IF these kinds of documents will make the team more productive, and produce higher quality software then document! Now, the next thing I tell people is to be LOW TECH. I mean, c’mon, do you really have to transfer that diagram on the whiteboard to visio? I’ve seen people take 2 weeks to do that, as the rest of the team is “waiting”, i.e WASTE. Why not take a picture? It’s going to change anyway, right? And, we “want” it to change, if we ever want to improve.

Remember, the end customer does not value these kinds of documents. So, DON’T SPEND A LOT OF TIME ON THEM. If your company “requires” them, then take the lowest road approach possible. Ask questions. Challenge the “process”. Processes were meant to change and improve, you should not be a victim to them.

Okay, to review….

  • Documentation can be good, if it makes the team more productive and the customer happier because of higher quality. But, BE CAREFUL
  • Low tech = Good
  • The customer DOESN’T CARE about those documents, so just take it easy there partner. Only do the bare minimum that you NEED.

Filed under Scrum Tagged with , ,