What makes you agile? Part Two

Recently, while visiting a client site, I was excited to see a large breakout room labeled “Agile Room”.  You can only imagine my surprise when I walked in the door.  I saw a series of cubicles.  I saw people working very quietly and independently.  I saw a scantly populated dusty board with only a few sticky notes and one single column labeled “Done”.  When I asked about the naming of the room,  they replied,

“Oh, well, we just call ourselves ‘agile’ because we deliver faster by not testing at all.”

Doh!

But all is not lost (on you, not them) because this experience got me thinking more about just what does make you agile.  If you read my last blog entry, I hinted that when you really start to understand agile disciplines, when you really start walking the walk, it is hard to not to look at any project in your life with an agile mindset.  What, you don’t believe me?  Follow me…

I keep telling my wife “work in progress” or WIP is a form of waste.  Unfortunately, she just thinks I’m dodging my work tasks.  But don’t worry, I’ve won her over before and will do it again.  This year, we have the very fortunate blessing of being able to take a family beach vacation and our 10 year anniversary trip.  Of course that also means a lot of research and planning and finding bargains.  I was quickly overwhelmed trying to find the perfect destination with the perfect price for both trips.  I was having trouble remembering which deals were better for which location.  Time for some lean thinking!  Rather than pay the cost for context switching, I focused on one vacation at a time.  Recognizing the value of the 10 year anniversary trip and how much it would appease the wife, I started with that trip.  I was able to get immediate feedback and deliver results quickly.  Once I had the highest priority trip booked, I could plan around that to add our family vacation.  Why would I do it any other way?  This approach works just as well with “honey do” lists and chores.  Prioritize the highest value tasks and focus on one at a time.  Deliver results and reap rewards.  You’ll thank me later.

Speaking of my wife, she works as a teacher at a local pre-school.  The principal has the teachers meet every morning before class and she presents an inspirational story or topic. This is a fine practice, but it could be improved. Later, I hear my wife say some classes are complete chaos and others are well oiled machines.  They have six classes at each age level, so there is some definite opportunities for sharing.  I suggested they change the morning meeting from a presentation by the principal to more of a daily standup.  That way they could discuss what worked well for their class yesterday, what challenges they have today, and ask for help or advice from the other teachers.  Something very simple, but something which could have a dramatic impact on the teacher control in the classroom and subsequently the educational experience of the children.

I know, I know, you are tired of LEGO analogies, but I think this is a good one.  (Maybe there is a good reason LEGO sets are such the ultimate toy?) My daughter got a “girl” LEGO set, complete with pink and purple colors and everything.  It is from the “Friends” series and this one is a quite impressive dream house.  It is supposed to take kids aged 12 and up days to complete.  As you know, there are always instructions on how to build any of the LEGO sets.  Think of this as the documentation.  The minimalistic documentation focuses on the experience and in fact provides no words, just pictures, or solution designs.  This LEGO set was divided into two halves, book one and book two.  This is kind of like deciding to have two releases.  What is really cool is the books or releases are further broken down into rooms or sprints.  Each room in and of itself is a completely usable toy on its own and requires no further building to be enjoyed.  Sound familiar?  After building three rooms and adjoining them, you have the first floor or release one complete.  Then this process repeats for the second floor or release two.  I think you get the idea.  Unfortunately, after excitedly trying to explain iterative development and increments to my 7 year old daughter and this amazing analogy, she was simply too eager to start playing with the house.  And even more unfortunately, she delivered this solution in just 4 hours when I was expecting her to enjoy it (stay occupied) over 4 days.

Did you make any New Year’s resolutions this year?  If you did, how did you decide what to do?  If you are like me, it kind of felt just like building a prioritized backlog.  As I thought about what and where I would focus this year, I asked myself how much value each item would actually provide to my life.  Very quickly I saw which things would be nice to do or learn, but which would not enhance myself or my family.  But don’t lose those items, keep them on the backlog and re-evaluate them next year!

My daughter is learning to play the piano.  It is such a beautiful instrument.  I can only hope someday she will dazzle me with delicate renditions while I relaxingly sip some wine.  Well that and I hope I can actually afford a real piano someday!   A few months ago, I noticed she was very focused on memorizing the entire songs for her recital rather than reading from the music sheet.  She was struggling a bit and trying to do the whole song each time through.  Naturally, I applied my incremental approach to the problem and broke the song down into smaller chunks.  And you know what?  She was playing the introduction perfectly in no time at all!  Then we added the verse and then the chorus.  I had her play all the parts together each time, building on the original increments. She was ecstatic when she realized the rest of the song, from the piano playing perspective, was just repetition of the verse and the chorus.  The product release, or song, was ready for the winter recital and she performed brilliantly.

So, you see, opportunities to apply lean and agile principles are all around us.  I can’t help but notice them.  And that’s what makes me agile.

What makes you agile?

I cringe whenever I hear an executive or a manager say something like, “Yeah, we got some development teams doing that agile thing.” Which is usually followed by something like, “I don’t know what the impact is, but we have a directive to have more teams doing agile.”

There are so many problems with those two statements my head usually starts spinning…

“What exactly do you mean, you are doing agile?”
“Why are only the developers participating?”
“What metrics are you using to verify improvement?”
“Who made the directive and how are they helping the organization succeed?”
“Did you provide any training or coaching?”
“Did you hire any agile consultants with actual experience doing agile transformations?”
“What problems are you trying to solve?”
“How often do the teams produce working software?”
“What practices and processes are you using that make you agile?”

