IMistaken

What I’ll be doing at Agile Practitioners 2012

noreply@blogger.com (Lior Friedman:) — Mon, 23 Jan 2012 20:01:00 +0000

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

Agile Practitioner IL – Fourth Meeting

noreply@blogger.com (Lior Friedman:) — Mon, 07 Nov 2011 17:44:00 +0000

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

Agile Contracts

noreply@blogger.com (Lior Friedman:) — Thu, 27 Oct 2011 23:05:00 +0000

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?

Can you spot the Contradiction?

noreply@blogger.com (Lior Friedman:) — Wed, 26 Oct 2011 11:42:00 +0000

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

“I have a Legacy System” is a lame excuse

noreply@blogger.com (Lior Friedman:) — Mon, 24 Oct 2011 13:17:00 +0000

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.

Agile Practitioners IL– Fourth Meeting

noreply@blogger.com (Lior Friedman:) — Mon, 17 Oct 2011 14:57:00 +0000

Just 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

Your code should Always be working

noreply@blogger.com (Lior Friedman:) — Mon, 10 Oct 2011 11:41:00 +0000

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.

Agile Practitioners 2012 Update

noreply@blogger.com (Lior Friedman:) — Thu, 06 Oct 2011 06:40:00 +0000

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.

TDD for Legacy Systems

noreply@blogger.com (Lior Friedman:) — Mon, 03 Oct 2011 17:59:00 +0000

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.

Agile Practitioner IL - 3rd Meeting

noreply@blogger.com (Lior Friedman:) — Wed, 07 Sep 2011 19:54:00 +0000

Sunday evening we met for the 3rd time. This time Roy Osherove discussed 10 mistakes team leaders make an updated version of the slides can also be found here.
During the talk Roy mentioned several books, out of those I really recommend Johanna Rothman & Eshter Derby, Behind Closed Doors: Secrets of Great Management. For me that book was a career changer. I recall reading it as a team leader and for the first time I felt someone actually wrote a book that explained to me what a team leader job is all about. Also the book is filled with practical techniques that can be applied as is. from planning to conducting one on ones. Just the sort of advice I needed at that time.

Scrum Master vs. Team Leader

Towards the end of the session a discussion rose regarding the place of the scrum master and about the amount of authority he as over the team.
On one hand we all know that a scrum master is not the team leader. and it is considered a bad practice to make the team leader into one. However, it is also clear that the Scrum Master as defined by his roles and responsibilities, should lead the team helping them to become better at what they do. and in fact in most cases the natural candidates for becoming the scrum masters are the team leaders.
So where does the line from leader to manager is drawn?
Actually I don’t have a good answer for that. My gut feeling tells me that a “good” team leader, will fit the role of a scrum master very easily. Yes there are some traps and pitfalls that he should avoid, but if he is “good” that should not be a problem. However, many team leaders are not “good” and there is a real danger making them scrum masters. While as a team leaders they might manage to still function, as scrum masters they are not equipped to handle an agile transition which by itself is hard enough. In most cases they just ruin any attempt at any kind of an agile process. In my eyes the job of a scrum master is so much harder and it take a more experienced person with the “right” state of mind to do a good job. Leading a team is much harder then managing it.

The “Good” team leader

the million dollar question is of course how to sort the “good” team leaders from the rest?

Are they the team leaders which demonstrate the best productivity in their teams?
Are the the one most liked by their teams?
are they the ones most appreciated by their managers?
or is it something completely different?

don’t really know.
The only thing I did found along the way, is that there is a strong correlation between team leaders exert minimal authority over the team to those who becomes great scrum masters. So when I see a team leader which doesn’t “tell” his team what to do, and instead asked them many questions I know that there is a good candidate for becoming a Scrum Master.

Making your team manage their own work

noreply@blogger.com (Lior Friedman:) — Wed, 07 Sep 2011 06:16:00 +0000

I really think that team leader should stop being the ones which split the work into tasks and decide who does what.

I’ve written more about this subject and it was published here at the 5whys blog. (which is an excellent reading materials for team leaders)

Bug: $10, Future Bug: $200, Angry clients: $5,000, One TDD course: Priceless

noreply@blogger.com (Lior Friedman:) — Mon, 05 Sep 2011 10:11:00 +0000

