Geek Out of Water - Gil Zilberfeld's Ramblings

“7 Steps for writing your first test” Slides

noreply@blogger.com (Gil Zilberfeld) — Wed, 08 May 2013 14:31:00 +0000

Here are the slides from my Sela Developer Practices 2013 talk:

PS: If you were not one of the thousands in attendance, I’m doing it as a Typemock webinar, Thursday May 9th. Register here.

May 7th, 2013

noreply@blogger.com (Gil Zilberfeld) — Mon, 06 May 2013 07:25:00 +0000

Tomorrow I’ve got a full day.

In the morning, I’m giving a talk at the Sela Developer Practice. This is going to be about “7 steps to writing your first unit test”.

Following that, I’m going to hang out at the Typemock booth at Agile Israel 2013.

If you’re there, come and say hi.

If not, well, I’ll catch you later.

I Have An Idea!

noreply@blogger.com (Gil Zilberfeld) — Wed, 01 May 2013 13:40:00 +0000

The biggest waste in software is what we build and isn’t used. Since we can’t know in advance what will be a selling feature, we have to implement the feature, put it in the wild, and hope for the best.

Wait, there’s more: Remember that everything we code comes with a maintenance cost, so it may be that we build something that instead of helping us make money, can even lose money. A lot over time.

To put it bluntly, that doesn’t sound like a smart strategy, right?

I like the lean startup idea of experimenting. With a low-cost experiment we can learn before implementing a whole feature if it’s worth it, or at least get a sense of success. So I’ve began an experiment on experimenting.

After thinking long about it (almost 2 minutes!) I decided to call it the “I have an idea” form. Ideas for features vary in size, and sometimes it’s a big effort in implementation. So before I’m going full force with implementing, I need to test the waters. By forcing myself to put this in words, I can really see if it’s worth it at all, or how we can build an experiment to see if that works.

The form (Word template) has two parts: Hypothesis and Experiment

In the Hypothesis part, we describe the feature from a customer point of view:

What is the idea?
Whom does it help?
What does it solve?

In the Experiment part, we describe how we can learn if our hypothesis has merit:

What are we going to do?
Who are we going to show it to?
How are we going to measure it?
How much is going to cost us?
How will we know if it succeeded?

That’s it. Pretty simple process to signal me if I’ve given something enough thought.

Will it work?

I’ll let you know.

PS. If you look closely, it’s just not for features.

Processes and Tools Over Individuals and Interactions

noreply@blogger.com (Gil Zilberfeld) — Mon, 08 Apr 2013 15:17:00 +0000

When I was a developer, I couldn’t understand why other developers were not as competent as me.

When I was a team leader, I couldn’t understand why my team didn’t measure up to my glorified project saving success.

When I joined Typemock, I couldn’t understand why most developers are prepared to live in bug-world, rather than just unit test.

War never changes…

During my first years at Typemock, I decided not to enter the “Typemock is too powerful” debate. The main argument was that tool capabilities put constraints on the developer. With more restrictions (that coincide with some good design principles), developers will not be able to abuse the tool. We looked at it as flexibility for any design. It was a religious debate, and as these go they were tiring.

When I first read the discussion around giving the same mocking abilities to FakeItEasy, it looked like the same debate, only with different actors.

This time, though, something felt different. I couldn’t put a finger on it at first. But what Igal (@hmemcpy) said connected with other things I heard from other Typemock alumni that went into the wild (in addition to the other regular voices): We don’t trust developers to do what we (or our boss) hired them to do. Developers, who are not skilled enough, will harm our way of life: Our code base, our practices. Where it really hurts.

The thought that having a tool will drive developers to better design is absurd. I’ve got examples aplenty. But it’s even worse: we’ve started thinking in terms of damage control. It’s no longer “with great power, comes great responsibility”. It’s “in straight jacket they can’t do much harm”. (And it’s always “they”, isn’t it?)

I was there before. I saw what unskilled people did as acts of stupidity. I was angry. I put constraints in place so “they” wouldn’t hurt “the team’s” progress.

It’s really not about tools

It’s about “us” saving the project in spite of “them”.

We think it’s the only way, since we know better. So we tie their hands. This leaves no hope for “them”, so they leave. We’d like to get more people like us, but come on, what are the chances?

The economics of the situation are simple – if you leverage the people you have, your chances of success are much better than searching for super-heroes.

But we’d rather take shortcuts. It feels we’re saving the ship. In fact we’re taking in more load.

“Individuals and interactions over processes and tools”

If you’re not willing to invest in your people, tools surely won’t save you.

The Better Side Of Anger

noreply@blogger.com (Gil Zilberfeld) — Mon, 25 Mar 2013 11:20:00 +0000

It was the nth time that a supplier has failed us. If we analyze it logically, there were two options: Get mad or roll with the punches.

Since we’re not Vulcan, it’s not really a logical choice: what we felt is anger, defeat. Or both.

Can’t do much with defeat. But anger is totally different.

From childhood, we’re taught that anger is a “negative emotion”. It’s counter productive. It’s not effective.

