Weblog for the AMIS Technology corner
Posts tagged team
Do not register bugs, Fix them!
Oct 28th
For years I was a proponent of bug/issue management systems and worked with open systems like Jira or Bugzilla and also with a lot of proprietary systems. I’ve used these systems during the development and production/ support phase of the products. Every time I use these systems I spend too much time registering, evaluating and sorting issues. At the end of the project I always get stuck with a dozen of unspecified issues with a vague status. Why is this? Bug tracking systems are not bad. The entire process of registering and tracking bugs is wrong.
What the most effective thing to do when you discover a bug? Registered the bug in a system and track it? Does this solve the bug? It doesn’t. You should be busy resolving the bug, not administrating and tacking it!
Compliments; Instant productivity improvement for software teams, with a small effort….
Apr 25th
Hello, you project manager/team leader. I expected this title to grasp your attention. Would you like to know how to improve the performance of your team members? This can be done without massive statistics or an expensive performance improvement program. This magic pill is called positive feedback. Just give your team members the credits for their work and compliment them for their achievements.
As a project manager we are aimed on the end result. In our day to day job we are focused on the things that are not yet done and the things that could go wrong. This focus on future result and possible impediments make us forget the past achievements of our team.
Agile software development, the principles. Principle 11: The best architectures, requirements, and designs emerge from self-organizing teams.
Dec 14th
This is the eleventh of 12 posts about the principles of agile software development. Purpose is to go back to the start of the agile manifesto (http://agilemanifesto.org/principles.html) and discuss the implementation of the 12 principles in real life software engineering. Goals of agility are to go deliver software of higher quality, faster, with a higher acceptance to end-users and able to follow the changing business requirements to strive for competitive advantage.
The question is: is this going to work in practice or is this only based on a nice marketing and sales story.
Principle 11: The best architectures, requirements, and designs emerge from self-organizing teams.
For a long time the engineering expertise (and also software engineering) was based upon the condition that you worked with specialists. These specialists emerged from the principle of division of labour and made it possible for these specialists to focus their attention on their specialism and create the best solution within their field of expertise. The Interaction designer designed a user interface, the architect created a global systems model, developers created code and infrastructure specialists created the necessary environment to run the application on.
Everyone was specialized and delivered the best solution within their capabilities. However when all these components where put together, noting worked. It is an illusion that specialists can design and foresee everything beforehand.
Within agile projects the solution is to use a self organizing team to perform these tasks. This team may consist of specialist, but this is not a requirement. The requirement of this team is that they work together and self-organize all aspects of the systems to be delivered. This team is permitted to make errors and invent their solutions, provided that they deliver and evaluate frequently (retrospective) and learn from their successes (and errors).
Agile software development, the principles. Principle 6: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Apr 23rd
Agile software development, the principles. Principle 6: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
This is the sixth of 12 posts about the principles of agile software development. Purpose is to go back to the start of the agile manifesto (http://agilemanifesto.org/principles.html) and discuss the implementation of the 12 principles in real life software engineering. Goals of agility are to go deliver software of higher quality, faster, with a higher acceptance to end-users and able to follow the changing business requirements to strive for competitive advantage.
The question is: is this going to work in practice or is this only based on a nice marketing and sales story.
Principle 6: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
The purpose of conversation/communication is to transfer a message form the sender to the recipient. In projects, conversation is either about the project process (plans, risk, approach etc) or project content (requirements). Getting your team members to understand the right information correctly is the key factor in the projects success. Being effective in this transference of information is crucial to save time and overcome misunderstanding, especially in agile projects. Face-to-face communication is in fact the most effective way of communicating your project.
Driving a 100km for a 1 hour meeting is much more effective than several teleconference meetings. Despite the technological advanced means of communication (IM, WebMeeting, Video Conferencing) there is nothing more effective than face-to-face contact. Read the rest of this entry »
Agile software development, the principles. Principle 4: Business people and developers must work together daily throughout the project.
Dec 19th
This is the fourth of 12 posts about the principles of agile software development. Purpose is to go back to the start of the agile manifesto (http://agilemanifesto.org/principles.html) and discuss the implementation of the 12 principles in real life software engineering. Goals of agility are to go deliver software of higher quality, faster, with a higher acceptance to end-users and able to follow the changing business requirements to strive for competitive advantage.
The question is: is this going to work in practice or is this only based on a nice marketing and sales story.
Principle 4: Business people and developers must work together daily throughout the project.
Strange, shouldn’t this be common practice? In my daily work I meet lots of developers that have never had any contact with business people. The only notice of the business they get is the constant feed of PowerPoint presentations. When they are lucky the presentations contain hard to understand schemas, “roadmaps” and high level (or extremely detailed) business requirements.
This 4th principle tries to overcome the communication and cultural differences between ICT and business. It recognizes that there are significant differences in culture and jargon between these two groups. By putting them together on a daily basis they get used to each other and they develop a common understanding of the goal of the project.
Working together on a daily basis must actually mean working together! So this does not mean a daily short meeting after witch the two teams retreat to their own project room.
Agile software development, the principles. Principle 3: Deliver working software frequently
Dec 2nd
This is the third of 12 posts about the principles of agile software development. Purpose is to go back to the start of the agile manifesto (http://agilemanifesto.org/principles.html) and discuss the implementation of the 12 principles in real life software engineering. Goals of agility are to go deliver software of higher quality, faster, with a higher acceptance to end-users and able to follow the changing business requirements to strive for competitive advantage.
The question is: is this going to work in practice or is this only based on a nice marketing and sales story.
Principle 3: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Old school linear development methods rely upon the assumption that an extensive specifications and design phase upfront will resolve all uncertainties and specify of all possible functionality in depth. After the design phase the development team retreat to their software factory to deliver the desired software in one big bang (in many cases many months or even more than a year later).
The result of this linear approach is a system; of witch the customer thought a year ago, he would need it in a year. As if the team could stop time to await the delivery of this system. Changes in environment and renewed insights are not incorporated in the end-product.
