Agile Practitioners IL– Group meeting #11

On Monday we met again at Kontera offices to hear Guy Nachimson talk about “How to help others take more responsibility”.
In the talk guy explained about a Christopher Avery's Responsibility process. this model deals with how people react and behave when they encounter a problem they need to solve. The model deal with various states that describes how a person reacts:

1. Denial – First reaction is to ignore the problem. it didn’t really happen.
2. Blame – when we cant ignore the problem we look for someone else to blame. “it wasn’t me it was XXX”
3. Justify – when we finish blaming, we then start to look for justification on why this happens. (the situation forced us to do this, things just didn’t let us do something different,…)
4. Shame – after we finish to justify our actions, we understand that it something we did and then we are a shamed that we did this and that
5. Obligation – here we understand that something needs to be done, however we don’t do what we want to do but something we feel we must do.
6. Responsibility – this is the state we want to be. here we take ownership of the problem and use our ability to deal with it and make things better
7. QUIT – sometimes, before we assume responsibility  we choose to give up and just let go.

According to Christopher, this model is quite universal and there is no way skipping this stages, the trick is to recognize where you are and try as much as possible to pass through these stages as fast as possible in order to reach “Responsibility”.

What did occur to me while hearing Guy describe the model, is that this model is not only applicable to individual, but can also describe organization culture. Personally, going over some of the companies I encountered, this model can be used to better describe how the organization as a whole is behaving. The easiest one to spot of course is the Blaming culture.

We finished off the session by doing a nice exercise in which guy used a friendly competition to show how one can better spot where a person might be located in this model by listening to what people are saying. things like:

• “but our group is only 3 people so we need more time” – justification,
• “We should have done XXX” – shame.
• “But we must do YYY” – obligation

All and all a very interesting session, I cant wait for December 17th to hear Christopher Avery himself going in depth into the subject. Two hours is not long enough to really cover this subject

Read more »

Posted in: Agile Management,Agile Practitioners IL,Events

Want to be a speaker at the upcoming Agile Practitioners Conference in Israel?

I’m so pleased to tell you that we will be running the second Agile Practitioners conference at the end of January 2013. If you want to help us make this conference just as great, please help us gather the best content out there. Specifically, if you have a new idea, thought or experience to share   drop at :
http://agilepractitioners2013.com/call-for-papers/
and propose a session for the upcoming event.

If you have any related question feel free to contact me directly – either by posting a question here or at my email: lior at practical-agile dot com.

Read more »

Posted in: Agile Practitioners IL,Events

Why should you become Agile

One word:

I believe that a developer work should be one filled with the joy of creation. When I started out to become a programmer I thought that it would be great. my work will be filled with:

• Joy of creation when working on building a solution to other people problems

• moments of joy when completing new things and releasing them to the market

• moments of satisfaction from work well done

• moments of eureka when I find great solution to difficult problems

• moments of collaboration when I work with my team members to achieve a shared goal

a few years later I found out that:

• its not fun when you finally get your product to the market realizing you just solved the wrong problem

• Its annoying that whatever you are doing always seems to take longer then expected

• its frustrating when you never have enough time to actually complete your work as it should be done

• its not easy to work along other people which are stressed out just like you.

• its disappointing that you never get a chance to learn something new because now is not the right time and we first need to finish.

• its depressing to continuously get a stream of defects on the code you write

• its terrible to work 3 days straight to understand why the system keeps on crashing at your client, when it behaves perfectly ok in your own environment

• its frightening to work on unknown parts of the system not knowing if what you will do will only cause more bugs

So why should you become Agile?

Because being agile is one major step towards bringing the joy back to work:

If you really become Agile, you will gain back the control over what you do and how you do it.

If you really become Agile, you might get the chance to truly collaborate with you’re the rest of your team

If you really become Agile, you will work according to market feedback and needs on the important things first

and if you really become Agile, you just might bring some of the joy back to your work.

Read more »

Posted in: Agile Values

Why should you Learn TDD

One word:

I believe that a developer work should be one filled with the joy of creation. When I started out to become a programmer I thought that it would be great. my work will be filled with:

• Joy of creation when working on building a solution to other people problems
• moments of joy when completing new things and releasing them to the market
• moments of satisfaction from work well done
• moments of eureka when I find great solution to difficult problems
• moments of collaboration when I work with my team members to achieve a shared goal

a few years later I found out that:

• its not fun when you finally get your product to the market realizing you just solved the wrong problem
• Its annoying that whatever you are doing always seems to take longer then expected
• its frustrating when you never have enough time to actually complete your work as it should be done
• its not easy to work along other people which are stressed out just like you.
• its disappointing that you never get a chance to learn something new because now is not the right time and we first need to finish.
• its depressing to continuously get a stream of defects on the code you write
• its terrible to work 3 days straight to understand why the system keeps on crashing at your client, when it behaves perfectly ok in your own environment
• its frightening to work on unknown parts of the system not knowing if what you will do will only cause more bugs

So why should you learn TDD?

Because TDD is one major step towards bringing the joy back to work:

If you do TDD right, many of the stupid defects will go away.

if you do TDD right, your system design will improve making it easier and faster to change

if you do TDD right, you will have a safety net guarding you from mistakes.

and if you do TDD right, you may be able to bring some of the joy back to your work.

Read more »

Posted in: Engineering Practices,TDD

Instoolation

Instoolation (n): belief that process problems can be solved by installing a tool. Gojko Adzic, BDD: busting the Myths.

I see that mistake more and more everywhere I go. During last Iltam meeting Elad gave a talk about tools for agile project management and the general spirit of the audience was, we have all sorts of thing we need to solve and we expect a good tool to help us solve those. things like dependency tracking, risk management, predictability, traceability, and more.

there is no tool that will solve any of those problems, you first need to install a good process that address those problems and later on you might be able to use a tool to help you to reduce the effort you invest in the solution.

but actually I didn’t want to write much about that, I do want to discuss about what happens when you add another deadly ingredient in the mix:

Not Invented Here (NIH) – Syndrome

From Wikipedia:

Not invented here (NIH) is a term used to describe persistent social, corporate, or institutional culture that avoids using or buying already existing products, research, standards, or knowledge because of their external origins.

So what do you get when you cross an Instoolation disease with the NIH syndrome?

Right. A huge chunk of money that goes down the drain to develop an in house tool that aimed to solve a problem that can’t be solved by a tool.

Just to give an anecdotal example, in one of my past work places, I experienced a 5M$ budget goes into customizing an existing ALM tool which was then assimilated into the company over a period of about 2 years and with extreme pains. The fun part was once the project was “successfully” completed,the involved team was immediately taken to do a proof of concept on replacement tools since the developed system was considered wasteful.

It just pains me to see companies going that road.

Want to adopt Agile and don’t know where to start?
click here to learn

Read more »

Posted in: stories,tools