salesforce.com & Agile

When undertaking any substantial body of work, whether it be a development (coding) or project rollout, the methodology refers to the steps taken to get from beginning to end.

As a software engineer myself, I recall back in university days, we'd learn time and time again about the Waterfall methodology, image courtesy of wikipedia below:


This was a strict process, where typically the entire scope of the project was planned out at the beginning, and then the project manager would move the project through to subsequent stages. A key principle of the waterfall methodology, is that if requirements change, one must move back to the start of the process. This methodology brings a lot of discipline to project management and it was designed to ensure that the outcome exactly matched clients initial requirements.

There were a few problems with this approach though, it assumed that clients requirements were fixed and it also ran with the ethos that software developers or business analysts needed an exact blueprint of requirements and design before they could commence.

Some say that this approach showed a lack of faith in software developers and business analysts, because the project manager would have to assign them a detailed list of business requirements (written down to exact specification) before they could commence work.

The other key problem was that customers didn't always know their requirements, or could not express them clearly, and typically customer requirements would change over time. This meant that monolithic projects would last for 12-18 months and longer, because each time a customer wanted to update the system design to meet a change in their business process, the whole methodology would start from the beginning again.

A newer approach to project management is one called Agile, principles of Agile PM are:
- Software Developers & Business Analysts know what they are doing
- Requirements should be captured, but not to the infinite extent required by Waterfall
- and importantly, the customer should always get a functional release at the end of each 'Sprint'

This approach would set about discussing the top requirements with a customer (say 5-10 high level requirements), then the Business Analysts & Developers would commit to delivering these within a 'Sprint', a sprint would be a window of days, anywhere between 14-60 days usually. The programmers would work in a less structured and more collaborative way and use their own initiative and knowledge to deliver the smaller set of requirements within the rapid timeframe.

Because software development was a risky business back in the 80's and 90's, people would use this same waterfall methodology, which is also used in construction for example, in building a multi billion dollar building or bridge. But requirements dont change that often when building a bridge.... and you cant just say to a Construction Engineer, go ahead and build the arch how you see fit...

Although due to advances in software technologies, it is now a reality that usable functionality can be delivered within short periods of time (Sprints), and that developers can take a high level requirement and deliver it without the large amounts of planning and paperwork that waterfall requires.

I was watching this webinar, about how salesforce.com themselves use an Agile approach in delivering functionality to their customers.

We've built our consulting practice within my company on an agile approach also, by giving more responsibility to the developer or consultant, and by starting with a reduced set of high level requirements, and keeping paperwork low.

I feel this enables us to react faster to customer requests and deliver more value to clients because we wont over analyse and document everything we are going to do, we will document at a high level, and then simply proceed and do it, this way we can present a prototype quite rapidly to our clients, and get feedback.

0 comments:

Post a Comment