Code Unit Test First

This practise is also known by many other jargons like Test Driven Development, Test Driven Programming, Test First Design etc.

What is the underlying objective is to let you know that you need to avoid writing a single line of code till you have not written to test it. It is nothing but saying in a broader term that if the requirements are not clear the project will go down the drain. Now take this saying from your QA and apply to coding process. If you doesn't know how to test what you are coding it is actually same as saying I doesn't know what I am coding.

So if you know what you are coding you will be able to write a brief test first. And that will make your coding requirement clear which will enable you to focus on writing only what is needed.

Follow these basic steps

1) Find out what you have to do.

2) Write a UnitTest for the desired new capability. Pick the smallest increment of new capability you can think of.

3) Execute the UnitTest. If it succeeds, you're done; go back to step 1, or if you are completely finished, deliver the project.

4) Fix the immediate problem: maybe it's the fact that you didn't write the new method yet. Maybe the method doesn't quite work. Fix whatever it is. Go back to step 3.

A key aspect of this process: don't try to implement two things at a time, don't try to fix two things at a time. Just do one.

When you get this right, development turns into a very pleasant cycle of testing, seeing a simple thing to fix, fixing it, testing, getting positive feedback all the way.

Guaranteed flow. And you go so fast!

Try it, you'll like it.

Continuous Builds

Continuous Build is a very vital aspect of Agile Methodology. It helps you recover quickly and allows bugs to be discovered early. It also put focus on Continuous Integration which is a entirely different subject altogether.

The concept of Continuous build implies that the code should be checked out from the repository often and the test should be carried out frequently to ensure that the builds are stable. The interesting aspect of this is to let all stake holders know that no bugs are getting committed into the build. The purpose of Continuous Builds can be achieved only if your code has high test coverage.

Carrying this task manually can be a big pain so if you rely on tools like JUnit to provide testing automation CB can be achieved fairly easily with the help of other tools like Hudson, Continuum etc.

These tools provides lot of Metrics and information, mainly about the changes in repository (CVS / SVN etc) since the last build. Who did the commits and for what reasons. Whom to notify if the build fails etc.. And these are important business directives for any project. As you can read all quality manuals and they will say bugs point out early in the project life cycle can save big bucks later..

Hudson and Continuum are two open source software which are very light weight and can be setup for most of the projects very quickly.

Agile for Quality Assurance

Today I will talk about one of the most difficult topic faced by any Project Manager, you got it I am talking about Quality Assurance. Matrix and Number is agile are quite tricky and have to be dealt separately than a normal Project Matrix. I faced it when my company was preparing for CMMi L5 audit and the auditor didn't knew how to deal with a Agile project. He kept asking stupid questions and I kept giving him Agile answers and after rounds of audit I realize how to fix the problem. Here what you can do but before that let me explain Agile Matrix which can be really really useful to calculate.

Iteration: One iteration is a few set of days under which team will try to achieve predetermined set of goals. One iteration can be anywhere between 1 week to 4 weeks. A standard meaningful iteration will be of 2 weeks . Depending upon your overhead you can stretch or suppress the iteration.

Velocity: Velocity is a quantitative unit which is calculated in person work hour and reflect the amount of work team has either done or planned to do in one iteration.

Assuming the estimates are done by Planning Poker or any other estimation methodology when you sum up all the numbers of units for all stories you have included to finish in the current iteration you will get Estimated Velocity.

When you add up all the available man hours for the team members participating in that iteration you will get Available Velocity.

When you add up all the estimated units of work in the stories considered done (100% done and not 99% or less) you will get Actual Velocity. Now thats strange why we cannot considered the estimates of the stories which are almost done and the answer is very simple, you will not deliver a story to the client unless it is 100% done and not when it is almost done. So what you cannot deliver to the client it is not considered done.

This post will continue with further details...

Implementing Agile in Agile Manner

I was attending SCRUM meeting with my team and normally it is followed by a 5 min TIDBIT session by anyone on a round robin basis. One of my team member raised a very good point, he was giving example of how we have successfully implemented Agile in our team. And he pointed out that we have brought in incremental changes. That means we have implemented Agile in the Agile way. We didn't rushed into things we took our time and we moved slowly bringing changes with each iteration.

