Agile Doesn’t Mean Endless

So Agile development is great for iteratively working closely with customers to develop and refine information systems that are useful to them and the organization.


But even in Agile, there is a beginning and an end to the sprint planning and project management.


Taking Agile to somehow mean endless in terms of adding more and more requirements or scope creep is not what is intended. 


Agile has to be bound by common sense somewhere between what is needed for a minimally viable product (MVP) and what is achievable with the designated resources, objective, and scope. 


Good project managers always have to be sound arbiters and be willing to ask the tough questions and determine if something is truly a requirement or simply a wish list item that is out of scope (but of course, could perhaps make it in for future enhancements).


We need to understand the difference between genuine customer service and irrational project exuberance based on inflated expectations. 


It’s not a dangerous project bubble we want to create that can and will get busted, but rather a successful project that is delivered for our customers that help them do their jobs better, faster, and cheaper.  😉


(Source Photo: Andy Blumenthal)

Winning Respect Of The People

Winning Respect Of The People

Please see my new article here in Public CIO Magazine on how we can learn from the technology industry to improve our nation’s government.

“We can solve technological problems beyond our forefathers’ wildest dreams, but we’re challenged to break political gridlock. compromise, make difficult decisions, and forge a balanced, reasoned path forward.”

Hope you enjoy!

Andy

(Source Photo: the talented Michelle Blumenthal)

At The Speed Of Innovation

Mars_explorer

Here are three perspectives on how we can speed up the innovation cycle and get great new ideas to market more quickly:

1) Coordinating R&D–While competition is a good thing in driving innovation, it can also be hinder progress when we are not sharing good ideas, findings, and methods in a timely manner–in a sense we are having to do the same things multiple times, by different entities, and in some more and other in less efficient ways wasting precious national resources. Forbes (10 February 2012) describes the staggering costs in pharmaceutical R&D such that despite about $800 billion invested in drug research between 2007-2011, only 139 new drugs came out the pipeline. Bloomberg BusinessWeek (29 Nov 2012) notes that for “every 5,000 to 10,000 potential treatments discovered in the lab, only one makes it to market” and out of the pharmaceutical “valley of death.” The medical research system is broken because “there ultimately no one in charge.”  The result is that we are wasting time and money “funding disparate studies and waiting for researchers to publish results months or years later.” If instead we work towards our goals collaboratively and share results immediately then we could potentially work together rather than at odds. The challenge in my mind is that you would need to devise a fair and profitable incentive model for both driving results and for sharing those with others–this is similar to a clear mandate of together we stand, divided we fall. 

2) “Rapid Fielding”–The military develops large and complex weapon systems and this can take too long for the warfighters who need to counter evolving daily threats on the battlefield. Federal Computer Week (19 July 2001) emphasizes this point when it states, “Faster acquisition methods are needed to counter an improvised explosive device that tends to evolve on a 30-day cycle or a seven-year process for replacing a Humvee.” There according to the Wall Street Journal (11 December 2012) we need to move to a model that more quickly bring new innovative technologies to our forces.  The challenge is to do this with reliable solutions while at the same time fast tracking through the budgeting, acquisition, oversight, testing, and deployment phases. The question is can we apply agile development to military weapons systems and live with 70 to 80% solutions that we refine over time, rather than wait for perfection out of the gate.

3) Seeds and Standards–To get innovation out in the hands of consumers, there is a change management process that needs to occur. You are asking people to get out of their comfort zone and try something new. According to Bloomberg BusinessWeek (17 December 2012) on an article of how bar codes changed the world–it comes down to basics like simplicity and reliability of the product itself, but also seeding the market and creating standards for adoption to occur. Like with electric automobiles, you need to seed the market with tax incentives for making the initial purchases of hybrids or plug-in electric vehicles–to get things going as well as overset the initial development expense and get to mass development and cheaper production. Additionally, we need standards to ensure interoperability with existing infrastructure and other emerging technologies. In the case of the electric automobiles, charging stations need to be deployed across wide swathes of the country in convenient filling locations (near highways, shopping, and so on) and they need to be standards-based, so that the charger at any station can fit in any electronic vehicle, regardless of the make or model. 

Innovation is the lifeblood of our nation in keeping us safe, globally competitive, and employed.  Therefore, these three ideas for enhancing collaboration, developing and fielding incremental improvements through agile methodologies, and fostering change with market incentives and standards are important ideas to get us from pure exploration to colonization of the next great world idea. 😉

(Source Photo: Andy Blumenthal)

SDLC On Target

Sdlc

I found this great white paper by PM Solutions (2003) called “Selecting a Software Development Life Cycle (SDLC) Methodology.”

The paper describes and nicely diagrams out the various SDLC frameworks:

– Waterfall
– Incremental
– Iterative
– Spiral
– RAD
– Agile

It also provides a chart of the advantages and disadvantages of each framework.

Finally, there is a simple decision cube (D3) based on time horizon, budget, and functionality for selecting an SDLC framework.

This is a very useful and practical analysis for implementing SDLC, and it aligns closely with the guidance from the National Institute of Science and Technology (NIST) Special Publication (SP) 800-64, “Security Considerations in the Systems Development Life Cycle” Appendix E that states:

“The expected size and complexity of the system, the development schedule, and the anticipated length of a system’s life may affect the choice of which SDLC model to use.”

While NIST focuses on the time horizon and complexity versus the PM Solutions Decision Cube that uses time horizon, budget, and functionality, the notion of tailoringSDLC to the project is both consistent and valuable.

Just one more resource that I found particularly good is the Department of Labor IT Project Management guidance (2002)–it is a best practice from the Federal CIO website.

I like how it integrates SDLC, IT Project Management, IT Capital Planning and Investment Control (CPIC), and security and privacy into a cohesive guide

It also establishes project “thresholds” to differentiate larger or more significant projects with greater impact from others and calls these out for “more intensive review.”

Even though these these resources are around a decade old, to me they are classic (in a good sense) and remain relevant and useful to developing systems that are on target.

(Source Photo: Andy Blumenthal)