Does Agile work when developing commercial enterprise software?

September 11, 2010

I recently had the opportunity to attend an excellent presentation on Agile / Scrum at the Nashua Scrum Club by Damon Poole, Founder and CTO of AccuRev and Vice President of the Boston-area Agile Bazaar.  The presentation was focused on how true agility requires product development professionals to examine our beliefs.  It was a very interesting, entertaining, and thought-provoking presentation and he is a very engaging speaker.  Highly recommended.

However, as I considered some of the key ideas being discussed — such as rapidly deploying product updates to customers and incorporating near immediate feedback from customers into the planning process for the next sprint — I could not help but wonder how effective these concepts would be when developing commercial enterprise software.

Most of the commercial enterprise software I have been involved with suffer from one key problem — it requires a significant amount of customization before the customer is comfortable deploying it across their organization.

As a result, a typical deployment requires each company to (a) install each new software release in a test environment, (b) apply their customizations, (c) test their customized installation to ensure it does what they need, and (d) deploy the new release in production.   In some cases, this process can take as much as 6-12 months.

As a result, companies in this type of situation cannot provide much rapid feedback on the new release — because the “real users” of the system won’t even see each new release for quite a while.   They also can’t rapidly deploy new releases because the out-of-the-box version doesn’t satisfy their business needs.

Commercial enterprise software is one of the most important (and expensive) type of software for many companies.  And Agile offers too many benefits when developing software  to be ignored by enterprise software providers.

So, how can we (as software development professionals) effectively utilize Agile during the development of enterprise software?

Care to share your ideas, experiences, and/or opinions?


Do we finally have the ability to have true “international” products?

May 24, 2010

Did you see the recent article about Google making its real-time translation tool available for the Android phone?  If not, you can read it here.

While this implementation will undoubtedly be fun for a number of cell phone users, imagine the impact if a number of enterprise software companies incorporate this technology into their products.

We have long talked about “localized” software products that are available in a number of single languages.  In other words, users in France interact with the software in their native language — French.   We also talk about “internationalized” software products that display numbers and other elements using the format that is appropriate for each user — which is important when users from different locales are sharing the same application.

However, we have not yet seen applications where free-form text entered by one user in one language can be read and understood by another user in a different language.  Google’s tool offers the promise of this capability.

Granted, any “automatic translation” tool will have problems in accurately conveying the content, context, and subtleties of a language.  And I suspect this problem will be especially difficult when translating between languages that have different origins (for example, English and Japanese).   However, as more applications incorporate this type of technology, more investment (and resulting technology improvements) will follow.

Consider the following situations where this technology would literally “change the rules”:

  • PDM, PLM, ERP Systems — Product descriptions, instructions to suppliers, questions on design intent from part manufacturers, etc.  In today’s global environment where a supply chain may include companies in multiple locales, the ability for each member of your supply chain to communicate in their language could significantly improve your ability to design and produce quality parts.  It also makes it easier for you to find additional suppliers because they no longer have to communicate in your language.
  • Twitter, Blogs, and Other Social Media Tools — You could interact with customers and potential customers in their language.  This would allow you to review a product idea with potential customers in a wide variety of locales and thus avoid problems like giving your new product a name that means “toilet” in another language.  And wouldn’t you like to know whether a product is interesting to a particular locale before you pay to translate the product’s screens, documentation, marketing, and sales materials into that language?  I know I would.
  • CRM and Other Customer Feedback Tools — As with the social media tools, imagine how much your customer service might improve if you could actually exchange information with your current customers in their language.  Today, companies rely on small teams of customer support specialists with multiple language skills.  However, this approach can introduce another layer of “interpretation” between the customer who is describing the problem and the Development engineer who has to fix it — which increases the difficulty (and cost) of providing timely bug fixes.  How much could you improve your service and reduce your costs if reliable and accurate real-time language conversion was available?

There are many other categories of commercial (and even military) applications that could benefit from this technology.  What is your favorite?  Or perhaps this problem is too complicated to be solved by any technology, even one from the guru’s at Google.   What do you think?


Is a Product Manager responsible for preventing corporate identity theft?

May 19, 2010

As product managers, we are responsible for identifying and prioritizing the features for our products.  Then we spend time with Development to create new capabilities and with Marketing, Sales, and customers extolling the benefits that these capabilities will provide.

One of our key assumptions is that each new capability is valuable to some (and hopefully, all) of our customers and potential customers.

However, in today’s litigious environment, shouldn’t product managers also be concerned with protecting their own company?

In an enterprise software application, a wide variety of users perform various functions, including many that could expose their company to risks.  For example, new product designs are reviewed and approved in Product Lifecycle Management or PLM systems,  raw materials are acquired in ERP systems, and confidential legal matters are managed and reviewed in document management systems.

Each of these systems have one thing in common — it is possible for an “authorized user” to perform an action that could put their company in a compromising situation.  And if someone has stolen this user’s identity and a terrible situation results — do you think that they will attempt to hold the enterprise software vendor responsible?

Of course they will.

If today’s legal system allows the manufacturer to be held liable when someone falls off the top of one of their step ladders, it will be easy to hold the enterprise software company responsible when the strategy of a defense team in a high-profile legal matter is downloaded and released to the public by someone who guessed the lead counsel’s password.