Here in this article I will explain the manner in which we adopted things and it worked :). We have done in slow steps, the first one was adopting the basics. We started with :
1. SCRUM meetings: We didn't used the white board at this point, but we concentrated on sharing work details with each other (What we did in last 24 hours, What are our plans for next 24 hours, and roadblocks in case we have not achieved the promised objectives)
2. Pair Programming: We started with the practise of Pair Programming and Sharing sessions.

Once these resulted in better trust and self accountability, we moved to next step and introduce some XP practices like:
3. TDD: Test Driven Development
4. Testing Automation: We introduce tools like Watij (Web Application Testing In Java)
5. Continuous Builds: This resulted in tight integration. We used a software called CruiseControl for this purpose.

As and when we started getting results out of it, we moved one more step. Here we introduced
6. Simple Sprint & Product Backlogs: To track all the user stories we were working on.
7. TidBit sessions: 5 Minute session immediately after SCRUM to introduce team sharing.

This was enormous and by this time team has already started feeling the Agile. We took one more step:
8. Improved our Product & Sprint: Improved format to generate Velocity, Put up some Definitions of Done :0).
9. Iteration Plan Meeting: To ensure that we are carefully planning our activities.
10. Sprint Demo: Where developers used to demonstrate the work they have done during the spring in a already agreed upon method.
11. Retrospective Meeting: Meeting that starts after our Spring Demo to find out the good things we did in this Sprint and should be continued and the things that should be removed from the Sprint immediately.

That's it. We do make small changes to these process which we follow. But overall we implemented Agile in Agile manner. :)

Scrum Unplugged

What is Scrum?

A variation on Sashimi, an "all-at-once" approach to software engineering. Both Scrum and Sashimi are suited best to new product development rather than extended development. Sashimi originated with the Japanese and their experiences with the Waterfall model. They had the same problems with the Waterfall model as everybody else, so they adapted it to suit their own style. Realizing that speed and flexibility are as important as high quality and low cost they reduced the number of phases to four -- requirements, design, prototype, and acceptance -- without removing any activities, which resulted in overlap of the Waterfall phases. Then they made the four phases overlap. (Sashimi is a way of presenting sliced raw fish where each slice rests partially on the slice before it). Other companies took Sashimi one step further, reducing
the phases to one and calling it Scrum. (A scrum is a team pack in Rugby, everybody in the pack acts together with everyone else to move the ball down the field).

Applying Scrum

For each Waterfall phase there are a pool of experienced people available, form a team by selecting one person from each pool. Call a team meeting and tell them that they have been selected to do an important project. Describe the project, include how long it's estimated to take, how much it is estimated to cost, how it is expected to perform, etc. Now tell them that their job is to do it in half the time, with half the cost, twice the performance, etc. Tell them how it's done is up to them and explain that your job is to support them with resources. Now leave.
Stand by, give advice if it's requested, and wait. Don't be surprised if a team member thinks the whole thing is insane and leaves. You'll get regular reports, but mostly you'll just wait. At somewhere around the expected time, the team will produce the system with the expected performance and cost.

How does Scrum work?

The first thing that happens is the initial leader will become primarily a reporter. The leadership role will bounce around within the team based on the task at hand. Soon QA developers will be learning how requirements are done and will be actively contributing, and requirements people will be seeing things from a QA point of view. As work is done in each of the phases, all the team learns and contributes, no work is done alone, the team is behind everything. From the initial meeting, the finished product is being developed. Someone can be writing code, working on functional specifications, and designing during the same day, i.e. "all-at-once". Don't be surprised if the team cleans the slate numerous times, many new ways will be picked up and many old ways discarded. The team will become autonomous, and will tend to transcend the initial goals, striving for excellence. The people on the team will become committed to accomplish the goal and some members may experience emotional pain when the project is completed.

Why does Scrum Work?

The basic premise is that if you are committed to the team and the project, and if your boss really trusts you, then you can spend time being productive instead of justifying your work. This reduces the need for meetings, reporting and authorization. There is control, but it is subtle and mostly indirect. It is exercised by selecting the right people, creating an open work environment, encouraging feedback, establishing an evaluation and reward program based on group performance, managing the tendency to go off in different directions early on, and tolerating mistakes. Every person on the team starts with an understanding of the problem, associates it with a range of solutions experienced and studied, then using skill, intelligence, and experience, will narrow the range to one or a few options.

