Summary:

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

Nine things I didn’t know nine years ago

May 19, 2016

 

Image from page 400 of “The Palm of Alpha Tau Omega” (1880)

It’s coming up on nine years since I first started slinging code in a professional setting. Professional here meaning with a salary, in an office, with other engineers, decent coffee and unreasonable deadlines.

Back then I was barely newly minted from school, and what I lacked in understanding I certainly carried in hubris. I remember being vaguely offended not to be on the list of Sweden’s top coders that year. No idea how they would’ve found me, but I still remember being annoyed by it.

What I’ve lost in hubris in the last nine years, I’ve gained in experience. I thought it’d be useful to punch down a few things that it would have been nice to know nine years ago — maybe it can help you, if you’re just about to take your first steps out of school.

In no particular order, here are nine things I wish I’d known when I started out:

  1. Experience counts for something. This is obvious, and maybe a bit condescending. But I remember the first time I saw a colleague in a live, heated situation pull up YourKit and hone in on the fact that we’d have two ServerInstanceFactories, not one, and that caused the entire app to go belly up. Or when I got literally smacked on the fingers for not using two-phased locking correctly. And a thousand other things. My first two years of working, what I mainly learned was that I basically didn’t know shit.
  2. People are messy. I’d love to know how many hours humanity as a total spends every day mediating between two or more angry 40-year old men. Most of the time, you’ll find reasonable people that don’t share your point of view on things, and you are not obviously right. There are tradeoffs. And sometimes people hold on to stupid ideas longer than they should, simply because they’re people. It’s a great irony that software development demands literal, logical, unambiguous reasoning while being complicated enough that you need to collaborate with ornate, arbitrary, ambiguous humans.
  3. You’re not logical, you’re biased. If there was one thing I was certain of was that I reasoned with logic and soundness and that I thought things because they were true. Things such as — we hire people only because of merit. Obviously. What I’ve learned is that any point can be argued from many angles, and who I am, where I was raised, what I studied and who my friends are all influence what I think is obviously true. I’ve also learned that I’ll likely never be Spock, and that the only reasonable defense is to invite different points of view, and accept that reasoning from different premises can lead to different conclusions, and still be logical and sound.
  4. You can use engineering for other stuff. As a flipside to above, I’ve also learned that the method of engineering that you learn in school and hone over the years is useful for a ton of other stuff than just programming. What engineering is to me is a way to define, decompose and reduce a problem space, and from that reason a solution under balanced constraints. Really, figuring out what you’re asking, and then answering that. And turns out that anything from sales, marketing, finance, design to analytics are super-susceptible to this. Don’t be afraid to dive in. It’s usually pretty simple to get stuck in.
  5. Users are not stupid. This one is a big one. When users complain about your product, it’s usually not because they’re stupid. Your dad, uncle or whatever that don’t really understand Facebook are not stupid. They just know other shit, and they haven’t learned this stuff yet. And that’s Facebook. They have literally hundreds of user researchers making Facebook simple. When your uncle doesn’t understand your app, it’s probably because it’s pretty unusable. Don’t blame users for that.
  6. Engineers have professional responsibilities. If you work with software in a company that makes money, chances are you have users. Even if you’re building Spotify, not a pacemaker, you still have a responsibility to your users. They’ve chosen your product, and if it sucks, they’re suffering and it’s your fault. This means that if you’re out chugging beer, the systems you maintain go down, and no one else can pick them up, you get a cab home and fix it. Obviously, don’t let a company take advantage of this responsibility. You should get reasonably compensated. But it’s still a responsibility. You can’t laugh off service disruption.
  7. Inverting a tree is useful, but not in the way you think it is. I’ve always been a strong believer in academic knowledge, and I loved taking the hardest courses. Particle filtering, non-linear signal processing, abstract algebra, advanced algorithms, etc. If it looked hard I wanted to know it. However, the point of Red-Black trees is not Red-Black trees. The point of graph traversal is not graph traversal. The point is, the tools you have shape how you solve problems. And the deeper the understanding of graphs you have, the easier it will be for you to see that a problem is a graph problem. Just like if you know enough economics, you can see business problems as market problems. And so on.
  8. Integrating early is always better. This is really mundane compared to all the other grand advice, but if you’re a bunch of people working on a piece of code, avoid branches and avoid submodules as much as possible. It’s really not better to work on your own branch until all is nice and then merge back. Merge early. Merge often. Otherwise you’ll spend a month merging. I promise. Like, I really, really promise … and actually, I guess there is grand life advice here as well. If you and someone you depend on disagree on something fundamental, don’t hold a grudge. Hash it out, as early as possible. Make sure you see eye to eye. The process and the product will be all the better for it.
  9. Simpler is literally always better. I saw someone write something like “Software engineers spend their first two years building complexity, and the rest of their careers managing it”. This is true. Really true. If you can avoid it, never write a dispatcher. Never write an orchestration framework. Don’t use Java if a bash script will do. Solve the problem you have now, not the problem you might have later. Nothing makes you feel as smart as a well architected, abstract framework for solving really complicated, general problems. Nothing makes you feel as stupid as not understanding how to debug it.

