Category: Agility

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.

A major challenge faced in product development, especially with newly introduced products, is to validate whether or not the product solves problems and delivers value to it’s target group. It is common practice to develop products based on assumptions without involvement of real users. As a consequence the risks of failure and waste of costs is accepted. Even expensive market analysis cannot eliminate uncertainty about the product’s value to real users. Obtaining valid feedback and learn from a product that doesn’t exist yet can be difficult, which leads to a high degree of uncertainty in terms of features the product should contain. Why would you take that risks while real users are available to support you gathering insights and validate the product? The …

Product Development powered by Minimal Viable Product Read more »

Individuals and Interactions over Processes and Tools. This statement is part of the agile manifesto. It highlights the importance of people and communication within the project. The key to understanding this statement is understanding the meaning of the word over. It may seem simple yet many people get it wrong. The word over is repeated four times in the Agile manifesto. The word over in this context means that while processes and tools are important in software development, individuals and interactions are more valued. This doesn’t mean we do away with the tools and processes. Actually we cannot work without them, but we should put more emphasis on the people and effective communication rather than following rigid processes. Developers love …

Unfold The Agile Manifesto – Part 2 Read more »

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.

Scrum is a simple and flexible software development methodology or framework. Scrum framework introduces alternatives to traditional project management systems such as Waterfall or Sequential development. In scrum we only have three roles; product owner who represents the clients or users, the scrum master who is the silent leader and the team. From my experience, additional roles are not needed since they don’t usually bring extra benefits. The Scrum framework covers all the necessary aspects for successful software and product development. Instead of additional roles it is possible to have a product owner team, where the different product owners cover different areas of the product. Depending on the degree of innovation and uncertainty in your project, this might be even …

Benefits of Adopting Scrum for Software Development Read more »