One of the most common discussion that always seem to pop up again an again, is whether Scrum /Agile is good or bad. I don’t know why but in most cases it’s starts with a claim that Scrum is not  good since it … and then state a reason. (or with the claim that Agile is dead),for example

Scrum is not a good process cause its not complete, it doesn’t define everything you need in order to succeed.

or

Scrum is not a good process. Team members are equal, each has his own set of skills and ability and treating them as equals will not work.

And although in many cases those argument make some sort of logic, what most of them are missing is that scrum is NOT a process. Scrum is a framework.
Don’t get me wrong, I don’t believe in silver bullets, I don’t think that there is one solution (process) that fits them all. Each project context is different. The people involved are different, the technology varies, the business domain changes. While there are common patterns of issues and behaviors that we can look for, at the end each project is a unique, and therefore will need a different way of doing things in order to succeeds. That’s what I love about Scrum (and Kanban and XP), they are flexible enough to handle most of the diversity you can find.

Scrum as a Framework

Scrum is just a tool. But a tool for what?
Many people consider scrum as a process for software development. That is, Scrum is a tool used in project management that will help you t create a product at th end. but that’s not exactly right.
Scrum is actually a tool for creating other tools, more specifically Scrum is the tool which you use to create a your development process. The process that you end up with after you “applied” the Scrum tool, is the “tool” you use to build your product.
Confusing? Yes? lets try again.
Normally this means, that in the process of using Scrum you take the company, the people/team, the technology and the product. those are things you feed into the Scrum Machine (along with many other things) and at the end after some time you get one new development process. that process is what you use in order to manage you project.

Scrum is not a Process

so what’s the actual difference? why the fact that scrum is a framework important?
When I see teams taking Scrum as a process, what many of them fails to realize that that there a lot of hard work involved. They start with using Scrum and expect that all of there problems will go away. They read the book follow everything that is written there to the best of there ability and they expect that everything will be fine. What then happens is that Scrum does what it was meant to do, it starts by surfacing all the underlying dysfunctions that have been will hidden there. That’s what Scrum does best.
In order for a team to create a good working process, it must resolve its dysfunctions. The Scrum framework was designed with the sole purpose of exposing them in order for the team to face them and find a working solution.
In fact, this is exactly the stage in which many Scrum adoptions fails. Its seem to be really hard, When a team starts using Scrum all kind of problems starts. So clearly if Scrum is causing all these problems it might not be such a good idea.
In some case the team will try to stick a little longer with the Scrum book. that usually doesn’t help. in other cases the Team will revert back to old habits that seem to have worked in the past. that doesn’t work as well. they either ends up in their old process (and then the claim that Scrum has failed) or they end end up somewhere else that technically looks likes a scrum based process, but in essence is not (a mini waterfall is one example)
Scrum book has no solution for dealing with bad coding, it state nothing about how to create a good flexible architecture. it doesn’t give you an idea how to handle two team members that simply cant work together,….

Knowing your tool

There’s a reason why most scrum implementation fails. Like any tool, one need to learn and practice using it. No one expects that his holes will be perfect the first time he picks up a power drill. right?
Managing a software project is a little bit more complex then that, and still people read the scrum book which seems to be simple enough and expects everything to work. It doesn’t, Especially if you confuse your tools. Especially if you think that Scrum has all the answers, Especially if you think that since defines three roles those are the only roles that you ever need on a project. Especially if you think that the 4 ceremonies are all the meetings you will ever need. Especially if you think that a daily meeting is just a daily status report, Especially if you think that you can continue writing the software like you ever did and still deliver something every two or three weeks, and I can continue for ever like this.
Especially if you fail to realize that when using Scrum you will need to work hard in order to create a working process for your team.
so one more time

SCRUM IS NOT A PROCESS

Are you also

• Feeling you can do a lot better?
• Thinking there’s much more to Scrum and Agile?
• Having a hard time Finding your place with the team?
• Doing things you are not sure you fully understand?

Then come join our Product owner workshop on April the 30th.

Read more »

Posted in: Random Thoughts,Scrum

So what is the Product Backlog?

Trying to define what is a product backlog is always a tricky business. One definition I use from time to time is:

The product backlog is just another way of describing the system requirements and serves to describe the work needed to be done

Which is a good way to simplify it to death. I had reasonable success using this definition with agile beginners, but clearly it doesn’t start to capture its entire meaning.
The more official definition taken from the Scrum guide at Scrum.org is:

