Unconditional support, trust, respect, generosity, and courage are the behavioural values required for agile—and also for rugby. On the surface, the software development methodology and the rough team sport may seem to have little in common. But Luis Novella writes that rugby can actually teach you a lot about agile.
When I recently joined an agile team, I suddenly realised I had actually been implementing agile for a few years, just without leveraging the branding. It wasn’t until I listened to Johanna Rothman speak that it dawned on me: Not all things called agile are truly agile, and there are a lot of practices that are agile but are not categorised as such.
Once I understood what agile really means, I realised that I’d seen many of its central tenets contained in another system that’s important to me. Unconditional support, trust, respect, generosity, and courage are the behavioural values required for agile—and also for rugby. On the surface, the software development methodology and the rough team sport may seem to have little in common, but in this article, I’ll show you that agile and the sport of rugby are alike where it really counts—and understanding how to be a team player can improve your career as well as your game.
Trust in Your Teammates
Rugby teaches you to find the most optimal, collectively intelligent strategy within a group of diverse and versatile individuals. When everyone has this mindset, you get sustainability, innovation, and the pleasure of working with a team fully engaged toward a common goal. Overall, rugby is a decision-making game that focuses on shared leadership, and many types of it. It assumes that individuals will be specialists for certain tasks, but they will have the contextual intelligence to make the best decisions for the team based on a deep sense of self-awareness and consciousness of the other team members and the progression toward the goal. Sound familiar?
Despite having played a few rugby games here and there when I was younger, I never imagined the endurance of the behavioral blueprint the sport could generate in a high-performance team. I would argue that the training provided by rugby in terms of behavior is useful regardless of what agile technique or method best fits the particular challenge.
One of the key elements is trust and unconditional support between team members. Despite 160 years of updates, improvements, and new laws, rugby teams at any level still function the same way: When the player with the ball makes a decision, every single teammate actively supports and engages with his position and the context, aiming to provide the best options for the ball carrier (who is always the boss in rugby, if you are into the boss concept). Every player trusts that the decision-maker will make the best choice based on his vantage point, opposition, position on the field, and available support. Once a decision is made, everyone on the team makes the maximum effort for the result of that decision to accomplish the best outcome for the team.
The decision-maker also trusts that everyone behind him will be attentive and available. He believes that if his execution fails, no one will recriminate him; instead, he will be supported. In rugby, you inevitably “fail fast” and make plenty of decisions that turn out to be negative, but you know your innovation was encouraged and respected by the team. Your team trusts that you did the very best you can. They also trust that you have trained and prepared yourself to have been in the best possible condition to play.
Trust releases many opportunities in life. You can innovate and create. You can surprise the opposition. You can discover abilities in your teammates that you did not know were present.
I have had the advantage of working with business leaders who have the courage required to embark in agile transformations the right way—to really and truly happen, change has to start at the top, and the first one to change has to be the inspiration leader. In my opinion, this trust and ability to innovate and err generates pleasure in what we do. It makes our work open and helps us measure and get feedback, because you also trust that the people around you want to make you better.
Just like rugby, agile is a learning system in constant change played by a collectively intelligent team, and the team’s every move is enabled by trust.
By: Luis Novella from the Spark Team
https://www.agileconnection.com/article/what-rugby-can-teach-you-about-trust-agile-teams?page=0%2C1
How the Future of Tech Impacts Work Habits
During the DevExperience conference on the 25th of March, we sat down with one of the key speakers, Lisette Sutherland, to discuss the ways in which technology advancements, and VR in particular, will impact people’s lives and working habits.
Beaglecat: Could you please tell us something about yourself and the company you run?
Lisette Sutherland: I am the director of my own company, Collaboration Superpowers. Myself and other licensed Facilitators give online and in-person workshops to help companies work better together remotely. I am also the remote team manager at a company called Happy Melly – a global network of businesses that are focused on making people happier at work (included are Management 3.0, my company, LeanChange.org, Improv Agility, and others).
BC: Do you think in 5-10 years we will have offices like we have today or do you think everyone will work remotely?
L.S.: Technology is making the traditional ”9 to 5” schedule unnecessary and less attractive for more and more people, especially the younger generation. The most important thing is working from where you are the most productive. Some people work better on the road, some at the beach, some from the office, some from the comfort of their own home – everyone should choose what works best for them.
BC: Do you think that we will be able to work using Virtual Reality in the near future?
L.S.: They’re already doing it. Virtual worlds have existed for more than 20 years now. People are going to school and earning degrees in VR. People are going to conferences in VR. The military uses VR for simulations.
The only issue is that navigating in VR is very difficult, it’s like learning to play the piano. That’s why it’s not so popular. It’s worth trying it out to see what it’s like to be in a virtual world. For example, you can create an account in SecondLife. When you log in, you are placed on a “newbie beach”, literally a beach for new people. Then you have to learn how to move your character and interact with the world and find your way to the place you want to go (like a conference).
BC: I am guessing that 10 years from now this is going to grow. How do you think this is going to impact us?
L.S.: One thing to be careful of is getting enough real life social activity. Technology has an addictive, unhealthy side to it. Each person needs to create healthy boundaries for themselves. The exciting thing is that with technology people can get together from anywhere in the world and solve interesting and challenging problems. I used to work for a company that was developing an online project management tool. The CEO was building it because he wanted to solve the problem of aging. He was frustrated that longevity scientists all over the world couldn’t properly collaborate together and easily share data. So he set out to build a tool they could use to collaborate at a distance. For me it was an ‘aha’ moment. I realized that if we could get the right people together, we could do great things like curing cancer or stopping global warming, or aging.
BC: What do you think the world will look like in 20 years?
L.S.: It is hard to say because if you asked someone 20 years ago what the future would look like today, they would have probably envisioned it completely different.
I recently held a workshop in Lebanon from the Netherlands using a robot – so I beamed into Lebanon, talked to the people as if I were there in the room. Drivable robots are also available now. For example, my friend from Canada beamed into one of these robots in Las Vegas, I beamed into another one from the Netherlands, and we both attended a conference as if we were in Las Vegas together. We visited booths, saw a presentation, had tea together, all from the comfort of our own living rooms. If you had told me I’d be doing that 20 years ago, I wouldn’t have believed you.
When borders dissolve, the possibilities really start to open up. For example, someone in Romania can work with a team in San Francisco, or a team in Vietnam. Sometimes you need that one guy or girl with that unique skill that nobody has – and what if that girl is not from the city you are working in?
There are also many people in the past that have been limited by location. For example, military spouses, disabled people or retired people. Military spouses have a hard time finding stable work because they are constantly moving. And there are many people who have retired, but still want to practice their craft or continue working somewhere. Because of remote technologies, there’s a whole new pool of people to choose from for the work that needs to get done.
BC: So do you think that in the future robots will do everything?
L.S.: I think robots should do the boring work and humans should do the interesting work. And maybe in the future not everybody will have to work full time, and maybe that’s ok. Do we have to work 40 hours a week? Why? That was a random number set by Henry Ford. Maybe we could work 20 hours a week and the rest of the time we could travel, or work on our hobbies, or spend time with our family, or just do whatever we want.
BC: What do you think is the influence of technology on productivity?
L.S.: Recently, I see a lot of companies struggling to go from being time-oriented to results-oriented. When we can work from anywhere, the focus is more on what you get done, not how long it takes you to do it. Spending the whole day at the office only means that you spent the whole day in the office, not that you were productive.
Summing up, the good thing about technology is that it dissolves borders but it requires a new way of working. What it means to be “present” at work is changing, and it’s opening a lot of new opportunities. A lot has happened in the last five years. I encourage people to explore some of the new tools and think about how they can use it in their own lives. My Work Together Anywhere Workshop is a great place to start.
Lisette Sutherland is Director atCollaborationSuperpowers.com, a company that helps teams work together from anywhere. She is also the remote team manager for the all-remote freelance team at Happy Melly.
Great Leaders Ask Great Questions
For the last few years, I’ve been working with and studying some of the best teams in the world; Red Arrows teams, SAS and US Navy SEAL units, Racing yacht crews, a Formula One pit crew, etc. I set out to study teamwork. In particular, I wanted to know how these teams have become world class. In the course of my studies, I identified six common characteristics, which differentiated these incredible teams.
Interestingly, I didn’t set out to study world class leadership. However, when I found world class teams, I also found world class leadership (I know, I probably should have expected that!). So, as well as studying teamwork, I also began to look at the characteristics that differentiated world class leadership. One of the most powerful insights that I discovered is this…
Great Leaders Ask Great Questions.
In fact, the great leaders that I encountered often didn’t provide any answers! Instead, they realise that the group has the potential to generate a better answer than they could on their own. It’s a principle that James Surowiecki outlines in his book, Wisdom of Crowds. When I shared this idea at an educational conference last year, a Head Teacher responded by saying, “That’s rubbish. Are your trying to tell me that Einstein should ask his class for the answer, and that the class will have a better answer than Einstein?”. “No”, I said, “Einstein is part of the class. So by engaging the class you get Einstein plus the class, not instead”.
Knowing that great leaders ask questions is one thing. Knowing what constitutes a ‘Great Question’, is another. So, what makes a question ‘Great’?
Here are some of my thoughts and reflections…
To me, ‘Great Questions’ are simply the right question, asked at the right time. To ask great questions, we need to understand the problem we’re trying to solve and where we are in the process. Do we need to ask a strategic question, or a tactical question, or one that’s related to implementing and executing a plan?
Strategic Question – Why?
Tactical Questions – What? …. How?
Action & Implementation Questions – Where? …. Who? …. When?
Very simply, it makes sense to understand why we are doing something (and whether we should be doing it), before deciding what we’re doing or how we will do it? Equally, it makes sense to know what we’re going to do, before deciding who will do it, when and where.
To me, ‘Great Questions’ are also well defined and simple. Sometimes it takes time and thought to frame a question well. The world class leaders that I saw at work often ask simple questions, which engage their team to collectively solve a problem. Some of the most powerful questions I’ve heard simply begin with the words, “How could we…?”.
To find out more, read Stronger Together; How Great Teams Work and hear from world class leaders sharing their wisdom on Be World Class TV.
By: Simon Hartley, Founder of Be World Class.
Your Engineering Team Is Not an Island: Success Demands a Holistic View of the Business
I just re-read the awesome post from my friends David Loftesness and Raffi Krikorian, What Does A VP of Engineering Do Again? And while I agree with everything that they say, I think there is one crucial item missing, which has been present in every job I’ve had because all of them were user-facing internet services and a majority of my job has been working with product teams. Collaboration with stakeholders (especially with product) is key, but if you take it one step further, a VP of Engineering is actually measured by execution in a wider context across many teams or departments. You cannot look at engineering in isolation for your successes or failures.
But first a short story about my first months at SoundCloud. The CTO wanted more front-end work done because an important release was nearing. He asked me to hire more engineers to accomplish that goal. I started recruiting, but then I looked at why the velocity of the existing team was not meeting expectations. So, I went to all of the front-end teams (at that time it was Web, iPhone, and Android) and asked a very simple question “What slows you down the most in your day-to-day work?” To my surprise, everyone gave the same answer “We only have one designer.” They went on to say that although the designer was very good, she was completely overloaded so designs, changes, and simple clarifications took forever to get done.
Now that I knew design was actually the cause for delays, the solution to my problem was not to hire more engineers (which might have even made the problem worse with more work for the designer), but to start building a design team.
Engineering leads need to look at the whole product process (together with the responsible stakeholders) and not just at engineering in isolation. What I did was a very simple (but, in this case, effective) form of value stream mapping. Our self-improvement at SoundCloud continued. You can read Phil Calcado’s excellent post about the organizational aspects of microservices at SoundCloud.
The Best Engineering Leads Will Stop and Assess the Situation
Continually assessing situations in a holistic way isn’t just the job of an engineering lead — everybody involved should take responsibility. But, in my experience, the problem usually surfaces in engineering because when things are not moving fast enough (and when do they ever?) management’s first reaction can be to throw more engineers at the problem so more work will get done, but also (and this is the not so nice scenario), management thinks the engineers are not working hard enough. Other common responses from management include reorganizing the teams or adopting new methodologies. However, as an engineering leader, you are a lot like a doctor: you need to diagnose the illness before treating the symptoms.
Engineering leaders need to look at the whole value chain and to sit with the leaders from affected departments to review at the problem. The solution to a problem might not be to hire more people (which a lot of startups do), but to organize product development in a better way. And if you have to hire, it might mean that you have to move headcount around. When everyone has the same goal goal — delivering more business value — shifting headcount from engineering to design or to recruiting shouldn’t be an issue. Afterall, the goal is more business value, not having the biggest department. So, when I realized our problem at SoundCloud wasn’t going to be fixed by adding more engineers, we created a design team. But this was just the first step towards a better setup.
Even after creating a larger design team, it remained isolated from other departments and was not fully integrated with our workflows. The problems of turnaround and wasted resources were exacerbated by the increasing risk of misalignment between product, design, and engineering. Therefore, the next logical step was to improve the organization by creating a delivery team per product.
Shifting Organizational Structures to Deliver Business Value
A delivery team is a team that can deliver the vast majority (95%) of its backlog items to production without dependencies on other teams. Unlike more horizontally-oriented teams (for example, a front-end engineering team that relies on the back-end engineering team for any back-end changes), a delivery team has all the necessary skills inside their team. So, depending on your company and your product, these teams can look very different. In engineering teams that are infrastructure focused, these teams can consist of only engineers; but if you look at a team that delivers a consumer-facing web app, then the team looks more like this:
Creating these delivery teams and then making sure you have the right staffing for them should eliminate a staffing mismatch between the affected departments. Some team members (like support) might just be a pointperson for the team, e.g., the support person only attends the daily standup and reports what is going on.
So, don’t look at engineering in isolation when trying to solve delivery problems. It is critical that each engineering leader (and especially the VP of Engineering, who can really influence the organizational setup) ensures that the overall product development process is set up in a way that reduces waste and delivers value to the customer which is the whole point of product development in the first place!
This post includes material from the upcoming book “Scaling Teams” by myself and David Loftesness, which will be published by O’Reilly in 2016. In this book, we will explain in detail the various scaling challenges of software startups.
Thanks to Laurel Ruma and David Loftessness
By: Alexander Grosse from issuu