Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
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)
Tech lay offs hit 3 year high: The case for agility and project leadership!
| The employment landscape for technical jobs does not seem to have come even close to hitting bottom. This report from CNET indicates that lay offs in the tech sector will hit a 3 year high.
As the report states:
During the first half of the year, 51,529 planned job cuts were announced across the tech sector, representing a 260 percent increase over the 14,308 layoffs planned during the first half of 2011. Things are so bad so far this year that the figure is 39 percent higher than all the job cuts recorded in the tech sector last year.
Hewlett-Packard proved to be the major force behind this year's uptick in planned layoffs, after the company announced in May that it would cut 30,000 jobs. Those layoffs will be completed by the end of fiscal 2014, and shave off 8 percent of HP's entire workforce.
It was also a tough beginning of the year for Sony and Nokia, both of which said they would lay off 10,000 employees. Panasonic and Olympus are also eyeing layoffs to make their operations more nimble.
About 60% of these cuts were due to the massive job lay offs anticipated by HP which has been unable to turn around their PC centric business model to the ever growing tablet and smartphone market that has taken the world by storm. To me this makes the case of adopting more agility and project leadership into your repertoire of transferable skillsets if you are in the IT/Tech sector as I'm sure many on this site are. HP itself could have been more agile and leading more profitable and innovative projects as well!
More troubling is this graph generated from the US Dept of Labor Statistics for jobs related to "information services" the majority of which were IT services:
This was generated based on the aggregate data of the last two decades starting from June of 1992 to June of 2012. The graph highlights the peak hit during the late 90s and early 2000 during the dot com rush and reveals the continuous downward trend to near 1992 levels!
Sorry to be so doom and gloom, but if like me you are in the IT/Tech sector, then its time to assess your talents, practices and skillsets and think how you will adapt, be agile and lead projects of the future. I know I will!
During the first half of the year, 51,529 planned job cuts were announced across the tech sector, representing a 260 percent increase over the 14,308 layoffs planned during the first half of 2011. Things are so bad so far this year that the figure is 39 percent higher than all the job cuts recorded in the tech sector last year.
Hewlett-Packard proved to be the major force behind this year's uptick in planned layoffs, after the company announced in May that it would cut 30,000 jobs. Those layoffs will be completed by the end of fiscal 2014, and shave off 8 percent of HP's entire workforce.
It was also a tough beginning of the year for Sony and Nokia, both of which said they would lay off 10,000 employees. Panasonic and Olympus are also eyeing layoffs to make their operations more nimble.
|
Posted on: July 23, 2012 11:06 PM
| Permalink |
Comments (1)
Agile Constraints
| Projects whether they are done Agile, waterfall, extreme, or whatever [insert favorite practice here], boil down to a series of interconnected tasks that require you to manage and reduce the variations between them to make sure they are done on time and within budget. Often times what prevents you from reducing the variations are constraints. In other words, some bottleneck is constraining you from reaching your optimal throughput.
This type of thinking lies at the core of the “Theory of Constraints” which originated and was made popular by Eliyahu M. Goldratt in his very popular business novel “The Goal”. TOC’s approaches constraints from an overall systems view and does not concern itself with every individual task, but rather how to maximize the overall system. So you have to recognize that your project’s total throughput will be the equivalent of your bottleneck. This requires you to focus on five steps to remove your bottlenecks:
If I were to view this from a Agile/Lean perspective, I should be able to quickly find the bottleneck (I think this is very similar if not the same as Scrum’s notion of an impediment), since this is where the story cards start to stack up. Typically in software development projects where Agile is done the most, the usual bottlenecks are in QA if you do not have much automation in your testing since there can be idle time before finishing a story before having it tested.
And sure enough, others in the Agile community have made use of the manufacturing technique known as Kanban. This technique sets up a WIP limit to the most important columns on the board and is where you should find where things like testing are hitting their WIP limits frequently. This is where you could take other resources that are sitting idle to assist the testers and since you’re doing Agile, you teams should be cross functional and be able to pick up the slack. At some point the “flow” would resume.
This is a very interesting integration of various techniques to remove bottlenecks in your projects. How are you dealing with constraints in your projects?
But sure enough, the solution other’s have found is to use Kanban since it sets up a WIP limit to the most important columns on the board and is where you should find where things like testing are hitting their WIP limits frequently. This is where you could take other resources that are sitting idle to assist the testers and since you’re doing Agile, you teams should be cross functional and be able to pick up the slack. At some point the “flow” would resume.Projects whether they are done Agile, waterfall, extreme, or whatever [insert favorite practice here], boil down to a series of interconnected tasks that require you to manage and reduce the variations between them to make sure they are done on time and within budget. Often times what prevents you from reducing the variations are constraints. In other words, some
bottleneck is constraining you from reaching your optimal throughput.
This type of thinking lies at the core of the “Theory of Constraints” which originated and was made popular by Eliyahu M. Goldratt in his very popular business novel “The Goal”. TOC’s approach is from a overall systems view and does not concern itself with every individual task, but rather how to maximize the overall system. So you have to recognize that your project’s total throughput will be the equivalent of your bottleneck. This requires you to focus on five steps to remove your bottleneck:
Locate the bottleneck
Maximally exploit the bottleneck
Subordinate everything else to exploiting the bottleneck
Elevate the bottleneck (add capacity some other way)
Avoid inertia and keep checking your bottleneck hasn't moved
If I were to view this from a Agile/Lean perspective, I should be able to quickly find the bottleneck (I think this is very similar if not the same as Scrum’s notion of an impediment), since this is where the story cards start to stack up. Typically in software development projects where Agile is done the most, the usual bottlenecks are in QA if you do not have much automation in your testing since there can be idle time before finishing a story before having it tested.
But sure enough, the solution other’s have found is to use Kanban since it sets up a WIP limit to the most important columns on the board and is where you should find where things like testing are hitting their WIP limits frequently. This is where you could take other resources that are sitting idle to assist the testers and since you’re doing Agile, you teams should be cross functional and be able to pick up the slack. At some point the “flow” would resume.
|
Posted on: July 17, 2012 11:42 PM
| Permalink |
Comments (1)