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

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

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

Pain the Ultimate Motivator

Gil Zilberfeld asks Why Did Agile Originate In Software?
Answer: the pain!
The software development business has been suffering for quite some time. The Standish group has been reporting (int heir Chaos report) that about 2/3 of all software projects does not meet initial expectations (either the completely fail or overrun budget/time or both). And for the past decade or so those numbers have not changed drastically.
And frankly every person involved in the software industry is familiar with this pain. Developing software is a hard business.
And where is a pain there is a reason to change. That is the nature of evolution. Successful species do not change. If the methods and techniques that predated agile were good enough there was no reason for Agile to be invented (or is it discovered).

The First question

One of the first question we start with at a new organization is trying to understand the current issues. And we specifically ask the people involved what exactly are they trying to solve. We ask not because we cant tell. We ask to make sure that they are feeling the pain. In order for us to actually continue we need them to truly feel it.
“I just want to improve” is not good enough. In order for agile to take hold and really succeed. There must be a a big enough pain. Otherwise the people involved most likely will not have the necessary motivation to stick with an approach that in many cases seems weird and counter intuitive. In order to change we must feel a pain.

How come we’re lucky to be the first citizens in agile-land?

Since Pain is common place in our industry we had enough people motivated to try new things. Eventually, I think, that what made agile evolve. Not so lucky are we?

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

Read more »

Posted in: Random Thoughts,Self Improvment

So how are design pattern working for you?

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

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

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

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

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

I wonder…

The human brain as a pattern matching machine

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

Learning to speak

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

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

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

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

Misplaced Design Patterns

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

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

Design Pattern as a language

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

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

So what should we do?

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

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

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

When two “Foreign pattern speakers” meet

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

So what are you?

1. a native design pattern speaker?
2. learnt design pattern as your second language?

Read more »

Posted in: Design,Random Thoughts

How do you decide if Agile is suitable to your project or not?

I get this a lot and usually I don’t give a simple and straight answer. This time I will make an exception.

So how do you decide if an agile is suitable for your project or not?

Simple! if you ask this question the answer is NO. I’ll repeat Agile is NOT suitable for your project.

wait wait, an agile coach saying that agile is not suitable???? what the…????

Yes. That’s exactly what I’m saying, as long as you keep asking this question, clearly you are not at the point of adopting Agile into your project.

I have found that I get this question from 3 type of people:

The agile practitioner/coach/consultant.

I ask you: do you really need an answer for this? who is doing the asking. Most likely these are just repeating the question. Since they have been asked by the other types. So for you, I hope this post will give an alternative answer to give.

People who have encountered Agile and think it’s nonsense.

These people have already decided against Agile. They are just seeking for excuses for not doing it. The hard truth is that adopting Agile requires people collaboration. chances for success drastically goes down if the people involved don’t want to go all the way and actually adopt agile values. So if you don’t want to do Agile, don’t do it.

Why seek excuses? clearly Agile will not work in your project, so until you decide to really give it a chance don’t try it.

Agile newcomers who doesn’t know what it is.

Everyone working in an agile way passed through this point. at this point you probably heard some stuff about Agile/Scrum/Kanban… you have heard rumors and stories about great success however you are not yet sure what it is and how does it fit into your process so for now you just want to know whether you should invest time and effort in this.

However if you are still at this point, don’t try it just yet. Simply because you are not yet ready. Most likely you are lacking the needed knowledge to make it work. Adopting an agile methodology is not a trivial thing, it requires knowledge and expertise. Agile implementations can and does fail and one of the common reason I see is partial knowledge of what Agile is all about. so until you gain the needed knowledge Agile is not (yet) suitable for your project.

Basically I think this is the wrong question, instead you should ask yourself the following:

• How will an Agile approach can help me improve?
• What can be the benefits I might gain if I’ll become agile?
• What will be my impediments for adopting an agile process?
• How can I increase my chances for success in becoming agile?
• What might be the risks if I become agile?

After answering these question you can decide how to proceed.

Read more »

