Agile Development

The Kernel Journals 8: A little help here!

The Kernel Journals 8: A little help here!In the previous kernel journals we have looked at the many practical applications of a process kernel that is based on the key software development entities (known as Alphas) that software projects add value to by progressing through their value states. We have seen that there are many advantages to separating these “whats” (progressions) that we are trying to achieve, from the many possible “hows” (software processes and practices) that describe how we might achieve and evidence these progressions, including the ability to set objectives and track progress in a common and consistent way irrespective of what specific practices a project happens to adopt.

Read More

Let’s measure the things that really matter

Let’s measure the things that really matterAs technologists, we tend to collect very detailed information and present it in a very technical way.  We talk about things like process maturity levels, and productivity indexes. I have even seen some measurement data about Agile maturity models that attempt to show how agile we are.  The problem with this kind of approach is it doesn’t provide anything that the business and the customers can relate to. 

The business does not really care how agile we are, they want to see results.  They want to be able to set targets, see improvements, and understand the benefits and the quality of the results being generated by IT. Only then can they begin to put the value of Agility into context – the context of the value and improvement generated by the move to agility. Read More

Attitudes Toward Delivering Business Value

Traditional software development projects are executed in a value-neutral setting in which:

  • Every requirement is treated as equally important
  • The delivery of technical components is seen as of equal importance to the delivery of usable systems
  • "Earned value" systems track project cost and schedule, not stakeholder or business value
  • A "separation of concerns" is practiced, in which the responsibility of the development team is confined to turning software requirements into verified code rather than delivering business value
  • The actual desired outcomes of the project are ignored in favor of implementing the largest number of requirements possible

No wonder so many projects fail to deliver the desired business results! Unfortunately this includes many iterative software development projects where the developers iteratively implement the requirements rather than delivering business value. Any management system that rewards things that are easily measured (like implementing requirements) without a clear and direct tie to business value delivered is headed down the wrong path. Read More

The Kernel Journals 6: Where to (first/next)?

The Kernel Journals 6: Where to (first/next)?We all know that we want to “cut to the chase” as soon as we can and start incrementally developing the software product through which we deliver value back to the business. But we also know that there are certain essential pre-requisites to “sprinting”, such as some kind of vision of where we are supposed to be going and the right team and tools to get us there. If we start motoring before we are ready we may head off in the wrong direction or we may find that the wheels come off as we accelerate through the gears. Read More

What is an Iteration?

What is an Iteration?

Iteration: A self-contained mini-project, with a well-defined outcome: a stable, integrated, and tested “release”. Let’s look at the three aspects of this definition in more detail.

A software development project produces a new release of a software product by transforming a set of users’ requirements into a new or changed software product. With an iterative and incremental approach, this process is completed little by little, step by step, by splitting the overall project into several mini-projects, each of which is called an iteration.

From the perspective of the development team, each iteration can be considered to be a self-contained
project. This approach is very powerful because it enables the development team members to focus on meeting their immediate objectives and ensures that the results generated are frequently and objectively measured. The management team needs to ensure that the iteration objectives form
a credible part of the larger overall project.

The management team needs to reinforce this way of working by ensuring that each iteration has the following:

Read More

The Kernel Journals 5: Making the Invisible, Visible

The Kernel Journals 5: Making the Invisible, VisibleThe kernel Alphas are the core, key, critical, central, essential conceptual entities that we need to manage and progress in a controlled way in order to ensure a successful outcome for our project. But, like all concepts, they have the distinct disadvantage of being invisible. A project manager is convinced that his project is important and that managing its progression to a successful conclusion is critical. But if, as an outside assessor, I were to say “bring me this project of which you speak so that I may gaze upon it and assess its status” he would be stumped. He can show me plans, people, documents, but he can’t show me “the project”. These key concepts are the elephants in the room that no one can see because …  well , because they are invisible. To be useful, they need to be made visible and real, so normal people can interact with them.

Read More

Two complementary macro-trends in software engineering by Ivar Jacobson

From my horizon, I see two distinct and yet complementary macro-trends driving the way we become better at developing software. One could be called “Methods & Tools” the other could be called “Professionalism & Craftsmanship”. These two trends are not new, they have been around as long as we have built software. Both are based on the fact that it is people who develop programs, rather than methods and tools. But they take different approaches to the problem by focusing on different aspects of software development.

