{"id":43668,"date":"2018-01-16T04:50:09","date_gmt":"2018-01-16T11:50:09","guid":{"rendered":"http:\/\/www.taterboy.com\/blog\/2018\/01\/agile-teams-are-fragile-things\/"},"modified":"2018-01-16T04:50:09","modified_gmt":"2018-01-16T11:50:09","slug":"agile-teams-are-fragile-things","status":"publish","type":"post","link":"https:\/\/www.taterboy.com\/blog\/2018\/01\/agile-teams-are-fragile-things\/","title":{"rendered":"Agile Teams are Fragile Things"},"content":{"rendered":"

Many companies seek salvation through Agile. They have heard about the transformative power that Agile brings, they hear a good sales pitch, and the company is all in. They work to change all their technology teams over to an Agile\u00a0process.<\/p>\n

\"\"
Team dysfunction can derail products whether that team is running Agile or Waterfall.<\/figcaption><\/figure>\n

It makes sense. Waterfall has some severe problems. It is a ballistic process. You define a target, you aim, and you fire. Success depends on how well you aimed at the very beginning. There is no changing once you start the project. Sure you can be successful, but the odds are low because the target is moving and usually not in ways that you can anticipate.<\/p>\n

Agile on the other hand, is dynamic. It craves feedback. When the landscape changes around the product launch, the product can change too, as it should. The Agile principles all make sense and sound great. It\u2019s an easy\u00a0sell.<\/p>\n

So then why do companies that introduce Agile still struggle? I have no doubt that some companies implement Agile incorrectly. I know that many companies and their employees don\u2019t truly buy in. But even if they buy in and run the Agile process right, I think many companies have a different problem altogether.<\/p>\n

Agile Teams<\/strong><\/p>\n

The unit of performance in Agile is the team. To take one example<\/a> of a definition, an Agile team is \u201ca cross-functional group of people that have everything, and everyone, necessary to produce a working, tested increment of product.\u201d This is a solid definition and most companies can get this part right. They focus on getting a cross-functional team and make sure to get a Scrum Master that can get the team everything they need to focus on delivering results. From here, it is expected that everything else will go smoothly.<\/p>\n

In the book the Wisdom of Teams<\/em>, the authors Douglas Burnet Smith and Jon Katzenbach* define a team a bit differently. They say that a team is \u201ca small number of people with complementary skills who are committed to a common purpose, performance goals, and approach for which they hold themselves mutually accountable.\u201d There is certainly overlap, but this shows a clear gap in the Agile team definition.<\/p>\n

The Agile team is about putting cross-functional people together and clearing the way for them to work. And in both definitions, the team takes responsibility for\u00a0results.<\/p>\n

High-performing teams, however, do more than that. They buy in to the purpose of the project. They have deep, intrinsic motivation for helping. The goals set are goals for the team. The team wants to hit results. Other books<\/a> about high-performing teams talk about teammates committing to a purpose that is bigger than the individual. They talk about trust and commitment. This is all missing from the Agile definition of a team. This is not the fault of Agile, and it\u2019s not a problem with Agile. Agile is trying to redefine the project management approach. This is a problem with the companies that are trying to implement Agile.<\/p>\n

A Sense of\u00a0Purpose<\/strong><\/p>\n

In User Experience Design we are taught early and often about the importance of talking with users and hearing about their experiences. If we learn their goals, their needs, and their pain points, we can deliver solutions for\u00a0them.<\/p>\n

Beyond that, there is an additional benefit of talking with customers. We develop a sense of purpose for the success of the product. The impact is tangible. We see how much users struggle with what they have and if we are successful how much it improves their lives. This helps the UX team build a focus that is greater than individual achievement.<\/p>\n

It doesn\u2019t mean that every UX designer is interested only in the greater good of user success. There are surely designers out there that are trying to be heroes. But we do have much better access to the why behind our products. When we talk about being advocates for the user, that\u2019s because we have seen the struggle. We fight passionately for user needs because we have sat side-by-side with users as they show their frustration using our products.<\/p>\n

But what about the people on the team who don\u2019t have that intimate connection? Where do they derive the sense of purpose for the product? If you work for a large company, you might not get to choose what product team you work on. It\u2019s that much harder to buy-in if you didn\u2019t choose what you get to work on and you don\u2019t get to see what impact it has on the users. The users just become some intangible entity that you are wholly disconnected from. What drives the motivations to deliver good products\u00a0then?<\/p>\n

\"\"
Rewarding for individual performance can have a negative impact on team performance.<\/figcaption><\/figure>\n

Most companies try to motivate good performance through a reward structure. If an employee does good work, they get raises and bonuses and promotions. Unfortunately, this set up is in direct conflict with the principles of high-performing teams.<\/p>\n

High performing teams care more about the team than the individuals on the team. This can be tough to manifest when companies pit individuals against one another to get promotions and bonuses. While each person may be on a team, they are rewarded as individuals. Those individuals who perform the best advance; those who don\u2019t, won\u2019t. Given this environment where there are too few slots for too many workers, people move companies every 2\u20133 years seeking that next promotion, that next raise, that bigger bonus. In no way is this beneficial to the\u00a0team.<\/p>\n

In his book Punished By Rewards<\/em>, Alfie Kohn argues that the traditional model of incentivizing individuals for performance has become a detriment to teams and company performance. Incentives (an extrinsic motivation) have been shown to decrease intrinsic motivation. People stop caring about what they are delivering?\u2014?they only deliver to get rewarded. And when people are forced to compete for rewards in the form of bonuses and performances, those who lose out lose motivation to help the team. It turns into a real lose-lose situation. Those that advance are slowly stripped of their intrinsic motivation because of the rewards, while those that do not are discouraged because they have been passed over. Whether the person is promoted or not, actual motivation to deliver great products decreases. And while individuals may succeed, ultimately, the user\u00a0suffers.<\/p>\n

It should also come as no surprise that many people don\u2019t get to choose whether they work using Agile. It is handed down to them from upper management. In large corporations, most technology teams are 2\u20133 org chart steps away from the decision being made. There is no debate. They are told that they will be doing Agile. Again, it\u2019s difficult to jump into something wholeheartedly when the decision is handed to you with no discussion. This is starting things off on the wrong\u00a0foot.<\/p>\n

And while it\u2019s difficult having decisions forced upon you, most people are willing to go along with a decision if they felt their voice has been heard. Do people get this opportunity in large organizations? From what I have seen, the answer is no. People may voice their displeasure, but usually not with the decision-makers (usually the Agile Trainers bare the brunt of\u00a0this).<\/p>\n

I have never seen anyone actively working against the interest of the team. I do believe that most people care about doing good work. But individuals working their best does not make for a great team. It takes more than that, and most organizations I have seen do not create an environment for high-performing teams to\u00a0prosper.<\/p>\n

In my career, I have only seen Agile running in a highly effective manner once. (This spans working at several companies and interacting with other Agile teams as a UX consultant. In my current role, I am not on an Agile team). I don\u2019t think it\u2019s a coincidence that this company focused heavily on the team component. It was a flat organization<\/a>, which means that people weren\u2019t trying to fight their way up the org chart. People earned their next title when they were qualified for it, not when a spot opened up. At this company, we worked hard on being open with one another and having the conversations we needed to have in order to deliver results for the customer. Delivering great products was the purpose, and with everything else out of the way we could focus on that. Of the other organizations I am familiar with that did not embrace this approach, they all struggled with Agile or so no tangible\u00a0benefit.<\/p>\n

I support the move to Agile. I have seen it work well and have seen it add value. But many companies assume it is a panacea that can address any ill they have. When a company shifts to Agile, and the agile team fails the common response is to blame \u2018Agile\u2019. I think people need to start looking more closely at the \u2018team\u2019 part of the equation. Often the fault lies\u00a0within.<\/p>\n

*For the record, this is the second <\/em>article<\/em><\/a> in a row I\u2019ve talked about this book. I\u2019ve been studying teams for another project\u00a0lately.<\/em><\/p>\n

<\/p>\n

Powered by WPeMatico<\/a><\/small><\/p>\n","protected":false},"excerpt":{"rendered":"

Many companies seek salvation through Agile. They have heard about the transformative power that Agile brings, they hear a good sales pitch, and the company is all in. They work to change all their technology teams over to an Agile\u00a0process. Team dysfunction can derail products whether that team is running Agile or Waterfall. It makes… Read the full article…<\/a><\/p>\n","protected":false},"author":4,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"jetpack_post_was_ever_published":false},"categories":[15],"tags":[],"class_list":["post-43668","post","type-post","status-publish","format-standard","hentry","category-general-info"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t