When you write code for a living, mistakes can be expensive. They can create bugs that will crop up in the next version or the version after that, they can cause problems down the line for the end user who can't use the software and worst of all, they can create bugs that you spend longs days (and nights) working to find before the release.

One way of avoiding these mistakes is Test Driven Design - write the test before the code and the bug (if any) is easy to find. And a course in Test Driven Design is not that expensive - and even less so today :)

http://goo.gl/3VMqM

Introduction To TDD – Early Bird

noreply@blogger.com (Lior Friedman:) — Thu, 01 Sep 2011 08:17:00 +0000

Just wanted to remind that you can still get the early bird pricing for my upcoming training on September the 18th. People who will register by Tuesday the 6/9 will get a 50% discount for the course (making the cost only 600NIS per person).
Details about the course can be found here,
Registration details can be found HERE
If you have any other question feel free to contact me

The value of a 1 day introduction to TDD workshop

noreply@blogger.com (Lior Friedman:) — Fri, 19 Aug 2011 06:25:00 +0000

Next month I’ll be teaching a 1 day Introduction to TDD .NET workshop. And I was asked to explain what is the value of attending such a workshop. Clearly one can’t learn how to TDD in a single day, and indeed this is not the goal of the workshop.

So what is the value in a single day Introduction to TDD workshop?

I will let the reader judge for themselves. However here are the things I expect to cover during the day.

Go over the basic rules of the TDD practice
Explain and demonstrate what a testing framework is used for.
Introduce base Isolation principles.
Explain concrete ways for mastering the TDD skill.
Go over the humps of pain – i.e. the main obstacles for doing TDD
Let participant practice their firsts steps in a safe environment.

I expect people to come out from the workshop with the following:

Knowing the costs involved in TDD.
Understanding the benefits.
Know what needs to be done in order to actually learn it
Be aware of the main obstacles and pitfalls in the road for mastering TDD

So is all this worth a single day of your time?

if you think it is you can Register Here

Starting TDD – One Day Experiment

noreply@blogger.com (Lior Friedman:) — Sun, 14 Aug 2011 21:37:00 +0000

A repeating question I encounter a lot is how to start with practicing TDD. in fact a while back I wrote a series of post on how one can start this in various contexts

(part 1, part 2, part 3, part 4, part 5, part 6, conclusions)

some people claim that TDD is a group activity, therefore it’s a waste of effort to practice alone. I believe that TDD is a personal skill, and while its better to have the whole team doing it, it can be practiced alone. Nothing should prevent you from trying to improve the quality of your code. (and in most cases the added value will negate any delays you might experience initially).

in this post I’m offering another way to start. in fact I think that a controlled experiment might be a better way to describe this. but anyway

Practicing TDD for 1 Day

To start you should dedicate a full day for this. while I'm sure this exercise can divided into several sections, I think that to truly benefit from this (and avoid the cost of context switching) it should be done in a single day.

By the end of the day I expect you to achieve the following:

have a good understanding of what TDD is and what are the rules to follow
write some basic unit tests on a simple problem
write a test case for your own system
have a basic understanding of the tools involved in the process.

I also expect that you wont achieve the following:

fully appreciate the costs and benefits of doing TDD
understand how to apply TDD in all situation
Be able to write tests to all parts of your system
have a deep understanding of Isolation techniques

(or put simply at the end of the day you will know some of the basics, but that’s about it)

Setup

in order to complete the day you will need to download and install some tools. specifically you will need a Testing Framework and a mocking framework.

Testing framework

any framework will do, really its not that important at this stage.

.NET use MsTest or NUnit
Java – JUnit
c++ – GoogleTest

Mocking framework

pick one of the power tools available:

.NET use Typemock Isolator or JustMock
Java – PowerMock (you’ll need either EasyMock or Mockito in addition)
c++ – Isolator++

(some of the tools are commercial so you will need to use their trial edition which is good for a few weeks)

Learning phase

The first step is to get a basic understanding of the principles involved. for this I would recommend the following session by Uncle Bob

Attempting as it might be don’t skip this part. It takes about an hour, but the important basics are in this. In order to succeed one must know what are the rules of the game and what are the expectations. doing TDD is not just about writing tests, its about how to write code differently. And the goal is to try this different way, not just write tests.

Do a Code Kata

pick a kata from the following page, any kata will do but I would recommend going with one of the katas in the Beginner++ section.

your goal in this step is to practice TDD on the kata.

that is apply the basic rules of TDD while trying to tackle a relatively simple problem.

I would expect you to be able to go through the kata (mostly) in under an hour

Learn Isolation Principles

The next step is to get familiar with your mocking framework of choice. Most likely, the easiest way to do it would be to go the the relevant tool website and get through the “getting started” or the “Introduction” parts. The goal is to understand what are mocking framework, what they are used for, and specifically learn the API of the tools and be able to use it.

If you want to invest a little more time and learn some of the theory behind this, here’s a very nice session (hour and a half) by J.B. Rainsberger which I personally like very much.

you should end this part by doing the following:

Create a new project.
To this project add 2 classes one that you want to test (Class A) and one which is used by Class A (Class B)
Add a method that just throw an exception to class B and make Class A invoke that method somewhere.
Next write a unit test which test Class A, specifically the part should activate the code in A that invokes the prepared method on class B.
Use the mocking framework in order to make this unit test work/pass.

Yes this is a very simple exercise, but in order to finish it you will need to pass through all the basic steps for using the mocking framework tool.

Take a break for lunch

Tackling the real system

The last part of the day is dedicated to write some unit test on your real life system. What we want to achieve is to actually write some tests on the real system that you actually works on.

The first step is to pick a place in the system to start in. The trick here is to chose an good part that on one hand wouldn’t be the hardest most complex part, but on the other hand still would surface the real issue that will be encountered later on. The ideal place should be a place that is focused on logic. Try not to go for upper part containing any GUI sections, and also try to avoid the lowest parts dealing with the data base (if there is one). If possible try to pick a class that reside somewhere in the middle tiers. hopefully somewhere inside the business logic.

After you picked your part, locate the class you actually want to write test for. When you have it, the first step is to locate the dependencies of the class you will need to handle. Start by writing those down on a piece of paper, and then dedicate some time to figure out how they are going to be isolated. Usually what helps is answering the following questions:

How are the dependent instances (the one used by the class under test) get created
How are they get “connected” (injected)into the class under test
what is the expected behavior you need in your tests

answering these question will help you later on in setting up the fakes (mocks) in your test.

Write some tests

next just write a couple of things you would like to test. The key here to start simple. think of a specific behaviors you want to test. for each behavior, think what is the initial state the test should start at, what is the action you want to test, and what is the expected behavior (result) of that action (and how you clean up after the test). When you have all those just try to write the test.

And always remember to have patient.

The first test in a new system is always the hardest to write. Even an experienced TDD’er is likely to take a couple of hours to actually get some tests on a new system. For a beginner it might take longer.

Summarize the day

Last action of the day is to think and reflect on the experiment. if you followed the steps, then you should have some tests on your real system. Now it is time to reflect on those and see what else you can learn. Think on all the things you accomplished during the day. Chart down the things that you need to invest more time in. Recap the main difficulties you encountered, and most important decide upon a few key actions you would like to take in order to continue your learning.

And of course let me know how it went.

Agile Planning is just Enough

noreply@blogger.com (Lior Friedman:) — Sun, 07 Aug 2011 20:13:00 +0000

Actually Agile planning is based upon two main principles:

Just enough
Just in time

that is, at each stage we plan just enough to get us going and answer the important questions at that stage and than we stop.

In this post Gil talks about agile planning how it mainly focused on short term. Well Gil you missed some important staff about what you call Agile planning.

lets start by saying that talking about agile planning as a concrete thing is basically misleading, agile planning is just a set of very basic principles (which I tried summarizing above). One need to refer to concrete planning practices in order to udge them.Planning is scrum does not look like planning in Kanban which does not look like planning in XP…

The example used is taken from a medical field, in which the stake holders

“needed to know everything would be ready in time, three years in advance.”.

Well sorry there is no such magic in our field. NO one can know what will happen three years in advance.

when you claim to be able to do that you are simply lying, both to your sponsor and probably to yourself as well. You can estimate, you can guess or you can extrapolate based on prior knowledge.

you will never KNOW.

Even when you sign a contract with millions of dollars in fines for being late, you cant know. you are just doing an educated guessing taking all the buffers and safeties you need in order to hopefully meet you goals in the given time. And BTW in most case you don’t (just check out Chaos report if you don’t believe me)

Long Term Planning

Gil is right about one important thing, almost every project need a long term plan. Question is and always will be is just how long do we need our plan and how detailed do we need it to be.

