Tag archive

team building

What Does Every Agile Development Team Want?

in Agile/Agile Engineering by

Win! Duh, Winning!

Okay, I know that is so 2011. But it is only human nature to want to not be put in a losing position, in fact we talk a lot about winning. We are naturally competitive, some folks more so than others — you know who you are. This may be an evolutionary thing because of our need to be adaptive. I’m not saying we are totally dog-eat-dog. We like to be able to look back and see that we did our best or that we delivered the best as a team. In my opinion, we win when we meet or deliver beyond our own expectations as well as the expectations that we helped others to set.

As an agile development team, when we set commitments at the beginning of the iteration, we are setting expectations to win. If we miss our commitments — clearly we are not winning. This sometimes can be compounded when teams don’t even try to innovate and adapt in an effort to overcome our missed commitments. In these cases they are complacent, and they quit trying to get better, which means they clearly are not going to win. My guess is that most people on these teams are not very happy, and especially not happy to be on a losing team.

Let’s face it, winning is hard. Outsiders (a.k.a. stakeholders including customers, executives, management, and other teams) will levy expectations upon us and the team, many times these expectations seem unrealistic and, at times, seem maliciously imposed. Also, in order to win, you sometimes have to lose — winning takes practice, which means you and your team will likely fail before you win. Often winning is hard because we are trying to do so as a team. Becoming a team is a whole blog on it’s own; however, remember that in Agile we measure outcomes based on the team. So we win and lose together.

I am not really the one to ask about winning and I know there is not one single formula to winning. That being said, I have made some observations of winning teams, they are:

Set Proper Expectations. I think this goes without saying, we’ve talked about it before — part of being successful means setting the right expectations and having all the right parties in the room to agree together on expectations. This doesn’t mean that at times we shouldn’t stretch ourselves to be better, but the rules of winning should be agreed upon before we try to win.

Be Consistent. Now, you can consistently lose, but we are not primarily talking about losing here. When I say “be consistent,” maybe I should say “establish consistency.” In that we should establish consistency in both the Demand side and Supply side of the delivery equation. Smoothing out peaks and valleys improves the likelihood of meeting shared expectations and making the act of setting shared expectations easier.

Try. If you don’t try, you can’t win — ’nuff said. Well, let’s be a little more specific. Teams that don’t try to set the right expectations, or teams that waiver from their end goal because they are not on board simply will not win. These are the teams that are often the superheroes and they’ll end up within Sprint Burndowns that never reach zero.

Rely on Strengths of Team Members. Everyone on a team has different skills and strengths — both tangible and intangible. Although it is sometimes good to work outside your comfort zone so that you can develop, when teams constantly do this or team members take on activities that reside more in their weakness zone, it’s really hard to get things done and meet expectations. Try creating a skills catalog for your team and try out Strengths Finder. Doing this together and making it visible helps team members to put themselves and others in positions to win.

Embrace Adversity and Diversity. We should not only embrace adversity (a.k.a. challenges and failures), we should also embrace diversity (a.k.a. team member differences). When something goes wrong, it should always be a learning experience, even if that learning is, “we shouldn’t do that again.” A team that picks themselves up after failure and moves on is generally a stronger team in the end. From a diversity perspective, with Agile teams we look to build cross-functional expertise. Well, it’s also good to build cross-cultural teams. I’m not talking about putting someone on a team who is totally a bad fit, but instead — introduce a team member that will bring new ideas and approaches to solve a problem. Plus, with diversity generally comes new experiences — which is usually a good thing.

Tennis PracticePractice. It goes without saying, you don’t get good at something without some practice — look at professional sports teams. Yes, there are those of us who are naturals at certain things — but even the naturals need to practice. When we practice, we learn – we learn new ways, better ways, and ways not to do something. Yes, we might experience beginners luck every-now-and-then; however, by practicing what is often unnatural to us becomes natural — then we can focus on the next level of challenges.

Apply New Techniques and Tools. As we practice, we should always be looking to find a new way to do something or seek out opportunities to improve some aspect of what we do with tools. Although I work for a tool vendor, I’ll be the first to say that tools don’t always solve a teams problems — people have to solve the problem. But tools and new techniques can improve the way we do something or make a solution more reachable. Not to mention, new techniques and tools can make solutions more effective and efficient.