That’s a lie.

First thing, we can’t control feeling anger more than we can control feeling happy. Emotions are emotions and cannot be controlled. What maybe ineffective is our behavior based on these emotions. And we are fully able to control behavior. So maybe it’s not effective to stand in the room full of people, shout in anger at your boss, threatening to quit. (Tried it, jury’s still out about how effective it really was).

Because anger is “bad”, we don’t talk about how anger opens the door to innovation and creativity. When you’re pissed, you’re starting to think about other options. What you can do differently.

So we can replace that supplier. We can readjust our work with them. Or divert money we spend to do stuff ourselves.

We can try something else that we didn’t think was possible, because what happened until now was acceptable. Just the way it is.

Few years ago, I got angry that another build was thrown back to the development by the testers. We’ve introduced smoke tests. We changed the way worked because we were angry. (Ok, I got angry).

Anger is not a negative emotion. Don’t be afraid of it. Don’t contain it.

What you do with it maybe life-changing.

The Real Enemy

noreply@blogger.com (Gil Zilberfeld) — Sun, 10 Mar 2013 20:28:00 +0000

Lior Friedman asked whether a tester should know how to program or become obsolete. Lanette Creamer said the same fate awaits programmers who can’t test.

This kind of discussion only happens in the dark corner of the software world. Within our small community.

In most companies, nobody thinks about this.

Human Resources

“When we hire a tester, make sure he does only that. God knows we don’t want to pay him like a real programmer.”

“When we hire a programmer, we don’t want her to spend her time testing, that would be a waste.”

Companies still hire to fill positions. Programmers have a very different job description than testers. Job descriptions, however, don’t help with fulfilling the business’ mission.

It starts with hiring, but doesn’t stop there. Let’s say this company is one that really believes in “our employees are our most valuable assets”. How does it train its employees? Of course, programmers are encouraged to learn more programming and debugging techniques. Testers are trained in deeper testing methodologies.

Changing Roles

The agile manifesto talks about collaboration and interaction. Scrum talks about the team. Neither talked about testing and programming roles.

Extreme programming, you say? Doesn’t mention roles. But does talk about programming and testing.

The reason there’s no squabbling over roles in agile land is that role separation is really none of the business’ business. Agile methodologies are about making the business money by building quality software fast. All the process you need is already there, anything else just puts wasteful constraints on the system.

Software needs to be of high quality. For that it needs to be programmed and tested. It doesn’t really say who does what. Make it so.

And yet we’re still attached to these titles. Asking if programmers can test, or tester can program is reinforcing titles over skills.

What we’re actually doing is reinforcing HR’s role in the organization.

We’re All Developers Here

Programmers should know how to test their code. Without testing they are going to waste both theirs and the company’s time on bugs.

Testers need to program. Without automation, they are going to waste both theirs and the company’s time on manual rote work.

We all value working software over comprehensive job descriptions.

We’re all software developers.

Who hate HR.

Skillz

noreply@blogger.com (Gil Zilberfeld) — Sun, 03 Mar 2013 18:39:00 +0000

Everyone has skills.

According to the dictionary, here’s the definition of Skill: The ability to use one's knowledge effectively and readily in execution or performance.

In other words: ability to do something. Some will say: ability to do something well.

In a tweet a while ago, Jim Grenning defined the 3 skills of refactoring:

Recognize bad code
Envision a better design
Incrementally transform bad into better, keep test passing

Ok, that’s four, but regardless, that’s a great definition. And he managed to put all that into one tweet!

Obviously, all those are skills, since they define the ability to do something.

But read them again: Not just abilities. They are higher abilities of great programmers. It doesn’t apply to most of us:

