Problem
The planning starts with a single reference that the team uses as an offset for the initial planning. After a while they forget what the initial reference was and choose another reference. Ending up with a fluctuating planning.

In order to prevent this happening often the whole backlog is planned upfront. Resulting in an equally planned backlog. However this can have a couple of downsides. For instance when a team have not worked together before, the initial planning becomes invalid in a couple of sprints. Work was underestimated or got easier after doing it a couple of times. Replanning the whole backlog then is needed in order to get a valid release planning. It gets even harder when the team changes or not all of the userstories are known at the start of a release.

Reference base
Creating a reference base helps to stabilize the planning in time. After the first sprint the team can create an reference base. This reference base can help to plan the next sprint more accurate.

The reference base is created during or after the retrospective. The following steps can be taken:

1. Mark the reference stories; The stories that went as they should have can be marked as a reference story. Stories that were exceptional or unusual can be put aside.
2. Rate the stories; The team can decide whether the story was over or under rated. Sometimes a story is rated 8 but to be on the safe side the team chooses 13. In the retrospective the team can decide whether it was actually an 8 or 13.
3. Categorize; The marked stories should than be categorized by type of work.
4. Decide whether to add; The stories than should be evaluated. Is a story the same as an existing story or does it help to add this story to the reference base.
5. Add the stories; Add the new stories to the reference base. Include the number of point, expertise needed for this story, etc.
6. Check whether stories are still valid; Sometimes a tool can change the validity of a story. For instance work that is handled by a tool or the amount of points changed due to a tool. Check with the team what needs to be done.

The reference base can change every sprint. Stories that don’t suit anymore can be removed, others can be replaced or stories can be added.

Using the reference base
The reference base can be used for verifying or to plan another stories. The more stories you have in the reference base the more it helps planning that story. Due to the use of the reference base the points assigned to a story remain more stable. This does not mean that a similar story keeps the same points forever. For instance tooling can cause to change the amount of points. So in time the reference base changes, but it is a stabilizing factor.

Conclusion
The empiric reference base helps the team to stabilize the planning. This makes it possible to make a more accurate release planning. It might even speed up a planning session.

Dimensional planning
Dimensional planning (story mapping) can help with this. Usually interfaces and prototyping are put in the first slices. The features that can be addressed later on should be in later slices.
Most of the times the different dimensions of the team work from separate backlogs, but are aligned in the dimensional planning. Although they work from a different backlog they can discuss the problems together. Often this leads to better solutions due to the different views on the problem. In some cases this leads to backlog items for the different dimensions.

Freeze
Somewhere in time the electronics development is frozen in order to start the hardware production on time. From this moment on only small changes are possible. For instance to lower the radiation levels or things that need to be done in order to get an CE certification. Meanwhile the other dimension still continues to develop software for the device. Sometimes solving some hardware issues. Depending of the requirements of the CE certification the main software features needs to be frozen too. Fortunately software updates can be applied in a late stadia.

Conclusion
In conclusion a cross dimensional team can work in an agile way. Using dimensional planning brings focus to the cross dimensional teams. Important is to freeze the interfaces between the hardware and software in an early stage. This will reduce the dependencies of the dimensions. Problems that occur during the prototyping can be solved by working closely together in an early stage.

SOA is an approach. The culture aspect of introducing a SOA is important, but it seems that companies want to invest in tools and not in people. In order of making this SOA to work they force their employees into this new way of thinking/acting. Often this leads to resistance which undermines the SOA goals. In this part we will look into ignoring culture when introducing SOA.

Culture
First of all: what is a culture? An organizational culture compromises the attitudes, experiences, beliefs and values of an organization. Hofstede identified five dimensions in his study :

• Small vs Large Power distance; degree of equality/inequality between people.
• Uncertainty avoidance; the level of acceptance for uncertainty and risks.
• Individualism vs collectivism; the contrast between individual or collective achievement and interpersonal relationships.
• Masculinity vs femininity; is your organization based on male or female values.
• Long vs short term orientation; contrast between relation values orientation.

