Geek Out of Water - Gil Zilberfeld's Ramblings

When Will It Be Done?

noreply@blogger.com (Gil Zilberfeld) — Mon, 28 May 2012 13:00:00 +0000

Everyone likes to know the answer. In fact, this question can be interpreted in many ways, and answered that way too. For example, if we’re using agile techniques, we assume things will go wrong. So what we’re asking really is when is the scope going to be completed.

And that’s not the way agile works, does it?

What we do is set deadlines. Some of the deadlines are real – like a tradeshow we need the product for. Some are there because someone just put a date on the table. Once we have a deadline, we’re starting our way towards the goal. Iteration by iteration, changing scope by feedback, making the best product we can for our customer.

If we get to the deadline, and there’s no product yet, we’ll push the deadline. Or miss the tradeshow. Regardless, we make a conscious decision about if we’re ready to release or not.

So if we know the dates are set, why does the question “when will it be done” still pop?

If the project is already on the way, what we’re really asking is “Is the scope going to be ready on time”.

Which goes against what we’re trying to achieve: Best value for the customer does not come from a predetermined backlog of features. It comes from the iterative nature of development. When we’re talking to managers who are new to agile development, this is usually what they mean

There’s a bit more to that: Dates are easy to explain. Scope is harder. “We’ll have X baked in, but only some of Y, and a bit of Z”. Managers are there to make decisions. It’s easier to make a decision about a date. With scope you need to drill down. Good managers drill down to understand the details, so they can make informed decisions. Some aren’t able to make decisions, but we’re not talking about them today.

In that case, we need to explain what we can have by what date. Help them make the decision, and by the way, educate them about the agile process. It may not be our job, but if we want to continue doing agile development, we’ll need management backing. And we’re called to the flag.

Agile-aware people will ask another question, or mean the question in another way:”What can we get in to product by the deadline”. This is an already informed question about how we do things, and there’s an expectations for the answer to be about features. As with any communication, our answer should depend on the knowledge level of the person we’re talking with to explain, but the discussion will be more focused than the former.

Yet sometimes the question is asked before the project even started. It really means:”Is the project feasible?”. Or more delicately, is it possible to do this by a certain date. If the project hasn’t started yet, we probably don’t know much about it. We can either compare it to what we did before, or guess. The guess should not be a yes/no guess. The problem is that the answer “probably” will be translated to an an affirmative yes. What managers want to know is that you’ve actually though about it, so we expect a date range, a plan and assumptions. If it’s not enough, the manager will ask more questions. Let’s remember: management invests a lot of money in a project. Managers want to know they are not throwing it away. They want to trust you, and plans and assumptions raise that trust.

Dates dictates how we manager our projects. Milestones, arbitrary or meaningful, are the driver behind projects. Within the the project time, we should work on what’s best for the customer, realize what we can put in the product and communicate the details.

Communication leads to trust. Without trust, we cannot achieve sustainable agile process.

So let’s work on that, shall we?

Predictability Addiction

noreply@blogger.com (Gil Zilberfeld) — Wed, 09 May 2012 15:25:00 +0000

I’m addicted to predictability. I admit it. I want my life to flow along, according to plan. Sure there will be some minimal changes, but I can adapt.

I’ve given up on this long ago, as I came face-to-face with real life. I know life is not predictable. And I have embraced change, as agile has taught me.

Or have I?

At ACCU, I had a pleasure of listening to Tim Lister lightening talk about estimation. Tim talked about weather forecast and compared it to project completion date estimation. If experienced weather people can only forecast (Read: DO NOT KNOW) the direction and impact area of a storm within hundreds of miles, how can experienced developers KNOW that the project will be completed on Sep 15th next year?

We don’t. We can estimate, give a range, but we don’t know everything. So we should talk about ranges of dates.
How does that go with my predictability addiction? Not well.

I would like to know when “it will be done”, so I ask the developers leading questions. “If we do this, the risk will be reduced, right? so we can release on…”. Or “Well, we might need to add some small feature X, but it won’t take more than a week, right?”.

My questions are “designed” to give me certainty. I either remove items from the equation, or add a “known” factor to the plan. The answers help me with my addiction… to some extent. In fact, I’m setting myself up for some crushed expectations.

