The Agile Executive

Making Agile Work

Archive for the ‘Enterprise Software’ Category

Enterprise Product: $50,000 and 8 months – You must be kidding!

with 7 comments

With the successful release of Enterprise Profile Management 1.0, I asked Nick Beaugeard – Founder and Managing Director of HubOne – to capture and share with us his Agile development experience. Some of the threads he describes might have been mentioned in other posts in this blog. Others, like “Invest in your method and tools before you hire people, not after you hire people!”, appear for the first time. Whether mentioned here before or not, the ‘secret sauce’ is Nick’s ability to pull so many threads together. The power of so doing is nicely expressed in Nick’s guest post below. 

Nick’s been involved in Tech for 27 years (if you include the games he wrote for the Apple II aged 9) and has been involved with companies like Microsoft, CSC, JP Morgan and many others. He’s also ran a number of start-ups, from web 2.0 to services to solutions companies and has been successful with a number of those. Nick has a passion for all things Agile, but prefers to design the methodology to suit the purpose, rather than rely on a one size fits all method. Notwithstanding this, Nick has some notoriety within Dimension Data for passionately changing solution development from failing waterfall to a test based development approach, suiting solutions and services.
 
Nick lives on Sydney’s northern beaches with his wife, four kids, two mice and a framed copy of the fabled W.W. Royce “waterfall” speech to the IEEE.

Here is Nick:

I’ve ran start-ups before. I’ve even managed the development of products before, but this is the first time I’ve set up a start-up with the sole goal of developing a product and bringing it to market. Thinking back on the last 8 months, I’m not sure I’d have taken the challenge on in retrospect, but we did, and we succeeded and so in this post, I’d like to share with you how a micro-startup with a budget of $50,000 can design, develop, release and certify an Enterprise quality product without going both broke or mad….

 

During my career, which spans everything from support, through solutions and has a great deal of focus on Systems Management, I’ve been constantly frustrated by something which should be really simple, how to find people with specific skills or responsibility. Seeing that the problem still existed, I set out to build a solution which would attempt to solve such a problem.

 
The first step on the road was to meet with potential customers. At this stage, I had barely a germ of an idea. It could be written in 20pt type on a single piece of paper. Nevertheless, I met with over 20 different potential customers and attempted to pitch the “solution” to them. The feedback I got was extensive, but the main and core piece of information was that the solution had value and merit and if we could deliver then these customers might just buy the software. I even went as far as to ask them how much they’d pay for such a solution and got a fairly consistent figure of about $20 per year per user.

 
I realised at once that the problem I was trying to solve was not a database problem. In fact it was a directory problem so I set about investigating whether I could produce a solution using an LDAP directory.

 
Right at the beginning, though, I made an investment in tools. I implemented great source control, issue management, task management and a build platform, just like I was in a huge team.

 
I also made sure I adhered to issue and task management and made sure that I was forced to complete the criteria for each check-in. I know that sounds stupid, and it must have seemed so… The CEO of a start-up assigning himself issues only to resolve them on check-in.  However I believed it to be easier to implement the processes I wanted before I had a team on board, demonstrate me using them and it would be WAY easier to get the team to use them!

 
To test if my architectural hypotheses was correct, I wrote a very, very basic API. This small piece of code was able to perform some CRUD (Create, Retrieve, Update and Delete) operations on my own custom directory objects.

 
Let’s read the above again… See I had no spec, some interesting comments from customers and just went ahead and wrote a prototype API. Next I wrote some Unit tests which exercised the API and went back to my customers to see if I was on the right track.

 
That bit was tough. It takes a fair amount of imagination to see a simple set of unit tests and then extrapolate that to a completed product. However my friendly customer s were very patient as I explained that a response of “Passed” actually meant what I just explained had happened.

 
Once again that feedback helped and I felt confident enough to prototype most of the API and almost completely complete the schema. Once again I created a bunch of unit tests, but this time I focussed on the core scenarios as discussed with our customers.

 
Still at this stage, we had spent almost nothing, had a good, working and testable prototype API and a schema which worked.

 
It was then time to go and get a couple of developers. I knew a couple of my close colleagues had just resigned from another company so I asked them if they’d come and work for me, at a vastly reduced rate, for some stock in my new start-up. 

 
Just the stage for a spec, huh? We’ve now got more than one developer so obviously need to write down then entire goal of the solution…

 
I thought not. My API was just a prototype and needed to be secured, consolidated, better documented, globalized and tested for performance and the unit tests demonstrated exactly how things should work. My new, fresh team set to work on tidying up and completing the API, working on issues and tasks and performing check ins. They also got told whenever they broke a build.

 
We were then seriously thinking about building a web services layer. This had several advantages, not the least being that we could support clients on multiple platforms. However, I was still a little uncomfortable with my API hypotheses and really wanted to build a client that exercised the entire API before we invested in SOAP and web services.

 
Therefore we set the challenge and therefore the scope of version 1. Version 1.0 would deliver a server (LDAP with an Installer) and a client (Windows XP and above) which talked to the LDAP server using our API.

 
That made the next challenge was the UI. This is a problem for me as I’m not one for having any design skills at all. However I could have sat down and tediously wire framed every screen and interaction I and my customers wanted.

 
However I knew a better wireframing tool – the IDE we used to write code instead. I sat down and started to craft a UI, using a lot of trial and error. In 7 days, I had a UI which exercised the main aspects of the API and the code base…

 
And that’s how our development stayed, I’d prototype (wireframe with code) a feature and the devs would then go and finish it.

 
We found bugs in the API, sure, but never needed to write new API methods to make the client work.

 
In the final weeks, we just worked on testing and fixing bugs… The test plan you ask? – Well that was the user guide! A full test pass meant running through each page in the user guide and doing everything it said.

 
A recent code review showed there was none of my prototype code left in the platform, but it didn’t matter. We shipped the product and spent less than the $50,000.

 
In conclusion our method was:
·         Speak to your customers. Not lots, all the time!
·         Invest in your method and tools before you hire people, not after you hire people!
·         Make the software function, before you spend time making a UI function.
·         Continuously test, fix and test again and don’t be afraid to throw prototypes away.

 
Last Friday we released version 1.0, go download it, you be the judge of how we did!