In scrum for example, there are 3 levels of planning:

the daily planning (done in each daily meeting) – we plan in extreme details what will be done in the next day
the sprint planning – we plan in details which tasks will be done during a sprint ( a few week ahead)
the Release planning – we plan the list of stories which we will deliver in the next release (typically 3-6 months)

And here Scrum stops.

That doesn’t mean there are no longer term planning, just that the longer term is “out of scope” for the basic Scrum process. u will still need a product roadmap, you will still need a strategic planning. and maybe just maybe (like in the example Gil gave) you will need to give a list of expected features for the next “big” version. However this kind of planning will always be more vague, will deal in general capabilities we would like our product to have and at the end will always be open to interpretation. it would never be concrete enough to actually start working on.

The nice thing that at the end my recommendations and Gil are the same (well we do basically believe in the same things):

do a release plan (3-6 months ahead) make sure you are working on the highest priority features and make your best to develop them as fast as you can, and always keep your progress visible top your customer.

So lets do a reality check, planning is nice and important, but “responding to change over following a plan” is what makes agile processes works. The longer the time frame you are planning chances are higher that this change will be bigger and come sooner.

So how are design pattern working for you?

noreply@blogger.com (Lior Friedman:) — Wed, 20 Jul 2011 13:50:00 +0000

A confession. I never did manage to make design pattern work for me.

A disclaimer. I don’t think that this is because design patterns are in any way “wrong” or “bad”.

Yes, I do use them occasionally and Yes, I do know a fair share of them. However, I always have this nagging feeling that I should know more patterns, and at the end of the day, when I’m actually designing my systems I rarely go:

“ahmm I can use the XXXX pattern to do this”.

So why is this so? why after so many years of using design patterns talking about patterns and even arguing quite a lot about them, I still can’t make them work for me?

I wonder…

The human brain as a pattern matching machine

Start of July I attended at Vipul Kocher session during the SIGIST conference, in his session Vipul talked quite a lot about patterns and specifically about testing patterns. All and all it was a very interesting session, out of which I would like to repeat two main idea’s. First, Vipul initial claim was that our brain is basically a very sophisticated and efficient pattern matching machine. We use patterns on a daily basis. We see patterns everywhere, we recognize all kind of patterns we create new pattern, and often enough we even use Meta patterns (patterns which are used to create new patterns). No wonder our brain is such effective in matching patterns.

Learning to speak

Vipul’s second idea I would like to quote, is the fact that human apply this pattern matching ability in or language learning process.

And in the first time we are not even aware we are doing so.

When learning our native tongue, our brains learns patterns for matching single words, to match complete sentences, to match grammars rule and to match common mistakes. And it does so without us being conscious to the process.

The second time we learn a language the process is different, instead of absorbing the patterns instinctively, we apply a conscious learning technique.Instead of understanding specific word, we translate meaning from our native tongue, instead of deducting the grammar we LEARN grammars rules from books (or a teacher). This is also a way of learning. However in general the end result is inferior, usage of our native tongue will always remain easier and will always be of higher quality.

Misplaced Design Patterns

When talking about design patterns there are a couple of anti pattern I see in their usage. Again, I don’t claim there is something inherently wrong with patterns. I do see however problems with their usage. The most common issue I see, is a problem in applying patterns. Specifically, too often I see misplaced design patterns scattered around systems. Look at your current system you are developing. How many singletons do you see there? are all of them necessary? how many times you have argues with someone that while XXX is a great pattern, using it here seem to be out of place?

Initially I thought that this is caused by simple lack of pattern knowledge and understanding. However I think the reason is simpler than that. Our brain is always on the look for patterns, our thought process is rigged to order the world around us into known patterns and shapes. It does so instinctively all the time, and specifically during design it tricks us to see patterns which actually might not be there. It takes a really trained eye and conscious effort to compensate. Failure in doing so results in having a misplaced pattern in our system.

Design Pattern as a language

Haim describe in “Design Patterns and the Tower of Babel” one very important benefit of using patterns. Patterns serve as a common design language for us, and this is good.

