Two Things You Can Focus On Right Now To Make Your Scrum Team Better

    Many years ago, when I asked my high school track coach how to improve my high jump performance he replied, "Run Fast, Jump High." In retrospect he may not have been the world's best track coach, nor I the best high jumper...to be fair. My consternation over not clearing the minimum jump height enough times in a row did cause me to discover long distance running, however. Distance running has stuck with me for 25 years since, so perhaps the man was a genius wrapped in simple, flippantly curt advice.

    Similarly simple advice can be found in the Scrum Guide. I review it, as well as the guidelines for Extreme Programming, often, and especially before each new consulting gig. The combination of these two concepts is what most people consider Agile these days and it helps to have them fresh in my head when I start a new project. Every time I read through the Scrum Guide I am struck by how obvious and straightforward it all seems, much like that *sagely advice from my old track coach. I am similarly struck by how readily we trade the simple Scrum guidelines for the convoluted as we go through our day to day operations. And how surprised we are when it bites us in the rump.

    Being a realist, I know asking for a commitment to Scrum done by the letter on most teams is going to be a tough sell. So, for this week's post I have picked exactly two pieces of the Scrum Guide I would like tattooed on the synapses of every team who considers themselves practitioners of Scrum. I see these simple bits of guidance from Scrum violated constantly and they are among the most empowering if followed.

Thing One - The Sprint

'The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created.'

    Taken on it's face this means every Sprint produces working software that can be demonstrated by a user. It does not mean the creation of some technical component that will only ever be known to work properly after several months of other giant architectural dreams are realized. Put something in the hands of the product owner that is usable. Do so every sprint. It may be embarrassingly light on features, but something that works end to end and could be shipped if required. Product owners and paying customers don't care one single bit about how shiny your data access layer and back end services are polished. Until I can charge customers or enable business functionality for a partner, the software is useless. Unfortunately, yes, I mean yours too.

Thing Two - The Product Owner

'The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals. 

The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:

• Clearly expressing Product Backlog items;
• Ordering the items in the Product Backlog to best achieve goals and missions;
• Optimizing the value of the work the Development Team performs;
• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
• Ensuring the Development Team understands items in the Product Backlog to the level needed.

The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable. 

The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner. 

For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says.'

    That's a mouthful by anyone's standards. An entire organization respecting a single person's decisions is also something I have rarely witnessed. Empowering a Product Owner and fighting to keep that Product Owner focused and present in the team space is genuinely tough. Having recognized that, it is still absolutely worth the effort. Letting one person focus on the product evolution and trusting them to checkpoint and refine as they iterate takes away a non-trivial amount of thrash that slows development teams down. I suppose one interpretation of empowering a product owner is really embracing the empiricism at the heart of Scrum. It means always moving forward, potentially imperfectly, so that the team can keep learning and producing value.

In Closing

    If your team is not currently doing these things, please don' take this post as a condemnation of your professional ability. Scrum is difficult. Software can be difficult. We all need constant reminders of how this is supposed to work and why it is important to be making continuous improvements toward a model we know produces the best results.

The quotes in this post were taken from the Scrum Guide, which can be found here.

