Tag Archives: Agile

It doesn’t work that way in enterprise

This title immediately caught my attention. Due to the recent work-related frustrations, I’m on the constant lookout for how to make things better. Peter Smith’s talk “It doesn’t work like that in enterprise” seemed promising. But to tell the truth, I was dissapointed. I think it’s important to sometimes have a rant or a good laugh, share the painful daily frustrations and simply vent the steam, so there’s a place in this world for Dilberts and Expert Beginners. But I’m a bit worried that while many people agree on what the problems are, there’s not much content when it comes to solutions. Contrary to the popular belief, there are some and at the end of the post I recommend my four favourite resources. Check them out!

I dream about the day when conferences will be full of practical advice and sucess stories about influencing change. I want to hear about tools that I can use in various settings, backed by facts and solid research. After all, change is pretty important in the Agile world. But before we get there, the most popular advice remains, obviously…

Get real, stop whining, just deal with it

“If you’re like most people, you face several influence challenges that have you stumped. For instance, at work you’re fighting an uphill battle. You’ve given your heart and soul to a quality-improvement program, but your best efforts to make quality part of the everyday culture have yielded no improvements whatsoever. None. (…) And you can’t fix any of this. (…)

Fortunately you’ve learned to follow the words of a well-known prayer: Every day you ask for the serenity to accept the things you cannot change, the courage to change the things you can, and the wisdom to know the difference. Somehow that gets you through.

And that’s the problem. It’s everyone’s problem. (…) We tell ourselves that we’re not influencers, and that it’s time to turn our attention to things that are in our control. We seek serenity.” 

(from “Influencer: The New Science of Leading Change”)

It’s hard for me to believe that somewhere in the world are developers that use USB stick as a CVS. I feel sorry for them. So what? Should I lower the bar, stop striving for more and be content with where I am now, just because we use Git? Shouldn’t we, as an industry, strive for more? Learn and share the ways to make things better? Constantly get better as professionals and as people?

It’s not only that I believe in the latter. I just can’t be “reasonable”. When I try, I am miserable. My productivity drops. My life sucks. I’m unhappy. So I gave up on praying for serenity long time ago. It just doesn’t work for me. Serenity might make me come to terms with conditions, that I deep inside never will accept. When I get in my “be reasonable” mode, usually after a few days I’m so miserable, that I inevitably go back to my “let’s change something” mode.

I’ve tried it and it didn’t work

The other common theme are experiences of very smart people, who tried, they did their best and yet, they failed. Let’s be honest, changing the world is hard. Changing the way people work is hard. Influencing organizations is extremely hard. It’s natural that people resist changes, because even change on a personal level is hard.

Most people that attempt influencing changes get discouraged, they become disilusioned and bitter, they give up. Instead of trying to change something, they move on and find a place where there’s no need for constant fights. If you’re in this situation, lucky you, that’s probably the best position to be at.

But those kinds of places are quite uncommon and hard to find, it might take a lot of time before you get there. Sometimes it looks good from the outside, but is less appealing when you’re on the inside. Sometimes the stakes are too high and you simply can’t afford to change jobs. Avoiding less-than-perfect places and people sounds good in theory, but is not that easy to apply in practice and you can never guarantee that “moving to a better place”, wasn’t a mistake after all.

But there’s hope

Next time you see a need for change don’t get angry or discouraged when people resist (yeah, I know it’s easier said than done, believe me:)), don’t take it personally. Accept this reaction as a fact, it’s expected. Instead of fighting, prepare for it. Go to the bookstore or open your favourite browser. But this time don’t laugh at the latest Dilbert strip. Don’t look for consolance and understanding. Look for solutions. Somebody already solved all your problems (and more).

We like to believe that we’re unique. We’re unique as people, our work places are unique, our society is unique, finally, our problems are unique. This is true to some extent, but most “unique” parts don’t matter that much. Common themes in problems with management or motivation or leading change are the same, independent of industry, culture or language. You need to adapt each technique to your specific situation, but you can use it anywhere.

Even if you stick to your “I’m different” argument, I think you will agree that most of our/your problems are not as difficult as taming HIV epidemic in Thailand, getting rid of Guinea worm or resocializing ex-gang members. Yet, all those problems were already solved by somebody, somewhere.

Some people (already) know how to do it

“[Looking for serenity] would be a good tactic were it not for the fact that the problems we’ve listed (…) can be and have been resolved by someone somewhere. That’s right. There are actual people out there who – instead of contually seeking the “wisdom to know the difference” – have sought the wisdom to make a difference. And they’ve found it. They’ve discovered that when it comes to changing the world, what most of us lack is not the courage to change things, but the skill to do so.”

(from “Influencer: The New Science of Leading Change”)

