The visionary

I think it is an asset to Coop Centrale to have a visionary CEO like Massimo with a great understanding on how practical application of technology to achieve his vision. He has a close pulse on the market behavior, good understanding on changing customer requirements, “Traditional customer categories are now blurring across hypermarkets, discount stores, and superstores. We see the same customers shopping across all our store formats – something that did not happen in the past.” While at the same time, he has a good grasp on technology to formulate innovative business models that will catch up with these market changes to remain competitive, “We also need a business model that allows us to show customers new prices and products very frequently, on a weekly or even a daily basis. Electronic labeling enables us to customize the information we provide to customers – improving the display and accessibility of products.”

It’s not the technology. It’s the people!

As I always said to my clients that the key of effective technology application is not the technology itself, but the people and process behind it. The people and process are what your business is made up. You should find technologies that support them instead of tweaking your process to suit the technologies. As Massimo nicely put it, “The challenge isn’t really the technology itself but its application to business. Can people across the organization – and particularly our customers – use the technology? So the key is transforming technology into a business enabler.” Based on my experience, tweaking your business process to suit a particular technology will allow result in more redundant process (or shadow process), creating more overhead and inefficiencies.

Bringing vision to life

I was in Europe several months ago for holiday. I was impressed by their innovation of self-scanning checkout counter. Not so much about the technology itself (I don’t think there is anything high tech here), but it is the way they innovate the process to reduce the manpower required, but most important of all, it cut down the waiting time of customers to checkout their items. To me, that is really putting technology into practical use. I can imagine that the implementation was pretty straightforward, but the ongoing observations and feedbacks are the key to success here, “We continually asked these questions and adjusted the technology and training for our employees, as well as the messaging to our customers. Eight years ago, only 1 customer out of 100 was scanning her own purchases. Nowadays, around 50 percent of our customers use self-scanning. It was a really gradual process to get there.” Massimo understood there is always resistance to change, but he advised that we should constantly looking for ways to bring the vision to life in tangible ways via piloting and prototyping.

Nevertheless, I think their achievement on this is merely tip of the iceberg. Although improving the customer experience seems to be the obvious goal, but I believe this is just a stepping stone to their greater goals. Massimo said, “Consumers are much less loyal to retailers and more selective about what they want. So technology will play a role in how we attract customers and maintain their loyalty.” Identifying customers while they checkout their items will allow the company to track their customers buying patterns, and actively engage them to provide compelling experiences and relevant offers that will give new reasons for coming to the stores.

Work with people outside your industry

I like his advice that he shared to encourage more visionary and innovative leaders, “I encourage managers to travel and observe what others are doing, looking at our own industry and especially at other industries, both in Italy and in other countries. We study restaurants, bookstores, and electronics stores – all places where consumers look not just for products but also for entertainment and emotional engagement.” That’s one of the reasons why I think putting my money in traveling is well invested. What I always said is don’t just look for people who are in your industry to work with you. Yes, they may understand better your industry and how your business work, but they may just think like everybody else in your industry. A lot of new ideas are inspired by existing innovations that is replicated or adapted from other industries.

Entrepreneurship is a journey. No, it doesn’t begin with the first step. It actually begins with a decision in your mind to undertake this life’s journey, your journey, whatever it may 
take and even how long it may take.

Entrepreneurship is fun and exciting. I like what Bill Rancic said during the Season 1 of Donald Trump’s The Apprentice,

The cover-your-butt mentality of the workplace will get you only so far. The follow-your-gut mentality of the entrepreneur has the potential to take you anywhere you want to go or run you right out of business – but it’s a whole lot more fun, don’t you think?”

Yes, I very much think so after all these years! More significantly, entrepreneurs are part of the major force of driving the country’s growth and economy, as what Andrew mentioned during the interview. I hope this interview video will give aspiring entrepreneurs out there the true picture of entrepreneurship so that they can decide wisely.

Coming Up Next

Investors such as business angels and VCs usually work with many entrepreneurs. They very likely have their fair share of experience in seeing successful and failed startups, as well as understand the key ingredients in starting successful business. Follow us on our Facebook Fans Page as we share the entrepreneurship lessons from an investor perspective in in our next issue.

Coming Up Next

Find out how Coconect come out with the idea. Learn more about the challenges and obstacles as they are trying to innovate the process? Follow us on our Facebook Fans Page as we discover the scenes behind Coconect in our next issue.

The link for downloading source code of the demo application is provided at the end of the presentation. Thie plug-in framework is a concept that was created in 2003 when I was developing an extensible IP telephony system. You can read more about the project here to see how this concept can be applied in real-world application.

Click here to download the source code for XShow.

More often when people look for software solutions, their first thought is of a technology vendor or software developer, which can be expensive and does not guarantee the best solution. Every business is unique even if they are in the same industry. What works for others might not work for you. Moreover, you want to use technology as a key differentiator or competitive advantage. Do not make the common mistake of focusing on the wrong things. You need to be objective and know how to ask the right questions. Here is a list of some of the responses I have heard to the question, “How did you go about choosing your software solution?”

• “The vendor sales consultant offered us free consultation on planning technology implementation.”
• “Because everybody in our industry was using it.”
• “Our end users liked the user interface.”
• “They told us their software solution can solve everything that we required.”
• “They pretty much convinced us that customized software solutions were the best choice.”
• “They have a large team of programmers and software engineers.”
• “They used a lot of technical jargons and buzzwords. Though I am not clear with them personally, but they seemed to know their stuffs well.”

These reasons can range from possibly acceptable to risky and dangerous. The key to successful technology implementation lies on proper planning. This includes thorough understanding of your short and long term business goals, need, pain and problem, followed by objective evaluation of technology and its functionality that suit your business needs.

Questions To Ask Your Software Consultant

Question #1: How long have you been providing these services?

A consultant that is new to the business may not have the needed experience to assist you. This might increase your risks of a failed implementation. If in doubt, always get a second opinion from another consultant.

Question #2: Who are your previous clients?

It is important to check references and the date of reference. The consultant must have good reputation. Frequent invitation to speak at local conference is a good indicator for this. Old reference dates may indicate that the consultant might not able to provide you with advice that is the most current and up to date.

Question #3: What did your clients like best about your services?

This will give you a very good perspective on the approach and methodology of the consultant. It is very important that they have balanced understanding of business and technology. Successful software implementation is less about technology and more about business. Beware of consultant who doesn’t listen and then come out with a quote or proposal that doesn’t resemble at all what you discussed. They should spend more time understanding your business, vision, process, and problem, instead of just selling and promoting their product features and technologies.

Question #4: Do you resell products, such as hardware and software?

A consultant that only deals with one or two vendors may try to fit your business problem into their solution rather than finding the right solution for your business need. The ideal consultant should be independent and have no ties to any vendor, and able to shop for your choice of products and services.

Question #5: How big is your programming team? What technologies or programming languages do they specialize in?

This will reveal that if the consultant is really a true consultant or a customized software house. The latter usually have a sizable programming team, which incurs high overhead costs where they will typically try to recoup from their fee. Ideally, a consultant should not have a fulltime programming team. This is to ensure maximum flexibility and cost effectiveness, as well as prevent giving opinions that are biased towards their team capabilities. A good consultant will assemble the team with the necessary expertise only after understanding your requirements.

