************ [SUBRAMANIAM-2006], Chapter 1-3 *******************************************************

Software development it’s a dynamic, ever-changing environment. In software development, the requirements

and challenges that come up during your project development are your waves- never ceasing and ever-changing. Like

the waves, software projects take different shapes and pose different challenges depending on your domain an

applications.

Your software project depends on the skills,

training, and competence of all the developers in the team.

A successful developer is the one with (technical) fitness,

balance, and agility. Agility means being able to quickly

adapt to the unfolding situations.

Agile is an approach that emphasizes people, collaboration,

responsiveness, and working software. The practical

emphasis of development shifts from a plan-based

approach to a more natural, continuous style.

You don’t leave testing to the end of the project. You don’t

leave integration to the end of the month or stop gathering

requirements and feedback as you being to code. You

continue to perform all these activities throughout the life cycle of the project. [Work progresses in iterations].

Unlike Crisis management, with agile methodology you want to tackle small problems while they are still small, explore

the unknown before you invest too much in it, and be prepared to admit you got it all wrong as soon as you discover the

truth.

Agility works only when you adopt a professional attitude

toward your project, your job, and your career. In agile

teams, the focus is on outcomes; fixing the problem instead

of affixing the blame. Only by understanding the process, you can begin to make changes effectively. Don’t code in

isolation.

Two techniques to prevent opaque code

Code reviews not only help make the code

understandable but they are also of the most effective

ways of spotting bugs.

Unit testing helps you naturally layer the code into

manageable pieces, which results in better designed,

clearer code.

Negativity kills innovation. When having a discussion:

Set a deadline.

Argue the opposite.

Use a mediator.

Support the decision.

Criticize ideas, not people.

Aside of keeping yourself up-to-date, you’ll need to let go of old, outdated approaches as well. How to keep up:

Learn iteratively and incrementally.

Get the latest buzz.

Attend local user groups.

Attend workshops or conferences.

Read voraciously.

Learn the new; unlearn the old. When learning a new technology,

unlearn any old habits that might hold you back. Question until you

understand.

Tackle tasks before they bunch up. It’s easier to tackle common

recurring tasks when you maintain steady, repeatable intervals

between events.

************ [SCHWABER-2004], Chapter 1*************************************************************

Scrum is devised specifically to wrest usable products from complex problems.

Who is the Scrum Master? Is the Scrum project manager who heads the Scrum project? Provides leadership, guidance,

and coaching. Responsible for teaching others how to use the Scrum process to deal with every new complexity

encountered during a project.

Scrum controls the process of software development to guide work toward the most valuable outcome possible.

Defined process control is a process that repeatably will produce acceptable quality output.

Empirical process control is when process control cannot be achieved because of the complexity of the intermediate

activities.

Visibility > those aspects of the process that affect the outcome must be visible to those controlling the process

Inspection > the various aspects of the process must be inspected frequently enough that unacceptable variances

in the process can be detected.

Adaptation > If the inspector determines from an inspection that one or more aspects of the process are outside

acceptable limits and that the resulting product will be unacceptable, the inspector must adjust the process or

the material being processed.

Complexity in Software Development: Requirements, Technology, and

People.

Stakeholders: those with an interest in the software and how it works.

From the image, the intersection of requirements and technology defines

the total level of complexity of the project.

Scrum addresses complexity of software development projects by

implementing inspection, adaptations, and visibility requirements of

empirical process control with a set of simple practices and rules.

At the start of an iteration, the team reviews what it must do. Then

selects what it believes it can turn into an increment of potentially

shippable functionality by the end of the iteration. The team is then

left alone to make its best effort for the rest of the iteration. At the

end of the iteration, the team presents the increment of functionality

it built so that the stakeholders can inspect the functionality and

timely adaptations to the project can be made.

The heart of Scrum lies on iteration.

Roles in Scrum

Product Owner > responsible for representing the interests of everyone with a stake in the project and its

resulting system. Product Owner gains funding by creating project’s initial list of requirements called ‘Product

Backlog’, return on investment objectives, and release plans. He should use the product backlog to ensure that

the most valuable functionality is produced first and built upon.

Team > is responsible for developing functionality. Teams are self-managing, self-organizing, and cross-

functional. They are responsible for figuring out how to turn Product Backlog into an increment of functionality

within an iteration and managing their own work to do so.

Scrum-Master > responsible for the Scrum process, for teaching Scrum to everyone involved in the project, for

implementing Scrum so that it fits within an organization’s culture and still delivers the expected benefits, and

for ensuring that everyone follows Scrum rules and practices.

All work is done in sprints. Each sprint is an iteration of 30

consecutive calendar days. Each sprint is started with a Sprint

Planning meeting, where Product Owner and Team get

together to collaborate about what will be done for next

Sprint. These meetings are time-boxed.

Every day, the team gets together for a 15 minute meeting

called Daily Scrum (Standups), each member answers 3

questions: What have you done since the last meeting? What

do you plan on doing now and between the next Scrum

meetings? What impediments stand in the way of you

meeting your commitments to this sprint and project?

Purpose of this meeting is synchronize the work of all team

members daily and to schedule any meetings that the team

needs to forward its progress.

Sprint review meeting is held at the end of the sprint. Team presents what was developed during the sprint to the product

owner and any other stakeholders.

After the sprint review and prior to the next sprint planning meeting, Scrum Master holds a Sprint retrospective meeting

with the team. Team should review, within the Scrum process framework and practices, its development process to make

it more effective and enjoyable for the next sprint.

Scrum artifacts:

Product Backlog > Consists of Backlog Description, Initial Estimate, Adjustment Factor, work remaining until completion.

Burndown chart > shows amount of work remaining across time. Shows correlation between amount of work remaining

and the progress of project team in reducing this work. Intersection of these indicates most probable completion of work

at that point of time.

Sprint Backlog > Defines the work or tasks that a Team defines for turning the Product Backlog it selected for that Sprint

into an increment of potentially shippable product functionality.

Increment of Potentially Shippable Product Functionality > Must be potentially shippable, be thoroughly tested, well-

structured, and well-written code that has been built into an executable and that the user operation of the functionality

is documented, either in Help files or in user documentation. A ‘Done’ increment.