As coaches, our focus has to be impacting how effective our team of developers work
with Agile processes and requirements for the development of software. Everything else is just noise.
(Created from ‘wordle’ with the text from the 12 Agile Principles of the Agile Manifesto)
I’m just going to put it out there- sometimes, ‘Directed Scrum’ can be okay.
One of the focal points of Scrum, and let’s face it- Agile in general, is the concept of the “Self-Organizing Team.” The generally accepted definition of Agile Software Development is:
Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. (source- Wikipedia)
There are 4 components to the definition, which are all stacked upon the last component- the team. The premise of the self-organizing team is that it has the skills, maturity, and wherewithall to organize, introspect, retrospect, and subsequently- improve. When this set of characteristics isn’t present, you just might be in need of a coach. Or, something a bit stronger, perhaps.
In some cases, a combination of all three approaches is warranted, but should definitely have a measured approach, resulting in the team being empowered, and set to be self-managing.
I once heard that ‘Juggling is more about throwing than it is catching’. So, that begs the question- are you throwing at least as much as you’re catching?
One of the hardest things to do, as a hands-on ‘doer’ and coach, is to delegate (throw). In doing so, I’ve violated one of the key learning patterns- failure. You see, by not throwing back to the teams occasionally (well-intended or not), I’ve prevented them some failures
(opportunities to learn).
Back to the question about how many ‘things’ you may be catching and throwing. There is good evidence to support the thought that we as humans, pretty much ‘suck’ at multi-tasking. A study of ‘time spent on task’ by a couple fellas from Harvard Business School revealed that in terms of ‘keeping the plates spinning’, we are at our best, with 2 plates spinning concurrently. After that, time spent on task starts to fall off dramatically, actually making us less productive. We need to know when to catch, and when to throw.
Young kids always make the joke- with two objects, throwing them up in the air and catching them, saying “Look- I’m juggling!” And of course, we placate them and say good job to them, while really saying- “If you aren’t juggling with 3 items or more, you aren’t really juggling.” (secretly, I’ve always known that the best approaches to most things in life were learned by kindergarten age!) Who knew that the little guys got it right?
To that end, if I am going to be a really productive, active coach, I need to only have two plates spinning. 1) observing, and 2) responding (no circumstance to that ordering!). And if I take my own advice from the top- I won’t ‘do’ on the behalf of the team, even if I see failure eminently approaching. Of course, I could ask some leading questions…that
could be considered a ‘throw’, right?
Throw your teams a bone!
My Fellow Qualitarians,
Why is it that testing seems to be the common Achilles’ Heel for many *agile* organizations and teams? Is it because of a shortage of literature? A shortage of expertise? Does it just not make sense? I think not.
What many organizations set out to do when they decide to ‘go agile’, is speed up the delivery process. This, in most people’s minds is comprised of two general ideas.
Wait a minute. Don’t we still need to test? Of course we do. Right? Isn’t #3 above supposed to be ‘ensure the customer gets what they asked for’?
I presume that QA started as an afterthought. An afterthought? How can that be in our software intensive world? Apps here, Apps there, Apps, Apps Everywhere! Forgive my Seuss-ism. Assuming for a moment that you are on the brink of adopting / migrating / transforming or what have you to agile, what would you proactively want to build into your testing practices? (Don’t worry- this isn’t a Covey rip-off. I already did that)
1) Test First, Test Last, Test All The Time, Sir! Seriously, building your process so that you can get started before code is delivered is key. So is a constant quality presence. Requirements. Design. Build. Deliver. No better way to do that, than to Automate First.
2) Risk-Based Testing Approaches. Whatever risk means to you, set yourself up to tackle this first. Complexity. High-Traffic Pathways. Money. Get used to doing a licked-finger in the wind analysis- often.
3) Put Your Customer Specs On. If you aren’t looking at things from the perspective of your customer, then you aren’t using the right lens. Responsiveness. Intuitiveness. Flow. Function. And yes, Form. I know what you’re thinking. Not my job. Tune in next time for the article, “It’s Everyone’s Job”.
4) Flex. Things change, and QA (if we’re being honest) is notorious for being too rigid. Requirements change. The customer’s ‘wants’ change. Technology/Approaches change. If we don’t flex with it and show value- something else is going to flex. (Did you get that?)
Thank you, and good night.
I recently started coaching a little league team. This is my 3rd year, in part or in whole. And like software projects, it’s funny how you always seem to have some of the same concerns, right at the beginning.
For this baseball league, I have no control over the random seeding of players that I receive. With that comes a lack of knowledge of skill level, experience, athleticism, or if they even understand the game. To boot- I get one, 1-hour practice with these guys to prepare for the first game. Enter the conundrum- where do I start? How do you eat an elephant?
One bite at a time of course. But more importantly, where do you start?
Detracting from the baseball metaphor, this is the same as walking into any new engagement or project where I have to ‘be the expert’. I find that there are common issues and problems with many project teams that are new to agility- but the difference is the symptom to those issues and problems. Kind of like coming down with a bug, here is my ‘antibiotics salvo’ that I like to use as a catalyst for agile change:
All of this can be done without ever saying the ‘a-word’…
I know- you are dying to know what I did with my hour- right? Offensively we spent a little time making contact with a swing, and running to (through) first base. Defensively, we spent time fielding the ball and throwing to first base. Incidentally, these are the only things that we will have to do in our first game.
Play Ball!
I am continually amazed at the stream of requests that I receive for ‘ROI’ with Agile. NEWS FLASH: (as immortalized by Admiral Akbar) It’s a trap!
The moment the first number trickles from your lips- you are locked into this rate on return. No appeals due to environment, team composition, corporate politics, etc. Stuck. This begs the question, ‘why wouldn’t I qualify a salable ROI number?’ I’ll tell you why. Correlation is not causation. Rather, just because something happens here, doesn’t mean it is going to happen there. (A flurry of great 80’s movies flash in my mind- Better Off Dead- If I ski K-2 also, she’ll like me; Can’t Buy Me Love- If I walk, talk, dress, act like the popular crowd, then I’ll be popular; Pretty in Pink- maybe if I don’t hang out with my yuppy friends, she’ll like me; etc).
Another ‘why’, and keep this on the DL as I am about to reveal one of the major secrets of agile: Agile is about people and relationships. Keep that under your hat.
AGILE IS ABOUT PEOPLE AND RELATIONSHIPS, people! It’s got nothing, really, to do with software!
Bottom line- if your buddy goes to the gym, runs on the treadmill for 30 minutes a day- and loses weight, do you expect if you model his workout, that you will have the exact same results? I hope not… If your online team ‘goes agile’ and delivers 50% faster, then you shouldn’t expect your infrastructure team to suddenly become 50% faster if they ‘go agile’ as well- but I bet they will get something beneficial out of it! Why the difference? Because people are an intangible set of variables and Agility is merely a tool to better understand that.
There’s a difference between knowing the path and walking the path.
A mainstream service and buzzword that has surfaced in the agile world is the concept of Agile Coaching. You might think to yourself- why would I need a coach, specifically for agile? Or, coaches are for sports, not‘business’. Contrary to those thoughts, I think about Professional Football. NFL teams don’t have a stated number of coaches that they can have on staff- and the number does vary by team. Last year, the average NFL team had an amazing 18 coaches on staff. (Even I, a heavy-hearted Packers Fan, was shocked by this.) These coaches have the background, experience, and training to look at very specific areas of execution, while allowing the entire team to function, as a whole.
Coaching in and of itself, is defined: to give instruction or advice. Within that definition, a few things are inferred. First, the ability to Instruct- one must have the ability to act in a teaching capacity, relating concepts and ideas in a manner that is digestible to the target audience (individual, team, or teams). Secondly, inferred is the ability to advise- or consult with your audience best practices, approaches, and methods, based on knowledge and or experience, from specific to team-wide areas of execution.
When is a good time for a team to engage a coach? Any time! Seriously, a coach can be a great asset to the team(s) or organization as your spin up agile methods, to guide you along the way, or for a 2 year veteran team that is looking to make further strides. Studies show that most agile teams implement a series of agile methods or practices, reap the rewards over time for that, and without any further ‘spiking of the punch’, fall into a performance gap.
Another time that is a good indicator that a coach could be helpful- low morale. I personally think that teams undervalue the concept of ‘cheerleading’, or celebrating your successes. (It’s why geese honk! The lead goose in the vee is doing the hardest work, while the rest of the geese tuck in behind and honk, as if to say, “go! go! go!” And of course, they trade off who is in the lead position, as a whole team effort.) A coach can help you identify your ‘done wells’, and your ‘can do betters’ with a fresh set of eyes, exemplifying the ‘term paper effect’ (you re-read your paper 20 times and think it’s perfect- and then some chump looks at it and finds 4 spelling errors in 15 seconds). This influence can help you further develop your agile culture, and hurdle the next performance gap.
Keep honking, my friends.
Thinking back upon the teams that I have been a part of, the really successful ones- we always went through what is called “Schneider’s Classic Change Curve”. You know the one, kind of like ‘Forming, Storming, Norming, Performing’…
It starts ‘on the up’, with High Expectations. You know- “oh cool, we’re going to try something…”
Then, expectations aren’t met. Ultimately, there is realization that some effort will be required to pull out of this downward dive. Next, you hit the period of despair- at this point, folks are either building a rescue vessel, or are lining up their deck chairs. And, if you are fortunate enough to be a part of the rescue vessel group, you get to see the light at the end of the tunnel (and yes, you are on the path to change for the better!) Congrats.
But how do we get here, and why? And why can’t we just take the easy path to get there?
The best way to relate to, and answer this, is the butterfly. Consider this: a butterfly starts as a little egg. He breaks out of his (or her to be fair!) egg as a little caterpillar. The caterpillar grows and grows, and ultimately starts to build the cocoon (or chrysalis, depending on the type) around itself, and starts the process of morphing into a butterfly. The cocoon bakes for a bit, until the butterfly is ready to emerge. Slowly, painfully, the butterfly works and works to make a little hole in the cocoon. Ultimately, through straining and pulling, the miracle occurs. All of this has to occur for the entire process to be successful.
Let’s then consider- if you are walking down a garden path and you see said cocoon. And you see that it is close to opening, and you decide to pull your pocketknife out and make a few nicks to weaken the cocoon, you know, just help the little guy out. What happens? It dies. Surely. The process is the process, in order for it to build the strength to survive. It just is. Like change. The process just is- for better or for worse. No shortcuts.
Bringing this back to Agile. So, the next time you realize that you are ‘working your way out of a cocoon’, acknowledge that moment. Understand what got you into that position. Take the moment in. And, be thankful that you are just a few days or weeks from a Retrospective, rather than another 4, 5, or 16 months from a ‘Project Post-Mortem’ (really? How macabre!) session. And of course, you don’t necessarily have to wait until the Retrospective to start talking about it…surely you are just a matter of a few hours from a standup where you can broach the subject, right?
Hopefully this wasn’t too abstract or touchy-feely for you all. I’ve just had a few bits of inspiration along this (garden) path this past week, with questions around teams making changes, and when they are going to ‘get there’.
I used to build houses in Mexico for a charitable organization. I have done 15 of these trips, having played the role as ‘grunt’ on the first 8 or so, team lead on 3 or 4, and construction lead on a few. A typical trip usually goes something like this:
On my first trip as a construction co-lead (13th trip?), I pulled my other lead, Tom, aside. I told him about this idea of blocking out the work into disparate chunks, having the group of 16-20 volunteers (secretaries, stay-at-home moms, software engineers, 1 or 2 tradesmen, pastors, and salesmen- many “first timers”) naturally form into groups that had some energy, and allowing them to pick their direction. He thought I was a little nuts at first, probably more because he was a command and control tradesman, with his own construction oriented business- and that’s how stuff gets done! After some prodding, and convincing that we are probably no better off anyway, he agreed. Long story short, we ran it passed the team at breakfast- and everyone was ‘in’.
Tune in next week for the results. Just kidding.
When we got to the worksite, the teams were already formed. People just started ‘doing stuff’. It was amazing. We took breaks every two hours, verified what direction everyone was operating in, and kept the pedal down. We reviewed at the end of the day Friday, retrospected around a campfire Friday night, and planned for the next day. Saturday, we kept the same pattern- AND FINISHED, at about 4:15. In all my trips, no team had everfinished on Saturday. Now, do you want to know the really fun part about this? There was a team working right next to us, with teams of people that had done this once before. On Friday, as our 4th wall was going up, they were taping a plotted Gantt chart to the side of a shack that was on their build lot. Just saying… Of course we helped them
Remember, as Keanu Reeves last attempt to motivate his team in “The Replacements”- “Pain heals, chicks dig scars, and Glory lasts forever.”
Take a chance on evangelizing Agile today- and look fondly upon the results!Scrum ain’t easy. Neither is sitting on the Mexico side of the border crossing on a Sunday night. You choose.
