The Digité Fountainhead

Using Swift-Kanban for customer portfolio management

2012-01-23T10:44:00.000-08:00

My business focuses on lean-agile coaching, consulting and training, not on software development services, and I successfully use Kanban to manage my customer portfolio.

It is untrue that Kanban is only good for software change management work. Many people new to Kanban have this misconception mainly for two reasons. One is because Kanban started in a change management team at Microsoft. The other one is because David J Anderson declared that Kanban is a method for change management in the organization and that statement can be misinterpreted. What David meant with that is Kanban helps you bring positive change to your organization. Although the original Kanban description is around software it is actually context free. There is a very popular book entitled Personal Kanban by Jim Benson that I invite you to consult.

Getting back to the main subject of this blog. I have been using Kanban for years to manage customer-facing and business-facing activities. The customer facing activities Kanban board has one swim lane per customer for easy visualization of the activities with each customer and to avoid making mistakes on which customer a given activity is for. Each customer has its own backlog, which we make visual as the first column on the board. The other columns are Ready, Execute (doing/done), Customer verification, and Completed columns. The WIPs for each customer are different and in agreement with the customer needs and my resources. The figure shows our Swift Kanban board for one of the countries where we conduct business. In addition to making remote communication easier, a huge advantage we have with Swift Kanban is that it allows us to resort the lanes up and down to indicate level of priority and activity (we used the smart lanes feature to accomplish this). That is, a lane (a customer) bubbles up if the our level of activity with that customer and its priority increases and bubbles down if the activity/priority decreases. That way if we will not be doing any work with a customer for a while its lane is "out of the way"; and it is still readily available to resurface at a moment's notice. We also count with a swim lane called "other" for general work that has to do with potential customers when the relationship hasn't matured yet to the point of earning a dedicated lane.

Our classes of service are

Business task
Business appointment
Business partner / associate task
Fixed delivery date
Immediate

Intangible tasks are business-facing and are, therefore, on a separate board.
Cheers,
Masa K Maeda

Kanban and the Focus on Fundamentals

2011-09-27T16:17:00.000-07:00

(Previously published in the DJ Anderson Associates sponsored eBook - Quotable Kanban)
Our Kanban journey began early in 2010 when we decided thatwe would build a product in the Kanban space that would address some of thebasic issues we saw our prospects face in adoption of Agile methods such asScrum and XP within their organizations that were historically used to doingwaterfall or iterative or some hybrid Agile method that combined more than onetype of processes.

While the presence of established competitors was a strongreason to look beyond the ‘popular’ Agile methods, we also felt a strong appealfor Kanban existed because of its focus on 3 key fundamentals:

Evolutionary change
Improvement of existing processes
Engineeringrather than Management processes

We have seen numerous organizations and teams take on large(revolutionary) process improvement initiatives – be it 6-Sigma or CMMi or evenAgile. We have seen them become consumedwith “the task of process improvement” over and over again. As a result, while there is improvement inthe interim, in terms of consistency with which a process is followed in theteam or the organization, the overall magnitude in terms of the time, effortand cost, of making the transition becomes huge and management begins toquestion the benefits! Kanban, with itspromise of evolutionary change, with one stroke, takes care of this fundamentalissue. It allows teams to take on onlythose aspects of change that they can comfortably handle.

Secondly, with an evolutionary approach, Kanban necessarilytackles current processes in an organization and helps improve them, ratherthan force a range of new processes on it. This is fundamental to understanding how Kanban can be applied not justto traditional software processes – but also to popular Agile processes such asScrum and indeed, to non-software processes – bet they within IT or in generalbusiness functions such as Sales or Marketing or Legal! So besides beingattractive to software teams, their pull for non-software teams, presented uswith a much bigger opportunity, which we are already starting to seematerialize!

However, the one aspect of Kanban that excites more thanothers is that it forces teams to focus on the “engineering” or the “delivery”processes rather than the “management” processes. This is where, I feel, Kanban trulydistinguishes itself from its ‘competitors’, if one may terms them asthat. Through the use of statisticalcontrol charts, Kanban helps teams identify their normal performance and theirdeviations from the normal – the outliers. Rather than advise teams to simply do better documentation or better managementor better reviews, it encourages teams to do better root-cause analysis – andattack root causes for poor performance – be that better or more specifictesting, better development or design practices or better collaboration andrequirements elicitation from customers. And in doing so, I believe Kanbanshows itself to be far more effective than any other framework to start makingincremental, lasting improvements in the final quality of the product orservice being delivered.

Far too often, after initial gains have been realizedthrough ‘traditional’ Process Improvement initiatives, teams start to questionthe extra overhead of ‘following process’ and wonder ‘what is in it forthem’. With Kanban, these teams are muchmore likely to realize lasting gains through evolutionary, (incremental) improvementsto basic existing delivery/ engineering processes and measuring their ownperformance in a much more meaningful manner.

Mahesh Singh

Co-founder, Sr. VP – Product

Scrum Bangalore - Scrum, Kanban and Pecha-Kucha!

2011-06-10T21:13:00.000-07:00

I recently participated in a local Scrum event in Bangalore and shared my experience in trying to implement Scrum and later Scrumban within my current organization. I have shared the slides below.

The event was hosted by SAP in their campus and had a keynote speaker who shared the information about Lean/ Scrum implementation @ SAP and how they are trying to transform the entire organization to a newer or “lean” way of software development.

It’s great to see such enterprises adapting to this new wave of software development. It will encourage a lot of other companies to try out such methodologies and share their experiences/ learning. The event had more than 40 participants from various companies like Mindtree, Aricent, SAP, Cisco etc.

There was an interactive talk from David Putman, a UK based consultant, and Srikanth Tadipatri. Both are currently helping the Tesco India team to move to agile development and they shared their experiences on various topics/ issues related to scrum implementation.

The other 4 presentations, including mine, were in a "Pecha-Kucha" format ( a Japanese style, where a concept is presented in 6 mins, 20 slides, auto-timed for 20 seconds) themed around 'Scrum: Success Stories'.

My talk was about our experience so far in implementing Scrumban – a combination of Scrum and Kanban and how it is helping us to work more effectively. It is hard to summarize the experience of over 2 years in 6 minutes (Pecha-kucha style is supposed to save people from 'Death by Powerpoint' ;)), but I hope I was able to put my points across.

Here's a link to my presentation, do check it out and feel free to contact and we can discuss in detail.

Participating in LSSC11: Lean on the Rise

2011-06-01T20:52:00.000-07:00

Digite participated in the recently completed LSSC11 (Lean Software & Systems Conference 2011), an event focussed on Lean Software Development, in beautiful Long Beach, California.

It was a great experience for me. The conference had a varied set of topics from Lead development, Kanban, CMMi (1 day), Risk Management, Systems Design, Kanban games etc. It was amazing to see this level of change, innovation and creativity in the Lean community and adoption in the industry. Companies and individuals are continually making effort to apply new and improved techniques and tools to the way they have been working and bring about greater productivity, quality and efficiency.

Digite is proud and privileged to help lead this change! Since we were one of the sponsors and had a booth at the conference, I couldn't attend all the sessions I wanted to, but that was a small price to pay for being there! Sessions were organized in three parallel tracks, and almost all of them were simply great, so there was no way but to miss out on many of them!

A quick summary of my Learnings/ observations from the conference:

All the keynotes in the conference were simply fantastic. I specially liked the Keynote by Chet Richards on 'Fundamental Secrets of the Universe'. He shared many anecdotes from his Marines background and spoke about John Boyd and his OODA loop, which are very interesting and has a lot of applicability to the software world.
Another great talk as by Joshua Kerievsky on Sufficient Design. I liked his observations on 5.x Development death cycle, explaining the state of many products, which become almost dead (with very heavy technical debt/ defects) by the time their 5.x versions come out. And how the "Resume-based development' attitude from the technical folks make one choose heavy design, even for simple requirements. His guidance - one should make design choices based on multiple criteria and most of the time, a "Sufficient" design is good enough to go, than doing very complex design.
I also loved the talk by Inbar Oren on “Who’s Afraid of the Big Bad Wall – Visual Management and Gemba Walks”. He talked about the impact of visualization and how Kanban boards almost replace the need for any manager to get an immediate status, without participating in a daily standups. Here's a link to his blog with slides.
The talk by Don Reinertsen on Cost Of Delay was also great. It is a very powerful concept and can be applied to all situations. While not always easy to quantify, it is a great way to prioritize all work!
Frode Odegard’s presentation on “Beyond Lean Value Streams: A Systems Approach" was another good one.
There was also a Tools track where many tool vendors (including Digite) showcased their Lean/ Kanban tools. It was interesting to see alot of innovation happening in this area. We got some good response, as well as feedback for our Kanban tool - Swift Kanban (www.swift-kanban.com).
There was also a Games track where attendees could play the Kanban game developed by Russel Healy. It's a great game for understanding the Kanban basics.
Here are a couple of other blogs/ links related to the experience @ LSSC11. They are definitely worth checking out to see what's happening in the world of Lean/ Kanban :-)

