This article in Bank Systems & Technology states that Capital One is now using Agile methods for 85% of software development projects. The indications seem to be that it has been quite successful for them, as the article states:
When Capital One started to roll out agile development in 2011, Wolfs said it amounted to just 1% of software that was delivered. Today, 85% of software is delivered by the agile method. With agile, Capital One now also releases approximately 400 products a month, has cut delivery times to three to six months while "cutting costs significantly," and finds 95% of products meet expectations on the first release, according to Wolfs.
This is all good, but one thing these kinds of articles do not talk about is what to do when a newly implemented method or process like Agile becomes routine and the initial gains taper off. I witnessed a similar phenomenon at a prior employer where there was an initially high performance increase and waste reduction after implementing Six Sigma and Lean, but once they started to taper off, it became harder and harder to maintain those gains.
At one point, people were spending more time trying to optimize processes that were already optimized as much as they should be where the gains were hitting the point of diminishing returns. I call this the “90% problem” since once you hit that milestone to where ninety percent or more of a method or process becomes the de facto standard in any organization, the costs to get the remaining 10% outweigh the profit of trying to achieve it. But because people are so close, they spend way more time than is necessary trying to achieve 100% which is impossible.
This is where it becomes more of a liability and when people or organizations start giving up looking for a “new solution”. It’s an ever recurring cycle. My feeling is that Agile itself has hit this productivity wall. Now the question is what is the “next new thing”?
It is dawning on me that in the world of project management (and business management in general), that we are too obsessed with managing complexity and reducing chaos which are becoming more inevitable in our increasingly dynamic and hyper-connected world. The concoction of tools, methods and processes that has flourished in the Agile community in the past two decades has all been in one manner or other, simple variations to address complexity and the ensuing chaos that results from this.
Maybe it is time to go the other direction and embrace complexity and exploit chaos. This is very new and I’m still thinking it through, but rather than the reductive process of extrapolating out the clearly defined project activities in a controlled iteration, could there be a way to let these “run loose” so to speak, see what kind of behavioral patterns and team dynamics result and just help facilitate the team to channel the flow patterns till they deliver what they need?
I know this is what many of the well know Agile methods are supposed to facilitate, but I don’t think they go deep enough or really exploit the small perturbations that could result in big breakthrough productivity gains.
In any event, rather than Agile I would like to call this Fragile project management. Because it’s the kind of project in which you must constantly “handle with care.” More explorations to come!
I have written extensively on this blog about the adoption of the Agile mindset to industries outside software development. I find this trend interesting as it indicates that the profession we are involved with comes equipped with tools, techniques and most importantly, a conceptual model of project management that’s applicable to all industries. That this trend is increasing is a great barometer on the future viability of this profession.
So it comes as no surprise that I run into this article about adopting the Agile mindset to the multi-channel marketing field of commerce. As the articles states:
Agile Commerce is the fresh and new approach to commerce in 2014, and it’s a critical way of thinking that you can’t risk overlooking… Undoubtedly customer sales and engagement channels are ever evolving; from brick and mortar stores, e-commerce stores, social media platforms, mobile as well as all the traditional media channels. For this reason, the focus needs to shift away from the “inside out” approach – companies looking at channels as individual silos, and instead look “outside in” by looking at the customer journey and the roles that each channel plays in the broader context to serve your customer. The reality is that customers are interacting with your brand across multiple channels in multiple ways. This realisation is at the core of the Agile Commerce methodology – Agile Commerce is about optimising the customer journey not just individual channels.
Aside from the faddish and incorrect use of terms like “Agile methodologies” that pepper the article, it is interesting to see this retail marketing group appropriate ideas from the Agile canon to discuss ways of incorporating better customer engagement and process to deploy marketing channel distributions faster.
From a purely practical perspective, this indicates that for us whose bread and butter is developing and applying project management methods and concepts, that we will be poised to be the ones who could lead these initiatives. We just need to think and break out of our IT industry box!
Last November I wrote a post on the initial botch up of HealthCare.gov’s use of Agile techniques on the front-end that didn’t help them deploy the site more efficiently, nor effectively. So it was with interest that I ran into this Time article where it seems they brought in some heavy hitters from Silicon Valley and revamped the site so that it now at least is workable.
So the article points out the broken contracting process (no surprise) and the idea that the “traditional” methods of deployment were just too old school:
But one lesson of the fall and rise of HealthCare.gov has to be that the practice of awarding high-tech, high-stakes contracts to companies whose primary skill seems to be getting those contracts rather than delivering on them has to change…
One of the things that shocked [the rescue] team most–”among many jaw-dropping aspects of what we found,” as one put it–was that the people running HealthCare.gov had no “dashboard,” no quick way for engineers to measure what was going on at the website, such as how many people were using it, what the response times were for various click-throughs and where traffic was getting tied up…
What saved it were stand-ups... The stand-up culture–identify problem, solve problem, try again–was typical of the rescue squad’s ethic.
But wait a minute, didn’t the government contracts stipulate that they use Agile last time? What was different this time? You can read the article for more details, but my feeling is that it is often times easier to fix problems that have already revealed themselves. And with such a large and public deployment like HealthCare.gov that did so badly the first time around, people’s expectations were as low as you could go so any improvements would look great.
Would getting the elite, heavy hitters from Silicon Valley initially been more beneficial? Maybe, but then they would have dropped in with a style that is very contrary to the government’s style of IT deployments that it may have created more problems. We’ll never know, but the lessons learned from this are one’s that we as project professionals should pay heed.
I found this article on the Defense.gov website and it seems they made a decision to go Agile with how they procure and deploy IT:
So, based on recommendations contained in the 2009 Defense Science Board Report, the department is working to speed up the route to acquiring new systems by increasing collaboration and improving processes, McFarland said.
“To do this, one must start with the defined requirement or capability,” she added.
In the past, once an IT requirement or capability was defined, organizations were able to acquire only that technology which precisely met the predefined parameters.
The introduction of the “IT box” concept is a significant change to the IT acquisition process, McFarland said. The IT box gives organizations the ability to acquire technology that improves on already-approved technology, as long as the changes don’t exceed certain parameters.
In addition to the IT box, the department has introduced interim guidance to adopt “modular, open system methodology, with heavy emphasis on design for change,” which will help DOD adapt to the changing IT environment, the assistant secretary said.
“The policy addresses the realization that IT capabilities may evolve, so desired capabilities can be traded off against cost and initial operational capability to deliver the best product to the field in a timely manner,” she said.
I still find the statement confusing. On the one hand, they are saying they need IT requirements to meet "predefine paramaters", but will also need to heavily emphasize "design for change".
Maybe the goverment works in a different reality, but that's not how Agile typically works. If I'm wrong, please let me know!