Scrum Vs Kanban fight

The fight between Scrum and Kanban is not over yet. Here is a nice blog entry that not only exposes the fight but a nice way to teach the intricacies of the two methods.

There are people who are proposing the middle path i.e. the ScrumBan path.

Agile Assessment tool

I am in the process of creating an Agile assessment tool. The assessment questionnaire would cover the following areas.

1. Fundamentals of Agile
   
2. Scrum concepts and practices
3. Engineering Practices
4. Workspace related

Fundamentals of Agile would cover questions around 4 Values and 12 principles of Agile

Scrum concepts and practices would have questions around 3 roles, 3 artifacts and 3 ceremonies. Specifically the team section would cover self organizing teams, cross functional teams

Engineering Practices section covers practices from XP (TDD, Coding Standards, CI, etc)

Workspace, as the name itself implies would cover topics like seat arrangement and other environment related topics such as use of Post-it notes, white boards, etc

The differentiating factor between the assessment tool that I am creating and other popular ones like NokiaTest is the granularity of the questions. Many Agile assessment questions that I have come across are at coarse grained level. I am in the process of creating fine grained questions.

According to me Questions like the following are coarse grained

• Do you do scrum Meeting ?
  
• Does your product owner prioritizes the requirement ?

Questions like the following ones are fine grained

• Do you ask the 3 questions during Scrum Meeting ?
• Do you do the meeting at the same place and same time each day ?
  

In the example above, the coarse grained questions around Scrum Meeting won't tell you if the team (specifically a novice Agile team) is practicing the Scrum Meeting in the right way.
The tool I am creating would ward off such differences in understanding of concepts and ensures to check consistent understanding of popular practices across the organization.

Choosing the Proxy Product Owner

Agile methods recommend having a dedicated Product Owner sitting with the team. However in practice, many product owners come up with various reasons for not being able to sit with the team.

(Image Copyright: All rights reserved by creator).

Some of the popular ones being

• We are very busy and don't have time
• We don't have sufficient budget to allocate a person
• It is the responsibility of the software company to gather requirement from us and understand it in one go
• Project is very large and single product owner is not sufficient to manage. But we don't have budget for multiple product owners (as experienced in distributed large scale development model)
  

We could add many more reasons to the above list.

However the software companies cannot or won't push the customer too hard on this front as they fear losing the customers. Keeping the above practicality in mind, some thought leaders have come up with a concept called Proxy Product Owners.

Identifying the Proxy Product Owner

The thumb rule many people propose is to make the Business Analyst(BA) the proxy product owner. This is because, BAs are considered to have in depth knowledge about the business and they can prioritize the requirements with little or no help from real product owners. They could also clarify any doubts around requirements as needed.

The question is, is this thumb rule applicable to all projects ?

Challenges in small budget projects

In fact, I believe we cannot apply the same thumb rule everywhere. Not all software projects have the luxury of having a dedicated Business Analyst.

How do we deal with situations like this when BA is not available ?

Many agilists propose an alternate idea i.e. to identify a senior developer or project manager as the Proxy. However I believe it is not easy as choosing a proxy based on seniority. The proxy needs to meet certain criteria for playing this role.

My experience says, to be proxies should have

1. built the trust with the product owner
2. faith from the team members
3. influence on the project team members and respected by other stakeholders
4. the ability to make decisions and convince others

So, it is very important to look at above and may be other key criteria before choosing the proxy product owner, otherwise, the project could get into trouble soon.