Advertisements

Written by israelgat

August 11, 2009 at 7:17 pm

Only 10%

leave a comment »

Readers of the posts Customer Intimacy and Enterprise Software Innovator’s Dilemma might recall two observations made in this blog:

  • The dissatisfactory state of affairs in enterprise software as characterized by Crawford and Mathews in their description of Consumer Underworld relationship between vendor and customer:

Ignore my needs… Be inconsistent, unclear, or  misleading in your pricing… Offer me poor quality merchandise and services that I can’t use… Give me a reason to tell my friends and relatives to stay away…

Open Source Software is becoming ”good enough”. It has already met or will soon be meeting the minimum requirements of the enterprise customer. By  so doing, Open Source Software will steadily gain ground from traditional enterprise software vendors

In a Viewpoint published in the July 2 issue of BusinessWeek,  former Harvard Business School professor Shoshana Zuboff cites the following statistics:

…  only 10% of Americans now saying they trust large corporations, according to the Apr. 8 edition of the Financial Trust Index. Some 77% of Americans say they refuse to buy products or services from a company they distrust, according to the 2009 Edelman Trust Barometer. [Highlights by IG].

The statistics given by Zuboff link the two observations cited above. One might argue that Crawford, Mathews and Zuboff deal primarily with consumer behavior, not with procurement of enterprise software. True that this argument might be, I sincerely doubt that the two worlds can be kept apart. At least some of  the folks who license and use enterprise software must be represented in the data given by Zuboff and are likely to act accordingly in their corporate roles. Moreover, her statistics seem to be quite consistent with the recent warning to high-tech issued by Christensen:

If you’re curious to know what lies in store for Seattle and Silicon Valley, spend a day walking around Detroit with the Ghost of Christmas Future.

Rusty Automobiles

with 3 comments

No, this post is not about today’s GM bankruptcy filing. Rather, it is about coming to terms with a phenomenon similar to rust – software decay.

An IT application development team I met with recently indicated they reached the point of allocating 80% of their resources to software maintenance.  Various colleagues of mine report similarly worrisome figures experienced in their practices. As a matter of fact, some of  my colleagues consider such figures endemic.

It might indeed be hard to visualize a rusted line of code. Decay, however, applies. To quote Capers Jones:

All known compound objects decay and become more complex with the passage of time unless effort is exerted to keep them repaired and updated. Software is no exception… Indeed, the economic value of lagging applications is questionable after about three to five years. The degradation of initial structure and the increasing difficulty of making updates without “bad fixes” tends towards negative returns on investment (ROI) within a few years.

