Posts

Something to discuss with your team: You’re working on a ticket, deep in your own task. Then you notice something odd: in a completely unrelated part of the codebase, the comments don’t match what the code actually does. Strange. Maybe someone changed the logic earlier but forgot to update the comments. Now imagine this was your solo project. You’d probably just fix the comment right away. Write a quick update, commit it, done. How long would that take? A couple of minutes, maybe? ...

The Hidden Cost of Too Much Process I’ve seen many teams fall into the trap of Runaway Process Inflation. They start with simple workflows, then gradually adding more steps in the name of efficiency. Yet each new step can subtly slow delivery instead of helping. More process doesn’t always mean more effectiveness. Before adding a checklist, approval, or workflow gate, consider: Does this help us deliver working software faster? Does it speed up feedback or slow it down? Does it improve decisions or just add paperwork? Are we solving a real issue or simply creating the illusion of control? The Essential Question How will this affect our ability to get changes in front of customers? ...

The Velocity Chart records how many story points are completed in each iteration sprint. This is an important chart to have, and I recommend it to all my clients. As the team creates user stories, they are added to the backlog. At some point, those stories need to move into the current sprint. But how many stories should we move into the sprint? We won’t know until we’ve done some basic estimations to get an idea of how many we should pull from the top of the backlog. ...

The Velocity Chart records how many story points are completed during each iteration sprint. This is an important chart to have, and I recommend it to all my clients. The problem is that many teams use this chart incorrectly. They try to use it to measure how much work the team should aim to complete in the next sprint. Towards the end of the sprint, this can create pressure on the team to work faster to meet that objective (often by secretly compromising on quality). Alternatively, it can cause the team to slow down and stretch their work pace so that their last bit of work aligns with the sprint end date. This way, they avoid closing all their tickets and being left with nothing to report in the daily meeting. ...

Before we had the light-weight agile type of development approaches there were two modes of thinking about how software should be built. The light-weight approach (agile before it was called “agile”) worked well for projects that enjoyed a low cost of change, and solved partially defined problems with informally specified goals. The other perspective was more aligned with “Scientific Management” which worked best for projects that suffered a high cost of change and solved very well-defined problems with extremely specific goals. ...