Put Our Best Foot Forward. Simply put, don’t put anything out there unless it is something you would put your name on and parade it in front of the world. A team I once worked with used to have “Good Code, Bad Code” sessions. This was a community of practice meeting where the developers would present examples of either good code or bad code. The author of the code generally remained anonymous; however, you were really nervous that it might be your code about to flash up on the screen as an example of bad code.  This type of discussion really forced everyone to raise their game, but at the same time if your code was brought up — you had the opportunity to discuss the circumstances and understand a different way.  Nonetheless, you always tried to put your best foot forward.

So those are the observations and experiences I’ve had around winning teams. In your experience, what makes up winning teams? Or, is something I said something you agree or disagree with? I really think teams want to be successful, it’s human nature. It doesn’t mean we always have to win, but it sure is fun and everything is easier.

Loving Me Some RSA Animate – Motivation

in Agile Engineering by

A large part of agile and making it really work is the people.  In fact, the organization can only support and foster the right mind-set through the behaviors of the leaders and the “walk-the-talk” mantra.  Ultimately the success of agile and the organization are the people associated with it. Thus, bringing me to the viral videos from RSA Animate.  RSA is an organisation that aims to trigger thoughts and share ideas — some are very clear and common sensical, while others concepts they discuss can be controversial and much deeper.  In all, they’ve published docs, videos, and held conferences that bring ideas and enlightenment forward.

Which brings me to a one of my favorites that I share constantly during agile training sessions – Dan Pink’s discussion on motivation. This discussion is based on Dan Pink’s book Drive, it is a fairly quick read and reasonably priced on Kindle.

[amazon_enhanced asin=”B004P1JDJO” container=”” container_class=”” price=”All” background_color=”FFFFFF” link_color=”000000″ text_color=”AC0020″ /]

Where’s the Incompetence?

in Agile Engineering by

Scrum is no silver bullet, and that it does not bring out excellence, but exposes incompetence.
— Ken Schwaber

So this is a great quote and it really resonates with any organization that is implementing scrum.  What you will inevitably find while implementing scrum is that certain team members and more importantly team functions and or departments are just not able to get the job done, or simply incompetent.  Maybe incompetent is not the best choice of words, but what I’ve found is that those people or departments that are asked to do something different, maybe step-up, or simply be around — stick out quickly when they are not performing well.  Within larger organizations, it’s not too uncommon to have team members that are able to hide and do just enough to skate by — this doesn’t work well within Scrum teams.

Weak LinkThe analogy to the weakest link in the chain is a great one for understanding the impact of a person or team that is not strong enough or capable of delivering on commitments made.  Just like a chain where the sound links of the chain can absorb the stress for a period of time, eventually the weak link breaks, the chain fails, and repairs must be made.  With implementing scrum, the level of stress remains constant and steady; thus, in short period the weak links appear.  When they do, preventive action should be made promptly to keep the chain, I mean the team, from failing.

So, what can be done?  Here are a few ideas that may work for your team:

  • Process Training.  This one is a lay-up.  Sit down with the team member or department head(s) to discuss their level of understanding regarding the Scrum process, how agile changes impact them, and how they can benefit from being part of the changes.  Identify opportunities for core agile process training, tool training, or possible soft skill training.
  • Identify the Strengths.  Often when a team member or department is failing, it is because they are working outside their strengths.  This does not mean that you change the team member or departments responsibilities, but it does mean that you might consider identifying ways for the team member or department to get their commitments complete while leveraging what they do well.  I wrote a previous blog about Strengths Finder, this is a great exercise for all teams — this will help a team to self-organize to ensure everyone can be successful.
  • The Team Adjusts.  Since the Scrum Team is cross-functional, identify ways that the weaker team member can meet their commitments.  This may be through have a team member move from developing core functionality to assisting QA on building out a test harness or possibly a QA team member working on documentation.  Often, when a team member is not performing well, it often ruins their self-confidence and this lack of success will continue.  Find tasks that the team member can be successful, get them some small wins, and see if that improves their outlook and inevitably their ability to perform.
  • Make the Hard Decision.  It may come to a point where a team member is just not cutting it, or because of their inability to meet commitments — they are bringing down the rest of the team.  It may be time to for a significant change — and a need to release the team member.  This is often better for the team, the individual, and the organization.  It is a hard decision, but one that needs to be made.  Allowing a non-performing team member to continue with the team and not meet commitments sends the wrong message to the rest of the team, and the Product Owner will start questioning the leadership of the team.  If it is a department that is not performing, it may be time to face this head-on and escalate the need to get better performance from that department.