Anyway. This is my list. The nine things I wish I knew nine years ago. It strikes me now that current me would love to see the list Nine Things I Wish I’ll Remember In Nine Years. What stuff have I forgotten that would warp my perspective? I’d love to hear your take on either this, or what I missed on this list.

By: Marcus Frödin from Spotify

https://medium.com/@marcusf/nine-things-i-didn-t-know-nine-years-ago-fcbc757b268b#.9xksp8f8t

Our office is closing! We can do better than just despairing

Jun 02, 2016

 

 

In March 2015 we received the bombshell from our U.S executives that our office in Oxford was to close as part of a long-term global consolidation of sites with some staff being offered relocation and the others made redundant. The products needed to continue, but how could we avoid the remaining time just being miserable?

Staff were asked to complete their current work and assist with knowledge transfer to the remaining development offices in the USA and India. The previous few years had seen good progress with agile and lean software development, customer satisfaction had steadily risen and staff turnover had been extremely low. So the closure announcement was a body blow. The chance of the announcement being taken badly was all too real with the risk of the situation disintegrating into a depressing mess.

The Oxford management team had the difficult task of trying to make the best of the situation and get the best outcomes for both staff and the company. One year on, the results so far have been remarkably positive. We can therefore make some recommendations for anyone else in this situation, some of which are also worth considering for companies during normal operations.

Actions taken

  1.  Long notice period – We managed to agree 18 months’ notice of the final closure.   This was necessary to complete current work and have an effective handover so that the complex medical imaging software products could continue. However, it was a very long time to hope that people would stay so other measures were needed.
  2.  Generous redundancy packages.   These were agreed at a level which impressed staff. With their tax-free nature, this gave people confidence that even if they didn’t find another job immediately, they would not have any financial worries for a few months.
  3.  Relocation support – Real commitment was shown to staff to find them other places within Siemens. This included generous relocation packages, funded exploratory visits for staff and families, advice from locals and flexible move dates. This was not cheap, but the cost was much less than hiring and training somebody new.
  4.  Voluntary end dates – Rather than imposing end dates, staff were asked to openly express whether they wanted to stay 6, 12 or 18 months.   It’s very hard to predict how people will react so it was better to try to align individual’s needs with business needs. Almost 100% of people got they end date they wanted, most opted for the longer duration and the company had adequate cover.
  5.  Keeping a training budget – Staff were given encouragement to still do training and qualifications.  The company would still get some benefit from the training in the short-term, it would help staff with finding a new position, but mostly it helped reassure staff that they could stay and still develop themselves.
  6.  A larger entertainment budget – It was important for people to socialise and support each other so there was an increase in company-funded drinks, lunches and a bigger-than- normal Christmas party.
  7.  Help with job-hunting – Staff were allowed to take some time for interviews and encouraged to have an open discussion on opportunities with support given to try to accommodate people’s wishes where possible.   External consultants were available to advise on interview techniques, CV-writing and job hunting.
  8.  Effective use of employee representatives – Rather than just fulfilling a legal requirement, a real effort was made to engage with the elected employee representatives, create a detailed FAQ for staff and share all information on the intranet.
  9.  Continued staff recognition.   The office was required to operate properly for an extended period so it was only fair that staff should be treated normally and retain the opportunity to still achieve an above-target bonus and the opportunity for promotion.
  10.  Management care – The managers have been very open, honest and helpful to the staff and shown genuine care and empathy for people and their circumstances.  This probably made the biggest difference and enabled so many of the positive results.  A site closure can be viewed by staff as a big breach of trust, so asking staff to believe promises about arrangements during the remaining period is a challenge and requires lots of reinforcement, consistency and ensuring that was is said is done.

