...copyright Elena Yatzeck, 2010-2017

Monday, August 30, 2010

MegaAgileTron and Sharpie Man Move To A Smaller Tent

A friend of mine works for a company that did some one-stop shopping and hired the vendor of their agile project management software to also run their IT organization transformation.  Handily, the transformation consisted of implementing the tool, which I'll call MegaAgileTron, and then providing training on the tool.  Apparently, at my friend's Friday's stand-up meeting, one of the people on his team said proudly "Wow, I have a lot of work to do today in [MegaAgileTron]!" And everyone nodded enthusiastically about how agile they have all become.  As my friend said, "it wasn't funny at the time, but now that I think about it..."

Agile project management tracking software has become its own industry, and the gadget-oriented CIO may be tempted to think that the best way to take her organization to the next level is to buy, install, and provide training on a new project management tool.  This approach, once taken, has the handy side effect that she can now easily prove the "success of the agile transition" by grabbing some readily accessible metrics, like "how many people are using the tool?" or "what projects are being tracked in the tool?" or, in the extreme case of my friend using MegaAgileTron, "how many hours a day are people spending in the tool?"  And really, that's fine with MegaAgileTron, especially for the short term, because at the end of the day, they're in business to sell licenses.

On the other hand, agile zealots, with whom I uneasily align myself at all times, sometimes lose track of the fundamental fact that what you're trying to do in your organization is become more effective, not become more agile, although of course we all like to think that these two are correlated.  But if purists believe it is "more agile" to limit oneself to a wall covered messily with sharpie-annotated sticky notes than to install a tool, then they will advocate violently for the sticky notes and the sharpies.  I am aware to my sorrow of a project on which purists were asked to update both the card wall and the electronic tool, and refused to do it, because "double-entry isn't agile," even though for their particular situation, double entry was the least evil of the available options to keep the project moving forward.

So as MegaAgileTron takes on Sharpie man for the banner of agile process purity, I have to ask myself, "why?"  Why does talk of "agile" slide so quickly into talk of processes and tools?  I think the answer is that it's harder to talk about something big like "IT's return on investment to the business" than something small like "what did I do when I clocked into work today."

An effective organizational transformation to agile techniques and philosophy requires an old-fashioned quantifiable business case which should be revisited by a high level corporate steering body on a regular basis for results.  "Make a good business case" is not an agile concept--it's a business concept upon which agile depends on many levels, from justifying an agile pilot to justifying any given project within the agile portfolio.  Building a good business case is hard, and requires the best attention of your best business strategists.  Tool-buying decisions and decisions about how an individual project team plan to conduct business can be done with far less rigor in most corporate contexts, since these decisions get made by "the tool department" or the individual line manager.  With time, passion, and energy at a premium in all corporations, the business case doesn't always get made, and that's to the detriment of the transformation.

If you're toying with the idea of "going agile," please work to understand how you will measure the actual business value of changing your IT organization, before you do much investment in highly paid internationally acclaimed speakers, professional services, tool-buying, or training on tools.

In its simplest form, the Agile Manifesto would ask you whether post-transition, you now get "Working Software" out of your IT organization:
  • faster, 
  • cheaper, 
  • and/or with more reliable quality. 
Or if you're taking a longer view, you might also measure whether your organizational transformation has impacted:
  • executive confidence (does the process seem more predictable than the old process, allowing for executive flexibility as the project team learns more?), 
  • customer satisfaction (do they like you better now that they get to participate in your process?), 
  • sales (overall, has your company reputation improved, and with it, your overall new sales?), and
  • employee turnover (do your employees like the new process, and flee less?).
If you are writing software for the internal use of your own company, rather than sale to customers, you may also want to measure:
  • how productive are the users of the software, in terms of the goods or services THEY produce, before and after the change to the IT organization.
You will also want to factor in the cost of change itself--your experiments with agile will have their own cost, so in your measurements, you will want to make sure to ask whether things are taking longer or being more expensive for your company due to the use of agile, in a way that will remain relatively constant over time, or whether the effect is a short term effect of being in transition.