The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product.

Which is more complete, but still raises quite a few questions. for example:

• What is everything? (new features? bugs? technical enhancements?…)
• If it’s a single source does it contains all the details? (i.e. the requirement docs)
• what is actually written inside it (how do we write those requirements? use cases? stories? plain English?)
• Is it a business facing document (i.e. read by clients and user) or is it a technical document (i.e. serves the team who needs to understand what to build)

So what is the Product Backlog

when trying to answer this I go back to my first initial encounter with  agile. At that time what I actually read and first saw was the work done by Ron Jefferies and Kent beck on eXtreme Programming. and what I still recall today is the simple statement in which Kent Beck explained that the whole purpose of agile is to bring all involved parties to one table and make them work together in order to create great products. (unfortunately I cant seem to locate the exact quote). At that time I didn’t know what a Backlog was and I was just starting to understand all the various agile techniques. but that statement just stuck and for me it’s the best way to describe what is the main goal of the Product backlog.
Forget about stories, requirements prioritization, acceptance criteria and all other technicalities which are associated with the product backlog.
In essence, when done right, the product backlog is the one “thing” that makes all involved parties converge communicate and cooperate in order to make the product a success.

The interface between the problem space and the solution space

To take it down into more specific terms what I think that the product backlog main role in the project is to serve as an interface between the business facing aspect of the product AKA the Problem space and the technical sides AKA the Solution space. On one side the Problem space is using the backlog in order to help it define the problem and describe on his terms WHAT its need to be done in order to help with the problem and on the other hand the Solution space uses the backlog in order to sort out the actual work. the team need the backlog in order to understand what is actually expected from him, what exactly he should build, what needs to be developed first. and most important use it to create a shared language he can use to talk to the business people and create a shared understanding.
And I’m guessing that this dual nature of the product backlog is what sometimes causes all these misunderstandings we see. here are some examples:

1. Every team occasionally needs to do things which are very technical in nature and involves a significant amount of effort. Being the single source of incoming work its not unreasonable that they will want to add it to the product backlog. However, these kind of things tends to be less understood by the business side, and suddenly there’s a conflict: “why do you add theses things that has no value to me?” asks the PO. “you know what, if you need it lets keep it there but please reduce the priority of it” which practically means ok I will let you put it there, but lets make sure that you actually wont work on it.
2. Being the single source of work, a reasonable team working in short iterations will expect backlog items to be of a certain size (typically a few days worth of effort). However, splitting requirements in a sensible manner is really hard work. The “Problem space” natural tendency is keeping the items size much bigger. I’m guessing it makes things easier to manage on their side (and of course avoid the extra work of splitting those into small chunks) and again we have a conflict
3. Not only that the Solution Space demands the things to be small, it also needs them to be FULLY prioritized. Even more hard work for the “Problem” side.

Now don’t get me wrong, there is no right and wrong here. All sides in all these situations are “right”. IF you look at it from there side. 

Treating the Product backlog as an interface

The moment all sides respect the fact that the product backlog is not only there to serve their needs alone, things tends to become much easier. When Technical people understands that the product backlog is the place in which business side describes the “Problem” and respect that. They find it much easier to keep it in a way which is understandable by the business side (avoiding the regular technical language they tend to use internally). When the business side respect the fact that the backlog is used to manage the actual work done. they find it reasonable to invest the effort needed in splitting, prioritization and other activities needed.
So don’t forget the Product Backlog is an interface. it’s the one thing that can be used to establish effective and productive communication by all sides of the business. Take advantage of it.


if you are also

• Having a hard time splitting user stories to shippable items?
• Struggling with predicting when will we reach the deadline?
• Having a hard time with prioritization of requirements?
• Does it seem that the team never understands what you mean?

Then come join our Product owner workshop.

Read more »

Posted in: Agile practices,Scrum

About Myths

To every Myth there is always an equal destructive (Stupid) and opposite counter Myth:

Here are some Examples

Myth

You do not need to design up front

Counter Myth

Design is a one time effort which is best done before you start

Reality
You need to design some of your system up front and some of your system as you go. How much you need atg each stage depends upon your understanding of the problem, you technical skills & your system.


Myth

All user stories may be implemented independently from each other

Counter Myth

We must analyze all the dependencies between all features in order to lay out our critical path