Overall, it was a fantastic experience for us. We got to meet some great people including industry thought-leaders, our own customers and prospects, all in one place. Lean/ Kanban is definitely emerging as a powerful mechanism to scale Agile at the enterprise level and to help organizations dramatically improve how they work.

Nitin Ramrakhyani,

Sr. Product Manager, Digite, Inc.

Agility Redefined

2011-05-29T22:42:00.000-07:00

There is an enormous amount of discussion and literature (in the Software/ Application Development circles?) about different processes (or methodologies), their pros and cons, their challenges, etc. While these articles are right in their own way, in most cases, they preach adoption and acceptance of one process. However, the fact is that rarely does a “one size fits all” approach work for anything – why would software be any different?

Interestingly, most software/ IT organizations are also trying to adopt one methodology across the organization. They bring “gurus” who espouse that process, run training programs and campaigns and try to mould the entire organization in one direction. They try to bring in common practices (positioned as best practices), common metrics (to compare performance of team or individuals) and common reports (while almost all status reports contain the same kind of information, have you see any 2 organization status reports look the same?). Over time, the organizations gets so consumed by this style of thinking that the people forget – who is it for? Will this help the project that I am executing?

Since I have been working in the domain of software development for the last 20+ years, I have come to realize that the focus of any organization needs to change to what is appropriate for the project. As a Project Manager, I should be able to:

1. Select the base methodology that fits my need as closely as possible: How can I select the right methodology for my project based on the nature and circumstances around my project? What are those attributes of a project that can help me decide the right development model for their project? Can a measurement criteria or guideline be defined for this?

2. If need be, identify key principles of various other methodologies that I would like to adopt: Are their principles of one methodology that I can “blend” with another methodology because they make sense for my project? So, for example, can I use a Kanban board for a Waterfall project? While the two may look to be at the opposite ends of the spectrum, my question is: why not?

3. Identify principles of my base methodology that I definitely don’t need: Are their principles of any methodology that I most definitely do not want to follow? For example, if my requirements are unclear and I am not convinced about a big bang estimate, can I start the project without a detailed estimation cycle?

In other words, I should be able to build a process that is right for the project, right for the people in the project, right for the stakeholders for the project. If you are in a services business and need to give a fixed price bid to a prospect/ customer, you cannot say then that I cannot do it because my process does not believe in big bang estimation. If you are working in distributed teams or with outsourced teams, you cannot say that I will not write detailed requirements because my process does not want me to do that.

Agility is all about being flexible, being able to adapt, fast! Translated to software development, it means:

1. Understanding different methodologies, their strength and weaknesses.

2. Having a tool to help implement different methodologies with relative ease.

3. A minimal layer of commonality across methodologies that can serve organizational needs for reporting/ aggregation without being a liability on the project. As idealistic we may want to be, it is important to recognize that organizations will want some mechanism to get a feel of project progress. That cannot be completely different across projects/processes.

4. Leaving the final decision to the Project Manager as to which methodology they want to use for their project.

5. Assist the Project Manager in adapting to his/her “desired” methodology, quickly.

I would like to know how you go about deciding on the ‘development process’ for your project. Let me know if you agree or if you feel otherwise.

Sudipta(Sudi) Lahiri
Sr. Vice President – Engineering & Professional Services

Join the Kanban Conversations!

2011-03-21T16:29:00.000-07:00

It has been an exciting 3 weeks since we launched the GA release of Swift-Kanban. Clearly, Kanban for software development and IT teams is being seen as the elusive weapon that promises to take Agile to the enterprise. From the volume of queries and the common themes of the inquiries, it is clear Agile practitioners know what they are looking for and will be demanding the right solution to help them make the transition to being an Agile enterprise.

Three key themes are emerging, which we find very interesting and are excited to learn more about through our interaction with our Beta users as well as prospects who are in discussions with us after the GA release:

Kanban for Distributed Teams

One of the most common reasons we are hearing when we ask why, is that the organization has distributed teams around the country, indeed the world - and simply cannot work with a physical board. In spite of time zone differences and multiple locations, these teams have managed so far by getting onto conference calls at the same time - and comparing notes and providing updates in prolonged interactions! With a Kanban tool, while these meetings may not go away (at least initially!), they get a powerful tool that visually communicates the same status of the project or a specific work-item and of course the entire project. That in itself is a huge benefit when teams have hitherto struggled with text reports/ email updates!

Kanban tools in conjunction with other Tools

Clearly, while Kanban tools provide significant efficiencies in project operations, projects continue to use a variety of tools including requirements management tools, testing tools and integrated development environments. Most of our interactions are helping us educate how potential Kanban practitioners propose to use these tools in an integrated fashion. With our extensive experience in integrated Agile ALM, we are certainly able to share our experience with existing customers; at the same time, we have learnt a lot about the possible integrations we may need to provide for a full solution. Irrespective of whether it is used on a development or a maintenance or a IT Helpdesk type of a activity, these integrations will ensure that not only does work flow smoothly within the Kanban board, but also outside of it!

Kanban and "Other Methods"

Kanban is not a software engineering method; however, it would appear that many organizations are approaching it as a software engineering method - be it against a traditional waterfall or iterative method or an agile method such as Scrum or XP! To us, it is clear that irrespective of the overall methodology being followed, Kanban provides a way to visualize "project operations" workflow and smoothen the flow of actual work. Thus, we are sure organizations will use a combination of software engineering, project management and operations processes that help them optimize throughput and increase output quality. This is fully in line with the principles of Kanban, that says that each (self-organizing) team must define the process that best works for them!

Our Kanban journey began more than a year ago and has just become much more interesting! We are having regular discussions with our early/ Beta customers. With David Anderson as our Advisor, we also launched the David Anderson Webinar Series and have seen a tremendous response to that. Come join us in these conversations and help us learn how we could better help you scale Agile in the Enterprise!

Mahesh Singh
Sr. VP - Product, Digite, Inc.

Agility requires greater Discipline. Are you ready for it?

2011-02-24T11:15:00.000-08:00

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?

2011-02-06T03:14:00.000-08:00

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

When is a project too small or too short for ALM?

2011-01-21T12:59:00.000-08:00

Someone recently asked that question in a community forum. Their own answer was - 'Never'. There are 3 aspects of this question that I can think of and respond with while agreeing fully with their answer.

Application Lifecycle Management (ALM) is an Activity

To my mind the phrase Application Lifecycle Management naturally means managing the lifecycle of an application. An application’s life begins humbly – with a request from a user or a customer, which fights for its survival amongst scores of similar requests. Once it wins, an application – however small or large – gets implemented/ developed to meet that request. Once deployed, an application has a life, the length of which is determined by a number of factors such as TCO and conformance to changing business requirements. The moment these factors weigh against the application, out it goes, upended by another request to replace that application!

A specific project which deals with an application - its selection/ prioritization, its development or implementation, or a making an incremental maintenance release of that application - is inherently 'part of' that application's lifecycle management, however short or small. So, the question itself becomes redundant from that perspective. Organizations are executing projects (that deal with applications) as part of that application’s lifecycle, whether they realize it or not!

ALM is a category of Tool(s)

From an Application Lifecycle Management tools perspective, different vendors have taken a different tack. While some have focused on purely the development or software engineering aspects of it, others have taken a broader meaning which includes the portfolio and project management aspects of managing an application's lifecycle. Still others have included a process-management aspect as well, that allows organizations to define processes for different aspects of the application lifecycle management, and use those processes in an integrated and standardized manner throughout the application lifecycle. Depending on the nature of the project, it will consume some or all of these aspects of ALM tools.

Various analysts such as Gartner, Forrester and IDC see it similarly; IDC actually has graphic that defines ALM as a combination of all three areas identified above. At Digité, we believe in that same vision. Thus, Digité provides a set of tools that allows our customers to manage the entire lifecycle on Digité or using a combination of ALM tools that Digité integrates with.

ALM is (part of) Organization Culture

A lot depends on an organization's culture, their approach to workforce productivity and quality, and what some of their key performance parameters are. Organizations focused on multi-geography/ department workforce productivity, Total Cost of Ownership of an application, and quality will typically consider any project to be part of ALM rather than see it in isolation. Every organization that understands the true nature and breadth of application lifecycle management will agree.

It would be great to hear some more perspectives!

Mahesh Singh

Sr. Vice President - Product

Digité Participates in Agile Coach Camp 2010

2010-05-19T23:09:00.001-07:00

Digite recently sponsored a team at the Agile Coach Camp (Goa, India) organized by ASCI (Agile Software community of India) where a good number of agile coaches and practitioners from various leading organizations and cities of India met in an open space format, to discuss various Agile coaching and implementation issues, as well as share notes on various flavors and practices of Agile being implemented in different organizations.

We started the conference with one-minute lightening talks from each one of us, on the topics which we wanted to be covered during the conference. We later wrote the topic on post-it slips and placed it on one of the open time-slots for discussion and came up with our own agenda board for the day.

