Digital Business Office for Remote Teams.

In this Digital age and long commutes, do we really always require an office space to work?

Turns out, now a clear new trend has emerged of working remotely. Remote working encloses a variety of arrangements in which “work”, traditionally conducted in a physical office space is instead performed from the employee’s home or a satellite office or even from a coffee shop. Gone are the days when working remotely was something only meant for sales and marketing employees.

Rather with globalization, working remotely with main office has become a necessity. The congested, long commutes are not only costly on wallet, they also affect health and create stress. Add to that increasing office rent, and companies are looking create a win-win situation, by facilitating remote working.

With digitally enabled virtual office, many office related tasks, and even jobs can be done remotely. Add to that the many benefits of working remotely, depending upon person’s perspective. You can simply work in the comfort of your home and make the world your office. Collaborate with your colleagues in coffee shop or through audio or video chats. Key benefits that have encouraged remote working are:

  • No Commuting reducing stress.
  • Work-Life balance due to reduced commute time.
  • Increases productivity due to less stress.
  • Focused collaboration instead of constant disturbances.

So what has exactly enabled Remote Working? Technology – specifically Digital Cloud has reshaped the way we work.

In the past, remote teams managed their work through multiple long email trails and maintaining history, files and folders. Thus, lot of their time was spent in preparing, managing and messaging the data. Thus, their productivity could be a nightmare. Now things have evolved, and you are a single click away from an orderly virtual office. With another click, you can get a custom report. Also, instead of waiting for getting data from someone’s spreadsheet, now the corporate data sits in a database with controlled access with a click. That is the power of digital business platform.

So what is a Digital Business Platform? Well, as it says, it is a cloud software that offers following capabilities:

  • From Anywhere, At Anytime: In this Digital world, physical office is being replaced with Digital Virtual Office. Connect from your home, a cafe or from your customer office!
  • Integrated Access: With a single login, access, modify and analyze your HR, Customer, Project & Product/Services data. Thus, your team use self-serve to raise an HR request, chat with colleagues on a project or define requirements or give approvals.
  • Digital Collaboration: Work with your team or invite your customers to connect with you to collaborate on project or report and resolve an issue at digital speed.

To enable this digital office trend, JamBuster has recently released its latest offering AgileBiz. AgileBiz provides your team a complete digital virtual office, with a single click. It’s available anytime, from anywhere.

AgileBiz Integrated Business

Experience the AgileBiz through the product tour. See how AgileBiz makes the working fun again!


How Digital Transformation Is Changing Our Lives: Part 2 – Amazon

No story of digital transformation can be complete without the Amazon story.

I was a regular visitor to Barnes & Noble’s stores. I am a speed reader, who loves browsing through books, before buying them. B&N offered opportunity for customers like me to purchase books that I will come back and read again if it is in my library. And the Starbucks coffee helped too.


But that changed in 1996, as I heard about a company called Amazon. Amazon enabled you to order books online, after you previewed through few sample pages, online. The book was delivered to your door in 3 days.

A major shift in this workflow came in 2007, when Amazon introduced Kindle device. Kindle connects you to Amazon marketplace, so you can browse through books, read samples and previews, and buy the digital copy of the book, to be read on, what else, the Kindle. Here came the e-book. Do appreciate that components needed for such shift took almost 12 years to be ready, since the Amazon sold its first book online, back in 1995.


Then around 2009-11, Amazon unleashed Kindle as a software to be used for PCs and smart phones. In doing so, they brought back their transformation focus to original workflow of browsing, ordering, fetching and reading books, and not the medium – the kindle or paper copy.

But, the transformation became truly complete, when In May 2016, Amazon released the Kindle Audio Adapter for reading e-books aloud via a text-to-speech (TTS) system for the blind and visually impaired.

At this juncture, Amazon digitally transformed ‘reading books’ to ‘listening to book’ and in between they brought in new population who could now enjoy the world of books.

In part 3, we will look at social implications of this Digital Transformation.

How Digital Transformation Changing Over Lives: Part 1 – Indian Passport Seva

We live in a world of cliche and buzzwords, along with technology innovations that is reshaping our lifestyles. So the relevant question -is the Digital Transformation just a current buzz or for real! If it is real, how is it affecting our lives?

Let us take a before and after example: Indian passport application was one of the worst experience, not so long ago. Unhygienic, unventilated office filled with unruly crowds and for-a-fee agents. It was like living through a sequel of Nightmare on the Elm Street, that showed you how bad third world government services are. No one knew for sure which documents you needed, nor was there visibility on when you will get new passport. Costlier agent you used, further away you got to stay from this inhuman process, only going for signature or so.

