Top 10 SOA Pitfalls: #2 - Unclear ownership / Project based funding

Posted by Viktor Grgic in the late afternoon: June 16, 2008

Last week Viktor Grgic explained the Missing skills en this week we’ll continue with #2 - Unclear ownership / Project based funding

In the world of standalone applications, there is typically a clear sponsorship and ownership of an application. There is also a single project with one project manager. The systems could be small or big, but the pattern remains the same. Funding is based on a business case and can be easily defended.
In SOA world, the story is different. There are the usual projects, each having their own objectives and often reluctant to work on generic services or enterprise components. If the ownership and funding for these components and aspects are unclear then chances are high that nothing happens on enterprise level or that it's not according to enterprise architecture or nobody feels responsible when things on enterprise level go wrong (e.g. security).
Several projects working together is not a bad situation, but there should also be a SOA steering committee and SOA competence center well funded and supported by company board.
(more...)

Agile way of documentation!!!

Posted by ShriKant Vashishtha in the late afternoon: May 5, 2008

As you enter into Agile world, a statement welcomes you - "Just do enough documentation". For quite sometime, I was puzzled what we really mean by this. In my view "just-enough" is very ambiguous or abstract. You cannot quantify it. For some who are working for a development project, creating documentation may not make much sense as you can find people just across your table to answer your question and you can get away by doing "not just-enough documentation" (no java-docs, no project overview etc). However when you come in maintenance cycle of the project, it just sucks. Maintenance may implicitly means new people, a long project cycle and people who leave the project or even organization itself.

What do you do then? People who were in the project at the beginning may not be there anymore, either from customer side or from software developers side. Without having a knowledge repository, new people will try to reinvent the wheel, will go through the code (white box, which ideally should be a black box most of the times) or will look like people who enter in a dark tunnel without having clue on what they are supposed to do.

(more...)

Integrating systems is a social skill

Posted by Luuk Dijkhuis mid-afternoon: April 29, 2008

Summary

Systems integration within limited timeframes is not mainly a technical art. It is a matter of social and organizational skills. Work on the touchy feely side, and tech will follow. “If you don’t manage the above factors well, you will be in for it anyway, no matter how cool, flexible, state of the art and gorgeous your technology.”

(more...)

Choose your managers wisely; they have cookies on the dark side

Posted by Barre Dijkstra mid-afternoon: March 21, 2008

In my every day work I encounter numerous management styles, ranging from HR-managers doing operational management and vice versa, to managers thinking that “divide and conquer” was a phrase written by a manager and is applicable on groups of employees. I am not saying all managers are bad at there job, certainly not, I am saying that management is one of the professional areas that is relatively easy to get in to but extremely hard to perform well. (more...)

Team norming and chartering

Posted by Martin van Vliet in the late afternoon: March 15, 2008

Staffing a new project is always a challenge. Juggling availability, experience and personal preferences, the proper mix of people has to be found that can make the project successful. Once this has happened, the project can get going and the newly formed group is expected to get on with the business of creating software.

One thing that is often forgotten is that the "project team" really isn't a team at all yet -- they are a group of people who have been put together to accomplish a goal. Chances are that at least some of the people have not worked together before and that there is no common ground for them to become a team. According to Bruce Tuckman, their evolution as a team can be divided into four stages:

  1. Forming
  2. Storming
  3. Norming
  4. Performing

(more...)

Importance Of Attitude in Agile Projects

Posted by Balaji D Loganathan at around evening time: March 11, 2008

While I was reading some chapters from the book "Toyota way", the author was mentioning the importance on hiring the "Talented people".
I also found institute's giving training like " Job Instruction (JI) is the Toyota way for worker training and people development.".

With my recent experience on Agile-Scrum based projects, I started realizing how important is "Attitude" of the person involved in an agile team. (more...)

Make your Scrum Team Sync & Happy

Posted by Balaji D Loganathan at around evening time: March 6, 2008

I had an opportunity to work as a "Scrum Master" (SM) on one of my last few projects. It was lot of fun with challenges and i had great pleasure on doing it. Thought I would share some few things that i have learned from the team management perspective as a SM.
(more...)

Risk management versus the Impediment List

Posted by Eelco Gravendeel just before lunchtime: December 19, 2007

Just the other day someone asked me: “what is the difference between managing risks and working the impediment list?”. At that time I didn’t get much further than "impediments may be risks and they may already be existing problems, but not all risks have to become impediments"… A correct answer in my opinion, but not a very clear or complete one. So let’s see if I can provide a better answer.

(more...)

Proactive Quality Assurance

Posted by Gerard Janssen in the early morning: July 18, 2007

Quality assurance is too often used to just identify a lack of quality and to find deviations from the norm. This is logical in organizational cultures where responsibility is something to be managed carefully. However, wouldn't it be better if QA would be supportive towards an overall strategic goal of improving quality? For this you need a sense of shared responsibility across the organization and its processes. Then QA can work to start improving quality by improving processes, procedures and practices, making sure to prevent problems instead of identifying them. Taking responsibility instead of shifting it. That's proactive QA.
(more...)

Team spirit and responsibility

Posted by Gerard Janssen terribly early in the morning: July 6, 2007

While working on projects or embedded with a customer you always work with other people. Having a good relationship with those around you is a must for being effective. If there is no trust, one cannot know whether the other party keeps his end of agreements made. Usually a natural sense of trust emerges when working with people. But what to think of those situations where you as a consultant are treated as an outsider who is not really part of the team and is considered way to expensive anyway?
(more...)

Next Page »