Trend “Methods & Tools,” exemplified by Semat Initiative (, of which I myself am one of the founders, drives the thesis that the way we develop software is immature and in need of being revolutionized. Yes, these are strong words, but the initiative is supported by more than 30 renowned scientists, scholars and practitioners in the software engineering field, including leaders from major industrial corporations (e.g., ABB, Ericsson, Fujitsu, IBM, Samsung, Microsoft, etc), academia (researchers, professors, institutional managers), and thousands of practitioners around the world.

Specific problems addressed are that often methods seem to be based on fashion and fads; that there are almost an infinitive number of methods that cannot be assessed or compared with each other. The number itself is not a problem. There should be many methods, however, these methods must be designed in such a way that they can be compared, assessed and improved. Finally, there exists a big barrier between academic research and industrial practices, which must be torn down.

The way forward is based on observation and understanding that:

  1. Every method is just a composition of practices, either human or technology related.
  2. Practices are reusable over many application areas and technologies.
  3. Underneath all practices is a small kernel of universals described by a small kernel language.
  4. Universals are things that we always have, do or produce when building software.  We will discover them!
  5. Practices and universals will be described by a small Process Kernel Language.

Using this kernel and the language, we can describe all known methods, and, because practices are comparable, methods that are composed from these practices can be compared. I would like to tell you a lot more now, but it can wait for later. The impact of this SEMAT initiative is that, if successful, we will streamline the entire software world: from academia to industry, from practitioners to teachers and researchers. We will become better, faster, and happier in developing software.

After all, it is people who develop software, not methods and tools. So we must address the “human” side of software development.

Trend “Professionalism & Craftsmanship”, which is popular with the original founders of the agile movement, for instance by Bob Martin (“Uncle Bob”), who takes a very different standpoint. From this perspective, the big problem is not the lack of methods or tools, but how we train, educate and mentor programmers to become professional craftsmen. Code can be written by anyone at any time, but what makes us professionals?

  1. We must be proud of what we do. We must be able to say “no” to either the boss or the customer, if necessary. We have our professional practices and these cannot be compromised.
  2. The boss and the client must accept the fact that our work is technical in nature; so let them think we are geeks, but respectable geeks.
  3. Eliminate hourly rate - doctors or lawyers are not paid by the hour (even if under pressure they may say so). There must be better ways to charge.
  4. Anything that is worth doing should be done well and with quality. When we ship code, we must know that it works. Acceptance testers should not find any errors.
  5. Become competent through an apprenticeship program. Choose a master and learn from him or her.  After some years you may select a new master and also learn from him or her.

Both trends are of course important.

Proponents of methods & tools suggest that it is clear that we must constantly improve professionalism. However, it would be much easier to be professional if we can elevate the level of our understanding of methods & tools.

Proponents of professionalism & craftsmanship are concerned that such an elevation means enforcing restrictions, and many are therefore hesitant or reluctant to work with or support initiatives related to methods & tools.

It is clear to me that we must do both. Since Bob Martin is a signatory of Semat, I think it is clear to him as well.

It is smart!

The Kernel Journals 3: Process Spaces and Bases

The Kernel Journals 3: Process Spaces and BasesSoftware development processes have long advocated structuring a software solution around a domain model of the problem space being automated. A domain model shows how our business processes add value by progressing the states of our key business entities. These entities and their life histories tend to be much stable over time than the processes that surround them. Modeling the entities and their states enables us to experiment with different ways of achieving the same outcomes (state progressions) as we seek to rationalize and automate these processes.
So, why have we never thought to build a good domain model of the software projects at the heart of our software development processes? At IJI we started building such a model some four years ago and this model now forms the heart of our process kernel around which we built the Essential Unified Process. One key motivator was to model the value that different development practices and processes can / do / should provide so that we could enable our customers to evaluate and select between different ways of achieving the same outcomes.

Read More

The Kernel Journals 2: An executable model of software development

The Kernel Journals 2: An executable model of software developmentI first learnt about the power of domain models more than 25 years ago when I first applied the Jackson System Development (JSD) process. This approach involves modeling the key conceptual entities in the problem domain and the business rules that define how value is delivered by advancing the value states of these key entities. Add a few key business attributes and you now have an executable model of your problem domain / business. You can then simulate the execution of your business merely by slapping some rough-and-ready user-interface screens onto these entities.
Read More

We Care!

We Care!How many people know that approximately 40% of the cost of a truck are software costs or that it takes millions of lines of code to develop a mobile phone? The answer is unfortunately, very few. People do not view these things as software products! Software exists in so many things that we touch on a daily basis, but it is hidden under the shells of pacemakers, cars, etc., and the amount of software included in a “normal” product, grows every second.

Is the fact that it is hidden, the reason why so many software projects fail or run over time and budget? Do decision makers realize how much money could be saved if they just cared a little more?

Well, we care! We know that project deadlines can be met, that project budgets can be kept and that the customer can receive what they expected. You just have to be smart and care a little more. Ivar Jacobson International supports an organization called Swedsoft ( whose primary goal is to care about the software industry, the hidden software industry.

Do you care?

Page 6 of 71234567