Brace yourself Spark the change is coming..To France!

Equipped with my graphic board, pens, sunglasses and shorts I set sail for the Scrum Gathering in Orlando. Having attended two awesome gatherings in the past, the bar was set high – however, I was far from disappointed.

From the offset, co-chairs Anu Smalley and Kate Megaw knocked it out of the park by entering the stage to the sound of ‘Starman’ by David Bowie, whilst wearing convincing spacesuits complete with helmets. This was their genius way of setting the Gathering’s theme ‘Infinity and Beyond: Transforming the World of Work’. With three tracks on offer, ranging from beginner (‘Mission Control’), intermediate (‘Orbiting the Earth’), to advanced levels (‘Agile Galaxy’), there were more than enough sessions to choose from for all 1100 attendees. Let’s not forget that this was the largest Scrum Gathering so far.

Although each session had a unique offering, there was an obvious key topic that resonated from all talks. During the CST/CEC retreat ‘Agile Leadership’ was introduced as a pressing subject, with one attendee keen to highlight the distinction between ‘Leaders’ and ‘Managers’. Brian Rabon reminded everyone that ‘Agile starts with Leadership’ during his opening keynote. A panellist on the PWC keynote pinpointed that any organisation would struggle without ‘Agile Leadership’, and Steve Denning went on to inform the audience during his ‘Agile Leadership’ talk that the key driver for ‘Agile Leadership’ is having a different mindset.

Leon Sabarsky identified during his ‘Extreme Scrum Hiring’ talk that an obvious flaw when interviewing individuals for team roles is to interview them on their own. His key takeaway was to move away from ‘One-on-One’ interviews by considering ‘Scrum Team group interviews’. This approach enables individuals to be assessed based on their engagement within the group, and demonstrate the qualities required for being an effective team player. It all comes down to good collaboration and communication, folks.

Leon noted that:

“the number one criterion that Scrum team members ought to be measured against is their Collaboration skill. It’s relatively easy to teach people a domain area, Agile methods and a specific technology. However, I can’t teach someone to collaborate well. They either have it or they don’t. If they don’t, they will reduce team effectiveness and cohesion over time.”

Another talk with an interesting twist was ‘Scrum Team CRM: Aviation Crew Resource Management Techniques for Scrum Teams’ by Thomas Friend. Using the narrative of flying aircraft, Thomas made strong comparisons between ‘Aviation’ and ‘Scrum’. Once again, the underlying message here was good communication.

During the Gathering another inspiring movement was unfolding. A group of passionate Agile Educators met face-to-face to carve out a manifesto for Agile that is authentic to Education. With a variety of case studies demonstrating how Agile values and principles have been adopted within an educational setting showing proven success, this group of innovative leaders were making a difference. They set out to define a vision and values for what resulted in the ‘Agile in Education Compass’, an inspiring model for how education can respond to the modern world with agility.

Once again, I had the opportunity to take to the pen and draw key insights from beginning to end. The canvasses enticed the crowds, and people soon took to Twitter to share the learning and store the visuals as a reminder of the Gathering.

Alongside this, on the final day, I couldn’t resist suggesting an Open Space topic around the use of ‘Graphic Templates’ which can assist coaches and facilitators in communicating with pictures. The session was a great success and those that attended were satisfied with their newly gained visual skills.

“Visuals speak volumes, this workshop encouraged me to draw and take these skills back to my team.” – Lynda Menge (workshop attendee)

Whether you wish to enhance your facilitation skills, make collaborative design thinking a key enabler within your team, or simply gain the confidence you need to draw live in front of an audience, join me for a one-day ‘Innovation through Visualisation’ workshop in London on the 1st of June or Atlanta on the 24th of July.

My final point on what drives so many people to attend the gatherings: passion and the desire to collaborate and share ideas. People attend these fantastic events for the discussions and seeds of information that are shared over breakfast, and last well into the evening over a cold beer, the networks that grow, and the desire to continue to collaborate way beyond the event.

I look forward to sharing some ideas with you at the next Scrum Gathering.

By: Stuart Young from Radtac

http://www2.radtac.co.uk/blog/scrum-gathering-orlando-through-the-eyes-of-a-live-illustrator/

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

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