kaizen

The project format is often the default way of organizing product development. Many organizations have elaborate processes for managing projects such as the UK Government’s PRINCE2 and Ericsson’s PROPS. Both are examples of the Stage-Gate process referred to in an earlier post.

Sometimes the project format is warranted, sometimes it is not. I came to think of a rather old paper of which I have faded photo copy in my (physical) binder with papers I have collected throughout the years. I happened to find it online [1] so that I can share it with you too.

The paper discusses what organizational form to choose for a project based on the nature of the project. The paper in the beginning emphasizes that it only deals with the “project organization” dimension of the project, not the “project management” dimension. The two dimensions are strongly correlated though as is demonstrated in Fig. 6 in the paper. In the functional end of the spectrum there is no project coordinator which obviously implies less focus on project management; the stronger the project organization, the stronger the project management function.

So when do we need a strong project organization and hence strong project management? This is discussed in Fig. 5 in the paper. Basically it says that when there is high uncertainty, new technology, high complexity, long duration, large size, one or a few customers, and high time criticality – in short when there is high risk – we need a clear project organization and strong project management. (See also this earlier post.)

When the opposite is true (low risk), then we can do with less project management and spend more of our resources on the technical tasks of the project. With low risk we can also think more “product” than “project” as discussed in my previous post.

When a product has been firmly established on the market (think Microsoft Word), most major customer risks, technology risks etc have been eliminated. The need for strong project management with all the risk management bells and whistles thus decreases. In this scenario the product is typically market driven to a high degree with a steady stream of new feature requests or correction requests (“bug reports”). Each such feature request or correction request needs to be analyzed on its own merits with respect to cost and benefit in a process that can manage the continous flow of requests. Once thus analyzed and decided, and given that the new feature doesn’t imply any major risk, there is less need for full-blown gate reviews and the rest of the project management apparatus when implementing the feature. We instead have a situation where Agile project management and development methods suit well. The list of approved feature requests maps nicely to the product backlog of Scrum and the informal risk management methods of Scrum [3] are sufficient.

Ready to go under the hood? (Source: Wikipedia)

It never makes sense to throw in one or a few high-risk features in an otherwise low-risk project. With other words, research and development should not be mixed in one and the same project. One high-risk feature amid 15 low-risk features may still determine the risk of the whole project and thus the required degree of project management. My favorite illustration of such a high-risk feature would be cold fusion as the suggested power source for an upgrade of an excavator or a similar machine. Regardless of how trivial the other added features are, the project will have a high risk of failure. Instead the cold fusion drive should be developed as a separate research project to remove most of the risk. (Good luck!)

For the continuos decision making and implementation of new features in an Agile process to work, the new features must thus carry a low risk. [2] and [3] describe how the residual risk can be managed in Scrum. (Note that [3] does not compare Scrum to a Stage-Gate model but some kind of very traditional everything-up-front waterfall model which may not be very realistic.)

I will write about the process of deciding and continously implementing new (low risk) features in a future post. Scrum covers part of the process but I’d like to add a thing or two.

Links

[1] Organizational Alternatives for Project Managers, Robert Youker.

[2] Managing Risk with Scrum, Vikas Hazrati.

[3] Managing Risk in Scrum, Valerie Morris.

The system development project is often used as the area of interest or scope when talking about processes, documents, maturity etc. Some concrete examples are:

• The CMMI maturity level 2 is achieved by defining a process for each project.
• A configuration management plan is often suggested to be written per project.
• Repositories for information items such as change requests and source code files are often set up per project.

I’m speculating a bit but I believe this project focus comes from the culture that also was the origin of process improvement: large, multi-year, military projects. Each project was almost like an enterprise in its own right. These projects by their nature also carried a high risk which is best managed in a project context. (See this earlier post.)

Many software projects today are only one in a series of projects throughout the life time of a product. Most commercial software go through cycles of improvement, sometimes in the form of “patches”, sometimes in the form of larger upgrades which come with new functionality.