Question #6: Do you personally have any experience in programming?

To minimize implementation risk, the consultant himself must have solid experience in programming to the extent where he can roll up his sleeves and get his hands dirty to support the team when necessary. Be cautious with consultants who come from business background and claim that technical skills are not required or relevant until the later stage. The ideal consultant should have strong technical background with good business sense.

Question #7: What is your free structure?

Be extra careful with consultants who do not do planning or do it at no fee. They will probably provide solution that will not work, or just a narrow view of choices, or have hidden fees to recoup those costs later, probably during implementation. Also, make sure that they don’t ask for all the money up front, advance payment of 40 to 60 percent is considered fair.

Question #8: How do you guarantee your services? What type of warranty do you provide?

Most consultants will promise client satisfaction, but how do they guarantee it. Timely delivery is one of the greatest challenges when it comes to software implementation. So make sure your consultant provides some sort of service contract that ensures they can provide on-time implementation.

Introduction

There is nothing more gratifying than the recent decades for those individuals who are in the engineering and technology profession. Since the early 1980s, there is a massive growth of high-tech businesses. These new businesses operate very differently than their traditional peers, such as trading, logistics, manufacturing, banking, and the like. Their business model has very strong focus on its people and knowledge to create values by providing radical solution to problems in ways that the market does not expect. More interestingly, these businesses are founded by engineers or techies who are trained in their profession to have strong analytical and problem solving skills. To mention a few examples: Bill Gates founded Microsoft in 1975 to develop programming languages for various computer systems. He was a computing science student at Harvard College at that time. Leonard Bosack was a computer engineer before he started Cisco Systems in 1984 to create a multi-protocol router that is instrumental in making Internet possible. Acer was created by Stan Shih who was an electronics engineer in 1976. It started off as a distributor of electronic components and microprocessor technologies, and emerged as a PC manufacturer over time. Mark Chang is the founder of JobStreet.com, a company that was formed in 1997 to provide recruitment services over the Internet. He used to be a mechanical engineer prior to that.

A common characteristic among the founders of these companies is, apart from their strong technical background, they do not have extensive exposure to the business world before starting up their business. Although they are proficient in their technical skills and knowledge, as I tried reflecting back on my past experience in various technical domains, and observing technical individuals around me, there are certain personalities or traits within us that are trained over the years as good engineers, which are not really suitable for business start-ups, and to certain extent might even put our business at risk. This article is to share with you my experience over the years, started off as a software developer, and gradually gained my business sense as I ventured into various businesses. The article may contain statements that are blunt and harsh as the objective is to ensure the intended message is presented in a more straightforward manner to prevent any misinterpretation. While you may find the article seems to be prejudice and stereotype in certain sense, I had done a great length of research on the subject to generalize all facts and cases presented here. In order to get the most benefits out of this article, it is advisable to read and understand with an open mind.

Trait #1 – Talking too much technical

“Our product has this intelligent energy analysis module, where it basically uses regression analysis on built-in data cube that allows you to simulate and predict your future energy usage pattern.”

Does that sound familiar to you? If you are like many techies, we tend to be mistaken of selling our product by promoting its features and technology. Unless your audience is technically inclined, otherwise most customers usually do not care much about the internal working (technology), not to mention they might not even able to comprehend it very well. You should instead tell your customer more on how your products can help them, what problem does it solves, how to use it, etc. It is better to avoid talking about your product features before your customer has bought into its benefits. In order to build your rapport quickly, you can share your experience and insights about your customer’s industry, try to relate to your opinion on the problems, needs, and dynamics in the industry. That can greatly increase your credibility in customer’s eyes to make your sales easier.

Trait #2 – Being a Chief Everything Officer (CEO)

“It will be great if we develop our graphics engine based on my PhD thesis, along with the path optimization algorithm that I learnt few months ago.”

We techie are very proud of our technical capabilities to solve virtually any problems. Sometimes, we feel too proud of it until we want to do everything ourselves so that we can get all the credits. Because of that, partnership and strategic alliance is never something that often comes to our mind. What we overlook in this context is the importance of time to market for our product and solution. With limited resources, we should relentlessly look for strategic alliance, partnership, licensing, and the like on the areas that are not our core business offering, which we can leverage on to get into the market as quickly as possible. We had overstressed on our technology superiority, where the fact is compelling product value proposition is more important. High technology does not ensure our business success, good product does. High technology is only good as your barrier of entry for your medium to long term business goals.

Trait #3 – Poor people management

“I am a lot more competent and efficient than my employees, might as well I do it all by myself. What’s the point if I still have to tidy up what they have done.”

Let’s face it, we techie are not the most people oriented person. We often feel that we are a lot more competent than our subordinates, which in most of the time we really are. (Unless you hire someone who is better than you, which in fact you should!) As a result, we end up trying to do all by ourselves instead of delegating to others. Then as your business expands, you will realize sooner or later you will need people to help you out so that you can focus on the tasks that really worth your time. In order to delegate, first we need to lower our expectation level, loose up a bit, let go and let others step in. It is not easy during the initial stage, but we just have to change our attitude and learn to trust our employees, provide room for learning and failure, set up an atmosphere of encouragement. A lot of techies lose control when they grow due to lack of delegation, hiring and training people. Therefore, we need to prepare for delegation to accommodate growth of company.

Trait #4 – Thinking too far

“Let’s make our core engine more robust and generic so that we can sell it in the future for additional revenue. It will be good if we include these functions as well as I believe we might need them later.”

Perhaps it is our strength in analytical skills and abstract thinking, we techie tend to focus too much energy on our long term goals. This often result in creating too much generalized “just in case” components, features, and functionalities during product development. With limited resources, we should always be mindful of the short term return that ensures survival of our business. When overly emphasize on the long term goals, everything is strategic with no projects targeting for short term profitability. This can cause competitive problems if the long term opportunities are high risk and time consuming, where competitors can take advantage of your immediate shortcomings. But having say that, too short term focus will make a company too reactive, than proactive, which can eventually succumb to competition. My advice is to focus on achieving the short term goals, while aligning them towards your long term goals. This means that you need to work on the short term goals in such way that it makes room for your long term opportunities. You should think twice when deciding on developing any “dead end solution”. Any of your short term measure must not sacrifice your longer term opportunities.

Trait #5 – Analyzing too much

“That problem can be actually solved with that algorithm. But what if there are certain rare occasion where… What if under these circumstances… What if… (Endless what if’s.)”

The baggage that comes with good problem analyst and solver is thinking too much, which, to the extent until we are bogged down by the amount of analysis and feel overwhelmed with the project and task to come to a rational conclusion. This is called “analysis paralysis”, a situation where you are frozen by having too many options with no clear answers, thus making you slow to decide as trying to wait for more facts. This “disease” typically afflicts techie as we often need to wait for all information to be in before making decision, which rarely happens in business as you usually will never have all the facts nor will there ever be riskless decisions. We need to learn to trust our instinct to decide in this situation. Sometimes, we just have to do it without thinking too much, bearing in mind there is no such thing as mistakes or wrong moves, only lessons learnt. You will soon realize most of the time, you need to try out your ideas in order to really find out whether they work for your business.

