by on

During summer holiday in school days, we cousins used to play around with water a lot. We used to get toy water guns, water filled balloons and use a water hose as our weapons. It was always and almost the person with the water hose hits the targets all the time. All the rest were having scarce resources and tracing the trajectory with guns and balloons was hard to hit moving targets.

Why am I talking about this, because it is the same in software development. The team with the water hose wins, this means whichever team is equipped to deliver any commit to production at will, is the one that will be able to deliver desired results and beat other teams.

So much has been talked about agile development but I have not seen it practiced in true spirit. It is usually about sprints, backlogs and masters; instead of building high performing, long running, well equipped teams.

Signs of teams that will meet business goals often and with precision

  • The managers let work happen by setting direction, instead of managing work and allocation
  • The teams know the financial & business impact and is able to take decisions that can help achieve it instead of decisions being top down
  • Tests are first class citizens, there are safety nets at all levels from units to systems to overall, no compromise on tests
  • 1, 2 & Automation. Automation is at all levels, removing any scope for repeated laborious tasks
  • Power and ability to operate the production environment by the team themselves
  • Well staffed and sustainable working schedule
  • Equal respect for one another, no heroes or heroines.

by on

When you are not able to lift weights at a gym, what do you do? Typically people go back, take rest, find what makes them stronger and eat that food; reduce the weights and slowly work their way up. In short people will nurture and train themselves to be better and stronger. They will not cane their hands and legs for not lifting those weights to expect a better performance.

Yet so many SDMs (Software delivery managers) prefer to use coercive power to try to make their teams perform well instead of nurturing and building a strong team. The reason being, many people treat their teams as a resource to be exploited than a team of individuals trying to solve a creative problem.

One solution to this problem is to remove the power the SDMs carry.

  • Make them mere facilitators and deal makers instead of the power to review, promote and reward people.
  • Distribute the powers within the team itself and keep the teams small enough to have meaningful connections and identify non-performers very quickly.
  • Decision making should ultimately rely on technical abilities and feasibilities than pure ego
  • Do not hire SDMs who claim that they can code but they prefer management, these are the know-all people who ruin everyone and everything!

by on

The biggest killer of developer time is meetings, it is a double whammy when it is run by people who do not know how to run it or how to finish it. So often a meeting eats up as much as the 25% of day without adding benefit to any of the attendees.

Image courtesy: Unsplash

Developers cannot spend time in 30 minute slots like non developers. It takes some time to get into the groove and let the mind feel the code as if it is the extension of the natural language. 3 hours of unbroken developer time is the golden rule for me, it does not matter if I am coding, writing something or just starting out of the window thinking about something. The biggest killer of my productivity is when people pull me out of my zone for status checks during the middle of the coding session.

Also too often the planned meetings are more of information gathering sessions for the highest placed person in the corporate ladder. Any agenda or plans are thrown out of the window when the first question comes from a leader. These meetings scheduled for about 30 minutes will get converted to rants, status checks, random questions, fears and more that drags on and on to go well into 90+ minutes.

The best way to run meetings is to

  • Set agenda & time window (Make sure attendees are prepared, if it is a status check it is best done at the start or the end of the day)
  • A facilitator who can keep time and moderate conversations if that goes away from the agenda
  • A parking lot to make sure to capture random thoughts that can easily derail a meeting

Any one I have spoken to, agrees to the above points, but fails to keep the meeting in check because it is mostly run by non developers who don’t mind those additional 30 or 60 minutes getting wasted; or they just keep quiet and stay on so that the seniors are not offended.

If you are a manager and have a development team, please give unbroken chunks of time to developers and learn to run precise status checks and meetings without draining the energy that can otherwise be put into solving problems.

p.s: Design discussions and dev huddles do not follow in the above category but they also need to be facilitated well by the tech lead.