Estimation is just that: estimation. We should reduce risk by not doing crazy things, and sticking to practices that reduce it (testing, anyone)but that won’t get us to certainty. Here’s an example: Our team works in pairs and we have a plan for the next few months. Now one person of the team got promoted, and left the team, so we’re minus one person. How much “velocity” have we lost? Is it just the linear drop in capacity? The thing is – we don’t know. There goes predictability.

Everyone is looking for predictability, but we’re deluding ourselves, thinking we can actually get it. Accepting uncertainty just goes against human nature.
So what’s my take?

Developers, testers, people who produce software: Give ranges. Explain these are estimates, even when the managers on the other side has a similar addiction as myself. And more important – measure velocity, cycle time, or whatever you measure progress with. It’s the past results, and the course corrections that gain the trust needed from managers that your ranges are not over-inflated or extra-reduced.

Managers – Ask for ranges, as well as past results. If you ask, you will receive. Don’t be tempted to ask for a date. Don’t ask (mis)leading questions, since you’ll get them. Since we’re betting the rest of the business on software delivery, it’s a poor starting point. Start from the ranges given, and build from there.

The first step in every recovery is admission. Eleven more steps to go…

Unit Testing Star Wars Style

noreply@blogger.com (Gil Zilberfeld) — Tue, 08 May 2012 15:43:00 +0000

I’ll be presenting in the Israel .Net user group on unit testing with a star wars twist on May 22nd. So don’t be shy, learn Hebrew, if you don’t know already and register here:

http://idndug-may-2012.eventbrite.com/

And if you haven’t checked out my latest article “The Developer-Tester Divide” , what’s your excuse? While you’re at it, check the rest of the articles in the publication page.

Image taken from: http://www.quickmeme.com/meme/359jzz/

Equal Rights for Non-Functional Requirement

noreply@blogger.com (Gil Zilberfeld) — Tue, 24 Apr 2012 14:57:00 +0000

In our recent meet-up at the Agile Practitioner group, there was good talk about non-functional requirement testing. One of the first questions we discussed was how come non-functional requirements are second-class citizens. Usually they are patched on the app as an afterthought, and like any last effort, we botch it up.

One of the answers was that it’s a product management issue.

It is a simple prioritization issue. Requirements drop down the priority ladder, because someone, usually the product owner, has decided that they are not important enough as other requirements. For example, a security requirement – log-in reports in a financial application. True, we need security, but it’s not going to be the first thing we do, since we need to actually put the financial logic there too. And the latter takes precedence.

Simple prioritization, right?

Unfortunately, there’s a cost to that prioritization. Until something really bad happens, say, we need to provide these logs to the government tomorrow, all functional requirement will take precedence. So we either don’t get to that non-functional requirement, or we’ll get squeezed to do it in a third of the time it really takes to do it, and welcome to botch-city.

That’s one way requirements don’t get done. Here’s another. Let’s talk about availability. We need to be up 99.999999% of the time. All the time.

Our product owner would like this kind of availability, and the dev team says: good, prepare your wallet. The check contains a lot of zeros. After the product manages lifted his jaw off the floor, he says: “Well, let’s work on something cheaper, shall we?”. He just learned that non-functional requirements usually cost a lot more than regular requirements.

We assume that the product owner knows what’s best for the product. We’re expecting him to make the right decision, and therefore, we believe that he’s taking everything into consideration, and comes up with the perfect backlog.

Get ready for a surprise

Our product owner is not superman (or in our case, Lex Luthor). He cannot know everything about business, development, security, architecture, IT serviceability, database maintainability, and a whole lot more. It’s hard enough to keep in one’s head what the app is supposed to be doing…

If the product owner doesn’t understand security, he won’t know how to prioritize security features vs. the rest. And as humans go, will give attention to the familiar stuff over the unknown.

So how can we make sure that non-functional requirements get met?

Remember “whole team”?

In extreme programming, the “whole team” makes the decision, not just the product owner. As team members we should ask more questions: “Do we need authentication logging?”. If our poor product owner doesn’t know even what authentication logging means, he now has a mission - learn and come back with an answer. And he would love it if that question also came with an estimate.

Ideally, the product owner should learn about everything required. Ideally he should have all the answers. But this is real life. We don’t know everything. Good decisions come from a team effort.

And by asking questions, seeking information, and bringing solutions together table we’ll have our democracy where all requirements are equal.

Which Part of the Glass Are We Talking About?

noreply@blogger.com (Gil Zilberfeld) — Mon, 09 Apr 2012 14:48:00 +0000

The CHAOS report says agile projects succeed three times more than non-agile, reports Mick Cohn. Good news, until I recalled that the CHAOS manifesto defines success as on budget, on time, and with all planned features. Show me an agile project that has all the original features in it, I dare you. Agility has change built-in, which makes the CHAOS manifesto definition a contradiction in terms.

Then the State of Agile review tells us things are on the up and up, agile-wise. And read that: 70% of those doing some kind of agile development are doing unit testing!

Not likely. They may be doing some kind of automated testing, and may call what they are doing “unit testing”, but most of them don’t.

That also applies to “scrum”. Or “agile'’.

Let me present you with my half-empty glass. One of the signs of agile’s decline, is the incorporation of “agile” into non-agile orgs in a non-agile fashion. A part of the process is taking agile terms and “fitting” them into the company’s existing culture.

The indoctrination of agile by the non-agile business changes the original meaning of the terms and the values behind them. So in most companies, “Agile” means more stand-ups, and less working software. The agile adoption starts, and sometimes ends, with communication processes, rather than the adoption of software practices. Effectiveness is what business people understand and crave. Working software to them can be done by typing faster.

The problem, is that at some point, this kind of “agile” will fall short on the promise real “agile” made: to save the business from destructive projects. And when these failures accumulate, agile will be the scapegoat, with or without quotation marks. Then, we, the ambassadors of agile, will need to find new ways to rebuild the trust given to us by business, but lost because of misuse.

The irony is that the whole process is iterative. We’ll rename agile, show results, business will show interest, try to take over, succeed in the beginning, fail eventually, back to square one.

But these cycles take years, even decades. Hopefully we’ll be here to see the next round.

Expert On Everything

noreply@blogger.com (Gil Zilberfeld) — Wed, 28 Mar 2012 14:18:00 +0000

I’ve read an interesting article about how agile leaves security features off the hook.

Security features are usually counted as a non-functional requirements. Non-functional requirements have been a thorn in the side of developers for years. But as with everything, it’s goes a bit deeper.

Non-Functional requirements are hard to define. You can define uptime, but how do you make sure your design supports it? Or you want a secure product, but what does that really mean?

A couple of things happen here: The product manager usually does not know enough about non-functional features (they usually are business matter-experts, and these non-functional things are not core to the product). Sometimes, they don’t even know how define what they want, it just needs to be there.

In many of those cases, the one who does take the decision is the developer. This is usually a bad thing. In agile teams, the team makes the decision. This makes the product owner very happy, since the interpretation of what is secure or stable is now a team decision, rather than his own. People don’t like to make decisions, especially on stuff they don’t fully understand, and here the team stepped forward instead.

As a team, it feels better if everyone agrees that we should concentrate on building what we know, rather than on what we don’t. We can specify that later. That’s how the security features get dropped in priority.

Unfortunately feeling better doesn’t create a stable or a secure product.

Let me state this clearly:

If the product owner wants a secure product, he needs to understand security. If he wants uptime, he needs to have the tools to understand if the solution the team suggests is good enough. If he doesn’t, someone else will make it the decision for him. And by this, he exposes the product to all sorts of risks, from actual security breaches to legal risks.

Product owners set the priorities to what the team works on. If the team reduces the priority against their will, the product owners are not doing their job.

“I can’t be expert on everything!” You say.

True.

But you need to be on everything in your product.

That’s what responsible product owners do.

Things Don’t Just Happen

noreply@blogger.com (Gil Zilberfeld) — Wed, 21 Mar 2012 11:22:00 +0000

The more I put time into product management, since, that’s my day job, you know, I’m more aware of user experience.

I’m talking about small features or behavior that if you ask any reasonable person, and by that I mean non-programmer, you’ll get a WTF look.