Trait #6 – Misunderstanding business networking

“I am busy developing my product and I don’t have time to network. I will start networking and building up my contacts when I start selling my product.”

Most techies never see business networking as part of their core business activities. Perhaps networking is never really our second nature. But more than anything else, we wrongly understood business networking as selling. The truth is, networking is never about selling. In contrary to what you have heard from those short sighted sales people, the true philosophy of networking is about building up relationships, either with your customers or other business owners. People often deal with those whom they trust, thus you need to gradually build these relationship over time to build your network of contacts that provide support, information, and business referrals. Networking is about forming and nurturing mutually beneficial relationships, which brings you new connections of whom will become good customers. This will ultimately bring you steady stream of business to ensure sustainability and profitability. Business success is about relationships, and building relationships takes time, so regardless of whether you are marketing your product, you have to invest substantial amount of time in business networking.

Trait #7 – Being unnecessarily perfectionist

“I tell you, this user interface will definitely look a lot better if we use some of the user controls that I found last week. Also, if we can implement a few shortcuts and tool bar buttons, it will make our software looks more complete and useful.”

Perfectionist is good only if it does not affect your overall efficiency and productivity. With the limited resources that you have during startup, you can’t have the best of everything. You need to be pragmatic. From time to time, try standing back to relocate your main focus, niche, and primary competitive advantage, and then divert most of your energy on that. Be a prioritization machine, and always conscious of your current objective to create just what is needed to meet the current objective and avoid the risk of feature creep. Once you have more resources, then you have more breathing space to consider what is the next best things to focus for improvement.

Trait #8 – Being ignorant on the sales process

“Build it and they will come. We just have to do mass advertising and emailing to announce our cool product to the world once it is released, and then wait for $$$ to come.”

We techie often think selling is a no-brainer work, which is a lot easier compare to programming. In reality, selling and marketing can be as challenging as, if not more challenging than programming. The reason is because there is no hard and fast rule on successful selling, nor any “sure win” strategy in marketing. It takes more than science and logical thinking to successfully tackle the market dynamics and psychology. The customers often have to be educated about why they need our product. Thus, it is important to know that selling to the first customer usually takes longer than we want or expect. We need to think of various strategies for overcoming customer inertia to change, which is even more critical if you are developing a unique product that the market does not know. The key here is always developing your product with thinking of how to sell in mind. You have to think critically on how the product features and functionalities affect the sales cycle and product lifecycle. Each stage of the sales cycle and product lifecycle will probably need different resources, tools, and skills to optimize sales results. Thus, it is important not to spend too much on product development and overlook the budget requirements and process of sales and marketing.

Trait #9 – Being defensive on changes

“Sorry, but I can show how your suggestion can be done thru this user interface too. In fact, I would prefer we stick to this interface as I had done a lot of research before developing it.”

Whenever our customers suggest some changes or a new feature to our product, rather than defending blatantly our design and decisions (which most techies tend to do), the customers will be more appreciative if we simply thank them, validate their ideas, and leave our justifications later. We always think that our product is the best thing, which the fact is, what customers think, what they want, is more important. If you do most of the talking, it’s hard to learn much about your customer. Instead, try to ask powerful questions that are open-ended and allow your customers or prospects to give you more information or insight. Rather than we keep schooling the customers, it is more beneficial to let them teach us. An interesting note is that a lot of entrepreneurs often end up doing business, products and services that is very different than what they thought customers need, and what they want to do. This reinforces the point that we need to learn by doing, listening, getting feedback, and adapting it into our business.

Trait #10 – Having weak determination

“Wow, this looks like going to be the next big thing! It is a lot more promising than what we are doing now. I think we should grasp the opportunity and do this now.”

As a techie, we are taught to be always at the forefront of technology. For that, we love new things, especially cutting edge technology. In our mind, we know that determination and focus is the key to success, but in our heart we are often struggling to resist the techie urge. The grass always seem greener on the other side of our fence, which in fact maybe due to our shallow understanding of the other side. It is so easy to want to go off and do new things. Thus, it is important to constantly remind us to be persistent and patient. If you think about it, your clients might confuse if you try to do or offer too much. We must have a clear identity in the market at all times where our customers know exactly who we are, and what we do, what are our business objective and priority.

Conclusion

I had shared with you on some of the behaviors I believe we techies should be aware of, especially if you have plans to start up your own business in the future. If you can keep these in mind at all times throughout your entrepreneurship journey, I have no doubt that your business success will be just around the corner. Your technical skills combined with good sense in sales, marketing, and management, will make you a savvy businessman. Your insight in the business domain will allow you to create a viable and attractive business model for your customers, while your extensive technical knowledge will enable you to explore various implementation strategies and find one that best supports your business model and priorities. If you are developing a product, you are able to ensure it is both technically viable and economically sound with an actionable go to market strategy.

Acknowledgement

Many thanks to Alex and Danny at TOBlender.com for making this article more lively through the comic illustrations.

Introduction

Pervasive computing has been evolving radically for the past few years and it is seen as an emerging trend of computing in the future. Mobile and wearable computers are the two areas in pervasive computing that are more obvious in our daily life and we have seen how they can make our life easier and more productive. One major area of applications for wearable computing devices is healthcare. For the patients with critical disease that requires round the clock monitoring, such as heart abnormality, wearable computing devices can monitor heartbeat and pulses, and can raise an alarm if some critical condition is diagnosed. But, quite often, these devices only have very limited computational power and storage space. This prevents them from being used for some serious computation such as pulse analysis.

The system that we have implemented takes the pulse signal from patients as input. The pulse signal that will be analyzed is input as a sequence of digital Electrocardiogram (or ECG) data sampled at a constant sampling rate. The way how the ECG signal is being sampled and digitized is beyond the scope of this article. In order to understand how the signal analysis works, we must have some basic knowledge about ECG waveform. The heartbeat of each individual consists of a distinct number of cardiological stages. Each of these stages will contribute a different set of features in the ECG waveform, due to the electrical activation by the muscle cells in particular regions of the heart. Figure 1 depicts the ECG waveform of a person with a healthy heart excerpted from [1].

The typical features of an ECG waveform are the P-wave, the QRS-complex, and the T-wave. Occasionally, a small U-wave appears after the T-wave. The cardiac cycle begins with the P-wave (marked as Pon and Poff in Figure 1), which corresponds to the period of atrial de-polarization in the heart. The most distinguish feature is the QRS-complex, which occurs during the ventricular de-polarization (from point Q to point J in Figure 1). The ventricular re-polarization that takes place after that will produce the T-wave. In the absence of U-wave, the end point of T-wave (marked as Toff) signifies the end of the cardiac cycle.

Related Work

