Agility requires greater Discipline. Are you ready for it?

For long, we have heard complaints about Waterfall, CMMI, etc. The complaints vary from too much process to too much documentation to too much overhead, etc. The fact is that like everything else that has been around for a while, the spirit behind these standards/ certifications/ methodologies has been diluted over time. I know of instances where tons of backdated documentation is generated before the day of the CMMI audit! Much worse, we have all heard of instances where certificates are “bought” out.

However, if you leave aside the negatives that creep into anything that’s been around for some time and focus on the real principle of it, you will realize that the complaining is not so much about too much process/documentation, etc.; it is about being told to do something in a “disciplined” manner. Software is creative and good developers don’t like being told “This is our standard and you will only do it this way!” It is like telling my daughter who is solving her arithmetic problem to write all the steps. She thinks it is boring and a waste of time; I think it helps her from making careless mistakes. Now, reconcile! Today, few developers write their program blueprint on paper before they start hammering on a keyboard. Modern day editors have discouraged the need for such time tested practices.

Agile got lapped up because it was pitched as lightweight methodology. The point it did not emphasize was – less documented process demands you (the developer) to be more disciplined. Unlike the Waterfall/CMMI methodologies that put a strong focus on review, feedback, corrective action, rework, etc., Agile focused on getting the job done (right) in short time buckets. So, everyone has to develop code as per the standard. Everyone has to be well trained. That is the only way to keep “technical debt” down. Is it easy? No…. it is a lot more difficult. Remember the open book exams in our colleges? I used to dread them compared to the regular exams!!

Now, we are talking about Lean, generally believed to be even lighter than SCRUM. Well, guess what… what is not being said is that it will need far greater levels of discipline on behalf of the development team. How else do you make sure that what everyone is pulling from the queue and working on will finally coexist together in the expected manner? The methodology does not highlight the benefit of “show early and often to get feedback from the customer”. So, a Project Manager now has to have the discipline to make frequent releases and solicit early feedback from the customer. The need does not go away just because the process did not highlight the need.

In summary, the lighter the tool and methodology, the greater is the (maturity and) discipline needed from the development team to be successful; else, it will not all come together when you want it to and in a manner you want it to.

A “part” solution to this desire (to get away from doing extra steps for the sake of process compliance or documentation) can be software engineering tools, ALM tools and development methodologies that help develop generate some of the documentation and structure in the background as the developer continues with his main work – development. Tools that help analyze code for memory leaks or code complexity or generate documentation fit that space. ALM tools, that build complete traceability from requirement to code without a developer going through a painful process to do so manually, fit that space. TDD methodology fits that space. A combination of all these, working coherently (which is far from anything in the space today), can really help focus the team on development and help partially reduce the demand on “developer discipline”. That is what the Development community will embrace.

Sudipta(Sudi) Lahiri
Senior Vice President, Engineering and Services

Is Agile ALM on SaaS for you?

In the last 2 years, Software-as-a-Service (SaaS) as a delivery model for corporate applications has found a significant amount of support.  In the aftermath of the 2008 economic crash worldwide, there has been a surge of interest in exploring the SaaS model for a variety of reasons – mainly around reducing up-front investment typically associated with on-premise license purchases (operating expenses vs. capital expenses), ease of getting up and running, the ability to opt-out if you didn’t like the software, and several others. 

At the same time, customers were cautioned about the key issues to keep in mind while adopting the SaaS, such as:

• Peripheral applications, that did not touch core business activity/ processes, such as HR, CRM, Payroll, etc. were easier to deploy on SaaS, rather than core applications.
• Even if applications were deployed on SaaS, they would need integration with other enterprise applications, whether in-house or SaaS, and customers would do well to evaluate SaaS vendors for the capability to integrate with other applications/ providers
• Even if applications were available via the SaaS model, associated implementation effort such as user training, organization change management, data migration and interfaces with other apps remained. Thus it would be a mistake to assume that SaaS would significantly reduce implementation effort and costs.
• Application security, scalability and performance; and vendor track-record (longevity, number of paying customers, financial strength) were other factors to look for.

Where is SaaS being adopted the most?

Common wisdom was that SaaS applications would typically be adopted by Small and Medium enterprises since they are usually more cash-strapped than Large Enterprises.  However, in an interesting research article published  by Saugatuck Technology Inc., a well-known SaaS research services provider based in Westport, CT, in September 2010, it appeared that SMEs were "much more likely to still be learning about SaaS - and to not have SaaS plans in place".  

Based on responses to several key questions, shown below, it would appear that only 24% or SMEs had implemented or were implementing SaaS applications against 43% of LEs!

 

What Apps are most Likely to be on SaaS?

Clearly, the peripheral vs. the core argument made a lot of sense.  Customers would be much more likely to trust an external service provider to manage corporate data that was not critical to its core business.  At the same time, they would be much more likely to outsource apps that were not core to the business.  

In a recent article, CIO.com refers to a detailed Forrester research that finally acknowledges that not all software will be successful on SaaS! Among others, it says Application Development software is successfully finding its way on SaaS.  Our experience with project management software is the same!   

At Digite, we have found substantial interest in our Agile ALM products in both SMEs and LEs and we have a healthy mix of both.  Given our customers' focus on collaborative software development using geographically distributed teams, both our on-premise (but web-based) and SaaS offerings have found widespread acceptance. Given the global trend of distributed technology teams, this is hardly surprising!

It would be great to hear of your perspective on which applications have worked on SaaS and which haven't.

Mahesh Singh

Sr. VP - Product