Below is a gist of some of the key topics from the above list which we sequenced into multiple tracks:-

Problems with Agile adoption in large organizations: - Agile implementation in a smaller organization (product or services) is still relatively easier than larger enterprises. The challenges grow manifolds as one tries to scale the agile implementation across others projects being executed in the organization. The objective of this discussion was to share experiences on such challenges and the approach taken while scaling the Agile implementation in a larger enterprise.
Do we need a process to define Process? <Sarcasm>:- It was an interesting take on various organizations trying to complicate a simpler (and agile) approach to Agile software implementation by introducing waterfall-like processes and standards which the projects need to follow to claim their 'Agility', thus making Agile Development lose its core values. One of the practitioners shared how he had been asked to come up with an 'Agile Compliance index' metric, on which all the projects can be measured for the level of 'Agile' practices they are following. Again, how much such metrics can represent project success is subjective and we brainstormed on various ways by which this can be tackled.
'Agile Tools': Role, Trends and what to expect in future? : - We proposed this topic to understand the role of Agile ALM (Application Lifecycle Management) tools in helping the teams solve some of these challenges. The software market is full of such web-based agile project management tools which offer various features promising the organization the magic potion of being called 'Agile' from Day1 of its implementation. But are these tools helping the teams do their jobs better? What are the expectations of the senior management from an Agile tool? How aligned and integrated are these tools with other systems and processes that are being followed by the organizations since so many years? Is the cost of implementing such tools justifies benefit derived from it? We had some interesting perspectives which I'll share in the subsequent posts.
Is Product Owner Mandatory for Agile Teams? What happens if there's no Product owner? :- Again this was a pretty interesting topic on the role and need of a "Product Owner" in the Agile team and who can wear this hat if there's no formal product owner in the project.
Pragmatic Agile: - Are we sacrificing delivery for agility? This track was conducted in a pretty interesting format where each one of us proposed a hypothesis of a good 'Agile' practice to be followed in projects and someone else in the group took an opposite stand to debate over it. This has been neatly summed up by one of the fellow practitioner, Vivek in his blog post.
Agile Metrics: - Having agreed that an agile way of working doesn't require too many tracking metrics, but the top management needs to be informed and updated by some means that the project is going on as per the commitment or not. This is more applicable in services organization and is often is linked to various other aspects like appraisals, costing, etc. How then to measure the success or failure of an agile project? It was a pretty interesting discussion and hence it calls for a detailed post.
Role of engineering practices in agile development: - The major part of an agile development and its success often constitutes of the underlying engineering practices being followed in the project. One can count on a number of practices being propelled as an 'Agile' practice (read a list of such practices collated by Naresh on his blog here). But how and to what extent do these practices impact the success of an agile project?
Experiences and learnings in Acceptance Test Automation: - Should the entire suite of acceptance test cases be automated? Is exploratory testing still as relevant, knowing the thrust of Agile on automation. Most of the practitioners shared their personal experiences on this and brainstormed on the best approach to be taken.
Measure ROI of Implementing Agile? :- This was a pretty interesting track where we discussed various 'measurable' metrics which can be tracked to showcase the value of implementing agile software development methodology over other traditional approaches. This has been again summed up by Vivek here.
There were a few more discussion points…but those that I have listed above are the ones I could remember or read out from the above image captured from a digital camera. Guess we can't rely much on gadgets beyond a point and should take concrete notes. ;-)

Overall, it was a great learning experience but by the end of the camp, with numerous discussions on various issues, we almost wondered if we had learnt new solutions to known problems or had just became aware of many more problems and perspectives on the solutions we thought we knew. Maybe it was bound to happen when we had a mix of coaches with different experiences and skills. And I guess real learning from such camps happens gradually as one comes back to the daily grind and reflects on the issues discussed and perspectives gained.

I'll delve into some of the above topics in detail in my subsequent posts.

Nitin Ramrakhyani
Sr. Product Manager & Agile Coach
Digité, Inc.

Product Engineering depends on ALM Lifeline

2010-04-04T21:59:00.001-07:00

(ALM for Developers Series)

If there is one team that epitomizes the 'Structured Chaos, Unstructured Innovation' mantra, it is the Digité Engineering team! Our daily churn across different engineering streams of new releases, maintenance and Patch Releases, as well as responding to Support and field issues are all done in a day's work! As Director, Engineering at Digité, my job is to make sure we are all pulling in the same direction!

Life before Digité

Before we built our product, in the early 2000's, we used a variety of tools – and in some areas, no tools – as we managed the myriad activities in each month and quarter! Tracking work on email, MS Office, Lotus Notes databases, Remedy and VSS was the norm. But every night, I would spend at least a couple of hours figuring out where we were and if my developers were really done with what they said they had done. Developers would themselves spend considerable time during the day on a variety of 'follow-up' and status update tasks and wasted between 20-30% of productive time every day. Digité 2.0 changed all that – and since then, life has eased up while Digité itself, now at 6.0, has become our 'lifeline'!

Integrated Release Planning and Execution

For planning each Release, Product Management, Engineering and QA start reviewing our Backlog – available through our integrated Requirements Management, User Stories, Customer CRs and Defects – for prioritization and scoping. Once the scope is finalized, we group the various work items into Iterations/ Sprints and start with the first one. In the mean time, we also have Management review and approve the scope, using our integrated workflow. A far cry from the old days of the release planning nightmare!!

In each Iteration (typically, we may have 3-4 Iterations per release), work gets planned as Minor or Major Enhancements. For major enhancements, we use Digite's Work Package module. All tasks associated with each enhancement are planned using either Digité's STaRT scheduler or our integration with MS Project. Developers get their work items and Tasks as their To-Do list within their Eclipse environment, which is also integrated with Digité. From scoping to work planning to allocation and execution, it's one smooth process flow.

Developers work primarily within Eclipse. When checking in code in Subversion, each developer links the Digité Work Item/Work Package for which they did the change and establish the traceability. Digite's Subversion integration helps a Reviewer to examine all relevant changes of a particular Work Item using the traceability links established all through the development lifecycle.

Completed features are given to QA. QA manages the full test cycle using Digité's Test Management module comprising of Test Scripts/Units and different Test events. All defects identified in each test event are logged in our Defect Tracking module, traced to the relevant work items and routed to developers for fixing using Digité. The developer gets these in their Eclipse To-Do list as well! Similarly, automation scripts running every night also generate defects, which are also tracked using Digité and routed to developers in Eclipse.

Once all iterations are done, the release is shipped to Support and Product Management – who also do cursory testing and review Test Results online to ensure the Release meets their Requirements! Ultimately, that is what Quality is all about!

End-to-end Visibility

With such an integrated execution platform, it really ensures that every stakeholder of the release (Executive, Product Management, Engineering, Release Management and QA) looks at the same view of the release status. This helps us achieve timely delivery of our releases without execution conflicts. Steady tracking of key development parameters has helped us reduce Defect Leakage by 66% over the last 3 years while developer productivity has gone up by anywhere from 35-65%.

No wonder that Digité it has become our 'LIFELINE'. It is just not possible to envisage life in Engineering without such a platform!

Chirag Kapadia
Director, Product Engineering, Digité, Inc.

What is the Vision – Agile or Agility?

2010-03-11T07:20:00.000-08:00

Induction into Agile

My introduction to the Agile world goes back about 3 years. Charged with the new buzz of Agile, a team at Digité attended an Agile workshop conducted by a local Agile/ Scrum trainer.

The first part of the workshop was really very exciting where the coach educated us on the Agile Manifesto. In the second half, we learned of various Scrum characteristics. At the end, the coach made a remark – 'You will be an Agile Organization only if you follow ALL of the Scrum methods described in the workshop'.

This didn't go down too well with the attendees. We started to discuss how we would adopt Agile in Digité. The change was going to be significant. We operate from three different locations – so getting people together in a room was not possible. Further, 'Paired Programming' was not feasible mainly due to cost constraints. At that time, our regression test cycle was a manual (and hence huge) activity before delivering each release to customers. Not to mention all the typical 'change management' challenges for overhauling existing systems and processes.

When co-workers asked about it back in office, most of us termed Agile as 'Star Trek'– all great, but fiction - not designed for software company like ours!

Reality bites – are we Agile?

Over the next several months, egged on by Management, we adopted some elements of the Agile methodology successively. The Product Management team was the first to move. Instead of working with perceived value of features, we started to rank order the Product Backlog. The Engineering team started to plan releases in multiple monthly sprints as well, ensuring a phased delivery and the ability to accommodate changes through the release lifecycle. The QE team was next in the queue, with Test cases automated and a nightly build available for testing.

At the same time, we retained many elements of traditional planning. We were committed to scope and timelines of each major release and there was no moving back from it. All the major software design and architecture decisions were taken during initial Release planning itself. We continued with formal 'Review' processes for code review to ensure code quality. Time tracking was also a key requirement and continued as is.

