Tuesday, September 26, 2017

How to eat an ELEPHANT?

How lucky I am, I just hunted down an elephant!! I am going to enjoy it for a long time. No need to hunt for a year. I have more than enough food.

Wait!! Meat will spoil soon, so I can not wait for a year to consume even, not six months. What should I do?? Hmm... I have an idea, I will be eating more and finish this elephant in six months.  No way, I do not want to die as obese. Oh my God!! what are my options? Yep, I have an idea, let's call my friends and share the elephant. That's a good idea, when they have an elephant, they will call me for the feast.

Hurray!!! I know how to each elephant again and again.

Now I know, how I will be helping an organization to transform. After all, I know how to eat an elephant.

Thursday, August 24, 2017

**Sarcasm** An Agile practitioner is a job killer **Sarcasm**

An Agile practitioner is a job killer

    1. He is multi skilled, he is a job killer.
    2. He produces bug-free code, kills jobs for testers.
    3. He keeps automating repetitive tasks, kills jobs for juniors.
    4. He speaks to customers regularly, he kills jobs for business analysts.
    5. He is part of self-organized teams, he kills jobs for managers.
    6. He shares information freely, he kills jobs for trainers.
    7. He codes, design, and architect, he kills jobs of paper architects.
    8. He is a team player, he kills jobs in HR management.
    9. He is part of collocated teams, he kills jobs in the travel industry.
    10. He communicates all the time with remote team mates, again he kills jobs in the travel industry.

Agile practitioners are job killers, we want our waterfall grown-ups back. We do not want disaster teens, we need grown-ups.

Thursday, August 17, 2017

Is Agile a Value System or Belief System?



Yesterday, I had a realization; a bar is a good place to engage in philosophical discussions with friends. To add spice to it is Google. We, few friends, were arguing - "Is Agile a Value System or Belief System". Keeping the sprint of engineering alive we agreed to settle on a definition of value system, belief system, value, and belief.

Value System:  A coherent set of values adopted and/or evolved by a person, organization, or society as a standard to guide its behavior in preferences in all situations. - http://www.businessdictionary.com/definition/value-system.html

Value system:  the system of established values, norms, or goals existing in a society - https://www.merriam-webster.com/dictionary/value%20system

Value: One's judgment of what is important in life, a person's standard behavior or principles

Belief and Belief system: A belief is something in which you believe without supporting facts. A collection of such belief around a context is a belief system.

In some cases, values and value system are backed by verifiable facts or folk lore, myths and legends (not verifiable because concerning events happened in distant past so blurry stories are embedded in society's collective memory or facts and belief manufactured to further an agenda purposefully or unknowingly).

For example believing in the (or many or none) God and associated factors is a belief system but accepting that we do not have any proof of existence or non-existence of God is a fact.

Now, is Agile a belief system or value system?

Certainly, Agile is not a belief system also not a value system but it promotes a value system. The real question is - are values promoted by Agile based on facts (empirical evidence) or manufactured facts and beliefs?

We need more many visits to the bar to explore further :-).

Tuesday, August 1, 2017

Scrum Rules

Scrum is a process framework/methodology
Scrum requires Agile mindset 
A Scrum team consists of a Scrum Master, a Product Owner, and Developers (members of the DevTeam)
Every Sprint is of same duration
Every Sprint is four weeks or less in duration
There are no breaks between two Sprints
The intention of every Sprint is “Potentially Shippable” deliverable
All meetings/ceremonies are time boxed

Every Sprint starts with Sprint Planning Meeting
The Sprint Planning Meeting facilitated by Scrum Master
The Sprint Planning Meeting is attended by Scrum Master, Product Owner, DevTeam members, and stakeholders
The Sprint Planning Meeting produces committed Sprint Backlog
In Sprint Backlog, the Product Owner defines Sprint Vision
The Sprint Planning Meeting has two parts.
The Sprint Planning Meeting is Timeboxed to two hours / week of Sprint duration
In Sprint Planning Meeting part one, Product Owner offers INVESTable PBIs to DevTeam and encourage them to commit for the current Sprint 
In Sprint Planning Meeting part one, Product Owner and DevTeam negotiate the scope of Sprint commitment 
In Sprint Planning Meeting part two, DevTeam break down contents of Sprint Backlog into SMART tasks
No additional stories to be added into Sprint Backlog after the Sprint Planning Meeting
No story deleted after the Sprint Planning Meeting from Sprint Backlog

