Posts Tagged ‘Agile Principle’

The Purpose of Re-Factoring


Refactoring is about reorganization, it comes from mathematics when you factor an expression into an equivalence – the factors are cleaner way of expressing the same statement. Refactoring means equivalence; the original product and the end product must med functionally identical. There are generally two reasons to do refactoring:

  • Maintainability – it is easier to fix bugs because the source code is easy to read and the intent is easy to grasp. This might be achieved by removing monolithic routines into a set of individually concise, well-named, single-purpose methods. Or it might be achieved by moving a method to a more appropriate class, or by removing misleading comments.
  • Extensibility – it is easier to extend the capabilities of the application if it uses recognizable design patterns.

In order to ensure that the function is identical is common to create a solid set of unit tests. The test should demonstrate that the behavior of the module is correct. If the test fails, you undo the change. Refactoring shall make your code clearer, cleaner, simpler and more elegant.

Self-Organizing Teams the most debated Agile Principle

Comments Off on Self-Organizing Teams the most debated Agile Principle

The practice of self-organizing team is one of the most debated principle and one that I personally haven’t figured out rather good. I think the big miss understanding is that people takes about different kind of teams in order to show the difference I like to show what I think the Agile Manifest meant by self-organized teams. What to strive for is that the “whole team” takes responsibility for getting things done and everyone feels that they can bring something to the team. But it doesn’t mean that the team is not free from management control.

What is generating energy and passion of the self-organizing team is that members enjoy the opportunity to organize their own work and contribute with a higher potential. But at the same time people enjoy avoiding administration and organization in order to concentrate on their work, often programmers like to program and not write progress reports to customers. So how does an agile leader achieve the subtle balance between command and influence?

This is the tricky thing. I think the team needs to be influence by the rest of the organization at the same time they need to focus on what they achieve. Management therefore needs to be helping the team figure out the direction and collaboration to other parts of the organization. The group shall have a great opportunity to influence how they work and how do what. I personally think a team needs to be lead and manage and have real genuine support from general management. So I’m probably in favor of more self-managing teams rather than self-Governing teams. I personally sees my management responsibility to make the best of the cards I been dealt with, I’m not always playing with a strait flush on hand. Not everyone have the ability to do the same thing and people do it different good and fast, therefore I prefer to manage who do what.


Here is some thoughtful links on the subject: