The word “agile” seems ubiquitous. I hear people talk about it all the time and see “agile” written in requests for proposals (RFPs).
In fact, just this week I saw a draft RFP for Agile Services with an estimated value of $100 million. Needless to say, agile is in high demand. It’s worth a lot if you know how to do it right.
There is a group of techies within the General Services Administration (GSA) that call themselves 18F (the GSA building is located at 18th and F Streets NW, Washington DC, just a couple blocks from The White House). They recently released an RFP for a Blanket Purchase Agreement (BPA) for Agile Delivery Services (ADS) worth $20 million. Those 18F folks blog about agile all the time.
When people contact me to inquire about our web services and I ask what they seek; they often say they are looking for an “agile” web designer. When I ask what they mean when they say “agile” I get a variety of responses.
Many start by lamenting about their current contractor that is not responsive to their needs, does not return phone calls or emails in a timely manner, or doesn’t understand the requirement.
So, I presume their definition of agile is the ability of a contractor to respond, i.e., be responsive to and understand their business needs. To some extent, I agree. Contractors, whether agile or not, should return phone calls and emails. And, hopefully, contractors are not so limited in their thinking that they can’t put on a business analysis hat or consulting cap, practice empathy, and understand the problem from their client’s perspective.
In fact, in Agile terminology, we would use techniques like User Stories, Backlog Development, and Sprint Planning to create a meaningful dialog with our clients, understand and document their needs, and get everybody in sync with a common understanding of the problem that needs to be solved. Moreover, when we hold Daily Stand-ups and encourage clients to participate in these 15-minute rituals then certainly 24 hours won’t go by without a client’s phone call or email getting addressed.
When I read “Agile” in context, I often see writers imply “flexibility” meaning they want the ability to change their mind and the scope of work (SOW). In fact, in the first line of that $100 million Agile Services RFP, I read, “the Office of Information Technology (OIT) requires highly-productive, innovative, collaborative, and flexible Agile services…”
Fortunately, with Agile, we embrace change … as long as it’s not in the middle of a sprint. Let me get through this sprint and then I would be happy to discuss your changes, unless you want to cancel the sprint altogether. In that case, we can discuss those changes right now.
When I talk to other web companies in the area and ask about their Agile Methodology, some proudly respond by saying they are hackers and hold 54-hour weekend hackathons to ensure that what was supposed to have been designed, developed, tested, and delivered between Monday through Friday gets done over the weekend before their client comes into work the following Monday morning.
I suppose I can understand the thought process of this response although, growing up, I always thought a hacker was a bad thing … somebody who never really went to school but just “hacked” their way through life. They don’t read instructions but instead, just hack it. Back in the day, a hacker would jerry rig something to fix an object to a working condition in a haphazard way … like duct taping a dangling headlight of a car instead of doing it the right way.
Regarding that 54-hour weekend hackathon to make up for over-committing to a sprint or gold-plating a project; since we do need to have a work-life balance to maintain a healthy lifestyle, I don’t think burning the candle at both ends to get done during the weekend what was supposed to have gotten done during the week is a good definition of agile. Like a rubber band, when you stretch your life out, it often snaps back. Burning yourself out week after week, sprint after sprint, is not sustainable. Not only that, working all night under these stressful conditions often leads to poor quality control, lack of documentation, and sloppy shortcuts.
In fact, with Agile, we have something called Velocity, Story Points, Fibonacci Sequence, and a Burn Down Chart that helps us estimate the size of a task, bite off only what we can chew, gauge our progress, and pace ourselves appropriately so we don’t burn out. Just because we use a burn down chart doesn’t mean we have to burn ourselves out. Moreover, we use Sprint Reviews and Retrospectives to help us get better at estimating and breaking down User Stories into Tasks or clumping User Stories into Epics so we can manage our time better and balance our lives for long-term sustainability.
When we read the 18F blog, we also see the word “lean” used again and again. 18F often references Lean Startup Principles. Earlier in this post, I referenced an RFP for Agile Services worth $100 million. When I read over that draft RFP, I again took note of the recurring use of the word “lean”. By lean, the author of that RFP meant lean processes and lean thinking that focuses on the elimination of waste in processes to reduce cycle times.
Lean. Agile. Lean. Agile. That is why we call ourselves Agileana. We strive to be lean and agile. We strive to lead by example and show, not tell, what Agile means and how it can be an effective methodology for managing projects that range from writing a book to building software, from planning a community to planning a vacation.
Agile is a lean and flexible methodology that focuses on delivering the most important priorities at a time using a series of smaller, successive iterations. By reducing scope, estimates are more accurate and tasks are more manageable.
For Agile to work, organizations should take an all-in approach. Doing hybrid agile often leads to failure and disappointment. Not only that, if a client wants their vendor to be agile and flexible, then it is equally important for the client to be agile and flexible as well.
Indeed, when we talk about the various factors of project management, i.e., scope, time, money, and quality; it is important to understand that if we fix any one of these factors then one or two other factors must be fluid or flexible. Otherwise, it’s not really agile.
In other words, if we are dealing with a firm-fixed price contract then it would be important to have a fluid-flexible scope of work. If quality (acceptance criteria) is firm or fixed then scope, cost, or time must be fluid or flexible. That’s agile.