Not every programmer can recognize bad code. Although every programmer can write bad code.
Envision a better design? A different design maybe, but to envision a better one, you need to have skill #1, and then understand how it can be improved.
To do the improvements incrementally requires not just the discipline, which not many of us have. It requires to envision the steps (skill #2), when most of us (sometimes) see the next step.

The good news? While not every programmer does this today, everyone can get there.

To me, skill is not just the ability. It’s the journey to achieve the higher level.

Anyone can improve their skills. The road is long, hard and full of learning, but everyone can get there. Most programmers don’t, by the way.

Decide to take the learning path. For example:

Look at you code critically. Will you understand it in a year’s time?
Once you’ve got the code working the first time, throw it away. Rewrite it better.
And write tests. Lots. It’s a skill too, you’ll get better.

Skillz. Jim Grenning has them.

You can too.

Chicken Thinking

noreply@blogger.com (Gil Zilberfeld) — Sun, 24 Feb 2013 20:55:00 +0000

Every now and then I go back to the army to give back, well something. And whenever I go I learn something new. This time, it was one week after my talk “It’s not that simple”. If it was the other way around, I’d have a couple more examples for the talk. Since time flows only in one direction, I’ll write the story here.

To protect the innocent, the guilty and future combat missions, I’ll describe what we do as the Chicken Control. For the sake of our story, we make sure all chickens get to the other side. And we manage the process: We identify the chickens, know how many go from one side get to the other side, and how many get lost in the middle. As you understand, this is top national security stuff.

This kind of business is usually done by dozens of people, but this time most of the work was simulated. Instead of actually passing real chickens across the road, professional chicken trainers were typing chicken data into the computer, simulating chicken flow across the system.

I’m mentioning this, since people who are not chicken experts, may think that chickens can just cross the road by themselves. Not so. Maybe in urban myths, but not in real life where chickens cost a lot, and so is the crossing. Chicken flow simulation saves the country big bucks.

Let’s get back to the drill. Everyone was aware that the data we see on the computer was simulated data. Not only that, we at Chicken Control know the typists type in chicken flow data at their leisure. It was part of the drill.

Yet when our team at Chicken Control looked at the data, they said: “It’s noon, and we’re just at 20%”.

These are smart people. They are aware of everything I told you and they have a lot of experience at Chicken Control. They are aware the 20% is just a simulated number, yet they look at it as “just 20%”. As if it had a meaning in the context of the drill. It didn’t.

It would if we were dealing with real chickens, but that wasn’t the case. When I reminded the team that the numbers they see are fictional and are dependent only on the free time of the typist on the other end, I was told: “Gil, you’re starting to annoy us”. After a couple of times I decided to get less annoying and shut up.

But not for long, since in the daily chicken review, the simulated chicken flow was discussed. The numbers when reviewed, and the team realized it wasn’t “just 20%”. Apparently they got to 20% too soon. They requested the typists type in the chicken data in a life-like chicken flow-rate.

Let me explain: Nobody sees this data outside the team. We’re simulating data for ourselves, observe it, and regulate the data, so we can review it again. Just us.

For the agile readers – this is a good thing. It’s a regular PDCA (plan, do, check, act) loop. Every system should have a closed-loop feedback like that.

For the lean readers – this is waste. Since the numbers don’t go outside, smart people are wasting time on the rate of typing numbers, which doesn’t have any real value to anyone, since nobody else gets exposed to these numbers.

And they call me annoying.

There are a couple of lessons here:

Deming was right: “Put a good person in a bad system and the bad system wins, no contest.” It was amazing how quickly people, whose day job is to control actual important business numbers, lose focus of the same numbers (chicken-related, but important all the same) and their meaning.
Put a mirror in front of them, and they’ll break it. People were really pissed at me for breaking the illusion of the game. There was no point in the game, but with a couple of remarks, I was labeled a trouble maker. In a matter of hours. By people who know me for more than a few years.
A person can be told “you’re annoying” a very low number of times before he shuts up. Even if he’s right.
System thinking is like prescription glasses. Once you’ve got them on, you see things differently. But you can’t really pass them around and let people use them. They just won’t fit, and people will not look at the system funny, they look at you funny.
If your system is not producing value, every control mechanism you put into it, is waste.

Next time we’re going to deal with real chickens. I’m sure things will make more sense then.

After all, wars are won by the people who know exactly how many chickens crossed the road.

“Agile Tribe Wars” Slides

noreply@blogger.com (Gil Zilberfeld) — Tue, 19 Feb 2013 13:57:00 +0000

Last week I gave the “Agile tribe war” talk (short short version) in Hebrew at DevCon TLV (which was mighty fun and at an excellent location, bar-wise). Next week, I’m doing the normal version in English in a webinar, so if you’re interested what the Justice League is doing there in the end, register here.

Here’s the prezi:

Maturity

noreply@blogger.com (Gil Zilberfeld) — Tue, 05 Feb 2013 11:57:00 +0000

It's a few days now after the Agile Practitioners 2013 Conference. Great people make great conferences, and they certainly did this time. I spent most of my time meeting and talking with people, and I also enjoyed some great sessions too.

This was a local conference (for me anyway) and I got a different vibe, than what I get in international conferences. There's also a chance that because Israelis are not shy (read: brutal) about letting you know how they feel.

Here are a few of my observations:

Agile is definitely not dead. More people realize that the old ways of developing software are not enough. Many new people came to the conference, which is always a sign for non-deadness.
Kanban is getting traction. Yuval Yeret’s session was not an introductory one, yet drew a large crowd including both newbies and experienced people.
The perception of agile is changing. People gain experience and understand that the benefits of agile come with a cost. Change is hard. Its a long way, and yet people are willing to take the high road.
The theme of the conference, as well as the depth of the sessions, raises the stakes. It is no longer about agile for software developers, it’s an organizational transformation. Ambitious goal, that along with embracing reality may eventually succeed.

All these point to one thing:maturity. Not of agile, or the values behind it. The maturity of people.

This is important.

I’m not sure about what “successful agile” is. I think it’s about transforming organizations into learning entities, that accept reality, willing to lose grounds in order to gain some later, and most of all, got happy people working in a safe environment. This may change tomorrow, but hey, I’m writing this today.

I do know one thing: To achieve this, what you don’t need is a bunch of crazy messiahs, calling for change because they are the only ones who know better. Been there, didn't succeed in that.

The successful mature way, is to ask tough questions and learn. To take the risks, weight the costs, fail and succeed in experiments, and learn from both.

And when you show results, you get promoted, and can make more changes.

The transformation is coming. As long as we’re running a marathon, rather than sprints (pun intended), I think agile might have a chance.

If not, I refer you to my agile is doomed post. I’m covered.

“It’s Not That Simple” Slides

noreply@blogger.com (Gil Zilberfeld) — Wed, 30 Jan 2013 17:44:00 +0000

Had great fun today at the Agile Practitioners 2013 conference today. Great keynotes by Boris Gloger and Dan North and great presentations by others, as well as meeting old and new faces.

For the ones who missed my presentation, and those who want to feast their eyes again, here are the slides:

Upcoming Gigs

noreply@blogger.com (Gil Zilberfeld) — Mon, 14 Jan 2013 09:24:00 +0000

I usually don’t do this often but things have piled up recently. So here is where you’ll find me in the next months:

Agile practitioners Israel: Looks to be a great 2nd conference. With guest presenters like Dan North, Yves Hanoulle and Markus Gartner, it’s bound to be awesome. I’m going to give a presentation called “It’s not that simple”. Because it just isn’t. Jan-30th, 2013 in Kfar Hamakabia, Israel.

DevCon TLV: This is a one-day conference abound with technologies for developers in Tel Aviv. To counter all the technologies, there's an agile track. I’m going to give the short version of the Agile Tribe Wars. Joining me on the track are Agile Sparks’ Yuval Yeret and Better Place’s Dror Helper. Feb-14th 2013 in Tel Aviv.

The Reversim Summit: Only a couple of days later, there’s a two-day conference, for developers. There are a lot of topics from development, craftsmanship, product management and devops. Which I think is a kind of first in Israel. I’m going to do a workshop on how to “TDD a spaceship”. If you don’t have a spaceship of your own, this could be your opportunity. Feb-18-19th 2013 in Tel Aviv.

Agile Dev Practices: This is a good one with lots of great speakers, all about agile and kanban . I’m really excited about this, because of speakers like Ellen Gottesdiener, Pawel Brodzinsky Olav Maasen and Chris Matts. I’m going to do the Unit Testing Spring Cleaning presentation about how to make good unit tests last. Mar-5-8th 2013 in Potsdam-Berlin.

Sela Developer Practice: This is more Microsoft technology oriented. Sela is a premiere software training school in Israel, and they have some nice presentations on all kinds of MS technologies. And they have rounded up a nice bunch of internation speakers, so if MS Tech is your thing, go there. I’m giving a “7 steps to write your first test”, focusing on going over the hump of starting out with unit testing. 5-9 May 2013, Tel Aviv.

Yup, pretty busy. And who knows, maybe more. Stay tuned.

Tango With Trello

noreply@blogger.com (Gil Zilberfeld) — Mon, 31 Dec 2012 15:42:00 +0000

My two-step forward, one-step back dance with Trello began way before I boarded the kanban train. In the beginning we used it as our main tool for planning, documenting and controlling development. The team was willing to try it, after using a whiteboard and (not-so) sticky notes with the planned-doing-done trio, which we copied to Trello.

Starting out it was ok. We had a dedicated screen for it. We had the stand up meeting near it. And then overtime, we moved away from that screen. The Trello board was always there, ready to be used in a push of a button on your own screen. Yet only some of us looked at it occasionally.

Which kind of bothered me, but I was willing to go with it. Push of a button, right?

Something else made me yearn for the manual board, but at the time, I couldn’t tell what it was.

When I started reading more about kanban, I thought Trello might be my board.I was experimenting with some tools, and Trello fit into my new view of the world. I still used the trio, since there wasn’t much to add. After reading “Personal kanban” I added the “today” and “the pen” and recently the “for reflection” columns. Got the WIP limit up on each list. Plus, the iPhone app for Trello made it easy to add tasks wherever I was.

I’ve made a habit of reviewing it weekly, daily and when moving tickets around. So it’s pretty much up there all the time. I like the visibility that was missing from the team board. But it’s still a button push away, right?

There was still something bothering me, and I still couldn’t put my finger on it.

When we started re-organizing the support team, we’ve started off with a manual whiteboard again. We’ve played with different configurations, and after a while I could finally say what I liked about the whiteboard over Trello: It was big.

It wasn’t that big in the beginning. We’ve put two big boards together to show the entire workflow. You can actually have a look at the wall, and everything good, and especially bad, was staring you in your face. And you needed to do something about it. Which is the whole point of a big board.

On a small screen, you can’t see everything, as the lists contain too many tasks. You can scroll up and down to see everything, but for that you need to be near the screen, holding the mouse.

You can’t see the whole picture.

That’s why Trello works for me personally, on my screen. That’s why it doesn’t work for me as a team information radiator.

The agile manifesto tells us to value individuals and interactions over processes and tools. Our tools should not tell us how to work, but instead should serve the work. The tools are not there to put constraints on us, individuals.

Yet they sometimes provide productivity enhancements. The team seems to like this productivity over big picture view, at least for now.

For the time being I’m going to continue using Trello for as my personal kanban system.

Even at that, I find the lack of big picture… disturbing.

Software Economics

noreply@blogger.com (Gil Zilberfeld) — Mon, 24 Dec 2012 15:10:00 +0000

Jason Gorman describes (in a very nice manner) how software courses are lowering the bar. It’s up to us to keep the bar higher.

I agree completely. Yet what happens with scrum certification in the last years, has started long before. We’d like to think of software as a craft and development as a skill. If that was true, there could be a big change in software quality, cost of maintenance will drop, and customers around the world will be dancing and singing hallelujah.

Software, like anything, succumbs to supply and demand. The bad news is that most developers are average. As with every large population, we can rate them all on a bell curve. With age and experience there’s a shift to the right (more good developers), but against that, new inexperienced developers come in (more bad developers), and some leave the trade altogether (all kinds). So most of developers remain “average”, economically speaking.

Companies don’t want software to be developed by average developers. They would like them to be excellent. But those excellent guys cost a lot, because they are in short supply, and the recruiting takes ages.

So the next best thing: Get average developers and get them to a better level. There’s a risk that when they become better, they’ll leave for a better pay somewhere else. That’s economy for you. But usually companies understand that the risk is much lower than the risk of going out of business because the developers remain average. So how do they do it?

The traditional way is training. They bring in a great trainer, pay him a lot, and let him do his thing. And then they expect some ROI. Turns out it’s a recipe for disaster.

The problem is that a few days courses really can’t raise the level of developers. But that’s not all: In fact, there’s a bigger problem. Organizations can’t really calculate the ROI, since they can’t evaluate the current level of software skills, can’t measure the training result, and how it translates to actual business. That’s because the people who organize these courses don’t understand the (low) value of courses. Or software altogether. The disaster comes when expectations crash, usually on the heads of the developers.

Ah, but where ignorance is abound, there’s money to be made. There are many who offer courses from HTML to CSM (or the “learn 3 languages in 1 day” Jason described), because there are many companies, who don’t understand software, but are willing to invest in what they think will give them a competitive edge. Cue the crashing sounds.

Software takes a long time to learn to do right. At least a few years. Good software people know that. They can actually raise the bar for recruiting and training other developers. They can train new and average developers to become better.

But mostly, it doesn’t even make a dent in the whole software economy. Most developers are average, and raising the bar to their level just means more average developers. It’s just mathematics.

Of course the developers reading this blog are not only above-average – they are also smarter, taller and more beautiful. To you I say- raise the bar. Get as much as you can from the software economy.

Just as long as you remember there’s a big system in play. Set your expectations realistically.

The numbers are against us.

Are Estimations Harmful?

noreply@blogger.com (Gil Zilberfeld) — Tue, 18 Dec 2012 16:21:00 +0000

In the beginning we had plans. These plans were crucial to the business organizations. They relied on products being ready, so marketing could have marketing prepared, sales can sell them, and support support them.

Then reality happened. Either the products were not ready on time, or their quality was bad, or were not what the customer wanted. Most of the time, all three.

Managers realized they needed to put things back in order and cracked the whip. Of course, this didn’t help. It added demoralization and more turnover, which was not really helpful to the organization.

Agile methods tried to deal with quality and customer fit. But instead of having full scope in unrealistic deadlines, it kept the deadlines. Since customer fit is much more important than scope, we loosened the scope reigns, and instead got incremental releases, on date with incremental relevant features.

In theory, at least.

Although the product development might have changed, and is now producing releases frequently, and even better quality, the rest of the organization hasn’t changed. Marketing still needs to know when to prepare material for product launch. Sales need training before that.

The agile development process still needs to fit into the rest of the organization. And it made an effort to do it. The planning process has two objectives: The first is to understand the requirement better. The second is about giving some predictability to the product owner, who is the proxy for the rest of the world.

Estimations are just that, so there are misses. The problem starts when we’re starting to hear estimations as promises and commitments. When we do that, a funny thing happens – the estimations become bigger. The same task now takes longer. Reality is elastic.

Gaming the system

People do not do this out of spite. They are professionals. What they do is take precautions. They do not feel safe (since the boss blames them for missing the estimate) so they make sure they don’t get in trouble. If all goes well, the estimations are met, and the product is delivered. If all goes well.

What worked for the development organizations though is bad for whole company though. The products get delivered but late. And now the boss has a different complaint: You’re working too slow.

Can’t please some people.

Necessary evil

Estimation are harmful because they breed blame. Since estimations are not certain, they have inherent risk. And nobody wants to hear about risks.

But we can’t change the entire organization today. It still needs predictability, even if it’s only a mirage. (I admit, I ask for estimates, and I know fully well they mean nothing. But I feel much better with an imaginary one, than with none at all).

Kanabn’s approach for creating predictability is based on lead times historic data, but it’s still not deterministic. They are still estimates. Maybe more grounded, but at anytime can explode into mega-tasks and break the fragile reality for everyone.

The hard answer is that old XP saying: Embrace change. Face reality. Understand that the plans we build are brittle. They make us feel better, and give us some grounds for better planning, but they can change in a wave of a hand.

However, we can’t make people embrace change. We can show them, time and again, that what we planned broke. Some will understand logically, but will continue to behave as before. So we’ll get asked about estimations anyway.

There is one thing we can do. Since estimation is harmful and doesn’t help, there’s no need to work on it so much. If you’re spending a day for a team of 10 on estimations, you’re throwing money away. Give some broad estimation and start developing.

After all, isn’t delivering software better than just guessing and discussing it??

What Is Agile

noreply@blogger.com (Gil Zilberfeld) — Sun, 02 Dec 2012 16:59:00 +0000

Agile is a mindset.

It is not a goal or end state. You can't be agile because someone or something (including certificates) say so.

There are no agile people (Sorry Yves). But, there can be agile organizations.

Agile organizations are in constant pursuit of improvement. They constantly learn and improve quality. They use the proper tools and processes to support improvement. And improve those as well.

Agile organizations respond quickly and effectively in a state of uncertainty. To succeed in a state of uncertainty, agile organizations trust their people. People feel safe to experiment. There is no penalty for failure, rather encouragement for learning. Agile organizations bring out the best their in people.

Agile is not a private club. Everyone can join in. It embraces collaboration and abhors exclusion.

Agile is about putting people first.

All the good things that come later are side effects.

Isn’t It Ironic?

noreply@blogger.com (Gil Zilberfeld) — Tue, 27 Nov 2012 16:30:00 +0000

There are many agile conferences these days. Many of them are not about what we used to call “agile” anymore. In fact, a friend pointed out when I mentioned a TDD session from an agile conference, saying: Really? An agile presentation with code?

Most of the topics today are moving towards lean, kanban, leadership and organizational transformation. It seems we are no longer satisfied with just transforming software departments around, we’re ready to take on whole organizations.

It happened so fast

Two major things have happened during the recent years. As scrum helped agile cross the chasm, it became the darling of the business world. The magic of scrum is in what it leaves behind – since it’s technically neutral, it’s easy to sell to managers. Without TDD or pair programming, business people are drawn to its process-based methodology.

And where there’s demand there would be supply – as more business people flocked to agile conferences, the topics shifted from software to organizational ones. You’d probably expect some resistance, right? Not quite.

It’s funny: Once we said software is completely different than anything else, and now we’re ready to apply it to everything!

And so, business people and agile people build symbiotic life together, riding together towards the sunset.

Hey, remember software?

In a twit-chat a few weeks ago, Ulrika Park said: stop talking about agile testing, agile development – instead talk about testing and development. The word “agile” is overused, and many times abused. This happens a lot in pop culture. Yes, as it matured, “agile” now goes even with marketing. Is agile cooking next?

We’ve lost our creation, and others have taken control.

Not many agile conferences sessions left for developers. We all know about TDD, and there’s no reason to talk about pair programming any more. All the XP practices have already been discussed, and have become boring. Like, simple design, dude? What’s so interesting about that?

One territory is still left for ex-XPers – craftsmanship groups and code retreats. The rest of the development conferences present more new technologies, rather than old practices.

I’m not bitter (much). Frankly, these days I find lean and system thinking more interesting than “boring” code reviews. I also understand that success sometimes finds different directions than how you envisioned it.

I do feel that it happened too fast, though. Few developers had time to really master the software practices. Craftsmen are still a very small group. The people entering the software profession today will have to learn the art by scavenging for books and videos, and maybe reinvent stuff that’s already out there (There’s an Israeli alt.net un-conference happening soon – the organizer thought it’s the first of its kind in Israel, while we already had four). The conferences were the way to share how software development is and should be - now they are going away.

To use a lean term – what a waste.

Also there’s a lot of irony here.

We’re leaving behind the things that take time to master (but are the key to success), only to run after the next new thing.

It’s what we used to do as we started programming, remember?

Upcoming Talks

noreply@blogger.com (Gil Zilberfeld) — Mon, 19 Nov 2012 14:28:00 +0000

It’s time to talk about when I’m going to talk next.

January 29-30th is Israeli 2nd annual Agile Practitioners conference. While having a 2nd year in a row in Israel is a success by itself. But wait, there’s more. Keynoting are Dan North and Boris Gloger, with more international speakers, as well as some of the best Israeli agile speakers this side of the rockets, like kanban expert Yuval Yeret and Typemock alumni (who is now in a BetterPlace) Dror Helper.

Friends, Israelis, countrymen, lend me your ear: Don’t miss this conference.

My talk is called this year “It’s not that simple”. Because life, agile and everything else isn’t – it’s complex. I’m going to talk about complexity and system thinking, and touch on the cynefin framework for good measure.

Then in March I’m going to Agile Dev Practices in Potsdam/Berlin. I like the agenda, as well as great speakers including Chris Matts, Olav Maassen and Bob Galen. My talk is “Unit Testing Spring Cleaning” – solutions to adolescent unit testing problems. Also coming is Lior Friedman, who incidentally is an organizer of the Agile Practitioners conference mentioned somewhere in this post.

If you’re interested in agile and lean development and management, these two are great options. Come by and say hi.

Planning some more, stay tuned.

I Want Answers Now!

noreply@blogger.com (Gil Zilberfeld) — Mon, 12 Nov 2012 15:26:00 +0000

I’ve become more aware how agile is perceived by different people, recently when I was at Agile Eastern Europe conference.

It was an unusual experience: my usual day job has been for a long time about improvement. My twitter conversations are about high level lean and advanced agile stuff.I’m floating happily inside my echo chamber.

The conference was an opportunity to meet other people: The newly initiated. There were a lot of scrum masters, product owners, developers and testers who have seen the light. They recently drank the agile kool-aid. They had lots of questions. They just needed answers.

And that’s where the problem started.

People want solutions

Regardless of how you frame it, people want the solution X to problem Y. And they want it now.

There was an excellent live coaching session with Lyssa Adkins and Michael Spayd. In this session, volunteers from the audience (really brave ones, I admit) talked about their problems and got coached on the spot. (This was an excellent learning experience, recommended).

The one thing that got stuck in my brain is that one of the coachees restated that her problem was that her team was not motivated. She wanted to increase their motivation.

Let me translate: “Agile makes developers motivated. Now I know I’m starting in agile, so there’s a couple of steps I’m missing, but once I understand what they are, my people will see the light. So all I need is help with those bits, and you trainers with so much experience can grant me that wish.”

Agile is not a solution

Agile does not increase motivation. There is a good correlation between teams that use agile mechanics and motivation. But saying our that be because we do standups we should be more motivated is silly.

Only it doesn’t seem so to the recent convert. Same with any religion, isn’t it? The newly initiated cannot see why others around them cannot make that step, all they need to do is invoke X to get others onboard.

The right thing to do is to confront them with the truth first (Lyssa did – You cannot motivate people, but you can help them get motivated).

Seems like this did not go very well. More like: That’s nice, but I’ll probably find my answer somewhere else.

Agile is an experience

The road is long, and experience is learned on the way. Yet people can’t wait. They know the solutions are there because other people promise they are (I’m looking at you CSM). And let’s face it, if I know there is an answer, why should I wait a year to learn it? Principles and guidelines are nice. Answers now are better.

I’d like to live in this world too. And that’s not going to happen soon.

Until we get there, I suggest a humble addition to the Agile Manifesto:

We value gaining experience over instant clear-cut answers. We’d like to have the ones on the right, but will make the best of the left one.

The learning experience helps us resolve situations. But only from our context. An answer may have helped others. But given in another context, may cause harm. Eventually we can learn how we can solve issues, and maybe even get our team motivated. But it’s never a copy & paste answer.

I Do Not Think It Means What You Think It Means

noreply@blogger.com (Gil Zilberfeld) — Tue, 30 Oct 2012 19:59:00 +0000

Here’s another example of why language matters, and how the words we choose matter so much.

I tried to join the European Lean-Kanban tour, not in person, but on twitter. (By the way, seems like an awesome tour, I’m thinking about going there next time around). And then the following tweet comes up:

"@cyetain: Talking to @DReinertsen at #lkfr12 he prefers "Deferred Work" to Tech Debt Metaphor. I think it is a bit clearer too..."

Before I give my interpretation, I give thanks to Jabe Bloom, who tweeted like crazy and made me feel at home (online) and for reporting this tweet (and giving birth to this blog post by proxy:)). And Don Reinertsen, I’m gaining more respect for everyday.

