Menu
Agile has become all the rage within the software development and enterprise buyer communities. Partly this is because it has become the hot buzz topic du jour. Just like intranet, portal, B2B, enterprise architecture and cloud, among others before it, Agile has become the pretty thing that everybody thinks they want. This is not to say that much real and lasting success was achieved with any of those paradigms (another word that once dominated IT conversations). But there were also many instances of organizational buyers and sellers gravitating to a fad and at times the enthusiasm was misplaced. In software development we’ve chased Waterfall, Incremental, RAD, Spiral and others and now the new excitement is Agile.
So to a certain degree the enthusiasm for Agile is chasing the latest and seemingly greatest at the moment. After all, if everyone’s all excited about it then it must be fantastic. Maybe.
The truth is that Agile represents a kind of pinnacle of software development evolutionary maturity through the last 6 decades. The methodology is the product of too many lessons hard learned. It includes a deep and responsible level of customer involvement and accountability. It requires genuine expertise on the part of the development team and its leadership. When done effectively it is the fastest and most cost effective way to build large software business process support software (BPSS) systems. And it is the easiest methodology to actually utilize effectively, if its rules are assiduously followed of course. “Sort of Agile” and “Agile Lite” are not Agile. They are a foolish cheat used because either the development vendor of enterprise buyer doesn’t understand Agile or is unwilling to be constrained by its structure. May they crash and burn with their pathetic, amateur efforts. The real power only comes from the real thing.
Currently when an organization looks to acquire a new BPSS solution they must scope out the project in its entirety to a degree of granularity that provides sufficient accuracy to identify the amount of budget they need to acquire. Sometimes they are spot on, but realistically that is extremely difficult to achieve. More typically they are either way over or way under in both the true requirements and cost and ultimately a square peg gets pounded into a round hole.
Another potential failing of modern BPSS acquisitions is that when the buyer publishes a request for proposal (RFP) the solicitation almost universally requires statements of core capabilities, management approach, technical skills, past performance, etc. Those things along with price are, theoretically, the basis for the contract award decision. When an award and the work actually starts the vendor is, however, mostly providing staffing to do work that the enterprise buyer directs because too often the buyer assumes a level of software development management ability that they do not poses.
Designing and directing an enterprise class BPSS solution requires deep IT expertise and if someone doesn’t do it all day every day they are not qualified to ad hoc step in and out of the management role. That’s the failing referenced in the last paragraph. A beauty of Agile is it prevents the customer from taking on a directive management role by, most paradoxically, keeping them much more directly involved.
But there is another power within Agile that is less obvious. It’s a strength that may currently be a little out of our grasp, but there is the potential to utilize it in the future and it has the ability to revolutionize how software development services are acquired.
Core to the Agile development life cycle is the Sprints. Unlike any other development methodology before it, Agile is done in chunks. It’s almost as if the team were starting and stopping and starting and stopping over and over and over, each time checking with the customer to precisely identify a piece of functionality to be built, then creating that functionality, testing it, delivering it and moving forward all over again. These cycles are called Sprints and they can span anywhere from just a few days to 4 or 5 weeks at the absolute most. On the face of it this may seem inefficient, but it is far more effective than any process before it for nearly all custom development projects. It is in the Sprints that an entirely new understanding of software development services can be found.
Uniquely, now, Agile provides an á la carte software development purchasing opportunity, that is, the ability to buy Sprints. While it is true that Agile is more efficient than any methodology before it, this is yet another transformative quality that in the future will change BPSS acquisition and delivery. An organization will be able to estimate how many Sprints they’ll need and can go to the marketplace with a solicitation to buy them. They can buy, say, 10 Sprints to be 3-5 weeks each with an overall anticipated level of effort. The competition comes in when the bidders are allowed to each utilize their expertise in BPSS by proposing their view of what is the right combination of team size, skills and Sprint duration and can cost out the Sprints accordingly. This is not just buying to the lowest price. It’s buying experience and the ability to demonstrate an understanding of the challenge and vision of the solution, in segments that are small enough to be accurately identified and understood. This is real software development that comes with real functionality, delivered fast and efficiently.
Sprints are logical segments of an overall software development effort and can be purchased based on an evaluated need, like buying servers for a NOC or hard drives for a SAN. If the project ends up not requiring as many Sprints as was expected, the cutoff point becomes obvious. If it requires more, the amount of the extra level of effort will be obvious as well. No more endless budget overruns with no end in sight. Suddenly software development can be treated almost as a commodity.
Earlier I said that we may be able to utilize this ability in the future. Why not now? The reason is simple. There’s a new acquisition skill and activity that must be understood and utilized in order for Sprint purchasing to become an effective reality. It will take time and experience for that skill level reach the appropriate level of depth and maturity to sufficient functional accuracy to avoid chaos.
Consider, the leadership of the Human Resources department recognizes that the HR Dept. needs a modernized IT system to support the day to day work of the department as well as to serve its customer, the employees of a 50,000 person agency. The job they do all day every day is HR. They are not IT experts and nor are they business analyst experts. Asking them to analyze the business processes of the staff in order to accurately assess the full functionality scope and anticipated cost of a custom software development effort is the fool’s mission that they are placed on every day in the modern acquisition environment. These tasks are full-time jobs of experienced experts and cannot be performed by a non-expert who also has other full time responsibilities. Hence, we see so many well-intentioned efforts fall off the tracks through no one person’s fault.
To be able to treat software development as a commodity by purchasing Sprints the leadership of HR needs to first turn to experts in BPMSS development to perform the initial level of effort analysis. There are currently not a lot of those experts and the government can’t hire them directly because the good ones are too expensive and the not so good ones will be even more expensive in the long run. But that will change as Agile develops history.
The government is accustomed to going to the marketplace for level of effort expertise in very large acquisition projects. The shift that must occur is to push much further down the size of project for which that type of service is sought. It’s still not going to be that simple, however. The best talent is actively engaged in business process analysis and Agile development execution. Any company that delivers an analysis of scope and level of effort for an organization would likely be OCI’ed out of bidding on the actual project, which is the much more attractive and lucrative work. As time goes on, however, there will be more experts in the field and it will be easier for the enterprise buyer to acquire the level of effort analysis they need to more accurately scope out their Agile development project.