When introducing a SOA some of these dimensions are likely to change in order to improve the performance of an organization. But wait a minute, a cultural change? It was just an architectural style! Culture is certainly relevant for SOA. For instance, when you look at ownership the first dimension can change. The ownership shifts from IT to the business. When you look at the second dimension, a SOA introduces an uncertainty, because people are confronted with a new way of thinking/acting. In the third dimension the way of working together (business and IT) changes.

Ivory tower
The way SOA is introduced in companies varies, but often SOA introduction is technology driven. From an ivory tower this new way of thinking is figured out and dumped into the organization (see also missing skills). Sometimes with a few practical guidelines, which are often very abstract. The guidelines are misunderstood by the business and IT people which makes it more complex. The main problem here is that the SOA vision is not shared between business, IT and CxOs, (and ivory tower). You can document guidelines, but this does not imply that involved people share the same ideas.

Awareness
In companies the adequate awareness is not filtered down to an enterprise level. Adoption of SOA might become a roadblock. The awareness starts with the concept of SOA. What is a SOA? In most cases people think they know what a SOA is, but have a different vision on the topic. Even people who do know what a SOA is, have different views on SOA. Therefore it is important to have the same vision at enterprise level.

Resistance
Although SOA should not be used to change a culture, the introduction will probably change some cultural dimensions. Resistance to these changes needs to be handled with care. The success of the SOA depends on the acceptance of the SOA, reducing/removing of resistance is crucial to increase acceptance

The best way to introduce a SOA is to follow the following steps:

1. Make the SOA vision a shared vision. Only a shared vision could lead to a successful SOA implementation. Without this first step a SOA is doomed.
2. Define a strategy of how to change. What is your strategy of changing to a SOA. Included cultural aspects and awareness.
3. Define clear tasks, roles and responsibilities.

When using these steps the acceptance of a SOA will increase.

The cultural aspect is often forgotten when introducing a SOA. People that introduce a SOA, often change a culture without knowing. When you are not aware of this, this might lead to an adoption roadblock. Be careful with a large cultural change. Start small, think big.

Next week Vincent Partington and Gero Vermaas will wrap up the SOA pitfall series.

In organizations data and functionality/processes are often fragmented, but are needed centrally. What are the causes of this fragmentation. Does a SOA solve this complexity automatically? Most companies start with a SOA and are confronted with this complexity during the implementation of the SOA.

First let’s take a look at the problem.

• Applications are often built using a silo model. The application contains a set of business functionality exposed through a user interface. The business functionality is intended for its own context without intentions of reuse.
• Applications or services have different views on an entity. For instance, an “amount” entity can include or exclude tax. Combining these different views into a single entity is difficult.
• Heterogeneous data environments with varied schema’s contain redundant data elements.
• When a service is centrally used, data replication is applied in order to combine the different entities and fragmented data into one service.
• Organizations with multiple business lines, spread over multiple locations, have stored core data fragmented in databases/systems. In many cases the size of the IT portfolio has a relation to the scatter.

The real problem is the way the data is stored and how functionality/processes are organized. The SOA architecture style won’t change these problems automatically. In some cases a SOA can make it worse due to the complex integration.

The complexity is caused by the functionality and data fragmentation over different systems, processes and locations. In many cases the fragmentation of core data is caused by organizational growth (for instance mergers and acquisitions). In most cases these companies have a heterogeneous data environment with redundant data elements such as static customer information, common business data or common external data (for instance government, market, or statistical data). Due to the fragmented data, it is often hard to create a complete view of the core business data such as customer information. In portals however, a complete view is needed. An incomplete view can lead to an inconsistent user experience. This might introduce risks and in the long term could lead to being untrustworthy as a company. In order to create a complete view, different complex and inefficient mechanism are needed for accessing/updating the systems/databases. This can lead to inefficiency and higher cost due to the overhead in accessing/updating data in multiple databases using different mechanisms. The real problem is the way the data is stored and how functionality/processes are organized.

Some organizations introduce a SOA in order to reduce the complexity, but what they really do is introduce JBOWS (Just a bunch of web services) and don’t solve the complexity at all. The existing business processes and business functionality remain the same.

In order to reduce complexity the following things need to be organized:

