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"  :-)

What's in a Name?

    Standing before me yesterday was a very well educated, well spoken, well dressed, and well intentioned pair of gentlemen who are administrators at a local university.  I really enjoyed meeting these guys and hope I get a chance to work with them.  They had questions, lots of them and good ones about how to change the development culture at their shop.  As our conversation progressed in the lobby of our development studio it was all smiles and nods and handshakes.  That is until someone used the word "resource" in reference to the group of human beings that author software for the aforementioned university.
    While I did not respond verbally, I am sure my face gave away my dislike of the term.  And after we wrapped up our chat, I found myself being critical of my own opinion.  I wondered if I was just being a silly, high-maintenance jackass about the phrase.  I have been on an anti-'resource' mission for 7-8 years now.  Maybe it's time to chill out a bit on the topic.  But then again maybe it's not :-)
     I don't want to get into an entitled, 'special snowflake' situation.  I do want to humanize the art and craft of software development.  The idea that developers are some fungible asset that can be leveraged on any project with equal outcomes is silly.  I sincerely doubt that silly idea was the impetus for the comment mentioned above, but speaking in that way leaves the door open for interpretation.  So...I disapprove. (shocker, I know)
    Software development is in a protracted period of transition.  Business and IT are quickly becoming the same thing, or at least combining to become the new state of things.  Software developers are the authors of the context in which business will be done for the foreseeable future.  In order to allow these human beings to do their best work, we need to be deliberate about creating an environment where uniqueness and creativity are the norm.  We want the best from our software developers so that we can continue to advance the business of IT and/or the IT of business.  The leaders among us need to expend effort making that happen.  Choosing our vernacular, our physical spaces, our processes, and our tools are all part of that equation.
    So pretty please, don't call us resources.

The Better Half

    Paired programming is great...except of course for when it's not.  On those tough days it is a developer's own annoying trip through hell and back with a deadline.  I've had it both ways.  I have had my most and least favorite days in software while paired up with another developer.  I wish I could end this paragraph now with some sagely formula for always having a positive pairing experience, but we are dealing with people and it's not that easy.
    As a consolation prize I do have a recent experience to share which you may find useful, or at least familiar.  As it turns out I spent about 11 months in 2013 on a team in the middle of a really interesting C++ project.  Prior to joining that team I had not worked in C++ for well over a decade.  As a result I went from SME to FNG overnight.  This also meant that I had to learn how to be effective as the inexperienced half of a development pair, which I don't do nearly enough. (Note to self)
    Trying to learn the domain, learn the language, and not impede delivery is tough.  Being confused can be a little demoralizing at times.  And constantly asking questions makes me feel way more vulnerable and annoying than I would prefer.
    That's the job though, so my advice to myself was to suck it up, get coding, and try not to ask the same question more than once.  That realization, as simple as it reads, seems to get lost most of the time.  From what I can ascertain most new team members get paired up and actually have little or no idea what their responsibility is as the new pair partner.  I suspect most just assume they are along for the ride and someone will tell them what they are supposed to do.
    Of course, I have a differing opinion on this matter.  Your job as a new team member and pair partner is to become a contributing member as quickly as possible, which can be as little as a few hours.  Everything you do during your first days and weeks on a team should map back to that goal.  This means questions, lots of them.  It also means reading every applicable thing you can get your hands on, trying to pair with and get to know as many team members as you can, understanding team norms and cadences, and keeping your teammates aware of where you are strong and where you need help.
    On the most successful teams I have seen new team members are pushing code in their first few days.  When these same women and men are asked weeks later about their experience of joining a high performing development team they always say the same things - "On most new jobs you sit around and wait for a machine to be delivered and read documentation." , "Getting to contribute working code in my first week on the team was great."
    So...the formula's easy right.  The most obvious business value of a new developer on a team is in his or her code...so be coding.  Coding will tell you what you don't know and what else you need to be doing.

