SMART Objectives Deployed at Synerzip

Much is said on the Agile processes in this blog, I think its time to talk about what else we do at Synerzip which we are proud of.

Today I will be talking about SMART Objectives. And yes, it is closely related to Agile. Remember what Agile says, its people over processes. Hence it is very important we keep our employees motivated all the times.

Lets see how a typical appraisal process works, once in 6 months managers and employee meets to discuss how the employee is doing, feedback only happens once in this 6 months. Often a rating sheet is being filled in with As,Bs and Cs, but the intend behind the rating is not shared at all or not shared effectively.

SMART Objectives - The Definition
Specific - Be specific about the objectives. Same thing applies to feedback, positive or negative, be specific, give examples of situations in past. But be very Specific. This is the most important point of SMART Objectives.
Measurable - The objective set should be Measurable. "You have to train 5 people".
Achievable - The objective set must be achievable. This is a must, if certain person in your team is not able to meet his/her objective, the failure is yours too.
Realistic - Many objectives can be achievable, but they should be realistic, they should meet the goals of the team,project and organization.
Time Bound - Each Objective Set must be time bound. "You have to train 5 people, before December 15th 2007".

SMART Objective process
Deploying SMART Objectives in your team is easy, running it is rather easier said than done. My own experience says processes have be light wieght and should be following general common sense, other wise over a period of time, people stop following them. The same is true with SMART Objectives.
In order to mae SMART Objectives effective, try to follow some of the following ideas

1. Regulary follow up with One on One Meetings. Once in a month One on One Meeting, in which not only feedback is exchanged, but the Lead follows up with person meeting his/her SMART Objectives is a good idea
2. Try to have a different rating sheet, in which you specifically mention, that in coming 6 months if a person meets his/her SMART Objectives (in timebound fashion), the person can get a A/B/C rating. Believe me, this motivates almost very one.
3. Often it is a good idea to share some ones SMART Objectives. This should typically be done, if the SMART Objective of one person, would have positive effect on others. In this case, others would themselves follow up on meeting of the SMART Objective

We see a great value in SMART Objectives in our team (Pavilion). If any one of you wishes to find something more, please feel free to contact us.

Posted by Rohit Ghatol

Mobile Computing Blog

Hi guys,

Being Mobile envangelist, started to recall to my work in Mobile Computing for last 4/5 years. I shall be writing stuff on some of the work I had done in Mobile, OS, Platforms. Challenges in designing applications for the mobile platform.

Please check http://anand-kale.blogspot.com/ .. Its still being edited so take a look at it after couple of days.

Cheers,
Anand

Agile Software Development Ecosystems

Just got this book from British Library, since it helps most of the times sometimes to read in the old traditional bookish way to understand the concepts. This is "Agile Software Development Ecosystems" by Jim HighSmith. It not only talks about scrum but other ASDEs.

Major Agile methods mentioned here are,

• Scrum
• Dynamic Systems Development Method
• Crystal Methods
• Feature-Driven Development
• Lean Development
• Extreme Programming
• Adaptive Software Development

The most appealing thing about this book is the presentation of case studies of companies on how they adopted the agile methodologies.

Some of the quotes by Ken Schwaber - Co-author of Scrum are

• "Scrum relies on self-commitment, self-organization and emergence rather than authoritarian measures".
• "Do these few things well, and projects will succeed"

Agile - Clearing the first misconceptions

Addressing the most common misconceptions or mental roadblocks for the lead

1. Water fall works then why Agile?

- We agree that water fall works, we agree even more that agile works better.Waterfall models forces us to enter in a contract based relationship with the customer.Instead Agile model is more inclined towards collaborative working.In agile, with the shorter iterations delivering working software, the customer can get a feel of what they would get and could ask for changes early. One reason Agile came into picture is because it is a better model to incorporate frequent customer change requests.

2. How to ensure quality in 3-4 weeks iteration?

- Being Agile on the project management is not enough, Agile has to work from individual contributors till the management. The individual contributors need to be educated about Agile development methodologies like TDD, User stories, etc.

3. It is not possible to deliver some thing in 3-4 weeks