Every day of team has Daily Standup at same time of day
The Daily Standup is not a status meeting but information sharing and asking for help meeting
The Daily Scrum is timeboxed to 15 minutes
In a Daily Standup, all team members remain stand up.
In the Daily Standup, every team member answers three questions only. No discussions.
All members of the team attend daily standup
If required after Daily Standup, team members may break into smaller groups

The Acceptance meeting is not an official meeting in the Scrum Guide.
The Acceptance meeting does not have time box or cadence. It is an impromptu meeting.
In an Acceptance meeting, one or more Developers and Product Owner meet.
Developer/s present a story and requests Product Owner to accept it as per criteria defined in Acceptance Criteria of this story.
Developer/s presents stories which have met Definition of Done (DoD).
The Product Owner may accept a story or decline the request
If story is accepted, it is marked as Done Done
If a story is not accepted, it remains in Sprint Backlog and DevTeam continue its effort on the story till it is accepted by the Product Owner in current Sprint or it goes back in Product Backlog for refinement after current Sprint is over.

The Sprint Review Meeting is conducted at last day of Sprint before Demo and Retrospective
The Sprint Review Meeting is for stakeholder feedback on the increment of current increment as well as product
The Sprint Review Meeting is facilitated by Scrum Master
All members of the team attend the Sprint Review Meeting
The Sprint Review Meeting may result in PBIs and/or items to be discussed in Retrospective
The Sprint Review Meeting is time boxed into two hours per week of Sprint duration

The Demo is not an official meeting in the Scrum Guide but most of the teams do it separate from the Sprint Review Meeting
The DevTeam demonstrates (show and tell) the delivery of current sprint to stakeholders
The Product Owner makes a call - Which PBIs to be demo-ed
The Demo may result in PBIs and/or items to be discussed in Retrospective
All stakeholders are invited to attend the Demo

Every Sprint includes Sprint Retrospective for the team to inspect and adapt
The team decides what to be leaked beyond four walls of the Retrospective meeting room.
Follow the Prime Directive of Retro
A Retrospective is strictly for the team. Only pigs are allowed, no chickens
In the Retrospective loop back the action items of previous Retrospectives
In the Retrospective conversation centered around three questions
All team members attend every Retrospective

Scrum Master is not a master of team but Scrum
No one reports to Scrum Master
A Scrum Master facilitates ceremonies
A Scrum Master is a Servant Leader
A Scrum Master works with only one Scrum Team
A Scrum Master is full-time role
The Scrum Master enforces time boxes for Scrum ceremonies and Sprint
A Scrum Master shields the team from interruptions
A Scrum Master is empowered to facilitate to tackle intra-team impediments
A Scrum Master is expected to work diligently to tackle organizational impediments
The Scrum Master has accountability to create and maintain the team’s Sprint burn down chart
The Scrum Master coaches the team to enhance effectiveness
The Scrum Master encourages the team to enhance efficiency and productivity by automation and better engineering practices
A Scrum Master continuously works with team to reflect
A Scrum Master has final authority within the team on the correct way to use the Scrum framework
A Scrum Master does not get involved in technical matters

The Product Owner owns Product Backlog
The Product Owner is accountable to keep healthy Product Backlog
All work to the team routed through the Product Manager
A team has only one Product Owner
No one in the team report to the Product Owner
The Product Owner is the go to person about product vision, goal, and functionality
The Product Owner accepts PBIs through out the Sprint
The Product Owner can cancel a Sprint midway
The Product Owner is always available to the team
The Product Owner keep on providing details on the PBIs as sought by devTeam
The Product Owner assigns business value to PBIs
The Product Owner interacts with DevTeam and stakeholders to keep Product Backlog DEEP enough to DIVE
The Product Owner has system analyst and business domain like expertise to understand pragmatic technological and functional realization of the product vision and goals
The Product Owner represents team in Demo
The Product Owner is accountable to refine Product Backlog on continuous basis
The Product owner do not add or delete items in Sprint Backlog in middle of a Sprint
The Product Owner owns Release burn down chart

