pledgerwood

Nov 082013
 

Two Halloweens ago, Agile Wolf stalked the corporate landscape of Kansas City.  His silhouette wove through the tall grass of the Silicon Prairie, only pouncing out to declare nuggets of agile wisdom and occasionally hip-hop dance.

This year, his cousin (I don’t know how that works from a species perspective – just go with it) Agile Horse made the scene, bringing thoroughbred lean counsel to the small to mid-size Prairie Village business sector and occasionally causing traffic difficulties on 75th.

Agile Horse lounges around with GEICO spokesman

Agile Horse lounges around with sales executive disguised as GEICO spokesman

Agile Horse expounds on the virtues of Kanban

Agile Horse expounds on the virtues of Kanban

Taking a break to hang with friends

Taking a break to hang with friends

Sporting the executive look

Sporting the executive look and causing aforementioned traffic difficulties

Blending in with the nice attorneys over on Windsor

Blending in with the nice attorneys over on Windsor

Glamour shot

Glamour shot

Enhanced by Zemanta
Nov 062013
 

Local staffing firm and winner of the Most Non-Ironically Orwellian-Sounding Twitter Handle Award tweeted this the other day:

All successful change initiatives start here

[sic]

That’s a pretty bold statement for a company that’s never done a change initiative.  All successful change initiatives start at the top.

This idea is actually not unheard of.  You hear it other places, mostly as the result of disillusionment.  You can’t be an agile consultant very long without having the surreal experience of a company hiring you to help them change, then deciding they don’t really want to change all that much.  As agility begins to cascade upward and outward threatening all extant presuppositions and practices, they stand, Gandalf-like, bellowing that YOU SHALL NOT PASS and breaking the bridge before all that hubbub you’re creating in their developer teams gets to accounting or whatever.  There was one organization in particular where I felt they were paying me a very good amount of money for the privilege of ignoring me altogether.  Like I said, it’s a very surreal feeling, especially when people can and do ignore me for free.

However, the truth is that change that begins at the worker level can and does work.  In fact, my most successful “agile transformation” started with a development team, and once people saw the points being put on the scoreboard, the changes cascaded throughout the organization, changing their culture, levels of trust, rate of delivery – all kinds of good stuff.  I’ve also seen change initiatives start at the top and fail miserably because, even though management was behind it, none of the workers were.  It was something forced down on them, and they could get with the program or get out.  People were resentful at worst and apathetic at best, confident in the knowledge that this was management’s new fad, and next year it would be something different.  Change initiatives that start at the top without the full buy-in and participation of the ground up have a high risk for failure, and I speak from experience.

So, is it the case that all successful change initiatives start from the ground up?  That’s also incorrect.  Nobody can destroy a company’s agility like their leadership, and I’m going to go along with Deming here and say that the vast, vast majority of a company’s performance problems rest with leadership (ironically, vast amounts of time and money are spent on structures trying to pinpoint failures in the work force – “We need to hold our people accountable” is usually followed by an unspoken “because the problem sure isn’t me”).  Your pilot project can outperform everything in company history, and management can still shut you down.  It would be nice if good results were the final word in these kinds of decisions, but anyone who thinks data is the final word in an argument has never been in a long-term relationship.  So, change initiatives that begin at the roots level without the full buy-in and participation of management also carry a high risk of failure.

If change initiatives that start at the top are prone to failure, and change initiatives that start at the bottom are prone to failure, then what are you supposed to do?  Start in the middle?

The first part of the solution is, as Deming says, “The transformation is everyone’s job.”  You have to be willing to address the organization as a whole.  Agility has ramifications for everyone, and can actually be harmful if you only optimize a particular segment.  Can you imagine what would happen if you could make the front driver-side tire on your car go 50mph faster than the other wheels?  A similar thing happens to organizations where agility is only increasing in one place.  If you want to transform an organization, everybody has to know that what you are doing is going to affect everyone from the CEO to the night janitor.  Naturally, this can cause concern, and this leads me to my second part of the solution.