Now that the niceties are out of the way…

Technical Debt or Deferred Work?

When developers talk about technical debt, the words say: There’s some technical stuff we left out, which will come back to bite us. The refactoring we didn’t do will cost us when we’ll enhance that feature. Those tests we skipped writing, are going to cost us in regression bugs.

Note the economic jargon: The debt is an economic one, NOT technical. That’s no coincidence. Economics is a better way to persuade managers to listen to developers.

There’s also an emotional nuance in the term. When we’re taking on technical debt, we, developers, are carrying the cross for the company. Not only that, we take the blame, and know we’ll pay the price later. Or we can translate it to: We’re warning you, managers, this “joint” decision is on your head.

From the manager’s side, things look much clearer: We’re always prioritizing stuff. We can’t do everything we want, and things get dropped. So in the upcoming release, we’re going to drop these pesky technical things we don’t really understand. We do understand there are associated costs and risks (as the developers tried to explain), and we’re ready to decide.

We’re really deferring work. This is a business decision.

Not Just Words

Agile started as a solution to a problem: building a bridge between developers and the business people. The bridge is built on trust. Trust is built on communication. When we use charged words on one side, or disregard this emotional charge from the other side, we’re adding cracks to the bridge.

A few cracks will not break the bridge.

What do you think happens when there are many of them?

AgileEE 2012 Videos

noreply@blogger.com (Gil Zilberfeld) — Thu, 25 Oct 2012 13:06:00 +0000

Well it’s been a great fun going to Agile Eastern Europe this year. Hope to get back there next year!

Here are the videos of my talks there.

First, the lightning talk: Will you still love me tomorrow?

And my main talk: 10 Phrases that can derail an agile project

What I’ve Learned From Reality TV

noreply@blogger.com (Gil Zilberfeld) — Mon, 22 Oct 2012 13:33:00 +0000

I’m not even a small fan of reality TV. With one exception: I watch Hell’s Kitchen almost since the beginning. I wish I could say I do it to improve myself, learn something, but it’s just a guilty pleasure.

By now, I know all the tricks in the book. I’m almost never surprised about who’s going home. I can tell who goes to the finals and why. I also know that what I see is not exactly what really happens (reality show, right?). It’s not boring, but I I know what kind of mind games the production is playing.

But in the last season, as I was watching, a light bulb lit above my head. I’ve noticed something that was there in front of me all the time.

Game Theory Coming To Real Life

I know, I know. This is a reality GAME show. What did I expect? Yet, it struck a chord, when I said to my co-watcher wife: This is exactly the prisoner’s dilemma!

The players try to work as a team, but hold back, or strike back, just so nobody else gets ahead. Many times the team fails, just because of a “me first” behavior.

For me this was another proof that system thinking is taking over my life. So watching Hell’s Kitchen is not just fun, I can now call it science!

From Reality Shows To Reality

In our life, we have goals that carry rewards (money, feeling good, titles) and punishments (staying after work to complete stuff, feeling bad, getting fired). Our default way of thinking is that if we do X, we’ll get Y. It’s linear thinking, which is easy on our brains, but unfortunately, has nothing to do with reality.

We are not the lone actors in the system. There are other actors with their own views, motivations and values. For teams to succeed, we need to change our point of view, and understand that others view reality differently.

Especially if you’re a leader. Command and control doesn’t work in complex systems. What you can do is rearrange the environment (more rewards, less punishments) so the actors can work more effectively.

The producers of Hell’s Kitchen understand that. What they do maybe immoral, because the product is the result of the production manipulating the players. Yet managers need to play the game as well.

Because no matter how we look at it, eventually we’ll examine the result for success or failure. We want to have a fun show. Or a quality product on time.

Rather than a late boring product show.

Wisdom of Crowds Is The Opposite of Innovation

noreply@blogger.com (Gil Zilberfeld) — Tue, 09 Oct 2012 14:02:00 +0000

I was watching a presentation called “Is it me, or is everything $#!t?”. I recommend watching it for yourselves, but here’s a taste.

