Geek Out of Water - Gil Zilberfeld's Ramblings

Clean Sweep

noreply@blogger.com (Gil Zilberfeld) — Tue, 14 Feb 2012 15:56:00 +0000

One of the questions I got in my Agile Practitioners talk startled me. Actually, it wasn’t the question that startled me, it was how I answered.

I was talking about why you cannot say “our organization is going agile” while saying: “we’ll get our developers into that agile business in a year”. I know it sounds funny, but you can’t really get WORKING SOFTWARE without the developers. It’s been tried before and failed miserably.

The question asked was: “But in order to succeed, you need to train the C-Level, and then managers, etc. Only then you get real backing for the development team”. I started to air-draw a waterfall in which training goes from one level to the next, and thinking back I was probably even shouting at the person who asked it (mental note: don’t do that again). I also said that for this to work, you need to support top-down training (from management) and bottom-up training (from the dev team) at the same time.

But after thinking a bit more I came to the conclusion that it’s not enough. It could work, but it requires a special ingredient to succeed.

The Special Ingredient

Let’s take an example from my day-to-day life: Unit testing. When does unit testing implementation succeed? When you’ve got a team leader, or an architect that can drive the change in his team. Usually the team lead has the technical knowledge and language to convince the team about the investment’s worth.

But move up one or more levels. Can it work when a CTO requires her organization to move to unit testing, without some team leads or developers involved? Rarely.

A team can go through the transformation, and successfully stick with it. But this transition rarely jumps over to other teams.

What’s missing in the team next door? The proper leadership (technical and managerial) that exists in that first team. And that’s the special ingredient – the right people in place.

That is the conclusion I’ve come to: If you want to do a sweeping change across the organization, you need the right people in place. People ready, brave enough to jump through the hoop, and try out new things.

And there-in lies the problem: The right people are usually not there. We have not built our organization to accept “agile-oriented” people. We have not accepted only developers who are “above average”.

That’s A Tough Pill To Swallow

Because what it means is that even if the top brass is ready to embrace agile, making it actually work depends on recruiting and educating new and existing developers, and placing them across the organization. Organizations need to grow those leaders into place so when they introduce the change, it will actually catch on.

Successful organizations do it, because it makes business sense. They take time and adapt. They raise the bar on recruiting and they put in training programs in place to make sure that the transition in months, maybe years, will work.

The average organizations won’t. They’ll try “going agile”, and six months later will call it a failure and move back to how they usually (mis)manage projects. And agile will take the heat.

Do You Want To Succeed?

For developers it’s easy. Enough material is out there on what practices you can start doing today. Team leaders? Start recruiting smart people. Educate the rest of the team. Get rid of the weak ones, they are slowing you down.

Upper management and C-Levels: your task is the most crucial. You understand that processes take time. Processes need proper resources and management. It’s not just getting the agile consultant into the organization, and giving him a free hand. It helps. But for it to work in an organization level, you’ll need to direct and manage for better recruiting and education, to push down these message so the rest of the organization will move in the right direction.

Then you’ve done a clean sweep. Then you can really say: “Now we’re agile”.

10 Phrases Presentation

noreply@blogger.com (Gil Zilberfeld) — Wed, 01 Feb 2012 14:21:00 +0000

I had a wonderful time at the Agile Practitioners conference yesterday. Lots of great minds, great discussions and great presentations.

Including mine. So if you weren’t there, here’s the prezi.

10 Phrases that Can Derail an Agile Project

I Do Not Think It Means What You Think It Means

noreply@blogger.com (Gil Zilberfeld) — Mon, 30 Jan 2012 15:03:00 +0000

Thanks to Dilbert, developers, engineers and the rest of us managed people, have come to disrespect the “manager”. Ok, it’s not just the comic, some of it was perpetuated by actual managers. Still, there are cases where the managers do the right thing, and the developer messes up.

Whenever this occurs, regardless if from the manager or developer side, we’re making the divide between the business and development wider. Sometimes both mean well. But it just happens that the parties don’t talk the same language and then you get what’s in the picture on the right.

Here’s an example. When a manager asks the team to increase their velocity, we’re on a crash course. The real original definition of “velocity” is past observations of the team’s performance from which we can estimate their future performance. So in fact that the perfectly sane question the manager asked, sounds to the developers like this:

Can you build a time machine?

Notice that divide getting bigger?

What happened is what marketing does some time: take a word that sounds familiar, but means something other completely, move it out of context and appear to sound more intelligent now that we own it.

Only we don’t and we wind up sounding stupid.

Another example. When the developer says to manager that the tests keeps slowing him down, and he’ll be more productive without them, we’re on that crash course again. Because what the manager hears is:

Testing is an accepted best practice. But that’s for normal people, I’m better.