• Eliminate redundant data by gradual reduction in the scatter of core data
• Use the right service granularity (see #7: Incorrect granularity of services )
• Move from the silo/application-based approach to a business process approach.
• Introduce a canonical data model for common data across the enterprise (something we will come back to later).
• Select the appropriate tools to manage and monitor the processes/services.

Complexity is not easy to reduce. SOA can help, but won’t solve the problem automatically. The root cause of the complexity is the way data, functionality and processes are organized. Solving these problems will really reduce complexity.

Next week, Vincent Partington will continue with pitfall #5.

Version mismatch is one of the growing pains of a SOA. A SOA starts simple, but after a while new versions of services will appear and the complexity will grow. Good life cycle management and supporting tools will help you to control the complexity.

The implementation of a SOA will contain services. Initially the services are designed for a purpose. Consumers of these services will use the functionality as designed. However, over time the services might change or new functionality is needed. What effect will this have on the consumers, services and infrastructure?

Let’s take a closer look on these changes. The changes can be divided in major changes (v1.0 to v2.0 ) and minor changes (1.0 to 1.1). The following types of change can be identified (combinations of the types can occur):

1. Minor change of interface: The current interface is extended without compromising the current functionality and interface usage. For instance adding a new method with new functionality.
2. Minor change of functionality: The functionality is changed without effecting any consumers. The implementation is revised. For instance a bug fix of the current version.
3. Major change of interface: The current interface is changed is such a way that it is not backwards compatible. For instance the methods are changed or the functionality is completely new.
4. Major change of functionality: Although in this change the interface remains the same, the functionality is changed in such a way that it will affect the consumers.

In general the minor changes won’t effect the current consumers. These consumers can continue to use the existing interface or functionality. Normally the service can be replaced with the new version without keeping the old version online. Howver regression testing is desired in order to make sure that the new functionality/interface hasn’t affected the existing functionality/interface. Note that the new functionality should fit into the current SLA.

In a major change the changes will most likely effect the current consumers. The old version can’t be replaced by the new version for a couple of reasons.

• The current consumers are not able to upgrade to the new version in time
• The old functionality is still required, although it is not functional supported (only technically).
• The consumers do not want to upgrade and/or are not willing to pay for the extra costs. These costs will raise in time in most cases.

In these cases two versions of the same service will be available for the consumers, although the functionality and interface differ. When multiple versions of a service exists, the complexity of the SOA increases. Although some companies will restrict the amount of versions in production it is often hard to maintain the versions. Often the functional support will only apply on the new version, but technically all versions should be supported. Maintenance is needed for both versions which could result in a minor new version for the old major version.

Versioning problems are in most cases caused by poor governance and lack of supporting tools. Practically the common problems with versions are:

• Who is using the versions? Who used the old interface? How long ago did they use it?
• Missing supporting tools to help manage the different versions.
• How long is support needed for an old version. When is it save to upgrade or remove a version.
• Are the consumers redirected to the right version?
• Consumers are directly connecting to the services without a proxy.

In order to keep track of all these services a good registry is needed. The registry contains services that are active. The registry contains the location and the consumers that use the services.
Tools like an ESB can act like a proxy to different versions. The exact location of a version is hidden from the consumers. The ESB routes the call to the correct version of the service.

Note that generic public internet services are hard to version. In these cases the consumers are unknown and can’t be contacted. Although the same principles apply, the only way they can be notified is in an anonymous way (for instance a notification on a website).

In conclusion versions of services will change overtime. Therefore it is important to be prepared for these changes. Limit the amount of versions and keep track of who is using them in a registry. Use tools to hide the implementation from the consumers so you can be more flexible with multiple versions.

Next week, Viktor Grgic will move on to pitfall #8.

Different personality types contribute to a successful team. Although behavior can differ from a personality, it forms a base of behavior people feel comfortable with. Knowing your personality type can help you understand what makes you tick. This self-awareness is an important factor in being successful. In general a personality type will define 1) your flow of energy, 2) how you take in information, 3) how you prefer to make decisions, 4) the basic day-to-day lifestyle that you prefer.