There are vast numbers of research that related to ECG analysis in the computing science domain. They had given us much motivation and inspiration into our work. Hughes and his colleagues [1] had proposed a method to segment an ECG waveform automatically into its basic features described above. LePage [2] and his teammates had focused more on the extraction and analysis of P-wave to determine the possibility of atrial fibrillation, which refers to a heart abnormality that causes irregular heart rhythm. Both of them used wavelet transformation to analyze the ECG signal and extract its features. Although wavelet transformation is proved to be a robust system when comes to signal analysis, however, they are naturally mathematically complex and ill-suited for devices with limited computational power to produce real-time result. A stochastic hidden Markov model is used in both works for post-analysis tasks like evaluating the signal features to determine the corresponding states in the heart. Hidden Markov model has been long known as a popular tool in the speech recognition domain due to its high versatility and adaptability under different circumstances. Refer to Rabiner’s paper [3] for a comprehensive tutorial on hidden Markov model. We used hidden Markov model in our system to detect the possible heart abnormalities based on the given ECG.

Signal Analysis and Feature Extraction

As we mentioned earlier, we assumed that the system takes the input as a sequence of discrete digital ECG wave samples at a constant sampling rate. In a simpler term, the input is merely a stream of numbers. Therefore, the initial stage of signal analysis is to examine these numbers and attempt to find their correlations that constitute to the features of our interest. Each feature is an attribute of the input signal at a particular time instance. We had identified three significant features for our case, namely Increasing, if the signal is increasing at a particular instance; Decreasing, if the signal is decreasing; and Zero if the signal is stationary, or it only exhibits a slight increase or decrease. (The tolerance of the slight increase and decrease is determined by a preset threshold.) Determining these features from the input signal is done by differentiating it at a specific time instance. However, since we are dealing with digital signal, therefore we can’t use the derivative calculation for continuous function. Thus, we had adapted the calculation for differentiating digital signal. The idea is to calculate the signal changes by averaging the signal samples around the target sample to be differentiated, which can be formally defined as,

where x is a sequence of samples from the input signal, x[i] is the i-th sample of the input signal, i is the index of the target sample to be differentiated, and d(i, x) is the measure of signal changes at ith sample. n determines the number of samples taken before and after the target sample to be averaged for the calculation. A small n value will make the computation more sensitive to slight signal changes. But this also means a minor noise in the signal will have a strong effect on d(i, x), which could possibly create an unwanted artificial feature. In contrary, a large value of n will lessen the effect of noise on d(i, x), but excess averaging across the neighboring samples can cause inaccurate computation of d(i, x). The best value of n depends on the nature of the signal to be processed, which is best determined empirically. In our implementation, we had chosen n as 4 based on the calibration against our ECG dataset that is comprised ECG signals produced by large sample of individuals. In reality, this can be treated as manufacturers’ preset that can be fine tuned for specific individual. Note that we assumed the source ECG signal is always sampled at a fixed sampling rate. Thus, if the sampling rate is a variable in the system, the equation above must modify to take into account of the sampling interval to ensure d(i, x) produce the result in the same time unit regardless of the signal sampling rate.

To improve the tolerance of the signal analyzer to trivial noise, so that the features in the signal can be determined more reliably, multiple scale-space signal analysis is done by applying median filter of multiple window size to the signal in parallel before executing the feature extraction. Median filter is often used in digital signal processing to reduce “salt and pepper” noise while still preserving the significant details in the signal [4]. Prior to the features extraction process (as discussed above) is being performed, the original input signal (denoted as S0) is filtered by three median filters in parallel, with each of different window sizes (w=3, w=5 and w=7), to produce three new signals (S1, S2 and S3 respectively). We will refer them as signals at different scale-space with respect to the original signal. These signals are slightly different among each other, but they look similar generally, as illustrated in Figure 2. Then, the feature extraction process is carried out in the similar fashion as above by calculating (i, x) for every sample of the S0, S1, S2 and S3. The features extracted from each sample of these signals are compared against each other, and only the feature that is consistent across all scale-space is preserved, and it is known as the true feature. The pseudocode for this process is as follow,

What we are trying to do here is comparing the features of the signal at different scale-space. The intuition behind is, if a feature is the true feature of the signal (as oppose to noise), then it will not be destroyed by the median filter but should appeared in the signal of every scale-space. Of course one can argue that this approach will not work on a weak but true feature, such as abrupt signal changes, which will be most probably treated as noise and filtered out in one of the scale-space. Clearly, we have paid a small price in terms of preciseness for achieving better accuracy in extracting the feature. Even so, this tradeoff had showed an acceptable result in our implementation.

Feature Analysis and ECG Models Construction

We used the hidden Markov model to model the ECG of different heart characteristic. The hidden states are basically the major features of an ECG waveform, i.e. P-Wave, QRS-Complex, T-Wave, and Baseline, while the observable states are defined by the signal features, such as Increasing, Decreasing, and Zero. Figure 3 depicts the hidden states and one of the possible state transitions. The precise definition for each hidden states are:

• P1: The increasing portion of P-Wave
• P2: The decreasing portion of P-Wave
• Base 1: Baseline 1 (refer to Figure 1)
• Q1: The increasing portion of QRS complex.
• Q2: The decreasing portion of QRS complex.
• T1: The increasing portion of T-Wave
• T2: The decreasing portion of T-Wave
• Base 2: Baseline 2 (refer to Figure 1)

The transition arcs in Figure 3 can be safely ignored since they merely illustrate one of the possible states transition. Moreover, the states transition will be constructed automatically by Baum-Welch algorithm [3], which is an iterative algorithm for training the hidden Markov model. In a nutshell, this algorithm takes an observations sequence, which in our case is a sequence of signal features extracted from the ECG, and then the algorithm will construct (or train) a model that is optimized for the particular observations sequence (the training sequence in this case). We collected the training sequence from the ECG produced by a healthy heart, and several other types of heart abnormalities. The ECG will be segmented into intervals of complete cardiac cycle. Then, we used this algorithm to construct the ECG models of different heart characteristics. However, since we are training a model against a set multiple of training sequence, with each sequence as a series of features extracted from an ECG interval of a particular heart characteristic, and there are multiple ECG intervals that correspond to the same heart characteristic. Therefore, we had used the modified version of Baum-Welch algorithm that works for multiple independent observations sequence as proposed by Li and Parizeau [5].

After the ECG models of different heart characteristics are constructed, an unknown ECG interval from the user can be identified using the Forward algorithm [3], with the ECG model that generates the highest probability relative to the rest as the most probable match of the possible heart characteristic. To decode the underlying hidden states of a particular ECG interval, the Viterbi algorithm [3] is used instead.

Implementation and Results

The system was implemented for a IBM Linux WatchPad. It’s a low power 32-bit ARM CPU (18-74 MHz) based device. It has low-power DRAM of 8MB, and Flash memory of 16MB. The device has a 320×240 B/W LCD display, touch panel, Bluetooth (V1.1w/ voice), IrDA (V1.2), UART (Cradle), speaker, microphone, accelerometer, vibrator and RS232C. It runs Linux Kernel 2.4.18, IBM BlueDraker and X-windows X11R6.

For the sake of modularity and ease of testing, we implemented the signal analyzer as a separate executable program with the hidden Markov model used for feature analysis. Both of them are piped together using the standard process piping by connecting the standard output of the signal analyzer to the standard input of the feature analyzer. In our prototype, the source ECG data is streamed from an external file to the signal analyzer’s standard input for simulating a continuous ECG reading from the user. The output result is produced by the feature analyzer through the standard output to inform the user of the possible heart abnormalities based on the ECG reading. In the later stage, we also managed to display the ECG waveform being analyzed graphically when we tested it on the X Windows system running on IBM WatchPad. A major challenge when transforming the concept of the two modules into implementation is, due to the streaming input data source, therefore we had to buffer the data until they are sufficient to be analyzed correctly. This might not be as straightforward as it seems to be, especially when the streamed data is filtered in parallel by three median filters of different window size. We must ensure that the output is available from all filters before proceeding to the subsequent processing pipeline.

A serious problem that had bothered us for quite some time in our hidden Markov model implementation was investigating why the training algorithm does not produce an optimum model based on the given observations sequence. When we had just implemented the hidden Markov model, we tested its three major algorithms (namely Forward algorithm, Viterbi algorithm, and Baum-Welch algorithm) against some test data found on some websites. We were very happy since the result conforms to the expected output. But when we trained the model against our ECG data, it does not produce an optimum model, i.e. when we run the Forward algorithm against the same training sequence, we get a very low (near-zero) probability, which we believed it is wrong. We thought that maybe the iterative algorithm was caught in the local maximum (as it might be). More surprisingly, the training process terminates so quickly, which is way faster than we expected for such a long training sequence. This had given us a hint on the problem. It turned out that the iterative algorithm often terminate in the second iteration. Since both iterations produced a very low probability that beyond the precision of a 64-bit floating point. There was nothing wrong with the low probability as it was due to the long training sequence. However, when the difference of the two iterations result was calculated, it was very small and interpreted as “very little improvement”. Thus the iteration was terminated. The remedy for this problem is taking the log-scale of the probability when calculating the difference. Similar to when an unknown ECG is being checked, the log-scale of the probability is taken to compare the probability ratio between models.

We had tested our implementation prototype against a set of 50 labeled ECG data. Each of them is segmented into an interval that contains only a single cardiac cycle that begins with the P-Wave. They were also preprocessed to have unit energy in order to normalize the dynamic signal range and stabilize the baseline. The prototype is running on IBM WatchPad (32-bit CPU at 75 Mhz). The result was computed almost instantaneously, and exhibits an accuracy of almost 90% to detect the heart abnormality correctly from the ECG, as depicted in Table 1. The ECG models for different heart characteristic were trained on an ordinary desktop personal computer beforehand, and then they were stored on the device built-in Flash memory.

Conclusion and Future Work

We had showed a simple algorithm for analyzing a person’s pulse by examining his/her ECG reading. The algorithm exhibited a very low computational complexity and it can be used for any real-time application that running on a machine with limited processing power. Although the training process of the ECG models required a considerably amount time, it is only needed to do once, and it is usually performed on a personal computer. The storage required to keep those are models are very small that every mobile computers and embedded system can afford.

However, there is still a lot of room for further improvements. As we touched bit earlier, it would be better if the signal analyzer and feature extractor is able to work with ECG signal at different sampling rate, or in another words, the sampling rate is a variable in the system. This implies that every process in the system must take the time unit into concern in its algorithm. The challenging part will be building the ECG model, since if the model is trained by a training sequence of a specific sampling rate, meaning that it can only be used effectively under that particular sampling rate.

In a hidden Markov model, if the observations sequence gets particularly long, there is a big possibility that the calculations will exceed the precision range of the machine. This is due to the multiplications of a large number of terms with each term has the range from zero to one. If precision overflow occurs, the result produced is unreliable and unexpected error might occur. Therefore, scaling is necessary for the algorithms in the hidden Markov. Rabiner [3] covered a great deal of details into this aspect in his paper.

Another improvement will be allowing the input to be at any arbitrary point on an ECG, without the need of a compulsory starting point, which in our case, the ECG to be analyzed must always begins with the P-Wave. It would be better as well, if we don’t need to segment the ECG into their cardiac cycle intervals manually for analysis. But instead the system can take the input as a lengthy streaming ECG data, segment them automatically, and perform the analysis and checking. If this can be done, there is a high possibility that we can even show the pulse rate information to the user as well.

There are a few open questions that struck our mind as we were moving along the way. Is using hidden Markov model an ideal solution to solve the problem statement of our system? Is it really a good idea to build the ECG models of different heart characteristics for detecting heart abnormalities? What if there is an ECG from a patient that suffers a rare heart abnormality and we don’t have the particular model registered in our system, what report will the system give to the user? Can we generalize the ECG models into merely normal and abnormal?

References

1. N. Hughes, L. Tarassenko and S.J. Roberts, “Markov Models for Automated ECG Interval Analysis”, Neural Information Systems Conference, 2003.
2. R. Lepage, J. Bouncher, J. Blanc, and J. Cornilly, “ECG Segmentation and P-Wave Feature Extraction: Application to Patients Prone To Atrial Fibrillation”, 23rd Annual International Conference of the IEEE Medicine and Biology Society, October 2001.
3. Rabiner, “A Tutorial on Hidden Markov Models and Selected Applications in Speech Recognition”, Morgan Kaufmann Publishers Inc., 1990.
4. J. Stein, “Digital Signal Processing: A Computer Science Perspective”, Wiley-Interscience, September 2000.
5. X. Li and M. Parizeau, “Training Hidden Markov Models with Multiple Observations – A Combinatorial Method”, IEEE Trans. on Pattern Analysis and Machine Intelligence, April 2000.

Introduction

Since the advent of the first digital computer in the early 1940s [1], software applications have been evolving steadily, with continuously improved technologies and practices to improve the productivity of software developers and the quality of software applications. The traditional prescribed way of developing software is through a series of software engineering processes [2]. Pete McBreen [3] has proposed a craft model that focuses on the people involve in software development. He realized that programming often requires both scientific (thinking of logical propositions) and artistic (formulate creatively various logical propositions) elements that must be nurtured and reflected within individual developers in order to deliver software with higher quality. His model was highly supported by Grady Booch [7], who believe that good people is equally important as good process.

Agile and Iterative Development Methods

Agile and iterative development is meant to address the shortcomings of traditional Waterfall model in software development [4, 5]. It suggested that software development is more appropriately regarded as new product development or an inventive project, with a high degree of novelty, creativity, and change and no previous identical cases to derive estimates or schedules. Thus an empirical approach that welcomes change is needed. Agile development is based on the Agile Manifesto (Listing 1) published by the Agile Alliance [8, 9], which focuses on simplicity, lightness, and communication to maintain rapid and flexible response to change by preparing light and flexible plans [6]. Iterative development breaks the overall development lifecycle into several iterations in sequence. Each iteration has a fixed iteration end date that is not allowed to change. The team is focus on producing the iteration release at the end of the iteration, which is a partially complete system that is stable, integrated and tested. The feedback gathered from this release will be used for planning upcoming iterations, until the final iteration release, where the complete product is released to the market or customers. (As illustrated in Figure 1.)

