Thursday 27 October 2011

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?

Wednesday 26 October 2011

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?)

Monday 24 October 2011

“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.

Monday 17 October 2011

Agile Practitioners IL– Fourth Meeting

Agile Practitioners IL - 4th MeetingJust wanted to let you know that the Agile Practitioner group will be meeting for the fourth time on November the 6th. This time I’ll be giving the first part of the session and I’ll be talking about how agile can be adopted by a small part (maybe a single team) inside a bigger organization that might be using other more traditional processes.
Like always entrance is free but registration is required. So please register here (SAP our hosts did ask that you will remember to bring your event ticket to the meeting)
You all are invited to attend and I also ask you to help us attract more people to the meeting. Please invite your friends, colleagues or anyone else you feel might be interested in coming. We really like to  grow up our relatively small community.
And last come if you haven’t already and join us at linkedin:  http://www.linkedin.com/groups?gid=81807&trk=hb_side_g

Monday 10 October 2011

Your code should Always be working

Source control branches is always a good topic to argue about. if you read any of my previous topic (or just know me a little) you are aware that personably I think those to be a complete waste of time and effort. My personal experience (which is validated against places I consult in) is that most usages of branches are covering some inherent process problems that best be solved instead of hidden. but that’s not what I want to  talk about.
what I do want to discuss is one of the main argument people raise for justifying their need to use source branches. and usually it goes like this:
yes we would love to work on one main trunk, we see the great value in that. However, not all programmer knows how to work their code without breaking the rest of the system. therefore we use branches to prevent the system from breaking during development of new features. and we integrate their work based on needs and stability.
Frankly I can relate to this. I can understand what is missing here. We need some good strategies for working on code without hurting system stability. so here are some options for you.
Invisible Coding
The first and most trivial technique is using build it (in the programming language) mechanism for disabling code. Yes something like the infamous #ifdef directive for C/C++ that exists in most (all) modren software languages. The main idea here is that all new additions to the code are marked as disabled until they are ready be activated and integrated into the main system.
For most this would seem as an ugly patching/hacking and most programmers has a a natural dislike of such an option. and probably with a good reason. After all if the code is not active what is the big difference than just using a separate branch? well not much, the only real benefit in this is that at least one side of the integration is always done. when you are working on a new feature and still work on the main trunk, even if your new code is disabled, it is always updated with other changes being done to the system. And since in most cases enabling/disabling the new parts is quote easy. With just a little care you can do parts of the second side of the integration in an ongoing fashion making the final integration easier, safer and faster.
Decoupling of New Code
The second strategy takes the “invisible code” approach one step further. the main idea here is to write the new code into the main system, but this code will be decoupled from the main code in such a way that it will be easy to prevent actual usage of the new code until it is ready. Its like building a new part beside the main system and only connecting it when it is good and ready. technically speaking it’s a little harder to achieve and sometime require a little bit of juggling and some getting used to thinking this way. On the upside this make sure that all new code is integrated into the system in such a way that only the final steps of the integration (making sure everything works) is left for the end. the back and forth tedious merging is done along the way. Also, from my experience most developers find this approach natural and tend to work like this anyway when adding new stuff. However, the down side, is that in many cases the harder part is to actually to the connecting of the new parts into the existing system. sometime you find that you missed some staff that invalidate part/most/all you work done in isolation. I usually advice people trying to go this way to start by first  solving the connecting part. that is start by making the system integrate into a “dummy” new part making all the calls do nothing. and when that’s ready go over and fill in the missing parts.
Work Small
This is kind of a process work around. it has nothing to do with how to write code. The main idea is to always work on small features. so small that in fact they can be started and finished in a couple of days  making the use of a branch just a big overhead with no actual need. If you can start and finish in a matter of days, you can just work on your local copy focusing the actual code changes in a very short, delivering everything at the end. Actually this is just like branching but since it is for such a short period of time integration will not be an issue and most likely merging will not be required.
actually this strategy has all sorts of benefit outside the technical domain so it is a recommended idea no matter what else you do, and if/when needed it can also be combined with other strategies
Test Automation
Well this is probably the one thing that will make your code work at all time. if you have a good suite of automated tests that does a decent job at covering your system, the rest just falls into place. You just work on the main trunk and make sure that everything continue to function by running the tests after each change and before delivering. If you broke anything the tests will let you know, and you can just find another way of doing this. Of course having such a suite is something that sadly most people are short on. and those that do have are usually already solved this problem a long time ago. but lets face it you do need test automation no matter how you work.
The Mikado Method (The Missing Link)
That’s one is new for me, while I have encountered this over a year ago, only recently I managed to actually dive deep and read the book (an excellent one BTW, which can be downloaded here (for now)).
and for me that was the missing piece in the puzzle, the main idea of the Mikado method is turning the problem upside down. you start by stating you goal, you find out what are the prerequisites for achieving you goal, you apply them to your system, see what breaks, find what’s need to be done to complete the prerequisites, writ it down in a graph and then revert your system back. then we repeat the process for each derived prerequisite and continue to so until we find actual things that can be done without breaking the system. This is a very short and probably not so good description of the Mikado process. but the book does a great job at that so just go ahead and read the first two chapters to get you going.
The great thing about this method is that it uses the power of a source control system, in way that allow a programmer to chart his way until he maps all/most of the things to do in order to reach the Goal, and only then actual work on the code is started. This allow one to start working in small steps from the end to the start while keeping the system intact all the way. at the end this is just taking the “Work Small”  strategy and applying it to the “technical” side, resulting in breaking down the work into small technical steps that can be safely taken. and the best part is that this is an actual technical technique that can be practiced and mastered.

This are the strategy I have used and will use and for me those things work. I’m sure most of the things stated here works well in combined together and the trick is to use the right tool for the task. would love to hear about more techniques for handling the same situation.

Wednesday 5 October 2011

Agile Practitioners 2012 Update

image
I think this is my first post on the conference, so lets start from the beginning.
On January the 31st. We will be having a big agile day conference locally in Israel. We have been working in the last few months to make everything happen, from bringing in international speakers, looking for great content locally to arranging for a place to host the event.
we also brought up a website for the conference: http://agilepractitioners2012.com/. go there to get more details about what the conference is about.
I would like to let you know (and remind those who do know) that the call for paper is still open and we are still looking for great sessions given by great people to have in the day.
if you have anything worth sharing please come and suggest a session: http://agilepractitioners2012.com/call-for-papers/
the call for paper is open until October the 16th, don’t miss it.

Monday 3 October 2011

TDD for Legacy Systems

We know test automation is crucial probably even mandatory, and TDD is a great practice to use, but lets face it our existing system is not test friendly to say the least.
so now what?
TDD for Legacy system is  my way to help people tackle this problem. During this two day training we will learn how to cope with existing systems. We will go over the basics of Test First methodologies and learn how to turn a system from a big  chunk of legacy code, into something that is covered by a suite of automated tests. we will discuss issues of setting up a continuous integration server, different type of testing that can be applied, how to tackle existing system design and how to slowly but surely improve our code base while writing automated tests for the existing code.
the training will assume no previous knowledge of test automation, however it is  hands on and does require previous experience in programming (at least one year on a real live system).
if you are interested and want to learn more details about the course syllabus and content can be found here
and of course you can just register here
so don’t wait up, take you r first step and come learn about modern software development.

 
Design by Free WordPress Themes | Bloggerized by Lasantha - Premium Blogger Themes | Walgreens Printable Coupons