Kevlin Henney shows this kind of photo, and now that it has happened to me, I thought I’d share. Let me set the scene for you: Frankfurt airport, the departure flight screen (bottom-right) goes BSOD. You can actually tell from the error what’s going on, only you need to be a programmer to enjoy it. For the rest of the people it’s a waste of a good screen. For the airport, it’s a waste of electricity.

The whole purpose of the error is to help the lucky recipient something to handle or report. Yet somewhere down the line, the end programmer forgot that the end user doesn’t hold the “How to handle BSOD” guide book for happy life. The sad thing is that the reporting part also doesn’t happen. What do most people do when with a BSOD? Restart. Regardless of the error. They can’t really read the error, it’s in an alien language.

Another example of experience gone bad. I was calling someone (who shall remain nameless) in a company (that shouldn’t but will). Here’s the voice mail message I got: “You have reached the voice mail system of company X. The person Y does not have an account in the system. Try calling later”.

Let’s see: how does it help someone who wants to reach Y. Part I: Confirmation - I got to the right company. Part II: Useless information. Part III: A very helpful message for someone who just arrived at the 21st century, but not for many others.

How do these things happen?

I can take the easy way out: A programmer decision, rather than a product manager. Developers communicate in Developish (both occurrences apply). So a programmer happened to find an edge case, needed to do some “error handling” and logged the error.

Usually that’s the case. I know at Typemock we’ve journeyed from error logging to helpful suggestions. We’re still getting better at it.

But the voicemail message wasn’t just a developer covering an edge case. Someone actually recorded the idiotic message. So there were a few people involved in approving and getting the message to me, and none of them asked a simple question: Is this helpful?

If you want to drill a bit more though, you’ll get a sense that either no one was thinking about it, or didn’t think it was important enough to make a fuss about it. Keep your head down, do your job, and don’t rock the boat.

In either case, professionalism lowers its head, waiting for the business storm to pass.

That’s sad. If we’ve learned anything in the last few years is that we can create good quality products that customers like, through proper development practices and discipline. Agile has told us that in order to make that happen, you need to be at least vocal, if not a boat-rocker.

But products like that are mediocre. They don’t put the customer experience first, but rather “do their job”, and “report”.

Much like quality, product experience is part of everyone’s job. If you code a feature, you need to understand the customer. That means, for example, that “DISK_NOT_BOOTABLE” is not helpful for a normal person. We’ve past the age where a product manage defines everything and the programmers execute the plan. It doesn’t cut it.

And sometimes you are the customer (in the voicemail case). Is that the message you want to receive?

Then be vocal. Shout “this is the most stupid message I’ve ever heard, and I seem to find it as helpful as a SysRq button on my keyboard”. (Really, what do we need it for?)

It’s called Responsibility.

If you consider yourself professional, it should be part of you.

Expectation Maintenance

noreply@blogger.com (Gil Zilberfeld) — Tue, 13 Mar 2012 16:14:00 +0000

When software projects fail, we grow the divide between business and development.

Let’s analyze a bit, shall we?

Why is the divide growing? The divide is basically a metaphor for trust. Mostly, the two sides don’t trust, or sometimes understand, each other. Their goals don’t coincide, and are not communicated correctly. Add to that some human nature, and we’ve got ourselves some fine mess.

Agile was supposed to be cure. By collaborating and showing results, it’s supposed to narrow the gap. Trust grows on each side, and everyone is happy.

Trust is gained from success. Does mistrust grow from failures?

Not exactly.

Mistrust comes from crushed expectations. The business people believed them what the developers told them about the delivery date. The developers believed the business people will not change the requirements, or would incur the needed cost. When that didn’t happen the expectations of both sides were crushed.