The second part of the solution is that organizations are resistant to change because of the way we try to make them change.  When we blame an organization’s agile adoption difficulties on their industry, culture, or people, we haven’t gotten to the root cause.  The root cause is that your way of changing the organization is setting it off the way a cold virus sets off your body.  “What the hell is this thing?” says your body, and the fever goes up to try to boil it out of you, the snot spigots unload to try to flush it out of you, and sometimes other unpleasant things that tend to happen at inopportune moments.  This is what organizations do to alien matter introduced into their system.  And believe me, brothers and sisters, I am preaching to myself as much as anyone on this point, as I can cite instances in my career when I was happy to blame the transformational difficulties on the company instead of the way I was going about things.

Yosemite Sam

Yosemite Sam (Photo credit: Wikipedia)

Change initiatives have to be done with a respect for people and in a manner that drives out all fear of losing their job (Deming, again).  This is the genius of Kanban: the changes are incremental, evolutionary, and the ideas and decisions come from the people doing the work instead of something imposed on them from the outside.  You can’t just go in like Yosemite Sam hootin’ and hollerin’ with pistols blazing.  When people start responding with resentment or fear, that’s your cue that you have done something wrong; it is not a cue that something is wrong with them.  What kind of misanthrope would you have to be to start thinking about getting rid of people who are actually doing you a huge favor by reacting negatively to what you’re doing?

When you start with where workers are at, and you give them the tools to visualize their work, and you help them define what they’re doing, and you help them measure how efficiently that work is being done, and you ask them, “So, what do you think we should do?” you are on the road to people being valued, giving you buy-in, and coming up with better solutions than you could.  Do you sometimes need to bring in ideas from the outside to get people started?  Sure, sometimes – but even then, it’s something you want them to own, not something they have to comply with.

Change initiatives from the top can work; change initiatives from the bottom can work, but both are risky.  Successful change initiatives start with everyone, and they are done by listening and building up your people instead of forcing it on them or getting rid of them.

Enhanced by Zemanta
Nov 052013
 
Industrial Engineering and Management building...

Industrial Engineering and Management building at the Technion in Haifa (Photo credit: Wikipedia)

I was talking with Lean/Agile Developer and overall smart guy Travis Dietz about requirements, and I brought up my old saw about requirements being inventory.  It’s an analogy that comes from the factory, which is where a lot of the ideas that inform Lean software development and Kanban come from.  Manufacturing was certainly Deming’s primary point of reference.  Principles, techniques, and even artifacts (control charts, flow diagrams) in this way of thinking most likely have their origins (or at least their ancestors) in manufacturing and industrial engineering.

How appropriate is this, really?

I mean, the Agile community has fought and is fighting hard to correct a misunderstanding about software development that we largely owe to NASA: the misconception that most software development projects are not fundamentally different from any other kind of building project.  You figure out what you want, an architect draws up all the plans, and the plans go to the workers to build out.  Because the plans have already been made, you can scale productivity just by adding numbers.  Also, past experiences should enable you to say how long a given development project will take if you can get a look at the plans.

In deterministic ways of building, this works all right.  If I have to make car doors, someone has drawn up the plans for a car door, and it’s my job to crank them off the line.  If my station averages 20 car doors a day, then when you ask me how long it’ll take to make a thousand car doors, I can give you a pretty good idea.  This environment – deterministic construction – is largely the environment much Lean thinking was generated in and is almost Deming’s whole world.

Software development, however, is non-deterministic.  Although you might have experiences that are similar at some level in the past, every problem is a new one.  Every bit of software you write has never been done before (because otherwise, you could buy it or just re-use the code).  Each feature is an act of problem solving and creativity, and we’ve all learned the hard way how quickly detailed plans become invalid.  Once you get to the battlefield, you have to adapt.   Software development is more like making a sculpture for a client than it is building them a car.  Given that the nature of the work itself is rather different than manufacturing, how appropriate is it to use optimizations from manufacturing?

