Difference between Agile and Scrum

It seems lot of  people are confused about the difference between agile and scrum. In this article i will describe the difference in very easy and graphical way. look at the following images. Agile is a kind of Umbrella of framework and methodologies. 

Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams.

scrum is one of the agile framework.

Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value

Conflict Resolution : Importance and techniques

Imagine going to work everyday and facing a colleague who does not respect you or having to work with someone who was constantly undermining you decisions.Would it make getting up in the morning and heading off to work a motivating experience?

Conflict is an inevitable part of project work.

 Whenever people come together to solve problems, there will be differences of opinion and competing interests. Some degree of conflict is healthy , to ensure that ideas are sufficiently tested before adopted. However , we need to make sure the conflict does not escalate beyond healthy skepticism and friendly teasing, or will end up with a negative and repressive team environment.

Creating an environment in which people can use conflict constructively is a key part of successfully engaging stockholder in a project. We must watch for instances when conflict moves beyond normal, healthy debate and become destructive and harmful to the relationship and the team.


Speed B. Leas offer a framewod that helps us judge the seriousness of a conflict and better understand teh escalation path from Level 1 (Problem to Solve) to Level 5(World Ward).

Understanding Lea's framework on the stages of conflict can help us look at a situation more objectively, moving past our own judgement to see what is really happening. Identifying the conflict stage can also help us determine what actions we should take or what tools or techniques may work in the given situation.


Therefore, when a team is in a state of conflict, we should first take some time to observe the conflict and make sure we are seeing both sides of the dispute. not just jumping in with a knee-jerk reaction.
We need to allow time for proper observation, conversation, and intuition about the the issues before taking action. This means at-first we simply listen to the complaints, without immediately trying to solve them. we feel the energy of the group, and assess the conflict levels. We look for glances, eye rolling, and words that halt conversations to ascertain if the conflict is out in the open , or if it is playing in the out in subsurface snippets.

One way to assess the level of conflict is to focus on the language  the team uses and then compare the conversation against the 1 to 5 conflict scale. let's look at the language used at the level in more details.

Standard Operating Procedures (SOP)

Agile Standard Operating Procedures

1. Create product backlog with User Stories

2. Designate the following roles:
        Product Owner
        Scrum Master
        Team Members

3. Conduct Sprint Planning Meeting

4. Daily Scrum with available team members

5. Weekly Code Review meeting including
        Storytime to groom Pivotal Tracker
        Retrospective “Inspect & Adapt” for team

6. Weekly Sprint Review with product owner

7. Developer Best Practices

• Every new idea => document user story => vote number of points

• Only choose work from voted upon features or chores
• Be accountable for delivering story. Pair program on a problem you can't solve on your own
• Person submitting pull request is different from person approving the request
• If you are pairing, ping pong code
• If you are working on a feature that does not need a pull request, when finished with tasks/chores:

               Check off each task finished in Pivotal Tracker as soon as completed.
                Mark feature finished when ALL TASKS it contains are finished.
               Team will check work at next scrum mtng.

http://www.agileventures.org/projects/codealia/documents/standard-operating-procedures-sop

Excellent FREE resource for learning Domain Driven Design

If you asked developers what books they should read, most would (or should) include Domain Driven Design by Eric Evans.

Why is it important?

The patterns and practices outlined in this book will help you develop more successful software solutions.

How?

Eric Evans shows how you can improve communication with your customer (by doing things like developing a ubiquitous language), implement agile practices and create maintainable solutions which follow good software development principles.

One of common criticisms of the book is that ‘it does go on a bit’.

The good news is that the folks over at InfoQ have come up with ‘Domain Driven Design Quickly’ which summarizes what Domain Driven Design is about.

The even better news is that it’s FREE if you register with InfoQ, which is no bad thing because it’s a fantastic resource with videos, presentations and some very good articles.

post ref : http://www.arrangeactassert.com/excellent-free-resource-for-learning-domain-driven-design/