When posed with the question, "Was Digité Agile?", I was never a 100% sure. Many customers I have spoken to clearly indicated that their methods are a combination of Traditional and Agile. While they abstracted from the "good parts" of Agile, they did not give up on what worked well for them all these years using traditional methods.

Agile or Agility?

Recently, I attended another Agile conference where David Hussman presented a session on 'Doing What Works Over Doing What You are Told'. David, an Agile coach for a range of companies, presented diverse and real-life views on Agile.

His thrust was – most of the organizations have mastered the art of software delivery after a number of iterations. If organizations have developed a certain way of working over the years, they don't have to necessarily scrap it all to adopt Agile. Agile manifesto is not prescriptive; it's a set of simple principles that teams should aim for. There may be various methods to become Agile, but being Agile didn't mean we'd to follow them all!

This certainly resonated with what our customers were telling us. Agile has great positives; however it also has challenges – for certain type of projects and organizations. For project sponsors, Agile projects lack visibility of final scope. There is no up-front planning of who will work on what. Large/ distributed teams have been slow to adopt Agile. This is where Agile ALM tools such as Digité, which enable both Agile and traditional methods, are helping significantly.

Overall, the message is loud and clear – our customers want Agility, where their customer requirements are being met better, faster and cheaper!

Rahul Vedak
Sr. Product Manager, Digité, Inc.

How ALM Tools Can Help Key Software Processes

2010-02-28T19:02:00.001-08:00

In a recent exchange, I was asked what the typical ALM tools do to address three key challenges around process improvement and compliance in software/ IT organizations, and more specifically, what we at Digité do about them. I felt these would be of interest to others as well, so here is a summary of that exchange.

Effort Estimation

Most tools lack any (effort) estimation capability and most estimates falter. This is one area that remains a challenge for most organizations and application/ software projects are notorious for not meeting their original effort/ cost/ time estimates.

Our experience at Digité has shown that there is very little standardization in the use of estimation methods, except perhaps the bare minimum use of Function Point Analysis, so it is not easy to select any specific methodology and incorporate into the tool. However, the fundamental problem that I believe we (as also most PPM/ ALM vendors) help resolve is of helping our customers build historic data, one of the most common reasons for poor estimates. By using Digité across the organization, our customers capture process and project data and help successive projects do better in terms of estimation. We do have specific but basic functionality around capturing Phase level estimates and then automatically assigning to WBS tasks - which the PM can then tweak as needed.

Standardized Measurement Systems

We believe that ALM tools are at the front and center of solving this problem – that's where work happens! So ALM tools are the ideal candidate to be the measurement system in a software/ IT organization. Through Digité's integrated combination of Process Governance, Project Management and SDLC functionality, we provide all projects a consistent method of data capture across all phases of the project and across all types of projects - be it development, maintenance, implementation, etc. So, every activity in the project is codified, and reduced to a WBS task or a workflow step - and baseline, plan and actual effort against all project work - whether planned or unplanned - gets captured against these tasks/ workflow steps. These then get rolled up based on the WBS hierarchy or by the metrics/ reports that use that data to provide a variety of metrics from quality, defect, earned value, variance and so on.

Different organizations have differences in the way they may measure even a simple metric like Defect Density or Defect Leakage; large organizations may have that problem even across business units! However, using a system like Digité, they are able to standardize the measurement and reporting.

Compliance to Process

Compliance to a process is the biggest issue that our customers deal with - and I sincerely believe that is where we at Digité provide very unique functionality that no one else provides. Digité's integrated Process Governance module has what we call the Universal Process Framework (UPF). This is a flexible framework that allows you to define CMMi/ 6-Sigma, PM-BoK or other framework compliant process templates (PTs) easily and flexibly for different types of projects that you do.

Each PT is a combination of the project WBS, various functional processes (workflows) like requirements management, defect tracking, test management, etc. (depending on the process or project type), deliverables, phase gates, roles, process artifacts, etc. These create what we call 'actionable processes' – the critical component missing in most process improvement initiatives that automatically convert process definitions to project work-items. When the process template is used to create a project, all of these become available to the project team. As the team does its work, the process automatically gets followed! Very little 'extra' work needs to be done to follow the process and project managers/ teams love that!

If you have any insights to share, we'd love to hear from you.

Mahesh Singh

Sr. Vice President, Product

Challenges in Time Accounting in Software Projects

2010-02-02T10:43:00.000-08:00

Time Management has always been a much talked about subject of management. Jim Rohn said “Time is more valuable than money. You can get more money, but you cannot get more time.” Yet, software engineering has always understated the importance of time. In most organizations, time sheets are filed casually. I don’t know of too many developers who can honestly say that they file time accurately.

As I tried to analyze the problem from my own experience, I have realized that there are two parts of this problem. Firstly, managements don’t appreciate the importance of time accounting. Beyond project costing or billing, few know what to do with it. The second reason problem is the TGIF syndrome! When it is Friday EOD, the last thing that you want to do is spend time at 6pm recalling what you did on Monday morning and then painstakingly file time for the right task/activity. Often, you realize that the task/activity that you worked on is not on your screen! So… what happens? You file your 40hrs (whether you worked 30hrs or 50hrs) wherever you can. Result: Garbage In, Garbage Out.

Digité Enterprise functionality lays significant emphasis of Time Accounting. Done right and done daily, it is a 5 minute task. Accurate time accounting has multiple benefits – it helps people understand how they spent their day (could be a problem for some). It helps Project Managers understand where their people are spending more time than what they should. The list can go on.... however, the biggest benefit is that when used on a daily basis and filled accurately, it does the job of progress reporting and status reporting automatically! How?

Assume a task is planned to take 10hrs. By filing time on the task for 8hrs and then saying that only 50% of task is complete OR that you need 8 more hours (either of which is possible in Digité Enterprise), you have told your manager that your task is now estimated to take 16hours and its % progress is 50%. When this happens across the entire team, I bet that it saves your Project Manager at least an hour every day (depending on team size). He/she does not need to talk to people to find out what an individual was doing, how much more time it will take, how much progress it will take, etc.

However, if this functionality is not well understood, it has the potential to make your life complex too. In Digité Enterprise, time can be filed on tasks as well as Project Items (Defect, Issues, Risks, etc.). Digité Enterprise architecture is based on principle that projects that are planned by work decomposition (WBS) will file time against the tasks/activities in the WBS. On the other hand, projects that are executed with Project Items primarily will file time on Project Items. For example, a Development Waterfall project will file time on tasks. However, a Production Support project will file time on Project Items. Mixing the two will inevitably lead to confusion, inaccurate metric generation, etc.

Take a simple scenario: In a simple Development project, one would have a Testing activity(ies). Testing activities lead to Defects being filed. So, if you now file time on the Defect, what are you filing your time on – time to execute the test case that found the defect OR time to log the defect OR time to fix the defect? If someone files on the Defect and on the Testing activity, how does the system avoid double counting of the same?

To avoid such confusion, Digité Enterprise built its solution with the understanding that the time used to test and identify/log the defect will be filed in a Testing activity. Similarly, the time taken to fix the defect will be filed in a Defect Fix/Rework activity. WBS projects will not file time on project items.

Now, consider a Production Support project where you are doing help desk tickets. In such projects, it becomes important to track how much time a specific ticket is taking and to be able to monitor the productivity of people who are working on these tickets in the different stages of the workflow. Obviously, there is no planned task for each ticket because you don’t know how many tickets you will get ahead of time. To handle such projects, Digité Enterprise allows you to file time on Project Items like Defects, Tickets.

Accurate time accounting is critical for all IT organizations - not just for EV and Quality metrics, but also for internal/ external financial accounting, costing and chargeback purposes as well; getting it done has been a challenge for long. We believe that with Digité's Time Accounting capability, we have helped our customers take a big leap towards achieving that.

Digité Goes On the Cloud!

2010-01-19T02:55:00.001-08:00

At Digité, we have been a web-based application right from the start. Before Cloud, before SaaS, there was ASP – and our initial product launch was as an ASP – Application Service Provider. As luck would have it, a majority of our customers preferred to host the application 'on-premise' and simply wanted to buy the license from us. This worked very well for us – because it gave us invaluable experience in a variety of areas, from the challenges of implementing an enterprise software across the organization, to testing the software for the scalability and robustness needed for a deployment such as Infosys, our largest customer, with a 100,000 users on a single Windows/ SQL Server based installation of Digité Enterprise.

Over the last 8 years, we have implemented Digité at Corporate IT, IT Consulting and Services as well as ISV organizations. And, amongst the many lessons we learned, we picked on two – the challenges an organization is trying to overcome by implementing a solution such as Digité – and the challenges an organization goes through trying to implement an enterprise solution like Digité.

Structured Chaos, Unstructured Innovation

