10 ways to be happy on an Agile project

Posted By on Nov 9, 2010


My Agile DragonBoat Team in Macau China

My Agile DragonBoat Team in Macau China

In the last few days, I’ve been getting messages with joyful and happy themes attached to them. I was then prompted to ask myself why some people are downright miserable working within an Agile framework, while many others would not have it any other way.  Thinking of various individuals from different teams and industries, I tried to decipher the observed patterns of those individuals who are sincerely happy in an Agile setting. What are the adopted behaviours, attitudes and the general state of mind of a happy Agile team member? I limited my brain dump to 10 high level points that seems to be a good starting point for anyone who chooses to take full advantage of an Agile project experience.

10. Don’t take yourself too seriously

If for some reason you break the application (build) and receive the “Cow of Shame” or have to put a buck in the pot, it’s no big deal. Dust yourself off, fix the problem and we move on.  See it as good natured ribbing and a fun way of saying:  “dude, you messed up” At some point, an agile team almost becomes a sort of family where all kinds of rituals appear to lighten up the environment and make work not quite seem like work.  Don’t get me wrong, not taking yourself too seriously doesn’t mean not taking your craft seriously.  Developers on mature agile teams are dead serious about their engineering practices.  But that doesn’t prevent Vicki from shooting her Nerf Vulcan Automatic Heavy Blaster when someone disrupts a deep refactoring Pomodoro 🙂

9. Help others get better

You’re the best programmer since Uncle Bob? Don’t keep it all to yourself. You’ll get that nice tingly feeling when sharing your wealth of knowledge.  You’re not certain how to go about it? Try pair programming. Take the wheel for while and then step aside.  Offer guidance, coaching and a “good job!” when deserved. Maybe you’ll find it way more gratifying to help others become better at their craft rather than being the hero all the time.

8. Try something different

You’re done?  That’s great! Is your team done? You could grab that task you would have never done under “normal” circumstances. This is your chance to assign yourself that business analysis task and  improve your overall understanding of the solution. Always wondered about that new UI technology? Go ahead! I dare you grab that funky Bootstrap task! It’s there, waiting for you! Why not? It’s fun!

7. Celebrate victories and defeats

Celebrating victories seems normal enough – but defeats?  Don’t we all learn more from our mistakes? If that’s the case, then why should we be sad about it?  If you just got through the iteration from hell and failed miserably, think of all learning experiences you’ve gained!  Flip the negative into a positive.  At the iteration retrospective, all those mistakes and blockers that caused the iteration to fail will be transformed into opportunities to make your life easier.  You, your team and your organization will have a clear action plan and will be held accountable in transforming the environment during the next iteration.  If that’s not worth celebrating, I don’t know what is!

6. Be honest

Agile projects are all about courage, transparency and honesty. “Inspect and adapt” just won’t work if you’re not honest with yourself and others. If you’ve been conditioned through the years to hide information to avoid being blasted, it might be difficult to drum up that courage.  You can start by allowing others to be honest and open. How? Don’t judge and don’t allow others to judge. Just listen and offer help because the next person needing help will be you.  In a healthy environment, being honest about your weaknesses and obstacles is considered a strength. If you try to hide, lie or cajole in the fully lighted context of an agile project, you will be miserable.  But once the stress of having to hide your blockers slowly evaporates this thing call happiness will most certainly set-in.

5. Collaborate

Move away from compromises and allow yourself collaborate with team members.  I know “win/win” is tacky and overused but it is where you want to be on an Agile project.   To even hope for this to happen, you need to want to find the right solution no matter who comes up with it. You need to be open minded, able to listen, wait, consider, consult (Bob Marshall) and temporally set aside your own views.

You’ve seen it a million times before and you clearly feel the need for State Machine design pattern for that specific functionality.  Two of your teammates feel it is overkill.  What is your reaction? Do you try to blind them with your experience and perfect knowledge of the GoF or do you listen, consider and have a truly open conversation?  This kinda stuff happens all the time with “performing” teams.

4. Avoid overtime

For an Agile coach, it’s great to work with individuals and teams that have an over-abundance of energy.  But too often, a lot of energy is spent on the wrong things or for the wrong reasons.  From my own experiences and from numerous observations, overtime equals to setting aside the Definition of DONE.

It’s 8pm on Thursday and this feature needs to be working and looking sexy for tomorrow’s Iteration Review….I’ll do the tests later.  Sounds familiar?

Over the top pressure and overtime to deliver ALL the planned features for a given iteration or project seems to give team members the “right” to consciently (or subconsciently) set aside all that needs to be DONE to deliver a quality product.  Untested and unmaintainable code translates to low quality software, unhappy clients and discouraged team members. Simply do less and do it better – In the end, you won’t burn yourself out and it’ll actually save your client some time and money.

3.  Generous interpretation

I first read about generous interpretation 5 or 6 years ago on Esther Derby’s blog and I’ve been using it ever since.  Courage, transparency and honesty on an Agile team is critical, but it can piss some people off.  At some point, someone will say something that will deeply offend you.  Instead of taking offense, generously interpret what was said.  Allow yourself to be sincerely convinced that whatever is said or done was done in best interest of the team, the project and the organization. Open up your mind to all that is positive in the behaviour of the people around you, no matter how bad that behaviour may be.  It’ll give you the opportunity to view the situation from a totally different angle. Psychologically, it’s a great place to be!

2. Get to know each other

As a coach, I love project kick-off activities!  In a Scrum setting, we often call this a Sprint 0.  A Sprint 0 goes beyond creating a project charter or Backlog; it’s also a team building activity.  Allow yourself to open up during this activity.  Share your passions, fears and ambitions.  Tell your teammates how you plan to make this project a success.  Once you get to know someone, you might be less willing to see him or her fail.  You might even set aside your own priorities and offer a helping hand.

If you’re on the IT side get to know the business and what drives them.  The same applies to you business folks.  Those individuals building your software are probably a pretty bright bunch! If given a chance, they might even set aside all that “abstract class polymorphism” mumbo jumbo and offer you a fresh view to your requirements.  Take it one step further and start recognizing the non-verbal signs. For example, when Bob takes off his glasses, it usually means that business requirements are not clear in his head.  At this point you might give him a couple of minutes to think it over instead of pounding him with additional questions.

1. Be congruent with your values

Are your actions defined from the inside out or the outside in? (I forget where I read that). In other words, are your choices inspired by your values or do you accept whatever comes your way and adjust accordingly?

No matter how you go about life, I would strongly suggest you take the time to reflect on your personal and professional values and before jumping into an Agile team – Even more so if you are presently miserable on your Agile project.  I would also compare those values and principles to those of the Agile Manifesto and see if they are deeply at odds with each other.  If they are, maybe the only way to be happy at work will be to steer clear from such a project.  On the other hand, if you recognize yourself and share a common vision of the world of work, you most definitely will have an amazing experience.

Cheers!

Submit a Comment