Individuals want to improve their skills, teams want to create more, and everyone wants to go faster. However, improving skills and creating more both require time: something we have a finite amount of. 

There’s often a huge difference between working software and complete software. In agile, nothing is ever really complete, and working software doesn’t have to be fully finished to bring value to the end user.

There’s often a huge difference between working software and complete software. In agile, nothing is ever really complete, and working software doesn’t have to be fully finished to bring value to the end user.

There’s often a huge difference between working software and complete software. In agile, nothing is ever really complete, and working software doesn’t have to be fully finished to bring value to the end user.

The best architectures, requirements, and designs emerge from self-organizing teams. The cultures that are trying to adopt agile are usually command-and-control, because most organizations are. This means that there’s a boss who tells their subordinates what to do, and then those subordinates tell their subordinates what to do. Agile attempts to flip that script upside […]

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. In traditional development methodologies, like waterfall, a customer might try to specify how a system should look and behave completely upfront before they even start development. The problem with this is it assumes that it is possible to completely […]

Simplicity—the art of maximizing the amount of work not done—is essential. When I first started in development, I tried to plan for every possible situation. I was given the requirements, but always asked “what if?” What happened more often than not was I’d build a feature and then never actually implement it because either the […]