And the divide gets bigger still.

In order to bridge the gap, we (whatever we are – developers or business people) need to learn the language of the other side – the terms, the tone and the nuances. Only after we did, we can actually find how we sound like to the other side. And then we’ll probably hold our tongues a little more often.

Want to hear more? Come hear me tomorrow at the Agile Practitioners conference. There’s plenty more where this came from.

Meet Me at Agile Practitioners 2012 Next Week

noreply@blogger.com (Gil Zilberfeld) — Thu, 26 Jan 2012 12:36:00 +0000

Quick reminder: You did register for Agile Practitioners 2012, right?

To hear all the great speakers and myself?

You didn’t?

The Stamp of Approval

noreply@blogger.com (Gil Zilberfeld) — Tue, 17 Jan 2012 16:05:00 +0000

I’ve recently posted on the Typemock blog on test organization, and gave an example of how organizing Outlook folders is not as effective as dumping everything in one bin and using “Search”. Here’s a quote (from myself, by myself):

The search box finds things much quicker. There’s also a penalty in the filing system. For each email, my friend needs to think where it belongs. What if it deserves to be in two places? The filing itself is costing him time.

Well, apparently, now there’s proof in electronic ink that I was actually right (which managed to astonish even me): The Harvard Business Review’s blog says: “Tip for Getting More Organized: Don't”. Which takes my short version above, and makes it into a full fledged article. Worth reading.

As the article say:

Organizing is wasteful; getting its benefits is productivity.

With proper tools, and focusing of what we actually want to get from organizing, we get better productivity and effectiveness.

Would that convince the organizing people to leave their wicked ways? Of course not. People, like people, don’t like change. These guys love organizing stuff: It works, they are the experts of the system , and there’s an endorphin rush whenever something gets placed in the right place. Without pain, there’s no need for a change.

That doesn’t mean we should stop trying to convince. It is our professional responsibility to show the light. It could be testing, or productivity tools or agile or anything else that we think might get everyone more effective.

And who knows, maybe somewhere, sometime, we’ll be proven right by an impartial ivy league university blog.

PS: If you want to hear me try to convince, register to Agile Practitioners 2012. See? It’s already working.

My Interview with Lisa Crispin

noreply@blogger.com (Gil Zilberfeld) — Tue, 10 Jan 2012 15:52:00 +0000

A few weeks ago, I got a chance to talk with Lisa Crispin. Lisa is a prominent figure in the testing world, and co-authored “Agile Testing”. This was a great opportunity for me to talk to someone from the tester side, as usually I talk with developers. And I felt this was more of a conversation, rather than an interview. While most “agile” teams are struggling with how testing fits in there, Lisa’s agile team is already running full speed ahead. I hope to meet Lisa in person in the future, and I definitely want to learn more on how testers role today is shaping up.

We talked about how we develop software at Typemock, how we make decisions and learn from our experience. This interview is on Lisa’s blog.

Can software succeed even if Agile failed?

noreply@blogger.com (Gil Zilberfeld) — Mon, 19 Dec 2011 16:05:00 +0000

I’ve got very interesting feedback for my last post about the decline of agile. I strongly believe that producing quality software, regardless of how it is produced is the most important thing we can do, regardless if we’re developers, managers or anything in between.

But is it enough to save agile?

Maybe it’s the wrong question. Does “agile” matter if we’re still pushing out quality software?

I’ve thought a lot about it, mainly because of Bob Martin’s comment:

I take solace in the fact that while TDD is no longer a conference draw, my classes in TDD are enjoying ever larger attendance. More and more people are _adopting_ TDD, and getting serious about good software practice. And _that_ is the thing that will advance the software industry, no matter what happens to the "Agile movement".

If TDD succeeds, we’ll get what we want – working software. That will bridge the gap between developers and the business, and everyone lives happily ever after.

I see a small problem with that plan (although I really wish it came true).

For the last decade, people have adopted TDD. They went through many obstacles that the business had put in front of them. That’s why successful adoption was despite management, rather than with their support.

It’s different now, isn’t it? More organizations are “doing” agile, and it’s easier to get support for agile practices. It’s easier to get funding for TDD classes. Less obstacles means more adoption.

What happens if (and when) the backlash begins?

Organizations that implemented agile poorly, would cry foul. “You stupid people, you’ve done agile without supporting software practices. What did you expect? You can’t have working software without software practices!” We’d say. But it will be too late. The press will cry out “AGILE IS DEAD! Get off the ship before it sinks!”.

The business people who supported agile will make a U-turn. And the team leader who wants to do TDD will need to go back to working in guerilla mode. At night, when no one is watching. And she will do TDD. Only this time, there will be more obstacles than before, because of that “failed-agile-thingy”.

