Category: Self-Organization

Self-organizing teams are an integral part of agile software development and one of the 12 principles of agile manifesto. Even outside agile software development, self.organizing teams can bring a lot of benefits to the organization. The sole purpose of these teams is to ensure that the process of decision making is decentralized, faster, and agreeable to all members. The self-organizing teams are autonomous, hence it becomes possible for them to determine how they want to approach a given problem. They also decide independently of any other teams, group or managers on what decision to take, implement and how to complete any tasks.

It is not a secret that companies are always looking for better ways to handle their software development needs to avoid projects dragging for long periods. Agile software development is one of the most preferred ways of software development due to its dynamic development nature, whereby, requirements and solutions evolve during the entire development process. The emphasis on collaboration between different self-organizing and cross-functional teams is at the core foundation of this method. Characteristics of a good agile development team When selecting a team for agile software development, a company should ensure that at a minimum, they meet the following factors.

When implementing agile software development in teams, context seems one of the least noticed factors. That’s remarkable as it is one of the most important aspects to consider when adopting agile methods. With a series of posts I want to shed some light on that topic, looking at context in agile software developments from different angles. Contexts that are relevant and worth to consider when starting agile software development are organizational culture, team setup (distributed or collocated, skill levels, language and cultural differences) and experience in agile methods and principles (maturity).

There is always a debate regarding the ideal size for a scrum team. The scrum guide recommends seven members plus two or minus two as the ideal number. There seems no consensus among the agile community regarding what the best size of a team may be. However, one issue that people are in agreement with is that smaller teams are more functional and productive. A quote from the scrum guide states that “small enough to remain nimble and large enough to complete significant work within a Sprint” The question then is, how small is small? This will depend on a number of factors.

In the traditional approach (called Waterfall) most developers never feel the owner of the code. Why did this situation happen? Because they haven’t any opinion about the technical issues related with the requirements. Business Analysts think and write uses cases (or other form to specify the requirements) to document each requirement. Then architects move all this information to technical level such as model of database and so on. Even more, there were some company (or maybe there are still companies working in this old way) that provide a framework to developers in order to standardized the development.