We proposed our method in agile and iterative development in the following sections. The three most influential agile methods to us are Scrum [10, 11], Extreme Programming (XP) [16], and Unified Process (UP) [19, 20]. They have provided us a well-rounded perspective on agile and iterative development, in particularly, Scrum’s project management style for self-directed team [12, 13], XP’s structure to ensure best engineering practices are applied [17], and UP’s architecture-centric approach to mitigate technical risks.

Mixing the Best Methods

There is a case to be made for mixing various agile and iterative methodologies or components to find the right balance between various development methods. We present in the following sections our vision for such a software development process.

The Workflow Lifecycle

The main purpose of the conceptualization phase is to establish a common vision. The team and other stakeholders of the project need to agree on the scope, vision, and priorities. A few requirements workshop are conducted to capture 10% of the significant requirements in detail. These are preferably features that deliver high business values, and span across as much architecturally influential elements as possible. Story cards are used to record these features as user stories (see Section 2.2) along with rough estimation of the development effort required. Use case model and supplementary specifications can be created to substantiate the requirement details if an onsite customer is not going to be available. The key risks of the project are identified and the release date is determined. Ideally, this phase should be short, such as a few days to a week. If it takes longer, it is usually a sign of excessive up-front specification or planning that should be avoided.

In the exploration phase, the primary objective is to implement the high risk high value features chosen in the conceptualization stage, while finalizing the requirements and features list. It is desirable to mitigate the major architectural risks in this stage by means of research, discovery, and creativity. However, it is important to understand that this stage is not only concerned with research, design modeling, and documentation, but includes programming work. While the main goal of this phase is to deliver an evolutionary prototype with production quality components that serve as a solid foundation for ongoing development, the creation of a small amount of throwaway prototypes are acceptable to mitigate specific risks such as design-requirements tradeoffs, component feasibility study, or demonstrations to investors, customers, and end-users. The software architecture document, which is created along with programming and testing, evolves iteration by iteration, summarizing the big ideas and motivation in the architecture. In addition to development, there will be a series of short requirements workshops (one per iteration) to refine most of the requirements based on the feedback from the growing system, and the estimation on story cards is further improved in light of the team experience on the development tasks.

By the end of this phase, the user stories to be implemented for the upcoming release are selected based on their estimates and time available towards the release date. The software architecture document is finalized, summarizing the stabilized architecture, supported by the significant programming work to build and prove it. The software object model can also be documented quickly by reverse engineered from code. This document is meant to be a short and concise learning aid that allows the team to form mental images of the whole system, and use as a guide for the team when making assumptions and decisions in creating detailed design, as well as instill common understanding.

During production phase, the customer (or product manager) chooses the user stories to implement at the beginning of each iteration. These user stories are selected based on the ones with the most business value, while ensuring that they can be completed in an iteration. The developers then break the user stories into many short, estimated programming tasks. The total estimated task-level effort may lead to readjustment of the chosen user stories. It is a mistake to create, at the start of the first iteration, a plan that lays out exactly how many iterations, and what will occur in each. The team only plans for the next upcoming iteration, and then planning adapts iteration by iteration based on current feedback. The iteration planning is typically a day’s work, or at most two.

Once this is done, the development works commence by implementing the selected user stories prioritized by highest business value first. The developers communicate with the onsite customer whenever possible to get accurate details about a user story, otherwise refering to the Use Case model and supplementary specification prepared. The team will come out with the simplest possible and most straightforward design that works while complying with the macro architecture described in the software architecture document. At the end of an iteration, most (if not, all) user stories planned initially are implemented, integrated and tested. An internal release of the system is produced for demo (actual product demo and not PowerPoint presentation) in a review meeting, where the team, customer, and other project stakeholders attend. The team articulates the system functions, design, strengths, weaknesses, effort of the team, and future trouble spots. Feedback and brainstorming on future directions are discussed and noted, but no commitments are made during the meeting until the next iteration planning. The series of iterations will ultimately work towards the release date to produce a fully working and tested system ready for release.

After the release, post-production works are carried out, such as deployment, training, marketing and sales. Documentation and manual writing are done incrementally in parallel along with the development effort and finalized when near the release date, when actual printing works begin. Maintenance phase involve activities like enhancements and bug fixes that can be conducted by following the similar workflow lifecycle to produce incremental releases and bugs patches. Figure 2 summarizes the entire workflow lifecycle.

The Core Practises

The workflow process described in Section 2.1 sets the direction for the team through the course of development by telling them the main purpose of each stage, the typical activities and recommended duration. The following outlines the core practices adopted from various agile methods that are carried out by the team in different stages throughout the development process. These are best practices that the team does on a minute-by-minute basis. We are attempting to have a development process that is agile and has a clear direction, knowing what are the best things we need to do to achieve these goals, while making some practices a routine in the process. We need to ensure that this will not only result in productivity increase, but reduce the requirement and technical risk of software, as well as nurturing a satisfying and sustainable team. Figure 3 provides an overall picture of how these practices fit within the workflow lifecycle.

Requirements

Requirement Workshop is a meeting between project manager, customer, and other stakeholders in the early stages of the development lifecycle to identify the vision, high level objectives, and business case, as well as agree on the scope, priorities, and release date. Features and requirements are captured as user stories, which are customer-visible functionality or scenarios in the software [14] written on story cards (A5 or A6 sized index cards) in brief, substantiated by use case models and supplementary specification when necessary [15]. Release Planning is conducted to define the scope of user stories, decide what to do and what to defer, in order to provide the best possible release by the agreed date. Time and effort required to implement are estimated for each user story in terms of ideal engineering hours [29, 30]. Estimations can be improved through experience gained during exploration phase, experimenting through spike solutions [31], and splitting large user stories. Then, the customer picks the ones with the most business value, and their estimated time and effort add up to the release date. Just before an iteration starts, Iteration Planning allows the customer to choose the user stories to be implemented during the iteration, while the team brainstorms engineering tasks (on a whiteboard or cards) in order to fulfill the stories. The developers then volunteer to sign up a set of tasks and estimate them. Every task should be estimated in half-day to two-day range, otherwise they are refactored.

Analysis and Design

The developers use the simplest possible design that gets the job done, bearing in mind that the requirements will change tomorrow, so only design what’s needed to meet today’s requirements, and avoid creating generalized “just in case” components. To foster common understanding and eliminate the fear of not knowing what to do, hold a quick design session where the developers get together and spend a few minutes up to half day sketching out the design. The usage of high touch low tech methods is encouraged during the design session, such as using CRC design with a few cards [21, 22, 23], or sketch some UML on the whiteboard, flipchart, or a sheet of paper. When arguing over design alternatives, pick the simplest one that could possibly work, or try a few ones to find out. To ensure simple design that contains minimal, simple, and comprehensible code at all times, continuous design improvement through refactoring is crucial and should be undertaken as part of daily programming habit [25].

Implementation and Testing