Keep in mind that it can be difficult to give up the control that it takes to support the Scrum methodology. The approach is risky, there is no guarantee that the team will not run up against real limits, which could kill the project. The disappointment of the failure could adversely affect the team members because of the high levels of personal commitment involved. Each person on the team is required to understand all of the problem and all of the steps in developing a system to solve it, this may limit the size of the system developed using the methodology.

Planning Poker (Time Estimations)

Time estimating using planning poker


Estimating is a team activity - every team member is usually involved in estimating every story. Why?

• As per Agile at the time of planning, we normally don’t know exactly who will be implementing which parts of which stories. Stories normally involve several people and different types of expertise (user interface design, coding, testing, etc).
• In order to provide an estimate, a team member needs some kind of understanding of what the story is about. By asking everybody to estimate each item, we make sure that each team member understands what each item is about. This increases the likelihood that team members will help each other out during the sprint. This also increases the likelihood that important questions about the story come up early.
• When asking everybody to estimate a story we often discover discrepancies where two different team members have wildly different estimates for the same story. That kind of stuff is better to discover and discuss earlier than later.

If you ask the team to provide an estimate, normally the person who understands the story best will be the first one to blurt one out. Unfortunately, this will strongly affect everybody else’s estimates.

There is an excellent technique to avoid this – it is called planning poker (coined by Mike Cohn I think).

Each team member gets a deck of 13 cards as shown above. Whenever a story is to be estimated, each team member selects a card that represents his time estimate (in story points) and places it face-down on the table. When all team members are done the cards on the table are revealed simultaneously. That way each team member is forced to think for himself rather than lean on somebody else’s estimate.

If there is a large discrepancy between two estimates, the team discusses the differences and tries to build a common picture of what work is involved in the story. They might do some kind of task breakdown. Afterwards, the team estimates again. This loop is repeated until the time estimates converge, i.e. all estimates are approximately the same for that story.

It is important to remind team members that they are to estimate the total amount of work involved in the story. Not just “their” part of the work.The tester should not just estimate the amount of testing work.

Note that the number sequence is non-linear. For example there is nothing between 40 and 100. Why?

This is to avoid a false sense of accuracy for large time estimates. If a story is estimated at approximately 20 story points, it is not relevant to discuss whether it should be 20 or 18 or 21. All we know is that it is a large story and that it is hard to estimate. So 20 is our ballpark guess.Want more detailed estimates? Split the story into smaller stories and estimate the smaller stories instead!

And NO, you can’t cheat by combining a 5 and a 2 to make a 7. You have to choose either 5 or 8, there is no 7.

Some special cards to note:

---

0 = “this story is already done” or “this story is pretty much nothing, just a few minutes of work”.

? = “I have absolutely no idea at all. None.”

å = “I’m too tired to think. Let’s take a short break.”

Extreme Programming Core Practices

The 12 “XP Xtudes” (Xtude is XP means ‘Attitude’) of Extreme Programming (XP) grouped into four categories

1. Fine Scale feedback

XP thrives on providing feedback at smaller intervals with higher frequency. This allows controlling deviation at the right time, since in software or any othe industry for that matter, once deviation starts happening it is dificult to control at the later stages.

• Test Driven Development via Programmer Tests (Unit Tests) and Customer Tests (Acceptance Tests/Automation Tests)
• Planning Game (Definition Iteration Objectives and playfield etc)
• Whole Team (Onsite Customer + Programmer + Quality Team + Customer Team + Scrum Master + Product Owner)
• Pair Programming ( two engineers participate in one development effort at one workstation)

2. Continuous Process rather than Batch

• Continuous Integration (Integrate Continuosly and keep the check using Nightly Builds)
• Design Improvement (Refactor Mercilessly)
• Small Releases (Release Often)

3. Shared understanding

• Simple Design (Do Simple Things, You Arent Gonna Need It, Once And Only Once, Simplify Vigorously)
• System Metaphor (XP way of defining the Architecture)
• Collective Code Ownership (Multiple People working on same code)
• Coding Standard or Coding Conventions (Uhh!! you know what it means, dont you?)

4. Programmer welfare

• Sustainable Pace (original name: Forty Hour Week)

YAGNI

YAGNI perfectly sums up XP (Xtreme Programming). Here is why and how.

"You Arent Gonna Need It" (often abbreviated YAGNI) is an Extreme Programming (XP)practice which states:

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