Self-Organizing and Strengths Finder

in Agile Engineering/Product Management by

Team WorkA key part of any good team, especially an agile team, is teamwork and more importantly a team of hardworking individuals that both care about their teammates and they understand the strengths of their fellow teammates.  In the sporting world you will often hear of situations where one player will attempt to play outside his strengths.  Or what is more prevalent, a player has an outstanding year due to either scheme or competition or simply a well formed team that emphasizes the strengths of the players.  Then that player is a free-agent and goes to another team, and the player’s career sags.  This is primarily due to familiarity, chemistry, and scheme that doesn’t fit the strengths of the player.

There is a concept that surrounds Scrum teams and that is the concept of “self-organizing” team.  Now this concept is often not clearly defined and depending on the Agile coach and or trainer, a team member might view this differently (see Does Self Organizing Team Imply Self Assembly?) .  Nonetheless, if we define self-organizing in the simplest form of a team that has the ability to take inputs and based on knowing certain attributes of their fellow team members, work is doled out, people are paired up, issues are worked out, team members are brought in and pushed out, and, in summary, things just start getting done and done effectively.

The “certain attributes” that a team uses for team self-organization often includes:

  • Team member workload
  • Technical background
  • Domain expertise
  • Team member availability
  • Understanding of the tasks-at-hand
  • Priority of tasks
  • Team member “likes”
  • Team member weaknesses
  • Team member strengths

Of course, all of these are important to consider; however, one would argue that the strengths are where all self-organizing should be focused.  As you guessed it, I’m the one to make this argument – and I encourage everyone who runs any type of team to take advantage of Clifton StrengthsFinder from the Gallup News organization (yes, that’s the same Gallup that does many politico and social polls).   StrengthsFinder came about from Dr. David Clifton – he is known as the father of Strengths Psychology.  The focus of StrengthsFinder is to help people identify their top five strenghts where they work best, understand these strengths, and see how focusing on using these strengths versus working on improving areas of weaknesses is much more productive, self-rewarding, and ultimately successful.

Some have grouped StrengthsFinder into the area of self-help or lumped it with personality tests such as Meyers-Briggs Type Indicator.  It is definitely not a personality test and if you did want to categorize it as self-help, you will find it to be much, much better and more effective than any other self-help book or tool.  When I was approached by a colleague that went through the StrengthsFinder exercise and he express the passion that this is for real and fulfilling, I was convinced I had to give it a go.  So after I took the 30 minute survey and got my results, I quickly learned and understood better why I say, do, and act certain ways.  It helped me rationalize and focus my energies within the areas of my strengths so that I can help my team and the company become more successful.  This didn’t mean I wouldn’t ever work on improving my weaknesses, but it did help me recognize where I can use my strengths to overcome or disguise my weaknesses.

So, you are now asking, why does this have anything to do with Self-Organizing agile teams.  Well, soon after going through the exercise myself, Dave (my colleague mentioned above) implored me to have our whole product development team go through the survey – we did.  After everyone had their top five strengths, we compiled the list and posted it on our team wiki.  We all sat down and discussed what we learned about ourselves and reflected on the strengths of others.