I’m sure the righteous people will continue to promote the software practices. It’s just going to be a tougher battle than it used to be.

So where does that leave “the agile movement”? A very small, disbanded group of heroes, who thought they found the bridge between software and business. Instead, they lost all hope in ever getting trust between the two parties.

I’d rather have that bridge than lose it. Even if I had Working Software.

4 Warning Signs that Agile Is Declining

noreply@blogger.com (Gil Zilberfeld) — Mon, 12 Dec 2011 15:47:00 +0000

I’ve been thinking lately about how agile turned out to be the way we know it today. And the more I think about it, I get more depressed.

You see, agile was supposed to save us all. It was supposed to be the bridge between business and developers. And 10 years after its inception, we should be happy that more than half of the projects are done in agile manner (depending how you interpret the numbers). Agile has crossed the chasm, but not like we imagined it would.

Companies are “doing agile”. But they do it the way they implemented processes for the last 200 years: Top-down. First they train the top management. Then they move on to directors. Then to team leads. And at the end, they get to the developers. Remember that “working software” part? It looks like they didn’t read the small print (much like in the waterfall case).
The business and development divide has grown. Because scrum won, we now have project managers as scrum masters. They don’t know much about software, and that doesn’t help bridge the gap between the two worlds. Developers still look at those scrum master certifications funny (with some reason on their side), and the PMs still don’t understand that in order to get to “working software” you need to persist with actual software development practices. Because if you don’t write tests, or refactor, your team will slow down very quickly. And that will not produce as much “working software” as it said on the side of the box.
It’s been just 10 years and we’re already looking for the new hotness. We didn’t have enough time to learn or adjust. Agile has now become “boring” and we’re looking to uncover more better ways to develop software. Those things that looked “shiny” a few years ago, like TDD or continuous integration, have lost their shine, and aren’t attractive anymore. Don’t believe me? check out the big conferences – seen these topics lately? Much like good management is dull and repetitive, so are agile development practices. But while we appreciate the old ways, apparently we value the new stuff more (without any good reason).
We can’t even appear as a united front. We’re bickering inside ourselves. Agile vs kanban, craftsmen vs non-craftsmen – you’re doing it wrong, we hear from every side. And since agile has now become mainstream, it has a lot of money pouring in, and the side (read: consultants and trainers) that shout the loudest get a piece of the pie.

At this point, I feel Agile is declining into what TQM was. A brilliant success in the beginning, and now just a history fact. In a few years, months even, the business side will wake up and say: Agile is snake oil. It doesn’t deliver on its promise (and it doesn’t matter if it’s done wrong). The backlash will be grand.

There is still some light at the end of the tunnel: Regardless of our role in the process, as long as we’re delivering working software, we’re contributing to balance this future backlash. As long as we stick to the original agile ideas, we’re helping agile win a few more hearts.

I hope our collective work will be enough, that results will prevail. But I fear we’re seeing the beginning of the end.

Don’t agree? Cheer me up in the comments!

The Agile Tribe Wars: The Prezi

noreply@blogger.com (Gil Zilberfeld) — Mon, 05 Dec 2011 14:56:00 +0000

I want to thank everyone who come to my presentation yesterday. I got my inspiration (and a few jokes) from the following presentations:

Agile Overview – Robert Martin
The Land that Scrum Forgot – Robert Martin
The Mistake at the Heart of Agile – Michael Feathers

And for the people who want to read the Waterfall paper by Winston Royce – there you go!

For the people interested, I made the presentation with Prezi. I can say that although I didn’t get much of flash effects from it, it did help me to organize my material and thoughts.]

Finally, here’s the presentation. Enjoy!

The agile tribe wars on Prezi

The Agile Tribe Wars–At the next Agile Practitioners IL Meeting

noreply@blogger.com (Gil Zilberfeld) — Thu, 01 Dec 2011 09:51:00 +0000

If you’re in Israel, and understand Hebrew – you’re eligible!

Join me on Sunday, 4-Dec-11, for a lesson you’ll never forget (or at least for the length of the presentation) - An agile history lesson. I’m going to talk about how we got here, what did we do on the way, discuss the question on everyone’s mind – has agile succeeded or failed. Oh, and where we’re going from here.

Are Scrum and Waterfall The Same?

noreply@blogger.com (Gil Zilberfeld) — Mon, 28 Nov 2011 18:49:00 +0000

I’ve gone back to watch Uncle Bob Martin’s presentation “Agile overview” from NDC 2010 (while you’re at it check his “The land that scrum forgot”, the man is such a storyteller!). In the presentation, Bob tells about Winston Royce’s study “Managing the development of large software systems”, from 1970. This article is the origin of the waterfall methodology, although the word waterfall does not appear in it.