Standing Up for Stand Up

    Earlier this week a disagreement occurred amongst some technical team leaders regarding how stand up meetings should be held.  One camp felt the meetings were becoming a bit cluttered.  The team is a remote team and several interested parties from the home location like to participate in the daily stand up via Google Hangout.  One of a few complaints is that the cross site communication makes the stand up kludgy.  There are regular interruptions to repeat things, for instance, since the microphone is directional, etc, etc.  Other annoyances were also noted.
    The other camp insists that the good that comes from the cross site participation far outweighs any headache it causes.  The home location values maintaining a strong relationship with the remote team and accepts the soft costs of doing so.  As is usually the case, both camps are correct and are now entangled in a very fine grained philosophical disagreement.
    But none of that is as important as the fact that it caused me to gut check my own reasoning and make sure that I was staying true to the principles that guide me as a leader.  You see, I believe that a human being's best work is the result of a harmony amongst the many forces acting on that person's life.  I think this because I latched on to the teachings of Lao-tse very early in my own life and value them even more today than I did 25 years ago.
    One does not need to know very much about Lao-tse or the Tao Te Ching to know that he believed a perfect harmony between heaven and earth existed naturally and could be found by anyone.  The idea he put forth is that the more a person interferes with the natural order of things the more that person will struggle against, and retreat from, harmony.  I am convinced that this concept is important to the technical work we do and the way in which we lead our technical teams.  There are examples of similar or identical thoughts all over the software world about "signal to noise ratio" or "context switching" and slightly more etherial things like "flow state".
    So bringing the point back to the decisions that impact development teams, I stand firm on the opinion that genuine annoyances are to be removed.  Knowing the human beings that choose to team with you is the job of a leader.  Working towards harmony through techniques and tools and improved (or removed) process is a leader's responsibility.  Above all else, the people who you ask to follow you deserve an opportunity to be happy and do the best work they are capable of doing.  In doing so they may experience their true nature without the arbitrary and false interferences business would otherwise impose.
    These are lofty goals.  It is likely that, as a leader, I will fall short of these goals on many occasions.  The desire and effort to achieve these things will give me an opportunity to expose my true nature, however.  And for that reason, I have no choice in the matter.
    Completing our round trip then, what should be done with the stand up meetings?  Give the remote team what they want so they can go be productive without being annoyed.  The need to coordinate between sites is an artificial constraint that the leadership has imposed on the project.  It is the job of those same leaders to find ways to satisfy the tangential needs of the project and not impede the harmony that naturally exists between a developer, a keyboard, and problem in need of solving.
    That's the way Lao-tse saw it then and that's the way I see it now.

Hiring Agile Software Developers

    Attracting and hiring the right people to form an Agile Development team is tough.  And anyone who has ever had to handle the coaching or removal of an underperforming or ill-fitting team member knows how important it is to make good hiring decisions.  A bad hire can become a drain on a team and even worse, take time away from coaching, skill uplift, and recognition of top performers.

    So how do you know if you are hiring a person that is going to fit on the team and perform?  And equally important, how do you know if they are any good at designing and writing software?  You have to audition them and you have to be ready to get into the nuts and bolts of their history in this craft.  So many employers, especially large employers, scan resumes for keywords, schedule interviews, and then don't go much further than to check that a candidate shows up on time, has a firm handshake, and wears appropriate attire.  Not good enough...not even close.
    In some cases this happens because a non-technical person is working alone hiring people for technical positions.  I have known more than a few managers, good ones, that are not current in the technologies their team uses and therefore feel outgunned when they have to interview a candidate.  Sometimes this works out, but in many cases that candidate gets hired and becomes that person in your group that you look at and shake your head...wondering how in the world the two of you ended up on the same team with the same title and are SO different.  If you are one of these leaders, knock it off!  Go get some help from an awesome developer you trust and start doing the job correctly.
    More often and more tragically, though, the group or individual running the screening process is very skilled technically and simply not using the correct tools to perform the task.  Not many of us appeared in the software development profession with a great understanding of what type of questions to ask a person when interviewing and what technical drills to put them through to give us insight into their abilities.  In far too many instances I have seen a developer or technical lead get asked a few minutes prior to the interview to "sit in" and then subsequently help make a hiring decision.  As Agilists and Craftspeople conducting ourselves in this manner is not acceptable and is a disservice to everyone involved.
    If we are going to be diligent and give candidates a proper look then we need a consistent audition process.  You don't want to go into the interview/audition process without a plan and depending on where in the world you work you are most likely required to provide every candidate with the same screening process so that you are sure to be impartial and unbiased.  All that being said, if you interview developers with any regularity, you must define an audition process.
    You may wonder where to start or think that planning an audition is tough, but honestly it turns out to be one of the more enjoyable things to do as a developer.  My response to this challenge was simply to understand the needs of the team as criteria and then script an audition process that exposed the presence or lack of those traits in candidates.  The higher the expectations of the role and the more tenured the candidate the more lengthy and complicated the audition becomes.  My recommendation is to therefore start simple and build into the more complex, kind of like everything else we do in this trade!
    Below is an example of my audition process for candidates that are newly graduated and/or just beginning in their software development career.  This flow was derived knowing that my recruiting department will have done some basic initial screening and that I had already been through at least one 30 minute telephone conversation with these candidates as a second filter.  I already knew where they were with Agile, XP, etc. and in most cases they had little or no exposure.  The team I wrote this audition script for holds a person's attitude to be *almost* as important as their technical ability.  The ideal candidate will have the positive, self-motivated attitude of a good Agilist and the chops to pair up and code and learn like a champ.  Based on environmental factors I also knew going in that I was only likely to ever get about 90 minutes to spend with a prospect.  Lastly, I believe this process is very much a two way interaction and I use it to introduce people to our corporate culture and allow them to gauge fit as well.