Let me begin by saying that to dismiss insights from manufacturing because it’s manufacturing is pretty dumb.  Many advances in the field of software development did not come from software development, originally, and you should never close yourself off from wisdom that might come from a different field.  If you’re going to rule out every field that is different from software development, then you’ve pretty much ruled out every field, including the ones that you like and use all the time in your software development.  Math is a very deterministic field as well, but you’re going to have a hard time programming without it.

But the question remains, how far can we really take this?  For instance, I have pointed out some things from martial arts that I believe have relevance to software development, but I don’t think practicing takedowns will help us write better software.  I think the solution may be in the distinction between laws, principles, and techniques.

Laws are universal truths that everyone everywhere has to deal with.  For example, people have to sleep.  Therefore, no matter what field you’re in, you don’t want to schedule people for 24 hour shifts all month.  People can only be in one place at one time, therefore, we do not assign people to five separate teams and expect them to be fully available to each one all the time.  They’re laws built into the nature of the reality we all share, so dealing with these laws is automatically going to be something that spans all fields.  Any insight that comes from some fundamental law of reality is pretty much guaranteed transferable somewhere else.

Principles are also general truths, typically derived from laws, but they are not always universal to all places and all times.  “Avoid the Bubonic Plague” is a good principle, but generally speaking, it’s not really applicable to most people today.  On the other hand, we might consider a principle like, “Employees should be empowered with the tools and authority they need to do their work efficiently.”  Although you could probably find an edge case or two where this didn’t apply, it pretty much applies everywhere.  Maybe someday when we live in a telepathic hive mind, concepts like “employee” and “authority” will no longer serve a purpose, but at least in our current context, it’s a pretty good principle and relevant to all kinds of work.  When applied to many different fields, you see good results.  I’d say that the vast majority of the concepts and recommendations of Lean, Kanban, and the various thought leaders in that area operate at this level.  You have to understand how the principles apply in your context, but they are more or less truths that are bigger than a specific field.

Techniques are specific implementations/practices of something, usually derived from principles.  These are only valid insofar as they operate in accord with their principles and are usually heavily conditioned by specific context.  For instance, in most of the apostle Paul’s letters to churches, he tells them to greet each other with a holy kiss (Rom. 16:16, 2 Cor. 13:12, 1 Thes. 5:26).  In the first century near east, a chaste kiss was a culturally standard form of warm greeting.  It was a way to show that you were a community and had a level of affection for one another.  In modern, American churches, you are likely to be maced when trying this out.  In our time and culture, a kiss has romantic connotations, or at the very least suggests a particularly close affection like a relative or a very old and dear friend.

In modern America, the church members might shake hands, hug, smile, slap on the back – something that signifies warmth and community to us.  The principles of community and affection span both times and cultures, but the specific implementations of those principles are very culturally conditioned, and if you went around to American churches trying to kiss everyone because “Paul told you to,” someone would rightly argue that you had confused the principle of Paul’s instruction with the cultural particulars, once they had slapped you.

It is in this area where, in software development, it is appropriate to go through these other industries at the practice level and decide if they’re really helpful in our context or not and, if so, do they need to be modified to better suit non-deterministic work?  One good example is control charts.  We (software developers) generally do our control charts based on probabilities rather than standard deviations, because we don’t have a consistent completion time we can use.  The principle is the same – we are measuring our throughput so we can make informed projections, offer our customers service level agreements, and have conversations about things that look out of whack – but as for how that actually gets done, you can’t just lift the practice out of Toyota and drop it onto a software development team.  You have to figure out if the practice will actually help you embody the principle, or whether it might need to look different or be scrapped altogether.

So, I will continue to borrow insights from manufacturing.  That environment is much older than software development, and they have discovered principles about work, flow, quality, and how people perform their best that we’d be idiots not to consider just because it came from manufacturing.  But when it comes to practices (and principles to some extent), we need to make sure we are thinking critically about the nature of non-deterministic work and the best way to embody those principles for us.

Enhanced by Zemanta
Nov 042013
 
W. Edwards Deming--statistician...saint

W. Edwards Deming–statistician…saint (Photo credit: Kazanjy)