And so on and so on.

The most important thing you need to accept for an agile transformation to be successful is this – agile is not something you do, it is something you are. Let me repeat that. Agile is not something you do, it is something you are.  Actually, in many cases, agile ends up being something you are not. But let’s stay positive.

What makes you agile? In order to answer this, let’s take a look at:

  • What is agile?
  • What makes an individual agile?
  • What makes a team agile?
  • What makes an organization agile?

What is Agile?
Agile is set of values and principles. These have already been defined somewhere, haven’t they? Ah, yes, any good agile blog should have at least one reference to the “Agile Manifesto”, so here goes… You can read the “Agile Manifesto” and its:

By the way, I’m wondering why they don’t have a better webpage yet? Seriously, it’s been over 11 years! But it really is good stuff and these statements are pretty widely accepted by agilistos. Of course, there is always room for continuous improvement, right? For example, I have seen some great updates made by http://disciplinedagiledelivery.com/.

Be forewarned though, just reading these values does not inherently make you agile – it can only make you agile aware. True agility can be achieved by embracing these values in the software disciplines and methods you practice. Heck, I even find myself applying agile principles outside the IT world and in my personal life, but that sounds like another blog post for another day.

What is Scrum?
Agile is not any one specific software methodology or process. Scrum is currently the most commonly adopted agile methodology for agile transformations. This is primarily because it is very straightforward, focuses on project management, and there is a plethora of “experts” available. We won’t even get into the joke that is the ScrumMaster certification test. The problem is many teams try to do Scrum without understanding the underlying core agile values behind Scrum. They don’t realize the discipline that is actually required. Inevitably, these teams are unable to adapt to changing conditions or scale to more than one team. And then we are forced to invent terms like water-scrum-fall, scrum-but, and fr-agile to describe the mess they’ve made.

What is Lean?
It seems like speaking to organizations about Lean can be easier to comprehend than agile. Lean never pretends to be a silver bullet process. For those unfamiliar with Lean, pause a moment and check out wikipedia. As is often the case, wikipedia provides a fair enough introduction at http://en.wikipedia.org/wiki/Lean_software_development.
Lean is a set of principles –

  • Eliminate Waste
  • Amplify Learning
  • Decide as late as possible
  • Deliver as fast as possible
  • Empower the team
  • Build integrity in
  • See the whole

These principles can easily translate into goals for a team or an organization. And the best thing about goals is even if you never reach your goals, you can still make significant improvements trying to attain them. Agile and lean are very complementary, so don’t worry about having to be only agile or just lean. Be lean. Be agile. It sounds sort of like a prescription for IT yoga, doesn’t it?

What Makes an Individual Agile? Experience counts!
When someone allegedly reputable tells you they can teach you Scrum in 15 minutes, what they mean is they can teach you the Scrum roles, ceremonies, vocabulary, and timelines in 15 minutes. And they probably can. However, it should come as no surprise there is much more to being a ScrumMaster than memorizing a few practices. Scrum is not taught in the pages of a book. A solid book with deep experience reports is a great place to start, but reading can only get you so far. (Geek comment alert.) Reading about Scrum is like adding more cores to a machine to get performance improvements running an application not designed for multi-threading. Scrum is really only understood and mastered through actual Scrum implementations with actual people and projects with actual goals and deadlines. This goes for more than just Scrum too. Be careful selecting your agile coaches and mentors and make sure they have the appropriate experience. This should not be too much to ask. Agile is already mainstream and as mobile development explodes with very short feedback and delivery loops, agile will be pressed even more into action.

What Makes a Team Agile?
It is pretty easy to see whether a team is agile or not. Agile zealots will argue their beliefs religiously and righteously declare, “You’re not agile!” Well, often they are correct. There is a whole pile of agile practices common to agile teams and you can find a good number of them here. It is also pretty easy to spot agile anti-patterns. As a developer with IBM in the early 2000’s, I can describe in detail many of those anti-patterns. (oooh another good blog topic). I can also understand why the zealots get so defensive. They have invested in building methodologies and when projects fail, they want to make sure the blame is on the people, not the process itself. “Who made you a process expert?” And the truth is, maybe they are indeed not software delivery process experts. But, shouldn’t the goal be to grow the agile community and help those teams understand how to embrace core agile values?

What Makes an Organization Agile?
I have hinted at this previously, but let me state it explicitly. Agile is not solely about the development team, it is about the organization. The testers need to work hand in hand with developers. The architects need to come down from the ivory tower and join the teams. The business analysts need to stay involved and collaborate with development. Discussions and demonstrations need to be ongoing and repeated. Project managers need to relinquish command and control practices. Executives have to adopt new metrics and change organizational structures. Traditional role boundaries start to bleed together and disappear. This is what makes agile transformation much more difficult than deploying agile from inception at a small startup. Organizations and people are resistant to change. Or so it is said. In actuality, change is unavoidable, and even more so, change is welcomed all the time. What organizations are really afraid is losing control. How do we keep control during an agile transformation? That sounds like another good blog post and may even make use of an agile swear word – governance.

What Makes You Agile?
How would you answer that question? For me it is not about the ceremonies or practices, but rather the underlying core values and principles. Agile is a maniacal focus on responding to change, collaboration, quality, working solutions, providing value, and broadening skill sets.

Go. Be lean. Be agile. Just don’t be fr-agile.