Many methods can help discover personality types. Myers-Briggs type indicator, (i)DISC assessment, Enneagram of personality, etc. supply tests in order to figure out what personality type people have. Some of these methods need intensive testing, and are therefore hard to apply without doing the actual test. However some of the elements of a type can be noticed without intensive testing. For instance the way people get their energy. Do they get their energy from within themselves or from external sources? Do they absorb information in principles or in details? Are they comfortable with scheduled/structured or open/casual environments? Knowing these preferences it will be easier to approach and work with other person.

In a team people often differ, but are these differences always bad? Some people see these differences as a flaw that needs to be corrected. However the personality type (or character) cannot be changed, so why bother? And even if you can change the personality type of a person does it help the project? Having only one type in a team will slow down the project. For instance, a team full of inspirers will hardly finish anything. After creating an idea they will get bored long before the project is finished. Different personality types in a team can complement each other and create a successful team.

Having a team with different personality types will probably result in a project failure if the people approach each other in the way they feel comfortable. For instance an intuitive person can handle fuzzy data (for instance, the entrance is located at the north side of the building) whereas sensing persons need concrete data (for instance after 50m you take a turn of 90 degrees and after 10m you will find the entrance of the building). Knowing team members’ personality type means knowing strengths, weaknesses and the way of approaching each other. When taking this into account a team is more effective.

Working together in a team will normally go through the following stages: 1) Forming, 2) Storming, 3) Norming, 4) Performing, 5) Adjourning. In relation to the personality types, the norming stage is important. In this stage expectations, styles, roles, etc. are set. During this stage strengths and weaknesses need to be discovered in order to prevent conflicts or hurt feelings. Listening and understanding the team members can help to support and complement each other.

In conclusion a personality-type does matter! It will help to understand what makes you tick. This self-awareness is the key to being successful. However a personality type indicates preferences and does not indicate the strength of ability of a person. Knowing these preferences it will help understanding other team members and work in a more effective way.

Practices

Ivar adopted these practices (or should I say best practices) from the successes of modern software development, which came from software engineering (Unified process), process maturity (CMMi, Spice) and agile methods (Scrum, XP). EssUP emphasizes using only those practices you really need and adapting the process to the needs of the project.

EssUp

Ivar stated that we don’t like reading. He has got a point with this statement. In multiple organizations the way of working is written down in thick documents which no one is going to read. Except for the ones who wrote it, nobody likes it. EssUp aims to be different. It uses a refreshing presentation approach using cards, and guidance sheets to present practices. Because it is presented lightweight way, the practices are easy to learn and understand.

The real power of EssUp that it is open and extensible. Anyone can create their own practices and share them with others in for instance a community.

Essentials

The EssUp has 8 essential practices which are divided five technical practices, and three cross cutting practices:

• Technical practices: Architecture, Iterative, Use-case, Component, Product
• Cross cutting practices: Process, Team (agile), Modeling

Where is testing you might ask? Testing is everywhere. It should be an integrated part of the practices and performed by the creators of the artifacts.

So are these 8 practices all there is? No, these are the ones that are gathered and aligned with each other. You can add more practices (even your own practices) to EssUp, but be aware that the practices could conflict with other practices.

EssUp vs RUP

The nice thing about EssUp is that you don’t have to use all practices. You could easily start with one and add more if you like. With RUP you use the whole process even if you don’t need create all the artifacts. Ivar stated this as the real difference. Depending on your implementation of RUP this might be true. In most projects I use cherry picking so this isn’t a real difference to me. EssUp differs in the lightweight presentation of the practices and extensibility.

After the presentation I asked Ivar about a Scrum practice. He likes Scrum a lot and is working on a practice which will be available in a few months.

Knowledge Generations

Ivar described EssUp in terms of knowledge generations. EssUp is the interactive way of storing knowledge. The differences between the generations are shown in table below.

The EssWork is an intelligent agent that can do active guidance, active review, active automation, etc. of EssUp. It will be available in the VisualStudio and the Eclipse environment. In my opinion the EssWork tool makes the EssUp fragile. Good tools will support the ideas behind EssUp whereas bad tools might result in not using EssUp.

Conclusion

So what’s so great about EssUp? It’s lightweight, easy to learn without reading tons of books. You could say it is in a way agile. I like the way EssUp is using cherry picking. Whether it will be a success depends on the way tools are supporting it and the practices that are created by the community.