Posted by Barre Dijkstra in the early evening: August 13th, 2008
I was speaking with a colleague today who’s working as a scrum master on a project with another customer. While we were discussing on how we both look at project metrics and related subjects, the subject of tooling was touched. They used ScrumWorks at that project and were quite happy with it.
After walking through the tool and specifically the features that dealt with organising releases, projects, etc. I found the tool lacking on one part, like all the others I’ve seen and/or evaluated; My current client is an enterprise organisation that has hundreds of employees that work on the software development, due to control of the environment works with fixed date releases and has multiple programs and projects running simultaneously.
(more…)
Posted by Erwin van der Koogh mid-afternoon: July 18th, 2008
A few weeks ago I was asked to explain Scrum and how our Agile Offshore Delivery Model works to one of our new sales guys.
During the session he asked me the question: “What does a client have to do to make a project done this way successful?”
Posted by Twan van Enckevort in the early afternoon: July 15th, 2008
One of the challenges we are facing in our project is connecting antique display devices to the brand new travel information system we are building. If you have traveled by train in the Netherlands you are familiar with them: large displays with booklets for destinations and departure times. It contains a number of booklets which are controlled by a stepper engine. The devices are called CTA’s, were developed in the eighties and are a solid piece of engineering. Behind the track indicator, which doubles as a door, is a temperature control for the heating, a power socket for connecting electrical equipment, a telephone socket and a connector for testing. Oh yes, did I mention it is heavy?
Posted by Eelco Gravendeel just before lunchtime: July 11th, 2008
Multidisciplinary teams are fine and all that, but how to go about true specialists in the project … where do they fit in? I would like to talk a bit about Specialists who are required to do work for the team, but do not have enough tasks or time to actually be part of the team. First I will show why it is just not practical or feasible to make some people fulltime team members. After that I will drop some ideas on how to handle these situations.
Posted by Viktor Grgic in the late afternoon: June 16th, 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…)
Posted by ShriKant Vashishtha in the late afternoon: May 5th, 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.
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.”
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…)
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
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…)