Integrating systems is a social skill
Posted by Luuk Dijkhuis mid-afternoon: April 29th, 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.”
Choose your managers wisely; they have cookies on the dark side
Posted by Barre Dijkstra mid-afternoon: March 21st, 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 15th, 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:
- Forming
- Storming
- Norming
- Performing
Importance Of Attitude in Agile Projects
Posted by Balaji D Loganathan at around evening time: March 11th, 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 6th, 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 19th, 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.
Proactive Quality Assurance
Posted by Gerard Janssen in the early morning: July 18th, 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 6th, 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...)
Reality is not plan based: change is a fact of life
Posted by Gerard Janssen in the early morning: June 22nd, 2007
The whole idea of executing a project is that you want to achieve something. A person or organization has goals that they want to achieve. A project is a way to coordinate the efforts towards achieving these goals. Ideally we set all of the goals before the start of the project, initiate the project and let it run to fulfill the goals. This way we would never have to discuss or question why we do the things we do. However, things have a tendency to change, even the goals might change. The question is how we deal with that.
(more...)
Reality is not plan based – Plans as a communication device
Posted by Gerard Janssen terribly early in the morning: June 11th, 2007
When it comes to the contents of plan there is a big difference between prescriptive and criterion based approaches. As we stated before the idea behind a plan is to provide guidance to the activities on the project. In that sense it is a sort of communication device. However, the way we use the plan determines its effectiveness.
A plan should describe how to realize the business case on which the project is based. In the criterion based approach to project management this means that the intention of the project is described, but not all activities on how to materialize the business case are specified. The essence of the plan is to explain or to translate the business case into practical guidelines and criteria on how realize the business case. Put differently, it specifies the high level requirements for the project that need to be met for the project to be deemed successful. Tom and Kai Gilb for instance like to state that approximately 10 high level requirements should be enough to give direction to a project. These requirements then are the criteria used to measure the progress and success of the project.
Archives
Xebia Sites
Categories
- Java (282)
- Agile (109)
- General (50)
- Testing (42)
- Performance (42)
- Hibernate (36)
- Scrum (33)
- Podcast (31)
- Architecture (31)
- Spring (28)
- SOA (24)
- Maven (22)
- Project Management (22)
- Middleware (23)
- Deployment (14)
- Flex (17)
- JPA (17)
- Eclipse (15)
- Xebia Labs (15)
- Quality Assurance (14)