Tag archive

team work

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.

Words Mean Things – Inspect & Adapt

in Agile/Project Management/Teams by

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.Agile Manifesto (agilemanifesto.org)

In case you weren’t aware, this is the 12th Principle of the Agile Manifesto and it is often translated into “inspect & adapt.” Of the twelve principles, this is definitely the one that everyone can easily relate to. The team should look at what they are doing, look at how they are doing, and adjust. This is primarily for the team and I would argue that it’s mostly about the process (and maybe people stuff), but it could be around the product and or project if we are doing this in respect to a specific release or even the outcome of the sprint.

With Scrum, there is a ceremony (a.k.a. meeting) that is called a Retrospective. Other frameworks and processes have adopted the spirit of this meeting and there are a bunch of creative ways to conduct the retrospective. If they are kept fairly informal, transparent, and candid — then they can be hugely valuable — especially when they are actionable.

But this blog is not about the retrospective, instead it’s about the terms and maybe even way we speak of the concept “inspect.”

inspect. v. To examine critically or carefully; especially, to search out problems or determine condition; to scrutinize.

If you’re development shop is worth its salt, then you are constantly inspecting. Let’s face it, the feedback loop with following iterative development, using continuous integration, employing automated testing, and on a cross-functional team is really tight. This means that we are constantly re-digesting information from our feedback loop — so inspection is constant.

photodune-3550517-innovation-sI propose this, instead of “Inspect and Adapt”, shouldn’t we “Innovate and Adapt.” Now I cannot take credit for this change of terms, I was driving home one day from the office and I heard a post-season interview with the Atlanta Falcons’ head coach Mike Smith. He was talking about the fact that the team has reviewed all the tape from the year and now it’s time to innovate and adapt. He went on to say that seeing one’s issues and or challenges is not enough, they have to find ways to beat the competition and be better — that requires innovation.

innovate. v. To alter, to change into something new.

So instead of simply looking and digesting, let’s imagine and innovate. Once we innovate, we adapt the new ideas to our team, we continue inspecting our feedback loops, and we continue our innovation.

Sometimes when you innovate, you make mistakes. It is best to admit them quick, and get on with improving your other innovations.Steve Jobs

Go to Top