Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
The third face of Agile: A solution in search of a problem
| In this blog by Mike Cottmeyer, he talks about the "two faces of Agile" where one is emergent, in that you are involved in an R&D like project where you are "experimenting, learning, and adapting (your) approach based on super-fast feedback cycles… and the outcomes, the products they are trying to build, are emergent. The end goal isn’t necessarily clear at the start". This is in contrast to the convergent type, where you are "to figure out the right products to build, but their markets have a predetermined notion of what to expect...but the outcomes, the products they are trying to build, need to converge around set expectations."
In other words, his argument is that Agile project typically have a clear end goal or one that will emerge.
An approach I think that is missing from the above is what I refer to as the dependent type, which is basically the reverse of the emergent type. It is an R&D project that runs in reverse. You have or know exactly what the solution will be, but you have just not discovered an application for it. So the end goal of the solution is dependent on the application of the solution and if that application delivers business value. It's a solution in search of a problem.
A good example of this would be Google+. Google+ is the latest addition to the social networking platforms with Twitter and Facebook as dominant leaders. Though it rose quickly the user base growth has tapered down and new entrant Pinterest has already surpassed it. Its initial claim to fame was its deep integration with its powerful search capabilities, but that has so far not been compelling enough to gain momentum to challenge Facebook and Twitter. Google+ is now adding business collaboration features to gain business users (and most likely to intercept momentum of Microsoft's acquisition of the business social networking site Yammer).
Even when you have a solution and the backing of a mult-billion dollar tech company, you will still need to be agile, adaptive, experimental and continuously iterating to find the right application to your solution! The Google+ example clearly highlights this dependence. |
Posted on: September 01, 2012 01:24 PM
| Permalink |
Comments (1)
Building a car in 90 days using Scrum!
| In line with my recent postings about Agile/Scrum being deployed outside software development, here's a TED video about a sports car called "Wikispeed" that was built and deployed using Scrum and crowdsourcing:
As further proof of this movement in the auto industry, I saw this job posting on GM's job site for an Agile Coach/ScrumMaster position. It does a fairly good job of describing the position that is in line with Agile/Scrum practices: The agile coaching team is a core part of the GM IT transformation to deliver software faster, and with strong business focus. The team of agile coaches supports this historical transformation by developing agile best practices, providing training and active mentoring on projects. We are the “How To” team for Agile development...
The Agile Coach is not only an expert in agile techniques but is also adept at change management through influence and facilitation. This role will work actively with the Project Manager and the development team to transform them to be a self managing SCRUM team. In this role, the Agile Coach conducts internal training sessions to the broader GM IT team to foster agile adoption. As the central role in helping GM IT to deliver software faster, the Agile Coach will have the unique opportunity to work on projects across the entire GM portfolio in functions such as product development, manufacturing, supply chain, sales, marketing, and finance.
It's interesting to see the continual adoption of Agile/Scrum outside of purely software development environments. Are you witnessing such adoption where you work?
The agile coaching team is a core part of the GM IT transformation to deliver software faster, and with strong business focus. The team of agile coaches supports this historical transformation by developing agile best practices, providing training and active mentoring on projects. We are the “How To” team for Agile development...
The Agile Coach is not only an expert in agile techniques but is also adept at change management through influence and facilitation. This role will work actively with the Project Manager and the development team to transform them to be a self managing SCRUM team. In this role, the Agile Coach conducts internal training sessions to the broader GM IT team to foster agile adoption. As the central role in helping GM IT to deliver software faster, the Agile Coach will have the unique opportunity to work on projects across the entire GM portfolio in functions such as product development, manufacturing, supply chain, sales, marketing, and finance.
|
Posted on: August 24, 2012 08:09 AM
| Permalink |
Comments (4)
Agile for radio program development?
| I’ve written numerous blogs here about Agile practices and methods that go outside of software development such as my recent one about the government adoption of Agile, to orchestras that are run without conductors, and even baby planning using Scrum. Another example I just found is an article about how the news radio channel NPR is using Agile, to develop and release radio programs faster and cheaper.
It seems the traditional method of developing new NPR programs involved a waterfall like process of a lot of upfront planning, time and costs to create a new show that could be prepared for launch. New programs were typically deployed slowly taking months to years and had costs in the upwards of millions of dollars.
Compounding this issue is the current economic downturn that has cut into the public radio funding. I’m sure the 2011 scandal involving the former high ranking NPR executive blasting the ultra conservative tea party as being blanket racists and critiquing their solicitation of taxpayer money certainly didn’t help.
Due to this, the new NPR vice president of programming, Eric Nuzum, decided to use Agile to develop their programs where more of their potential listeners had an active involvement, while also delivering the programs quicker and with less money:
The network seems to be taking a page from agile software development, the philosophy that products should be released early and iterated often. The shows are live (cheap) and/or adaptations of existing shows (easy), all produced in six- or 10- or 13-episode pilot runs instead of as permanent offerings. Listeners and local program directors are invited to help shape the sound of the programs, making it something of a public beta... Nuzum said the nimble approach to programming is more or less the new normal at NPR. “Whether [these shows] have a future or not, I’m really proud of what we’ve come up with,” he said. “The bigger experiment is the process…This wouldn’t have been possible a couple of years ago.”
While I’d have to say that their use of Agile would be more “in spirit” than in principle, I will nevertheless grant that this is another great example of Agile thinking and mindset influenced by the Agile software development movement, that is being utilized outside software development.
|
Posted on: August 16, 2012 08:04 PM
| Permalink |
Comments (1)
Agile government?
| I had a chance to read the US GAO report on the use of Agile in the government sector in its entirety. It has some pretty eye opening facts. Apparently (and not surprisingly) the government is waking up to the incredible waste that goes on with procuring software for the Federal government. A good example would be the FBI's "Virtual Case File" system project that was cancelled after five years of effort and spending $170M dollars. So in 2010, they decided to pass a law requiring the DOD to adopt agile practices when procuring software and the report details what they did and the results they found. As the GAO site states:
Federal agencies depend on IT to support their missions and spent at least $76 billion on IT in fiscal year 2011. However, long-standing congressional interest has contributed to the identification of numerous examples of lengthy IT projects that incurred cost overruns and schedule delays while contributing little to mission-related outcomes. To reduce the risk of such problems, the Office of Management and Budget (OMB) recommends modular software delivery consistent with an approach known as Agile, which calls for producing software in small, short increments. Recently, several agencies have applied Agile practices to their software projects.
Federal agencies depend on IT to support their missions and spent at least $76 billion on IT in fiscal year 2011. However, long-standing congressional interest has contributed to the identification of numerous examples of lengthy IT projects that incurred cost overruns and schedule delays while contributing little to mission-related outcomes. To reduce the risk of such problems, the Office of Management and Budget (OMB) recommends modular software delivery consistent with an approach known as Agile, which calls for producing software in small, short increments. Recently, several agencies have applied Agile practices to their software projects.
From the report it seems the federal government encountered the same issues and problems that would be found in commercial software development. Here's list of what they found:
But then here are some of the items they had success with:
Despite the initial setbacks, the GAO recommends "that the Federal CIO Council, working with its chair, OMB’s Deputy Director for Management, include practices such as those discussed in this report in the Council’s ongoing effort to promote modular development". Some facts to back this up is the FBI's Virtual File Sytem that got ressurected as the "Sentinel" case management system, where an in-house agile team of the FBI finished over 80% of the work in 10% of the budget after Lockheed Martin was issued a stop work order for their horrendous waterfall performance. It will be interesting to see how well the goverment does Agile indeed! |
Posted on: August 10, 2012 08:10 PM
| Permalink |
Comments (2)
Agile’s Costly Confusions?
| This article by IT World Canada outlines a report by done by Voke Inc., a technology consulting firm, in which they conclude that Agile methods can cause costly confusion, due to the lack of knowledge about its implementation’s long term costs.
According to the article, the report:
Was based on a survey of 200 different companies using agile methods. Participants in the survey were asked how much they knew about the costs of reworking code, what benefits agile provided them and even what the definition of agile was.
Many companies using agile development methods don’t have a clear picture of the long-term rework costs, says Theresa Lanowitz, a Voke analyst who worked on the report. Forty-four per cent were unable to give a dollar figure. Another 35 per cent couldn’t identify a single benefit of agile, yet were able to name 35 challenges they encountered with the method. Not only was there confusion about how to apply agile concepts, but there were 100 definitions of what the term even meant, she added.
The report’s conclusion seems to be centered around the idea that businesses grappling with this dilemma found less than optimal value when moving toward a development method that was put in the hands of the development team to control. Or as the Voke reports asserted, businesses view it as a “mandate to participate in the developer-centric movement called agile”.
I tend to agree with one of the critics of the report, Israel Gat from the Cutter Consortium, who maintains that it is up to the business groups to be engaged in the software projects. In Scrum, this would mean having a solid Project Owner to ensure the business requirements are vetted and prioritize so that the working deliverable captures what is needed by business. This is what ensures that business gets engaged… at the end of each iteration, they will see their vision realized more and more and you may have to work to disengage them a bit if you’re doing your job right!
And just throwing vague requirements over the wall to developers and expecting them to do be self-organizing and agile without organizational adoption and support is most likely not to succeed. As the article concludes, it’s not that Agile’s “precepts are difficult to assimilate, but rather that some businesses aren’t committing themselves to learning and applying it”.
|
Posted on: July 31, 2012 10:31 PM
| Permalink |
Comments (2)