Here’s Royce original waterfall diagram:

Royce saw the waterfall method as an ideal, and you maybe surprise to learn that he recognized it won’t work in practice (see the first sentence under Figure 2). Not only does he say so in this very article, he also explains why:

Royce identified the feedback loops that make agile so powerful. He noted them however as obstacles to the flow of the waterfall.

That’s all history, of course. Apparently, too many people didn’t flip to the next page, to see who the killer of billions of dollars was. What possessed so many in our industry to follow a model that even its parent says is flawed?

I don’t know the real answer (if you do, let me know!), but I do have a theory.

The waterfall model is simple, and understandable to common people. And by common I mean regular business people. It’s easier to wrap our mind around the simple (yet flawed) waterfall model, than accept and deal with the actual interruptions caused by real life.

Come to think about it, this is similar to another model that is winning the hearts of many people: Scrum. Scrum is now the agile method of choice in mainstream. Scrum is easily understandable by business people, since its based on familiar processes, and doesn’t require understanding of geeky development practices.

What do you think? Why did waterfall succeed? Is scrum destined for the same fate?

Velocity: Agile Killer or Unsuspecting Mark?

noreply@blogger.com (Gil Zilberfeld) — Mon, 14 Nov 2011 15:24:00 +0000

Jim Highsmith recently wrote about “Velocity is Killing Agility”. Velocity was originally used as a planning tool. You measured velocity in the past, in order to see how much throughput you’ll get in the future. If we put it very simply:

Throughput = Capacity x Velocity

Now, as Jim describes in his post, velocity has turned from an observed (immutable) value to a goal, that can be tweaked.

And I ask: Why is that a surprise?

For years, we’ve been taught that “if it can’t be measured, it can’t be managed/controlled/[insert your favorite activity here]”. Business organizations still want an answer to the question: When will it be ready? And if your team has gone agile on you, you try to get what you can. Can’t get an answer? Measure a proxy,. And once you have a proxy, i.e. velocity, you can build a plan how to improve it.

What do you mean “you can’t change” velocity? Sure you can! Better computers, better people and less coffee breaks and see how your productivity, I mean, velocity jumps up. Don’t believe me? I’ll show you next month, we’re measuring it!

Sure, velocity was not meant to be used like that. But that’s how it used today, as a translation proxy between the dev team and the business. It’s not killing agile, it’s adapting it, translating the agile lingo into business-speak.

History has taught us that sometimes what people invent ends up being used differently than how they imagined. I guess that’s where our dearly beloved velocity went.

My advice: don’t worry about it. What you should be concentrating on is producing high quality software features out the door. Management wants to improve your velocity? Don’t throw the idea out the window. There are always better ways to improve your output, individually and collectively. Improved productivity leads (eventually) to an improved velocity.

Frankly, that’s a win-win situation, if I ever saw one.

Software Developers are NOT Special

noreply@blogger.com (Gil Zilberfeld) — Mon, 31 Oct 2011 19:16:00 +0000

As I was going through Twitterland, I heard this strange sound:

“Coders are special. We are expected to know how to do things we've never done before and estimate how long they will take."

Well, yes and no. The part about estimating how long it will take is definitely true. See, there’s someone paying for your efforts, let’s call him the customer. The customer wants to know when he gets something for his money.

Haven’t done this before? Maybe the customer hired the wrong gal or guy. Maybe he should have gone with someone who HAS done this before.

Or maybe you’re one of the very special group of people working on actual new technology, most developers aren’t. Statistically, I’m sorry, but you’re not.

For every one, in every profession, there are new tasks to do, or tasks that contain new elements in them. We never do everything exactly the same, because even if we try to control everything, there’s going to be a traffic jam, a communication meltdown, or a small war. There’s always risk involved and that affects our estimations. We still need to give them, though

Developers have hard time estimating as the next guy. There are ways to minimize risks, but eventually, we need to give a due date, because this date means money going somewhere, and the wallet needs to know when and how much.

Sorry to break the illusion. Coders are not special.

Upcoming Presentations: Florida First!

noreply@blogger.com (Gil Zilberfeld) — Thu, 20 Oct 2011 15:49:00 +0000

Here’s a short, incomplete list of my upcoming public speaking engagements. When I know, you’ll know.

I’ll be speaking at the Agile Development Practices East Conference on Wednesday November 9th, at the Rosen Centre Hotel, Orlando, Florida. My talk is about “8 Principles for Better Unit Testing”. I’ll be at the conference area throughout Wednesday and Thursday, so if you’re there, come say hi.

Two days before that, November 7th, I’ll be at the Deerfield Beach user group meeting (part of Florida.Net) where I’ll do my “10 Secret unit testing tips” and do a group code kata. They call it a Deerfield Beach Special Edition, and I hope it will be special indeed.

