By Dick Stark
I’m mostly finished with Mark Schwartz’s just published book, “A Seat at the Table,” and like the 2016 book, the DevOps Handbook, I’ll dedicate several blog posts to this excellent book. “A Seat at the Table,” is definitely worth a read. Mark Schwartz, by the way is the one that is credited to helping bring Agile into the Federal Government when he was the CIO at USCIS.

What exactly is Agile project delivery? Well, like the US Supreme Court definition of obscenity as “we’ll know it when we see it,” Agile paradoxically, is, “we’ll get there when we get there.” This is not to imply that Agile has no sense of urgency. On the contrary, Agile, according to Mark Schwartz is, “we should inspect and adapt frequently, rather than slavishly following a plan.” This is opposed to the way that the rest of the world typically delivers projects.

RightStar follows a process for new business development that begins by working with prospects that have pains, like poorly defined code version control, release management, and testing processes. We propose a solution consisting of software such as Jira, Bitbucket, and Bamboo, combined with RightStar consulting services. Then we deliver a price quotation along with a statement of work, either fixed price, or T&M, with identified deliverables. We follow the project in a waterfall approach, as detailed in our project plan or work break-down structure. If changes crop up, we either ask for a change order or work the change for “free” because the customer often indignantly states, “how could you have not known our real requirements.” We normally prefer T&M contracts to try to avoid this scenario. When working a FFP project, we typically include a FFP premium to cover any contingencies that might arise along the way.

The challenge with Agile projects is the customer’s contract process. A prospect doesn’t normally give us a contract to provide a “we’ll know it when we get there,” contract. Instead we have a contract with fixed requirements and deliverables. This is often not ideal, because neither the customer nor RightStar have a very good idea about what the customer’s real needs are until we begin the project.

In contrast, we deliver our Atlassian projects on an Agile basis. The process begins by understanding that the limiting factors are time and cost. Scope is variable factor. The key is to ensure that we have quoted sufficient hours to the customer so we can implement most if not all of their business requirements in the allotted time.

When we start an Agile project, we begin by making sure that the customer understands that we will focus on the highest priority business needs at each point of the project and that the lower priority items may not get implemented within the authorized budget.

Regarding customer satisfaction, an Agile approach that emphasizes fast implementation through incremental scope lets the customer clearly see the progress of their project. In a waterfall approach, the customer specifies all of their requirements and then we go off and implement, according to the specification. Occasionally, we will discover during go-live, that we didn’t build the system they had expected. Our experience is that most customers don’t fully understand the Atlassian tools until they actual start to use them. Asking them to accurately define their requirements at the outset is an exercise in frustration. An Agile approach therefore allows for iterative and continual customer satisfaction. No surprises ever!