Posted in: Agile practices
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
Can you see what’s wrong here?
(i.e. why does a real agile person will not get close to this job?)
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.
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.
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 :)
Posted in: Course
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.
I will let the reader judge for themselves. However here are the things I expect to cover during the day.
I expect people to come out from the workshop with the following:
So is all this worth a single day of your time?
if you think it is you can Register Here
Actually Agile planning is based upon two main principles:
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)
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:
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.
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…
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.
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.
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.
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
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.
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?
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:
and after some discussion and debate:
Here are our main “finding”
The four winning topics are:
the runner-up topics were:
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:
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
Posted in: Agile Practitioners IL
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.
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
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.
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.
I‘ve been wanting for quite some time now to setup a monthly meeting for people 
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
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.
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
11/07/2011
2: ApplicationObject.Solution.SolutionBuild. 3: ActiveConfiguration.SolutionContexts) 4: { 5: if (context.ProjectName.Contains(project.Name))
6: return !context.ShouldBuild;
7: }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;
what do you think?
Posted in: IDE
A couple of months ago Microsoft released a tool enabling to gather code metrics on code form command line. (detailed post here).
While it took me some time I’ve updated my Msbuild custom tasks project and added an Msbuild task for better integration of the tool into a build cycle.
The task enable the exporting of metrics for a given solution and includes an xsl to transform the resulting xml into an html report.
(older tasks in the project allowed running all tests (using mstest) in a given solution and exporting VS coverage report to an xml)
To download the latest release go to here, and if you have any questions or additional requests contact me either through the CodePlex forums or directly.
Towards the end of June I’ll be participating in Sela’s “Dev. Days” conference. Unlike other conference, “Dev Days” event is a collection of 1 full days workshops that will be given over the span of an entire week. During this week there will be 25 different workshops in various subject aiming at beginners and advanced Developers alike.
My part in this event will be 2 workshop that I’ll be having:
At this workshop ill be going over the principles of agile. I will show the basic Scrum process and technique and will demonstrate the key differences between Agile way of doing things and classical waterfall approaches.
If you are want to know what the agile buzz is all about I really recommend attending this day.
2. Introduction to Test-Driven Development
TDD has established itself as one of the leading practices in the Agile community. However there are several obstacles in actually starting to TDD. The goal of this day is to give all participant a good starting point for actually starting to code in the TDD style.
If you ever wanted to give TDD a go, but always found it hard to start. Maybe this day will get you going
2 other related workshop that might be of interest in the context of agile and testing are:
Team Foundation Server 2010 and Visual Studio 2010 and Visual Studio 2010 Testing Tools. but of course the week has many more very interesting workshops. for the full agenda go here and if you want to register follow this link.
Posted in: Conferences
This is the presentation I gave last week over at the “QA and Development in Agile” conference (including some extra slides the I didn’t have the time to go over). Unlike other presentation this one was solely process related and not about any tool so I hope everyone enjoyed it.
The main pint o the talk was that its more important to optimize the team feature throughput than the team utilization and I hope I managed to get it across.
Would you like hear me present? Contact me!
and in any case would love to get your feedback on the experience.
One of the major roadblocks in an agile transition is the fact that
sure, some organizations are succeeding in doing agile under such contracts but one of the promises of Scrum is to be able to easily cope with changing requirements, and change the work plan to contain the most valuable features seen at that time.
On the other side, after so many years working under fixed price,fixed content contract its really hard to change especially since much of the time the other side (the one paying) is not really involved in the decision to adopt agile.
a couple of weeks ago I had the chance to talk Giora Morein during a conference, after a while we started talking pricing schemes at which point Giora pointed out that when working under a fixed price contract, the risk involved is mostly placed on the side providing the services, while when using an hourly/daily rate most of the risk is taken by the paying side.
I believe that this fact is part of the problem we face when trying to adopt to an agile contract. The problem is how to convince a customer that is used to having the risk placed at the supplier to accept the risks involved in committing to a project under a flexible budget and content.
The first thing I found useful when I try to switch to a flexible more agile contract, is to start by acknowledging this fact. I than counter to with the benefits of such a move, focusing on the benefits the client will see.
In many cases this is not enough and the customer will still choose to use the same fixed price, fixed content agreement and in this situation I found the following steps to be very useful to establish a level of trust needed to actually change the working contract.
In order to actually change anything the first order of business is to sort all requested features by order of importance. In most cases this is grasped by the client as a reasonable request and it opens several channels of communication whiled doing so. its very important that the client will be involved in this as much as we can since this phase build the basic understanding both parties can build upon later on.
Second I try to add the following key points to the contract
(since all this points are actually controlled by the client most have no real objection to include them in the agreement):
1) Scope can be changed - The client can swap any requirement/feature by a new one of similar size, as long as it conforms to the basic priority scheme.
2) Priorities can change - by the client at any point of time. These changes will be reflected to the work plan (excluding things which are currently under way).
3) The client can take a working version of the work so far. In fact he is encouraged to do so and provide any feedback he can n it.
4) Termination - at any point of time (subject to a reasonable fee – I use 25-30% of the remaining cost) the client can terminate the project taking all the work done so far.
I have tried this scheme on a couple of occasions and found that after a few times the client actually invoke any of this clauses. He usually see the benefits involved in such an agreement and the next time he actually insist on this ability and is much more open to a working under an “agile contract”.
Posts