Our customers are in the business of developing or maintaining or implementing software – in-house or third party, custom or off-the-shelf. This is hard work that usually involves defining requirements and building or assembling software solutions that meet those requirements. This is by itself a tough job; introduce geographic, cultural, logistical and technology barriers of today's global economy, and the job becomes tougher by several magnitudes. Our customers have seen the value that Digité provides by giving them a flexible, easy to use, lightweight and cost effective mechanism to quickly get organized in their development processes so that they can get on with the far tougher job of building great software! Over the last 8 years, we have been amazed over and over again at how our customers' teams have innovated to build great software to delight their own customers, internal or external. And we have learned from those experiences. Key amongst them – that people don't want to reinvent the wheel. If someone has already done it, reuse and build on top of it! And two, keep things simple, yet comprehensive enough. "Just enough process" is a recurring theme.

The Small Matter of Organizational Change Management

Implementing ANY enterprise software is not easy; implementing Digité Enterprise – which pretty much touches everybody in a software/ IT organization, can be even tougher. When you are coming off a culture of using email, spreadsheet and some basic project management software, the job of moving everyone to a somewhat standardized way of doing things – managing projects, building software, measuring progress – can be daunting. More than technical learning challenges, more than software challenges – quality, integration, migration, performance, etc. – people simply have a hard time doing something they have been used to doing one way to a new, even if better, way. Yet, in spite of conventional wisdom, an overwhelming majority of our customers have succeeded in meeting this challenge through a combination of process, scope control, phased implementation planning, management buy-in, user buy-in, and more. More often than not, two of the key ingredients to success have been to keep things simple – and to aim for speedy, short cycle-time implementation milestones. The resulting success and the perceived (and real) progress of the implementation itself provides a positive reinforcement which further propels further implementation!

Digité SaaS - Solutions as a Service

Agile ALM or Application Lifecycle Management has become a force to reckon with, especially in the Global Delivery Model. Most technology companies – small or large – are trying to leverage distributed resources and teams to deliver their products and services. With the events of late 2008 and 2009, interest in SaaS applications has made it a viable business model once again. We believe that we MUST share with our customers, especially the Small and Medium Business enterprises, the lessons we have learned over the last 8 years in Digité with respect to overcoming the 2 challenges discussed above. Digité's Agile ALM on SaaS is our new service that aims to do precisely that.

Please come check us out at www.digite.com/saas. If you like what you see, please contact us at sales@digite.com!

Mahesh Singh

Vice President - Product

Digité Improves Quality – of Life!

2009-11-26T02:28:00.000-08:00

(ALM for Developer Series)

As a Testing manager in Digité, I am perhaps best placed to share Digité Enterprise's impact on my team's and my work.

Prior to using Digité, we used to manage our test inventory in Excel sheets – which is how a lot of organizations and teams still manage their test repository. These were multiple sheets that were organized module-wise. Test results were similarly tracked in Excel and we would depend on a combination of filters/ pivot tables in Excel to help us identify the failures, resubmit them for execution, etc.

Simpler and More Accurate Manual Testing

Since we moved all our Manual Test Inventory from Excel to Digite, life has become simpler. Earlier, for any regressing test cycle, it was difficult for a team lead to consolidate the test status when our test suite was divided across 20 testers. At the end of the day, they would have to chase everyone to mail back their testing status, find out how many defects were identified, calculate pending test cases and then redistribute the same so that testing could be completed on schedule.

With the Test inventory automated in Digite Enterprise, the Team Lead can just execute a report to gather the status. The report gives them the current testing status, number of pending cases, number of failed cases, number of defects identified in the system, status of those defects and when are they expected in the next development cycle.

Effective Test Automation

Further, we also track our automated test case inventory in Digité Enterprise. As the automation team makes progress automating manual test cases, the test cases automatically get excluded from the manual testing cycle using a simple filter in the product. Earlier, this was tracked in Excel by my team leads for automation and manual testing. Maintaining consistency of this information by checking Excel files manually was complex and time consuming. Further, these would never tally because they would be done at different points of time and data was dynamic. Now we have ability to get all sorts of reports – module-wise failures, priority-wise failures, tester-wise defect identification, etc.

Leveraging Integrated Application Lifecycle Management

Managing the overall testing would have been very difficult without Digité Enterprise. Test case development starts early in each release we plan, right after Product Management delivers the Use Cases/ User Stories for the release. The QA team develops the Test Cases for each Use Case, automatically linking them via Traceability. The Test Cases are jointly reviewed by Product Management, Engineering and QA for each release and approved.

With 3,000 QTP Scripts and around 1,500 business functions, we track over 7,000 manual test cases (sanity, smoke and detail test case) in the automated test repository. Product changes and their impact to automation testing assets are tracked through CRs in the automation project. We track the product branches on which this change is applicable. With our Subversion integration, every change is directly reviewed in Digite Enterprise.

Automated Tests run every night, and the results are available for analysis the next day. After completing root cause analysis of all failures, product defects are filed in Digité's Defect Tracking module. A report gives us an assessment of how well the nightly automation ran. A number of metrics are automatically calculated to give the nightly test trends across a month, last run's defects - product and automation scripts defects, script failures (false alarms and genuine), current status of product defects and the number of script failures due to the product defects, by module.

Significant Productivity and RoI

In the last 2 years since we moved our entire Testing process to Digité, our manual testing team has shrunk from 10 to 3, while we have kept our Test Automation team stable. Our test repository has added from 14000 to 19000. That is a huge jump in productivity and a significant ROI in the last 2 years.

Ashwini Lalit
Manager – Quality Engineering, Digité, Inc.

Nasscom Product Enclave 2009, Bangalore

2009-11-21T04:42:00.001-08:00

In an indication of the growing ranks of software product/ engineering companies in India, Nasscom – India's premier software industry association – organized its 3^rd Annual Product Enclave, in India's Silicon Valley – Bangalore. I was there to represent Digite there along with my colleagues. The theme at this year's conference was "Positioning to Win" – and underscored the need for software companies to establish their brand globally through innovation – both in product and marketing – and thought-leadership.

At Digite, we understand the importance of this. Being a leading-edge software startup is not the best place to start establishing a brand. But meeting and working with pioneering customers and partners, as we have done over the last 8 years, has been an incredibly rewarding experience – and well worth the trip on the leading-edge! In the coming year, Digite plans to roll out some pretty innovative initiatives both on the product and the marketing fronts, all of which will unfold here in our blogs and websites over the next several months. The Product Enclave was a good venue to hear some of the industry luminaries validate our initiatives through their thoughts and ideas.

This year's event had Guy Kawasaki of Garage Technology Ventures, Rajesh Hukku, former CEO of i-flex Solutions (now Oracle Financial Solutions) and K. Ganesh from Tutor Vista, among others. Guy Kawasaki was, as usual, brilliant – both in ideas and oratory! Some of the points he made for small/ start-up technology companies -

Build what you want to use
Niche Thyself – Jump the curve and Create the new curve
Pay no (or very little) money for Marketing, Tools, People
Instead of sucking up, suck down/ across
Use Twitter – fast, ubiquitous, instantaneous and FREE
Give people value constantly and once in a while earn the right to sell
Put everything in the cloud (pay less for infrastructure)
Ship than test
Forget the VC
Don't let the Bozos grind you down

K. Ganesh, CEO of Tutor Vista keeps it simple. Tutor Vista is an incredible virtual tutoring success story with 20,000 students (just 20 times more than what the VCs thought was ever possible!) and 5,000 teachers that used simple yet effective techniques such as on-line 24x7 live chat and getting 15-day free trials establish credibility. Inspiring story that! Rajesh Hukku's story of i-flex and its trials and tribulations and the 'roll-up your sleeves and make it happen' attitude that lead to its success is a great example of innovation on all fronts – product, marketing and overall leadership.

To sum it up, I will borrow from one of the panel speakers from Tejas Networks who spent 25 years in the US before recently moving back to Bangalore. He said "the environment in Bangalore (read India) is very exciting, perhaps as much as anywhere in the world, the ecosystem is getting there and the time is ripe for innovation and products to happen". Therein lies the opportunity for product companies.

Breakaway opportunities uniquely present themselves in the curves; and races are won or lost in the curves. At Digite, we are uniquely positioned to address a new set of challenges in the area of globally distributed software development and application lifecycle management with curves like Agile and Lean methodologies already upon us. It promises to be an exciting 2010!

BM Raghunath
Vice President, Business Development, Digite, Inc.

Do ALM Tools benefit the Developers?

2009-11-12T15:06:00.000-08:00

(ALM for Developers Series)

Recently, I got asked this question by a prospect – a large bank's SEPG head. Their exact question was – How does Digité help with the developer experience? Clearly, Application Lifecycle Management (ALM) tools have made the life of the PMO, the SEPG, the Quality group, the Project Managers and the executive management better. But how do they benefit the folks doing the actual development?!

Here was my response to them about specifically what we, at Digité, have done to improve the life of the Development Team – the Business/ Functional Analyst, the developers and the testing team.

