Agile Methodologies

When people read my blogs and articles, or take my courses, some respond with "We don't need to do that. We're an agile shop.". When I hear that I immediately think, "Do you know what an agile methodology is?". Look up "agile" in the dictionary. All it means is "Quick to respond".


I am a proponent of agile methodologies for software development. The classic waterfall model, as taught in a number of Project Management courses, does not work and never has. It assumes you can complete every step in a project completely and never have to revisit it. Nonsense! That's not how we build stuff. We build as a series of iterations with each iteration building upon the last.


I remember a few Project Managers from my past trying to impose a waterfall methodology on a project, and it never worked. Caused nothing but problems and unhappy customers.


The problem is that many people, especially developers, believe that an agile methodology allows them to do whatever they want, get feedback from the client and then change it, over and over and over again, until it is what the client wants. Throw Project Management out the window. Talk about the long way to get to somewhere, rework after rework after rework.


Why then do some instructors continue to teach the waterfall method as if it's the only way to develop software? Because that's what they were taught and they can't get beyond that.

I continue to teach about the Requirements, Design, Development, Testing and Deployment Phases of a project, not because they need to be done in that order completely, but because they all require different skills, tools and techniques to accomplish and have different best practices. It's just a good way to divide up the material. Don't assume it means that you must do the 5 phases in order with no overlap. Just doesn't work.

What is Business Analysis?

According to the International Institute for Business Analysis (IIBA);
 

“Business analysis is the discipline of identifying business needs and determining solutions to business problems. Solutions often include a systems development component, but may also consist of process improvement, organizational change or strategic planning and policy development. The person who carries out this task is called a Business Analyst or BA.”

 OK, now that we’ve got that taken care of, let’s talk about what it really is and why it’s needed.

Software has a dismal track record.  Most software projects finish well over budget and very late.  A company that budgets $200,000 for a software project may end up spending a million to actually get it.  Are you into the third year of your one year project?

We need to do better.

Prior to the 1990s programmers designed and wrote software pretty much by themselves.  Desktop computers were relatively new, very expensive and there was still much resistance from business.  Users didn’t understand the capabilities of computers.  Most software projects were initiated by IT.  Techies who understood computers had the vision and acted upon it.  But like an artist, they had no idea, nor did they care, about how much or how long it took to realize that vision.  Some really great, beautiful, elegant software was created, but it was art, and very expensive art at that.

Companies started to realize that the situation was not supportable.  You have to treat software development as a construction project.  There’s only so much that you can build for so much money in so much time.  We’ve been doing this with other things for centuries.  Buildings, bridges, roads, railways...

An examination of software projects that were well over budget or behind schedule showed that the number one reason for that was scrap and rework, meaning the programmer built something, showed it to the client, was told it was wrong and had to go and do it again.  The fastest and cheapest way to build anything is to build it once.  The only way that can happen is if the person building the product knows what the client wants in sufficient detail to build it.  That is the goal of a Business Analyst.

Every software product is based on someone’s vision.  When the client looks at a piece of software and says, “That’s not what I want.”, ”That’s not what I need.”, “That’s not what I asked for.”, it’s because it does not meet their expectations, in other words, it does not match their vision.  That’s because there were two different visions, the one the client had and the one the programmers had.  The programmers obviously built to their own vision.

The goal of Business Analysis is to make sure the product created meets the client expectations.  In order to do this the Business Analyst must capture the client vision, articulate it, document, validate it and communicate it to the development team.  In other words, to make sure that the product developed is according to the client vision.  There should only be one vision and it should come from the client.

Capturing that vision, articulating it, documenting it, validating it, communicating it and validating the product created, requires skills, tools and techniques that I will expand upon in subsequent entries.