Rusty Divine

Live, Love, Learn, Teach

Agile Principles Exercise

Earlier this week our project manager, Keil, asked us to review the Agile Principles and pick one that we felt was most important to our project at this time, then justify our choice. We emailed him our results without talking to each other.

Today the development team (9 of us, including Keil) met to talk about what everyone picked. Our choices were scattered, but our rationales converged on the importance of getting working software in front of the end users to get quick feedback and promote trust between our two groups.

It was interesting that similar justifications could be made for so many of the different principles. Keil then showed the responses from the end users* and there was only some overlap with their choices, and their rationale converged on the importance of trust between our two groups – trusting us to deliver quality and expected functionality.

One of the dev team remarked that the end users’ chosen principles were less technically focused overall than the developers. I hadn’t realized it, but some of the principles do seem to be more technically focused while others are people-or-process-focused.

The only principle that more than one of the devs picked, “Simplicity--the art of maximizing the amount of work not done--is essential,” was not chosen by any of the end users. Coincidentally, we’re currently hashing out a new feature request from the end users that the dev team feels may be over-complicated while the end users are persistent in the request for it. There’s a related post about this on Keil’s blog.

I’ve been thinking about the agile principles and how to apply them to the disc golf app Adam and I are working on. It’s been a struggle to tailor the process that is appropriate for a project where we can apply 8 hours a week between us to it. I’ll post something on that later, along with some of the input Keil has on what we’re doing now.

 

*We’re fortunate to be able to work with our end users every day because they are directly down the hall from us, so getting feed back is very quick and relatively easy for our team.

Remember to set the Target Framework

This is the second time in a few weeks where I have had a wtf? moment caused by not setting the Target Framework for a new project to the correct version.

Today it was missing an EmailAddress data annotation from the System.ComponentModel.DataAnnotations reference. I know the EmailAddress annotation should be part of that library, and my reference showed the correct library version (4.0.30319), but the EmailAddress just sat there with that red squiggly line mocking me.

Until I remembered to update my Target Framework from .NET Framework 4.0 to .Net Framework 4.5.

TargetFramework

Team Geek

Team Geek: A Software Developer's Guide to Working Well with Others, by Brian W. Fitzpatrick and Ben Collins-Sussman.

The Big Idea:

Humility, Respect, and Trust – HeaRT – are what it takes to be a great person and team member, in fact, it’s what is going to make or break your career.

Humility: Be open to self improvement and being wrong. Seek out other opinions and treat them fairly. Lose the ego – don’t comment on every discussion, be willing to conform some so that you don’t spend energy struggling against the system, and learn to take criticism.

Respect: Care about other people and their emotions. Appreciate their abilities and accomplishments.

Trust: Lead with believing people will do the right thing and want to do it well. Let yourself be vulnerable and trust that your team will not harm you.

Book Notes

Gone are the days of the Genius Programmer in a private office churning out code or technical specifications isolated and uninterrupted. Today we expect our teams to communicate continuously, be open to alternative ideas, and to put the code before themselves – you are not your code.

The authors state that “Almost every social conflict can ultimately be traced back to a lack of humility, respect, or trust.”

A manager needs to make it obvious that she trusts her employee and the employee will feel positive pressure to live up to that trust.

“The best advice we got when we first became engineering managers at Google was from Steve Vinter, an engineering director. He said, ‘Above all, resist the urge to manage.’” The authors believe the most important thing a manager can do is to serve her team.

Managers, don’t:

  • Ignore low performers
  • Ignore human issues
  • Be everyone’s friend
  • Compromise the hiring bar
  • Treat your team like children

“The engineer asking for advice typically doesn’t want you to solve his problem, but rather to help him solve it, and the easiest way to do this is to ask him questions.” Knowing the right question can be better than knowing the answer.

Managers need to shield their teams from chaos. Keep the second guessing, power struggles, budget concerns, and other external drama away from the team. This can be very difficult if you have a good relationship with your team, but it’s important to separate your responsibility to protect the team morale from your urge to be transparent with them.

“If you have six kids and give each one the same amount of water, light, and fertilizer, they’ll all get equal treatment, but the odds are good that none of them will get what they actually need.”

Engineers crave autonomy, mastery, and purpose.

On difficult team members

Try not to think in terms of bad apples, but in bad behaviors. It’s the behaviors you want to filter out, not the people. “If, after repeated warnings, the behavior doesn’t change, only then does it makes sense to consider formal rejection.” Will the project still benefit in the long run with this person who exhibits bad behavior?

Managers need to be intolerant of destructive behaviors, and explicit about the team approaching each other with HRT.

On Communication

A good email is short. If you need something from the reader, it should be three bullet points or less and one – and only one – request.