Most of you know the situation when we had planned some work, let’s say a few different tasks. Then we started most of them, work in parallel and when time is up only a small portion of the work is really completed. In teams working towards deadlines or iterations this usually at least feels bad or has consequences, such as more budget needs to be requested or delay of delivery.

Little’s law is a theorem in queueing theory by John Little. What it says is that long-term the average number (L) of customers in a stable system equals the long-term average effective arrival rate (λ) multiplied by the average time (W) that a customer spends in the system. As a mathematical formula it’s: L = λ W In simple words, there is a relationship between the average number of customers in a stable system, their arrival rate, and the average time in the system.

Product Owner vs Project Manager, what’s the difference? Seems there is none, as many orgnizations just rename roles from one to the other. The cases of renaming that I’ve seen, were one way from Project Manager to Product Owner. That’s a pity as both are distinct roles which require different profile to fill the roles with quality.

Technical debts are part and parcel of the software development process and no matter how careful we approach the development process, there will always be possibility that we may encounter them along the way. Technical debts imply that a developer, at some point applied the easiest route to a solution instead of using a better approach to a problem that would take time. The most vulnerable time for making these haste decision is when the deadline for release of a software product is nearing and there is still work to be done.  These debts can also be incurred during bug fixing. A lot can go wrong during debugging, and removing a minor bug on a large projects sometimes can cause …

How to avoid and deal with technical debt Read more »

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.