Even if you're totally, totally, totally sure that you'll need a feature later on, don't implement it now. Usually, it'll turn out either

1. You don't need it after all, or
2. What you actually need is quite different from what you foresaw needing earlier.

This doesn't mean you should avoid building flexibility into your code. It means you shouldn't overengineer something based on what you think you might need later on. There are two main reasons to practise YagNi:

• You save time, because you avoid writing code that you turn out not to need.
• Your code is better, because you avoid polluting it with 'guesses' that turn out to be more or less wrong but stick around anyway.

A scenario that explains the practices:

---

You're working on some class. You have just added some functionality that you need. You realize that you are going to need some other bit of functionality. If you don't need it now, don't add it now. Why not?

"OK, Mohan, why do you want to add it now?"
"Well, Rahul, it will save time later."

But unless your universe is very different from mine, you can't 'save' time by doing the work now, unless it will take more time to do it later than it will to do now. So you are saying:

"We will be able to do less work overall, at the cost of doing more work now."

But unless your project is very different from mine, you already have too much to do right now. Doing more now is a very bad thing when you already have too much to do.

And unless your mind is very different from mine, there is a high chance that you won't need it after all, or that you'll need to rewrite or fix it once you do need it. If either of these happens, not only will you waste time overall, you will prevent yourself from adding things that you do need right now.

"But Rahul, I know how to do it right now, and later I might not."
"So, Mohan, you're telling me that this class you're writing is so complex that even you won't be able to maintain it?"

Keep it simple. If you need it, you can put it in later. If you don't need it, you won't have to do the work at all. Take that day off.

YAGNI in the context of the other Extreme Programming practices

You have a Release Plan: each User Story has been assigned to an Iteration where it will be done. Under the current Iteration Plan, you are working on an Engineering Task that you signed up for, in support of one of the Iteration's User Stories. As always, you have signed up for as much Ideal Programming Time as your Load Factor indicates you can accomplish.

You are evolving the system to have the new functionality required by the User Story, defined in the Engineering Task. You add capability to any class we need to, directly growing from the requirement. If you find yourself writing duplicate code, you refactor to eliminate it, even (perhaps) adding an abstract class, or making a subclass, etc. You and your co-programmers always keep the code clean.

You're building a class, and suddenly you get an idea for a feature you could add to it. You don't need it right now, but "Someday we're gonna need ...", you say to yourself.

Keep in mind that you are employing other Extreme Programming practices that allow you to deal with the future when it happens. Collective Code Ownership allows you to change anybody else's code to give it the functionality you want. Refactor Mercilessly and Once And Only Once make it easier to understand the best way to add your functionality. Unit Tests help ensure that your added functionality won't break any past functionality. So if you do need to implement this feature in the future, it probably won't be much harder than it would be to implement now.

At this moment, you have a choice: continue working on what you signed up to do, or begin working on something you didn't sign up to do, and that isn't needed in this Iteration.

Therefore, tell yourself YAGNI. Set aside your thoughts and fears about tomorrow and get back to work on today. Without a clear use for the feature, you don't know enough about what is really needed. Spending time on it is speculative at best.

Once Upon a Time....

A Chicken and a Pig lived on a farm। The farmer was very good to them and they both wanted to do something good for him।
One day the chicken approached the pig and said, "I have a great idea for something we can do for the farmer! Would you like to help?"
The pig, quite intrigued by this, said, "of course! What is it that you propose?"
The chicken knew how much the farmer enjoyed a good healthy breakfast। He also knew how little time the farmer had to make a good breakfast. "I think the farmer would be very happy if we made him breakfast."

The pig thought about this. While not as close to the farmer, he too knew of the farmer's love for a good breakfast. "I'd be happy to help you make breakfast for the farmer! What do you suggest we make?"
The chicken, understanding that he had little else to offer suggested, "I could provide some eggs."
The pig knew the farmer might want more, "That's a fine start. What else should we make?"
The chicken looked around...scratched his head...then said, "ham? The farmer loves ham and eggs!"
The pig, very mindful of what this implied, said, "that's fine, but while you're making a contribution I'm making a real commitment!"
Chickens and PigsOn Agile projects the term Pig has come to describe all the developers, designers and testers who commit to the actual work। The term Chicken is applied to everyone else who make intellectual contributions but do not commit to any work।

Note: Images are borrowed from other sites*