Archive
Window of Opportunity
Whether you are doing Scrum, Extreme Programming or whatever you want to call it, “time” is a major driving factor in development. Companies are engaged in product wars where it is essential to have new products or functionality in place within a window of opportunity. Create a world class product but miss the window of opportunity you might as well not have developed anything at all.
Concept: Just in time development
The days of trying to plan what is needed in advance in detail and then develop everything at once are over. I am not saying not to do any planning at all. And I am not saying this concept implies working in an environment with little or no structure. I am saying do just enough planning at a high level but not spend a lot of time planning every detail. The future is going to be delivering value at the point of sale or close as possible to the point of sale. If you are using unvarying and predictive practices in software development you are no match for today’s volatile environment. In many cases we do not know what is fully needed or what functionality will be a big success until we get feedback. In addition, in some cases the really good feedback is not given or known until close to the end of a development cycle or release cycle. And in some special cases the point of sale. These are reasons to evolve a product quickly and efficiently as possible close to the end of the development cycle. Instead of anticipatory project management and development practices we should embrace the concept of “just in time adaptive development”.
Concept: Rapid iterations
One basic concept to being adaptive and being able to deliver value toward the point of sale is timing of rapid releases. Build, test and deploy core functionality and then add features in every release. Build a flexible base first and then add features rapidly later. All project deliverables such as vision, scope, design and code are developed in an iterative fashion.
When creating multiple version release plans make good decisions on what to deliver now and what features and functionality to defer. Develop high risk features first. If major changes are required to the architecture they can be completed early to minimize impact to the project. This means feedback is critical for these components. Major changes to the architecture late in a project life cycle usually requires a much bigger effort due to having to change more components and the added complexity of additional code supporting multiple features. In addition, core functionality should be delivered ASAP. What good is a solution that cannot be used for months? Deliver the core functionality first and then incorporate feedback in rapid subsequent iterations to add features. This means the base code must be flexible. By flexible I mean easily maintainable. The previous short sentence is the topics of many books about the details of creating quality code that is also easily maintained.
There are cases where it is not possible to actually deploy rapid versioned releases to the customer. In this case, you may consider an option to deploy to an environment where customer feedback can be solicited. This may be a controlled test site that simulates a real production environment. Rapid releases are deployed and feedback is solicited. Once the product has evolved to a certain point the product is deployed to the real production environment. You may be creative enough or be able to work with stakeholders to come up with other options that work.
See Figure 1 below:
Working through iterations or releases quickly and maintaining manageable scope are key points so that iterations or releases are delivered within scheduled time frames and are of high quality. I am advocating that the releases be small. A few weeks of work at the most is included in any given release. A major down fall is to attempt to deliver way too much in each release especially the initial release. Doing this significantly increases the chance of missing scheduled time frames. Once behind in the development schedule you hope and think you will be able to make up ground in subsequent releases. But in my twenty plus years I have never seen this come to fruition.
Concept: Feedback loops
Shorting project feedback loops are a good thing if your project team and executives are willing to face reality early. Early, frequent and rapid feedback loops have the potential to save money and time by early termination or making early appropriate adaptations to software development projects.
Project team members and executives should constantly evaluate and make adjustments in four critical areas:
1). Product functionality.
2). Product quality.
3). Team performance.
4). Project status.
I like to call implementing feedback making refinements or evolution of the product. No software is perfect so corrections if needed are implemented at this time as well. Plans are just speculations therefore I like to use the terms like refinement, adaptation or product evolution. During a projects life cycle we are reacting to events rather than to a predictive plan. Success depends on constantly evaluating reality-based feedback. The process should embrace discovery and then act on what has been discovered and thus evolving.
Concept: Clear lines of responsibility, accountability and collaboration
In addition to the above mentioned concepts, your organization needs to have excellent collaboration and interaction among your relevant management groups. This means all aspects of your business are executing toward a common goal. Your IT strategy is in-sync with your business strategy. Roles and responsibilities should be clear and concise so everyone knows exactly who is responsible for what and when.
This is a brief introduction to the basic concepts. Each of the concepts mentioned above are complete topics in their own right. Many books and discussions are available for further reading. All I have done is to pull them all together here in hopes of showing you the most important concepts needed to achieve maximum value and hit your window of opportunity.
Information Technology and Customer Service
The fact is that excellence in Information Technology or any job for that matter is all about customer service. In IT, it is not about the technology it is about the service and about the customer. Without the customer, there would be no job. Information Technology really could be called Information Services. It is a service provided to the customer and technology is the tool being used to help deliver the information.
Types of Customers.
There are two types of customers, internal and external. Internal customers are those internal business units supported by IT and can be referred to as employee to employee type relationships. Another type of customer is external to the company and can be referred to as employee to client, or employee to customer. Do not make the mistake thinking your work has such value that you can be flippant with your customers. The attitude that the customer is very lucky to have a person like me as an IT engineer is a big mistake. According to my experience I have seen successful people in IT excel because they know how to manage and maintain good relationships with their respective customers and not because of their superior technical skills. One example is, I worked for a company where there were two software engineers. Engineer number 1 was very knowledgeable and an expert in his field but was very flippant in his answers. The other engineer, number 2, was not so knowledgeable but his attitude was superior and he tried very hard to do the best he could. Engineer number 2, did not always know the answers immediately but would always follow up shortly with the correct answer. I found myself always going to the person who had the better attitude. Knowing I may not get an answer immediately did not discourage me. This goes to show you that a smile and a respectful attitude are keys to success and keys to having loyal customers. I believe in today’s competitive market this can be viewed as an added value.
Going beyond a respectful attitude.
Providing excellent customer service goes beyond smiling and having a respectful attitude. The real test is when your customer has a problem. How you handle the problem will determine if the customer will be loyal or the type of relationship you have with your customer. Sometimes we hear but do not listen. Often when people talk they are distracted and are only half way engaged in the conversation because they are busy thinking about a response while the other person is still talking. Many times this can lead to things being assumed and the listener not fully understanding the complete problem. One way around this is to listen first without being distracted and then formulate your response in a way that improves mutual understanding of the problem. This conveys to the customer that you really understood. If not, then the customer can explain some more. This technique can be used for clarifying communication and avoiding misunderstandings. This happened to me with a customer. The customer was having a crises with the software just implemented and was very upset. I was suddenly caught in an argument where I was busy formulating my immediate responses to the customers accusations. The conversation turned into an argument and the customer left visibly upset. I realized later that I should have suspended my judgment and listened first and then provide options on resolving the crises. As it turned out it was all a big misunderstanding of how the process really worked. Because of this incident I had to work extra hard to gain back the loyalty and trust from this customer. Customers know that you cannot always give them what they want but appreciate that you take the time to really listen to them and try hard to resolve their problems.
“The interaction between people build great software.”
Jeff Sutherland
Chief Executive Officer
Scrum, Inc.
Rapid Software Development
Rapid Development
Objective: Achieve rapid software development.
Software developers are usually under intense schedule pressure to “get it done”. The development time problem is pervasive. Most large projects miss the planned delivery date by 25 to 50 percent. In addition, I dare say that a good percentage of projects that span over a year in development time usually are way over the estimated completion date. The most critical issue facing the software development community is development speed.
Where does all the time go?
You can see by looking at Table 1-1 most of the time for small projects are spent in detailed design, coding and unit testing. If you could eliminate those activities, you would shave 65% off the development time. The most time expensive activities of large projects are architecture/design and detailed design. Cutting design time might seem like a good idea at first. It looks that time cut in design could shorten the project development time. What is more likely to happen is that any time saved will be paid back in later stages of the project. Think about this, a design error takes an hour or so to make corrections on paper. No code changes are involved. The same error detected during system testing could take anywhere from a few days to a month to correct. I have learned that the most effective strategy is to perform each development stage as efficiently as possible. I have actually reduced development time by spending more time in upstream activities such as design. This is because a typical project consumes around 40 percent correcting defective requirements. Correct these problems when they take less time in design. A good design saves time.
“All she had done was to carve one more pattern in the mosaic of her identity, that constantly unfolding design which had been growing more intricate with each passing year. The mosaic would continue to grow…until in the final moment the design was complete.”
Jeri Taylor
STAR TREK VOYAGER
MOSAIC
Software Development 