Scrum Video Tutorials by Jeff Sutherland

Recently came across this amazing library of Scrum Videos. These videos are recorded as interviews with Jeff Sutherland, co-inventor of Scrum.    Jeff explains the concepts in these short videos in a crystal clear way. 

Enjoy the videos by visiting this link

Top 5 Articles from 2011 and New Year Wishes

Being in Australia, just started our new Year 2012.  Looking back at 2011, glanced at Google Analytics to see the popular articles. Out of nearly 2 dozen or so articles I have posted  since the last 12 months, almost all articles have more than 3 digits page views.   Thought would shortlist the most popular ones and share it with the readers.

 

I have edited the Top 5 articles into a clean brochure kind of PDF document.  Feel free to download them from here.

Wish you all a very happy new year and warm wishes for the year 2012

Photo courtesy: dreamtime.com

Definition of Ready template for teams - A free one for download

Have you come across teams struggling in iterations bombarded with surprises ? I have seen many times. 
Teams and POs  concentrate mostly on “Definition of Done”  by keeping the end in mind, which is good. However, it is also important to evaluate the readiness before entering the iterations.
As we all know, Garbage in – Garbage Out,  if the team starts Sprints/iterations with weak information, the output produced too would be of poor quality.

 

In one of the case studies, Team didn’t have the acceptance criteria for all the user stories. But they were convinced by the PO that, it would be detailed out during the iteration. The team signed up and  incidentally, things didn’t go as per the plan. The team ended up building a few stories with incomplete features.

Imagine having a robust checklist which is used as the gateway into a Sprint. Noting is allowed into the Sprint fort without getting clearance from this gateway.    This gateway is nothing but Definition of Ready(DoR) Checklist.

 

The Definition of Ready checklist will have the list of items that need to be in place before stepping into the iteration. 

Some examples include,

* Clearly defined User stories are one of the key items to be ready before the iteration planning meeting
*  A healthy backlog with enough stories for atleast 2 iterations
*  Healthy Dev and Test environments
*  Availability of team, etc

A few points to remember

* The DoR checklist is a living document and should be kept upto date with the learning from each iteration. 
* Scrum  Master could own this document. 
* The list should have the inputs from not only the Scrum Team but from Product Owner(s) ,Scrum Master, Business Analyst and other stake holders. 

I have created a DoR template with typical items needed to kick start using it. This is not an exhaustive list, but gives you a feel of DoR items.  Feel free to download the PDF version of the template from here.   This is free to use as a starting point for building DOR checklist.

Secret recipe behind Amazon’s software development methodology

Have you ever wondered What is the secret behind some of the successful product companies ?  

Have you ever wondered what methodology do these companies follow in software development ?

Right now, my favourite companies include  Amazon, Apple, Facebook and Google. I don’t miss a chance to read information about their org structure, software development process, recruitment process, etc.

In this post, I would be uncovering Amazon’s strategy while building a product.  Before Amazon starts building any product, they write the following documents  Press Release, FAQ, Customer Experience and User Manual.  
Press Release is a short 2 or 3 paragraphs note about the product as though it would be published in a newspaper.
FAQ  as the name itself implies covers the frequently asked questions about this product. Questions with What, How and Why trigger thoughts for the stakeholders to see missing pieces of information.

Customer Experience this document captures the stories about customer user experience. This could happen through Mock-up screens or use cases.
User Manual  covers the way the product to be used. 

Following picture depicts this process.

They don’t spend months together in writing these documents. These documents are crisp and cover the information on a need basis. They involve all the relevant team members from technology, and business while preparing these documents.

The benefit of this process is, it provides a greater clarity around the product that needs to be built and avoids the confusion.
I feel that these documents could also be used as:
        a. Training manual for new joiners 
        b. Requirement spec  

Do you have stories or secret recipe to share from successful companies ?

How to be an effective Product Owner ?

Product Owner (PO) plays a pivotal role in Scrum projects. As the saying goes “Garbage in – Garbage out”, if the PO provides poor quality requirements, the developers churn out equivalent code, and in turn an inferior product.  We keep seeing a lot of failed products in the market. If we track back and identify the root cause of these products, it would have some connection to the requirement gathering phase.