Posted in: Agile Values,Random Thoughts

The Human Iron Triangle

The Iron Triangle in software development is an old well known metaphor for explaining many of the hard realities in software project management.

The first version Ive seen was taken from Scot Ambler The "Broken Iron Triangle" Software Development Anti-Pattern looks like this:

Another version I like is Mike Cohn Clock representation:

Recently I came up with my own version mapping the various roles in a typical project, doing it i came up with this:

I’m still trying to understand what it says but so far i came up with the following insights:

QA Are Trapped

No wonder QA people feel caught up in the middle. That’s exactly where they are. Everyone is pulling on all sides and they are stuck in the middle getting torn apart.

Managers will always win

Management hold the more stable end in the triangle. Resources/budget has a tendency to stay relatively fixed and in practice does not allow for much flexibility. This might explain why management never budge.

R&D will never learn to like marketing

Looking at the triangle its perfectly clear why Product/Marketing and R&D always fight (which i have seen too often ending up in a disaster), both are trying to pull in their own direction and since management never budge you get a direct conflict between the two.

I wonder what else i can learn from this.

Read more »

Posted in: Random Thoughts

Things That Works – Time Management

Gil has posted two articles (Write down everything, Juggling multiple tasks) about techinques he uses for time management that works for him. Since i liked his title so much and since this is a problem im struggling with as well I thought to add.

So first lets describe my context (a solution is not relevant without the context in which it works/failed). being an agile coach means that a large chunk of my time I’m dealing with a few regular clients, some small gigs that pops up and of course the staff related to marketing sales and logistics. I’m also doing some academicals research and have a couple of pet projects I try to advance.

Attempt 1

I started out by using old plain memory power , and to say the truth most of the times that worked for me. However, in time the amount of things i juggle between, caused me to miss things which should have not been forgotten. So I understood i needed to back up my memory.

Attempt 2

Next step was to write everything down, I started out by using physical notes, however since most of the time I’m not in the same place I found the need to carry the notes with me to be too cumbersome.

Attempt 3

next I rearrange everything into a big list (using excel), I’ve tried applying the “product Backlog” technique taken from Agile methodologies (well that’s a surprise). And to many extends that improved things a lot. Using a backlog allowed me to write down big things I wanted to accomplish (“stories”) and to break them into specific things I need to do (“Tasks”). It also improve prioritization, making sure that the important things got done first.

Lately however I recognized that a simple unified backlog is, well, too simple. when examining my work week i discovered that in most days, my work was dedicated to a single main thing (with some small interruptions to other things). I also noticed that if I group the backlog along the lines of my work days i can treat many of the things has there own separate project and I don’t really needs to prioritize between them. I just need to decide how much effort to allocate to that project i.e. decide on which day I’m where.

Attempt 4

So finally my current scheme for handling things has molded into this:

For each “project” I do, which currently are:

1. One per client.
2. One per pet project.
3. Research
4. Personal
5. Marketing
6. Logistics.

I have a separate to do list contained in a one page plain text file. In all cases (and I think this is crucial) I keep the list less than a page long. Each list is sorted by priority and every new thing gets inserted into its proper place according to project and priority. When I finish tasks i just delete them.

I no longer distinguish between ’stories’ and ‘tasks’, since I found that after splitting the list into various files one page is enough to hold all the tasks.

At the start of each Month I do an initial plan of how to split my days, which get revisited at the end of each week (and any other time I feel the need to do it).

at the start of every day, when i get to the place where that days project is being done ( a client, home,…) i can just focus on one specific from which i decide the goals for that day.

and the rest is still left for “Memory Power”.

Summary

so far my last attempt is working ok for me. on the good side I managed to order my week into complete days and to some extend decrease the amount of context switching. I’m consciously limiting myself and when I can I don’t split a day between two projects or more. inside a day I’m keeping my focus and so far i managed to minimize the misses.

on the down side I think that overall my task list has grown and I’m starting to feel the pressure. I know that that’s probably because I’m taking on too much and I think that happens since I’ve lost to some extend the overall view. I need to find a way to improve on that (or find a way to to add more hours per day).

Read more »

Posted in: Planning,Random Thoughts,tips

Importance of prioritization

Knowing to prioritize is a necessary skill.

when you open windows live update which claims to have 1 more

important update selected

and you see that the update name is

Games for Windows - Live V3.3

You kind of think that someone is missing something.

Read more »

Posted in: Random Thoughts

The things alcohol make you do

A consultant and a developer went to a bar.....

And after a few drinks they got into a stupid discussion on how bad programmers are.

One said that most programmer will look at a class and if they will think that they will only need a single instance of that class in their system they will instinctively make that class a Singleton.

The other would not accept the fact that this can be.

So who do you think is right and who is clearly mistaken?

and while you're at it, can you tell who said what?

Read more »

Posted in: Random Thoughts

Customer Support

A couple of days ago I had a good conversation with a friend of mine regarding customer support. Before going into the actual discussion, I want to say that I'm a very strong believer in actively engaging your customers/users on all level, specifically one of the competitive advantages any organization can develop is having great support. In fact there is no excuse for not having great support. You don't have to be a big company, you don't have to use any fancy management system, you don't need to hire special experts at doing so. All you need is the will to establish great support and the persistence to actually go and do that.

Establishing great support, from my experience, has one of the biggest ROI in the organization.

But back to the discussion, specifically what we talked about is how far will they go and expose their support database to their users. Currently, while they do have great support, from a user perspective, once a call has been acknowledged as a defect or a needed feature there is no visibility as to its progress.

In most cases, either you have stumbled on a critical thing, resulting in an almost instantaneous fix (sometime in a matter of hours), or you have stumbled on something less important which go into an arbitrary hidden to do list. as a user there is no middle ground. The things that go into that future to-do list are going into a big black hole and there is no telling how long it will take to actually get a fix.

On the other hand when I asked why do they not publish the above mention to-do list, he told me that currently he fears that seeing the entire picture might scare off some potential and even existing users.

To that I said not likely!

Granted I'm sure that some will be scared if the list is big enough, However like I any kind of relationship being honest is probably the best long term strategy. Hiding the truth from your users has a big chance to backfire. As been demonstrated in several occasions (and being on that end as well I also can testify), you can't hide forever behind a hidden to-do list. At the end the users, will start noticing that some defects are going down that drain hole never to return. And if enough of them does so eventually you will have to deal with a damaged reputation and that's even less fun. Hearing once and again that "this will be fixed/added in a future version" without committing to a time frame, becomes annoying unless you actually see those in a reasonable time. And you never but never want to have annoyed users.

Personally I prefer to hear the truth, if you decided that the issue is not that important just let me know. If its that important to me maybe I'll be willing to pay for it. If not, just help me to work around this. I'm a grown up and I expected to be treated as a grown up.

of course we have also discussed some middle ground, one option was to allow all users to track only their open cases. Which probably wont change the fact that these things are not fixed, but will give a better indication to the actual status of things.

naturally in the long run the only true solution is just to make the product so good and the number of defects so low that this will become a non-issue. However that's probably a whole different story.

So share with me how are you handling your support at your work place? what more can be done in order to mitigate and find a good compromise?

Read more »

Posted in: Random Thoughts,Self Improvment

Flexible Planning

I sometimes have trouble with explaining to people the basic concept behind agile way of thought regarding project planning and management. Recently i cam across this gem, which as far as i could tell is unrelated to software but in my eyes does a marvelous job at explaining these ideas.

just to make sure i understand, I’ll recap his main points.

there are two way of planning and managing a project:

the classical way – set your goals as the result you want to achieve, from those goes backward and derive the steps needed in order to achieve these goals.from these decide on your plan of action and than just try to follow that plan.

Flexible Planning – goes a little different. you still start out by setting the goals as desired results. but instead of going backward from them, you start by examining where you are and then pick a single action to do that will bring you closer to these goals.when you finish doing that action you evaluate your position again and again pick a single action that will advance you towards your goal. hopefully given enough time you reach your goal.

these two approaches are completely different, the first one when applied to software projects will result in a Gannt chart depicting your plan and by trying to forcing the organization follow that plan. in some places management will even put several check points to and allow the plan to change (which in most cases when facing reality that is a must). The second approach is in my opinion embodied in all agile processes. its an inspect and adopt process. you take one step inspect your new state and adopt you next actions.

The funniest about this, is that i used to work at a company which was in all aspects attempting to be and was an “agile” company. However, in one of the higher management meeting, I was told to plan my work and my team goals using the first approach. Sadly only today I can recognize the contradiction.

Read more »

Posted in: Agile Principles,Planning,Random Thoughts

The one true way

in a recent post uncle bob talks about BDD and compare it to a table based style of test definition.Ii don’t want to talk about that.

i do however want to comment on the following quote:

My issue is not with the tools. My issue is with the idea that BDD is the only true way, and that all tests should be expressed in GWT format forever and ever amen.

Lets revise this statement. In fact lets just remove the part where BDD is mention and we get:

My issue is not with the tools. My issue is with the idea that _____ is the only true way

How many times have you been in a discussion which went along these lines? how many blogs have you seen advocating for “single and best” solution?

I myself have seen these kind too many times. I’ve seen it in the context of design, testing, code convention, SCM’s,coding languages, methodologies, you name it.

ENOUGH!

In this short and simple sentence Uncle Bob captured what I believe too many people are tending to forget. People tend to forget that every problem and I mean every problem has a context. And that context dictates whether a specific tool/solution/approach is good or bad. In our profession there are no simple answers and straight forward solutions, silver bullets do not exists.

What distinguish a true professional from the rest, is the ability to use many techniques and approaches, picking from them a correct solution for a given problem.

Beware of people that preaches “Mine is the only true way”.

Read more »

Posted in: Agile Values,Random Thoughts

YAGNI - It all Connects

Everything in software connects. Here a common thread that connects the following agile? principles:

YAGNI - You Aint Gonna Need It.

YAGNI is referred to the fact that most time in software development its useless to try and think ahead since most of the time we just don't really know if we are going to need this or not. as Ron Jeffries puts it:

"Always implement things when you actually need them, never when you just foresee that you need them."

KISS - Keep It Simple (Stupid)

Which is the same as saying do "The simplest thing that could possibly work" we use this phrase when we want to emphasize that simplicity in software has usually much more value than we initially think.

There is no one perfect design

I'm not sure this has anything specific to agile. But this one has been gnawing at me for quite some time. Too many times I've been in design sessions were people were deeply arguing about whose design was the best, when clearly they were all good enough. While clearly there is such a thing as good and bad design. Mostly its a matter of context. Every good design is aimed at allowing a certain type of change to be easy. However by doing so, many times, it makes other types of changes harder.

So how do all these three connects?

If we accept the fact that there is no one perfect design and each design is best suited to a given type of change, and we also accept the fact that we lack the gift of vision, so in most times we fall into the YAGNI principle. We are left with the conclusion that we must do "The simplest thing that could possibly work". Even if at that point of time the resulting design doesn't look great. That's OK. If and when we will need to apply changes, then we will know exactly what type of change is required. And only then we shall evolve the design (by Refactoring) to cleanly accommodate that type of change (which is most likely to happen again)

(I would like to thank Uncle Bob, that in his talk about SOLID design in NDC has helped realize how these principles close the circle)

Read more »

Posted in: Agile Principles,Design,Random Thoughts

Practical Scrum Course

At the end of the first day in my Practical Scrum course I've asked 2 questions at the end of the day:

1) What was the most surprising thing you have heard today?

2) What is the most controversial thing you have heard today?

here's what I've got:

The most surprising

1) That even for the simplest "project" it takes 2-3 tries to reach a good way of doing things. (In response to an exercise we conducted)