Results

  1.  Staff morale – This went through the inevitable rollercoaster of shock, anger, worry then acceptance.   People were annoyed or upset at the decision, but overall viewed the offers as fair and professional.   Staff who had been through a redundancy before thought that the way this was handled was much better. Although losing colleagues is unavoidably sad, people have been positive about making the best of the situation.
  2.  Staff stayed until their agreed date – The long notice period and generous packages meant that most people were fairly relaxed about finding a new position and happy to leave serious job hunting until a few months before their agreed end date.  Whilst, it’s an imposed change for everyone, in some cases, staff have appreciated having the “luxury” of having an extended period with a financial cushion during which to calmly think about what alternative job they would really like to do in future. Staff have been open about their hunting and have discussed mutually agreeable end-dates before accepting offers.
  3.  Results still achieved. Work on products continued at a good level.  Inevitably people weren’t going the extra mile in quite the same way as they used to but were professional and productive.   Staff have been helpful in ramping up new recruits in India and continue to take pride in their products.  There have been no surprise, early, resignations or disciplinary issues.
  4.  A surprising number relocated. 25% of people relocated to the USA which was a lot higher than anyone originally expected since people liked being in Oxford.
  5.  Additional social events – The activity in the office “community” if anything picked up since the news with whisky tasting, a pool tournament, team nights out, a group cycle ride around town etc.
  6.  Peer-to- peer training – Staff have shown a great desire to support each other and proactively run open seminars for others in the office to share their knowledge with others (e.g. Sharepoint, Data Science, Android Programming, Arduino programming, Linux etc)
  7.  More cakes – We’ve always provided cakes on a Friday but the number of spontaneous cakes being brought into the office on other days has gone up.

Overall it has been a much more positive experience it could have been. The office morale is still good and the staff have received outstanding praise for their continued professionalism and dedication.

The results has been good for the company as there is a smooth handover taking place while ensuring that people are taken care of.   The actions above have not been cheap for the company in the short-term, but are ultimately delivering better long-term value than the alternative of instant site closure followed by disorder and a long period of rebuilding a new team from scratch.

Suggestions relevant for companies not closing

Whilst some of the topics are only relevant to a site closure, some things could be beneficial anytime.

  1. Management openness is always a good thing. It’s easy to forget the importance of explaining plans and listening to feedback. Make sure there’s time for group meetings, 1 to 1 sessions and occasional surveys.
  2. Peer-to- peer training is always very cost-effective so time and support should be given for this. Staff have a lot of varied knowledge and it’s motivating for both the trainer and attendees.
  3. Creative entertainment. It can be an easy area to cut, but pays back a lot. If people have a good social relationship with colleagues, they are much more committed to them and hence also the company. The entertainment does not necessarily have to be lavish e.g. a pool table and     tournament, an indoor mini-golf area made out of office accessories and text books, a pancake- tossing event on Shrove Tuesday etc. Something a bit different every few months keeps things fresh. Cakes, are always good.
  4. Look for the best outcome for both staff and the company given the circumstances. Arrangements with staff have to be fair to get the best results in the long-term.

By: Stephen Wells, Siemens Molecular Imaging, Oxford

Rejecting roles

Mar 29, 2016

Rejecting roles: That’s marketing’s job. You need to talk to IT.

Having roles is considered essential by most organisations. We’ve read dozens of business blogs, HR advice articles and even management training courses that insist clearly defined roles lead to better results, greater productivity and higher motivation. Without clear definition of roles, they warn that tasks get missed, no-one takes responsibility, the office is chaotic and individual motivation drops.

We disagree.

The writers of this advice have grasped the outcomes they want – people taking pride in their work, everyone focusing on delivering value, individuals coordinating and collaborating – but they’ve applied the wrong solution.

They’ve confused roles with responsibilities.

That may not sound like a big deal, but we think it is. Rigid role definition has some major downsides. We believe it hurts companies and individuals, costing them in creativity and happiness.