In Chapter 2 of Out of the Crisis, Deming presents his 14 key principles for transforming an organization’s management, and by “management,” I mean “the way things are done,” not just specifically a certain organizational layer.  As Principle 14 tells us, “The transformation is everybody’s job.”

This was a fascinating chapter, not just because of the principles themselves, but because I could mentally compare and contrast them with how organizations I’ve worked with have been run as well as what business/agile consultants talk about when they speak of transforming an organization.  A lot of things consultants talk about a lot are not in that list, and vice-versa.  It was also interesting to see the points Deming chose to really hammer on.  Pages and pages are spent on the single-vendor principle (Principle 4), for example.  I didn’t count, but that one point may have more ink dedicated to it (in this chapter) than any of the others.  When leading a software development team, our “vendors” are not just equipment and software vendors, but they are also the people who give us our requirements, so I had to do some uncharacteristically intense cogitification to think through how that principle might apply to that area.

But those details aside, I wondered why his principles seemed so alien to American business.  I mean, the man almost singlehandedly rebuilt Japan’s economy and brought them from being a nation shattered by war into a lead contender in the world economy.  When you think about it, that doesn’t leave the rest of us with very many excuses, does it?

“I’d love to take the time to focus on quality, but our sales were lagging last quarter, and we really need to just get some things out there to meet some marketing deadlines.  We’ll track back around and improve things, later.”

“Yeah, I know what you mean.  Times are tough.  Last quarter, someone dropped atomic bombs on our major cities.  So, you know, that’s similar.”

If Deming’s principles can bring your business to roaring prosperity after that, it seems like more people would be doing these things, or at least talking about them, right?  He had worked with organization after organization, employee after employee, manager after manager, country after country.  He wasn’t infallible by any stretch, and his thought came out of a particular context, but still – why does it seem so different than what people are on about, today?

I think one reason for this is that Deming had a different end-game for businesses than most of us.  In Deming’s eyes, businesses existed to build a nation’s wealth and increase the prosperity of her people.  It’s really been interwoven through everything in the first couple of chapters.  Businesses that follow his principles prosper in the market, which enables them to provide more and more better-paying jobs to more people for years and years to come.  The idea that a business exists primarily to make a lot of money for an individual (or small group of individuals) to be discarded when it has served that purposes seems kind of alien to his way of thinking.

In Deming’s mind, if I start a business, it should be so that I can increase the prosperity of as many people as I can for as long as I can.  This is business eschatology.  This is the telos of your organization: to keep as many people employed as possible, paid well, happy and gratified, and improve your country and ultimately the world in this way.  Of course, as a by-product, you’ll be increasing your own prosperity, too, but you increase your own prosperity by focusing on helping first.

Perhaps this is way his notions of focusing on quality, building long-term vendor relationships, continuous improvement, ditching evaluations, and building systems that bring out the best in your people seem so out of place in the current business consulting climate.  In American business, today, the goals of many business owners are to make as much money as they possibly can in as short a time as they possibly can.  The goal drives your current behavior, which is why many of the discussions en-vogue today revolve around working faster, getting rid of people, getting lean by way of cost cutting, etc.  A lot of businesses are just trying to make as much profit as they possibly can as quickly as they can.  Everything else is driven by that.  Quality is only interesting if it becomes a factor in how much money they can make.  Improving their system is only important if it helps hit a certain profit target by a certain timeline.

I don’t have any statistics on this – it’s purely a personal hunch based on conversations, so don’t take it to the bank – but I’ll bet if you asked a group of startup owners what their long term goals were, a fair amount of them would say they’d want to get the business up to a certain value and sell it.  I’m not condoning nor condemning that.  It’s a perfectly legitimate choice.  It is, however, very different from Deming’s idea of the role a business plays in the economy and in the lives of the people involved, and so the values are going to be different.

As for me, reflecting on things like high unemployment, the reputation for shoddy workmanship certain American products tend to have, the disparity of wealth distribution, an ever-growing class of “unhirables,” businesses that are here today and gone in three years, I don’t know.  You almost get the impression the man was on to something.  The crisis he wants us to get out of isn’t a crisis of bad business; it’s a crisis of national and worldwide economic proportion.