In a DevTeam there is only one role - Developer
The DevTeam size is between 5 to 7 people
The DevTeam members are in continuous conversation with each other beyond Scrum ceremonies
The DevTeam estimates PBIs
The DevTeam strives to keep Technical Debt minimal and stable
The DevTeam commits in Sprint Planning keeping in mind the historical facts and current factors
The DevTeam is responsible to potentially shippable increment at the end of each Sprint
The DevTeam keep Product Owner in loop with respect to Technical PBIs
The DevTeam strives for automation in every aspect of development and maintenance
A DevTeam member can describe product with end to end functionality
A DevTeam member can describe product's high-level architecture
A DevTeam member actively seek to help of the team mates
A DevTeam member commits to do whatever it takes to reach each and every Sprint goal
A DevTeam member volunteer for a new task from the Sprint backlog as soon as it completes the current in hand
A DevTeam member is willing to learn any skill needed to help team
A DevTeam member work with all the team members to expand the Definition of Done
A DevTeam member seek direction for product vision and scope from the Product Owner
A DevTeam member never direct any other individual team member which task to work on next

Product Backlog is a ranked list of PBIs
Any one in the universe can add PBI to a Product Backlog but Product Owner prioritize
Product Backlog is an evolving list
Product Backlog is accessible to everyone

Sprint Backlog is a subset of Product Backlog to signify commitment of team for the current Sprint
Contents of Sprint Backlog are suggested by Product Owner but finalized by DevTeam
The order of delivery of items from Sprint Backlog is discretion of DevTeam
In the end of a Sprint, Sprint Backlog should be empty
Sprint Backlog is accessible to everyone

PBI is one which adds value to the Sprint deliverable directly
PBIs keep on evolving with rapid bursts when in Product Backlog but once in Sprint Backlog, evolution is much controlled
Most of the time PBIs are written as user stories
Each PBI has acceptance criteria 
The top PBIs are small enough (effort) that several can fit into a single Sprint
PBIs are invitations to conversations, not detailed specifications
Defects/bugs are PBIs

Scrum Board has four columns - Product Backlog, Sprint Backlog, Doing, and Done
Scrum Board is visual representation of work - To Be, Doing, and Done
Scrum Board helps to visualize and enforce WIP limit

Burn down chart is a graphical representation of remaining work in the current Sprint
Burn up chart is a graphical representation of completed work in the current Sprint
Burn up/down chart is updated daily

PBIs are 3Cs and INVESTable because of SMART tasks to make Product Backlog DEEP enough to DIVE

Wednesday, July 26, 2017

Symptoms of Maturity of a Scrum Team



In the Agile way of working and Scrum, we all talk about team's maturity. What are the characteristics of a maturing team? In this article, I am listing few of the characteristics of a maturing team.


  1. Duration of Sprint Planning Meeting start reducing due to better and better refinement of PBIs
  2. Refinement sessions start becoming shorter and shorter because DevTeam and Product Owner are refining Product Backlog on continuous basis
  3. DevTeam starts ignoring presence or absence of Scrum Master during Daily Standup
  4. Impromptu Retrospectives start happening
  5. Fifteen minutes time box for Daily Standup starts feeling long
  6. After Daily Standup, Scrum Master has shorter and shorter  To Do list w.r.t. impediment resolution  and DevTeam members are tackling impediments themselves
  7. PBIs are of similar size
  8. Burn Down chart is pretty smooth over many many Sprints
  9. Product Backlog is DEEP enough and holding INVESTable PBIs for next one to two Sprints
  10. In a truck hitting a DevTeam member thought  experiment, effect on velocity in short term start reducing
  11. Technical debt has steady or downward trend
  12. Scrum Master in getting more and more involved with organizational level impediments because DevTeam is tackling team level impediments
  13. DevTeam is interacting with end users though work is routing via Product Owner


I am sure you have your own list. Let's share that list with the wider community.