Luminaries like Jim Highsmith and Michael Mah have long since made a rigorous, quantified case for how agile software development has paid off in businesses like yours in the past.  Read their work and ponder its impact on your business.  But as you actually proceed with your own transformation, let me just issue the simple reminder that you want to keep focused on the health of the business as you proceed, and not get lost in the sideshow antics of the process people.  Choose tools to use based on the business problem you're trying to solve.

[Disclaimer:  I am necessarily agnostic with regards to tools, since I think they should be chosen to fit your actual business need, but my firm, ThoughtWorks, does sell one, Mingle, which seems to have been quite good in a lot of contexts.]

Friday, August 27, 2010

Et tu, Toyota?

I was gripped by anxiety today when I found out that Toyota is recalling another 1.13 million vehicles, and even more if you count Canada.

I worry for Toyota owners of course, American and Canadian alike.  But professionally, I feel even more worried for us advocates of lean and agile principles who have depended on Toyota to provide a one-word motivation to our audiences.  For decades, Toyota has been our hero, and even if we quickly disavow the company now as having any major role to play with lean, the questions about Toyota’s quality and processes are going to come back to haunt us, and we need to be prepared.

So today’s recall news brings agile presenters (and would-be Toyota owners) together to ask three new common, and newly urgent, questions:

  • Is there actually a problem?  Do friends let friends buy Toyota any more?  Or is this nothing more than an emotional media circus?
  • If there is a problem, was it caused by Toyota’s adherence to lean principles?  If so, what do we need to adjust in our teaching of lean?  If not, what do we need to do in describing how Toyota fits into our world view as agile/lean advocates
  • What should our go-forward plan be, as consumers, and as advocates for lean/agile principles, in light of this year’s Toyota-related events?
Is there a problem? 

Well, as agilistas of all races, colors, creeds, and sexual orientation are prone to say, “it depends.”

Thesis 1:  this is media hype, like what happened to the Audi 5000 ten years ago.  Jamie Flinchbaugh provides this excellent summary of the journalistic and blogosphere debates around the Toyota Affair.  He points to a valuable article by Business Week’s Ed Wallace on how media coverage of this type of incident has fanned the public’s tendencies to prefer the hype around an emotional story to verifiable facts, which tend to be less interesting.

Thesis 2:  Toyota has an actual long-term problem with their electronic throttling system.  Today’s recall supports a theory the New York Times advanced already in February that Toyota has had problems in their electronic throttling system design which go back to 2002 or even 1998, and what we saw in 2010 was not just driver error, oversized accelerator pedals or loose floor mats.  The smoking gun here is that when the first recall broke in January, Toyota brought consumers in to have their accelerated pedals shortened and mats tightened, they also did a quiet computer reflash on the vehicles to allow the braking system to override the throttle, which it didn’t previously do.

The ABC story which provided the most details about the throttling problems, however, included footage which was clearly doctored, which suggests that whatever the truth of the matter, hype is part of the equation as well.

If there is a problem, was it caused by Toyota’s adherence to lean principles?

Let’s assume there is a long-standing problem with Toyota’s electronic throttling system.  Or even a shorter-standing problem with floor mats.  To what extent should we blame lean?  The Wall Street Journal’s headline article on January 30 discussing the Toyota affair was entitled “How Lean Manufacturing Can Backfire.” 

Mark Graban of LeanBlog observes that the WSJ seems to make frequent ill-informed attacks on agile/lean techniques, particularly “just in time” manufacturing, and if he's right, this is no exception.  If, indeed, the use of large quantities of standard foot pedals was the root cause of the problem, as they explain, that’s hardly a manufacturing choice Toyota can be said to have made from lean principles, which calls for small, quality batches.

Moreover, if Toyota knew about problems with their foot pedals, floor mats or electronic throttling systems and didn’t act on them, then Toyota was definitely NOT following fundamental principles of agile and lean that call for “failing fast” and “building in quality.”  Toyota is famous for providing a literal “emergency stop” cable which could be pulled by any person on the production line who finds any fault in the product, and which should result in an immediate halt to production until the problem has been fixed.  As Gad Allon says eloquently, there were enough quality problems being reported to Toyota as early as 2002 for someone to have done something much earlier.  He calls this “The Andon Cord that Wasn’t Pulled

