Development Management

Trust is everything

Ok. So you have a bunch of nerds. These nerds are expensive. Some of them don't like each other and most of them don't like people in general. However - the magic that you have seen glimpses of ... are pretty amazing. You of course would like to see more magic. Thats the question at hand.. how to we see more magic output? And Less...

• Pointing Fingers
• Who's Right, Who's Wrong
• Unproductive Meetings
• Wasted work
• Unnecessary process
• Missed Deadlines
• Exceeded Budgets
• and lost Trust

The answer is really simple. Trust. Trust. Trust. Trust and more Trust.

Trust is saying that when you agree to something that you do it. That your team can count on you. Trust that you are honest about your estimates. Trust that your team has the companies best interest at heart.

‍

A process is a set of agreements. If this happens then that happens. If that happens when we do this. Theres a process. Most processes have people and if the people don't trust each other the process falls on its face and I don't care WHAT methodology you choose or who you have running it. The focus should be trust.

If I am evaluating existing dev shops I try and quickly sniff out where the trust is fragile or non-existent. Thats where I start repairing.

Here are few guidelines that I do my best to follow in a team and I think it will lead you toward better software and a better work environment.

• Be the first to point out your failure
• Request constructive criticism
• Responsibility might be yours, even if the fault wasn't
• Carefully craft a process with your team. Commit to following it. Then commit to reevaluating it, often

‍

Methodology and Process

I've been the expensive training seminars. I've got the certificates printed on card-stock. I've worked side-by-side with some amazing dev managers. I can tell you first and foremost that there is no - one process to rule them all. Your project, developers, locations, languages, work schedules, consultants and even executive expectations may have an impact on your process. You're going to choose one - adapt it a bit - measure it and then fix it... all the time.

When your team fully agrees to follow a process as a test - knowing that deviating the process can ruin the test - they'll start to follow. IF and only IF they play an impactful part in reevaluating how that process went. If thats the case - you'll get your dev team's trust and with that comes valuable insight from the nerds in the trenches. When you are hearing individuals ask for help, point out their mishaps and requesting changes to the process - you're on the right path.

‍

Agile software development‍

I tend to gravitate towards - its focus on daily stand-up meetings, importance of QA and short feedback loops. The problem and the advantage here is that so many dev shops here have built upon this methodology that its hard to articulate what's agile and what's not. Which is why I tend not to get hung up on the term, but rather the functional process. Some examples of Agile methodology in practice are. Heck some people consider Scrum (below) to be a derivation of Agile.

• Lean Startup
• Feature Driven Development
• Kanban
• Extreme Programming
• Peer Programming
• and many many more.

‍

‍

Scrum software development

Scrum or often seen as SCRUM is a lightweight process that gives individuals a lot of freedom, but encourages co-location (in person) and mandates continual short check-ins. These short and frequent check-ins ( often called Stand-ups) are where this methodology gets its name. As rugby players frequently huddle in a "scrum".  It requires a "Scrum Master" to actively coordinate the process. I believe that SCRUM's emphasis on sprints and process management really lends itself to mobile app development. As QA is specifically hard, deployments and app reviews are a bottleneck and developing an app release schedule drives the cadence.

Waterfall software development

This one has gotten a bad rap lately - as its more rigid and less "agile" than others. However - in environments where things are highly linear/sequential it can be a good choice. As with any of these methodologies there are always things to learn. Often I tend to use a process similar to waterfall when creating a product from scratch. Then shift to an agile-style methodology when we have customers and feature requirements are coming in from all side. Things are no longer linear and sequential then and this method tends to not deliver results as quickly as others.

‍

‍