Looking a bit far into the future, I’ll be speaking at the Agile Practitioners 2012 in Israel, on January 31st next year. The topic is not closed yet, so stay tuned and get ready for a surprise.

In the meantime, I’m doing a webinar each month at Typemock. Next week, Wednesday October 26th, I’m doing the long-named “The Step by Step Guide to Building Effective Agile Development Processes”, so if you haven’t yet, register now!

For more of me, check out slides and recordings at the Events and Webinars page. And if you want to hear and meet me closer to where you live, invite me!

The Agile Time Lords

noreply@blogger.com (Gil Zilberfeld) — Mon, 03 Oct 2011 18:54:00 +0000

InfoQ had a round-up of ideas about “How Long Would it Take to Build the Product?”. It was funny (ha-ha funny) to read some of the responses. One person suggested that upfront estimations end up in a fixed scope, which is anti-agile. If I was new to agile, I would read it this way: if you’re REALLY agile, estimations are not for you.

Well, that’s a great way to set up expectations for the new agilist. If you want to pick up the pieces later, that is.

It seems that developers don’t really need estimations. They can work without any planning or time limit (not effectively or efficiently, but they can). True time lords.

But estimations are a tool for the project sponsors. The ones who pay for the project. They want to know when they’ll have something to show for their investment.

If there’s no agile experience in the organization, when the sponsors ask:“when will it be read?y”, they know that they’ll get a date, to which they’ll need to add 6 months, and that at the end they’ll need more testers. It’s painful, but they learned from history, and this gives our poor sponsors some kind of predictability in their life.

If there are already agile projects in the organizations, the sponsors already know that it’s not about fixed scope and date. They’ll get what they can by that date. Sure, they’ll always want more, but they learned to live like that. That’s another way to have predictability in their uncertain life.

But if the organization is in transition to agile, the sponsors are very touchy about these things. They are looking for some predictability, and the last thing they want to hear is: We’re agile now, we don’t give estimates.

Wrong answer.

Forget about pure agile, and give your sponsor confidence this new way of developing software can actually work. That his trusted developers are not some inmates taking over the asylum.

Estimations are a way to introduce predictability and trust to all the project stakeholders. It allows the organization to plan ahead, know when the team needs more people, or to transfer people to other teams, to raise money or just put a date on the calendar when the marketing team can start promoting the new product. It’s not much, but way better than the black hole of uncertainty.

Remember: Agile is about collaboration. And not jut with the customer, also with your boss.

A Sacrifice to the Agile Gods

noreply@blogger.com (Gil Zilberfeld) — Tue, 13 Sep 2011 14:30:00 +0000

Last week, I had the great pleasure of attending the Agile Practitioner in Israel meeting. Roy Osherove gave a splendid presentation on the “10 mistakes team leaders make” (and if that’s the sample, you better go check the entire course).

As the presentation went on, it was evident there’s some division between the crowd and Roy. The crowd came to hear about the agile leader, the Scrum Master. Roy was talking about the team leader. And these entities, their roles and skills were not the same. Or were there? You can read more impressions on the discussion in Lior Friedman’s blog.

Is this post-agile speak? Are the two roles the same, or have we grown past the “classic” scrum master role?

Scrum Master vs Team Leader

Roy is talking about the role that scrum left behind: The manager. That’s the classic team manager, the one who is responsible for her team, from the view point of the organization. You remember her, right?

Usually, team leaders get promoted by being the best at what they do, usually develop software. No one has taught them how to manage, let alone lead. No one has taught them how to hire people, how to develop their team, and how to manage conflicts in the team. This doesn’t sound like scrum anymore, does it?

Nope, that’s management, that nobody teaches (nobody except the excellent Manager-Tools). The great team leader is a great manager. The one that scrum forgot.

The Forgotten Manager

In a recent post, “Is Agile Doomed?” I wrote (again) about the disconnect between the developers and the business, and what led there. Scrum managed to build a protected developer team. But it did so by building a wall between the developers and the business. The manager was indeed another brick in the wall (get it?). Scrum didn’t have a place for a manager. The team self organizes, communication is flowing, and processes are in place, thanks for the scrum master.

But business organizations have not changed so much over the last few years. Sorry agile folks, we’re the minority. For businesses to grow, we need good managers and great leaders, whose people skills are at play. The people the business counts on to grow the people on their team. These would be the future managers.

Teams that are adapting agile are struggling with the role of the team leader. Most of the discussion around this, not surprisingly, was about the manager losing his “power”, or authority. The transformation of the manager to a scrum master was the answer.

However, this transformation should not be complete!