In Scrum, the product Owners own the backlog. It is extremely important to do due diligence while choosing a PO. Larger organizations running multiple projects, and many releases find it difficult to identify good product owners for all projects. They end up picking and sending any one with some knowledge of the domain and tagging them as POs. This is dangerous and inefficient way to fill such a key role.

Based on my past coaching experiences on several  Scrum projects, I have found several factors influencing the PO role. I have put together these factors in the form of a picture. Scrum Projects will be very effective if the following points are kept in mind while identifying a suitable person for the PO role.

 

 

Following brief explanation is not in any specific order

1. Lack of Agile/PO training: It is important for designated Product Owner to have undergone Agile, Scrum and Specifically PO trainings.

2.  Organizational Complexity:  Large organizations with several groups, sponsors and IT departments creates their own complexity .  I am sure experienced coaches working with large multi national corporations would vouch for this.

3. Lack of domain knowledge: There is nothing worse for a PO to be leading this role with no proper domain knowledge.

4. Leadership Style and Personalities: Even though no Scrum book talks about this point, I feel it is very important for a PO to be

     * Pragmatic
    * Ability to convey the goal and vision
    * Not getting irritated with questions
    * Empathetic
    * Collaborative rather than Command & Control

5. Not enough Authority:  POs with inadequate authority in making decisions, not only leads to waste due to sign off processes, but also creates frustrations among POs.

Are you aware of other factors impacting effectiveness of PO ?

Who should be blamed for a failed Scrum Project ?

An interesting discussion about  Who should be blamed for a failed Scrum Project ? in Scrum Practitioners forum  made me to write this short article.    

As I started putting the comment together to respond, I was getting more questions than answers.

Here, are some of my thoughts:

• Personally, I feel that as long as there is a blame game culture around, the weakest one gets the blame. My experience has been that being more vocal one could push away blame easily.
• As far as I know, there is no democratic debate to nail down the culprit, its all about witch hunting.  Following paragraphs provide additional reasoning.
• Wearing a purists hat, Trust is the foundation of all the work. Whether it is Software or non-Software work, Whether one follows Waterfall, Six Sigma or Agile. Failure is a hall mark of Mistrust.
• Failure will not happen just like that one day. It is the culmination of issues built up over a period. The issue keeps accumulating every hour/every day. Scrum Meetings, Retrospectives were recommended to catch the issues at an early stage before it leads to FAILURE. With the context of Scrum in mind,
Here is the list of few more questions one should ask:

• Did the team raise any issue at all during the Scrum Meeting ? If not, why not ? 
• If, they had raised the issues, did the Scrum Master track it ?
• Did Product Owner attend the Scrum Meeting regularly ? Did he/she catch the issues ?
• Are the team afraid of bringing out the issues upfront ? Who is influencing this behaviour?
• Did retrospective happen regularly, and issues were brought out during retro ?
• Did stakeholders/Sponsors attend the retrospective ? Did they show any interests in the “What is not working well” column ?
• If the team is not following any of the Scrum recommended practices, project itself is initiated with the wrong footing. Should someone be blamed for this ?


Answers to the above questions evoke a different set of answers and emotions.

Before ending this article, let me share a good quote 
As Karyn puts it:
Blame gives people an easy out. If it’s not your fault then it’s not in your control. If it’s not in your control then there is nothing you can do about it. If there is nothing you can do about it, then you don’t have any obligation or any need to try to change. If you can blame someone else, somehow, it lets you off of the hook

Duration of Iteration 0

Iteration 0 is typically the duration between the initial “Discovery” and “Evolve Phase” of a software project.  As such, there is no formula or a number to determine the iteration 0 duration, which suits all the projects.

I use the following check list to decide the duration

1. Duration of the project :  If the duration of the project is small, then one should be cognizant of spending a lot of time on Iteration 0. 
For a 6 months or 1 year project 1 week of  Iteration 0 should be good enough.