Last February when my wife, Suneeta, renewed her passport, it was a very different experience. This time around, she filled her application online at government of India passport site( ), sitting at home, on a Sunday evening. She then booked the meeting on-line, for which she had many options to choose from. Then she up-loaded digital images of required document proofs. Turns out, she needed only two. All said and done in 30 minutes. On the Tuesday of the interview, Suneeta went through normal token-based queue with five or so different processing units, taking about 55-60 minutes. No crowd, only short queues, decent furniture, air conditioned offices and polite crew. At the end of which she got all okayed to pay, meaning renewal approved. Same week, Friday morning Suneeta received SMS mentioning that her new passport was dispatched earlier evening. In the afternoon, courier delivered her new passport to our home.

Ten years ago, when I returned to India, it was unimaginable to think that one could renew passport in 5 days as a normal service, by spending no more than 4 hours (travel time included), without an agent.

This massive change or really the transformation of otherwise manual, tedious and stressful human experience into ‘warmth of your home online application and a small polite biometrics appointment’ is an example of digital transformation.

I am sure, one day this experience will further evolve. A conference call will enable the digital passport to be updated automatically, instantaneously through a biometric marker such as the retina check on your phone- all done in few minutes or even seconds, and ably assisted by a friendly, patient robot through the video call.

But for now, Indian passport is as close to digital transformation as current technology infrastructure in India allows.

One could say that this digitalisation started sometime in early 1990s when Internet revolution came out of scientific laboratories into public domain, with browsing, email and input forms that took your information online. Or may be late 1990s when passport information could be browsed on web. So why was that not transformation?

Well, it can be called a shift, as due to technology gaps, digitalisation was limited to a few specific actions, but not nearly a complete workflow per se. The digital transformation is thus about taking a workflow that may contain tedious manual tasks with stressful experience, but otherwise adding little human expertise, and making it painless and reducing the time duration by order of magnitude.

We will take a different example in next week’s blog.

Scaling Agile for Enterprise or Scaling Enterprise for Agile?

The success of the Agile with smaller teams have got the attention of enterprise teams. The question is whether it can be duplicated when scaled to enterprise size.

To bring scalability, we must first understand where does agile gets it agility!

Our experience of moving our small waterfall services team into agile product team over last two years, told us that agility comes from three sources:

  1. Focus on story to get DONE (a smaller unit than application (waterfall) or even feature)!
  2. A dedicated, multi-functional team that works collaboratively, autonomously to get this story DONE, and
  3. Early feedback of customer, ensuring early and guaranteed delivery of business value.

A focused, dedicated scrum team is thus the heart and soul that ensures agility of Agile. Look at the agile team of 6-8 like an $50 entree in a chic restaurant. Thus, scaling restaurant’s operation is not offering buffet, but creating and managing multiple teams that can simultaneously feed hand-crafted $50 entrée to 500 patrons a night! You get the idea.

And there lies the real challenge in scaling. Like in chic restaurant, there needs to be lot of preparation, well defined workflows, roles, and responsibilities. This is exactly what different enterprise scale frameworks are trying to do! They try to define terms, workflows, roles and responsibilities. SAFe®, for example, provides workflows that connect product definition module to program planning and software development modules through portfolio module. Also the roles and responsibilities in each of modules. These process frameworks need to complemented with transformational framework.

Here is what I mean by transformational framework: assume that a 5 people agile team get DONE 10 stories through a 2 weeks’ iteration. An enterprise team of 500, will need to have 1000 stories backlog ready at the start of iteration time box. Not only that, come next iteration 2 weeks later, another 1000 stories need to be ready again. Over the year, your team needs to define 26,000 stories ready for development. So the first challenge, is ensuring a steady stream of stories to feed your 100 agile teams, at the rate of 1000 stories per two weeks’ iteration. (These calculations always make me appreciate the prep a la carte restaurant has to do to serve 500 people a night.) How do you transform team, capabilities and processes that achieve this?

So how do handle 26000 stories a year? An enterprise with 500 people, most likely will need to start categorizing their products in one or more product lines. Similarly, to manage backlog of 26000 stories, it will need at least three levels of backlog hierarchy as Epic > Feature > Story. Assuming average 50 stories per feature, 50 features or 2500 stories per epic, this backlog classification can handle 26000 stories in about 11 epics or an epic release a month.

Next is to ensure that there is a product line + systems group that has capacity to create 26000 stories a year. Traditionally, most organizations assume that having larger developers proportion in team is the key to agility. We saw that once you go agile, your team composition changes considerably. Then again you may want stories to be groomed close to say 80-90% before iteration starts. Define too early, and they do not allow flexibility; define too late and development can’t finish. So optimizing out-of-phase of story definition/grooming with development is key.

