{"id":937,"date":"2010-11-09T18:41:25","date_gmt":"2010-11-09T18:41:25","guid":{"rendered":"http:\/\/agilepartnership.com\/?p=333"},"modified":"2010-11-09T18:41:25","modified_gmt":"2010-11-09T18:41:25","slug":"10-ways-to-be-happy-on-an-agile-project","status":"publish","type":"post","link":"https:\/\/agilepartnership.com\/fr\/10-ways-to-be-happy-on-an-agile-project\/","title":{"rendered":"10 ways to be happy on an Agile project"},"content":{"rendered":"
\"My<\/a>
My Agile DragonBoat Team in Macau China<\/figcaption><\/figure>\n

In the last few days, I\u2019ve been getting messages with joyful and happy themes attached to them.\u00a0I 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.\u00a0 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.<\/p>\n

10. Don\u2019t take yourself too seriously<\/strong><\/p>\n

If for some reason you break the application (build) and receive the \u201cCow of Shame<\/a>\u201d or have to put a buck in the pot, it\u2019s no big deal. Dust yourself off, fix the problem and we move on.\u00a0 See it as good natured ribbing and a fun way of saying:\u00a0 \u201cdude, you messed up\u201d 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.\u00a0 Don\u2019t get me wrong, not taking yourself too seriously doesn\u2019t mean not taking your craft seriously.\u00a0 Developers on mature agile teams are dead serious about their engineering practices.\u00a0 But that doesn\u2019t prevent Vicki from shooting her Nerf Vulcan Automatic Heavy Blaster<\/a> when someone disrupts a deep refactoring Pomodoro<\/a> \ud83d\ude42<\/p>\n

9. Help others get better<\/strong><\/p>\n

You\u2019re the best programmer since Uncle Bob<\/a>? Don\u2019t keep it all to yourself. You\u2019ll get that nice tingly feeling when sharing your wealth of knowledge.\u00a0 You\u2019re not certain how to go about it? Try pair programming. Take the wheel for while and then step aside.\u00a0 Offer guidance, coaching and a \u201cgood job!\u201d when deserved. Maybe you\u2019ll find it way more gratifying to help others become better at their craft rather than being the hero all the time.<\/p>\n

8. Try something different<\/strong><\/p>\n

You\u2019re done?\u00a0 That\u2019s great! Is your team done? You could grab that task you would have never done under \u201cnormal\u201d circumstances. This is your chance to assign yourself that business analysis task and\u00a0 improve your overall understanding of the solution. Always wondered about that new UI technology? Go ahead! I dare you grab that funky Bootstrap<\/a> task! It\u2019s there, waiting for you! Why not? It\u2019s fun!<\/p>\n

7. Celebrate victories and defeats<\/strong><\/p>\n

Celebrating victories seems normal enough \u2013 but defeats?\u00a0 Don\u2019t we all learn more from our mistakes? If that\u2019s the case, then why should we be sad about it?\u00a0 If you just got through the iteration from hell and failed miserably, think of all learning experiences you\u2019ve gained!\u00a0 Flip the negative into a positive.\u00a0 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.\u00a0 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.\u00a0 If that\u2019s not worth celebrating, I don\u2019t know what is!<\/p>\n

6. Be honest<\/strong><\/p>\n

Agile projects are all about courage, transparency and honesty. \u201cInspect and adapt\u201d just won\u2019t work if you\u2019re not honest with yourself and others. If you\u2019ve been conditioned through the years to hide information to avoid being blasted, it might be difficult to drum up that courage.\u00a0 You can start by allowing others to be honest and open. How? Don\u2019t judge and don\u2019t allow others to judge. Just listen and offer help because the next person needing help will be you.\u00a0 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.\u00a0 But once the stress of having to hide your blockers slowly evaporates this thing call happiness will most certainly set-in.<\/p>\n

5. Collaborate <\/strong><\/p>\n

Move away from compromises and allow yourself collaborate with team members.\u00a0 I know \u201cwin\/win\u201d is tacky and overused but it is where you want to be on an Agile project. \u00a0\u00a0To 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<\/a>) and temporally set aside your own views.<\/p>\n

You\u2019ve seen it a million times before and you clearly feel the need for State Machine design pattern for that specific functionality. \u00a0Two of your teammates feel it is overkill.\u00a0 What is your reaction? Do you try to blind them with your experience and perfect knowledge of the GoF<\/a> or do you listen, consider and have a truly open conversation?\u00a0 This kinda stuff happens all the time with \u201cperforming\u201d teams.<\/p>\n

4. Avoid overtime<\/strong><\/p>\n

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

It\u2019s 8pm on Thursday and this feature needs to be working and looking sexy for tomorrow\u2019s Iteration Review….I\u2019ll do the tests later.\u00a0 Sounds familiar?<\/p>\n

Over the top pressure and overtime to deliver ALL the planned features for a given iteration or project seems to give team members the \u201cright\u201d to consciently (or subconsciently) set aside all that needs to be DONE to deliver a quality product.\u00a0 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\u2019t burn yourself out and it\u2019ll actually save your client some time and money.<\/p>\n

3.\u00a0 Generous interpretation<\/strong><\/p>\n

I first read about generous interpretation 5 or 6 years ago on Esther Derby\u2019s blog and I\u2019ve been using it ever since.\u00a0 Courage, transparency and honesty on an Agile team is critical, but it can piss some people off.\u00a0 At some point, someone will say something that will deeply offend you.\u00a0 Instead of taking offense, generously interpret what was said.\u00a0 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.\u00a0 It\u2019ll give you the opportunity to view the situation from a totally different angle. Psychologically, it\u2019s a great place to be!<\/p>\n

2. Get to know each other<\/strong><\/p>\n

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

If you\u2019re on the IT side get to know the business and what drives them.\u00a0 The same applies to you business folks.\u00a0 Those individuals building your software are probably a pretty bright bunch! If given a chance, they might even set aside all that \u201cabstract class polymorphism\u201d mumbo jumbo and offer you a fresh view to your requirements.\u00a0 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.\u00a0 At this point you might give him a couple of minutes to think it over instead of pounding him with additional questions.<\/p>\n

1. Be congruent\u00a0with your values<\/strong><\/p>\n

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?<\/p>\n

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.\u00a0 I would also compare those values and principles to those of the Agile Manifesto<\/a> and see if they are deeply at odds with each other.\u00a0 If they are, maybe the only way to be happy at work will be to steer clear from such a project.\u00a0 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.<\/p>\n

Cheers!<\/p>","protected":false},"excerpt":{"rendered":"

In the last few days, I\u2019ve been getting messages with joyful and happy themes attached to them.\u00a0I 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.\u00a0 Thinking of various individuals from different teams and industries, I tried […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[17,22,18],"tags":[],"class_list":["post-937","post","type-post","status-publish","format-standard","hentry","category-agile","category-coaching","category-scrum"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/agilepartnership.com\/fr\/wp-json\/wp\/v2\/posts\/937","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/agilepartnership.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/agilepartnership.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/agilepartnership.com\/fr\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/agilepartnership.com\/fr\/wp-json\/wp\/v2\/comments?post=937"}],"version-history":[{"count":0,"href":"https:\/\/agilepartnership.com\/fr\/wp-json\/wp\/v2\/posts\/937\/revisions"}],"wp:attachment":[{"href":"https:\/\/agilepartnership.com\/fr\/wp-json\/wp\/v2\/media?parent=937"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/agilepartnership.com\/fr\/wp-json\/wp\/v2\/categories?post=937"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/agilepartnership.com\/fr\/wp-json\/wp\/v2\/tags?post=937"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}