Digité Participates in Agile Coach Camp 2010

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:-

1. 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.
2. 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.
   
3. '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.
   
4. 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.
5. 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.
6. 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.
7. 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?
8. 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.
9. 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.
10. 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

(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?

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

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