With a large number of projects, presumably working on the same specs and code, enhancing and refactoring it, it often makes more sense to focus on the product instead of the project. Regarding the bullets above this would for instance mean:

• It makes sense to early on in the product’s life cycle develop a standard development process for the product instead of inventing a process in each project. This would mean going for CMMI maturity level 3 early on.
• The configuration management plan should be written for the product, not the project. It makes little sense to change the way the data is managed from project to project. This would in fact impede (re-)using the previous versions of the specs and the code as a starting point for the next project. And it would be really difficult to see how one could have different configuration management plans for parallel projects working on the same set of specs and code.
• The repositories holding the specs and the code (e.g. the configuration management system) should of the reasons mentioned above be organized for the product so that e.g. branches would be possible to make for parallel projects.

I’m reading Susans Blackmores book “The Meme Machine”. It starts where Richard Dawkins left off at the end of his seminal book “The Selfish Gene”. Dawkins of course talked mostly about the gene as the “thing” that evolution revolves around but towards the end of his book he speculated about whether ideas, memes, could have traits similar to those of genes when it comes to proliferation.

The mean meme machine.

As I understand it, Susan Blackmore claims (a) that there are ideas that can change the behavior of people, (b) that ideas can jump from one person to the next by imitation, and (c) that ideas that facilitate their own proliferation (by appropriately modifying the behavior of the “infected” person and by being easy to imitate) will be the most successful ones in spreading themselves across the human population. Susan Blackmore suggests some successful memes:

• Altruism which makes one popular and gives many opportunities to spread the idea of altruism even though the genetic advantages of altruism aren’t always obvious.
• Celibacy (as practiced by e.g. catholic priests) which relieves the practitioner from the mundane duties of raising children and such and leaves him or her with plenty of time to spread the idea of celibacy itself.
• Religion, especially a religion that strongly promotes missioning and perhaps altruism.

A more light-weight example from my own experience is one of those irritating songs that pop up every summer here in Sweden. They are typically very banal but they infect your brain and after a while you find yourself humming the increasingly annoying tune and infect others with it. Here’s one (click it on your own risk). The link requires Spotify.

Memes and genes don’t always pull in the same direction. It is easy to find human behavior that doesn’t benefit the genes in any way. Suicide bombing comes to mind as a particularly ghastly example.

We can perhaps see organizational change as the “infection” of the organization with memes that change the behavior of the staff, a little bit like the meme of celibacy so fundamentally changes the behavior of the catholic priests; we wish to change the organization by letting it become “host” for the infecting meme. One of my earlier posts might in fact discuss the spreading of memes for such a purpose [1].

What ideas (memes) from meme theory could we then use in our change management activities? A couple of possible things come to mind:

• Any “change idea” should ideally in itself include the idea of spreading the idea further and be persuasive enough in that respect so that people include such spreading in their altered behavior.
• The idea must be simple enough to catch on. The song Macarena sticks much easier than a piece by Bela Bartok. This of course does not mean that Macarena is “better” than Allegro Barbaro.

I will leave it at that in this post but will perhaps later return to the above two bullets. We’ll see if I manage to infect anybody with this particular meme.

Links

[1] The purpose of you next presentation.

Does it exist?

When describing a metamodel it is often difficult to keep apart the description (model) of something and the thing itself. If I want to describe a metaclass representing a system function for instance I find it easy to slip and start talking about the real-world function when the intention was to talk about the description of the real-world function.

I have noticed that it is easier to slip with some metaclasses than others. The slip seems more likely to happen with a description of something concrete than with a description of something abstract. A system function (a mapping of some input values to some output values) for instance feels concrete enough for the slip to happen whereas a non-functional requirement is a bit harder to imagine in the concrete world.