I’ve been on a lookout for practical advice when it comes to change for quite a long time. Most of the material is purely motivational, hard to apply. Here I want to recommend four resources that I find most valuable and practical, I’ve learned a lot from them and every time I go back, I still learn something new. Some tips are very easy to apply, others might take years to master, but as far everything I’ve tried worked and helped me.

#1. “Influencer: The New Science of Leading Change” and other VitalSmarts resources

Those resources are not tied to any specific industry or type of organization. The techniques will work for professional settings as well as dealing with teenagers or issues with a local community.

The most important take-away for me was understanding how many areas we need to take into account, when planning any change (motivation and ability on personal, social and structural level). You can have a quick look at this concept and useful questions at  Influence Change Planner handout. If you focus only on one of the six areas, there’s a high risk that your impact will be too weak to influence a lasting change. Remember, change is hard. We should analyze inhibitors in multiple dimensions and use multiple sources of influence to maximize our odds of success.

A big “AHA!” was for me realizing that sometimes change can be really easy, if we focus on the right area. For example, it doesn’t matter how motivated people are, if there’s a structural obstacle to change. Moreover, most of the time we can attempt change in mutliple ways, but some solutions are more effective/cheaper/easier/faster than others. I vividly remember the example where cooperation problems between chefs and waiters were solved by removing the need for direct communication. All they needed was a metal spindle (read the story “William Whyte ‘s 50 Cent Metal Spindle”).

#2. Jurgen Appelo’s books and Happy Melly project

Jurgen is focusing more on management in the context of IT, but also takes quite broad approach. If nothing else, he’s an excellent aggregator of high-quality resources. I found my #1 resource recommended in one of his books.

I think the most imporant things I’ve learned from Jurgen is that – like it or not – we’re all managers to some extent. We don’t need an official title to be leaders and we all are responsible for how our organizations operate. We can cry and whine, we can deny it or we can learn to use it for our (and other’s) benefit.

I also find very valuable the fact that he fully acknowledges that management and leadership are complicated. He looks for inspiration and solutions in various places, focusing on tools that have some scientific background (especially complexity theory). Here’s very practical, so if you are short on time and hate all those strictly “inspirational” pieces, “Management 3.0” might be your new favourite.

#3.  Esther Derby, Don Gray, Johanna Rothman and Gerald M. Weinberg “Essays on Change Artistry”

I haven’t finished reading that one yet, but I’ve already tried to put into practice one tip. It’s basically impossible to influence change if you enter the group as an “outsider” that always knows better and critizes everything, before even they understand the context and get familiar with the people.

Sometimes it’s very hard to resist the urge to call everbody idiots and just assume that actually, in this situation, we for sure know better. The problem is that even if that’s true, we’ll lose opportunity to share what we know with others. First, we have to take care of the basics. Get to know the group members, get accepted by them, learn about their history and context, make sure that we share the common goals and look for ways to contribute to achieving common goals and priorities.

It sounds so obvious and simple, yet, I don’t know many examples when people really followed this advice. I’ve also realized that I’m not too good at it and since then pay more attention to this area. Even if I can’t wait to share my new super idea, I take a few deep breaths and spend some time learning about the current solution and its context. Sometimes it turns out that my solution wouldn’t fit the constraints that currently are in place. Sometimes it turns out I didn’t understand the problem well, before coming up with a solution.

Well… That was just what I’ve learned from one of thirty essays in this book.

#4. Sandro Mancuso “Software Craftsmanship: Professionalism Pragmatism Pride”

Last but not least, I want to recommend my latest discovery. This is the resource completely focused on software development (obviously:)), but is looking at the subject in very broad terms. Sandro took good care of organizing the content and using phrases that stick. Although I was familiar with most of the concepts even before I read that book, I’ve learned a lot. Some concepts were taken to new depths, others were enriched with new insights and specific tips or new examples.

Two parts of the book, that I found especially valuable were related to recruitment strategy and saying no. Taking responsibility for estimates and project success is a hard topic, controversial. I think that Sandro’s take on this matter is excellent, he skilfully tackled the most common myths and provided tips for dealing with hard situations, that most of us encountered in some form.

Wrap up

Influencing change, be it using new tools, changing processes or modifying communication patterns is a huge, difficult subject. You can pray for serenity, in the end I think that is the easier option. But you can also believe that influencing change is a learnable skill.

If at any point you feel frustrated or simply tired of hearing that “it doesn’t work that way” wherever you are at that moment, open one of those books, watch author’s presentations or read their blogs. You’ll find hope and lots of practical tips, that you can start using straight away.

