Exploring new software development tool sets: Interview with John Simpson of Jama Software

John Simpson is director of customer outreach and marketing at Jama Software.  John is a contributor for Business Analyst Times. At Jama, he represents the voice of the customer in their product strategy and communications.  He has over 14 years experience working at software technology companies including Microsoft, WebTrends and Omniture. In his spare time, he chases his three kids around Portland, OR and raises awareness for cancer research in his local community. You can reach John at jsimpson@jamasoftware.com or follow him on Twitter.

Today, John passionately shares his views on the traditional tools used by software development teams and how a new breed of web-based, interactive tools can help us work better.

Challenges posted by traditional software development tools

Question: What problems are companies facing with the traditional software development tools?

Answer: First, let’s define what these tools are.   This category is notorious for acronyms and jargon – ALM, PLM, SCM, RM,  if you were new to this space, your head might spin.  So, let’s offer a bit of demystification to keep things simple:

• ALM – application lifecycle management – tools to manage software development projects
• PLM – product lifecycle management – tools to manage physical product development projects
• SCM – software configuration management – tools to manage source code and changes between product versions
• RM – requirements management – tools to manage the scope of what customers want and what the team is committed to build

Acronyms aside, these tools are designed to help product development teams plan and build the right products.  In addition to standalone software, over 66% of all new products (cars, airplanes, cell phones, consumer goods etc.) now have software within them, so the lines are blurring between ALM, PLM, SCM, RM and even testing tools for managing test cases and defects.  Regardless of what we label things, the fact is tools are enablers and they either help you or they don’t.  They’re not a replacement for skilled people and a workable process – tools that work enable efficiency, quality, speed, consistency and automation.

In terms of problems, I love the irony that this category of software is supposed to help teams build great software that customers enjoy using – YET the traditional applications are infamously cumbersome, bloated with gold-plated features and are difficult to use.  Oops!   That’s like telling your kids sugar is bad for you and then stuffing your face with 2-lbs of candy on Halloween.

The core issue with the traditional tools is that they were designed 20-30 years ago as hard-core desktop tools.  Powerful, yes.  Easy, heck no.  The world has gotten much more collaborative since the Nixon administration and the era of Disco.  Teams are distributed all over the world.  Customers and stakeholders are much more involved.  Processes are more fluid and constantly being tweaked.  Development cycles have accelerated.  And at the same time, the scope of the complexity of the products people are building doubles every 2-3 years.  So, the sum of all these characteristics has created the need for more collaborative, open, Web-based toolsets.  And, if a software application isn’t easy to learn and use within a few weeks, it doesn’t work in the eyes of many organizations.  The days of 6-9 month deployment cycles to adopt an enterprise tool are gone.

Question: If I’m an individual in one of these organizations with a traditional ALM toolsets, what challenges am I likely to face?

Answer: 1. Pain.  2. Steep learning curve.  3.  Info silo’s  4.  Process rigidity.  5.  A suite trying to do it all, but really only good at 1-2 aspects.  The biggest thing, is that you’ll have to change the way you work to work with traditional tools.  It’s all backwards, the tools should flex to fit how your team naturally works.   The major shift we’ve seen in this category and across all software for that matter, is that modern tools are more user-centric and they conversely offer:

1. Immediate ROI
2. Fast adoption
3. Collaborative environment
4. Process flexibility
5. Specialized tools that are open and integrate easily with other best-of-breed tools.

The trend is to provide seamless integrations to allow people and different roles to work in the tool of their choice.   The data shows that’s what companies want.   It’s our job as vendors to provide it to them.  Not to be salesy, but to just provide any example to illustrate this point.  Jama Contour is a popular Web-based tool focused on requirements management.  Atlassian JIRA is a popular Web-based tool focused on defect tracking.   They play nice together, bridging the gap the often exists between Business Analysts and Developers:  http://www.jamasoftware.com/contour/jira-connector.php

Signs you need a new development tool set