Developer Audition – (Entry Level/90 Mins)

Introduction
09:00 - Greet at lobby (Tech Lead)

09:00-09:05 - Ride up to team space floor. Introduce Tech Lead in more detail. Describe and settle on agenda. Offer restroom/water.

Cultural Fit
09:05-09:15 - Tour team space. Introduce candidate to team leads/members as available and describe roles. Pick up other team leads who will attend audition.

09:15-09:40 - Proceed to conference room. Describe Culture (ex: Agile, Poly-skilling, Teaching Days, Standing Teams, Continuous Improvement, Retrospectives...)

Some Suggested Questions Regarding Cultural Fit

1. Describe the work environment from your work history in which you were most productive and happy.
2. Describe the most effective roles a good manager plays with the staff he/she manages.
3. What is your preferred work style, alone or in teams? => What percentage breakdown between the two suits you the best?
4. When working in a team, describe your mostly likely role on that team. How would other team members describe you?

09:40-09:50 - Candidate Questions/Break if needed


Technical Aptitude
09:50-10:20 - Using the whiteboard and Tech Lead's PC in the conference room. Although a quality technical solution is important, also of interest in this segment of the audition are the questions asked, what resources are used to problem solve, and how the algorithm is determined. Assuming the candidate attempts the solution most people go to first, involving an array, it is very important to gauge how he/she feels about having that solution refactored.

1. On the whiteboard, in any syntax or plain English, describe the logic to take in a string and return the characters in the string in the reverse order. (5 minutes) 
2. On the whiteboard, write a HelloWorld program in Java or another syntax of candidate's choosing. (5 minutes) 
3. On the PC, in a pair with the Tech Lead, NOT using an IDE, with access to the Java 6 API on-line, write a Java Hello World style program returning any string the candidate chooses. (5 minutes)  
4. On the PC in a pair with the Tech Lead, NOT using and IDE, with access to the Java 6 API on-line, extend program from step 3 with logic to also dynamically return the reverse of the string returned above. (10 minutes) 
5. If we don't hit the preferred solution the first time, refactor the previous exercise to look more like the code below. (5 minutes)

10:20-10:30 - Candidate Questions/Wrap up/Walk out


One Sample Solution to Questions 3-5 (an actual contribution :-)

class HelloWorld {
  public static void main(String[] args) {
     String myText = "Hello World";
     String myTextBackwards = reverseMyString(myText);
     System.out.println(myText);
     System.out.println(myTextBackwards);
  }

  private static String reverseMyString(String myText) {
     StringBuffer tempText = new StringBuffer(myText);
     return tempText.reverse().toString();
  } 

}

    As you can see, there is not a lot to it.  You may choose to do much more with the technical audition based on your needs, but some basic exercise such as this or any of the multitude of simple Coding Katas out there will get you started.  For the more experienced candidate and/or more tenured role I would highly recommend also having them pair with one or more developers on the team.  Just be sure that person has been briefed on what to evaluate so the expectations are clear and consistent.  Having a properly planned audition will demonstrate that you are part of a professional organization that takes the hiring process seriously and allow your team to make an informed decision with consistent data points for each candidate.