All production code is created by two developers at one computer, where both engaged actively via open communication, to keep each other on task and motivated. While one of the developers is coding the immediate programming task, the observer is doing real-time code review. The developers all need to agreed on a coding standard, and most importantly, all must use and enforce it. This ensures that the code communicates as clearly as possible and supports a shared responsibility for quality by everyone. Vic Hartog had written very comprehensive coding standards for the C# programming language [32]. All developers are responsible for the whole system, and any source code may be changed by any developer at anytime. If a developer identifies a problem or discovers a chance to improve a certain portion of the system, it is the developer’s responsibility to fix or enhance it by pairing with an experienced developer, or at least address it during the next standup meeting.

It is mandatory to write unit tests for all functions, methods, and classes written by the developers. In fact, the unit tests must be created prior to the actual coding, and they are released into the code repository along with the code they test. Having unit tests available prior to coding helps the developers to be more objective and code just enough to meet the original intention. Aside from that, unit tests also ensure that any new modifications do not break the functionality of the existing code. There are several unit test frameworks [22] that can be used to simplify unit tests creation and automation. Aside from unit testing, Acceptance Testing and Customer Tests are written from the user’s perspective by the customer to test every features. The testers implement them in an automated way, usually via comparing the program produced results with the predefined results created by the customer. A bugs database is needed for cases when manual testing by the customer and tester is necessary, to keep track of test results and defects from iteration to iteration.

All checked-in code in the repository is continuously re-integrated and tested frequently on a build machine, in an automated 24/7 process loop of compiling, running all unit tests, and all or most acceptance tests. The developers were notified by email if there are problems during the build and test process. Ongoing effort is put in to keep build time low (10 minutes ideally) to maintain the true purpose of continuous integration.

Project Management

A Daily Standup Meeting is conducted on each workday at the same time and place, to hold a 15 to 20 minutes meeting with the team members standing in a circle, focusing on the same special questions that are answered by each member: (1) What have you done since the last standup meeting? (2) What will you do between now and the next standup meeting? (3) What is getting in the way (blocks) of meeting the iteration goals? This practice provides a frequent measuring and adaptive response mechanism to update tasks and remove any impediments. Blocks reported at the daily standup meeting are ideally decided immediately, or within 1 hour. The value of “bad decisions are better than no decisions” is promoted. Blocks reported at the daily standup meeting are ideally removed before the next meeting. The project manager should create a Team Firewall to ensure the team is not interrupted by work requests from external parties, and if they occur, removes them and deals with all political and external management issues. The whole team needs to establish a Common Vocabulary, or “System of Names”, from the language of the problem domain that everyone can use. This will make communication between the developers and customers easier.

Performance Measurement and Tracking

Daily Tracking is about tracking progress in terms of the actual number of programming hours spent per day by every developer on their tasks or user stories. By tracking real effort expended we can direct help and provide resources when a story is over or nearing estimate, in order to complete the task as quickly as possible. A big picture of the team progress can be illustrated by plotting a line chart with the X-axis represents days in the iteration, while the Y-axis is the effort remaining by subtracting the total programming task hours spent from the estimates. To measure how much work the team can get it done in one iteration, Project Velocity is measured by summing up the actual programming effort spent on all completed user stories, and total up with the completed tasks for any unfinished user stories for the iteration. Based on the knowledge in past iterations, the upcoming user stories are re-estimated, and the customer is allowed to choose the number of user stories equating to the project velocity measured in the previous iteration. The project velocity is expected to go up and down, but if the change is too dramatic after a few iterations, a release planning is needed to revise the scope and release date. The core idea is to track the total amount of work done in team effort during each iteration to keep the development moving at a steady predictable pace.

In order to continuously verifying the software quality, Quality Tracking is done by measuring unit test scores over time, which should always be 100 percent pass. The official customer measurement of quality is the acceptance tests that is determined at the end of every iteration or, if possible, every day. The number of acceptance tests gives a good measurement of the testing scope, and the number of successful tests tells how well the team is doing. A bugs tracking system is important to trace the bugs when found and track them until they are fixed. The tracked bugs might form certain patterns allowing analysis and assumptions to predict future occurrences.

Change Management

To deal with changes, Iteration Demo and Review is conducted at the end of each iteration, to demonstrate the current iteration release to the team, customer, and other stakeholders. This is actual product demonstration and not some PowerPoint Presentations. The goals include informing stakeholders of the system functions, design, strengths, weaknesses, effort of the team, and future trouble spots. Feedback and brainstorming on future direction is discussed and noted, but no commitments are made during the meeting until the next iteration planning.

Workplace Environment

An Informative Workspace is recommended with easily accessible information on current project status and priorities, including individual commitments by the whole team. Work trend and velocity are made visible as well. Various charts reporting work quality and progress can be easily evidenced in the room. Project related information that is constantly evolving and requires ongoing improvements by team members can be written and published using Wiki Web technology. Wiki allows people to edit Web pages using only their browser, as well as creating new pages, and hyperlinks between Wiki pages by a set of special WikiWords. Comparison of various Wiki implementations can be found here [26, 27, 28].

Lessons Learnt

We managed to convince the management to apply our proposed method in one of our new product development. This product is a knowledge based visualization software application, which is fairly novel, and we can’t really find any similar applications in the market that we can model from directly. Thus, we think it is perfectly suitable for agile and iterative development.

Before commencing the development, it is crucial that the build server for continuous integration is installed and running. Bugs tracking system should be in place about the same time as well to ensure the smooth flow of the rapid reviewing and feedback cycle throughout the iterations. It is also important to have the customer works together with the developers during the conceptualization stage to capture the initial requirements as user stories. The customer will attempt to identify features with high business value, while the developers will supply inputs from the technical perspective, performing rough preliminary assessments on the technical viability and evaluating their contributions towards the overall architecture.

During the iteration planning, we had learnt that it is extremely useful to keep the customer available throughout the entire session, even when the developers are brainstorming the engineering tasks that seems unrelated to the customer and does not actually require customer presence. But as the developers sometimes require to re-estimate a user story or re-adjust the scope in light of better understanding of its complexity and time availability, it is important to ensure that the customer have common understanding onto this before starting the development. Throughout the iteration as the user stories are being developed by the developers, as we mentioned in the early section, ideally the customer should remain onsite with the developers to clarify any queries that might arise during the development. Although it does help if certain complex user stories are elaborated using use case model and supplementary specifications when the customer is unable to dedicate majority of his time with the developers, we found that the better solution is to nominate a customer proxy (usually the product manager), who represents the actual customer, and frequently communicate with the actual customer to get great understanding (both breadth and depth) on the software being developed. This also works well for software that has a lot of customers, for instance, end user software.

We can’t emphasize more on the importance of automated unit tests as a safety net to any code changes that could possibly break existing code. Aside from having unit tests for every functions, methods, and classes, it is imperative to train the developers on writing effective and comprehensive unit tests in order to elicit the true value. For instance, in addition to positive unit tests that test a function is working correctly, it is essential to include negative unit tests that try to break a function, for example, testing for exceptions or errors being raised by certain functions or methods. It is very easy to write superficial unit tests (or none at all) especially during crunch hours, which should be avoided altogether. Developers should be constantly reminded that implementing unit tests is equally important as user stories and features, and no user story is considered complete without proper unit tests for its implementation. Frequent design improvement through refactoring should also be another important part of the standard programming routine to ensure the effectiveness of agile methods. As we are avoiding speculative big up front design before coding (for reasons mentioned in earlier sections), the developers need to constantly look for ways to improve the current software design in light of experience and better understanding on the software being developed, so that the design always keep up with the present requirements. Without frequent refactoring, the software will risk ending up with shoddy design with a lot patchwork that will significantly reduce software maintainability issues in the long run.