Question: If I’m a manager, what are some of the warning signs that I need to look at a new tool sets to help solve software development issues? Why can’t I just fix the process and use the tools I’ve already invested in?

Answer: The easiest sign is to look at yourself. What’s your interaction with the tool as a manager?   A good tool should be a tool managers want to interact with.  For greater visibility, for reviews, for approvals, for feedback, and for tighter management of projects.  So much time is wasted in status meetings and formal review cycles with management that can be eliminated by breaking down the silos and bringing everyone into the tool.  You shouldn’t have to wait for a weekly call or status meeting to know if a key new feature is taking longer to build, a release date is at risk or if scope has changed.

A good tool gives managers real-time status updates anytime, anywhere and brings them into the conversation throughout the process.   This is probably the #1 area of efficiency an organization can achieve immediately – simply by bringing together all the relevant information into a central hub, organizing it, connecting it all together, making it easily searchable.  We wrote a whitepaper on this recently that provides some significant stats on the productivity issues that stifle innovation:

Question: It sounds like we’re in a situation where maybe the traditional tools have over-engineered the process or offer too many requirements. If I’m a business analyst facing a transition from a traditional tool to a more agile toolset, what kinds of features should I expect to lose?

Answer:  You’re absolutely right.  The traditional tools were designed for classic waterfall process with gate by gate by gate.  The needs have changed, and the processes have changed in many cases.  I hesitate to use the word “agile” because it’s so overused and a trendy buzzword.  We describe the newer processes as being “fluid” meaning they eliminate gates and allow constant flow of information, embracing change as a natural part of process.  Call it agile or iterative or scrum or XP, the labels don’t matter as much as the fact that your team has a process that’s followed consistently, works for everyone and gets the job done.

In terms of the tools, there used to be major trade-offs in functionality for simplicity between traditional desktop tools and Web-based apps, but really not anymore.  In the last 2-3 years, the advancement in Web technology has been exponential, and one can honestly argue now that the modern Web apps for ALM, PLM, SCM, RM are equally as powerful as their  traditional predecessors.   Minus the IT burden, and plus the natural collaborative benefits of the Web.  We’re reaching an inflection point, where people can have their cake and eat it too with the newer Web-based tools.

ROI on development tool sets

Question: As an IT manager or executive, how do I measure the return on investment for a light-weight development tool set?

Answer:   Over the years, I’ve probably seen 50+ different ROI models, some decent ones, some crazy ones with hundreds of variables that were a disaster.  My advice is take the ROI spreadsheets and throw them all away.  Seriously, burn them.  No one believes them anyway. Of course, do it if you need to satisfy your CFO’s need to have a financial validation of the investments you make.  I’m not devaluing metrics.  By all means measure the results of everything you do and the investments you make.  That’s important.  My point is if you truly want to gauge return on any tool, cruise the office floor at the end of a work day and ask your staff 3 simple questions 30-days after you’ve implemented it.

1. Did you use the tool today?
2. Is the tool making your life easier or harder?
3. If we took the tool away tomorrow, would you want to hurt me?

Ask those 3 questions and you’ll have your answer.  If people like a tool and use a tool, you’ll gain productivity, speed, quality – all things you could quantify in dollars if needed.  If people don’t like tool, they won’t use it and it’s a waste of money.  It’s that binary.  It doesn’t require a complicated ROI model.  My belief is any tool worth its weight pays for itself in 6 months or less.  The great ones in less than 90 days and people would be emotionally upset if they didn’t have it, because they love using it.  See the recent article on the “hierarchy of belovedness” to gauge where your apps rank.

Thanks for the opportunity to share my perspective.  Good luck building great products.  I love learning about what others are doing, so please don’t hesitate to contact me with your feedback.

Related posts:

1. Supporting business analysts through competency development: Interview with Dave Schrenk, CBAP
2. What part does the IIBA play in your professional development?: Interview with Kym Byron, CBAP
3. Starting a Requirements Engineering Community of Practice: Interview with Anthony Oden, Business Systems Analyst at Dell