Reality
There will always be some dependencies between different user stories, however a lot of those can be eliminated with some effort invested during story slicing. Those which are left are usually obvious enough for a reasonable team to deal with.


Myth

you don't need architects.

Counter Myth

A strong enough architect can design the system in such a way that anyone could implement it.

or

The architect doesn’t need to code

Reality
Every team needs to have strong design skills, when the projects becomes big enough a dedicated person (aka the architect) to help with the communication of the overall design and helping making sure everyone stays on the same picture is really important. However, the architect in order to be effective, needs to be involved in the day to day programming issues and challenges the team encounters. And at the end it will be the programmers that will do the implementation and they will adapt it according to their understanding so you better have a strong team as well.

Read more »

Posted in: Agile practices. Random Thoughts,Design,Engineering Practices

Creating a Mini-Waterfall

Some people refer to sprints as mini-waterfalls. Well that’s a mistake, sprint are not that.  But a mistake or not, doing a Mini-Waterfalls still seem to be a natural step for some people when they start with their Agile transformation.
So how do you create a mini-waterfall?
well its not very hard like anything else when you create a mini-X you start by taking the X for example:


and then you make the same thing just smaller. like this:

see where this is going?

I encountered several contexts in which a companies, after getting some basic knowledge about Agile, seem to think that they are already mostly Agile, and what left for them to do is just start working in short cycles. So in order to become “Agile”, they take their regular process as is and shrink it down to fit inside short time boxes (anywhere between a couple of weeks to a couple of months) and wait for all problems to disappear (well they just become agile didn’t they?)

Is this bad?

Well actually by itself no. Doing a mini-waterfall isn’t necessarily a bad idea.
on the Pros side we can say the following:

1. Mini-Waterfalls is some kind of an iterative process so you will get more feedback.
2. When you work in a short time boxed iterations you will be forced to work in smaller batches.
3. To support working in small batches you will need to get used to cut and slice the work into small things.
4. and when you work in smaller batches, all kind of things will become visible. For example, your one week manual regression cycle is going to be a real problem. The fact that you only manage building a working version of your product once every three days might also be an issue…

So basically when you start doing a mini-waterfall you are taking one big step in the right direction
However, On the Cons side we should probably say that:

1. Mini-Waterfalls is some kind of an iterative cycle so you will get more feedback.
2. Working in short iterations is just different than working in long cycles.
3. If you don’t do the needed mind shift, working in mini waterfall is going to be very hard
4. And if it gets hard enough , most likely you will stop doing it.

So basically doing a Mini-Waterfall process is not a steady state. Keeping it for long is extremely hard. When you a team starts working in short iterations things that were comfortably hidden become  visible and painful.  and the natural reaction to pain is to make it go sway. You can either fix the problems – maybe becoming more agile as you do, or you make sure to hide them again by reverting back to the older process for example.

So when is it bad?

Mini Waterfalls become bad when organizations confuses them with an agile processes. The difficulties of sustaining a mini waterfall along with this confusion, causes some companies to revert back and claim that Agile is bad. In fact I’ve participated in several emotional discussion with people that experienced exactly that. (BTW trying to go down the this was not agile road only seem to fuel the fire).

Can it be good?

Well I don’t know. However, I’m not sure that’s even an interesting question. Personally I would avoid a mini waterfall. If you try to become agile you should probably try doing something different. There are easier and less risky ways to start. trying Kanban might be a good alternative if you want to start at a familiar place.

But we already are in a Mini Waterfall. Now What?

First realize that by understanding the problem your are half way there.  Best option at this stage is to face reality heads on. Stop pretending you are Agile. You are not and its really not important at all. Accept the fact that the problems you see are naturally caused by trying to take a lengthy process (designed for long cycles) and squeeze it into  a very short time period (iterations). What’s actually crucial at this stage is to examine the pains and learn rom them.  Each and every pain is a place in which something new can be learnt, about your process, about your team about the context or maybe personally about yourself.  If you manage to locate the actual root cause there’s a good chance you can make real progress. Design small experiments with the goal of finding out what may be the cause of those pains. Try to test different things and see how they effect you team. Collaborate with other parties in the organization and see what they have to say. And always remember that a new process (yes even a mini waterfall) require a new way of thinking to make it work. Most likely old solutions wont solve these new problems.

Read more »

Posted in: Agile Management

Can your team agree to this?

Read more »

Posted in: Agile practices,Engineering Practices

Do you think this guy is Agile?

A few days ago I read a very interesting article in one of the the local news site. the site was covering a speech given by a key figure. I’ve taken out some parts which I found extremely familiar. And yes I deliberately have taken it out of context as well,
Try to see if you can guess who said this, what is his role, and in what context it was said:
The following was said at the start of his speech:

When we ask ourselves what is the one thing that distinguishes successful human societies from failing ones. Answer is: the ability to change.

Later on I found this part:

When this is in your core, when you know how change, the difficulties you are experiencing are only minor glitches. The world is becoming increasingly competitive, more and more flat and global, we know about ourselves what others do not know about us: no matter what happens, no matter what will be the circumstances, we will know to take out the best. Whatever problem we will face, we will  know - almost instinctively - how to turn it into an opportunity.

Well to me this sound that the guy completely grok what Agile is all about.


And for those who doesn't  like to keep guessing.
This was said as part of a speech given By Yair Lapid, Israel current Minister of Finance. It was part of the speech given to him in a conference titled “Will tomorrow be better?” and in this talk he discussed changes our local economy will be facing in the upcoming years and about changes he is trying to make.

Read more »

Posted in: Agile Principles,Agile Values

“Introduction to Agile Process Management” Slides

Had great fun last week at the ALM user group meeting. Great audience with great questions and feedback, as well as meeting old and new faces.
For those who missed my presentation, and those who want to refresh their memory, here are the slides:

Read more »

Posted in: Agile Management,Events

Must programmers know how to Test?

I was never asked before if a programmer should know how to test. The underlying assumption is that programmers know hoe to test their own work, and therefore are skilled at testing. Problem is that they are not. And the sad thing is that so far they have managed to get away with it. I’ve been a professional programmer(that is writing code for a living) for more than 10 years, in all the places I’ve worked my managers did ask me if I tested my work. And my answer was always “of course”.  But never was I actually challenged on that. No matter how many bugs were found in my code, no matter how much empirical proof there was that I did a bad job at testing. None of my technical managers ever told me, “please take this work back and test it again, and this time for real”, ever. And never have I seen it happen to any of the other programmer I worked with. I did get work back from time to time with claims that some of the functionality was missing, I did get a lot of bugs to fix. At times it was so bad that my “testing” activity usually only included making sure it compiled executed and didn’t crash on my machine. and that what I called testing.

Programmer who Cant test will become obsolete

As automation gains more hold in our industry people start to expect much more from testing at the unit level. In my last work place doing test reviews was part of our on going process, in fact we probably invested more time in reviewing test code than actual production code. For us it was extremely important to make sure that written code was properly tested (verified) at the unit test level. I expect this is very common to all software teams doing TDD. And while I’m sure many of us just wait  for this weird TDD notion to go away. its my strong believe that it wont. on the contrary latest surveys suggest that as agile is gaining in our industry the necessary engineering practices are also

Programmer – catch up on your testing skills

if you as a programmer want to stay relevant in future markets, you should really start increasing their testing skills. Yes there is still time before testing skill will be listed as one of the mandatory skills in job posting. The growing need for writing automation at all levels, gives a definite advantage (at least in my book) to programmer that has some sort of formal knowledge or experience in testing. (and yes I will need to see some actual proof and will verify such claims during interviews). No I don’t think a programmer should be a professional tester as well (although that might help), but basic concepts of QA, properly designing test suites and understanding that there are more than just unit testing is something I would expect every self respecting programmer to know. In  my limited experience I have found that programmers that posses this knowledge and skills are just better programmers.
And if you want to know how to start here’s something you can try: STARTING TDD – ONE DAY EXPERIMENT

Bottom line

As a programmer you should want to know how to properly test your work(at least at the unit level) ,in order to decrease the time you will be looking for a new job

Read more »

Posted in: Agile practices,ATDD,Random Thoughts,TDD

Must Testers know how to Program?

One of the most common question that rises when talking to testers in an Agile context is
“Does testers have to posses programming skills in an agile team?”
For a long time my answer to that was no, since testing includes vast number of activities which doesn’t require programming skill there will always be room for testers who cant program.
However I think that I was mistaken. these days I would expect anyone who claims the title of a professional tester to posses some level of programming skills. 