2. Pending items : These are the items which could negatively impact starting of Evolve phase.  Based on my coaching experiences on many projects, I have managed to create a checklist of things typically needed to start the actual development.  

Some of them include:
     a. Development and testing environment readiness (licenses, Hardware, etc)
     b. Is Backlog healthy and ready to support one or two future iterations
     c. Do we have the team ready with the right skills
     d. Does the team need any training before they start the coding
     e. Does the team have all necessary tools to start the project
    
If  the team does not have basic things, then there is no meaning in starting the development and waiting in between.

3. Did it exceed > duration  of 1 iteration ?
The iteration duration varies from project to project, and stays between 2 – 4 weeks (max) in most of the good Agile projects.
I always tend to suggest that the Iteration 0 should not exceed duration of one iteration.  In my world, if Iteration 0 needs more time to finish then there are more challenges ahead for this project.

Notes from Lean workshop - Vol 2

http://www.techno-science.net/?onglet=articles&article=3&page=3
The Empire State building construction is  a classic example of  application of Lean principles.  It was built within budget and in time.

Here are the few success factors that lead to this achievement.

 

1. Team work: Owner, Architect and the Builder. 

In a software development scenario the above team could be compared to the Sponsor, Architect and developers.   Notice that there is no product owner.

Mary, recommends that product lead should have both technology and business acumen. This is opposed to the concept of Product Owners, who are purely coming from business background.

2. Builder was highly experienced in building such large scale systems.

3. Identifying and focussing on the key constraint: Material flow. 

4. The design was based on less coupled systems

 

5. Every one was made aware of the key constraint that was the cash flow.  Every day delay caused nearly 10,000$ (~120,000 $ in today’s term).

6. Constraints were kept in mind while laying out the plan, and not based on the design.

Notes from David Snowden’s lecture

November month provided me rare and very good opportunity to attend workshops anchored by renowned speakers across the globe. 

It started with David Snowden’s workshop on Complexity theory  followed by  Mary and Tom’s leaders window.  


David is known for his contributions towards knowledge management and Complexity theory related subjects.  He has won several awards and a very good speaker.

The 2 hour I spent listening to Snowden is memorable.  I had a few Aha moments during the workshop, and based on Snowden’s pointers, I am continuing research on the areas related to complexity theory.  He is one of the inspiring speakers I have come across. The venue was crowded with eagerly looking lean thinkers and Agilists.

A few points from my notes :

1. Building Inefficiency provides opportunity for innovation

2. Systems thinking provides an idealistic and futuristic view, where as complexity theory looks at current state of affairs

3. One learns things better by failing rather than doing it right or reading “How to” books

4. Complex systems are dispositional but not causal

5. It is important to know the principles, and “why” behind the principles to scale it.

Notes from Lean workshop - Vol 1

Mary and Tom’s Leaders workshop  had been insightful, and a few thoughts are extremely radical in nature. The notes I took during the conference span a few pages, and would be sharing it here in the next couple of posts.

Got Opportunity to have lunch with Mary, and got an opportunity to take a few pix with her during the conference.

1. Involve diverse team during any decision making process. Healthy conflict is one of the key ingredients in building a successful product

2. Having a meeting like Scrum meeting/standup every day is always useful. However, Mary recommends the Pulse Meeting model that is followed at Scania 

3. Functional requirements should be considered as unarticulated high level designs.  Reading between the lines, there is a hidden design in every functional requirement.  This is also echoed by Tom Gilb.

4. Having a Product Owner between the sponsorer and developers adds waste.  Share the vision with the developers and let developers/technical people take it from there in building the product

5. Find a way to write less code

6. 25 – 30 % Productivity can be increased by eliminating Task switching

7. I was under the impression that PDCA cycle was invented by Deming but learnt that it was Walter A Shewhart from Bell Labs

8. One should be cognizant of  applying the competency or technical leadership styles while forming the team.

9. Also, discussed  Little’s law and Queuing theory in addition to practicing few case studies of its applicability in software projects

10. Trying to utilize 100% of bandwidth reduces the pace rather than improving it.