However there is a catch. At least for me, the Design Pattern language is our second language. As a second language I will always find it harder to use. When using a secondary language (as in English ), I always struggle for the right words (patterns), I fail to understand the nuances behind them, I make stupid grammar mistakes and occasionally I use inappropriate words (if you don’t believe me read this article again). When I use Design pattern I feel the same, no matter how much effort I invested and will invest in learning patterns, I think that for me the cause is lost. I will not be able to use design pattern as my “native design tongue

So what should we do?

I see two options, the first is making sure that pattern does become the native tongue for new comers to our profession. On the upside design patterns has got a hold and I do see this more and more new comers learn them very early. However,I think that this process is going too slow. In order to actually see this done on a bigger scale, design pattern should be embedded into basic training and should be thought at universities (which I haven’t seen happening yet)

The second option is for people like me, those that will always have a different native “design tongue”. Like always, the first step is to admit that we have a problem. The problem is that the pattern language will always feel uncomfortable and be less effective for us. We still can and should use it, but when we do, we should be aware that we are “translating” and in the process our meaning can get twisted.

This is very frustrating. Especially when a “native pattern speaker“ meet a “second langue pattern speaker” like me. No matter how I try to avoid it, I end up reverting to my native language in order to “keep up” and when I do confusion start to hit (resulting occasionally in some heated arguments). Therefore the second step is to always keep in mind and be aware that this is happening.

When two “Foreign pattern speakers” meet

And last, and this is what I should always remember to verify, sometime on the other side there is another “pattern as a second language“ kind of guy. When this happen to be the case, we can sometime, just maybe, skip the whole pattern things. Chances are that it will be easier to communicate using our native design tongue.

So what are you?

a native design pattern speaker?
learnt design pattern as your second language?

Agile Practitioner IL– First Meeting

noreply@blogger.com (Lior Friedman:) — Thu, 07 Jul 2011 14:31:00 +0000

First group meeting went great. (Here is the group forming)

Thank you all for coming and participating

Elad Sofer

which seems to be enjoying himself here, just blogged about it and I couldn’t have said it any better than myself.

I will only talk about the second part of the meeting.

During this part, we tried to get a feeling on where the group would like to take this forum/meeting/activity.

W attempted to gather some ideas on the following:

What content would we like to discuss
How we would like o conduct these sessions
who would we like to hear talking.

and after some discussion and debate:

Here are our main “finding”

Topics of Interest

The four winning topics are:

Continuous Deployment
Agile for Executive (how to convince and how to include them in the process)
Agile in Enterprises
How to start the development of a new product using an agile method

the runner-up topics were:

choosing content for a sprint
Agile in none SW development projects (support, Maintenance, IT,…)
Scrum in details + real life experience
dealing with the Integration phase in an Agile process.

How to conduct these meetings

About the how, the consensus was that a session which is divided into two parts in which one is a lecture and one is an activity based was great.

another idea was as follows:

1/3 Presentation
1/3 collecting ideas for discussion and choosing which ones to discuss
1/3 Discussions in small groups on the above

Who would we like to hear

and last on the who front we got 2 local names Roy Osherove and Oren Ellenbogen (consider yourself invited), and two international speakers: Martin Fowler, Alistair Cockburn (I wonder if we can get on of them to visit)

and just before I forget, I would like to thanks everyone who helped make this group come into life.

Especially Elad and Ilan who partnered up with me, and really did most of the work to create this group. To Ohad Israeli and Nice for hosting the event giving us their excellent facilities to conduct this meeting. and Last to Typemock who sponsored the event and made sure we wont stay hungry

TDD .NET Course

noreply@blogger.com (Lior Friedman:) — Tue, 05 Jul 2011 08:08:00 +0000

Next month ~~(starting on August the 8th)~~ (Starting on August the 14th) I’ll be conducting a public “TDD .NET” course . Registration is now open for everyone, so go here and book your place.

The course TDD.NET is based on practical experience and lesson learnt gathered over the past several years. The course main goal is teach basic concepts of TDD practitioners while giving participants enough practical knowledge to start practicing on their own.

5 Reasons for Doing Scrum

noreply@blogger.com (Lior Friedman:) — Tue, 28 Jun 2011 06:19:00 +0000

A while back ago I gave a talk about what are the main benefits any organization should expect when changing its process into an agile (Scrum) process.

Here is the recording of that session. Its about 50 minutes long and its in Hebrew.

Hope you enjoy it

Open session With Jurgen Appelo

noreply@blogger.com (Lior Friedman:) — Mon, 13 Jun 2011 14:39:00 +0000