After ensuring product and backlog scale-up structure is in place, program management need to be scaled, along same line – people, capabilities, process. Finally, task management needs to be scaled by providing and managing task container hierarchy of program, release and iteration for multiple teams. Here lies the challenge of managing the interconnected stories across teams and sequences and so. Thus, scaling agile in an enterprise will require transforming team compositions, bringing in newer work flows, roles and responsibilities. While current frameworks tell you where to reach, the challenge lies in how to reach there or how to transform, while continue to deliver on daily basis. For now, that is topic for a next article.

Also, this in no small proportions brings out a need for an agile development tool that is built for enterprise grounds up, and build for transformation from waterfall to agile. These were major considerations, why we built SoftALM® – our agile ALM tool on enterprise scaled model from day one and then developed SoftAgile™ as enterprise project tool.

Throughout this you might have noticed, the agile team is really staying 6-8 people strong. And it is the enterprise that needs to regrouped, scaled and hence transformed.

Essentially, it is not scaling agile for enterprise, but it is the enterprise that needs to be scaled or transformed to leverage agility!

Why Choose SoftAgile™ Over Jira Software®?

Remember the time Jira was a new kid on the block? It was a nice simple to use, value for your money, yet extremely reliable tool.  Well that kid is now grown into a complex tool, offered as too many pieces of a puzzle and of course, getting costlier every time a newer combination is offered.

SoftAgile is built through 10+ years of experience of outsourcing, building and managing a 400+ strong enterprise product team. It therefore enjoyed advantage to learn from the pioneers, the good features, but also identify some major gaps from existing offerings.

Softagile philosophy is an easy-to-use, highly integrated, built for transformation from waterfall to agile, an agile project tool that lets team craft great software!!!

Here is how SoftAgile works for team, compared to Jira!

    1. SoftAgile and SoftALM® provides solution customized specific to product or project focused teams.
        • The product teams, such as software product makers or large IT groups, look for Agile ALM Tools as these tools essentially covers the lifecycle of a product – from product definition, project built to develop, software development sprints, product quality and customer support.
        • Project driven teams such as software services teams or small IT groups prefer agile project tools as these tools allows an outsourcing services company to define a project to develop an application for a customer using customer defined features, plan project and develop software. Thus, define product and verify quality modules of a typical Agile ALM tools are absent in project tools.
        • When we were building SoftALM® with a combination of product and project driven customers, we appreciated this difference. Thus we first built SoftALM® – an Agile ALM tool for the product teams and then we carved out SoftAgile from it, for project driven teams.
        • Jira is built as a project tool, more for complex workflow configuration with no focus.
    2. SoftAgile is built for transforming your waterfall teams to Agile! Jira provides multiple templates for different projects.
        • Transitioning your team from waterfall to Agile is a transformation of team. It is because while waterfall is a development methodology, agile at first and foremost an attitude!
        • The incremental, iterative and interactive nature of agile requires team to move on three levels. While a waterfall team works on requirements, an agile team on a story. Many agile teams see story as a group of requirements. SoftAgile provides this feature-story-requirements hierarchy to facilitate the transition. Similarly, acceptance testing can be series of test cases that can be traced to story requirements. SoftAgile therefore provides test cases, testing cycles and regression. Finally, agile teams thrive on customer feedbacks and works collaboratively with customer feedback. SoftAgile provides customer access directly into software and be part of the team through customer role with configurable access.
    3. SoftAgile provides an integrated tool for project teams, while to get some functionality Jira needs you buying lot many plugins.
        • SoftAgile not only provides Agile project capabilities but also agile teams, backlog with requirement management, test case management, regression, release and version management, along with issue and customer management, thereby providing an end-to-end experience along with. Jira will need Confluence and Zephyr plugins for backlog and testing management. Jira also has no customer or release management capabilities.
    4. SoftAgile allow you to plan for a release with multiple application versions for multiple customers. In Jira you will need to build multiple versions and manage them as separate release for otherwise common stories.
        • As an agile ALM Tool maker, our single Agile ALM project release contains multiple applications along with customer specific version, with some variation of stories. Thus,SoftAgile makes it simple and easy, while Jira creates additional work and hence complexity.
    5. SoftAgile provides an issue management module so issues are reviewed and then prioritized and automatically added to backlog as per review decision and priority. This ensures that backlog is uncluttered and prioritized.
        • Furthermore, SoftAgile provides a customer dashboard to get customer specific views. In Jira, issues go directly to project.
    6. Architecturally, SoftAgile provide automatic traceability for feature, story, requirements, test cases, dogs, defects and issues with customer and applications. In Jira, no out-of-box traceability is provided, but a plugin can be separately bought with additional tracking efforts.
    7.  SoftAgile is built for use at out-of-box! Jira needs installation and configuration by experts and training before team can start using it.
        • SoftAgile is installed on a server in less than few minutes and comes with out-of-box standard agile configuration and access by roles. You can, of course, further configure to customize the workflow.
        • SoftAgile Access is driven by roles can be changed easily in few seconds. More specific roles can be added.
        • SoftAgile provides on-page tour and help for getting your team train fast.
        • Jira Configuration and role access has grown long and complex.

      8. SoftAgile makes it easy, Jira has grown complex.

        • Jira, in its quest to be an enterprise tool, has grown complex. The easy flow of SoftAgile is compared to Jira below:
      • Agility is an attitude, a state of mind to move fast without losing quality but also without hierarchical burdens. SoftAgile builds on this at every instance to make things easy on team, so they can focus on crafting great software!