Testers who cant program are obsolete.

This fact can not longer be ignored.  As automation gains a firm hold in our industry a tester must be able to significantly contribute to all automation effort. And while certainly one can contribute to this effort without knowing how to program, the room for these is relatively limited.
Yes, even 10 or twenty years from now our industry will still have a large number of testers who cant program. The same way that even today there are still professional Cobol programmer or programmers who cant do object oriented programming.  But I would expect that this will be the minority

Testers who cant program – CATCH UP

If you want to stay valuable in the market, start learning the basic skills of programming today. no, I don’t think you will need to become an expert top notch developer (not that there’s nothing wrong with that). The actual skill level required in order to become a productive test automation engineer (i.e. significantly contribute to automation effort) is lower than that. But Unless you will start to aquire these skills soon you will find very hard to find new open positions.
Here’s an interesting post that backup these claims with some concrete data. And while I don’t consider this in any way as scientific proof or even big enough to indicate anything with significant statistical confidence, it still suggest that   ~80% of testing job posting indicated a programming skill as necessary. Also notice, this post was published as early as 2010.  My personal observation of recent job ads, which is certainly skewed towards Agile culture, suggest that the percentage is even higher.

Bottom line

As a tester you should want to know how to program in at least one major programming language ,in order to decrease the time you will be looking for a new job.

Read more »

Posted in: Agile practices,Agile Testing,Random Thoughts

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

30 days experiments

If you have been following my blog you might have noticed a bizarre pattern in my posting. OK’ lets face it. I’ve been silent for more than 6 months and suddenly there’s an almost endless burst of posts.
What’s up with that?
One of the session I had the luck to join at xp2012 was a group of lightening talks. it was lucky cause I drifted in towards its end and managed to catch the last couple of talks. The first one I already blogged: The Manager's Dilemma by Ola Sundin dealt about management role. this post is dedicated to the second one and that one actually triggered my burst of posts.

Making Change Stick in 30 Days

The session was given by Tom Kealy and was talking about doing small experiments in changing behavior. I’ll let the slides talk for themselves and would just add that the talk was based on Matt Cutts TED talk: Try something new for 30 Days
I really liked his talk and decided to give it a try and since I really felt bad about my posting silence I thought that would me my first challenge:

post something new each day for 30 days

and here is were I currently stands:

The 30 days are not over, but I’m quite happy with the result. This was certainly something I will remember for a very long time. I think that my next challenge would be:

Do a physical workout every work day for the next 30 days.

so what would be your personal challenge?

 

 

Update:

this is how it looked at the end of the 30 days. Apparently I did some mistakes in the previous image. good for me

Read more »

Posted in: Random Thoughts

My Personal eXtreme Programming story

Today at Iltam meeting, I shared my personal experience in using a development process based on Extreme Programming. For all of you which are interested the slides (Prezi) can be found here.

I also would like to take a moment and thank Moshe Salem and Shlomit Morad for inviting us once again to give this session.

And last I want to remind you that next week we will be having the 9th meeting of the Agile Practitioners group. in this session Ayende will share his experience and his wisdom in writing automated tests. to register to the meeting go here

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

Read more »

Posted in: Events,XP

About Visibility

A couple of years ago I had the luck to attend a course given by Ken Swchaber. during that course Ken pointed that the main role of the Scrum Master in a scrum process is to ensure visibility. On all Levels.
But why is visibility so important?
There are many answers to that. Probably too many for me to do justice to them all. for example, you need visibility to understand exactly where you are in order for you to make the right decisions based on real hard facts.
Today, I happened to tune in into a TED session about Four principles for the open world, by Don Tapscott. In that session Don talks about Transparency and what that may cause organizations. He explains that since today the world is so transparent organizations must really adopt good values as part of they backbone. those values are what creates trust which later on enable real collaboration.
So here you have it, we want to create a high level of Visibility in order us to gain the needed trust which will enable us to truly collaborate, with our customers, with our managers with our peers and with ourselves. Visibility is the key to get there.

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

Read more »

Posted in: Agile Principles,Agile Values

Iltam Meeting – Being Agile

on Sunday 1/7 Iltam is going to conduct an interesting meeting that will cover some very interesting agile subject. Specifically what I really like about this meeting that after a very long time I see some content that will mention my old and favorite Extreme Programming process. For some reason the XP methodology is no longer discussed in the Israeli community.