The existence of some things can be determined with our senses but we need some sort of measuring device for other “things”; some things seem to exist more than others. We can for instance determine the (approximate) weight of a permanent magnet with our own senses but would need a magnetometer to measure the existence and quantity of the magnetic field. Our model of the magnet can just as easily describe the weight as the magnetic field. We can likewise rather easily determine whether a function exists in a system by applying input stimuli and observing what happens. It is slightly harder the observe the existence of non-functional characteristics such as electromagnetic emission; you need some special purpose instruments and probably a special purpose measurement chamber. But both “things” exist in this sense and may make sense to describe in our model.

The answer? I believe that everything we model must exist in the sense that it must be possible to determine if the model is a useful description of the real world or not. But we need to be clear about whether we talk about the real world “thing” (phenomenon) or the description. There can be a huge difference.

There are many definitions of “model-based development” or “model-driven development”. “Model”, like “quality” or “justice”, is an elusive word. In system development we often think of a graphical view of a UML model or a SysML model when we talk about a system model. We also perhaps think about a specific tool for creating such models.

In this post I’d like to elaborate on a previous post in which I claimed that most (everything?) of what we do is based on models of the reality we’re dealing with. Some mundane situations where we use more or less explicit models of reality that help us to predict how the reality will react to our actions and help us choose actions that help us reach our goals:

• Keeping track of social relationships. Some scholars in fact claim that the brain has evolved as a response to a pressure to manage social relationships in a large group.
• Navigating roads or the terrain using either the memory or an explicit map.
• Writing a piece of open source software for my own pleasure and use (see my other blog) keeping the specs in my head, as comments in the code, as a user guide, or as sketches on a piece of paper.
• Human walking or almost any kind of physical activity.

Whether an activity, be it system design or a road trip, is model-based is therefore, I claim, not a very interesting question. My answer is “yes, to some degree”. It is more useful to ask more detailed questions about the characteristics of the model:

• What is the abstract syntax of the model?
• What is the concrete syntax of the model?
• What are the semantics of the metaclasses of the model? This question can be rephrased to:
  • What is the purpose of the model and each of the metaclasses?
  • What questions does each metaclass or cluster of metaclasses answer? Examples could be “what are the functional requirements on this system?” and “how is safety goal X satisfied?”.
  • What transformation rules apply to each of the metaclasses?
• How useful is the model for its purpose?
• What is the ratio of amount of information in the model and in the modeled piece of reality? Rephrased:
  • How efficient is the model?
  • How much information is built into the semantics of the metaclasses?
• How accurately can we answer the above questions?

I might try to analyze some existing models according to the above questions in future posts. In this post I will just say a few words about “model-based” versus “document-based” development. There is of course no fundamental difference between a “document” (for instance a Word document) and a “model” (typically created with a modeling tool such as Enterprise Architect or Rational Rose) since many modeling languages have textual concrete syntaxes and can thus be expressed as “documents”. We could very well describe a well-defined system model in Word.

It is difficult to answer the questions above accurately about for instance a free-format design document. The concrete and abstract syntaxes are typically not well-defined although we may have a template that gives guidelines as to the type of information that goes into the document. We may draw informal diagrams where a “box” may represent several different things; our metaclasses are not explicitly identified. We use regular prose to describe different aspects of the design. We may use words such as “task”, “process” and “module” without defining exactly what we mean. The purpose of the document may be unclear. It can in principle be used as a basis for future development or as a documentation of the as-built system. If we are not clear about the purpose we may fail to keep the design document updated when for instance the software is changed. Since the document is only readable by humans, its purpose is probably to communicate and perhaps to deliberate on the design. Whether it is useful for this purpose and efficient depends to a large degree on the skills of the designer who creates the document.

I prefer the real thing anyway.

As I have written below, I have been using the Eclipse Process Framework (EPF) for quite some time now in a client project. Overall it has been performing well and has won acceptance by the client. So well that I kind of lost inspiration to do something similar all over again, just to have it my way. I have after all developed two previous variants of a similar, model-based process editor, so maybe it would be a sign of lack of imagination to do a third version. I guess I have to find a new excuse for a programming project. (There should be an Android phone for me in the mail and I’m hearing rumors that there is an excellent Android development plug-in for Eclipse [1]. I just need a fantastic idea. What about an image of beer in a glass that you can drink virtually? Oh, that’s been done already.)

