Agile Software Development Process

The agile method of product development has some great advantages with its ability to facilitate rapid prototyping, strong adaptation and flexibility, and constant collaboration.  However, despite these strengths, there are a lot of challenges that need to be overcome when dealing with client stakeholders.  Most of these can be attributed to a lack of understanding of the agile process.  It is up to your software staff to bring your clients along successfully through the process by avoiding some of the following pitfalls.

Fixed Price Agile

The agile process is about continually shifting strategy to pursue accurate agendas according to an ever-changing technology landscape. That all sounds great, but many clients shy away from the happy marriage between a time and materials agreement and agile.  They’re not comfortable saying ‘it will cost as much as it costs and we’ll pay whatever that is’. This is a rational fear stemming from disappointing experiences on past projects or with previous development partners. Therefore, you’ll need to be prepared to combine the fixed price budget with the agile process.

With this method, you cannot shift priorities without informing your client of the budgetary impact of their decision. It is imperative that new requests for new items or stories are understood in complexity and scope.  They can then be put into the backlog as part of the normal agile process but there also must be a discussion. If the budget is fixed, another item in the overall agenda may have to be removed.  This is an important distinction because clients can lose track of what is in and what is out. When their budget is exhausted there may be a lot of grief if items that were originally proposed have not been delivered.  If the budget is truly fixed, then clients need to be protected from going over budget by changing scope without an understanding of the consequences.  Any newly added items or removed items must be updated in your issue tracking system. It is the SW development partner’s responsibility to keep the customer informed and ensure that understand budget ramifications are communicated and understood.

Waterfall Proposal

The agile plan is only relevant to the current iteration or sprint. Any other schedules are simply conjectured.  No matter what disclaimers are included in your proposal, if you include a schedule in your proposal you will be held accountable to that schedule. In the waterfall paradigm, the entire schedule may be included with dates that accurately represent deliverables.  In agile the only schedule is the sprint schedule which is only accurate for a single sprint.  Resist the urge to provide even an estimated long-term schedule.  Instead, agree on the required functionality and describe the epics to be performed during the project.  Keep in mind the previous point in that new scope items may remove other items if this is a fixed price effort.  That means that even epics provided in the proposal are somewhat transient. Remember in the agile development process, the product backlog contains all of your requirements while the sprint backlog contains only your two-week schedule.

Lack of Participation in Agile Meetings

The client must have representation at both sprint planning and sprint review meetings. There should be NO exceptions to this. If you had a house being built would you just assume everything was just fine until you stepped foot into the finished house? No. You would be checking progress at every step. Software development is no different. A key advantage of agile is that the client sees the product early and often and can make necessary adjustments. If the client is not present, you’ve thrown one of the greatest advantages of agile out the window.  During sprint planning, the client should be describing and or agreeing on the proposed stories to be completed during the sprint.  Ideally, the client will have a product owner who can describe the stories in detail. (More on the case where they have no product owner later.) They must also validate all acceptance criteria on a story-by-story basis to ensure that stories are developed in accordance with the correct criteria. During sprint review, the client has the final decision as to when a story can be accepted as done. They must validate that the aforementioned criteria have been accomplished.  We’ve seen clients become “really busy” and start to miss some of these meetings. This results in a piece of software that does not meet client expectations. It this occurs, it is your fault for having allowed the absentee behavior. The longer the lapse in participation, the larger the deviation will be from what your client wants.  Your project will absolutely go over schedule if you have to make changes to functionality because they do not meet the intended specifications.

Who is the Product Owner?

Our previous point was regarding clients who don’t take the proper time to participate in the agile process. There is also a real problem with a customer who doesn’t dedicate a product owner to the project.  Even if there is a product owner defined they may not always understand the full scope of the role.  The product owner is responsible for the definition of acceptance criteria through writing stories, the sign-off on completed stories, and the prioritization of the backlog.  What we’ve seen is that clients are not prepared to dedicate the necessary resource to be a product owner so we often have to fill that role ourselves.  This can cause arguments to ensue between the stakeholders that belong to the client and the in-house product owner based on provided functionality.  It becomes extremely important for the in-house product owner to remain in sync with the customer and the development team at all times.  All conversations that happen between client and product owner need to be documented in their associated stories.

Even if the client provides an all-star product owner you’ll still probably need either an in-house product owner or account manager that can protect the team from working on out of scope items that were not in the agreed upon budget.

Where are my Requirements?

In waterfall, there is usually an eye chart of a requirements matrix that calls out every requirement that has been agreed upon.  Agile, in contrast, has no requirements matrix to adhere to.  This is new to many clients so it is important for them to understand where and how the requirements are tracked.  Requirements tracking is still a fundamental necessity, so logically there has to be a place where the requirements matrix resides, with mutual accessibility for both the client and the software team. In agile, this is the product backlog.  It contains every requirement in the form of a story.  It will be up to you to teach clients how to read through the backlog when they have a requirement question.  If the product owner is their employee, it is imperative that they understand how to use whatever tool that you’ve all agreed upon to track stories. If your backlog cannot stand as your requirements documentation it means that the stories that you’ve written are not compliant with the agreed upon requirements.

In closing, service companies can benefit from the efficiencies gained from the agile process with careful communication. Keep in mind the pitfalls outlined here to ensure that your clients and your team are in sync throughout the development process.  It is the duty of scrum masters and product owners to navigate these waters correctly and successfully so clients can realize their dreams.‍

‍