During my travels last week, I had a conversation with some folks in the consulting industry. Over dinner, one expressed his frustration with Agile development cycles in a fixed price contracting scenario, citing that “nothing ever seems complete in Agile.” As you can imagine, the conversation became very animated. As we exchanged our experiences with Agile development, he contended that “Agile doesn’t control scope,” or “Agile becomes too iterative and ends up spawning more project spin,” along with a healthy dose of it’s “difficult to control Agile within a statement of work.” It became clear that he was confusing Agile development with a lack of project maturity and an immature development approach, so as we talked, I began to outline some of his concerns:
1. Scope Control
In a fixed-price scenario, controlling project scope is important for a consulting organization to control its margins. But no one ever said that Agile and scope were exclusive terms. Agile itself is a way of more aggressively controlling project scope in a way that produces something more tangible so that product construction can progress quickly and according to scope. I suggested that change control was in order, a topic on which many engagement managers wrestle with their own account managers and business development executives to address. While no one ever likes to say “no” to a customer, I contended that enforcing mature change control processes is the way of turning that around to show the customer that “this is how we can say yes.”2. Agile Is Too Iterative
When I asked the questions about this, my colleague felt as if the number of iterations tied to the scope could get away from him and become very poorly tracked. This is especially true when your proposal to win the work only covers the 80/20 proposition, the 20 percent being the big unknown. So he asked me how many iterations were necessary for completing a project. The notion I conveyed was to improve their estimation skills and knowledge base around the projects they would routinely bid so they could understand their own track record of performance. After that, it becomes easier for them to understand just how many iterations it should take to complete similar projects in the future.3. How Do You Control Agile Within a Statement of Work?
This is where the discussion became very animated as they struggled with how to control and better manage their customer, and therefore their engagements. So I detoured quite a bit on this response by asking a few more questions:- * “Do you have a strong process to determine if an Agile user story or a formal business/use case is required?” They didn’t.* “Do you ask the customer ‘what’ rather than ‘how’?” Here, they struggled with a strong response.* “How many times do they go back and forth with their customers in the iteration?” This was a simple answer: Too many.
This is a critical area for both change control and managing the engagement through their statements of work (SOW). They had never agreed on a standard with their customers for mature project change control to manage costs and time and ensure that projects didn’t run amok, nor had they incorporated provisions into their SOW to address how many times something could be changed before they asserted themselves. My answer was simple: “two.” Every iteration or Agile sprint needs to be signed off by the customer. If they’ve done the “what” based on the customer’s requirements and clear statements, made any subsequent revisions based on according to those specifications, and could demonstrate that they’d completed the requests according to the requirement, it’s time for the SOW to take over and dictate a change. It’s also long past the time when the customer needs to be educated on telling the consultants “what” to do, not “how to do it.” Selecting Agile as an approach to development projects/engagements doesn’t mean ensuring that those projects don’t also carry a healthy dose of scope/change control and the correct engagement approaches to controlling unnecessary work. Rather, Agile should teach us to do only those things that are necessary versus ignoring elements that are clearly necessary for success, and mature scope/change control are absolutely required. My colleagues in this case had neglected to consider that Agile also suggests a healthy dose of pragmatism in its approach to achieve success for their customers. Using Agile doesn’t mean that mature project methods aren’t also part of the equation. From what began as a healthy disagreement on what Agile represented, or a misunderstanding on their part, concluded by debunking these common myths and misconceptions when they responded that they “really liked those answers.”
