Lessons Learned From a Hurricane, Part I

I recently stumbled across an article that made me really contemplate how Agile methods and teams can be successful, as a corollary to the topic that it was written about.  One of the foundational ideals of the article reads as follows:  Trees that were grown in *ideal* and sheltered conditions fall over in their first big storm.

The context of this is a agricultural experiment.  Trees, bushes, flowers, and crop plants were all grown and nurtured in an ideal dome based environment.  After several years of growth and maturity, the dome was removed.  Several months later, a hurricane force storm came through the area, and blew down all of the trees.  Nearby trees that grew in the wild, or were planted intentionally did not share that same fate.  Why?

It was determined by arborogists that  trees need wind and weathering throughout their life to cause the roots to grow deep AND broad.  This combination of breadth and depth is what allows the tree to thrive and survive.  Root depth  is what typically allows the trees to find more water to be absorbed by the tree.  Root breadth is what gives the tree stability. Clearly, they need both to survive a variety of situations.

How does this relate to agile teams?  One such consideration: being shielded or sheltered by a manager or Scrum Master.  Often times, under the best of intentions, we want to give the answer to our teams.  This does not promote team learning, or team failing, which is a must in order for a team to mature.  Another form that this takes, is when a manager ‘coddles’ or shields a team from the realities that surround them, like visibility of work being an impediment to the organization buying into agile, or not being honest with them on performance, or not driving towards the minimum viable product.  These are all crutches that we need to rid ourselves of so we can grow, face the occasional conflicts, and rise above in order to put ourselves on an upward trajectory.

Stop, drop, and roll Dick, roll!

Want to be more Agile? Be more Disciplined…

That’s right.  I said it.  To be more agile, you must be more disciplined, rigid.

The thing about agile that strikes me funny is how misunderstood it really is.  So many folks think that it is a license to freelance or freewheel, or something, which invariably is never “free” from cost, rework, technical debts, etc.- especially as we increase in the number of people that have to work together.  Now, if you operate in a two man shop, and the other guy is out selling, do what you want!  But if everyone in modern, multi-person, multi-team shops were simply free to make up their own process or do what they want to do because it feels good, we would be documenting a modernized screenplay of “Lord of the Flies.”  [He doesn't know .Net, so tonight, we're gonna ...]

I recently had some discussions across multiple groups with an organization.  Never once did any of those groups mention a desire of NOT having a process, or NOT improving.  In fact those groups used words like framework, management, and yes, AGILE.  It is my belief and understanding through experience that people want borders, edges, etc.  I read an article a few years ago, but cannot find the reference to give it credit.  It was about an experiment on road markings.  A person was put into a car, and asked to drive down a road; the catch is, the road had no lines whatsoever.  The result, after X number of people is that the vast majority drove right down the center of the road, using the road edge as the boundary, and wanting to be centered within the boundaries.  Funny thing, in my experience of coaching agile teams and raising kids, this is a common safety net and way of operating.

Now, I’m not suggesting that we through the baby out with the bathwater, but there is some good middle ground to try and land on here.  Somewhere between creativity and rigidity is a place where there are guidelines that cover the 80% rule, and allow the appropriate amount of flexibility to cover the other 20%.  Remember, Agile is a methodology, and for those using Scrum- it’s a framework- not a checklist.

Find a process that works for you and your teams, and also makes sense for your organization.  Then, challenge it occasionally, make it better, make it your own.  Then follow it.  Rinse, Repeat as needed.

 

Lawn Mowing for Dummies

I’ve always loved those ‘Dummies’ books.  Probably because I can be a ‘dummy’ at times, but more likely because the authors do such a great job with separating information, and cutting to the chase on specific concepts.

The other day, I had my usual outdoor chores to take care of, one of them lawn mowing.  I have an acre, and 3/4 of it is just wild grasses and weeds, which actually looks okay, as long as it is mowed down once a month or so.  I went out to the garage to fire up my John Deere for the first time this season, and wouldn’t you know it- it didn’t start.  I went through the usual checklist of things to troubleshoot, but it was clear that it needed lots of help, since I didn’t properly winterize it (technical debt!).

Push mower, here I come.  It wasn’t the end of the world, but it takes about 4 times as long to push mow the ‘back 40′ as it does to knock it out with the riding mower.  So I pulled up my big boy pants and got started.  I naturally just broke it into 3 increments, due to it’s irregular shape.  I also took two breaks, one for water, one for gas, and inspected the progress by going to the highest point and checking it over on each break.  Iterative and incremental?  Sure, at it’s most rudimentary level.

