Posted by Rik de Groot around lunchtime: August 20th, 2010
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.
Posted by Rik de Groot in the early afternoon: June 18th, 2010
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?
(more…)
Posted by Rik de Groot around lunchtime: June 23rd, 2008
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.
(more…)
Posted by Rik de Groot late at night: May 19th, 2008
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.
(more…)
Posted by Rik de Groot just before lunchtime: April 29th, 2008
Last week we started the Top 10 SOA Pitfalls countdown with #10: NIH syndrome. This week it’s time for #9.
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.
(more…)
Posted by Rik de Groot late at night: December 12th, 2007
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.
(more…)
Posted by Rik de Groot at around evening time: April 26th, 2007
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.