What I’ll be doing at Agile Practitioners 2012

I’ve been quiet for some time now. mainly because I was very busy in making Agile Practitioners 2012 event happen. It was and still is a lot of work but most of it is fun and I do hope that all the people coming will enjoy it.
over the last couple of weeks I’ve been asked a couple of times what would be good session to go to. basically I don’t know all of the speakers are good and while I haven't heard all of them speaking those I did had excellent sessions. Its really hard to choose from them.
But out of all of them here's a list of those I’m planning to to attend.
of the three available workshops (Gojko, David and Corey) ill attend the Improving your TDD. ITs not often that I have the chance to hear about my main passion from leaders of the industry and this rare opportunity is too much for me to pass. (I do hope I’ll have the chance to peek in the two others though)
On the second day naturally ill hear the two main keynotes.
but other then that I think ill go with the following:
1) Agile Meets the Falafel-Land: Culture Clash or Common Cause?
While at the end I do believe people are people, the notion about us being a little different then the rest does appeal to me. and it would be great to hear how other people deal with things that are unique to our culture.
2) 10 Phrases That Can Derail an Agile Project
Being a close friend of Gil I had a couple of chances to hear him and I enjoyed it every time.Also I have a feeling that this session will have a few practical lessons for me to learn. Gil is really bringing some Product Owner wisdom and knowledge that I find very useful in my line of business.
3) Design For Testeblity is a Fraud
while I already heard this session before. I think it will be a little hard for me to skip this one.
4) Weaning a Legacy Platform From Offshore QA
I Find offshoring to be a very weird concept. one of those things that sounds like a very good idea until you actually try to do it. Too many times I’ve seen it fail. While I respect the fact that in some contexts that may be good idea. I still would like to be prepared to the day when someone asks me to help bring work back.
5) The Mythical Man-Month –
An Agile Perspective
Hearing about Brooks is always a good idea. Besides this is my first chance to hear Ohad, something I’ve been wanting to do for quite some time now.

So what session you are planning on going to? if you still haven’t decided that’s ok. But if you haven’t already registered Shame on you, quickly before anyone notice go here and register. There’s still enough time and a few places left

Read more »

Posted in: Conferences

Agile Practitioner IL – Fourth Meeting

I had much fun at yesterday meeting. I really liked the amount of questions and interest people showed. While they didn’t make my life easy, I really enjoyed the conversation and discussion.
for those who missed here are the slides

Agile in unfriendly territories

View more presentations from liorf

Hope to see you all again net month and of course at the Agile Practitioners 2012 conference

Read more »

Posted in: Agile Practitioners IL,Scrum

Agile Contracts

Agile contracts is an interesting thing. one of the main push back against going agile I get in places is that while agile is nice and all there is no way we can convince our customer to work like this. “they want a fixed price fixed scope deal”. In any case this post is not going to talk about why Agile contracts are a good idea, or how to get buy-in from your clients to sign an agile contracts. This post is going to talk about:

The forces against an agile contract

The power of Inertia

People don’t change easily. The fact that our industry has been using a “Fixed …” contract for several decades now goes against trying anything else. Especially if that something else is substantially different. An agile Contract is exactly that. Different.

Risk

An agile contract puts the risk on the paying side (the customer), he is going to pay for the work done, even if that work is of lesser value. Naturally if its value is low enough  he can bail out. But still the risk is on him. While a “Fixed …” puts the risk on the development team. they need to fulfill their part before they get paid.

Trust

our industry has not been that great at delivering working software. (to say the least). Most software projects either fails completely or significantly does not meets expectation (either they miss the timeline, exceeds the budget or reduce scope)Potential Profit. An agile contract actually says exactly that. By going for a flexible scope (or time) we actually say we don’t know exactly what will happen, we don’t know what we can deliver (or when). That’s a hard message to tell the one who is paying.

Potential Profit

This one is a little elusive. One of thing we do as a development team when we go for a “fixed …” is add buffers to mitigate our risks. At one place I used to work I saw a two days chunk of actual work being priced as 11 weeks for the client. And he was willing to pay (there is a cost for putting the risk on the developers). For us as a development team this represent a significant potential profit. If we could just estimate accurately and actually finish the work in the time we say we can. The buffers just become easy money. No matter how many times we under estimate work, every time when we do a new estimate we are always sure that this time it will be different. This time we have considered everything. After all we are smart people.

As you can see there are strong forces affecting both side to resist going for an agile contract. Can you think of more?

Read more »

Posted in: Agile practices

Can you spot the Contradiction?

Here’s a job description I got over the mail (the original message was in Hebrew so I’ve translated):

Subject : Project manager – Control of Agile software

A project manage with control of Agile software is need for an international development company dealing in Wireless Electronics

• Must – BSC in engineering
• 1-2 years of experience in project management or in project scheduling and task tracking as part of the project team
• Experience in Configuration management – significant advantage.
• Experience in production processes, moving from research to production – an advantage
• Must have knowledge in Excel, Ms-project, Agile software
• Great interpersonal skills, teamwork, ability to work under pressure
• Fast learner of systems and processes, ability to dive into details
• Excellent English
• Willingness to travel

Can you see what’s wrong here?

(i.e. why does a real agile person will not get close to this job?)

Read more »

“I have a Legacy System” is a lame excuse

Q: “why have you not written any automated unit test until now?”
A: “ look, we have a and complex big system. no one has written automated tests for it. it will take me too long to do it just now. I know its important but we have XXXXXXX so we cant do it now”
This kind of excuse, which sadly I hear way too often,  rate high among the “list of most lamest excuses”.
Don’t believe me?
How about this?
Q: “when are you going to cut down on your expanses and start saving money?”
A: “Look, I’ve already have a big mortgage on my house, and the cost of living has risen lately. So now is definitely not a good time to start saving. In fact since I just need to replace my car with a new one I’m just on my way to the bank to get an additional loan.”
or maybe this?
Q: “you know that you were diagnosed with high cholesterol, when are you going to start a healthy diet?”
A: ”you know you are right. But we are just entering the holiday season so now is not a very good time to start. In fact I cant wait for the family dinners, Health is not high on my family priorities, I’m guessing that’s why its so good”.
and this?
Q: “why aren’t you using a source control system?”
A: “well we have this big batch of code and its kind of a big mess. We thought about starting to use a source control, but it will take us too long to port our code into such a tool, and train all the developers. And you know we need to do XXXXXXX, so now is not really a good time”
Its Never too early to start
I think you got the point.
It all boils down to accumulating debt, technical debt in case of software development. That is,  you know you need to do something now. ASAP! But since  the effort involved seems to be high, you delay. You decide to take on additional debt, and with it comes additional interest. Causing you to do more rework and have less time and the monster feeds itself.
Face it, like most necessities in life there will never be the perfect time to do it. Test automation on all levels (unit,integration acceptance E2E,…) is not an option.  More and more teams realize that and do something about it. To stay competitive you will have to do it also, later will only make it harder. 
The fact that your system is big and complex is the real problem, Test Automation is one proven way to tackle that problem.

Read more »

Posted in: AUT,Development Practices,TDD