At the time when we did this exercise, we were about ten months into using a Scrum agile methodology.   We had earlier delivered a huge product release and we were coming off a really tough period where everyone was getting burned out by the product launch, supporting new customers, and having some frustrating issues largely due to incomplete quality processes.   Soon after experiencing StrengthsFinder, we saw that the team which would normally “mouse-up” during difficult team discussions, would start leaning on each other strengths.  This helped me as the team lead, to simply sit back and let the team work through challenges that when previously encountered, the team would simply brush under the rug.  Going through StrengthsFinder seemed to give the entire team more confidence and it helped those team members that would often simply focus on trying to improve their weaknesses to instead, embrace their strengths and take on the tasks that best suit them.   Not only would they have more self-confidence, but they also embraced the strengths of their peers.  When we would start new feature or enhancement development, the team members often signed quickly and they would ask a fellow team member that may have been stronger in another area to assist (e.g. using a person that has the Relator strength to interview subject matter experts).

Within two months after working through StregnthsFinders, we experienced measurable quality improvements and we moved closer to a self-organizing team where anyone on the team could lead within their strengths.

So if you are working within an Agile team and you are struggling with the “self-organizing” aspects or your team has hit a continuous improvement plateau, give Clifton StrengthsFinder 2.0 a try.  The books required can be obtained for less than $13 at Amazon or Borders.

Five Ways to Establish Trust

in Agile Engineering/Product Management by

As everyone knows, a key success factor of an agile process implementation, specifically Scrum, is establishing trust between the team delivering and those waiting on the delivery (basically between the product development team and the business).  In order to establish trust, a development team should be meeting their commitments made during the planning meetings; thus, delivering what they said they would.  Sounds like a pretty simple formula and for the most part — it is.

Never trust the teller. Trust the tale.
– DH Lawrence

Outside of simply delivering what you said you would in a sprint, here are five ideas to establish trust:

  1. Always act with integrity. It goes without saying, truth sets you free.  But what is more than simply being honest while communicating with someone, but it is more important to perform your job duties with integrity.  This means, no cutting corners, maintain the utmost quality, and always keeping the team informed when it comes to matters that may impact the core deliveries.
  2. Ask questions and share information. Make sure that if an idea is not understood, be sure to not be afraid to ask a question (sometimes, the first thing that comes out the mouth is “I don’t know”). Be sure not to assume you are all-knowing about an issue, so share what you know — this is an excellent way to facilitate conversation and potentially discover what you don’t know.
  3. Reasonably accurate expectations (estimates to complete). In the agile world, estimation can be challenging.  This is primarily due to the lack of data present at the beginning of tasks.  The easy way to overcome this and become more accurate with your estimation is to be sure to break down stories into common development tasks.  This may include an analysis, design, build out, unit test, etc type task.  I also like the proto-type, stub, or even the sub-functional task where a small piece of functionality is implemented.  Estimates generally get better the smaller the task and they are of course better when more than one person sets the estimate (leveraging the experiences of others will help).  Finally, always accurately update estimates to complete daily.
  4. Deliver within the boundries of the commitment. Simply stated, don’t always try to be a hero and deliver beyond the expectations of the original commitment. This can be viewed by management (be it product or development) as sand bagging estimates, or simply going rogue and “doing as you want to”. Not to say that finding a great way to do something that was much more productive is not a good thing or seeing that you can do a lot more within the context of the product functional area is not appreciated. But the right way to handle this is to disclose that you found a faster way to do something and your estimate-to-complete is much less than orginally anticipated, so you would like to work on another key capability that is similar to the functionality being implemented. Negotiating this within the context of the daily standup (and possibly within a follow up meeting) would be the correct course of action.
  5. Consistency is key.  Having one good sprint is not enough, a team needs to establish a trend of delivering on sprint tasks on a consistent basis.  This applies to the team as well as the individual.  Once a team is able to demonstrate a consistent trend surrounding capacity, story points delivered, hours worked, etc — the product stakeholders can start to reasonably expect that what the team says they will finish will in fact be delivered.

Remember the idea of trust should also exist within the scrum team and between scrum teams where there is a need to share deliverables or even if you all work within the same development organization. The five ideas above should be applicable to ensuring that all scrum teams work well together and within the overall scope of an organization.

What techniques or ideas do you have about how to build trust with the product management or project stakeholders?  What have you’ve done that works?

Go to Top