- This perception is due to past experiences in water fall, which is more focused on task completion than deliverable. In Waterfall the word "deliverable" is not uttered in the first 3-4 weeks. Here is where the basic difference comes, Agile talks about deliverables as agile believes in working software than documentation or code. In order to deliver some thing in 3-4 weeks, right from the lead to every individual level would have to contribute deliverables. Larger deliverables are broken into smaller ones.


4. How to get the more frequent client involvement?

- One of the requirements for Agile to be successful, is to have the client involved on a regular basis. If the client is not ready to receive the iterative deliverables, agile is not useful to the client as well as to the team following Agile. If for some reasons meetings do not happen with the client regularly, other ways to get the client involved to actually see the deliverables in effect is a must. For this other mediums like a audio video recording of the working software could be provided. This may help in getting the client interested to actually work with the deliverables and suggest their feedback early on itself.




Addressing the most common misconceptions or mental roadblocks for the individual contributors

1. How can 3 weeks suffice for delivering some things

- As far as individual time line is concerned. This is not a big change. Developers in Watefall model also have tasks assigned for 1/2/3 or max 4 weeks. Agile is all about changing the developers mind set from tasks to deliverables. As the developers role changes from completio n
of tasks to deliverables, they become responsible for the deliverables. In this sense they are more productive and start thinking from what really matters to the customer.

2. Daily Stand ups or Scrums - What a waste of time?

- Developers or QA testers wish to be more productive and they perceive meetings as necessary management evils. In case of Agile, the meetings are focused for individual contributers and are meant for individual contributers to provide feedback, status and put forth their roadblocks. Daily scrums are not only status update meet to report to the lead, but to provide possible risks seen by the individual contributors and corrective planning to allow individual contributor to be more productive. This is also the place to change priorities based on the daily situations

3. Updating Status on Wiki - We meet daily then why this additional overhead.

- The Status update on Wiki helps two purposes
a. Tracking Progress
b. Acts like a record, that can be used for future estimations.

Instead of shooting a email (which is hard to track), updating a wiki page, takes the same amount of time.


4. TDD works only in Theory

- Most of us acknowledge TDD is helpful, but most of us again would not take dedicated effort in that Direction. TDD (Test Driven Development) even though is easier said than done, the benefits of TDD against not doing it (as it requires time and effort) is way more than the consequences of not having TDD.
One misconception with TDD is that people think that TDD has to be implemented for even existing code. Writing TDD for existing code/legacy code is some what a non feasible operation. Instead the idea is to have strong integration test cases for existing/legacy code and follow TDD for the new development you would do.

Agile Story - Scrum Panchatantra

Effectively executing Daily Scrums
Instead of reading one more article on Agile, let's see conversation that takes place in an Agile team during their Daily Scrums.
Let me introduce you to our Agile team under observation.

	King Frog - Agile Lead
	Tom - Agile Developer
	Missy - Agile Developer
	Hog - Agile Developer

---

