Agile Development

Traditionally the way software were developed is that the customer who approaches the software development says this is what i want and gives a thick document and the customer and developer would sign that off. The customer would sign that he now agreed this what gonna be done within the next 6 months. But unfortunately, it is impossible for a customer to envision everything upfront. So after a little bit of development, he might say "Actually that would have been called but unfortunately i didn't think about this so It hasn't been signed off. So we are going to add this in phase 2." So because of that the customer might end up with a product that it is not exactly what i wanted. So Agile development enables the developer to more agile and the customer actually. There is no upfront document. The customer can be more agile about requirements and any time change in requirements. Agile is all about embracing change. As we know software changes over time. Needs changes all the time and the agile addresses that big problem and makes possible to give the customer exactly what he wants.

Needs for Agile:1. Rapidly changing requirements.
2. Changing the environment.
3. Changing laws.
4. Changing people.
5. Mistakes on the initial planning stage.

How to start the Sprint 

Imagine it's the first day of your 2-week sprint (iteration, etc.), and you're eager to get started. Your burndown (or task list, etc.) has just 4 tasks:

Task	Estimate
1. Implement "Order Status" screen.	35 hours
2. Print username in system logs.	2 hours
3. Investigate clustering in Tomcat.	15 hours
4. Upgrade to newest version of GWT.	20 hours

The question is, then, how do you get started? What do you do on that first day? You've committed to completing all the tasks, so does it matter? Of course it does.

Two simple approaches are...

1. Start with the tasks that are most fun. "Investigating clustering" sounds interesting, so start with that! This makes for a more enjoyable sprint...at least for the first few days.

2. Knock off the low hanging fruit first, and get some quick gratification at the beginning of the Sprint. Just like some financial gurus say to pay off your lowest debts first, it's nice to build some confidence before you get to the tough stuff.

Honestly, I find it really tough not to use these strategies - I just naturally want to do the fun tasks or quick-wins first...but having lived through more than a few failed sprints, I've quickly learned better.

First, there are some tasks which other developers are depending on me for (e.g. "Upgrading GWT"), and so if I wait till the last few days to do this, I effectively hose my colleagues. Second, there are times when I don't finish all of my tasks (gasp!) - maybe I had to call in sick one day, or requirements shifted, etc. If I do the most fun tasks first, I may have left some high value tasks hanging.

So here are some more disciplined approaches:

3. Start with the task that has the most dependencies on it (either within my own task list or for other developers). This approach is the best for keeping you in the good graces of your team.

4. Find out from the business owners which tasks are the highest value and work from high value to low - that way if something doesn't get done, it will be less of a big deal. For example, the "Order Status" screen might be crucial to the business, but "Upgrading to GWT" is not as big a priority.

5. Dig into the task that is the most complex first, so you can identify and mitigate the biggest risks right away, and you'll have more time to address them during the sprint than if you waited to the end.

Now each of the last three approaches (which can be blended, of course), are significantly more disciplined than the first two, but there's still a problem...

Most developers (me included) typically like to work sequentially - complete a task, move on to the next one. I find this more gratifying (and less stressful), but not very effective. It's very possible that lingering within each of my tasks is some big gotcha, that needs time (i.e. calendar time, not hours of work) to be dealt with. For example, maybe there's some question about the "Order Status" screen that needs to be posed to a business owner, and that business owner is booked solid till Thursday. Or maybe investigating clustering requires the assistance of a sys admin, and he needs a week lead time. If I don't identify these dependencies early, I could easily put myself in a position where I can't complete my tasks.

Given this, I've found the most effective approach to starting the sprint is this...

6. On the first 2 days, take a spike through each of my tasks (similar to the XP concept), understand better the requirements, and pick out the tricky pieces that might require input from others. This may require writing some code, but not much. Once I have a good handle, at a conceptual level, of what each task entails, then I can use some blend of strategies 3, 4, and 5.

The biggest drawback to this approach is that on those first two days, I find myself barely burning any work down - because most of what I'm doing is asking questions and planning. After everything is in order though, I typically can roll smoothly through my work.

Additional material:

Websites:

1. https://www.scrumalliance.org/
2. https://www.scrumstudy.com/

Books

1. Fun retrospectives
https://www.dropbox.com/s/gym6tst8rc7lsxb/funretrospectives.pdf?dl=0

2. A bunch of pdf files:
https://www.dropbox.com/s/s6jpdgl001ge7gb/Agile%20Documents.rar?dl=0

Video tutorials List
https://www.dropbox.com/s/7terxxxfseqc0w1/Scrum%20Video%20List.xlsx?dl=0