I am currently working on an automated system test engine for a project developing a medical device. The test engine runs on a PC and can connect to the device through some network connection. In the device we have implemented a very simple command line application that allows us to control the device from the test engine. We can send a command like "key Accept" to the device which will act like the user had pressed the Accept-key.

To make automated system testing more manageable we thought about extending this small scripting language with language constructs like loops and subrutines. But we did not want to implement an entire scripting language from scratch. Instead it would be much easier if we could use an existing scripting language, like JavaScript which already contains these language constructs.

It turned out to be quite easy to add scripting to our .NET-based test engine, using the Microsoft Script Control. Now we can write a test scripts in JavaScript like the following:   

    // Test pressing a key 10 times
    var i;
    for(i = 0; i < 10; ++i)
    {
        device.key("a");
    }

The "device"-object exists inside the test engine and is written as a .NET class:

    public class DeviceProxy
    {
        public void key(string key)
        {
        sendCommand("key " + key);
            Console.WriteLine("Pressing '{0}'", key);
        }
    }

An instance of this class is added to the Script Control at startup:

    ScriptControl sc = new ScriptControl();
    DeviceProxy deviceProxy = new DeviceProxy();
    sc.Language = "JScript";
    sc.AddObject("device", deviceProxy, true);
    sc.AddCode(File.ReadAllText(scriptPath));

You also need to please the COM-to-.NET interop by setting ComVisible to
True in AssemblyInfo.cs. Take a look at the sample project.

By Lars Thorup

In his classic book about Toyota, The Toyota Way, Jeffrey liker describe the 14 management principles that are guiding the way Toyota operates.  These principles explain why Toyota is different from other companies and so much more successful.

Principle #13 is about nemawashi: The way Toyota makes and implements decisions.

Liker describes the principle this way:

Do not pick a single direction and go down that one path until you have thoroughly considered alternatives.  When you have picked, move quickly but cautiously down the path.

And about the  process:

Nemawashi is the process of discussing problems and potential solutions with all of those affected, to collect their ideas and get agreement on a path forward. This consensus process, though time-consuming, helps broaden the search for solutions, and once a decision is made, the stage is set for rapid implementation.

How can we apply and use Nemawashi in our organizations and how does it fit a agile approach to software development?

There are two aspects of Nemawashi.  First of all it is a thinking process. By deliberately not deciding before all alternatives and risks has been considered, we avoid a kind of habitual thinking, where we just take the first solution that comes to mind, and start implementation immediately.  If we are always are guided by our habits, there will be very little innovation and new thinking. Second, it is a way to create support and engagement from everybody involved. By consulting people involved, carefully listening to their opinion and incorporating it in the proposal, the chances for successful implementation are much better, than if implementation and decisions are forced through.

A common understanding of agile development is that it is more about “doing” than “thinking” and most Agilists are sworn enemies of Waterfall processes with detailed planning up front planning.

So how is nemawashi different from waterfall planning?

Toyota has the concept of The Gemba – the real place, where actual work is done. Any planning activity is done close to or at The Gemba, and not in an ivory tower far from reality. Second  The process of considering alternatives and risks will be a process that is driven by experiments and trying out things – what in product development is called Concurrent Set Based Design.

The ability to do lightweight planning and quickly decisions, as we do it in agile development,  is based on having a software development system, that allows us to have low cost of change, and rapid feedback.  If we think that all processes in a company or in a development group will work the same way as we implement new features in our software, we may make a dangerous mistake.

There is a number of decisions that are not easily reverted, and  does require input and adjustments from many involved people to be successfully implemented. Examples are hiring of new staff, architectural decisions, and changes in organization.

If you hire new people, and have not assured they fit well into the team, or you have not carefully accessed, that they have the skills and competencies you are looking for, it can be very costly to correct. If you decide to start using a tool to manage your development process, because a vendor recommends it, or you know somebody else using it, you are likely to pay a high price, for a too hasty decision later.

A final quote from the Toyota Way:

If you’ve got a project that is supposed to be fully implemented in a year, it seems to me that the typical American company will spend about three months on planning, then they’ll begin to implement. But they’ll encounter all sorts of problems after implementation, and they’ll spend the rest of the year correcting them.

However, given the same year-long project, Toyota will spend nine to 10 months planning, then implement in a small way such as with pilot production and be fully implemented at the end of the year, with virtually no remaining problems.

Alex Warren, former senior vice president,

Toyota Motor Manufacturing, Kentucky

By Bent Jensen

Just the other day I was thinking about the core ideas of Agile software development, and I believe I came to an interesting conclusion. I think the core of agile development is all about one thing -- Aggressively attacking risks. Well, maybe there is more to it  but that is what I'll talk about in this blog entry.

Whether you start up a new software project, or join an existing team that has been constructing something for years, you need to consider what the risks to the project are, and especially what you can do about them.

Risk of not shipping on time (or not shipping at all)
Practice makes perfect. Start shipping from day one -- That is, for instance ship a new release every week. Naturally it depends on the kind of product you are working on, but more than often this is perfectly feasable. In fact, this happens every single day for many web-applications, and users may not even notice.

Risk of building the wrong thing
Have developers work closely with users throughout the project, and encourage them to build an executable and testable model of the business domain, without too much focus on integration. This ensures that the product can in fact solve the core business problem.

Risk of not being able to integrate different parts.
If there is a risk of integration issues, practice! Integrate risky parts from day one of the project. For instance, communication protocols that you haven't tried before may be risky. While accessing a database may be a walk in the park. Find out which integration points require early integration, and balance those efforts against the efforts involved with the risk of "building the wrong thing".

Risk of high long-term maintenance costs.
What you need is a software solution to a business problem. What you don't need is unneccessary technical complexity. Aggressively attack complexity, and make sure your product is still capable of solving the business problem.

Risk of shipping software with defects
Where are your defects? In the business logic, or at the integration points between different modules? No matter which, the answer is simple: Test it (automatically) -- From day one! And use every single defect found, to improve the development process so that you introduce less errors in the future.

Risk of unacceptable performance issues
Have your team commit to a measurable performance goal. ...And you never guessed -- Measure it from day one.

The key to long-term success, is knowing what your long term success factors are, and figuring out how to address them on an everyday basis. What is our long-term succcess factor? I bet you are looking for a cost/earnings ratio close to zero viewing at the entire lifecycle of the software product. This is done by either increasing the earnings, or lowering the cost of development and maintenance. Also a short time-to-market is most likely attractive to your company. Thus, address those every day.

That's it for now. Keep working on reducing your risks out there.

 

By Sune Gynthersen