Beyond Scrum - Tools and Techniques

We want to create create software, not only for business benefit but because great software is one of the artistic hallmarks of our age, and truly great software (Stephen Wolfram's Mathematica, and Ivan Sutherland's Sketchpad (1963!) are two of my favorites) is the artwork of our time.

Scrum and the current vestiges of Agile will get you "deliverable" software, but they are not enough to get you GREAT software -- there's too great an emphasis on serviceable delivery, and not enough on the countless subtle enhancements that take you from d e l i v e r a b l e to insanely great!.   I'm sure that the two aren't mutually exclusive, so let's talk about how we make the quantum leap.

We've started with what's wrong, so let's gather it all up and set it to right.  If we peer a bit deeper into ideas behind Scrum, we can take it beyond the dreadful manifestations of those ideals:

• We need great communication, so that every stakeholder has the latest information to make the best decisions. We also need team huddles so that everyone stays connected, heart and soul, to what the team is creating.
  • We do not need a morning attendance meeting where everyone recites a mantra

• We need leadership to evolve our vision as we understand it better
  • We do not need consultation

• We need wisdom that embraces not only the "what" and the "how" but the why

Communication:

We start with communication because communication is both the yin and yang of great projects:

• Metcalfe's Law says that the value of the customer base we reach grows on a power-law, and N*N is vastly better than N.
• Amdahl's Law, though, says that we get diminishing returns as we add to the development team, and intra-team communications are the bottleneck
• The formula for communications channels:  n(n-1)/2 also gives a second-order equation for why things get exponentially harder with larger development teams

Scrum has some fine ideas if your scope is limited enough that you can complete it with a team of 6-9 developers.  Its communications limitations doom it for larger projects, and it's not too hard to show that they fail in the 6-9 developer range as well. Given the power laws that both costs and benefits follow it should be pretty clear that "morning stand-up meetings" that leave no written record just don't make sense for anything much more profound than "Chrysler Payroll."   In the Two-thousand-teens, here's a better, broader approach to communications:

• Chat -- Yammer,  Campfire or Hipchat provide asynchronous, logged communications -- the kind of essential but non-imperative chats that cooperating developers have every day.
• Meetings -- Skype, Google Hangout or Apple Facetime are all good ways to electronically do screen-sharing and 1:1 or 1-many meetings.
• Electronic "Standup" meetings -- Update software like Status Hero takes away the need to get everyone together in person at any time, and logs and archives the results
• Screen Sharing -- Remote pair programming used to be a tough slog, but faster Internet and sharing tools make modern pair programming almost as good as being there. Skype is de-rigeur for sharing in the 2010s, and all Macintoshes come with a fantastic screen sharing application.
• Source code control -- Subversion has fairly universally gone over to Git in the 20-teens
• Source code socialization -- Github and Gitlab (for do-it-yourselfers) provide the social side of code management
• Wikis -- Basecamp and Jira are widely used.   Basecamp is more social, Jira is tech-ier
• Requirements -- JIRA and Rational rule the roost here.
• Deployment -- GoCD and Jenkins are best in class here.

We want a heartbeat for the project, and these are examples of far better tools to achieve it.   We still want live and up-to-date developer status, and here Status Hero logs and tracks the latest. Jira and Rational keep our developer requirements, git holds the source code and Github/Gitlab track code reviews and social access to the code.  We deploy continuously with GoCD or Jenkins, and Jira or Basecamp track the social side of project management.

Our team and software are continuously integrated and routinely stay up to date.   As a leader you need to ensure everyone stays up on Status Hero, but in 2015 standup status meetings make about as much sense as "personal tape drives".   Better communication tools and continuous integration "are the new tape."

Leadership:

Scrum routinely (in both good and bad senses of "routinely") delivers mediocre software because it completely abdicates the leadership function in software development.  Scrum Masters are said to have "power but not authority" -- in truth they have neither.  They can guide a team but the developers don't report to the Scrum Master, and when the hard decisions that determine great software need to get made there is nobody tasked with making them.

Steve Jobs is the shining light in this field, and he was the Vince Lombardi of consumer device software.   He was Lombardi for good because he was absolutely tyrannical, and nobody ever had to wonder "where the buck stopped."   He also had the vision, will, skill and personal magnetism to hire remarkably talented people to work under his yoke.   He was also the Lombardi for evil, because if you try to manage like Steve Jobs and you want anything like Steve-Jobs-results, then you better have all the talents and gifts Steve Jobs had.

Lombardi was a curse when I was growing up, because his Super Bowl victories created a legend that glossed over his psychopathic coaching tactics.   That legend was embraced (and those tactics adopted) by scores of Lombardi-wannabes who 1) didn't have his skills, and 2) were coaching kids and not playing for professional stakes.   In that post-Lombardi era lots of kids were driven brutally in pads on hot summer days by sadistic wannabes who adopted his drive without gaining any of Lombardi's other skills.

One of the greatest flaws of Scrum in the Jobs-era is that the leadership gap left by the "Scrum Master" role is often filled by Product Owners who adopt Jobs' micromanagement obsession without having any of his remarkable vision.   It's a miracle if such misguided and misled teams ever ship anything.

Great software requires both management and leadership and creates a breathtakingly difficult position to fill:

• Technical enough to keep up with insanely fast-paced technology advances
• Managerial enough to take fingers off the keyboard and be "chairman of the bored" with occasionally-necessary paperwork
• Visionary enough to see magical solutions and articulate enough to make the team see them too

Nobody teaches such wizardry; Gandalf, Yoda and Harry Potter may have grown into it but mostly such leaders are born into it.

Wisdom:

Simon Sinek captures a really important message in his book (and accompanying TED talk) "Start With Why."

• If you try to tell a development team "what" to do, you'll chase in circles because any sufficiently interesting software technology moves too fast for development managers to keep up with it -- if you're a manager and you understand it enough to recommend it, then it's already been surpassed by something better.
• It's modestly better to try to tell your team "how" to do it, but this fails as well because just as "no battle plan survives contact with the enemy", no good implementation approach survives first contact with customers.

Let's let Sinek tell the story:

Starting with Why is the magical elixir so often missing in software development.  The great wonder of modern development tools and technologies -- the tools listed above, coupled with modern ecosystems like Java, Rails, Hadoop and the emerging Angular++ JavaScript world -- is that you can start with why and if you take what the tools and frameworks give you, you can evolve the "how" and "what" while keeping to schedule and budget.

I've done this before -- with Chris Russell (reporting to Larry Ellison) at Oracle, for Sandy Kemper at Perfect Software, and for Bruce Ianni at Innovadex.   Scrum isn't the answer, but it's a start.   If you take Scrum, replace the Scrum Master with a real leader, drop the silly Standup attendance check and add tools to manage the creation of different levels of advancement, integrated but all on their own timeline then you don't have Scrum any more. In 2015 the answer is so much better, richer and more evolved than just Scrum...

"Do business as if you were playing a game.  Have fun, know the rules, and when it's time make up your own..."  ~ Guy Laliberté - CEO Cirque du Soleil