People and Practice

AgileTM vs Real Agility - The Constant Rush

Being in a rush is counter-productive. It is stressful for the people doing the work and the quality of the work suffers. In software development that translates into an ever increasing amount of spaghetti code and an architecture of quick fixes which then leads to a slow down. This slow down then leads to greater time pressure, and the rush gets worse.

Real deadlines do exist, and sometimes out of necessity a team has to pull out all the stops and make a short-lived dash. The big problem arises when this mad dash is the normal state of affairs.

AgileTM vs Real Agility - Truly Self-Organizing Teams

Empower people to act responsibly and they generally will. Exercise empathy and people will trust you. Give people the information they need and they will reciprocate. Agile development was an attempt at doing these things better, but it has been reduced to a collection of code words and empty rituals by managers who don’t realize that it is actually their philosophy about the purpose and nature of management itself that needs to change, and not merely their choice of techniques.

AgileTM vs Real Agility - The Fight Is On

This series is about agile. Not AgileTM, not Big A Agile, not the type sold in three day certificate programs, not the nice neat packaged set of rules Agile, not the type mandated from above, not the religious kind.

No... this is a series about real agility. An idea, a concept that is more than a set of rules and roles. This is my contribution to help my fellow software developers out there, struggling against the frankly terrible practices being carried out in our industry in the name of Agile. This is a series about taking the power back into the hands of the real experts, the software developers. That is where agile began after all.

Consulting and the Journey to Mastery

In my 12 year career I've worked in a variety of development roles and seen periods of extreme growth and periods of stagnation. The periods of growth are highly rewarding and exciting. They are periods where all you see is opportunity for innovation and you just want to build and build and build. The periods of stagnation are quite the opposite, you get bored, your solutions become less innovative and you risk burnout. Not to mention your career goes nowhere if you remain in a permanent state of stagnation.

Detective Optimizers

Having worked in a centralised application support team I have had the opportunity to study the personality traits that make a good fit for support and which don’t. When I say support I am talking about supporting the operation of an application in production, whether it is in a centralised team or in a dev ops team that supports what it builds.

The Freedom Quadrant

What is it about programming that most programmers love? Creativity, problem-solving, analysis and critical thinking are just a few. However, when a senior developer explains to a junior, to the letter, how to implement something, we are taking away those great things about programming from the junior and we are taking away the opportunity for learning. But that doesn’t mean that we should give free rein to anyone in the team to implement solutions as they wish. It all depends on the level of the developer and the complexity of the problem/solution space.

"We"

As a team leader you are directly responsible for the moral and attitudes of your team. One of the most important things you can do is strive for an attitude of team positivity, comradery and togetherness. If you get this right then you are on track to having a successful team, get this wrong and no matter what else you do you’ll hit a wall and you won’t be able to progress. Not to mention that working in a team that likes each other and believes in what they do is really fun and rewarding.