In an environment of uncertain budgets and evolving technology, a modular or Agile approach to acquiring new systems can provide greater cost control and flexibility. In Part I of my primer on Agile, I wrote about the What and Why of the modular approach to buying information technology (IT). Now in Part II, I’ll look at the How. First-hand experience implementing Agile for a federal agency has proven that it takes upfront training and a dedicated team approach to make this concept work.
What and Why Recap
What: Agile is a modular paradigm in which you award smaller, short-term contracts to a wider field of vendors. You buy capabilities in an incremental format to achieve overall project goals. This acquisition concept lends itself to purchasing IT where the technology changes rapidly. It allows for building the capability gradually, resulting in the final solution.
Why: The Office of Management and Budget (OMB) has identified six benefits of using an Agile or modular approach: speedy delivery of usable capabilities; increased flexibility to adopt emerging technology; decreased risk of missing cost, performance and schedule goals; increased opportunity for small business to compete; better contractor performance through closer monitoring; and fewer sunk costs resulting in greater investment control.
Lessons from the Field
Having worked with a large federal agency, I can pass on a number of lessons learned for acquisition professionals in the IT arena using Agile methodology.
Training is required. Everyone on the team must fully understand what Agile is and why it’s being used. Some folks look at it as one big to-do list, but I found value in the Agile way immediately. Training is a necessary time investment to ensure everyone fully understands how Agile is applied to generating product in an efficient manner. Agile also takes practice. Even when everyone agrees on the benefits, it can take time to get used to the cycles involved.
Collaboration is key. The process starts with establishing an integrated product team (IPT) which begins work with an initial planning meeting. This could take from two hours to half a day to strategize what you want to accomplish. In the initial planning meeting you won’t know all the answers. The beauty of Agile is that it’s a continuous iterative process where you’re working on part of the overall plan one piece at a time.
Short Sprints are part of the process. When standing up a project you create Sprint cycles. The first Sprint might be to develop the plan. Or it might be to put a contract together and you know what you need, so the Sprint is to gather the information to make that happen. Choose a handful of tasks to complete during the Sprint, assign people to them and have them focus only on those tasks for a two-week period.
Frequent review measures progress. Every couple of days, review the work that’s being done in a Scrum or brief meeting. Whatever is not completed goes into the Backlog. At the Scrum ask, “What did I do yesterday, what am I going to do today and what are my hurdles?” Hurdles can be internal or external. For example, if you’re waiting for a piece of information from outside the agency it can be a hurdle. It’s the job of a Scrum Master or facilitator to listen, compare progress with the backlog and determine if the team is executing according to the plan.
Scrums should be short. More meetings? A Scrum session is only supposed to be 15 minutes – a very pointed and immediate assessment of progress. The job of the Scrum Master is to keep the discussion moving and keep people focused on their tasks. If done right, it’s useful and is not a painful process. Scrum Masters require certification and should be skilled at implementing the Agile methodology.
You’re never really done. It’s okay to carry backlog over to the next Sprint, but you have to understand what that means: if you don’t make it, are you going to have to extend your schedule? Does it affect your cost? Think about Program Management 101: At the conclusion of every Sprint, ask how the work affects your cost, schedule, and performance.
Expect mid-way challenges. The nature of government is such that agency leaders and senior executives come and go faster than projects get completed. Agile has the flexibility to deal with change. Still, if a change of direction happens after several Sprints, or if new team members are assigned to the project, it could require another planning meeting to set an adjusted course.
Cross-Communication keeps the project moving. If you’re working on part of a very large project, things that happen within other teams can affect what you’re doing. Using the Agile method on big projects, no group should work alone. For example, program managers can brief Directors of Engineering, Deployment, etc. who then should regularly communicate between project groups.
Stakeholder feedback is vital. Who are your stakeholders? The customers you are acquiring services, systems or products for. They have a huge stake in what you’re buying for them and should always be consulted. Other stakeholders include those funding the project. They have to make sure that what they’re paying for is useful to the government. Stakeholder consultation should happen upfront and throughout the project
Make Agile “Magic”
The word “Agile” means being able to move quickly and easily. Can an acquisition, especially an enterprise level solution, really be nimble, or spry? The “magic” of Agile is that it focuses on smaller pieces. These basic concepts, when applied incrementally, are proven to result in a more effective, cost-efficient way to purchase and develop IT capabilities.
