Reading List..

I have been involved in transitioning two of the largest organizations (in the North America) to value driven project methodologies such as Agile, Scrum, and Lean. During these transitions, I have coached several teams, managers, and executives on Agile Practices and principles, and have often been asked for recommended reading list. I have accumulated a list of references that I often recommend my new teams read when starting their journey on Agile. Here is the list for your reference.

Books

Agile Project Management with Scrum (Schwaber)

User Stories Applied (Cohn)

Scrum and XP from the Trenches.pdf (Kniberg)

Scaling Software Agility (Leffingwell)

Agile Estimating and Planning (Cohn)

Implementing Lean Software Development: From Concept to Cash (Poppendieck)

Test Driven Development: By Example (Beck)

Agile Software Development with SCRUM (Schwaber)

Online References

Scrum Alliance

Being Agile is our favourite thing

Agile Manifesto

Agile Wikipedia

Mountain Goat Software

Jeff Sutherland NYC Spin

Scrum and XP from the Trenches

Agile Project Leadership

Agile Management

Ward Cunningham on the origin of the term Technical Debt

Agile Thoughts

Testers Shine on Agile Projects

Requirements Up Front

Agile Requirements

BSA Role

It’s Not Just Standing Up

Big Macs vs. The Naked Chef

Agile Has Crossed the Chasm

Constructive Disruption and Compromised Agility

Kanban in a nutshell

Learn from the experts: Blogs, RSS Feeds

Schwaber on Scrum

Agile Advice

Agile Alliance

Agile Management Blog

Implementing Scrum

Pages tagged with 'agile' on del.icio.us

Stevey's Blog Rants: Good Agile, Bad Agile

agile at google

The Planning Onion: Five Levels of Agile Planning

Shameless post: link to my blog

Unlearn what you have learnt

Delivering the W, One Game at a Time

Field of View

a quick introduction: What is Scrum?

Field of View..

Field of View is defined as the angular extent of the observable world that isseen at any givenmoment.

As we all know, in Agile, planning is a continuous process. We do not believe in big planning upfront; rather planning is a continuous process and we do planning at different layers, at different stages in the life of a project. Mike Cohn refers to these multi-layer planning as Planning Onion.

At different layers of this Planning Onion, the project team focuses on varying level of details at different stages of project.

At the inner most layer, the daily planning, team focuses on the particular day (What am I planning to do today? Are there any impediments?). So, at the inner most layer, we can say that our field of view is just that particular day, we focus on one day and thats about it.

The next layer is Sprint planning, often refered to as Iteration planning. The team is now expanding the full of view and now focusing on one iteration. Team's field of view is expanding from one day to couple of weeks (depending upon the length of the iteration.)

So as we move from the inner most layer to outer layers, the field of view is expanding. As you get to the inner layer the details become more and more clear.

If I put a flashlight in front of this planning onion, you will see that the light is brightest near the flash light at the inner most layers, and as we go the outer most layer the light becomes more and more dim, the details become hazy. So, with this flash light, you would still be able to see (kind of) the road map if you were looking far ahead but at the same time it would not give you lot of details.

Star Wars and Agile..

In the Star Wars movie The Empire Strikes Back, Luke tries unsuccessfully to rescue his X-wing fighter from the swamp. After some time, he gives up. He tells Jedi Master Yoda that lifting the fighter is impossible with the force, the new approach Yoda is trying to teach him. Yoda has these words of wisdom for him:

"You must unlearn what you have learned."

Scrum is no different! Like the Jedi force, the Scrum framework is conceptually easy; it's putting Scrum into practice that is difficult. In order for a team to be successful, the team members must unlearn what they have learned so far in their careers.

Check out my recent article for more details on what habits must be broken to succeed in Agile Adoption.

What is Scrum?

Recently, a friend of mine asked me "What is Scrum?"

I started thinking what is the best (and quickest) path to introduce a person to Scrum? So, I started my research for references; and here is a list of online resources that I feel can be used to get a quick familiarity with Scrum.

Enjoy!

Here are some more online resources:

• The Agile Elevator Speech
  
• Scrum in Five Minutes
  
• An Introduction to Scrum
  
• Scrum et al. - Ken Schwaber (who created Scrum) on Scrum at Google
• And, of course, if you are (American) football fan, you can read my article that draws similarity between The Partiots - a Football team and some of the Scrum practices.

Harvard Business Publishing and Agile..

I recently read an article from Harvard Business Publishing on "Why Good Projects Fail". As we all know, the failure rate for projects is very high; more than half of the projects fail! This is especially troublesome in Traditional Project Management as you would not know if the project is failing until it is too late (remember, one big bang delivery!)

In this Harvard Business Publishing, the author suggests using rapid-results initiatives in order to minimize and mitigate the risks of failure. What he means by that is "to use small projects designed to quickly delivery mini-versions of the big project's end results". Do you 'smell' Sprints here!?

He goes on to list several defining characteristics of this rapid-results initiatives approach such as:

* Results oriented (As we know, with each sprint, our goal is to deliver value to the Product Owner.)
* Vertical (Refers to Cross functional team)
* Fast (Refers to Sprints and Releases)

There are many parallels in this article and what we do in Agile landscape. Check out the article here to find out more details.

Product Backlog, Product Owner, and Business Value (BV)

As we all know very well, the Product Backlog (PB) is very critical artifact in Scrum and Agile. PB should be the central repository of all the work that needs to be completed in a Project. We capture all the work (as we know as of Today) in the form of Epics, Features, and Stories. The Product Owner (PO) would then be responsible for providing the priorities on them. The PO may also decide to use the Business Value (BV) to help him/her prioritize the Product Backlog.

While there is no explicit formula for Business Value, the Product Owner should be making implicit decisions based on his/her experiences. While assigning BV to Features and Epics, the Product Owner may consider some of the following criteria:

* What the team has accomplished so far?
* What the team can complete within the Release Cycle?
* Complexities
* Dependencies
* Impediments
* Market Size
* Market Timing
* Opportunity Cost

If you 'zoom' into these criteria and look at them closely, you will realize the first few criteria drive the Priority and Sequencing of the Feature and Epics. The last three, Market Size, Market Timing, and Opportunity Cost, are the ones that will drive the Business Value.

Google CEO on pair programming..

Recently, I read an article on Business Week. In this article Google CEO Eric Schmidt describes the simple principles that helps the company drive innovation.

In this interview, he mentions that the best programming team is a "telephone call," which is two people, you and I, programming together. Sounds familiar! He is describing the pair programming.

He goes on to mention that the second-best programming team is, everybody fits into a single room. All other variants are bad. Do I hear co-location here?

There you have it! Even Google CEO is promoting pair programming and co-location.