10:30 a.m : Day begins .....

	: Let's start with our Daily Scrum
	: Who would like to start?
	: I would! Yesterday, I completed test cases and implementation for my XML configuration module. Today I plan to integrate it with the system. I do not have any road blocks. Basically my world rocks!
	: I was supposed to work on the Mysql DAO module, but I got stuck with a Mysql transaction problems. I have written to the Mysql forum, I expect a resolution by today. This means by yesterday's task of integration with system does not complete and I will have to work on it today also.
	: Ohh!! that means I can not start with my service layer. Well I wrote the interfaces for the service layers yesterday and today I wanted to write the implementations, based on Mysql DAOs provided by Hog. That means I can not work on what I planned for today and tomorrow :(.
	:So do you have any thing else on plate, which can be done in 2 days time?
	: Well, yes indeed, I was coming up to that point. I was planning to write client code for my service layer. I was to myself write a stubs for the Mysql DAO. This will help me test the client code also. I was planning this at a later time, but looking at the situation now I can very well continue on that task for today and tomorrow. /my immediate plan would be : Today I work on the DAO stubs and tomorrow on the implementing and testing client code for my service layer.
	: Good to know, you yourself could plan out things for you
	: Well that's what I have learnt working in Agile for a year. I know I have to contribute deliverables instead of just doing my tasks. I also know I am responsible for it.
	: Great!! My turn now, Yesterday I did code review for Tom and wrote test cases for Hog (in pair programming). Today, I am preparing the deliverables which we will demonstrate to the client in Tomorrow's call.
	:But the Final Delivery is months ahead, What's the point in doing a demo now?
	:This way we will know early whether the client approves these features, if yes great. Even if there are some changes, it won't cost us so much at this course of time. In the worst case if the client doesn't want a particular feature to be put in at all (after getting a feel of it), only 1-2 weeks of work is wasted.
	: So we have the meeting with the client tomorrow? but I heard that he is out of town and won't be available for tomorrow's meeting.
	: Ohh! yes I remember now. Well in that case, let me send him a audio video recording of the demonstration. This way the client would be up to date on the most recent deliverable. Also, I will reschedule the meeting some other day in this week itself. Getting a feedback from the him on our deliverables is very important for our Agile Story to succeed. Lets get started on our work, Team!! Ribbet !!

Did you observe?
1. The conversation indicates the team's approach is bottom up
2. Changing prioritites is accepted in a very positive way
3. Individual contributors play a bigger role, than just focusing on one's own task.
4. Every one is watchful for risks coming up from dependencies, also every one seems to be able to come up with mitigation plans
5. Client involvement is on a high priortity
6. Every one knows what every one else is doing

Myths about time and material model

Myth 1 – Iterative product development using agile methodology must be done using the T & M model. “Fixed bid agile” is an oxymoron.
T & M has certain intrinsic inefficiencies listed in the myths below. It works better for outsourcing work to “body-shops” than to the tech savvy providers of product development service. It is possible to do agile development in the fixed bid model using the first iteration to elaborate requirements and estimate costs. DSDM ( www.dsdm.org ) which is one of the agile methodologies prescribes this too.

Myth 2 - Fixed Bid model can’t whereas the T & M model can address loosely defined requirements which is the case with most of the product development work.
Nothing can be more untrue than this. Most of the customers and product managers know most of what they want when they decide to approach the developer. Many of them have elaborate requirements document covering most of the core functionality to be delivered. The developer can estimate and submit a fixed bid on the basis of such a document. Its true that requirements change and estimates need to be revised and the requirements document becomes outdated. But having an outdated document and an initial estimate is better than not having any document or estimate.

Myth 3 – Customers own the team and the IP held by the team-members. Team member’s tacit knowledge is more valuable than explicit knowledge stored in the document form.
Agile gives more importance to people over processes and working code over documents. But relying on people as the only way of holding IP is dangerous particularly when you are using off shore teams where factors such as attrition and low loyalty and low experience need to be accounted for. Teams must maintain documents that give insight into the code being developed or else it will be difficult to induct new members into the team.

Myth 4 – Why spend time on elaborating requirements, design and delivery plan as required in case of the Fixed Bid model? Requirements change; thus making the design documents outdated and throwing the delivery plans off course.
Design documents not only record what is going to be delivered in the code but also force the developers to organize their thoughts. Similarly not having a plan with milestones and completion dates is not a good idea. Over all management and cost control would be difficult without a plan. Design and plan documents provide the basis of comparison to estimate extra efforts required when the requirements change. Story point based flexible plan with no completion dates can lead to “gaming”.

Myth 5 – Delays happen mainly due to the phenomenon of “requirements creep”; hence customers must allow teams to postpone part of the time-boxed deliverables to the next sprint – in other words, customers pay for the delay.
Developers should share the risk of such delays too. Its the developers’ responsibility to extract requirements in the first iteration by asking the right questions. Quick methods of estimation such as “Planning Poker” lack the opportunity for product owner to go back to business analysts and other customers for answers to some of the questions posed by the developers. Time boxing prescribed by the agile model is possible only when enough effort has been taken on elaborating the requirements. Leniency on what is delivered in each sprint leads to inefficient utilization of development resources and hence it should be avoided. There should be some restriction on when and how much to re estimate.

Myth 6 – Test Driven Development. Unit tests can always be written before code and they serve as a substitute for an elaborate requirements document
Many a times developers can’t think of a test before they write the code. By their very nature developers think of “how things work” unlike the testers who think of “where things can go wrong”. Unit tests coverage is rarely 100%. Developers decide not to write unit tests for certain functionalities under extreme time pressure. Unit tests can become outdated just like design documents and are even harder to maintain.

Synerzip's Blog Site Created

Synerzip launched its blog site.