Digité's Unified Inbox automatically collects all the tasks and artifacts that a team member needs to work on, sorted by project, priority and urgency. No more time wastage in search and follow-up to figure out what work they are supposed to do next!
Digité's integrated set of products ensure that there is minimal wastage of effort in learning the tool itself, in navigating from one tool to another due to an integrated UI and a single repository, other than the code repository.
Our Requirements, Change and Test management features enable Business/ Functional Analysts, Testers and users collaborate continuously to identify, build and manage requirements use cases and test cases collaboratively. They work on individual requirements, decompose them online, baseline and review them; and track any changes to them throughout the development lifecycle. For the Agile practitioners, Digité provides User Stories and Iterations to plan, prioritize and build their user stories in iterations assigned to specific releases.
Digité's Integrated Traceability ensures that developers understand a software requirement along with other related items – user requirements, change-requests, test cases, documents – all thru a single integrated view – so that they can work with a holistic understanding of the business. Similarly, the developer's ability to view a defect holistically – through viewing associated failed test case(s), the related software/ user requirements, etc. means that a developer gets a full understanding of what failed, why it may have failed and do a full impact analysis – thus ensuring that the developers do an effective job of fixing the defect. This prevents a significant amount of rework and ensures a much higher level of initially delivered quality and conformance to requirements.
Our Eclipse/ Subversion/ CVS/ VSS adapters ensure that navigation between the developer's environment and Digité is minimal – and developers and testers can focus on doing their work rather than managing their work. Within Eclipse, they get to view all of their tasks and other work items and are also able to post their effort to Digité Timesheet without leaving the Eclipse environment.
If tracking effort is important to you, you may like this. Our customers report that their developers take anywhere from 30 minutes to 2 hours each week (!) to update their timesheets. We provide an automatically populated timesheet and integrated time-logs available alongside each work item for immediate update as soon as a developer completes working on it.

All of the above have resulted in anywhere from 20-35% direct impact on developer productivity and equally importantly, 45-60% improvement in initial quality of product delivered and overall organizational productivity.

At Digité, we use our product for pretty much everything we do – as Sudipta, our VP of Engineering and Services, explained so well in the previous blog post – Are you still without an ALM Tool? I can't tell you how many times our team members have given us feedback about how convenient and time-saving it is for them to use Digité for managing their own development/ implementation work!

In the coming days, our own team members from our Development, QA and Product Management organizations – will tell you, in their own words, how they see the impact of Digité on their own work and indeed their lives.

We would also love to hear from you about your experience using Digité or any other ALM tools in terms of Developer experience and productivity.

Mahesh Singh
Vice President - Product

Are you still without an ALM Tool?

2009-11-09T11:45:00.000-08:00

Many of our customers ask the question - why have ALM tools not become a project necessity? Why are they not more “visible”? Are you one of those still wondering if YOU need one? Let me give you some real data from our own example using Digité Enterprise to help you decide.

Our code base is 1.4M LOC, certified on 2 databases, 2 app servers on 2 Operating Systems. That means 8 stack combinations, ignoring that we run on both IE and FF. Further, because we have many customers on old versions of the product, we maintain a minimum of 3-4 maintenance branches at any point of time. So, if you fix a defect on one branch, you have to replicate that across all other branches. How many hands-on people do you believe would be required to maintain this application with a steady flow of enhancements? If you did not know our head-count, I would suspect that your answer would be ‘around 40-50’. We do it with an average of 15 FTEs! If one has to look for productivity examples, I cannot think of anything better than that.

We maintain our Backlogs on the tool, we rank them and estimate them and then, depending on the capacity, determine how much we can do in the next release. That just defined our Release Scope! In all my past 20 years as a software/ application delivery professional, that process has taken 4-6 weeks! We do it in a couple of days.

Once our Release Scope is defined, we execute our enhancements using workflows.

Our test cases, manual and automated, are all online. They are defined module-wise and graded on their importance. Depending on the impacted modules in the Release, we identify our scope of regression testing with a few clicks.

Test execution and defect tracking is all in the system. We don't have to maintain long lists in spreadsheets trying to build pivot tables on status, resource-wise, age, etc.

Our customers file issues that we convert into to defects or enhancements. Once again, we do our impact analysis on the system, review it on the tool with comments and then, assign it for coding and testing using workflows. When we commit our changes (we use SVN), we identify the defect or enhancement it is for and completely traceability is established automatically.

My experience is that organizations handling an application of this size would have 3-4 Technical Leads managing a team of 30-35 FTEs and a full time Manager. We have less than 1FTE playing the role of a Release Manager. We meet once a week for 2 hours. That is the extent of Project/Program Management that we do. The rest is all online...

My CEO gets his full dashboard on the system, real time. No multiple versions from different managers, no data manipulation, no dedicated operations staff preparing Excel/Word reports on Friday evenings or over the weekend.

The results: we have made a release every quarter for the last 2 years. We have slipped once by 3 days. We have brought our defect rates down by over 30%. Of course, we have built a great team but without one integrated tool, we would have been in a mess, doing a lot of rework!

So, if you are not on an ALM tool, get on one! In 6-9 months, you can’t imagine building software projects without it. How many times do you handwrite a letter anymore?

Sudipta Lahiri
Vice President – Engineering & Professional Services

Is PPM enough?

2009-10-26T12:41:00.000-07:00

I have spent a lot of time over the last 10 years discussing or working with a large number of our customers who have moved away from the ‘traditional’ methods of managing software projects to a more centralized and “institutional” method. An overwhelmingly large number of these companies have evaluated Project Portfolio Management (PPM) tools as their first option for moving away from their disparate solutions, which usually would be a combination of MS Project on the desktop, email, spreadsheets and a lot of hand-waving!

The promise of PPM tools is enticing. From the capability of management dashboards that unambiguously tell you whether projects are in Green, Yellow or Red status, to being able to smoothly make Fund/ Kill or Go/ No Go decisions about a project that is not exactly meeting its objectives, the case for PPM appears crystal clear. Who would not want such capability?

The reality however has been somewhat different for a number of companies.

Can I really trust my PPM dashboard?

In other words, is the data reliable? How is it being collected, collated and consolidated? Is there a reliable process behind this? Are basic steps such as estimation, time tracking and baselining of projects in place?

When organizations and project teams attempt to move away from managing projects using office productivity tools and other point solutions, they are not just switching tools, they are very often changing fundamental processes of how they work and how they manage their work. PPM tools demand a significant level of data reliability – which translates to process maturity – at the ‘operational’ level; to ensure that all aspects of project effort are being looked at, all the project deliverables – not just tasks but various deliverables and work items - from requirements to documents, from test scripts to defects – are being considered in computing the ‘real status’ of projects. This means that execution/ operational level processes need to be in place and automated so they can feed reliable data to the PPM solution.

A lot of PPM efforts have resulted in failure due to this fundamental problem of lack of automation at the operational level of project teams and the lack of project team buy-in. Application Lifecycle Management (ALM) tools that include or integrate with PPM/ Process Governance tools can much more effectively help in this regard.

Where do I file my time for this issue?

One of the basic challenges of project planning tools such as MS Project is that they are great at project planning but not at managing project execution. While PPM tools have ensured that some of the earlier challenges of over-dependence on the lone project manager have been taken care of, they still do not take care of resolving such basic issues as tracking effort on unplanned work.

It is humanly impossible for a project manager to put down every last bit of work as part of their WBS. On the other hand, filing time in a common “Miscellaneous” task means losing visibility to where 15-20% of the project effort might be being spent, so that one could plan better in the future! Very often, PPM tools miss out on all the effort being spent on unplanned work in projects and thus relying on incomplete data for providing management status update.

Integrated ALM tools help by focusing on the project team and making them more productive rather than just providing a dashboard for senior management which may not be fully reliable.

Why are so many defects still open?

Have you run into these questions – “Is that project really green? Or did the PM omit to take into account the large number of unmet requirements?” Or, for that matter, “Is the testing task really completed? Then why are all the defects still open?”

The ability to drill down into a project’s ‘real’ status is most important for portfolio management teams. PPM tools by themselves, do not and cannot provide this visibility and still continue to rely on the abilities of the project manager and project teams to ensure that they collect data from all sources and tools manually before providing that update.

ALM tools with integrated PPM capability make the project managers far more effective by one, providing the PM a comprehensive view of the project and in fact, proactively alerting them of potential red-flags; and two, by dramatically reducing the overhead of collecting data from myriad sources and putting it all together for status reporting, resulting in as much as 40-55% increase in Project Manager productivity.

Where is the final revision of the requirement??!

The value of a single repository for all project artifacts cannot be measured. Having managed projects directly and indirectly for over 20 years, I have seen project teams struggle with the simple task of managing all the information and artifacts - requirements, change requests, documents, issues, defects, test cases, deliverables - related to their project across a combination of email, portals, network directories, configuration management systems and team members’ desktops – resulting in horrendous loss of productive hours and project delays. Just to be able to go to a single place for all of that – makes team productivity go up by as much as 20-35%! PPM tools do not address this crucial business need; and thus do not contribute to mitigating the very factors that lead to project failure.