As a prequel to the first Agile Practitioners IL group meeting (register here). Jurgen Appleo has kindly offered to give a short, one hour, session during his visit next week. I know this is a very short notice but knowing Jurgen, I’m sure it be worth while.

The event is limited in space so for further details and registration go here. And don’t forget that we would still like to see you all at the first formal group kick off meeting.

Video of my talk at “QA & Development In Agile” conference

noreply@blogger.com (Lior Friedman:) — Mon, 06 Jun 2011 11:53:00 +0000

Last month I spoke at “QA & Development in Agile” gathering. SELA were kind enough to video my talk and to make it avail;able online.

Details about the talk (with the actual slides) can be found here.

and if you want to tune in and listen to the actual talk (about 30 minutes in Hebrew) you can do it here.

Also I would appreciate any feedback you can share. So feel free to add your comments.

New Agile User Group – First Meeting

noreply@blogger.com (Lior Friedman:) — Sun, 05 Jun 2011 15:04:00 +0000

I‘ve been wanting for quite some time now to setup a monthly meeting for people who are interested in Agile. Since the demise of “Agile Israel” meetings I haven’t seen any sersiou sattempt of setting such a group, although I feel that many in the industry are interested . Therefore I would like to invite you over to the first group meeting of the “Agile Practitioners IL” .

This session subject will be "Feedback". We will have Elad Sofer (which is also a co-founder of this group) talk about "Feedback - The secret ingredient of success", why feedback is so important for success and how it is used Since this is our first meeting we shall also try to gather feedback from participants on what else they would like to hear, and how they would like to see this monthly meeting evolve.

If you want to get involved, please RSVP at http://www.eventbrite.com/event/1774314021

Location:

Nice System

Hapnina 8, Raanana.

Time:

Gathering starts at 17:30

You can join the Agile Practitioner IL group at http://www.linkedin.com/groups/Scrum-Practitioner-Israel-81807?trk=myg_ugrp_ovr

Food and drinks are sponsored by Typemock LTD.

Flaw in SolutionContexts.GetEnumerator

noreply@blogger.com (Lior Friedman:) — Wed, 01 Jun 2011 06:56:00 +0000

I’m guessing that this post will be useful to a very small number of people if at all. However there might be a bigger lesson here for people writing their own collections and that is how not to code GetEnumerator method.

but first some background information.

when working with a visual studio add-in I needed find out weather a specific project is excluded from the build cycle.

the DTE provide interfaces and object to access this info and the code I ended up with looked like this:

        1: foreach (SolutionContext context in        2:    ApplicationObject.Solution.SolutionBuild.       3:        ActiveConfiguration.SolutionContexts)       4: {       5:     if (context.ProjectName.Contains(project.Name))       6:         return !context.ShouldBuild;       7: }

However, this code resulted in an exception popping from time to time which took me a little while to understand.

the exception I got was :

System.ArgumentException
The parameter is incorrect. (Exception from HRESULT: 0x80070057 (E_INVALIDARG))
System.Collections.IEnumerator GetEnumerator()
at EnvDTE.SolutionContexts.GetEnumerator()

where the line number pointed to the foreach statement.

After some digging I found that this happens if in the solution you have an unloaded project as part of the solution. and the fix was quite simple jut replace the foreach with a simple for resulting in something like:

       1: var contexts = ApplicationObject.Solution.       2:    SolutionBuild.ActiveConfiguration.       3:    SolutionContexts;       4:         5: for (int i = 0; i < contexts.Count; i++)       6: {       7:     try       8:     {       9:         var context = contexts.Item(i + 1);      10:         if (context.ProjectName.Contains(project.Name))      11:             return !context.ShouldBuild;      12:     }      13:     catch (ArgumentException)      14:     {      15:         //this is thrown when a project is unloaded      16:     }      17: }      18: return false;

Now I can understand why an unloaded project will throw an exception if you try to access its configuration data. What I don’t understand is why they didn’t handle this inside the GetEnumerator and instead choose to crash it as well.

I think this is a mistake, in general if a piece of the information is missing don’t fail the entire operation just exclude that piece from the result. that way you will enable the user to decide what to do with the info he does have.

what do you think?

Don’t you love useful error messages?

noreply@blogger.com (Lior Friedman:) — Thu, 26 May 2011 08:49:00 +0000

Ok now what?