Why break it into pieces if you are just going to knock it out in an afternoon?  Simple.  We thrive on accomplishment.  By breaking it up, we get to FINISH something even before all the work is done.  I also attacked the highest risk increment first- the portion that had the hill, which is hard work!  By taking this approach, I finished a something, and the hardest thing first, which got me mentally in a great place to ‘happily’ finish the job.

Think about iterative and incremental approaches for just about any work you have to perform, and inspect the results.  You just might be amazed.  Alternatively, you can just have your teenager mow the lawn!

You Kan(ban) Do It!

A topic of interest that seems to be gaining some steam around the agile community and with some of our clients is Kanban.  Kanban is a Japanese term that is literally translated ‘signboard’, often cited as ‘card wall’.  The practice of using a Kanban has permeated many agile frameworks, and is sourced from lean methods, which originates from lean manufacturing.  As opposed to the manufacturing side where lean and Kanban are leveraged as inventory control systems, the software side utilizes this as a scheduling system.

Most folks identify Agile with Scrum.  So, in order to best describe Kanban, I will juxtapose it with Scrum.

Both methods are empirical insofar as a inferred or explicit ability to experiment with the process.
Both methods are adaptive, rather than prescriptive.
Both methods provide visibility into ‘what is being worked on’.
Both methods empower the team to make determinations around the process itself.
Both methods are fueled by cadence and continuous flow.
Both methods operate as a ‘pull process’(we have bandwidth, pull the next one in), rather than a ‘push process’ (wait for a staged gate before proceeding)

Scrum condones the use of time-boxed iterations called “Sprints”. (Our bucket is only ‘so’ big)
Kanban leverages work-limits by each workflow state. (Little’s Law)

Scrum creates a feedback loop at the end of each sprint for review and retrospection.
Kanban creates a feedback loop at the completion of each work product with regard to queues and lead time.

Scrum leans on different roles to facilitate the process and ceremonies.
Kanban doesn’t require* the creation of any roles outside of the folks doing the work.  *but doesn’t say you can’t either J

Scrum resists change within an iteration. (planning, then commitment to a body of work)
Kanban welcomes change at any given time. (next addition to the work states, adherence to the WIP limits)

Scrum seeks to establish a velocity to understand how much (and when) a body of work can be completed.
Kanban develops a cycle time for work in order to provide information back to the customer as a baseline SLA.

Scrum leverages the burndown chart and velocity metrics as the standard of reporting.
Kanban makes no prescription for reporting, but rather empowers the team to report on what make sense for the team.

The crux of Kanban is to have a constantly evolving backlog of work that flows into queues of limited sizes, that are updated each time something moves from one queue to the next.  Based upon completion, the team develops a sense of lead time, and how many items are optimal for each queue.  That’s it.

Neither approach is more right than the other, and there are great cases for taking a bit from each and using the pieces that work best for your organization.  Some folks, highly prizing both the cadence and ceremony of Scrum, and the visibility and flexibility of being able to respond to work requests of Kanban, operate in a hybrid called Scrumban.

Just keep swimming…

Focus.

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)

Some People’s Kids!

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.

  1. Coach them.  We do this for many other areas of life, so why should this be any different?  A coach can be a powerful way of inducing best practices within your teams, as well as roadmap some improvements.
  2. Drive them.  Remember, Agile doesn’t mean we throw documentation out, along with discipline and process.,- we simply align it to make things work.  This can also mean, in the absence of the above, exampling it by driving.  Of course this plan has to include a transition of ownership to the team.
  3. Align them.  Certainly a last ditch effort for an established team, but either moving people in or out of the team to promote an alignment should be considered, especially if ‘getting started’ is proving overly difficult.

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.

Juggling

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!

Don’t Get Testy with Me, Bernaise!

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.

  1. Don’t spend forever creating requirements up front
  2. Develop product as quickly as possible

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.

 

Little League

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:

  • Card Wall.  It’s nice to know what work you have to do, right?
  • Daily Scrum.  Talking, face to face.  It’s the new email.
  • Product Owner Enlistment.  If the biz is on our side, who could be against us?

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!

Correlation is not Causation

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.