I believe PPM tools are great management tools for executive decision making. However, they do not focus on or deal with the operational processes that need to be in place so that PPM tools get reliable data. In order to have a good executive information system, it is imperative that the operational processes are cleaned up and automated through a good set of execution/ operational tools. In the world of applications, products and software, ALM tools do precisely that. To have a good PPM implementation, ALM solutions are not only necessary but are also a pre-requisite!

Mahesh Singh
Vice President - Product

Collaboration in Requirements and Change Management

2009-09-29T01:28:00.000-07:00

The topic of Requirements and Change Management continues to spark enthusiastic debate and discussion amongst the software community. And for obvious reasons!

I was talking to an industry analyst recently – and he himself drew attention to the fact that software requirements are so hard to do, unlike a bridge or a tunnel or building - where requirements were so much easier to define. Absolutely!

Yet software teams and organizations continue to pay scant attention to this critical discipline that is responsible for the failure of such a high percentage of software projects. A recent study and analysis done by IAG Consulting (http://tinyurl.com/dldfwb) had these (not so?) surprising findings:

Companies with poor business analysis were 3 times more likely to see their projects fail!
Bad project requirements can result in up to a 60% hike in project costs, and
For a $3m project with poor requirements, companies would pay an average of $5.87m!

The study concluded that projects and organizations where Business and IT worked collaboratively on requirements were much less likely to see cost and time overruns than those that did not.

The Software Engineering Institute (SEI) has determined that projects that spend up to 60% of the overall effort in Planning, Requirements Analysis and Design have dramatically lower cost and schedule overruns compared to projects that spent that level of effort in Coding and Testing.

This should be fairly obvious - after all, if you don't know what you have to build, how can you build it well? Yet, software professionals, teams and entire organizations continue to suffer from this lack of focus on up-front requirements definition and ongoing requirements management. There is also no doubt that requirements will change - for a variety of reasons. Managing the changes to the requirements on a continuous basis and keeping an eye on the impact of these changes on project budget and contract dollars is what project managers must do all the time.

While the importance of granular requirements management, project managers and business analysts have been hampered by lack of technology support to enable that. Traditional requirements management tools have been too complex, too expensive and too stand-alone to be effectively used. Thankfully, however, a new generation of ALM tools that provides lightweight, web-based, fully-integrated functionality have changed that landscape. One of the most important capabilities these tools provide is collaboration.

Collaboration between business and IT, between customer and service provider, between marketing and engineering is key to ensuring that all stakeholders on a project stay in agreement on precisely what requirements need to be delivered by when. At the same time, it helps both sides objectively decide when requirements change, why they changed, whether they are justified and if they are budgeted for.

The importance of collaborative and ongoing requirements and change management cannot be over-emphasized. After all, in the definition by quality guru, Phil Crosby,

Quality = Conformance to Requirements

I would love to hear from you how you are tackling this significant challenge – whether in-house or in an outsourced situation.

Mahesh Singh
Vice President - Product

experience is the product

2008-11-14T03:29:00.000-08:00

Came across this wonderful presentation on product design by Peter Merholz of Adaptive Path. Please take some time to go through it as it will certainly be useful to you at some point in your career.

Here are my notes from the presentation. These points would be much more clear if you see the presentation where Peter gives some very interesting examples to support it,

Don't focus on technology or features. Focus on the experience that you want to create and then build a system that gets you there
Technology as a product design strategy can be used on ly when the technology is disruptively new! e.g. First generation word processors were very difficult to use. You needed to remember many commands in order to work with it effectively. But because they were technologically far superior than the alternative "type writer" of that era, they became popular.
Once technology becomes standard, we tend to compete on features. And there are numerous examples where competing on features has been taken to the extreme. One such example is Microsoft WORD. A very good example of this phenomenon is VCR. When VCRs first came out, for the first time they allowed people to record live TV. This made them very popular. As years passed by VCR got bloated with features. So much so that people could not even program it anymore. So adding more and more features actually caused the decline in VCR usage. (Then came TiVo that once again revolutionized ease of use when it came to recording TV programs!)

Some take aways from the presentation,

Designing from outside in...Christopher Alexander says, to design pathways first put the lawn in place, then see where people actually walk and then add paving!
Create an "experience vision" statement. e.g. Palm Pilot vision was, a. Fits in shirt pocket, b. Syncs seamlessly with PC, c. Fast & easy to use and d. cost less than $299. Concise and clear vision that made Palm design a compelling one.
Leverage the System! This one is my most favorite! System as a whole does not get simpler however the experience of using the module of the system become much more enjoyable. e.g. iPod only allows you to do basic things like browse, play, rate audio songs. For everything else such as creating actual playlists you have to use iTunes. Thus Apple simply leveraged the system to remove unnecessary complexity from the everyday use of the product, iPod and the rest is history!

Experience Is The Product

View SlideShare presentation or Upload your own. (tags: petermerholz dconstruct2007)

Changing the world, one light bulb at a time!

2008-11-05T04:04:00.000-08:00

Here is an invention that will boggle your mind. These are the new light bulbs that are use virtually no electricity and they last for 50,000 hours. (That is 6 years of continuous operation!)

The fins on the light bulb are actually designed to allow heat to dissipate. These bulbs are designed by the company LightingScience. Each bulb costs over $125 each!!! Before you jump to conclusion that you will never buy such an expensive light bulb, consider the fact that you will save enough electricity in 7-8 months to offset the price. In addition you will NEVER have to replace it! I remember solving industrial engineering stastistical problems that dealt with the cost of changing light bulbs for large companies. Because cost of changing light bulbs is very high, it is actually very routine to change them even when they are not completely worn out. This is a huge wastage! Using one of these bulbs you are virtually eliminating the need to change light bulb ever!

When I look at this new invention from my product management hat, it is such an iconic example of doing new product development. When doing new product development, it is very essential to have a fresh perspective and not hamper your creativity based on what exists today! Only when you avoid the trap of doing something similar to what you know or see around you, then you can create something truly disruptive and revolutionary!

Let me know if you think you would buy this product at this entry price tag. Do you love your planet enough to take the plunge? :)

Facebook kids on to something big for enterprise?

2008-10-06T01:49:00.000-07:00

Facebook co-founder Moskovitz leaves to start group collaboration company

It is a long shot but I would be curious to track what these kids come up with next and how it affects Globally distributed ALM space! These guys could very well come up with the next disruptive phenomenon/paradigm that we so desperately need! And who better to do it than co-founders of Facebook? Click on the link below for the full article or just read the excerpt below

….and the new project requires a company built around it from the ground up, with the goals of efficiency and group collaboration embedded deeply into its DNA from day 1.So we’ve decided to leave Facebook (in about a month) and start a new company, to build an extensible enterprise productivity suite, along with a high-level open-source software development toolkit, built for the Web from the ground up.

http://venturebeat.com/2008/10/05/facebook-co-founder-moskovitz-leaves-to-start-group-collaboration-company/

NASSCOM Product Conclave Conference 2008

2008-08-24T23:15:00.000-07:00

I had the pleasure of attending the second annual product conclave conference organized by NASSCOM. This year I was not only an attendee but a speaker too. The conference was held on August 11th and 12th at the Grand Ashok hotel in Bangaluru. This year there was much more participation than last year which was the inception year for product conclave conference.

This conference focuses on indian software product business and brings together luminaries from all known and unknown Indian product companies.

With slowing services sector and increasing VC funding there is lot of interest in software products business. However building a great software product requires a different set of skills and most importantly a different mindset. My speaking topic was centered around the same theme, "Product Development to Product Management". I had the fortune of sharing the panel with VP of Product Management from Yahoo! India, VP of Product Management from iFlex software and a senior Marketing manager from Rational/IBM India office. I talked about the role of product management and how it gets confused frequently. As software product business takes root here in India, there is great need for educating and dissiminating this information. As such our session was very well attended and got great response. So much so, that I may be helping out NASSCOM further with creating/delivering "product management basics" course in future.

Suhas A. Kelkar
Vice President Product Management

Right way to build brand!

2008-04-24T03:31:00.000-07:00

Google named world's number 1 brand!

Google has been named the world's number one and most powerful brand for the second year in a row, with an estimated value at $85,057 million. This, according to BrandZ's top 100 brand ranking for 2008.

If you notice a company such as Nike is coming at #53. This is very surprising to me! I see lot more advertising and marketing done by Nike as compared to Google. These days every sport that you see on TV has Nike sponsorship! This holds true from US athletics to European soccer leagues to the latest Indian Premier League! You do not see any advertisements by Google at sports events, on billboards (except may be in Mountain view CA), or on TV! Despite that it is coming in at #1.

This talks a lot about the popularity of Google and it's products. If you build the right product that solves right problems, people will notice you! Brand equity you build this way is long lasting and it is the right way to build brand awareness!

-Suhas A. Kelkar
VP Product Management, Digite

Process Becomes a Breeze in Tampa at SEPG North America!