Consider the wisdom of crowds. If we can check out a reality TV show, and ask the crowds what they think about ideas on it, we’d get a normal distribution, sort of. We’ll get a mean and a variation and basically we’ve got the most popular ideas. The crowd has spoken.

But how good is that idea? It’s the mean, plain vanilla, right? So what happens when you’re looking for better ideas?

Usually we’re not looking for the best solutions in reality TV (we can learn a lot on system thinking from watching them, but that’s for another post). However, we’re always looking for better ideas, answers, solutions. In our professional life, we’re looking for the best possible ideas.

It seems the wisdom of crowds does not go along with real-life solution finding. Like Nolan says, it can help you to weigh a cow, but for more complex stuff, it’s not that helpful.

So where do good ideas come from?

They don’t come from the middle. They come from the outliers, where innovation starts. Outside the box. Good answers and ideas are the exception, not the norm.

The problem, of course, is that if you have outrageous ideas, you first need to try them, then need time to prove they were helpful (or not). So many of them are either killed before we can try them, and we don’t allow time for them to bloom.

Here’s my takeaway: For successful living, we need to experiment. To learn what works and what doesn’t. And experiment more with less-common-sense ideas. After all, for common ideas, we’ll get (maybe) common results.

For that we need a fail-safe environment. Some of the experiments fail, and we need to make sure it’s safe to fail. Or else, we won’t have new ideas, no innovation.

Just common sense.

Speaking at Agile Eastern Europe 2012

noreply@blogger.com (Gil Zilberfeld) — Thu, 27 Sep 2012 13:39:00 +0000

I was supposed to be there last year, but due to personal engagements had to cancel.

But I’m not missing this year’s AgileEE!

I’m going to talk about “10 phrases that can derail an agile project”, plus a lightning talk. I know, I know, there are other speakers as well. But come see me anyway.

And when you’re there, come say hi!

Unit Testing Spring Cleaning: On LIDNUG This Week

noreply@blogger.com (Gil Zilberfeld) — Mon, 10 Sep 2012 13:46:00 +0000

This week, Friday September 14th, I’ll be doing a LIDNUG talk about unit testing (gasp!). This one is not of the introductory kind (if you’re interested in one like that, check out the video and presentation page, or check out the Typemock site). This one is for people who are doing testing for a while, and now see a whole new set of problems. If the beginning was about where do I start, what tools should I use, and how do I get my team to begin, this one is about slow builds and dropping motivation.

This is a new presentation (at the time of this writing) and I’m looking forward to do it, and hopefully get some hard hitting questions.

You can register here. See you there!