Thursday 17 March 2016

Introducing SoftAgile™ from JamBuster.... or "Why one more Agile Tool?" as an ALM analyst asked.

We at JamBuster Team are very proud to introduce our new Agile Tool, SoftAgile, over next week!!!

SoftAgile was born in a very counter intuitive way.

In 2014, we saw that to build an application required using multiple ALM tools: product or backlog definition tool, project planning, sprint & task management, testing, defect & issue management, release management along with integrations to IDE and SCM tools. It is almost like a ALM quilt made of patchwork of tools!

One of the big challenges with such patchy ALM is that you have to keep on switching between different tools, and thus an integrated view of the project is almost impossible.

Different ALM tools for single Agile process

So we envisioned an end-to-end agile ALM platform that will have five modules: define product, plan program, develop software, verify quality & customer support. We named it SoftALM®

We got lot of interest from a software product companies to become our beta partners. And their feedback started to bring polish to our vision of SoftALM®.

And then it stuck to us that the SoftALM® is most suitable to either Software Product companies or those who build applications for their businesses and customers, like insurance, banking or e-retailer. The focus here is developing software as a product.

The feedback from our software services beta partner, was of course, by now understandable. They felt SoftALM® was a bit too product centric for their use.

Service companies and start-ups suggested could we change the focus more to project and customer?

This meant almost taking out product axis and replacing it with customer, project and application focus. This was the birth of SoftAgile. It is thus counter intuitive that we would built a big Agile ALM platform for product focus, and then carved out a smaller application from it. Of course, SoftAgile therefore benefitted from instant enterprise scalability.

Single platform for different ALM and Agile functionalities

Turned out, the SoftALM® was built so logically that it's transformation to SoftAgile was swift. We took about 15 months to build SoftALM®SoftAgile took only 2 months to be carved out!

So you can see why we built these two tools!
  1. To tailor each agile tool as per product (SoftALM®) vs project (SoftAgile) focus of end users.
  2. To provide integrated applications that provides end-to-end capabilities for either of these end user groups.
  3. To provide tighter integration between ALM attributes, that reduces rework and provide total visibility across product and project axes.
Well, when was the last time an Agile ALM software gave you a dashboard that combined your entire project work flow, like our DashFlow™ - the project dashboard in SoftAgile? This is how we saw integration working for you.

Dashboard and flow in SoftAgile

During these 2 years, we discovered an another view of iterative agile-namely improving software through feedback over multiple early and many releases... more like crafting software!!!!

So now you can unleash the power of your agile team to craft your next great software withSoftAgile!

Where Does the Agile Gets it Agility?

While we have been dilly dallying moving to agile practices over last few years, early this year we decided that our small product team needs to be fully agile over next 6 months. The last 8 months of transformation has helped us all see whether Agile is as agile as it is made out! We saw 40-50% increase in team velocity over waterfall for the same team!


Waterfall focuses on a release that spans across define, design, develop and verify to develop multiple features in an almost assembly line manner. Agile divides the features into user stories (as if sub-feature) and each of these user stories is defined, designed, developed and verified within one or more iterations by a dedicated scrum team. We discovered that this difference between waterfall and agile manifests to accelerate velocity through following three sources:


A scrum team is functionally complete team that focuses on a few user stories and works towards their completion or achieving the ‘Definition of DONE’ during an iteration or few. For this team, any question that stands as an impediment to DONE becomes a high priority task, not a to-do list item. A dedicated, complete team focused on user story means it gets a detail attention for UI, development, quality and integration, thus reducing rework (which is common when large teams work on large sized efforts).


Thus a focused, dedicated scrum team is the heart and soul that ensures agility of Agile and therefore the first source!


In Agile, the user stories get fully developed and delivered in iterations, while in waterfall, we had to wait until multiple iterations are rolled in a release to have a single feature delivered. Thus agile scales down its focus from features to take an ‘a la carte’ approach of developing user story. This focus on user stories as opposed to feature, adds to project agility as the second source.


Those poor souls harassed by ghost of waterfall projects know well that it is the rework at the end that really burst the project deadlines. The incremental approach of agile provides the opportunity for early customer reviews and hence early inclusion of change requests and early rework, thereby keeping ghost of rework in-check! We also saw, that early feedback seems to invigorate teams to get it DONE and serves as the third source of agility!


Thus, the agility comes from dedicated scrum teams, focus on user stories and less rework due to early feedback! This of course starts from team attitude! Attitude of scrum team to get stories DONE with high velocity and superior quality, with a healthy attitude towards feedback!
jambuster.in