Enhanced by Zemanta
Nov 012013
 
The Deming Institute mentioned you on Twitter!

People smarter than I am who understand Deming liked the article

It’s pretty cool to have an article about Deming’s thought approved by the actual Deming Institute.

I’ll get back to actual blog posts, soon, and stop the shameless self-promotion, but it’s been really gratifying to have that article picked up by such prestigious parties.  Can’t wait for all the fast cars and money to start rolling in!

Enhanced by Zemanta
Oct 282013
 
Different speed limits apply for day and night...

Different speed limits apply for day and night time on this stretch of the U.S. Highway 1 on the Florida Keys (in a Key Deer habitat). Note the nonreflective backing of the day speed limit number. At night only the number on the lower sign is visible in the headlights. (Photo credit: Wikipedia)

A little less than a year ago, Ben Barreth and I were racing at Sadlers, and he asked one of the attendants what the secret was to a low time.  The attendant told him: “Slow is smooth, and smooth is fast.”

See, if you go tearing around the track at top speed all the time, you’ll end up doing things like drifting around corners, brushing up against walls, and having to do massive changes of direction.  You feel this when you race; if you take a sharp corner at top speed, your wheels lock up against the track making that terrible screeching noise, and it takes all the speed out of you.  You have to start building up speed all over again.

Although it might seem counter-intuitive, the fastest way to get all the way through the system is not to crank up to your top speed the whole time; there are key times when you need to slow down to navigate difficult areas and, in the process, you end up going faster as a whole.

I’ve been getting back into my W. Edwards Deming reading (a man who was very clear that problems in American management are process problems, not people problems), and in the opening chapter of Out of the Crisis, he makes the main point that low quality is what’s holding many organizations back.  Low quality necessitates rework.  It makes customers unhappy.  And it isn’t free – someone gets paid good money to put those product defects in, and then someone gets paid to take them out.  He captures the “quality chain reaction” in a diagram that looks like this:

Improve quality -> Costs decrease because of less rework, fewer mistakes, fewer delays, snags; better use of machine-time and materials -> Productivity improves -> Capture the market with better quality and lower price -> Stay in business -> Provide jobs and more jobs

(Deming, Out of the Crisis, Chapter 1)

As one of many illustrations of various facets of quality, he brings up an example of a superintendent he was advising.  The first thing they did was measure the amount of defects produced over time, and they found that although the rate was variable, it was also fairly predictable (average 11% defective products over 30 days).  So, they had a nice, predictable system for producing bad stuff.

How do you get this number down?  Well, in this case, the people defined what counted as acceptable work and unacceptable work with examples of each, and made sure everyone understood.  This one act alone brought that 11% down to 5%.  That’s at least a 6% gain in productivity.  Then you start thinking about that remaining 5%.

The point is, a huge gain in speed was made when the group made a firm decision on what work would and would not be acceptable, and everyone knew what that meant.  Does that mean that it might have taken a little extra time to ensure what you were working on met the acceptable standards of quality?  Probably in some cases.  Would taking the extra time to meet quality standards take longer than finding the deficiencies later and fixing them?  Probably not.

Lowering your amount of rework is the cheapest, least disruptive way to move faster.

And there are many other benefits as well, especially when it comes to customers.  Defects take a toll on the customers who receive them.  It wears down trust, goodwill, and can ultimately drive them to look for someone else.  Driving your workers to produce faster at the expense of quality denies them the ability to feel pride in their work and a sense of craftsmanship and accomplishment.

Focusing on the quality of your work helps you get more high-quality product into the market faster, is more appealing to your customers, and is more enjoyable to your professionals.

Do you know empirically how much re-work accounts for your total workload and costs?  Do you have clear definitions of what’s acceptable quality and what isn’t?  Does everyone agree on those and agree what should happen when work is unacceptable?

Everyone wants to go faster, but just remember that productivity isn’t an open straightaway; it’s a system with sharp curves, critical decisions, and a dependency on a support structure that can only take so much wear and tear.  Slow is smooth, and smooth is fast.