Toyota, in fact, persists in denying that there’s a problem with the throttling system, even while issuing soft fixes on it, including in this webinar which provides Extreme Scientific Detail.

So Where Does That Leave Us?  Can We Still Use Toyota Quality to Motivate Agile Converts?  And Should We Buy Toyota?

Any long-term admirer of Toyota and what it stands for may be disappointed in the recent quality problems with the cars, and with what seems like clear violations of the agile/lean philosophy that should have prevented these problems.  However, as many others have said quite eloquently, Toyota is still quite exemplary in most ways, under most circumstances, compared to the competition, particularly when it comes to using lean processes to leverage generally higher quality. 
  • Long-time Toyota watchers predict that Toyota will continue to beat out their competition in finding and removing these defects, in the long run.
  • And as Marty Larivieri says, the fact that the WSJ is using the example of Toyota to show that lean principles lead to lower quality could certainly mean that “apparently someone who is too young to remember the Chevy Citation and its X-body siblings is now old enough to write for a major newspaper.”   
All the same, in my slides, I am temporarily going to start talking about Toyota the way people talk about their favorite rock band, and explain “I only like their old stuff.”

Monday, August 23, 2010

The Agile Ronin

I was recently cheered and inspired by Jonathan Rasmussen's post on the "agile samurai," also the title of his recent book.  In his blog, he suggests that the the samurai, unlike the "rice pickers," are the ones who:

  • say what needs to be said
  • call BS when they see it
  • laugh in the face of unrealistic schedules and expectations
  • tackle all the hard, complex, thorny stuff no one else wants to wade into
  • are technically excellent at their craft
  • take pride in their work
  • and are comfortable in their own skins
I liked this description, but it made me nervous in some ways as well.

So since I'm prone to zealous pursuit of metaphors, to the point of finding and reading two or even three results of a Google search as I look for enlightenment, I investigated real-life samurais and found that they were actually constrained significantly in their behavior, living by a creed of "loyalty to one's master, self discipline and respectful, ethical behavior."  Such a person might think twice about pushing back on authority in a corporate context.

In fact, it appears that the bold warrior implied by Rasmussen's description is most likely not a run of the mill samurai, but rather a ronin, the "masterless samurai," who lived by his own ethical code but had no permanent master.  Prior to the awesome 1998 movie with Jean Reno, ronin were already famous in Japan through the mythology that grew out of the eighteenth century heroics of the "47 Ronin." Wikipedia says that the story "was popularized in Japanese culture as emblematic of the loyalty, sacrifice, persistence, and honor that all good people should preserve in their daily lives."  But this story also holds some cautions for people who value, say, continued employment.
From http://japanesetex-style.blogspot.com/2011/02/47-ronin-kisshoji-temple-osaka.html
Without giving the full plot away, the incident involved 46 principled men revolting against all established authority to avenge their leader, the 47th man, who committed ritual seppuku at the request of his boss, the shogun, rather than apologize after he physically attacked a person who severely annoyed him.  Before he died he announced his only regret was that he swung and missed.  Of course, once the 46 successfully killed Kira, the annoying person who caused all the ruckus in the first place, they were also immediately requested to fall on their own swords, literally, which they did.  

In the aftermath, commentators complained about a number of things, including that the 46 should have slit their own bellies immediately upon taking their revenge, rather than waiting for orders, since they were being cowardly if they hoped for a non-death sentence.  Others argued that they shouldn't have waited a full year to take their revenge since the annoying person at the root of the problem was 60 and could have died in the interim.  As in so many real life situations, an odd situation seems to have spun out of control and then been very weirdly interpreted after the fact.

At any rate, at the end of the day, the implied hypertext behind the concept of the "agile samurai" is probably a little disruptive to the central message of the book and the blog.  It is sometimes good to remember that discretion is sometimes the better part of valor.

Friday, August 20, 2010

The Good Silo -- Servant Leadership, Self-Organization and Yes, Old Fashioned Middle Management