Most organisations intend their role definitions to be a way of signalling particular specialisations, expertise and responsibilities… but instead, the definitions swiftly harden into barriers, marking out territory which is defended against ‘interference’ from others. Have you ever been told to back off by the marketing manager for commenting on the new advert? Been refused access to the code base by the developers, ‘in case you break something’? Been told to leave presentations to ‘the sales guys’ or forecasts ‘the finance guys’? At the extreme, you may have your opinion rejected with a straight-forward ‘well it’s not your job to worry about x, it’s mine!’.

Individuals may also use their role definition as a way of avoiding unpleasant or boring tasks. This ‘that’s not in my job description’ approach ends up making the company less efficient as well as eroding team motivation. I remember organising a last-minute marketing stunt when I worked at Unilever. I was booking a double-decker bus to turn up and I wanted to check it would actually fit into the office forecourt. The marketing assistant nipped down to Reception to check. An hour later, she returned. The security guard had refused to measure the gateway and if it was beneath the dignity of a security guard, then she reckoned it was beneath the dignity of a marketing assistant as well. So I borrowed the security man’s tape-measure and checked the gateway (you could – quite literally – have fitted a bus through there). Anything wrong with doing my own measuring? Absolutely not. Anything wrong with wasting an hour of time arguing about whose job it was? Plenty.

Roles are comfortable – but bad for us

It’s very human to defend our own work and our own opinion. When we can dress this up with the authority of experience, expertise and organisational separation – all the better. Except it isn’t. Rigid role definition acts as a barrier and can stifle innovation. It can also make things slower and less efficient.

If a customer rings up with a problem, they want a solution, not to be told that only part of their problem can be dealt with by this department, and they must be passed on to billing or whoever to deal with the rest of it.

It’s not great for individuals either. Sticking to just one thing may mean our knowledge gets deeper, but also narrower.  We can get bored or worse, so convinced of our own expertise that we can’t take on other points of view.

Being Radical: Sticking to the start up way

In many start ups, a lack of defined roles is the default position. There is not enough money to hire specialists – instead developers must learn to present to investors, marketing managers must be able to create and manage their own customer data, and everyone must have a grip on the financial assumptions as well as a grasp of the their product (this often means some grasp of the technology).

When entrepreneurs look back on the early stage of their companies, they often comment on wistfully on the diversity of work and of how close to the customer it meant they were.

Jeff Bezos, CEO of Amazon, recalled being the ‘mailroom grunt’ in the company’s early days, driving books to shipping and courier companies in his 1987 Blazer. But this doesn’t scale, right? Jeff Bezos is not still doing deliveries. Actually, he is. He spends a week every year in the warehouse. It’s not a PR gimmick, because he refuses to set up interviews when doing it. It’s an opportunity to stay connected to his responsibility – leading Amazon – and not the role of CEO. That includes really understanding conditions for employees – something for which Amazon has received a lot of criticism – and staying close to core services like order fulfilment.

Another trick used at Amazon is to have individual employees who have no role at all. Bezos has ‘shadows’, people who simply follow him around. It means there’s always someone free to chase a wild idea or set up an experiment – and it recognises that a responsibility like ‘envision Amazon’s future’ requires several people, not just a single role.

So what should we do?

1. Responsibilities not roles

Some radical companies go for a very broad responsibility ‘provide value to the company’ and say that how this is fulfilled is up to the individual. Others go for more precise responsibilities: ‘help the customer’ or ‘make sure we comply with financial regulations’.

The point is that how you fulfil these needs can require doing tasks which, in other companies, would be seen as belonging to differing roles.

2. Trust people

A lack of roles makes people more responsible, not less. Tasks rarely get missed because everyone knows they have total responsibility for the work – no tester will come pick up the programmer’s bugs; no finance controller will correct over-optimistic projections.

3. Trust people some more

A lack of roles doesn’t mean that everyone will try to do everything. People naturally gravitate towards what they’re interested in and what they’re good at. If someone is convinced she’s a brilliant illustrator and everyone else insists the stick men cartoons are rubbish, she will soon stop.

4. Value dissent not consensus

No roles doesn’t mean you have to design by committee. Heated arguments are common, and that’s fine.  Even if people don’t agree at the end of the debate, the important thing tends to be to air the problem. Opinions can be rejected; a decision can still be made, risks can still be taken…

By: Helen Walton from Gamevy

Leave a Comment

Your email address will not be published.

Comment *

This site uses Akismet to reduce spam. Learn how your comment data is processed.