Enhanced by Zemanta
Oct 252013
 

In many ways, it is like one of your toys, but a toy for adults.

Johnny

Original drawing of Johnny Five-Aces

In 2006, a man on the SomethingAwful forums had a vision.  This vision was to solicit volunteers on this forum to create the best computer RPG to date.  This RPG was “The Zybourne Clock.”

When the object enters the timestream, time begins to correct itself. Let me use this example: Imagine four balls on the edge of a cliff. Say a direct copy of the ball nearest the cliff is sent to the back of the line of balls and takes the place of the first ball. The formerly first ball becomes the second, the second becomes the third, and the fourth falls off the cliff.

Time works the same way.

In a very short time, the project produced a prodigious amount of material consisting mostly of bad game ideas, poor artwork, and horrifically written prose (a later parody would introduce the character Dr. Malaprop because of the vast amount of malapropisms).  Any kind of criticism was met with harsh resistance and removal from the project.  Unfortunately, the group’s single programmer fell to this Damoclesian sword after two weeks.

You always had a pension for the dramatic, Johnny.

Once the project materials leaked, the SomethingAwful forums at large had a field day writing parodies, creating “fan art,” and even a fake game trailer and interview.  In fact, far more effort and material has been produced making fun of the Zybourne Clock than was ever produced as actual game content.  Even to this day, it’s very difficult to tell the difference between parody material and original material, mostly because the original material was so colossally bad.

Next few things I want to cover. The change mood command will change the selected characters mood at random. It can only be used once in battle. You can also use an item to change a characters mood by using an item or by seeing a Psychologist. Okay, Ill let you do the rest! Look forward to our next and final installment of tutorials, Timesynch!

Oh yeah one more thing.

Anger <> Hurt

Tense <> Nervous

Happy <> Sad

This Friday, for your entertainment, dear readers, I present you with the keys – the keys to a door – a door to space, and a door to time.  Open this door carefully, for this door, the door you behold and are about to enter through the door, has on its other side nothing other than the Zybourne Clock.

The answer came to me while reading an article out of a Science magazine that I had picked up about 2 years ago. The article basically summarized how the planet got to its current point in its evolutionary cycle and where it had started. It compared key points of life over 20 millenia and now. I sat there in and thought about the article for a good 3 hours. If we could subtely alter the cycle at which the planet terraforms and speed up human evolution, we could, possibly make humanity advance far past wars in a few millenia’s time. My heart jumped into my throat as I ran through the bay doors to tell my colleagues that I had finally found a safe way to alter the way the timeline to such a degree as to not rip a hole in time itself.

As I looked around the room, my excitement faded. All of them looked as if they had just became very ill.

“Doctor, you understand if we do this, We will fade from existance as the timeline corrects itself.” One of my colleagues said in the grimest manner I had ever heard him speak before.

I began to turn pale, and dizzy. I quickly found a chair and used the magazine (that I was subsequently still clutching) to fan myself.

Enhanced by Zemanta
Oct 222013
 
Español: Socarrats Futbol Team

Español: Socarrats Futbol Team (Photo credit: Wikipedia)

All around enlightened guy Bob Marshall told me that he thought my last post was confusing.   What’s worse is that Bob is pretty familiar with the various elements and issues that circulate around Lean/Agile transformations, so if he thought it was confusing, then it’s probably just one notch up the food chain from gibberish depending on where you’ve been with this issue.

This is my attempt to be clearer.

Most organizations, when they transition to something more agile, adopt cross-functional teams as part of that initiative.  For those who don’t know, a cross-functional team is a team consisting of people from various “departments” who work together directly to deliver value.  In software development, this means that, instead of having a group of people gather requirements in this team over here, this group of people who do UI/UX over here, this group of people who do database stuff over here, this group of people who do QA/Testing over here… instead of all that, your teams are composed of one or more people who each contribute collaboratively to delivering an increment of value.