(by the way, don’t think that the same didn't happen when we had a successful project. Only then, we had the bitter taste of crushed expectations replaced by the sweet taste of a released project).

So we like success better. Big surprise.

Unfortunately even agile doesn’t promise success every time. And so, at some point, regardless which side you’re on, you’ll end up with some expectation shattered.

How do you narrow the divide after it’s grown?

The funny thing is, agile has that answer too.

Agile project success depends on discipline. Continue writing tests, even under pressure. Continue doing the stand ups, even if it’s known exactly what the plan is for today. Continue doing retrospectives, even if it’s not convenient to gather all the team together on one day on site.

That’s what we need to do: pick up all the fragments of expectations from the floor, then continue doing the same things that help us be successful the next time.

Because they will. And the divide will shrink.

This post may seem like it belongs in the self-help section. While this is true, remember that the writer is a cynical bastard, and if he writes this stuff, at least he believes it.

PSS

If you want to hear more from the cynical bastard, find him at the “Software Passion Summit” next week in Goteborg, Sweden talking about this stuff.

A Culture of YAGNI

noreply@blogger.com (Gil Zilberfeld) — Tue, 06 Mar 2012 16:16:00 +0000

My natural habitat is an agile software development company. I usually meet with people who are already agile, or aspiring to become agile. And then there are other times, where the “real world” hits me on the head, saying I should leave my little pond for a while, and see what’s really out there.

For the last few days I’ve been doing some very important work in a, let’s call it a government agency. People here do not develop software, but they are software users (and abusers, read on). Nice people, but they have been corrupted by a very strange force.

They don’t know what YAGNI (“You ain’t gonna need it”) is, but they practice it religiously. They put a lot of time, effort and energy (real energy – passion, anger) into working on stuff that isn’t used. They know it, yet they do it anyway.

What makes so many people work on waste? These are intelligent people, mind you, not simple drones.

People who tried to inject any agile methodology or practices and failed miserably know the answer: It’s that vague thing we can’t put our finger on called “organizational culture”.

This organization has top-down management, command and control style. The workers are managing a lot of information. A lot. This information is collected diligently over time.The collection of data, as well as filtering it up to management is the primary business goal of the organization. The organization understands there’s a data overload, so upper management requires data filtering.

But here’s the catch: Because no one is ever sure what the top man will actually ask for this time, they provide all the data, in different formats through different filters, so if there’s a question popping up, it is available in just a few clicks. And as you probably guess, no almost never looks at that information.

If we translate it to actual actions, the guys take the raw data from one system (a giant excel sheet), copy-paste to a PowerPoint slide-set, then hide/unhide stuff, copy that too, make sure the links are working correctly. In the activity I was part of, the data changed every few hours so the operation needed redoing over and over again. All this extra formatting work almost never gets viewed, because management is, rightly, looking for the most filtered data.

“Are they crazy?” you ask. “All you have to do, is just provide the filtered data, and if someone asks, and only then, hit the raw data and get some answers. That’s the logical thing to do”.

When culture and logic collide, logic rarely wins. People get used to the “crazy question of the day” and they adjust. They prepare to mitigate (which is usually a good thing), but in the process they spend too much time on the wrong work.

There’s a saying: “It’s better to ask forgiveness, than to ask permission”. I always say that if you’re a team leader, fighting the organization to get agile adoption, do the guerilla agile dance. Make the changes, hope that no one notices, and then show results.

But it’s not as easy as I make it sounds. Because culture is a very inclusive club. People within a culture accept people who fit the culture, growing the core group. When you’re fighting against the culture, it’s in all directions: upward with management, downward with your team and sideways with your peers. Some will help. Others won’t.

It’s not easy. In this organization, there’s no way of changing the culture in the apparent future. Waste will continue, because people feel safe in what they do, despite of the waste.

You might face the same problem in your organization. My advice still stand: Find allies, work to show results, get promoted and recruit and train the people who will help make the sweep.

If all that fails, because of the culture, it may be a sign to look for another organization with a different culture.

Upcoming Events

noreply@blogger.com (Gil Zilberfeld) — Thu, 01 Mar 2012 18:33:00 +0000

It’s update time again. Here’s the plan for the next few months:

March 19-20: Software passion summit, in Goteborg, Sweden. I’ll be talking about the ultimate question in software: “When will it be done?”. I hope to provide some answers as well. This is a new conference, and by the looks of it, is going to be very special.

April 25-28: ACCU, in Oxford, England. This session is going to be a back to roots for me. I called it “From Crappy to Classy: Legacy Code Resuscitation”. Basically, it’s just taking some crappy C++ code, and through tests and refactoring, making it beautiful. And there’s no fun like C++ refactoring, everybody knows that!

In an undisclosed date in May, I’m going to be back in the Israeli .Net User Group (which has also been resuscitated), talking about unit testing. Formal name: A new hope.

And who knows what will happen in June?

Stay tuned.

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.