Please be honest.  Does the concept of "self organizing teams" frighten you at all?  Do you picture everyone in your organization trooping into some large room with no chairs and being asked to arrange themselves into color-coded "pods" and then come up with plans for total quality management, preferably presented as a skit with lame props to upper management, who, naturally, will not be participating in the pods in any in-person sort of way?

If you're in charge of an IT organization of, say, 250 people, and you want to really shake things up the way British Telecom did, you would be fully within your rights to ask:  so how do we structure this?  And you should demand an answer from your transformation coach more specific than "well, we'll set up a bunch of collocated self-organizing teams" which is implicitly followed by the silent phrase ("and your middle management will hate it, hate us, and hate you, but mostly hate us, and won't THAT be dramatic??").

I'm going to break a pretty strong agile taboo here and suggest that you just go ahead and set up a new hierarchy.  Yes, that's right.  If you don't already have them, you should hurry to set up old-fashioned line of business silos.  Certainly I'll allow for piloting first and the like, although strictly speaking, I don't think it's necessary.  And certainly, I'll quickly explain why these will be "good" silos, not "bad" silos, if you'll bear with me for a moment.  For now, let's just say that the best way to structure your teams is going to be to start by having everyone focus on the customer.

This structure will naturally create the need for multiple levels of leadership, and give each of your middle managers something quite meaningful to do:
  • Somebody should be on point for each line of business.
  • Everyone else should be organized into a tree structure attached to this person where managers are held responsible for their area of authority, and wherein no manager is responsible for more than 10 people.  Really, six would be optimal.
  • The nodes of the hierarchy should be project teams working off of a shared program backlog for the whole line of business.
That's it, you're done with the hierarchy.  But now comes the hard part:  servant leadership and, yes, self-organization.

When you publish your org chart, borrowing from the Swedish as is so often the case, you are going publish it upside-down, at least philosophically, or even literally as this Houston, TX, construction firm does:


As symbolized by the chart, you will start your agile improvements by recognizing that the most important people in your organization are the project team members who are delivering the software to your customers.  This transaction is the reason your company is in business.  These teams are cross-functional and self-organizing, once they are set up, and through their interactions directly with customers, they will tell you what you need to do.

Meanwhile, each manager is in place to carry water and remove obstacles for the team above them.  Sure, then as now, as you move further away from the project team level, you will encounter higher salaries and fancier titles, but to some degree, these will now be justified, because you need skills that are harder to find in the marketplace as you move down this chain.  And what are these skills?
  • Monitoring the team for problems and protecting it from bullies, removing them where necessary.  The more points in the hierarchy, the more challenging it is to figure out who the bullies are to remove them.
  • Coaching, including providing salary and bonus related financial incentives to individual team members, based on how well they are working within the structure.
  • Representing the team's actual needs on occasions when attendance by everyone would be a pointless free-for-all.
  • Encouraging and organizing cross-team and cross-boundary meetings at all levels, so that within and across lines of business, the whole corporate structure can take advantage of mutually known best practices to continue to do the best thing for the customer.
The stress in this new structure is on non-cynically using one's authority to consistently tune the individuals and interactions which are the most important part of the agile endeavor, and keeping everyone focused on the customer.

The result of the new structure is that although each line of business has a boundary, the members of these hierarchies are given incentives to work together, within and through their boundaries, to do the best they can for the customer.

Your job, as the owner of the new structure, is to monitor it to ensure that it behaves as though it is upside down, primarily by observing the human interactions which are occurring within it on a day to day basis.

When you hear "servant leadership," you may be even more frightened than you were about self-organization.  Perhaps you think of socialism, or maybe a "rap session" someone made you attend in your youth.  Maybe you flash back to when they tore the desks out of the library at your university and filled it with orange bean bag chairs, and you all started calling it "the Romper Room."  And even though you're super liberal on the political spectrum, or maybe you're not, maybe that scares you.  If so, okay, fine, we're all scared.  But let's get over it and start building some silos.

Wednesday, August 18, 2010

Distributed Agile: It’s the People, Stupid, er, Honored Colleague