So, the UI/UX team, database team, and so on are replaced by Team Jedi Grizzlies which consists of a business analyst, a UI/UX person, 3 programmers, a database person, and a QA person (or something like that – you get the idea).  Then you have Team Frenzied Waffle Irons over here with a similar composition, and so on.  Instead of having teams siloed by job function, specialty, or skillset, your teams are cross-functional – they are interdisciplinary task forces that work together to deliver value incrementally.

In a football game, you don’t have all your linemen in one group and all your quarterbacks in another group and all your safeties in another group.  Instead, you have an offensive group, a defensive group, and special teams – all consisting of players with different skillsets and specialties necessary to score (or prevent it).

The first challenge to an organization’s culture is, first of all, the concept of team.  Most of our “teams” are really individuals that share a skillset or sit in the same part of the building, but they don’t depend on each others’ work.  We’re like individual silos.  So, like the gentleman in New York, one of the first hurdles to overcome is the idea that we actually need to work in teams.  Organizational success can’t afford to rely on a series of individual heroic efforts.  More throughput, higher quality, greater morale, less stress, more trust – these are the kinds of things that come from teams.

The second challenge is that the teams are cross-functional instead of being separated by function.  Most orgs are well-used to a siloed model and find a cross-functional model alien (and often impractical at first) to their way of thinking and doing.  A lot of procedural infrastructure has probably grown around the siloed model, complete with elaborate schemes of checks and balances to govern the hand-offs.

Having a team consisting of people with all different skill sets working together to deliver something, however, is disruptive.  It’s a huge growing pain, but the culture changes and consequent productivity changes are astounding.  Nonetheless, there are many things about the way you work, the way the company as a system operates, and a whole host of logistical issues that go into forming cross-functional teams.  But one of the key things that has to happen is the breakdown of traditional divisions, and each member of the team thinking of themselves as offering a service to the team – almost like a mini-business with the rest of the team as a customer.

The third challenge is primarily what I wanted to deal with in the last post, although I touched on the others.  As this process happens, inevitably the question comes up of how much crossover is appropriate among the team members.  It just so happens that, right now, there’s not a lot of database work.  So what’s your DBA team member supposed to do?  Could she be a member of another team and split her time?  Yes, that’s a solution that can work.  There are drawbacks to that, but that may be in everyone’s best interest.

But another solution is to have your DBA help with some other aspect of the team, like QA or coding or helping work through acceptance criteria or doing research for the next round of features or talking with customers to show them what you’ve got so far and ask if you’re on the right track.  To go back to the football analogy, if a cornerback intercepts a pass, he doesn’t drop it because scoring “isn’t his job.”  No, he runs with it as far as he can.  If he scores, great!  If not, great!  It was an amazing act of assistance that brought the team further.

Once we have bought into the idea of everyone helping everyone else out, the issue naturally arises of how far you take this.  Should your UI/UX guy learn programming?  Should your business analyst learn professional testing skills?  Should your QA person learn how to work on the UI?

And this is where it can get confusing because there is no one-size-fits-all answer that will apply to every team and every organization, so what I offered is that a focus on how best an individual can serve the team will begin to suggest these areas.  So, rather than everybody learning to do everything, look for the value you can offer to the team and see what opportunities that creates.  If you’re the DBA, for example, and you find that you frequently get done with the database stuff early, but your QA person is consistently swamped, then you might learn how to run test scripts or create automated tests.  If you’re a programmer, and you consistently wait for mockups from UX, then create a basic one in their tool or in HTML or on a napkin and start collaborating with them to help get the ball rolling.  The possible combinations are as unique as a team is.  I offered a way I like to give people on the team exposure to different areas.  The developer may not be a UI expert, but they can do in a pinch.  And so on.

But what I also wanted to get across is that you don’t have to sweat this principle.  Everyone does not need to be alarmed that they have to get into all kinds of additional areas in-depth in order to have an agile team.  By all means, keep working on the things that motivate you, but don’t forget that your role isn’t to become the world’s most productive programmer – it’s to help your team deliver value.  Sometimes, that means doing things outside your box.  Uncomfortable things.  Unpleasant things.  Horrific things.

Like test scripts, for instance.

Enhanced by Zemanta