Hazardous that software decay is operationally and economically, it is lethal once it becomes embedded as a revenue generator in the business design for enterprise software. In particular, high maintenance costs as part of planned obsolescence  invariably lead to the sorry state of affairs characterized as “Consumer Underworld” in The Myth of Excellence.

If you find this post a bit dramatic, please read Christensen’s recent post on the titanic efforts to turn things around launched by GM when it was already too late. Christensen concludes his post with a very pointed warning:

If you’re curious to know what lies in store for Seattle and Silicon Valley, spend a day walking around Detroit with the Ghost of Christmas Future.

Written by israelgat

June 1, 2009 at 1:24 pm

Are We at a Point of Saturation?

leave a comment »

In a post entitled Enterprise Software Sale as Corporate Pathology: The World’s Greatest Dog and Pony Show, colleague James Governor recommends the following practices for coping with aggressive enterprise software sales tactics:

In order to better fight their corner enterprises need to be smarter and more aggressive themselves. They should:

1. Pay more attention to the people that actually do the work. Don’t buy software that your developers have no intention of using. Make sure architects are listening to developers.

2. Consider offload options:

  • application server – if you’re running a Java workload does it really require the quality of service that a WebLogic offers? If not why not look at Glassfish, say, or Apache Tomcat.
  • database- not all data are equal. That being the case put data in the most appropriate place. If it just needs to be thrown in a bucket of bits then consider MySQL or a file system rather than your “enterprise standard relational database”
  • cloud- its other [over? IG] there. take advantage of it, especially for non transactional workloads.

Use open source and cloud as personal trainers for proprietary software. Use alternatives to snap back if the salespeople try and bullshit you.

Examining the issue James brings up from an industry perspective, the question of possible saturation jumps to mind. At this point in time, do enterprise software vendors develop more software than the demand profile warrants? Such a situation, for example, manifested itself in telecommunications during the late 1990’s and early 2000’s when only 1-2% of fibre cable capacity in the US and EMEA has been turned on. The resultant losses have been catastrophic.

 If we are indeed at a saturation point for enterprise software, a strategy question and a policy questions present themselves:

  1. For enterprise software vendors: What is the strategic course to turn around technological maturation and market saturation?  Is “pedal to the metal” strategy still appropriate for enterprise software vendors?
  2. For policy makers: Is enterprise software an industry whose growth should be stimulated? Or, would another sector of software prove superior as a target for stimulation? For example, embedded software has the potential to be used in more and more products. Moreover, it has the potential to become larger component of the products in which it is embedded.

The two questions are related. Investment choices made by enterprise software vendors will determine how dynamic the industry becomes. A possible public policy decision to stimulate growth in enterprise software makes sense only if  the industry demonstrates strong generative potential: it should be able to create new businesses around enterprise software; and,  it must trigger growth in the various industries where enterprise software is used. Absent such effects, why stimulate growth in enterprise software?

As pointed out by Perez, the public policy decision needs to take income distribution into account:

If you want to sell basic foods, your potential market grows with number of low-income families; if you sell luxury cars… you look to the upper end of the spectrum. So the rhythm of potential growth is modulated by the qualitative dynamics of effective demand. Therefore, even if the quantity of money out there equals the value of production, if it is not in the right hands, it will not guarantee that markets will clear.

It was pointed out in Enterprise Software Innovator’s Dilemma that “good enough” Open Source Software is inevitably becoming good enough. If you accept this premise, an attractive policy decision could be to allocate public funds to making Open Source Software enterprise ready. Once it is (enterprise ready), the stimulative effect of low cost enterprise software could be huge. For example, it might enable SMBs to offer services that currently can only be afforded (and provided) by Fortune 500 companies.

Companies make shoes!

with 2 comments

Peter Drucker made an astute observation which is quite relevant to the current business situation during a September 1998 interview with Fortune:

Securities analysts believe that companies make money. Companies make shoes!

Readers of this blog might have said “software” instead of “shoes.” The point would have been similar to Drucker’s. Good financial management is no doubt  important for your company’s success. It is no substitute, however, to focusing on the business you are in, the technology(ies) that drives the business and the effectiveness of the underlying systems and processes.