The bottom line to create an environment that is conducive for software research and development is to recognize the human aspect in the process. In our company, we promote verbal communication more than documentations among team members. We attempt to understand and sensitive to individual needs in order to make them the most productive on what they are doing. Pair programming greatly synergize the team, but different pairs might have differently compatibility, thus it is important to switch pair from time to time. We also found that it is important to instill team focus on the current iteration of work in order to produce the iteration release on time. Overtime should be avoided, communicating to adjust scope if necessary. Timely iteration release has significant psychological effect to the team. It will give the team a great sense of completion at the end of each iteration, and ensure every developer to come fresh and clean at the beginning of each iteration.

Conclusion

We have given a broad perspective on agile and iterative development methods and proposed our preferred way, which is carefully crafted by choosing the best process practices from a thorough understanding of existing methods. Most agile development practice recommends four to ten people in a team. Larger teams should be split into a few sub-teams [33]. For estimating and tracking development effort, there are some who suggest using abstract value, such as Story Points or Gummy Bears. Ideal Engineering Days is another way of estimating by assuming the number of uninterrupted work days required. Estimation is “an art at best” and the key is to measure performance and harness this feedback [34]. There are a number of software tools available for aiding the planning and management of agile and iterative development. Some XP experts such as Ron Jeffries are strongly against using them, as he believed it will deter human interaction and participation [35]. Whilst we definitely agree on this, we still perceive values in those tools for helping the team in better organizing and archiving project related information, i.e. imagine if the story cards had coffee spilled on them, or bug reports were misplaced, etc.

For a successful implementation of our method, it is common to adopt it with pilot projects and a method coach to drive the learning process. The pilot projects should be big enough to be significant, but not too big with too much risk to fail, which will definitely banish the adoption drive. It is necessary for the developers, managers, and customers to have an honest perception of the method, and be cautious not to oversell it but instead propose the pilot project as an experiment whose results will be justified against a set of quantifiable goals to guide further steps. It is important to bear in mind that improvement might not be quickly apparent as it takes time and skill over a series of projects.

References

1. “History of Computing Hardware”, Wikipedia, Wikimedia Foundation Inc., 2006, http://en.wikipedia.org/wiki/History_of_computing_hardware#1940s:_first_electrical_digital_computers
2. I. Sommerville, Software Engineering (6th Edition), Addison Wesley, 2000.
3. P. McBreen, “Finding a Better Metaphor than Software Engineering”, Software Craftsmanship: The New Imperative, Addison Wesley, pp. 25-33, 2002.
4. W. Royce, “Managing the Development of Large Software Systems”, Proceedings of IEEE WESTCON, IEEE Computer Society Press, pp. 328-338, 1970.
5. B. Boehm, “Anchoring the Software Process”, IEEE Software, IEEE Computer Society Press, pp. 73-82, 1996.
6. C. Larman, “Plan the Work, Work the Plan”, Agile & Iterative Development: A Manager’s Guide, Pearson Education, pp. 62, 2004.
7. G. Booch, Managing the Object-Oriented Project, Addison Wesley, 1996.
8. Manifesto for Agile Software Development, 2001, http://www.agilemanifesto.org/
9. Agile Alliance, http://www.agilealliance.org/
10. K. Schwaber, Agile Project Management with Scrum, Microsoft Press, 2004.
11. K. Schwaber & M. Beedle, Agile Software Development with Scrum, Prentice Hall, 2001.
12. K. Fisher, Leading Self-Directed Teams, McGraw-Hill, 1999.
13. S. Berkun, “How to Make Things Happen”, The Art of Project Management, O’Reilly Media, 2005.
14. R. Jeffries, A. Anderson & C. Hendrickson, “User Stories”, Extreme Programming Installed, Addison Wesley, pp. 28-29, 2001.
15. A. Cockburn, Writing Effective Use Cases, Addison Wesley Professional, 2000.
16. K. Beck, Extreme Programming Explained: Embrace Change, Pearson Education, 2005.
17. W. Humphrey, “Why Don’t They Practice What We Preach”, Annals of Software Engineering, Springer, pp. 201-222, 1998.
18. C. Larman, “Programming as if People Mattered”, Agile & Iterative Development: A Manager’s Guide, Pearson Education, pp. 30-31, 2004.
19. P. Kroll & P. Kruchten, The Rational Unified Process Made Easy, Addison Wesley Professional, 2003.
20. P. Kruchten, The Rational Unified Process: An Introduction, Addison Wesley, 2003.
21. D. Wells, “CRC Cards”, The Rules and Practices of Extreme Programming, 1999, http://www.extremeprogramming.org/rules/crccards.html
22. “List of Unit Test Frameworks”, Wikipedia, Wikimedia Foundation Inc., http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks
23. K. Beck & W. Cunningham, “A Laboratory for Teaching Object-Oriented Thinking”, Proceedings on Object-oriented Programming Systems, Languages and Applications, ACM Press, pp. 1-6, 1989.
24. D. Rubin, “Introduction to CRC Cards”, Methodologies and Practices – White Paper, SoftStar Research Inc., 1998.
25. M. Fowler, K. Beck, J. Brant, W. Opdyke & D. Roberts, Refactoring: Improving the Design of Existing Code, Addison Wesley Professional, 1999.
26. “Comparison of Wiki Farms”, Wikipedia, Wikimedia Foundation Inc., http://en.wikipedia.org/wiki/List_of_wiki_farms
27. “Wiki Feature Comparison”, WikiMatrix, http://www.wikimatrix.org/
28. “Wiki Farms”, http://c2.com/cgi/wiki?WikiFarms
29. K. Beck & M. Fowler, “Project Scope and Estimation”, Planning Extreme Programming, Addison Wesley Professional, 2000.
30. R. Jeffries, A. Anderson & C. Hendrickson, “How to Estimate Anything”, Extreme Programming Installed, Addison Wesley, pp. 185-188, 2001.
31. R. Jeffries, A. Anderson & C. Hendrickson, “Spike Solution”, Extreme Programming Installed, Addison Wesley, pp. 41-44, 2001.
32. V. Hartog & D. Doomen, “Coding Standard: C#”, Philips Medical Systems, Philips Electronics NV, 2003.
33. C. Larman, “Multiteam or Multisite Early Development”, Agile & Iterative Development: A Manager’s Guide, Pearson Education, pp. 248-249, 2004.
34. M. Hohman, “Estimating in Actual Time”, Proceedings of the Agile Development Conference, IEEE Computer Society, pp. 132-138, 2005.
35. R. Jeffries, “Some Thought on Planning Tools”, XProgramming.com, 2004, http://www.xprogramming.com/blog/Page.aspx?display=PlanningSoftware