DashFlow™: One Click Agile

When we were developing SoftAgile and SoftALM®, we faced same challenge as other agile tool makers. Namely creating a tool that is easy to navigate around. As such this is number one complaint about present day agile tools.

Turns out, agile as a development methodology has pretty good depth and thus to add or view data, user have to go deeper in menu. This problem gets exasperated when you add other ALM modules such as product definition and quality management.

This understanding led us to realize that instead of giving a multi-level menu, why don’t we give a menu map that essentially provides the flow of application. Of course we made it clickable to allow a single click to go to those deeper views in the applications.

Single view of Agile

DashFlow™ is an integrated view of agile projects in SoftAgile and SoftALM®.

It is a combination of agile project dashboard integrated with SoftAgile workflow as shown below:

Dashboard and flow in SoftAgile

DashFlow™ serves many purposes:

  • Provides application map, making it easy to navigate around the application. Since this map is click enabled, one can jump to inner pages from project home page.
  • Provides a bird’s eye view of workflow for agile implementation.
  • Provides an instant dashboard with key analytics across the whole project, from backlog to versions.
  • Instant view of releases with iterations for each of agile teams.
  • Flexible use of Lean vs Enterprise version. Through on page menu of pop ups or full page items.

We think when you integrate project management with lifecycle attributes such as backlog management, test and bug management, along with tracing code, one can end up with a pretty large system. DashFlow™ clearly is an easy way to handle such complexity!!

Should Issues be part of your backlog?

Problems in a working software take different forms: defects, bugs, mistakes etc. And then there are issues reported by customers. Should customer issues be part of your project’s backlog? To answer that question, here’s a scenario:

Scenario: For your software X, version 1.0 has been released. Your team starts developing the meatier features of the next version, scheduled 3 months later. As the days pass, you start receiving emails from your customer users.

One email says a requested functionality has been implemented incorrectly and the user is not at all satisfied with the result. “Would you kindly redo the functionality as it is required for day-to-day functioning?” the user writes. Another says that a newly implemented feature needs to be explained to their team. Yet another has a handy suggestion for an existing feature.

Manage your Issues by listing them and then categorize/prioritize them before adding to Backlog

Now the catch: the term “Issue” was used for all the above three points by the customer users. But are they actually issues?

The first point (redo the functionality) is really a requirement change. The second point is a request for support. The third point is a suggestion.

Imagine adding these three points directly to your Project’s backlog, simply using the term “Issues”. Deciding what should be done with this sort of backlog, will not be easy. Which Issue should be resolved first and who should do it? In the meantime, if some more Issues are added, then your backlog will start to clutter up.

Project Manager faces different challenges while managing Issues for his/hers Backlog.


Using categories and priorities for Issues

Instead of using an umbrella term like “Issues” for customer feedback, what if Issues could be categorized in more Project-friendly terms and THEN added to the Backlog?

For example, point A is categorized as “New Requirement”. Point B is “Support request” and Point C is “Suggestion”. Priorities are also assigned. A affects the customer’s user day-to-day work and hence, is “Important”. B’s priority depends on the support team’s availability and C’s priority can be “Later”. However, if it is a good suggestion and adds value to X as a product on the whole, it should be categorized as a new requirement or feature.

Since prioritization and categorization is done, team members can effectively and easily make decisions as to which Issues should be added to the Backlog. Since A is “Important”, it can even be implemented on priority and deployed as a patch (making the customer user happy).

Backlog managers are happy, since the backlog is not simply cluttered and it is easy to make out what is actual backlog added for development and what are customer issues to be included as part of development.

Typical scenario of how Issue Management takes place between Support and a Project Manager's Backlog

How to convert Issues to Backlog

Deciding which Issues should be converted into Backlog items after categorization, can be performed by a single person or a group of individuals, depending on the internal workings of your organization.

If formal approvals are required before adding to a Project’s backlog, a review board should be set up to review the categorized Issues. For smaller teams, where it is possible that a Product owner manages both support and backlog, he/she can directly add to the backlog.

So, finally can the question “Should Issues be part of your backlog?” be answered?

The short answer: Yes after Issues are properly categorized and prioritized by the backlog and support team in tandem.