“Agile” An Effective System That Can Be Hard To Sell!
“AGILE”! We hear the phrase thrown around a lot especially in the development space. There are countless books, seminars, blog posts and opinions on the topic.
While we do believe in the agile methodology of development / project management its not to say it does not have it pain points. For me one of the biggest hurdles is customer adoption or for a lack of a better term Selling Agile.
A Little Bit About Me
My name is Michael Marzovilla and I am one of the managing partners here at Sego Solutions. I take on a lot of our project management tasks and work very closely with our clients.
This consists of consulting with potential clients, explaining our process, and trying to communicate how our agile workflows have proven to be not only the most cost effective but produce better results in less time.
Our Agile Workflows
I mentioned above our agile workflows. When consulting with clients we use this term to describe our development process, project management, and billing structure. Having these things well defined is paramount in easing some of the pain that you may experience in selling agile. We devloped an Infographic to help communicate this with our clients and find that this helps explain the process.
These workflows all work hand in hand and are the core of our business.
From our experiences we have found that most (if not all) clients want to know two things, how long and how much. While these are undoubtedly valid and reasonable questions in many cases they are just not possible to answer…..or at least answer accurately up front.
We have been down the road of 40 page scope documents that outline every detail that will go into a project, analyzing how long it will take for every piece, and developing a firm price and delivery date. The client signs a contract agreeing to set amount and we are off. Then something happens along the way, and to put it simply…. THINGS CHANGE.
Now both client and contractor are locked into an agreement to do 40 pages of “things”, for xx amount of dollars, due in xx amount of months and “things” are changing as they inevitably do. This makes for a bad situation all around.
With our agile workflow we bill on a time and materials basis. This means we only bill for hours that are used. There are no long term contracts or commitments to continue development past each billing cycle and our clients can evaluate our productivity throughout the entire project.
We find that this is a huge selling point as opposed to the traditional “contract” method. Most of our agreements are simply for an hourly rate with a cap on the number of hours and from there we start the process.
Another tool we use in our process is user stories. We assist our clients in creating these non technical micro descriptions of user interactions. The user stories are used to create, organize, and prioritize a series of short and focused development cycles called sprints.
During the sprint process we have frequent reviews. We use these reviews to discuss potential options with our clients, present any problems that may have been discovered, get client feedback/approval on features, and review budget and hours remaining.
This allows for us to keep track of the time we are spending to implement certain features and helps both the client and contractor decide if it is time and money being well spent. This is a huge component to why we feel agile projects stay on budget.
Above all the most important part of our projects is constant communication. Our clients play a critical part in all of our projects. Constant communication and most importantly decision making plays a big role in the final cost and time frame of the project.
We understand that you can't tell a client give me a blank check and it will be ready when its ready. We also understand the likelihood of being able to accurately outline all facets of a project up front.
So what is the happy medium? We always like to ask a client what their budget is so we have an idea of what they are looking to spend and this will help us conceptualize what can be done in that budget. We generally ask for this after an initial consultation and in some cases a follow up or two.
From there, in most cases, we can provide the following:
- An estimated amount of hours to complete the project
- An average number of hours we can dedicate to the project on a weekly/monthly basis
- An hourly rate
- A billing frequency
- A review schedule
It is these 5 things that will serve as the base of our agreement.
While I definitely agree that one of the hardest parts about closing deals with clients can be selling them on agile, I can not see going back to managing projects any other way. We have had tremendous success on projects using some of these methodologies.
Refining our process on how we present this to clients has greatly helped our adoption rate and I hope this will help some of you refine yours as well.