The good managers should continue to manage people. The bad managers should be removed, and replaced with good managers. Scrum has given us a great platform for businesses to be effective and productive. But in the long run, businesses need to consider the big picture.

Managers should not be sacrificed on the agile altar.

"10 Secret Unit Testing Tips" Webinar

noreply@blogger.com (Gil Zilberfeld) — Mon, 29 Aug 2011 15:39:00 +0000

Last week I had great time hosting a Typemock Webinar called “10 secret unit testing tips”. The fun thing was that I’ve discovered both in preparation and answering questions live that I have at least 20 tips in me for at least two more webinars. So prepare for “10 secret unit testing tips strike back” and “Revenge of the 10 secret unit testing tips” coming soon to a screen near you.

Probably will take less than 6 years, I don’t do all the special effects that George did.

In the meantime, here are the slides. You can view the video recording on the Webinars page.

The Real Value of a Non-Agile Plan

noreply@blogger.com (Gil Zilberfeld) — Wed, 10 Aug 2011 18:43:00 +0000

A couple of comments on my last post (the sad truth about agile planning) made me think: Maybe I was slamming agile planning too much.

Then I thought (after an elaborate discussion with myself) – I wasn’t doing that at all!

So let’s put some things in perspective: Can I make a plan for the next 3 years in the project? Absolutely.

Will it be real/correct/anywhere near that? Absolutely not. We can’t predict what will happen, no more than we can control if we’ll even be in the company in three years.

Then why bother? Two reasons.

Putting a plan in place requires thinking. I know, we don’t talk about much about thinking in agile too much, it’s not (air quote) part of the process . But much like TDD makes you think before you code, creating a plan makes you think about what you can and cannot control, what can happen, milestones, etc. It doesn’t mean what you planned will actually happen, but you know you’ve done some risk analysis just by thinking.

The 2nd reason is the cornerstone of any agile methodology: communication. You show this plan to the project sponsors, and convince them that you’ve actually thought about it. They know it’s not accurate, and that maybe the project will stop because of economic events that even don’t appear in the plan. But that gives them confidence. It raises trust.

In the past I didn’t understand that. I was sure the only way to gain (actually win back) trust was to show actual working software. It’s definitely a show of force when you’re delivering working software consistently. But you should do more . When you show a plan, you gain trust. When you communicate status on the plan you gain trust. And when you react to unforeseen events and communicate decisions, changing the plan on the way, you gain trust.

If you’ve already got this trust in place, you’ve got it made. And, you need to work at it to maintain it.

Projects succeeds when everyone communicates with each other, and trust each other. It’s up to us to build the trust on the business side. If we don’t? Let’s not be surprised that another unforseen event happened: the project got shot down.

The Sad Truth About Agile Planning

noreply@blogger.com (Gil Zilberfeld) — Mon, 01 Aug 2011 18:46:00 +0000

If you’ve read any basic agile stuff, you know that agile teams deliver value in a consistent frequency. The team works on what’s important first, giving the best value for money. When working in a consistent velocity, you can estimate very accurately when features are going to be delivered.

Prepare yourself for a shock.

It is true that when the team has gelled, had enough experience in estimation, and is moving in a constant velocity, life is good. But most people are not there. Chances are, that you’re struggling with inconsistent estimations, varying velocity, some turn over for good measure and enough unknowns to fill multiple buffers in a Gantt chart.

There’s an old myth: There’s no planning in agile. You’ll find there’s a lot of planning, but if done “right” it’s mostly short term. There’s logic behind it: The bigger the task, a lot can change on the way. It makes much more sense to cut it down to smaller bites, estimate and deliver them, and move on to the next important feature.

However, most of the real world doesn’t work like that. In my former job, I managed software projects of medical instruments that needed to be ready for an expo, after FDA submission. The expo was on a deadline and the competition didn’t wait. The project sponsors needed to know everything would be ready in time, three years in advance.

You might be surprised to learn that answers like: “It will be ready when it’s ready” or “you’ll get what’s the best value every month” were not pleasing to the project sponsors’ ears. See, they needed to know what they’re getting and that it will be on time. Couldn’t face reality, the old geezers – they wanted actual long term plans.

Well, these are the guys who put the money into the project. They may have unreasonable demands, like wanting to know exactly where the project is, but the expo is not moving, is it?

Pure agile may work, but business people are so tired from earlier failures, they don’t trust the team anymore. And they are looking for reassurance or control, by demanding more information. And I’m sorry to say, they are right.

They need answers, so they can make better decisions.

So what can you do when presented with the unreasonable question: “When will it be done?”

You plan, even for the next 6 months, and stand behind your plan. This would be a rough plan, but will present you’re working on the correct features. When progressing, update the plan, and communicate your status. And apart from that, you present working software, showing continuous improvement in the product.