And what about a situation where a new part in an automobile is approved by a well-meaning administrative assistant who misunderstood which part their boss said to approve.  When this approved part is later discovered to be faulty and results in the deaths of a number of people, don’t you think that the company will complain that it was “too easy” for the assistant to pretend to be her boss and that the software should have done a better job of detecting and preventing this action?   Unfortunately, the answer is probably “yes”.

Thus, I believe Product Management needs to expand the criteria that we use to evaluate potential product capabilities, as follows:

  1. Riskiness — Capabilities that the product absolutely must have to protect the viability of “our” company.
  2. Must Have — Capabilities that the product must have in order to be effective in the market place.
  3. Should Have — Capabilities that the product should have, but are not required.
  4. Nice to Have — Capabilities that we would like to have, but are not required.

This approach will result in more time being spent resolving “Risk” issues and less time on user-visible features that could generate revenue — which could also threaten the continued existence of the software company.  Oh joy!!   Yet another trade-off for Product Management to balance.

So, what do you think?  Does this topic ever come up in your product planning?  Or does your company depend on the fine print of your license agreements to protect itself?


Do you remember CALS?

April 21, 2010

I was talking to someone the other day about standards for exchanging electronic product data, and then I realized I had forgotten something important that was also very personal to me.

Perhaps you can help refresh my memory and identify the DoD program that came after CALS.

Years ago, there were no real standards for exchanging electronic design data.  CAD/CAM was still in its infancy and software packages like AD-2000 were just being demonstrated.  As time went on, a number of CAD vendors arose — each with their own unique file format.  But in most companies, the paper drawing was still considered the “official design record”.

The US government became increasingly concerned with exchanging design data because they often wound up paying their suppliers multiple times for the same information, which increased their costs.  As an example, if a new submarine hull was built by Newport News Shipbuilding (in Virginia), the major refit for that hull was often done in a year or two by Electric Boat (in Connecticut).   And since each company needed proper documentation to perform their work and the previous documentation belonged to the other company, they would reproduce the design artifacts themselves — and charge the government accordingly.

Into this situation came the NASA IPAD (Integrated Programs for Aerospace-vehicle Design) Program Office.  The IPAD Program was partially funded by the US Navy and included over 100 key leaders from computer suppliers, software providers, aerospace companies, government and military agencies, educational institutions, and consulting firms.   The goal was establish standards for exchanging electronic design data among the various suppliers that NASA planned to use in the creation of its next generation space vehicles.   Standards of this type would then allow NASA to drive downs its costs, by eliminating the need to duplicate design artifacts.   The IPAD Program also leveraged a significant amount of work that was being done during the same time-frame by the US Air Force ICAM (Integrated Computer-Aided Manufacturing) program.  A summary of the IPAD program can be found here, although it was published well after the program was underway.  (For those interested in more information about IPAD, I suggest the NASA Technical Reports Server at this link.)

Eventually, as with most government programs, the scope of the IPAD “solution” (or perhaps “problem”) was extended to other government agencies, who hoped to leverage these ideas and reduce their costs.

The follow-on program was initially known as CALS (Computer-aided Acquisition and Logistics Support), but was renamed over time to “Continuous Acquisition and Life-cycle Support”   (See Wikipedia for a short article or this NASA reference.)   Many of the same people from IPAD were active in the CALS program, which was eventually expanded to cover all of the US Department of Defense (DoD).

Many of today’s standards for exchanging digital design data, such as IGES, STEP and countless ISO standards, owe much of their history to the IPAD and CALS efforts.  In addition, the entire PDM (product data management) and PLM (product lifecycle management) industry owes much of its existence to the IPAD program and their efforts to create the “Relational Information Manager” (or RIM), and the IPAD Information Processor (IPIP) for managing and sharing digital design artifacts.

I was very fortunate in that Robert Fulton (R.E. Fulton), one of the key visionaries behind this program and the NASA Program Manager, was also my father.  So I literally learned about “engineering data management” at the dinner table.

Which brings us to my question…   The CALS program eventually evolved into another DoD program which specified that the US government “owned” the digital data for the products they had paid to have designed and that all data had to be submitted in specific digital formats before the supplier would be paid.

My question is — What was this program that came after CALS called?


Wistia video sharing and PLM or ERP systems?

March 24, 2010

Just saw the notice that Wistia got their 2nd round of angel funding.  Congratulations.

Wistia Gets Additional Funding (from Mass High Tech)

Their value proposition is centered around allowing companies to distribute video and track how it is used.  Makes sense for promotional materials.

But could it be used in PLM or ERP systems?

For example, you produce a training video that illustrates the correct way to install an ECO which is then distributed to all of your service reps.  How much more confident would you be in the performance of your service technicians if you knew which ones had (and had not) viewed the video?

Likewise, getting proposed engineering changes reviewed by appropriate people has always been a challenge.  Various companies have tried before-and-after drawings, drawings with annotations (or notes),  pictures of the proposed changes, etc.  But there is no way to know whether each reviewer actually looked at all of this information BEFORE they approved the change.   Perhaps Wistia’s technology could be adapted to track these events and incorporate that logic into the PLM system’s review capabilities…

What do you think?


%d bloggers like this: