Do we need a Tech Lead role ?

I have been thinking about whether we need a tech lead role for sometime. But now, I have come to a conclusion that tech lead role is unnecessary. Let me list my reasons, why I feel that way.

1. Instead of a tech lead , we need a person to act as tech facilitator. This role should be rotated among the team members in weekly basis or biweekly basis. The main responsibility for Tech facilitator will be to resolve some technical conflicts within team by facilitating a discussion where advantages and disadvantages of all approaches are discussed and decision is made.
2. I strongly believe the person with a strong technical expertise will be recognized by the team itself. We do not need to appoint a tech lead. Team members will go to a person who they trust as expertise in that technology. So there is no need for a technical lead role.

So instead of we pushing a person as a Tech lead to a team, I think we should let the team organize itself.

Waterfall is perfect (with some assumptions)

I took "Software development life cycle" course in my school long time ago. It was an interesting course as it was the only course that explained software development process from one level up compare to other programming courses. As a part of the course, I learnt about Waterfall process and different phases in waterfall process. At that time, I felt that Waterfall process is so simple and perfect. 

1. We gather ALL requirements
2. We design the ENTIRE system to attributes and behaviors level in classes
3. We code those designs
4. Test the system
5. Ship or release it.

I felt waterfall is the way to go. It is amazing yet simple. It has less steps than making chicken soup.  Waterfall process can never fail, but there is a catch. Waterfall process has many assumptions and some of them are,

• Requirements never change
• Design is perfect
• Coders can easily implement those designs
• Defect fix will not have much impact in the design as it is perfect.

These assumptions can never be true. In waterfall process, we never consider these assumptions can be wrong. We do not consider them as risks. I think this is the biggest flaw in waterfall process.

Now lets look at some assumptions made for agile process.

• Requirements will change
• Design will evolve and change as we gather more knowledge

As you can see assumptions made in Waterfall process and Agile is totally different. It is these assumptions that make such a difference between agile and waterfall. It is not the phases. In both agile and waterfall we will have requirement , design , coding and testing phase. 

In agile because of its assumptions, these phases are done quite differently from waterfall process. 

Requirement Analysis:

In agile we embrace change and expect requirements to change unlike Waterfall process. So expecting change in requirements, we do not do too much analysis. We do analysis only when it is needed. The advantage is as you wait till the last moment, you can use new knowledge that you have gathered about the system. 

Design and Coding:

In agile, design and coding phase happens in quick sessions that it looks like a single phase. As developers expect the requirements and designs to change they make sure they have good test coverage as a safety net. As they have good test coverage, they are not afraid to change their design or code. They do not spend too much time designing for future (which will be different anyway). They get things done with the information they have at that time.

Testing:

Defects found at this stage would not have much impact in the system as all other phases are expecting things to change. So there is no surprise. 

Workflow:

As analysis is done only when needed, there is less features for developers to design and code. As  only few features are implemented, there is less features for testers to test. So all these phases are done in a very fast rate. Mostly within a week or two. They keep doing them again and again till the customer is satisfied.

As you can see, some simple assumptions can change the whole software development process. So more than anything else, your assumptions will determine whether you project will be waterfally or agilely.

Please teach me rspec

I was first introduced to BDD like 4 years back by Dave Astel's article. I really liked the idea. It totally made sense to me. I was like damn this is the way we have to think for designing objects. That time I was working in a java project. Igor and I were like okay lets do BDD and started naming our Junit test methods like testDogShouldBarkWhenThrownStoneAt . When jBehave released I wanted to use it, but I never got a chance.

When I started working on yewoh, I was so excited that now I can chose whatever framework I want. Being a BDD addict, I obviously chose rspec. It is a great framework for doing BDD.It gives you nice syntax to express behaviors in "when" and "should" format .It felt very natural for me to write verifications for verifying my object behavior instead of tests.

Now after using rspec for sometime, I have some questions about rspec.

• What is the best way to organize specs? In rails project, specs are arranged in folders like models, controllers etc. I do not have a problem arranging the spec files, but I am not sure how to organize specs itself. Does anyone has some good practices that worked for them?

• Sometimes my objects have behaviors like "Player When power is on It should start playing When play button is pressed " . In this behavior I have two When conditions. How do you express this behavior in rspec ? Should I have it like

describe Player, "When play button is pressed"
    it "should start playing if power is on"
      ....
   end
end

using a if condition. Or should I have something like this

 describe Player, "When power is on and play button is pressed"
   it "should start playing"
     ...
   end
end

• In unit test, usually we write tests to make sure our method do not blow up when we pass nil for example. I feel it is a good test to have. How do we writes spec for this kind of situations?  

Rspec documentation has good explanations and examples for rspec syntax. But I am looking for best practices for using rspec.

It will be great if you all share your experience with rspec.

Do we need Iteration Planning meeting?

Iteration Planning Meeting (IPM) is becoming a controversial topic. In one side , some people feel IPM is a must. In other side, some people feel IPM is not needed. I have friends and people whom I appreciate in both sides. According to me, I feel IPM is needed (not a must) but in a different form.

These are the activities that usually happens during a typical IPM.

• Showcasing (Demo to customers)
• Retrospect
• Story presentation
• Story tasking and estimating
• Planning
• A little celebration for finishing an iteration.

In those activities I have mentioned above, I am not convinced that some activities should be part of IPM. Let me explain one by one.

Retrospect:

Retrospect is where we collect knowledge to eliminate waste. We can retrospect what things worked and what did not work. The problem I have is why cannot retrospect be an ongoing activity instead of just happening during IPM ? We can have a board where everyone in the team can add things whenever they want that they like or do not like. The board will be always up to day. In daily standups everyone can discuss on issues that are very critical.

Story presentation:

Story presentation is where a analyst will present what a story is all about. Developers can ask questions to understand about what is expected out of that story. This is a very useful activity, but again why it has to happen during IPM. Story presentation should be postponed till some developer is ready to work on it. That way we can use new knowledge that we acquired in the past few days working with other stories.

Story tasking and estimating:

Please look at my other blog, where I have discussed the importance of tasking. Again like 'story presentation' this activity should be done at last possible moment (ie.., when developers are starting to work on that card) instead of being done during IPM.

Planning:

Planning is something that we can never avoid. Planning has to happen. But we should understand that planning is not a commitment. We should be willing to change our plans as we gather new knowledge. Planning for short term should be more towards what is next three stories (keep this number as low as possible) that I wanted my team to work on. Things change so fast and we gather so much more knowledge in a short time. So planning should be a continuous activity rather than being done only during IPM.

Now our new form of IPM will have only these activities,

• Showcasing (Demo to customers)
• A little celebration for finishing an iteration.

Ideal situation:

In a ideal situation, customers will be always sitting in your team room. Whenever we have a story done, we can deploy to a demo machine (which is very close to production system ) and demo it to the customer. In this scenario, celebration is the only activity we will doing during IPM.

Reality:

In reality, not all customers will be sitting in team room. So we need a scheduled time to demo the stories you have done to get feedback from them. So we will need IPM , but in new form.