Listen, learn … then lead!

An interesting TED talk from four star General Stanley McChrystal about how the events following 9/11 lead to a new style of war and a requirement for a very different form of leadership of the widely distributed military response.

I think this is a worth while talk for any leader to watch and hear about how the General adapted in the face of change..

Exceeding the forty hour work week

To follow on from ‘How to Make work-life balence work‘ video Alison Morris from Online MBA has a pretty interesting inforgraphic regarding the effect of the current trend in America to work more than forty hours a week: it is pretty sobering stuff!

While Europe tends to better at work-life balance than North America there is still room for improvement on both sides of the Atlantic.  I believe it is in an employers best interests to not over work their staff if they want to get the best quality of work.

Distributed Scrum

Software Engineering Radio’s recent podcast about Distributed Scrum was pretty interesting.

The most memorable comment from the while discussion was that a remote/external team is on that is more than thirty metres from you team.  This would mean that many other scrums team that would normally be considered internal teams would actually be external teams e.g. two teams could be in the same building but could be external to each other.

Another interesting idea was instead of having each separate remote group work on sperate tasks or features was to instead split development between the different teams.  The idea is that this will force communication to occur much more frequently than the traditional approach of having each team work in a separate siloed task.

The Rands Test

Rands has posted his own ‘Rands Test‘ in the style of Joel Spolsky’s famous ‘Joel Test‘ for telling if your company is screwed or not.  Rand’s test is focuses on communication while Joel’s original test focused on engineering:

“There is a higher order goal at the intersection of the two questions The Rands Test intends to answer: Where am I? and What the hell is going on? While understanding the answers to these questions will give you a good idea about the communication health of your company, the higher order goal is selfish.”

Embracing chaos

Last week there was a very public service outage in Amazon Web Services (AWS) cloud infrastructure that took down a large number of web sites and services.  This post at the High Scalability blog is a very comprehensive list of articles and posts covering the AWS outage from all possible angles.

So many great articles have been written on the Amazon Outage. Some aim at being helpful, some chastise developers for being so stupid, some chastise Amazon for being so incompetent, some talk about the pain they and their companies have experienced, and some even predict the downfall of the cloud. Still others say we have seen a sea change in future of the cloud, a prediction that’s hard to disagree with, though the shape of the change remains…cloudy.

Particularly interesting is Netflix’s Chaos Monkey (see point 3) and how it has been credited with helping Netflix stay online during the outage.

One of the first systems our engineers built in AWS is called the Chaos Monkey. The Chaos Monkey’s job is to randomly kill instances and services within our architecture. If we aren’t constantly testing our ability to succeed despite failure, then it isn’t likely to work when it matters most – in the event of an unexpected outage.

Deliberately destabilising a live system to improve its robustness is counter intuitive but it seems to have paid off for NetFlix.

Why Scrum fails…

My biggest issue with Scrum is not the methodology itself which I believe is very effective for software engineering, it is how Scrum is typically adopted by development teams. In my experience most teams that are new to SCRUM seem incapable of trying to use and understand Scrum without first modifying the Scrum process to ‘suit their unique development culture’.

These modifications while being well meant usually distort the Scrum process sufficiently to doom the process e.g.

  • The scrum master is also the product owner.
  • Assigning each programmer to multiple scrum sub-teams.
  • Weak scrum masters that are unable to control a stand up meeting.
  • Scrum teams of 20+ programmers.
  • Stand up meetings with chairs…
  • Stand up meetings taking 30-60 minutes due to meta-discussions.
  • Not reviewing task estimate accuracy.
  • Not tracking all work being performed e.g. bug fixing, training, holidays etc.
  • Not engaging stake holders.
  • Not having daily stand ups.

I think Scrum is a very useful methodology when its applied correctly as it constantly captures, measures and responds to changes in the project. However Scrum seems to have a fairly unique problem that its very hard to stop teams tampering with the methodology before they really understand the implications of their changes.