Are We There Yet?

Like children in the back seat of a car, our stakeholders can be incessant at times, don’t you think?  Projects seldom go as planned, or are even delivered in some nearby variant of ‘on-time, on-budget’.  So how do we know when we are there, or at least able to say where there is?  Here is my take on ‘when we will get there’…

1.  The What.

Get into a room with your stakeholders and get on a whiteboard.  Break the need down into functional areas, flesh out your epics, and find your atomic work items that you can get started with NOW.  These are the “WHATS” with conditions of acceptance – not necessarily the “HOWS”.  This will create a feature and function framework.  Repeat as need, your mileage will vary.

2.  Hindsight is 20/20.

Take a quick look back before you decide to look into your crystal ball.  In terms of team and delivery, it truly is the best measuring stick for understanding team capacity.  And of course, do what makes sense here- if two people are going to be out on an extended vacation, clearly you won’t be able to deliver as much had they not, yes?

3.  Know what DONE means.

It’s important as a team to understand what it is exactly that you have to DO to DELIVER.  Often times, teams overlook the very important step of defining what DONE means.  In the absence of that definition or understanding, how does the entire team know how big something is, with some sort of collective understanding?  Create it, communicate it, and infrequently, review it.

4.  Rinse, Measure, Repeat.

Clear the forest for the trees.  Collaborate constantly.  Squeeze your backlog to make value rise to the top.  Measure your results.  Make it better.  Do it again.  Use this information to set delivery targets.

Check, Please!

Posted in Agility, Coaching, Culture, Estimation, Uncategorized | Leave a comment

Lessons Learned from a Hurricane, Part II

In the second half of this, I’d like to examine another facet of what makes us stronger, and helps to weather the storm.  Yes, pun intended.

Another observation that was uncovered in the article is that trees that typically are less resistant to hurricane force winds, but still survived, were growing in groups.  Growing in groups.

Team as a concept in the corporate world carries far less weight, in my humble opinion, than in any other setting where the term is commonplace (sports, military, etc.).  Maybe that is due in part to terms like group and division, or that this is just our job.  I’ve seen far too many organizations view ‘team building’ as simply a box to check in order to appease the powers that be.  That said, here’s my personal checklist to get your team to grow as a group:

1.  Change the view!  Get approvals, budget, etc- and plan a day out of the office, but to STILL WORK.  It’s amazing what a change of venue can do for workplace distraction elimination, creativity, etc.  Work CAN BE brainstorming, idea generation, etc – you don’t HAVE to have your laptops fired up :-)
==> Coffee Shop, conference space, a team member’s house, etc.

2.  Do something different!  Do you think those trees were expecting a hurricane?  I think not!  So do something where you will interact with each other, in a different context.
==> For ideas, maybe survey your team for their top 5 hobbies or interests and find some common ground, then dot vote?  Hike a 14er, play a game, go golfing, etc.

3.  Be intentional! …about #1 and #2 above on a semi-regular basis.
==>  every 3-6 months?- or whatever makes sense, and vary the duration from a couple of hours to a day.

4.  Pass the torch!
a) give folks within the team the opportunity to lead, event to event.
b) inspire other teams to do the same.
c) take this into other spheres of your life! (family, church, friends, etc.)

Party on!

 

Posted in Uncategorized | Leave a comment

Tractor For Sale

I once heard a story, that I cannot corroborate; but sounds too true in general, and with our approach on so many things.

Russia had an immense work force in the earlier 1900’s, but lacked the mechanization to take them to the next level in terms of production, especially for export and their financial security.  They also lacked the cash to import any measurable amount of equipment to reverse that position.  It’s a catch .22 if I’ve ever heard of one.

Their solution?  Buy (or procure) one of what they needed, reverse engineer it, and make their own.  The story I heard was of a Japanese tractor.  The Russians had copied it exactly, but failed to understand that the cracked engine block was a flaw, not part of the design.  You can imagine where it goes from here.  I did a little research and stumbled on a thread about a B-29 that crashed in Russia in WWII, and they appeared with an exact replica, called the TU-4, patched hole in the fuselage and all!!

This is still true of us today!  We adopt a process or approach, and seem to follow it, flaws and all, without question.  Agile methods and their supporting frameworks are GUIDELINES, not the rule or etched in stone!

A very simplified example of this is the retrospective.  I find a lot of teams in a room, staring at a projected screen, and one guy asking, what worked, what didn’t?  It’s quiet, only one or two folks are contributing, and it’s an overall, rather lackluster experience- without much value.  When I ask, “why do you conduct your retro that way?”  The response invariably is “That’s how we always do them.”  </shakinghead>

You have to do what makes sense, and you have to make the process work for you!  Embrace change, and innovate your process!

This is a very complicated case, Maude. You know, a lotta inslotta outs, lotta what-have-you’s.

Posted in Agility, Coaching, Culture, Uncategorized | Leave a comment

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 groups of trees that grew in the wild, or were planted intentionally did not share that same fate.  Why?

It was determined by tree specialists 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!

Posted in Uncategorized | Leave a comment

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.

 

Posted in Uncategorized | Leave a comment

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!

Posted in Uncategorized | Leave a comment

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…

Posted in Uncategorized | Leave a comment

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)

Posted in Uncategorized | Leave a comment

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.

Posted in Uncategorized | Leave a comment