The current macro-economic situation gives you an opportunity to soberly assess the viability of your business design (as distinct from doing a lot of financial engineering). With asset inflation corrected, measuring the effectiveness of your business model in terms of the ratio Market Value/Revenues is much more meaningful now then it used to be prior to September 2008. As pointed out by Slywotzky in Value Migration, a market value to revenues ratio lower than 0.8  indicates value outflow for your company and possibly for your industry.

For software companies, the impact of “good enough” Open Source Software should be assessed in conjunction with close examination of the market value to revenues ratio. Twitting from the recent OSBC conference in San Francisco, colleague Andrew Dailey of MGI Research reported “… ERP/CRM are viewed as least susceptible to open source disruption… due to high transaction volumes and high integration needs.” Conversely, Andrew considers office productivity software as ripe [for the picking by Open Source Software]. I am personally of the opinion numerous Application Life-cycle Management tools could be massacred by Open Source Software.

The confluence of the threads highlighted above poses a fairly unique opportunity for the Agilist to convey a major premise of Agile to his/her executives. Like a thriving Open Source Software community, a hyper-productive Agile team can pick a ripe market faster and cheaper than an old fashioned software company could. Moreover, if a company is in one of the markets that are susceptible to an Open Source Software onslaught, Agile can (up to a point) provide defense against such onslaught. Whether you choose to attack or defend, Agile software gives you the advantages of proprietary software at a fraction of the traditional cost.

Energy from New York

with 5 comments

In her recent post on the Rally event in Los AngelesJean characterized the energy in the room as “electric!” Yesterday’s event in New York was characterized by similar energy. There was something in the air – folks having a great time learning about and discussing the subtle points of the art of making great software.

 

Governance was a major topic for the participants in NYC. Those representing financial institutes highlighted the inevitable delay and disruption to the process that change control boards cause. Media folks indicated how difficult it is to reconcile the editorial process with the technical process. A disconnect seems to be happening in both cases: Agile is not broadly accepted beyond certain scale, nor by all corporate functions. Hence, various attempts to “harness” Agile, to only use it selectively.

 

 

Governance seems to be applied more pedantically these days due to cost cutting measures. In particular, experimentation is frowned at in many place. The simple fact that Agile fosters innovation through affordable experimentation is not fully understood. Nor are the precious life-cycle effects of innovation adequately comprehended.

 

 

I came out of the NYC event convinced that we as a movement have a great opportunity on our hands. What we -Agilists – do works quite well. The need clearly exists to elevate Agile to the enterprise level. We will be solving a real problem in so doing.

 

 

 

Written by israelgat

April 3, 2009 at 8:52 am

Pains from Los Angeles

with 14 comments

Click here, here and here for stroke-by-stroke coverage of the March 26 Rally event in Los Angeles by Zach. From my own interactions with participants during the event, I compiled the following  list of the most painful issues between an Agilist and his/her executive(s):

  1. The “sausage syndrome”: “Don’t bother me with details how you do the software – just get it done” seems to be the attitude of numerous “business executives.”  I must admit I still don’t get it. Software is becoming pervasive on an unprecedented scale. And, software is becoming bigger and bigger component of just about any product in which it is embedded. Ditto for software as part of the business process. What is your recipe for success if you (as an executive) don’t get down and dirty on such a major component of your business?!
  2. Agile as part of the overall software engineering fabric: This issue is a close cousin of the “sausage syndrome”. Expectations of Agile are unrealistic as it is not grasped holistically as one layer in the overall context of  the art of programming. We direly need a construct like the OSI Reference Model for software engineering.
  3. Agile and the real customer: Much of the emphasis is still on Agile in R&D. The real customer is not iteratively integrated  in the development process. In spite of a ton of data to the contrary, we often drive the iterative development process under the fallacy that the customer problem is well understood.
  4. Agile in the business context: Discussion are usually focused on $$. Most Agilists do not seem to be well equipped to discuss Agile in the contexts of  risk mitigation and compliance.
  5. Assimilating Agile: Little understanding that apprenticeship is a wonderful way to learn Agile. Precious few invest sufficiently in on-going Agile consulting and coaching.

I started the event stating that I feel like one foot in cold water, the other in hot water: we accomplished so much over the past few years, yet much more could and should still be accomplished. I finished the event with precisely the same feeling: a ton of enthusiasm for Agile in the trenches; the immense opportunity to harness this enthusiasm at the enterprise level is not quite happening yet.