Sounds like the old waterfall world calling you back?

Well, that’s the real world. It requires balance between the long term and the short term. Agile planning is not enough.

Breaking the Laws of Nature

noreply@blogger.com (Gil Zilberfeld) — Mon, 18 Jul 2011 17:54:00 +0000

Are sales people and developers like oil and water?

As I was reading this article I recalled Michael Feathers’ presentation at NDC about “The mistake at the heart of agile”. To recap: Agile closed the developers behind a walled garden, in order to let them produce without interruption from other sides of the organization. On the minus side, it formed the gap between the sides, which had affected how the developers understand the customers.

There are stereotypes of the developer and the salesman. Some of them are based on the occasional truths. I’ve crossed over from the development trenches to the “dark side”. I sometimes get called “working on the side of evil”. Laughs aside, we have these views of the sales and marketing.

No, the other side is not exempt from this behavior. “Why is the product not done, when they said it is? and what is this internal value they work on? I can’t sell internal value!”. Let’s admit it, we’ve contributed to how we look in other eyes. And in our banding together inside the agile circle, we’ve formed the geek culture that helps us look at the other side in Dilbertian glasses (just an example).

This “us against the world” is nice, fuzzy position to be in. But if we want to help our organization, we need to build a bridge to the other side. It starts with learning the vocabulary, using it, and dropping the sarcasm (and believe you me, that was the hardest part for me). Learn their motivation, what makes them happy and what upsets them.

Here’s an example: You know that saying “the testers are delaying the release”? It’s because the testers get in after the development cycle (in non-agile orgs). And because the development went longer, the pressure is on them. Well, guess what. It doesn’t stop there. Marketing is next, and then sales. The marketing and sales team need the greatest help and info about the product, because now they need the confidence that what they talk about actually does what they say. Otherwise, they are left holding the ball, and if it’s not a quality ball, you know who they blame, and what they think of them.

Oil and water don’t mix. That’s a law of nature.

Developers and sales people? Not so much.

The Ruby Train Wreck

noreply@blogger.com (Gil Zilberfeld) — Mon, 11 Jul 2011 18:23:00 +0000

The latest “my dad is cooler than your dad” in develop-sphere, started with “The Ruby Train Goes Choo-Choo”. Soon enough many have joined the fray on both the Ruby and .Net sides, with the normal people saying: Take a rest. You are not what you program.

Of course, the normal people (I’m assuming you, dear reader, are one of us) are right, and the zealots are wrong.

While they have a right to state their opinion, let’s remove our “developer” glasses. Let’s look at this through the “business” glasses.

Can we trust developers to work together? They are so opinionated. They are not team players, are they?
Why do developers always take these things too far? Why don’t they care about solving real business problems instead?
And they always look for the new shiny thing. Can we trust them with making rational decisions?
Finally, if they become so much engulfed in these discussions, they probably have too much time on their hands.

“You’re generalizing too much”, I hear you say.

“They are just a couple of idiots. It’s their foot, they can choose to put it in their mouths.”

They are not just hurting themselves, you know. Business people already look at us funny. These guys reinforce this image.

And that hurts you and me, regardless of what we think about Ruby. What business people think can impact their next hire.

Next time you see this kind of argument, don’t just roll your eyes and go away. Present the zealots with the business glasses. You might lose some geek points, but you’ll be helping the rest of us.

Fear, Courage and Unit Testing

noreply@blogger.com (Gil Zilberfeld) — Mon, 27 Jun 2011 18:47:00 +0000

At NDC I was fortunate to take part in a session of Cyber Dojo, run by Jon Jagger and Olve Maudal. You can have a taste at it online, but it’s better experienced with a guide. The attendees pair up, select a kata and a programming language and start adding features and tests. Every 5 minutes you switch pair. I was very lucky to pair with Michael Feathers, Jon Skeet, Corey Haines, Jim Shore and others in this session. But this post is not about name-dropping.

One thing to note is that programming was not done in an IDE. A browser-based editor for coding let you type in code, and then a single button would run the tests, and you get the result of the last run instantly.There are many things you can learn from this session (including how fast Jon Skeet could spread Linq within the different pairs ).

I want to concentrate on two feelings I experienced. Let’s start with…

Confidence

Working without a full IDE (Visual Studio or equivalent) robs you of signals you’re accustomed to. Without squiggly red lines, warning about syntax errors, I found my self relying on the “run test” button. It was no longer just running the tests – it told me that my code also compiled, and it’s ok to continue typing. The more I added code, I used the button more - just to get feedback on the current state of my code. This feedback gave me the confidence to continue.

It makes sense – with less information, you take small steps, and try to get as much feedback as you can before proceeding. It’s like wandering blindly in a labyrinth – you feel your way slowly, try to get as much tactile data with your hands.