Even if other people tell you otherwise, remember, there’s nothing wise in giving up. Don’t get discouraged when you fail in your attempts. You will fail one way or another, in one or many of them. That’s a normal learning process. Get up, learn more, practice, adapt and try again. Then share your experiences. I can’t wait to hear about it.

Pair programming – is it worth it?

I was recently tasked with creating a “quality improvement” strategy for one of our projects. One of the controversial propositions turned out to be pair programming. How are we going to justify this cost to the client? That question caught me off guard. I didn’t even think that might be an issue. I didn’t even think about mentioning it to the client, too. For me it’s just a natural part of my work, like using CVS. I never had to justify doing that to anybody. In fact, it used to be quite the opposite.

Stage 1: I hate it

For me personally, pair programming was very challenging. It was the least favourite part of my work. I am a perfectionist (luckily, recovering one) and ever since I can remeber, I hated people looking over my shoulder when I was working on something. Even when I was in primary school and my mum wanted to check how my essay is progressing, I got aggressive. That’s the main reason why I always insisted on not having anybody sit behind my back. I hated the idea of somebody staring at my screen. What if they saw me doing something very dumb?

Over time, I got pretty good at using various avoidance techniques, altering aggression with jokes and plain refusal. Of course, I could got away with this behavior at home, but it wasn’t professional to say the least. Pair programming was not only allowed, but strongly encouraged by my team-lead when I worked at VSoft. I’ve also heard a lot about its benefits. Like it or not, since everybody around me was doing it from time to time (and I couldn’t really say no, every time they wanted to pair on some task), over time I simply got used to it.

Stage 2: I learn a lot

My first “real” pair programming experience was slightly over two years ago and I can’t believe how much has changed. I don’t mind other people looking at my code. I love it. Getting feedback is awesome. I like getting new ideas to improve my code during reviews. I got comfortable with criticism, use it to learn about different approaches and coding preferences. At the same time, I learned to defend my point of view, discuss the motivation behind the decisions I made and be ok with changing my mind, when reviewer points flaws in my thinking.

I can’t recall specific words, I don’t remember all of those small and big ideas I learned through pairing with other people. Some of them applied only to the situation at hand. But there were a few that I benefit from today, such as testing untestable code (thank you Lukasz for being such a pain in the neck about it, now it’s second nature:)), getting familiar with all the crazy shortcuts, learning about new tools, etc. I’m also much better in giving feedback to sb’s code and learned a lot by thinking hard how their code might be improved or why something “didn’t feel quite right”.

Overall, once I got over this irrational “don’t you dare look at my code” attitude, my rate of learning went up significantly. Besides, I think that my productivity was higher, when I worked in a pair, because I was fully focused on a task at had. There was no email checking or talking to colleauges. I did my best not to waste somebody else’s time. Unfortunately, I don’t have any hard data to support that claim.

Stage 3: It’s not a silver bullet

When people ask whether pair-programming is good or not, I think the only honest answer is (of course) “it depends”. There are some people I can’t pair with. When we tried working together it was simply counterproductive, because we just kept arguing and nothing got done. Working with some others was challenging, but I learned a lot. Finally, when working with some people I felt that magical synergy, we were more effective together than each of us working separately, because our working styles and our typical focus areas were complementary.

So it depends to large extent on whom we work with. It’s good to get out of our comfort zone, but I think that pushing through, just for the sake of activity when it’s clearly not working, doesn’t make any sense.

Then it depends on the task at hand. When the task is a no-brainer or we’re very familiar with the area of codebase we’re working on and we’ve done similar tasks before, then pairing might be a waste of time. For me it was most beneficial when I worked on something very new or especially complicated. I could have asked for a review afterwards, but pairing seemed to be more efficient way than stopping every now and then to discuss my idea with a colleague.

Stage 4: It’s hard to work otherwise

There are two situations when pairing seems to be great, irrelevant of other factors. The first is introducing a new person to the project. I can’t understand why people don’t see how wasteful it is to give a vaguely described task to the newbie and instructing them to “ask when they need anything”. Even if they are experienced developers, it takes some time to understand business requirements and be able to understand the impact of every decision on other areas. We lose opportunity to make sure early on that they follow our interal standards and practices. Not to mention the frustration they experience, when they happily announce their task is finished, only to be told that they have to re-do it because of some stupid catch they were unaware of (happened to me recently a few times, extremely frustrating experience).

The other situation is making significant changes or working on some complex piece of logic. It’s beneficial to discuss our design ideas, pay close attention to implementation, make sure we don’t make stupid mistakes, that can be avoided by using second pair of eyes.

For me the main benefits of pair programming are exchange of knowledge between the devs (both domain specific and regarding tools and skills) and avoiding painful surprises during reviews or testing (Oh, how could you miss that edge case? How could you not know about this email I sent to XYZ half a year ago? Why don’t you know about our super-secret document, where all this is described? How can you not know that some external app relies on this file being in that location?).

