June 14, 2013

1174 views

Management is Dead

Written by:   Bryan Healey

A good team is an ensemble cast, composed of various individuals with an array of strengths and weaknesses, all of whom are fully capable of making calm, intelligent decisions that will benefit the company, the current project and themselves. It is for this reason that any good team will inevitably be helmed by a leader who does remarkably little "leading," confident to let the team self-govern and flourish. With a group well picked, well organized and properly segmented, having each participant in a position to play to their strengths and feel empowered to question and make honest mistakes, the leader can focus on the task of orchestrating the grand mission: architecting projects, planning for the future, and continuing to keep the team happy. This is the essense of hands-off management. Forget about job descriptions, job titles, protocols and procedure; a team is composed of thinking individuals, and these humans thrive in dynamic, adaptable environments in which opinion is valued and everyone is willing to take a risk.

This methodology requires first the careful and cautious construction of the team. Every hire will represent a new team leader, and each candidate should be measured against the expectations of a leader. It may take more time, and the process can at times be frustrating, but the long term rewards will be near-incalculable.

Once the team is in place, the hands-off approach requires the direct and continuous input of each member of the team. Every developer, designer, test engineer and product manager must be an active participant in the company mission and in their own career, able to grow and evolve as circumstances allow. This means getting every stake holder involved wherever able and letting them drive the process. And it is important to remember that, in this scenario, the leader is not an arbiter; the team should not expect a final ruling from above (except in extenuating circumstances). In this world, the team is truly unleashed, allowed to make their own path and forge their own success (and failure). The leader is the facilitator, fostering a culture of success through mentorship and careful team building, and managing failures when they occur to help the team constructively learn and later avoid.

When you hire smart people, let them be smart; it will pay great dividends!

June 11, 2013

1145 views

A Love of Solo Development

Written by:   Bryan Healey

Software engineers are rarely given their due credit in popular circles. Artists by any objective standard, they are to the digital world what an architect is to the physical; a melding of math and beauty to create great benefit. I have watched many an engineer toil in glee at the prospect of crafting a solution that in practice is only marginally improved over the standard of the day - but improved still! It is because of these creatures of code that our society has seen such rapid and elegant advancement in technology (and the rise of the technical supercompany). And while any engineer will undoubtedly agree that some measure of project management is key, an overabundance of management can, in contradiction to the intent, stiffle creativity and set back the intentions of the best and brightest.

I posit that the most effective means for managing developers is to largely leave them alone, as long and as often as possible. A good development process exists specifically to afford the developer the longest amount of uninterrupted development time possible, breaking unweildly projects into smaller tasks and mini-projects that can be completed in a single sprint. With the shackles of management removed, the developer can devote their full attention to solving the task without the project losing focus or becoming stranded. The best managers, at least in my experience, are those who understand the balance necessary between communicating effectively and being given time to solo development and creative isolation. Just where that balance lies is unique to every developer, but I can assure you that it leans wider to the side of isolation than most managers are willing to admit.

June 05, 2013

1175 views

Why Agile?

Written by:   Bryan Healey

Software development, like any good religion of math, is regularly divided on the most effective approach; how can we best box, categorize, accommodate and shorten the cycles of code release? Over the years, many methods have been employed, tested, modified and then tested again, including prototyping, team development, incremental development, waterfall, spiral, RAD, and Agile. Each method has a good share of evangelists and atheists, and all developers and managers have their horrors and heaven-sent tales that they are ready to tell at the simplest provocation. And while I try to remain agnostic when concerning any debate of spiritual matters, on the issue of software development I tend to lean, with varying degrees of rigidity, toward the beauty of Agile.

Let me tell you why:

Firstly, and most disputed, when done correctly an Agile process is the one best suited to leaving developers alone. Despite an expressed hatred of the morning stand-up, the sprint review and the iteration planning sessions, Agile is actually rather skint on the need for interruptions. Stand-ups should be very quick (if they are longer than 15 minutes then big trouble is brewing), planning sessions should be managed almost entirely by product and require minimal input from team leads, and post-mortem gatherings can be done in only minutes following a successful sprint. With so little need to meet and pester, the developer is freed to focus more on what s/he does best: developing great code.

Secondly, an Agile process provides the highest possible amount of management insight with the least possible amount of micro-management. If a check-up is required, I need only to glance at the burn-down rate, review the team task management suite, or render the most basic of listening skills during each morning stand-up. There is no need to pester the team lead or make unscheduled stops at each desk with questions and encouragement just to see how everything is moving along and on target (something every developer will undoubtedly decry).

And finally, it is near effortless for any team to transition into Agile. The biggest hurdle is almost always the same: becoming accustomed to the more rapid release cycle and reporting process. Yet functionally, Agile is little different from any unstructured development process, in that it takes that unstructured goal and breaks it down into smaller, more predictable, unstructured tasks. There should be no grand planning, which cuts down on project ramp-up, and the developer is still mostly left to the task of programming, but with the ultimate goal of each task constrained to prevent runaway development.

Given the choice, I always err on the side of Agile. Perhaps not an evangelist like some, it has proven to me to be the most effective method for developing software.