Back to EPF. The most impressive thing about it is, in my opinion, that it is so stable. No crashes that I can remember. I once managed to mess up some files but in retrospect I wonder if the real mess appeared before or after I started to edit the XMI files by hand. One thing that has bugged me a bit is that modeling elements that “extend” other, more basic elements (a kind of inheritance for those of you of the object oriented persuasion) have not always been updated when the base elements have been modified. I have been forced to for instance manually update processes that extend a capability pattern when that capability pattern has been changed. This seemed to be particularly true for diagrams. I have even had to delete diagrams from time to time and create new ones to get them updated. I believe I saw something about that in the release notes for the new version I just installed so maybe it has been fixed.

Other than that, I still stick to the opinions in in one of my previous posts but I’ve come to accept that I can’t get it all. The benefits clearly exceed the drawbacks.

Links

Android Developers

I upgraded my Eclipse Process Framework Composer application from version 1.5.0 to 1.5.1.1. The upgrade seems quite uneventful so far. The only thing I had to do manually was to copy my tweaked layouts to the new structure. Below a list of the files I have modified to get the colors, fonts and layouts that I want (mostly for my own reference). I find the original color scheme a little bit daring.

...epf-composer/plugins/org.eclipse.epf.publishing_.../xsl/bookmark.xsl
...epf-composer/plugins/org.eclipse.epf.publishing_.../xsl/index.xsl
...epf-composer/plugins/org.eclipse.epf.publishing_.../xsl/PublishedBookmarks.xsl
...epf-composer/plugins/org.eclipse.epf.publishing_.../xsl/topnav.xsl
...epf-composer/plugins/org.eclipse.epf.publish.layout_.../layout/css/default.css
...epf-composer/plugins/org.eclipse.epf.publish.layout_.../layout/xsl/activity_wbs.xsl
...epf-composer/plugins/org.eclipse.epf.publish.layout_.../layout/xsl/overview.xsl
...epf-composer/plugins/org.eclipse.epf.publishing_.../docroot/stylesheets/common.css
...epf-composer/plugins/org.eclipse.epf.publishing_.../docroot/stylesheets/common_adv.css

Reorganizations are probably as old as humanity. The paleolithic hunting parties must have been subject to reorganizations from time to time. It might have been a bit more physical than the garden variety reorganization today, but the objective was probably similar: to make the organization more effective and efficient or to reflect a new power structure.

Reorganizations are not always easy. I have a couple of times used a rather simple verification method to better prepare for the new organization. The method can be used either to design the new organization and the new processes or to “test drive” (verify) the new organization and processes after they’ve been designed but before they are launched. The method is inspired by the ideas of Ivar Jacobsson described in [1], in particular the concepts business use case [2] and sequence diagram [3] as applied to organizations rather than IT systems.

The verification method suggested is based on two assumptions:

• The organization exists to provide services or products to external parties. Providing such a product or service requires interactions between the organization and the external parties. These interactions can be describe as business use cases, i.e. short “stories”. The business use cases in turn are realized by activities inside the organization (together forming a process) performed by a number of roles. (See [2] and the example below for further clarification.)
• The most important aspect of getting something done is that somebody is responsible for doing it and that the “baton is passed” between the different roles participating in the process so that nothing falls between the cracks. The exact method each role uses to get the job done is of course also important but not as important as that there is somebody there to do the work in the first place. People usually find ways when they know it’s their responsibility even if there isn’t any prescribed method and methods can be designed later if needed.

The method is centered around the creation of one or several sequence diagram(s) representing the process(es) and the roles realizing the associated business use case. (See below for an example.)