At this moment, I can’t think about any more efficient and sustainable practice for continuous quality improvement and spreading knowledge among team members.

Stage 5: Back to square one

So how do you justify to your client not doing it? Is there any more efficient way for achieving the goals I’ve just mentioned (improving quality, mentoring, sharing knowledge, avoiding bugs)? Is pairing something one should discuss with the client? Should client be allowed to make such decisions for us?

For me the only honest answer is that I can’t justify not doing it. The other ways for konwledge sharing and keeping high standards that I know, are not as effective (e.g. workshops, presentations). Code reviews should be enough for ordinary tasks in an experienced team, but even for them, I think the two situations mentioned in Stage 4 are still relevant. When it comes to clients I believe that it’s my job to be the best professional I can be and client shouldn’t decide on standards in our industry.

I think this is true not only for software. For example, I don’t go to the dentist and tell him he shouldn’t have an assistant, because I have to pay more for the service. I trust that they do their job well and that this is the best industry practice. I also suppose that if they worked alone, the overall cost would be much higher, they would do the same task longer with more mistakes and caused me more discomfort. Better service for less money? Even if not true in every case, I think this is more common than most people realize.

Programmer Anarchy

I’m a self-diagnosed control freak. Sometimes I struggle with the urge of adding an already done task to my to-do list. Just so I can cross it and make my list look right. Look perfect. Look like it mattered. Doing something without a plan makes me feel uneasy. And this is in my “unprofessional” life. In professional one I’m far worse.

So Fred George really hit a nerve, when he said that the only reason we have plans and management is that we don’t trust each other.

I really loved it when he said they use only one metric, which is how much money they’re making. As long as they make more money, devs can do whatever they want and consider valuable. That’s it. Can’t get any simpler than that. Keeps you focused on the big picture.

But claiming that plans are esentially useless tools, that are mainly used for keeping track who should be blamed if things go wrong… Claiming that managers are simply people, that make sure the right person is blamed… Now, this is a completely different kettle of fish.

At first I dissmissed it as a standard wishful thinking of yet another Agile nut.  We got rid of documentation, why stop there? Let’s cut the costs even further and get rid of nearly all the people apart from devs. There’s nothing they can’t do, so why waste money on all the other “specialists”? After all only devs are the “true” Agile stars. Let’s make an all stars team…

Two weeks later I’m still thinking about it. Each and every day I’m more convinced that the guy nailed it and what he said applies to “non-product” companies even more.

I know that plans never work out anyway. Trust the control-freak. But it’s even worse when they actually do work. Plans give you a direction and keep you focused, but when you take them too seriously, they slow you down at best or make you miss the target altogether at worst. Sometimes we manage to complete a project “right on time”. Does it mean that our planning was so perfect? Or maybe we killed the goose that laid the golden eggs by working like crazy to meet the deadline? Or maybe we could get there way faster, but we looked at the board and Parkinson’s law kicked in? How much time have we wasted for tweaking and managing the plan, for making sure the plan is working, for assuring stakeholders we’re not sleeping all the time? Could we be faster without all this? Did we actually reached our goals? Heck, who knows what our goals are?

We might argue that without requirements we don’t know what to do. Yet, I’ve never seen requirements that perfect they don’t need any clarification, or don’t benefit from conversations. On the other hand, I’ve heard often things like “I’m not really sure what that means, but if they can’t get their requirements right it’s not my problem”. It’s their fault. They always complain, they don’t know what they want, they change their mind all the time. They, they, they… Just give us your money and go away, don’t disturb. It becomes hilarious, when it applies in exactly the same way to internal clients, even if they are devs as well. Isn’t it some kind of universal magic? Once you stand on the other side of the computer screen, you’re nothing like me. You’re exactly like them.

We might argue that without a deadline we never get anything done, that it motivates people. Yet, there are so many projects done after hours, for free, just for the joy of it. Yet, there are so many devs that hate their jobs and keep programming at home to keep their sanity.

We did our job perfectly, we followed all the rules, we met all our yearly goals, the project is finished according to the plan, we moved all thousand tasks to “done done”, we celebrated the success and threw an awesome party for our “dream team”.

Yet, somehow we failed the client.

But who cares anyway? It’s nobody’s fault… The “how” and “what” are defined perfectly, we follow them to a tee, it’s our job after all, we know what we’re doing. You say that we missed the “why”? This is not our problem. We are happy spinning our hamster wheels, going nowhere, benefiting no one.

And so everybody has their ass covered.

See: Fred George “Leaner Programmer Anarchy”