Empiric story reference base

Planning has an important role in Agile. The team uses planning to estimate the complexity of a requirement (userstory). The number of complexity points handled in previous timeframes then helps to decide what could fit into the next timeframe. However the complexity changes in time. Things get easier doing it a second time or easier ways are found for problems. This makes the planning even harder. Creating a reference base might bring stability in planning. These references make it possible to create a release planning without planning all the requirements upfront.

Read more →

Cross dimensional teams

Working in multidisciplinary teams is common in Agile. In practice this means that the team consists of people with different skills, but work in the same dimension (for instance software). What about cross dimensional teams? In cross dimensions teams not only the skills differ, but also the area of expertise. For instance developing an electronic device includes electronics and software. They work on the same project, but can they act as one team?
Read more →

Top 10 SOA Pitfalls: #1 – Ignoring culture when introducing SOA

Last week Viktor Grgic explained Unclear ownership / Project based funding. This week we’ll continue with #1 – Ignoring culture when introducing SOA.

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.
Read more →

Top 10 SOA Pitfalls: #6 – SOA does not solve complexity automatically

After discussing #7: Incorrect granularity of services , let’s move on to #6.

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.
Read more →

Does a personality type matter?

A good team can make or break the success of a project. Where does this success come from? Is it the way of cooperation or is it the mixture of the right personality types in a team? Do you pick the right personalities and make them work together or does it happen naturally?

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.
Read more →

EssUP, the practice centric software development process

We don’t like RUP, let’s do practices. Last week Ivar Jacobson (the father of the Use Cases and the Unified Process) was in the Netherlands spreading the word of the Essential Unified Process (EssUp). EssUp (http://www.ivarjacobson.com/essup.cfm) provides a fresh approach to software process improvement and claims to be a new “Practice” centric software development process.

Read more →