Anyways, there will be three parts to this session in the first part my partner Elad Sofer is going to talk about agile tools, Afterwards Danko will do a scan of various process models which are bundled under the Agile umbrella and I will do the last part in which ill talk about the experience I had in managing an R&D group using the XP process, if you are interested the complete details can be found Here.

hope to see you there.

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

Read more »

Posted in: Events

Taking design out of the requirements

One of the biggest mistake you can make as a product person is to include in the product requirements technical design decisions.
I picked up this lesson about 4 years ago at a session given by Tom Gilb at the first Agile Testing Days conference. I think this lesson is applicable in all types of development processes but is crucial when you are trying to use an agile process

The Mistake

Here’s an example I recently encountered at a backlog grooming meeting:

We need to have a pipeline of processing stages in order to …

It was the word pipeline was got me going. when you mention a pipeline in a user story. no matter how you turn this around you just decided not only what you want but how you want it built. there is no sane user (that I know) that actually care about pipelines. in fact I would assert that most sane user has no idea what a pipeline is, unless they come from the oil business.

So why is this wrong

First lets be clear there is nothing wrong about doing design. In fact it’s a very crucial step in developing software. The thing is that you don’t want to mix between technical design: how we are going to create this, and the business needs (requirements): what we are going to build. and there are two main reason why you don’t want to mix this:

1. when you use the solution in order to describe the requirements you actually hide the business need. instead of discussing the need you start to discuss how you implement it. this makes business decision like prioritization, exact behavior much more difficult. its especially true if the solution is for some reason marked as an “infrastructure” that will be needed. as a product person how can you give low prioritization to something the technical department just claimed to be an infrastructure? even if that infrastructure was just created to solve a less important business need?
2. you don’t want to kill the team creativity – the moment someone put the solution - pipeline in the story was the moment the team stopped thinking about is this the best they can do. Is pipeline the best way to achieve the need? maybe it is maybe its not. putting a pipeline in the solution will discourage any team from thinking about alternative. After all, they were not asked to solve a problem, they were asked to implement a pipeline. so that’s what they will do.

When you are at the phase in which you design your product translating it into requirements for the development team, try always stay in the problem domain. Let the technical people worry about the solution. Technical design is the exact thing they are trained to do. the minute you start giving them the solution you just wasted a highly priced team and probably took one decision much too early.

Read more »

Posted in: stories,tips

Push vs. Pull Management

Over the last decade or so I encounter quite a few managers, while each of them was unique in its own way, I roughly found that I can divide them into two main groups according to their strategy.

Pull Managers

On one hand there were managers who were very into what went on always walking around asking question showing interest in everything going on and putting their nose into all places including those it didn’t belong in.

Push managers

in the other group there were those who considered themselves the focal point of their team, they usually got their info by using all kinds of report, they did attend meeting when needed, and naturally they did talk to their team, but most of the time they were minding their own business using their own room to manage the work. and popping from time to time to ask something/direct the work.

While I do have my own preference on how I would like to see managers behave. I do think that you can be successful using either way. I do however feel that there are contexts in which “Pull managers” have a higher chances to succeed.

Pull vs. Push Systems

No I’m not going the Kanban road. I do want to talk about systems design.

question: if you have a system in which a single component needs to keep track of the overall system state how would you design it?

Will you have the various parts of the system “send” their events to this main component (Push) ? or would you have that main component pull the needed information whenever he needs it?

like always the correct answer is: it depends. If you have a very high rate of changes in your system (lets say thousands of events per second) or/and you have a relatively small number of parts. you would most likely prefer a pull mechanism. if however you have a relatively small rate of change or/and a large number of parts you would probably prefer a push mechanism.

Now lets take it into management. I’m used to work in an agile environment. in such an environment that amount of data which is gathered on a daily basis is large. the entire process is created in order to handle changes. and if you do it right most likely there will be a lot of change. and in such an environment if you want to succeed I believe that going the pull way will server you better as a manager.

Trying to sit in your office and expecting the information to come to you will means that you most likely will:

1. annoy your team – demanding them to bring the information to you whether on a daily basis or via and electronic management tool.


2. Miss a lot of the info – since an agile process will focus on verbal communication, there’s a lot going on which is not captured in any written way

Trust me if your managing an agile team you will need to do the Gemba each day

Read more »

Posted in: Agile Management,Agile Values