2008-04-14T23:33:00.000-07:00

Posting a conference report from Mike Amend who is a Senior Director, Business Development based out of US.

Digite definitely led the wave of Process Improvement on the beautiful shores of Tampa Bay. Although, I can assure you our feet never had the time to touch the beautiful sands of the pristine Florida beaches! Our time was overwhelmed with interested parties from the United States, Europe, South America, Asia and parts unknown (California?). Even though this was SEPG North America, the rest of the world was very well represented!

Digite attended and exhibited at the 20th Annual SEPG North America, March 17 – 20. The reception of our solution to those most interested in Process Leadership was extraordinary! These people knew the importance of process, but also knew that the supporting pieces of our holistic solution solved many of their common issues that doomed the best honed process. Vision from our Project Portfolio and Management piece of our solution, coupled with out completely integrated Collaborative Software Development pieces (Requirements, Change, Document and other IT Management needs) provided the support to both monitor, measure and enforce process throughout the Enterprise. They were AMAZED they could get this all from one, web-based tool! They had all been forced to use lightly interfaced point-solutions that did not work well together – even if all came from the same vendor! Because we were so different, Digite was a BIG hit!

The show was attended by Ram Subramanian, Mahesh Singh, Mike Amend and Rahul Kapoor. As usual, the four of them traveled quite well together and found the food of the Tampa area exceptional! Mike and Mahesh judge the culture of any destination by the quality (and quantity) of the cuisine at the best Thai Restaurant in the area! They were pleased to say that Tampa Thai is some of the best (and most abundant) they have enjoyed outside of Thailand!

Next year, the SEPG conference will be hosted by San Jose and I am sure that Digite will make the grade again as one of the Premier stops within the Exhibit Hall for those interested in Process Improvement and Governance within the Application Lifecycle Management of the Enterprise.

We look forward to seeing you there!
-Mike Amend (You can reach me at mamend at digite dot com)

this is how buzz words are born...say hello to "synchromesh"

2008-03-18T21:22:00.000-07:00

Ever wondered when/where buzz words are born...Recently Ray Ozzie had a keynote speech at the Mix 2008 conference and I was able to spot birth of a new buzzword, "synchromesh"

Ozzie teased the next evolution of his decades-long exploration of synchronization and collaboration, which he referred to as a "seamless mesh"--or what I'll call "syncromesh"--in his Mix '08 keynote in Las Vegas:

Just imagine the possibilities of unified application management across the device mesh, centralized, Web-based deployment of device-based applications. Imagine an app platform that's cognizant of all of your devices. Now, as it so happens, we've had a team at Microsoft working on this specific scenario for some time, starting with the PC and focused on the question of how we might make life so much easier for individuals if we just brought together all your PCs into a seamless mesh, for users, for developers, using the Web as a hub.

Mark my words, if Microsoft is successful in pushing their agenda, then you will be hearing more and more of the word synchromesh until it will be come part of the Oxford dictionary. Just recently I talked at a conference about SaaS and had made a slide that shows the logical progression of technologies. I guess now I must go back to it and add synchromesh :)

Firefox 3 five times faster than IE7...wow!

2008-03-12T09:24:00.001-07:00

Firefox 3 Beta 4 is 5x faster than IE7, 3x faster than FF2 by ZDNet's Ed Burnette -- The almost-but-not-quite-final beta of Firefox 3 (FF3 beta 4) is now available for download. The most noticeable improvement is speed. In some tests, it’s three times faster than Firefox 2 (meaning the test completes in 1/3 the time), and a whopping five times faster than IE 7: (Source: Mozilla Links) Other improvements in beta 4 include: Smarter [...]

Project Portfolio Management yields results

2008-03-11T22:23:00.000-07:00

I have been involved with PPM domain for quite a few years now. I have seen the very beginnings of the project portfolio management when we had to not only write software that would enable PPM but had to go out and educate customers on the importance of PPM tool. That was the time around 2001-2002 when companies were strapped for cash. Also around the same time, Sarbanes Oaxley was just getting defined and corporate IT folks did not know what changes it really meant for them.

There were just a few players in the PPM domain and many of them simply grew out of their project management, rather than have a vision for top down portfolio management and setting up a PMO practice/processes.

Fast forward to 2008, and finally I am seeing studies that validate the usefulness of a PPM tool. See an in depth article, "ROI study: Product portfolio management yields results" posted to ZDNet.

The entire post on ZDNet is worth reading. But here is the most important section of it,

Key findings from the study include “savings of 6.5% of the average annual IT budget by end of year one and 14% (NPV) over a three year deployment period.” In addition, the PPM software examined:

Improves the annual average for project timeliness dramatically by 45.2%.
Reduces IT management time spent on project status reporting by 43.2%, reclaiming 3.8 hours of each manager’s workweek.
Reduces IT management time spent on IT labor capitalization report by 54.7%, recouping 3.6 hours per report.
Decreases the time to achieve financial sign-off for new IT projects by 20.4%, or 8.4 days.

Notice that not only it says that PPM tool will give you savings in terms of dollars but it also improves projects delivery by 45%. Sometimes people focus too much on the direct dollar benefits from a PPM tool and they miss out on the benefits such as increasing project timeliness etc.

I am very glad to see such reports coming out which validates my belief in the rigor of having PPM processes and tools in an IT organization.

NASSCOM Product Conclave Conference 2007

2007-11-25T21:09:00.000-08:00

NASSCOM Product Conclave

This week I was able to attend the first ever NASSCOM conference targeted towards product companies based out of India. Having realized the trend in Indian IT companies to shift up in the value chain from services to products it is quite appropriate for NASSCOM to start this initiative.

The conference was attended by who’s who of the Indian IT companies. CxOs and VPs from reputed product companies such as Subex Azure, Yahoo, Philips R&D and of course digité ;) were present for the conference.

The keynote speech by Sabeer Bhatia was the highlight of the conference. He made some very insightful remarks and said that for product companies to be successful they need to,

Challenge the status quo: Here he gave an example of iPod. When iPod came out there already were 30-40 MP3 players in the market. But Apple was able to challenge the status quo in that market and invent new market for themselves via innovative design.
Think out of the box. Sabeer criticized and cautioned that Indian educational system is such that we are not trained to ask questions. You cannot build new and successful products by just doing more of what is already known. You need to think out of the box. Product development needs to be disruptive and not incremental.
Take more risks. Sabeer quoted that silicon valley is built on failures not on successes. Nine out of ten companies fail before one succeeds. Hence it is essential to take more risks.
Think global. Build products that solve global problems not just india’s problems.
It takes time to build a successful product company. 4-5 years are needed to successfully build and launch a product. He mentioned how lucky he was to conceive, develop and launch hotmail in just 18 months which was a lucky anomaly.
Products are built not by large teams but small teams of highly motivated individuals. Founders of the product companies need to have product DNA!

Throughout the first day it was clear that no one was sure about the exact definition of the term “product”. It was finally Samir Palnitkar of Airtight Networks who put it in simple terms. He proposed a definition for the term product as, “Anything that scales disproportionately and does not require additional human resources for scaling up”.

Services companies have the distinct disadvantage that they have to increase their head count in order to scale in terms of revenues. On the other hand product companies, with an initial investment for building a product can then scale and sell it to as many people as they can, without too much additional cost. Incidentally, this is why the valuation for a services company is 1-1.5x (of revenue), whereas for a product company it is around 3-4x. An interesting comment from Dr. Lin L. Chase (Sr. Vice President, Technology R&D-India, Accenture) was that she has seen recently that product companies with SaaS offerings are demanding 6-7x valuation!

There were few other very insightful remarks by many other individuals. I won’t be able to attribute them correctly but will still list a few of them. Someone gave excellent advice to new upcoming product companies in India, “to spec the product globally but sell it locally”. Idea is to make the product successful in the local market before undertaking the global market challenges. The talk by Ashish Gupta of Helion Venture capital was very impressive.

One other remark was also very good. It was that don’t position your Indian product company on the basis of cost advantage (due to low labor costs). Instead of using the “low cost advantage", position it as “innovation leverage”. E.g. instead of saying that you can build the product for 1/3^rd of the cost, you can say that you can innovate three times more for the same amount of dollars!

Interestingly everyone was in agreement that “any arbitrage will tend to eliminate itself over time”. So the cost advantage enjoyed by Indian software services industry is going to be fetching diminishing returns. This is going to create some interesting conditions for the local IT market and will push it further in the direction of higher margin business models such as becoming product development companies.

All in all, I had a very good time at the conference and am looking forward to attending and participating in more such events by NASSCOM.

-Suhas A. Kelkar
VP, Product Management,
Digite

my first blog...

2007-11-15T02:31:00.000-08:00

After lot of procrastination, I have finally gotten around to creating a blog page. I plan to brag-err-blog about our product features and other general things that pertain to various topics such as,

Project Portfolio Management
Application Life cycle Management
SaaS, Web 2.0
etc. etc.