Tech Lead - I do not think it means what you think it means.

    A bit of wisdom from Inigo Montoya for the title of this post. And a bit more wisdom from the Agile Manifesto to ease us into things; "The best architectures, requirements, and designs emerge from self-organizing teams." The line in the title is borrowed from The Princess Bride circa1987, and the Agile Manifesto from 2001, which at the time of this writing, is nearly a decade and a half past.
    A part of much more recent internet history is an article published by InfoQ on my 40th birthday that brilliantly details the concepts of self organizing teams and the broader topic of self-organizing systems. The same article also notes that we basically have no idea yet how to make and support these self-organizing teams. One has to wonder how, given the proliferation of Agile both as a software approach and marketing buzzword, we still haven't figured out this silly self-organizing team thing.

    Welcome to the enterprise software terrordome. Organizations with long standing cultures built on hierarchy at all levels aren't about to just let teams of professionals run rampant. As they've "gone Agile" these companies lost the managerial relationship with developers once held by a proper manager hovering over a row of cubicles. A manager who had paid her dues and was properly institutionalized. What to do? They can't leave real, direct managers in place, because that's not Agile. But they darn sure can't let developers run themselves either. Imagine the chaos that would ensue if a bunch of math, science, and engineering minded individuals were allowed to sort things out themselves. I shudder at the thought of the efficiency and common sense that would linger like a dark cloud over the whole situation.
    Alas, the modern Tech Lead role was born. If there cannot be a manager then there must be some acceptable proxy who can keep an eye on things. To loosely employ Anais Nin, they needed a spy in the house of software. Having served in the Tech Lead role on many teams for many years, what I can honestly offer is that a Tech Lead is the more modern, more technically qualified, incarnation of a manager. Somewhere around the third time I fell for the "50% time coding and 50% time performing other duties" farce, I got the point.
    The existence of these Tech Leads is an organizational crutch. One of many clear signs that we have not yet realized the vision laid out before us in 2001. You see, teams know quite well how to interface with each other and who the experts are on the team. Developers learn quickly who has answers and who they are actually following, generally based on a belief that those surreptitious leaders are technically capable and will provide a fruitful path. It is the broader organization that does not know how to interface with teams, and therefore installs a Tech Lead rather than learning how to work in this way.
    There are some unpleasant side effects that occur as a result. Problems that should be owned by all team members become Tech Lead problems. Decisions that should be whole team decisions become Tech Lead decisions. Evaluation of team members inevitably get proxied through the Tech Lead instead of being managed by the team themselves. The wisdom of crowds is lost. The virtuously lazy nature of humanity kicks in and the whole notion of a team working as equals toward a goal goes right out the window. I could go on...
    I say a good Tech Lead, a really truly good Tech Lead, who is focused advancing our profession and doing what is right, is trying to figure out how to eliminate the need for their role. It would be easy to say this is the responsibility of the companies we serve, but it won't get us the outcome we desire. It's on us, Tech Leads, to teach the people around us how not to need us. Then we'll have really done something.

Not(!) My Hero, Sprint Zero**

tl;dr

If you are about to have a Sprint Zero that intentionally does not deliver anything of value to the Product Owner, you are making a mistake.  Please reconsider.

the rest of the story

Like everything else we humans get our hands on, the concept of Sprint Zero is being abused lately and used as an outright retreat into practices we know don't lead to business value.  I am going to come right out and assert that at the heart of the matter is fear...at the team, leadership, and maybe even organizational level.  How we behave when pressed to deliver is a great litmus test for the character of our development culture.  Sometimes, as with these sprints designed specifically not to deliver anything of value, we don't pass that test.

Every one of us worth our salt knows the code we write will tell us if our project structure is any good.  The humans writing the code will tell us what they still need to learn.  The tests will tell us if our product is shippable.  We also know that no matter how much we plan, many of our assumptions and approaches will change as we learn.  The shortest duration to turning over all the rocks along our path and seeing all the truths about the software we are attempting to conjure is to try to write it and observe what happens.

So why then do we not just start every project by trying to deliver some part of the value?  In most cases, whether justified or not, because we are afraid to be wrong and especially with an audience.  We want to design a little more, learn a little more, delay a little more...and hopefully stack the deck in our favor so that there is something impressive for the demo at the end of Sprint...ONE.  This is a very human thing to do, but still wrong.  It signals to me that we have not yet overcome this silly fear around performance, or worse, that something about the environment makes it an unsafe place to be wrong and sometimes both I suspect.

We are humans.  It is OK to be imperfect in this creative process.  As a matter of fact, it is one of the ways we learn most effectively.  Dive headlong into the ambiguity and start trying to put the 1's and 0's where you think they belong.  You will know in short order whether or not you got it right and you will learn loads of useful things for the effort.  If you feel like you need more architecture, oversight, and process to keep your teams out of trouble...you have much bigger problems.  And they will not be solved with any amount of code...or architecture, oversight, and process.

Less chatter...more code!

**For the record the original title of this post was "!My Hero, Sprint Zero" but I was not sure the less technical types would pick up on the "!" as meaning "not"  :-)