2) That the waterfall methodology is an example of a flawed model. (taken from wikipedia: Royce was presenting this model as an example of a flawed, non-working model (Royce 1970).)

3) That so far the Scrum process is not that far from what we are actually doing.

4) That plans don't have to be too detailed, and paperwork may actually be less important then we think.

The most controversial

1) The claim that we are not good at estimations.

2) That we can start development without planning everything initially

3) That we can work (most of the times) in cycles of 3-4 weeks and give real business value to the customer at the end of each cycle.

Read more »

Posted in: Random Thoughts,Scrum

ScrumBan

After Alistair lecture the convention divided into 4 different tracks, I chose to attend the session titled as ScrumBan given By Yuval Yeret (a Coach in Agile sparks). In this talk Yuval introduced some of the ideas behind Kanban and how they fit inside a Scrum Process.

So what is Kanban

I not going to explain too much here info on that can be found here and here. I would just say that Kanban is what guided toyota when designing its lean manufacturing line and it very much resemble a Scrum process with two major differences:

1. its more flow based and less iteratice kind of process.
2. being a flow based process the amount of work In Progress allowed (WIP)is limited.

When to use Kanban

Kanban should be used in situations when one can’t plan effectively, even for a very short cycle found in Scrum. This usually happens in specific kind of projects. one example would be projects which are mainly about support and maintenance. In These priorities really change on a daily basis making planning useless.

However many projects do have specific stages in which its really hard to plan ahead and naturally they adopt a more Kanban style of working. This happens a lot towards a release date during the Hardening phase. In this phase most of the work is about solving issues found as fast as possible and there is nt much use in doing extensive planning ahead.

When not to use Kanban

Kanban is sometimes adopted to hide a Scrum smell. Sometime an organization find himself incapable of planning and adopt Kanban way of working. However, the inability to plan can sometime be a real dysfunction needs solving. Maybe the PO is not doing a proper job in managing priorities, maybe an external force like the CEO is injecting too much noise… adopting Kanab in this states will only hide the problem (at least for some time). In these contexts Kanban can be viewed as a ScrumBut

The effects of doing Kanban

The most visible effect of Kanban is that from time to time team members will be blocked. Since the amount of WIP is very limited. there will be cases in which a team member is not allowed to pick up new work and needs to find himself something to do. The first option this member has is to help others. and indeed, One of the goals of a Kanban process is to generate teamwork in order to solve bottle necks in the process.

but there are cases in which one cant help others, this is the time in which a member works on improving the process. Whether by trying to understands why the bottle necks happens and resolve them. or by doing any kind of work to improve General productivity (Paying Technical debt, optimizing some development process, cleaning up…)

another Effect a Kanban has is the that regular measurements like Velocity burn down charts lose their meaning. You cant draw a burn down when not working in time boxes, the same goes for velocity. Instead in a Kanban process one use a modified Burn up chart in order to measure the WIP at any given time (where the goal is to minimize it) and ”lead time” which is the time it take for a task/feature to be finished (naturally the goal is to shorten the time).

To summarize Kanban is an agile process, which resemble Scrum but takes it a little further by adopting a flowing kind of process. It was successfully adopted by Toyota , and it can be adapted to enhance a Scrum process or to replace it in specific stages during the prodcut life cycle.

next Scaling the PO Role

Read more »

Posted in: Events,Random Thoughts,Scrum

Versioning Scheme

There are various scheme for handling version number. But so far I haven't really encountered anything meaningful in any of the schemes. several days ago I encountered scheme which I really liked.

The scheme is a variant of Change Significance and is specifically aimed for API libraries, that is while I'm sure it can be extended to regular products, its basic semantics is for aimed for API's libraries.

and the semantics goes like this (using a four digit sequence):

• a change in the first number means the API has changed in a breaking manner.
• a change in the second number means there were additions to the API
• and a change in the third number means an that the internal behavior
• Last number is a sequential build number.

Let take for example NUnit, if NUnit will adopt this scheme. When upgrading from lets say 2.4.0 to 3.0.0, I would expect that some of my existing tests will need to be updated to reflect the changes. When upgrading from 2.4.0 to 2.5.0, I would expect to see some new abilities reflected in new API's (but my existing tests should still stay valid). And last, when updating from 2.5.0 to 2.5.1 there would be some internal changes in behavior that shouldn't affect me at all.

I really liked this one when I heard it, what do you think?

Read more »

Posted in: ALM,Random Thoughts,tips,tools

The Fifth Value – Respect (cont.)

Some time ago I touched the subject of respect in the software development business. Yesterday I had the chance to talk with one of the persons working at  a client of mine. Beside of holding the respectful position of VP QA (the company is of medium size) the guy also allocate one day a week to maintain an IT business he once had which currently has a single client. After talking about how he ended up in this kind of arrangement, an obvious question for me was why does he keep on doing it. Isn't the fuss of handling a single customer to big to be worth the time?

The answer I got was:

Working for that client puts me in perspective. once a week i get the chance to function as a plain technician. This gives me the opportunity to get on my knees and work with the bits the bytes.

For me this is the essence of humility (which is a corner stone for respect), although the guy has attained the "big boss" status, he understand that there's more to it then just management, and in order for him to excel at his work he needs to get down as close as he can to the daily work the people working for him do.

I salute you!

On the other extreme,  a previous boss of mine once told me that he was advised (and agreed to) to treat every hour of his work as costing 2000$ (no, this was not the guy salary). The reasoning behind this that being so high on the food chain he should not waste his time.

For me this kind of attitude puts you on the opposite scale. Saying such a thing comes as close as you can (without actually saying it) to "I'm worth more then you are" or more simply "I'm better then you are". This is just being rude.

I wonder how would that guy take an advice that goes: "Unless you generate 2000$ profit for the company per hour, your not doing your job"

Read more »

Posted in: Agile Values,Random Thoughts,Self Improvment

Quality is infectious

In his recent post - Quality-Speed Tradeoff — You’re kidding yourself, Ron Jeffries has explained how high quality is mandatory in order to achieve high delivery rate.

There are many reasons for quality issues in a product, inherent technical complexity, lack of skill or just plain laziness. However an over looked factor that really hurt quality is pure pressure. When the pressure to deliver rises above a certain level (which vary for people and teams) the team starting to cut corners. When pressed developers will deliver. However we are not magic workers. When pressed we usually starts by working longer and harder, but when that's not enough, the only option left is to compromise current quality in the hope that part of the work can be delayed after the delivery. The mistake involved is the belief that after the release there will be time to fill in the blanks so to speak. naturally there is never enough time. In the agile community we even given those cut corners a glorified name, we call the work we should have done "Technical Debt".

Bad Quality is Infectious

The real problem is that bad quality is infectious by nature. It can starts by maybe skipping a needed refactoring, it might start by not writing  unit tests for a given component (assuming we will do it later) but very soon islands of low quality code start to form. As time goes by these islands have a tendency to grow. In a large enough code base they hide themselves for quite some time. They are always discovered at an inconvenient time when they affect work being done but when there is no time to actually fix it, so another workaround is coded, and again quality suffers just a little more. So they grow and grow until bigger problems starts to show, suddenly the escaped defect rate has significantly increased, adding new features become harder and takes longer. And quality continues to deteriorate until something is decided to be done about it. The problem is that by the time we reach the this stage the cost for fixing the issue is high.

Good quality is also infectious

The good news are that good quality is also infectious, most programmers (at least those I know) really want to do a good job and achieve a high quality code. So it doesn't take much effort to keep us on the high quality road. I have seen cases that a single team member by not compromising quality, cause the rest of the team to follow, even at points when pressure was high.

 

 

So the morale of the story is very simple, quality for me is mainly a state of mind. The moment I accepted the fact that by trading quality I always but always LOSE (and constantly reminding myself of this) I find it easier to achieve better quality. The up side is that I saw how this kind of approach infects others as well.

Read more »

Posted in: Development Practices,Random Thoughts