The sequence diagram should be created interactively in a workshop by a workshop leader and with all line managers likely to provide resources to the process present. Once all resource providers agree upon the sequence diagram and thus the process it represents, the process and the organization is considered verified.

The following steps can be used as a guideline:

1. Select one or a few business use case(s) to analyze. In the example below the business use case is “get support”.
2. Identify initiating event and role (“business actor” in [2]).
3. Identify involved roles.
4. Draw the sequence diagram together. Add and remove roles and tasks until a reasonable workflow is found.
5. Identify risks for delays, bottlenecks or other potential problems with the drafted sequence diagram, e.g. by asking the following questions:
   • Does the task add value?
   • Is the role receiving an task request likely to have the right skills to perform the task?
   • Are the right incentives in place to perform the task?
   • Are there enough man-hours available to perform the task?
   • Is the task a natural part of a role’s responsibilities or a “hack”?
   • Is the required information for performing the task readily available?
6. (Optional step) Suggest allocation of roles to departments.

Depending on the degree of consensus going into the workshop and the complexity of the processes, a two hour workshop might only suffice to cover one single business use case realization (sequence diagram).

The sequence diagram below represents a (simplified) realization of the business use case “get support” and is thus a (simplified) example output from a verification workshop.

A business use case realization.

By creating the sequence diagram we have shown that we have a reasonable organization and process in place to solve this task. Among other things we have shown that:

• There is somebody to receive the support requests and that the customer will get a much wanted acknowledgement of the reception of the support request.
• The first line support will not get stuck in hard-to-solve problems but can give fast answers when such answers are available.
• There is a path for solving product issues (“bugs”) with a developer on call (and that such a developer on call must be allocated).

Other typical business use cases that could benefit from this type of reasoning could be tender creation, request for a new product feature, scheduling of a new project, and creation of the annual business plan and budget. Some interesting questions will undoubtedly surface when working through these business use cases.

Links

[1] Ivar Jacobsson. The Object Advantage.

[2] Business Use-Case Model Guideline

[3] UML basics: The sequence diagram

Today I visited a company called Sörman (yes, they’ve kept the umlauts in their name which I applaude) and listened to a seminar. One of the speakers gave me the following insight:

In traditional development methods information is stored in documents. But, every time the information is processed by humans, it is actually transformed into a model – a mental model. We don’t think in terms of linear text when we reason about technical solutions. Instead we create some sort of model of the system in our head and reason in terms of that model. It may well happen of course that different people get different mental models from the same linear text as there may be several ways to transform it into a mental model.

Since model-based development is closer to our mental models to start with, there should be fewer transformation errors going back and forth between the (external) system model and the mental model. Not all models are graphical though. There are some mental meta-models that are largely linear and suitable for a textual concrete syntax. We for instance like stories that in turn create images in our heads which is for instance why use cases might still be a good way to describe system behavior.

I often hear expressions such as “here we should define what we do, not how we do it”. These kinds of statements are in my opinion rather meaningless or at least ill-defined.

Let’s take an example from the quality management domain. Some level of process or method description may be said to describe “what” (to do), not “how” (to do it). Typically a process description tells you to do, say, A, B and C where A might be “define the system requirements”. Standing on the level where A, B, and C are described, A could indeed be said to describe a “what” (the “what” being to define the requirements). It doesn’t say anything about “how” to define the requirements.

Now, let’s say that A, B and C are all parts of a higher level process description called “system development” which is one of the business processes of a development organization (along such processes as “system maintenance” and “customer support”). Standing on the business process level, “system development” would be a “what” but A, B, and C would rather be the “how” of system development as they would answer the question: how is a system developed (it is developed by (A) defining the requirements, (B)…).

Conclusion: depending on your perspective, a “what” can be a “how” and vice versa. Looking downward in a hierarchy of process descriptions you see the “hows”. Looking around you at one of these “how” levels you instead see a lot of “whats”. So when you use the (imo false) what – how dichotomy, please at least state whither your head is turned.