Let's say you're provisioning a new project team with members on multiple continents.  As you look for ways to do your work quicker, better, and cheaper, you may ask yourself: “Can we approach this project in an "agile" manner?” But you may have just read Martin Fowler’s excellent description of the ideal team room, and detected that the prototypical agile workspace isn’t big enough to span multiple time zones.

Should you give up your dream of using your new project to launch the agile revolution at your firm?  Well, yes and no.  A distributed agile team will not gain all of the benefits of Alistair Cockburn’s “osmotic communication.”  The team members in Bosnia won't be overhearing the Toronto office's discussions and benefiting from them.  On the other hand, you may still prefer for your distributed team to be agile rather than not.  You don't want to kill something good while waiting for the perfect.  And you may be acting on a mandate from above which gives you no choice, “self-governance” be damned.  So here’s what you do.

Years (or even millennia, if you follow Mary Poppendieck) of shared tribal experience with agile techniques suggest that a distributed project, like its collocated counterpart, will succeed or fail directly in proportion to the effectiveness with which the people on the project team work together.  Lilia Efemova has a wonderful discussion about the need for communication and common ground on project teams.  If you can build team trust and understanding across multiple locations, you can get the team to do things like “scrum of scrums” and whatnot in a heartbeat.  The reverse is not always true. 

Start with four basics:

·      Start with a careful vocabulary and go from thereDo not refer to anyone as “offshore.”  Whose shore are you talking about?   For best team morale and velocity, the premise must be that team members in all locations are equal in status, and each person is especially valued for his or her unique cultural background, project approach, experience, and personality.

·      Don’t even think of starting a distributed agile project without a shared online information radiator, preferably one that can be electronically projected onto a wall or smart board or the like for all to view at each site.  Agile zealots are quick to say that you should start with “post-its and pens,” and consider “the tool to be secondary.”  It is not.  Although a tool can’t create a high-performing environment for everyone on the distributed team, lack of a tool will certainly create miscommunications and lack of trust quickly and painfully

If you have no tool, you will end up with a power imbalance across teams where one team has control of the radiator and the other teams don’t.  Please don’t do this.  Here's a ranking of the options:

o   Looking for trouble:  one physical lo-tech radiator kept up to date by local scrum master and distributed by digital photo to other sites.
o   Better in theory than in practice:  physical lo-tech radiator kept up to date by teams and synched by each scrum master through digital photos and the like.
o   Good:  shared online tool which everyone updates centrally, and which you project at local standups.
o   Awesome:  shared online tool which everyone can update and which is always projected on a wall or smart board at all sites.

·      Start the project off with an in person meeting for the whole team.  Try for two weeks.  Figure out the most cost-effective location for the meeting, and bring everyone there, and have your project inception meeting.  Make people share rooms.  Put people up at team members’ houses.  Get the team together in person to get to know each other.  Team members will do far better during subsequent virtual contact via email, text, camera and phone, because they’ve already gotten to know each other’s quirks in person.  After this, send single project team members to different sites on occasion to reinforce the in person connections.

During the project itself you may want to experiment with an always-on reciprocal webcam arrangement or a shared virtual world within which each person represents him or herself with an avatar sitting in a shared room, to do better than you can do with phone calls and texts.  But regardless of what communications techniques you put in place for the duration of the project, it must be planted and periodically fertilized with in-person meetings. 

·      Team build. Even if you are unable to get your team together in person, allot some time during project initiation to creating common ground and a basis for communication on the team.  I personally eschew events involving trust falls, ropes courses, and anything with a blindfold.  What I would strongly recommend instead is that you start your project inception by cheerfully but efficiently forcing everyone on the team to understand each other’s professional persona (not their fear of heights).  Have everyone take the Myers-Briggs test, the interesting MAPP assessment, or the currently popular StrengthsFinder test, and discuss the results together.  (You choose the tool—these are just three I know about!)  Do not even think of having trust falls.

Sometimes in the thick of things, I think we lose track of the first premise of the agile manifesto—this isn’t just a set of techniques.  We win by focusing on individuals and interactions, and we just have to work harder on those interactions when a team is distributed.