IMistaken

Scrum is not a process

noreply@blogger.com (Lior Friedman:) — Tue, 01 Apr 2014 04:16:00 +0000

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.

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.

So what is the Product Backlog?

noreply@blogger.com (Lior Friedman:) — Wed, 12 Mar 2014 09:33:00 +0000

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:

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

About Myths

noreply@blogger.com (Lior Friedman:) — Fri, 11 Oct 2013 20:00:00 +0000

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.

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.

Creating a Mini-Waterfall

noreply@blogger.com (Lior Friedman:) — Fri, 19 Jul 2013 11:50:00 +0000

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:

Mini-Waterfalls is some kind of an iterative process so you will get more feedback.
When you work in a short time boxed iterations you will be forced to work in smaller batches.
To support working in small batches you will need to get used to cut and slice the work into small things.
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:

Mini-Waterfalls is some kind of an iterative cycle so you will get more feedback.
Working in short iterations is just different than working in long cycles.
If you don’t do the needed mind shift, working in mini waterfall is going to be very hard
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.

Can your team agree to this?

noreply@blogger.com (Lior Friedman:) — Thu, 27 Jun 2013 19:25:00 +0000

Do you think this guy is Agile?

noreply@blogger.com (Lior Friedman:) — Thu, 20 Jun 2013 18:44:00 +0000

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.

“Introduction to Agile Process Management” Slides

noreply@blogger.com (Lior Friedman:) — Mon, 10 Jun 2013 18:29:00 +0000

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:

Must programmers know how to Test?

noreply@blogger.com (Lior Friedman:) — Wed, 06 Mar 2013 13:08:00 +0000

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

Must Testers know how to Program?

noreply@blogger.com (Lior Friedman:) — Wed, 27 Feb 2013 15:19:00 +0000

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.

Agile Practitioners IL– Group meeting #11

noreply@blogger.com (Lior Friedman:) — Wed, 07 Nov 2012 15:23:00 +0000

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:

Denial – First reaction is to ignore the problem. it didn’t really happen.
Blame – when we cant ignore the problem we look for someone else to blame. “it wasn’t me it was XXX”
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,…)
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
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.
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
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

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

noreply@blogger.com (Lior Friedman:) — Thu, 20 Sep 2012 14:30:00 +0000

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.

Why should you become Agile

noreply@blogger.com (Lior Friedman:) — Sat, 07 Jul 2012 20:01:00 +0000

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.

Why should you Learn TDD

noreply@blogger.com (Lior Friedman:) — Fri, 06 Jul 2012 14:08:00 +0000

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.

Instoolation

noreply@blogger.com (Lior Friedman:) — Wed, 04 Jul 2012 20:07:00 +0000

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

30 days experiments

noreply@blogger.com (Lior Friedman:) — Tue, 03 Jul 2012 22:30:00 +0000

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

My Personal eXtreme Programming story

noreply@blogger.com (Lior Friedman:) — Sun, 01 Jul 2012 21:20:00 +0000

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

About Visibility

noreply@blogger.com (Lior Friedman:) — Sat, 30 Jun 2012 19:51:00 +0000

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

Iltam Meeting – Being Agile

noreply@blogger.com (Lior Friedman:) — Wed, 27 Jun 2012 19:31:00 +0000

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

Taking design out of the requirements

noreply@blogger.com (Lior Friedman:) — Tue, 26 Jun 2012 19:17:00 +0000

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:

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

Push vs. Pull Management

noreply@blogger.com (Lior Friedman:) — Sun, 24 Jun 2012 18:49:00 +0000

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:

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

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

And Sometimes You Lose

noreply@blogger.com (Lior Friedman:) — Thu, 21 Jun 2012 19:43:00 +0000

Here’s a story of TDD adoption failure:

about Two years of effort becoming insignificant in about 6 months.
Shame

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

Don’t Repeat Yourself–the story of a wasted hour

noreply@blogger.com (Lior Friedman:) — Wed, 20 Jun 2012 21:25:00 +0000

The DRY principle is kind of a known concept to most software developers. it goes hands in hand with “Minimize Duplication” (4 elements of simple design by Kent Beck) “Single Source of Truth” and probably some more of this kind.

But lets start with a story

I hate Wasting Time

This week I was sitting doing some pairing trying to setup their first Given-When-Test using nBehave. We went through the regular steps: creating a new empty project, setting up a new empty spec test running it seeing that it fails and started working on actually doing something meaningful by loading up the application DAL into the test context.

10 minutes into the process, executing what we had resulted in a very nice FileNotFoundException and some text talking about that the need to use a strong name assemblies only.

Great!

Of course Microsoft was generous enough to omit the name of the actual file (which probably would have saved us most of the time in fixing the problem and your time in reading all this) but anyway 1 hour later we noticed that the code base has several 3rd parties dll’s appearing in the wrong places and they were all checked into the source control AND to make things happier they were not of the same version. In short we had mismatching dll’s duplication.

Of course, like always, after I fix a problem everything seems so obvious and I cant figure why I didn’t understand it much earlier. but anyway after 2 more minutes we had that one thing solved and we actually were ready to do some serious work. At that point however we ran out of time so we scheduled to continue another time.

Duplications are Evil

Yes the DRY principle which wikipedia defines as :"Every piece of knowledge must have a single, unambiguous, authoritative representation within a system." applies to more than just code and code design. It applies to all parts of the system, in my case it can be restated by the common sense directive:

You shall only have a single copy of any 3rd party dll checked into your source control

Yes I feel stupid

So where else can DRY be applied? What example do you have?

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

Agile Practitioners IL - 9th Group Meeting

noreply@blogger.com (Lior Friedman:) — Mon, 18 Jun 2012 22:33:00 +0000

On July the 8th we are going to meet again. This time we will meet at live person offices and will take the content into the more technical aspects.
Oren Eini (AKA Ayende) is going to talk about:

Unit Testing - A Historical & Economical Overview

And we might even do a hands on if time allows, so don’t forget to bring your laptops as well.
The even of is open to everyone however registration is required. for more details and to register go here

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

More Agile Myths

noreply@blogger.com (Lior Friedman:) — Sun, 17 Jun 2012 21:07:00 +0000

Marc Löffler in this post talks about some agile Myths. about a year ago I blogged about some agile misconceptions. Here are some to add to this list.

Agile = No Design

In an agile process you usually wont see a specific design phase. In fact scrum for example does not explicitly talk about design at all. This leads some people to think that in an agile process design is not done or is not deemed important. Well actually quite the opposite. Design is such an important part of software development that trying to box it into a specific time/phase in a process simply doesn’t work. When development software you need the flexibility to change/update/adopt your design as you learn more and more.that is why in agile circles we will usually talk about emergent design, or iterative design. the idea is to design more and more of the product as we learn more and more about the problem.

Agile = No Planning

It still puzzles me how people reaches this conclusion. Yes there is no one single long term plan that we follow. But just by looking one can clearly see that most of the structure you have when following an agile process is centered around planning. In scrum in all the ceremonies we do some sort of planning. In sprint planning its quite obvious we plan a sprint, in daily meeting we pan the next day, in demo we gather feedback in order to help plan the next sprint and in a retrospect we plan how to improve.

Agile = Small Teams

When I started out most of the time coming to large companies I heard them saying that while agile sounded nice it seems to be only appropriate for small teams mainly or those “crazy websites” projects. Funny enough I’m lately starting to hear (usually in small companies) that while agile is nice, its too much of a process and is too strict for what we need. its only good for bigger projects when you need a process to get going. It’s funny how the wheel turns.
In truth an agile process can be used in both situation, and the actual goal of the process is to find a balance after some trial an error of course. on one hand we want to give enough structure as to avoid complete chaos and on the other to still allow for the flexibility and agility which are so important to stay competitive in the software industry.

What other agile myths do you know? What is your experience with those myths? feel free to comment…

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

One question at a time

noreply@blogger.com (Lior Friedman:) — Sat, 16 Jun 2012 20:59:00 +0000

Taken from Agile Testing list:

If someone asks me a complete list I tend to ask what is your most valuable question you want to get answers now.
And because I am a man I can only do one thing at a time ;)

Pascal Dufour.
What a great way to describe the process of test automation.
Yes I now the context of this quote was completely unrelated to anything about testing, But it did ring a bell for me.

Where should I start?

A very common question I hear many time when I talk to people about the need to test their feature. Many times that not because they don’t know what needs to be tested. But because there are so many things to test that it gets a little overwhelming and from all the many things its really hard to know where to start.
So here’s an idea. Treat your tests as question you would like to get an answer for. Each test case ill reveal a piece of information about the feature you write telling you some specific a fact about how the system behaves.
for example when you test a trivial add method one question can be: I want to know how my method adds too positive integer values. another question could be: I want to know how my method deals with adding a negative value to a positive value. and so on.
The trick is to ask yourself:

what is your most valuable question you want to get answers now"

that should be the first test you write, and when you get an answer the next test should give you an answer for the next most valuable question. and you continue to write tests until you don’t have any more questions to ask.

only do one thing at a time

Does this sounds like one assert per test?
To me it does. and now I have a good answer when people asks me why just one assert per test.

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