And on to anxiety. Even borderline…

Hysteria

In the last session, before the bell rung, I wandered a bit. My code wouldn’t compile, and so I wanted to get back to a safe point where all my tests ran. My automatic reaction was to press CTRL-Z to undo the last changes. And then panic struck: This isn’t a real IDE. No undo for you. I actually felt real anxiety! I barely worked from memory to make the tests pass in the last second, feeling the pressure of looming failure.

So what have I learned?

It’s a great experience, everyone should try it.
Use the best IDEs you can. Even small features make you more productive.
You can’t code without confidence. Unit tests give you confidence and eliminate fear.

Have you had experiences like that? What have you learned?

“Danger! Craftsmen Ahead!”– The Movie

noreply@blogger.com (Gil Zilberfeld) — Mon, 20 Jun 2011 18:13:00 +0000

My NDC 2011 talk in moving pictures form.

Danger! Craftsmen Ahead! from Gil Zilberfeld on Vimeo.

Is Agile Doomed?

noreply@blogger.com (Gil Zilberfeld) — Mon, 13 Jun 2011 18:31:00 +0000

At NDC 2011, there were a couple of presentations about the state of the agile today. Of note, were Uncle Bob Martin’s excellent “The land that Scrum forgot” (That man can give a show just by reading from index cards!) and Michael Feathers’ “The mistake at the heart of agile”. Until the videos are out, you can get the latter’s description on Gojko Adzic’s blog.

Kent Beck’s vision, the purpose of agile, was supposed to bring developers and customers together. But something happened on the way to paradise.

According to Uncle Bob, the developers lost the lead when scrum was taken over by project managers. At the beginning, XP practices were the basis of the agile movement. But when Ken Schwaber started his scrum training courses, it was project managers, rather than developers that got the certifications. And as I’ve noted in my presentation, certifications speak the language businesses understand, and one of its keys to success.

Michael Feathers goes back further to see where the separation began. He states that It started because both XP and scrum saw the need to protect the development team within the organization. They needed to make sure that project managers, product managers and others do not rock the boat of development. The product owner in the team, is basically a gatekeeper, keeping all others outside. The abstraction kept development efficient. But it also made development less effective.

How can we overcome the division?

Uncle Bob suggests the craftsmanship movement may be the last chance to take back the ownership over the agile process, and realize Kent Beck’s vision. Michael Feathers suggest another insight: Instead of the segregated development team, build heterogeneous teams that include not just developers, but also business specialists, support teams, etc..

Interesting stuff. While between the two, I feel more drawn to Michael’s utopic solution, both endgames seem far-fetched. I don’t see craftsmanship taking over, because business won’t let it. And as Michael suggests, re-organization of the business will be only due to business understanding that it will make it more competitive, and that requires better management. We’re a long way from there.

Is agile doomed?

Not necessarily.

In order to achieve the connection between developers and customers, more developers need to cross over to other business roles. They will be able to speak both languages: business and develop-ish. With more power and influence they can affect how organizations structure themselves, and maybe pull towards Michael’s solution.

Developers are key in realizing the agile vision. But for agile to succeed, they need to learn a second language.

So Right, So Wrong

noreply@blogger.com (Gil Zilberfeld) — Wed, 08 Jun 2011 10:04:00 +0000

How can something seem so right, and yet so wrong, at the same time? Easy.

When the person who speaks is different than the one listening, which is usually the case, and there’s a translation problem.

Consider the term “Refactor mercilessly”. I don’t recall when I first heard it, but it definitely caught my ear (and you know how painful that can be). You can just imagine yourself hacking your code into shape, like Edward Scissorhands. And you’re not done until everything is trimmed, there’s no excess fat, no stone left unturned, and no cliché left unused.

To use technical terms, you renamed everything in a readable fashion, you Didn’t Repeat Yourself, and your design was improved 15 times already today.

And that sounds great, like a battle cry of a professional developer. “Professionals refactor mercilessly!” (and other’s don’t).

But how does this sound to the non-technical person?

The first thing he asks is “What’s refactoring”? and you answer: “It’s changing the code without changing functionality”.

Say it out loud to just to hear how much refactoring sounds like a waste. Non-developers will never remember the second part “Refactored code makes maintaining it feasible and cheaper”.

But that’s not enough. As a true professional, you exclaim:”I refactor mercilessly!” and after you use the explanation above, the non-tech guy, who may be your manager (or future hiring manager) now looks at you funny. Maybe for the last time.

How can something seem so right, and yet so wrong, at the same time? When we don’t understand how we sound to the other side. It can also have some disastrous effect on our careers.

Want to hear more? Catch me on Friday on NDC 2011, Oslo. There’s going to be more of that.