Wednesday, April 12, 2017

Random Thought - How to learn (sic!) Agile?

A lot of people asks - how can I learn Agile?

My answer is pretty simple to budding Agilest. Please do not learn Agile or do Agile but become Agile. No one becomes Agile by reading a couple of books or attending some training.  You need practice and more practice. Certainly to gain information (not knowledge) you need to do efforts by:

•    Classroom training (face to face or online);
•    One to one (face to face or online) coaching;
•    Participate in local meetups and Agile related community activities;
•    Books, blogs, videos, podcasts, and articles;
•    Participation in online discussions – Quora, Linkedin, facebook, slack channels, etc;
•    The best is on the work training by working with some team which is already working in Agile way; and

•    If you do not have access to Agile teams on the work, you can do small projects to mimic the Agile way of working e.g. daily routine, laying pavement in your backyard, etc.

Monday, April 10, 2017

Random Thoughts – Agile transformation

All trees are different but we want straight jacket solution for Agile transformation/ Architecture development.

Roots hold the tree and provide stability to any tree. Just look around, you will see hundreds of type of trees but roots are very similar. However, as we move upward toward stem to fruits variation in characteristics of the trees become very obvious.

Roots are like values on which organizations and people stabilize and provide the base of growth. Stems are like principles which grow on roots and help a tree to stand up high. Branched originating from the stem are like guidelines which have bigger variations among different trees. Next step is smaller branches - frameworks and methodologies which have bigger diversity even for a tree on which flowers and fruits make a tree to spread across the generations. However, have you noticed as you move from roots to flowers & fruits variation keep on increases?



Are trees representing organizations - having very similar values but increasing variation in conducting business?

If trees are organizations are so similar why do we seek one solution fit all answers for the Agile transformation? Why do we not focus on values and design a custom solution for the Agile transformation? Do we have a hangover of straight jacket ERP era where some divine expert knows all?

Tuesday, April 4, 2017

Team building exercise to help increase velocity and quality

Team building exercise to help increase velocity and quality

Are you looking for a team building exercise that will show how scrum works? Try this team building exercise to increase velocity and quality on your team. Try making paper airplanes as a team. If you have a team of 10 people, split the team into two teams. You will try to build as many paper airplanes as possible and also measure a distance that the planes will fly. Here's how it works:

Run 3 - 6 minute sprints to build as many paper airplanes as possible using plan, do, check, act (PDCA). You will take 1 minute to plan how you'll build the paper airplanes. You'll take 3 minutes to build as many paper airplanes as possible. Then you'll take 2 minutes to check basically a retrospective. What went well? What can be improved? Lastly, you'll act differently based on the answers from the check cycle.

In this exercise, there will be four roles:

  1. Checker - One person will check how many paper airplanes are built and can actually fly.
  2. Inspector - Another will work as part of the assembly process, but will also pay attention to the process itself and look for ways that the team can make better planes and speed up their production. 
  3. Builders - Everyone else will concentrate on building as many paper planes that can actually fly the distance in the assembly time allowed. 
  4. Timer - One person will focus on keeping the time of each cycle.
Each team will measure how many planes fly the measured distance after each sprint. You will notice by doing this exercise the team will make better paper airplanes after each sprint. By using PDCA which scrum was taken from you will build better paper airplanes because you're constantly looking for areas where you can improve.

Adopted from the book “Scrum: The Art of Doing Twice the Work in Half the Time” by Jeff Sutherland

Thursday, March 23, 2017

Random Thought – User story sizing

User story sizing is based on relative sizing. It means story-A is approximately twice big as of story-B and your big is different from mine.  It means there is no standard way of saying that how much resources (skill, time, people, coordination effort, etc.)  are needed to complete a story.
But there is a catch. As we start working together, slowly your big and mine big start to converge. But it requires a close working relationship. It also means that team-1 big might be different from team-2 big, so we can’t compare team-1 and team-2 on the basis of the number of story points completed in a sprint even if team size, type of work, the skill set of team members, distribution, and other thigs are same.

To compare teams, we need to look into their velocity trend with annotated information around context for each team (number of team members, type of work, distribution of team members, the skill set of team members, the dependency of stories, availability of team members, the structure of stories, etc.). Also, every spike (and dip as well) in trend line should be annotated with reasoning (e.g. team lost few members during sprint five).


Now, let’s back to assigning story points to each story. We as human beings are terrible at sizing, especially if size is either big or small. So any scale which is to be used for sizing user story should be widely spaced and space between two pin points must keep on increasing as size increases (assuming we will not estimate the small work). Fibonacci series fit into this requirement. It is suggested that every team member develops some mental model to start with for sizing purpose. I have developed mine own model and love to share:

Story Point
Mental Model
Remark
1

Story is too small to estimate, it must be combined with a similar story.
2

Story is small but acceptable to work with.
3

Story is of good size and I can complete the work in a couple of days.
5

Story is again good size but may touch upper limit of my capacity to complete in a couple of days.
8

Story is big enough. I need to split into smaller ones so I can complete the committed work in a couple of days.
13

Story is definably big and must to be split into smaller ones. Are we going to the moon?
21

Oh my God! It is not a story. It is an intergalactic ship.

On the basis of this mental model, I have also created planning poker cards which are available at https://github.com/tusjain/agileanswer/blob/master/PlanningPoker/PlanningPoker.pdf under common creative license.

Wednesday, March 22, 2017

Agile fable: Agile transformation


You might have come across the fable in which ant work hard but due to the burden of organizational hierarchy and desire for reports destroyed the organization.
Every day, a small Ant arrived at work early and starting work immediately, she produced a lot and she was happy. The boss, a lion, was surprised to see that the ant was working without supervision. He thought if the ant can produce so much without supervision, wouldn’t she produce more if she had a supervisor!
So the lion recruited a cockroach who had extensive experience as a supervisor and who was famous for writing excellent reports. The cockroach’s first decision was to set up a clocking in attendance system. He also needed a secretary to help him write and type his reports. He recruited a spider who managed the archives and monitored all phone calls.
The Lion was delighted with the cockroach’s report and asked him to produce graphs to describe production rates and analyze trends so that he could use them for presentations at board meetings. So the cockroach had to buy a new computer and a laser printer and recruit a fly to manage the IT department. The Ant, who had been once so productive and relaxed, hated this new plethora of paperwork and meetings which used up most of her time.
The lion came to the conclusion that it was high time to nominate a person in charge of the department where the ant worked. The position was given to the Cicada whose first decision was to buy a carpet and an ergonomic chair for his office. The new person in charge, the cicada, also needed a computer and a personal assistant, whom he had brought from his previous department to help him prepare a work and budget control strategic optimization plan.
The department where the ant works is now a sad place, where nobody laughs anymore and everybody has become upset. It was at that time the cicada convinced the boss, the Lion, to start a climatic study of the office environment. Having reviewed the charges of running the ant’s department, the lion found out that the production was much less than before so he recruited the Owl, a prestigious and renowned consultant to carry out an audit and suggest solutions. The Owl spent 3 months in the department and came out with an enormous report, in several volumes, that concluded that ” The Department is overstaffed..”
Guess who the lion fired first?
The Ant of course “Because she showed the lack of motivation and had a negative attitude.
Now let’s flip the organization and its growth in the Agile way of working where the role of managers, HR and any other person/entity who are not value contributor is constantly challenged.
Every day, small Worker Ants arrived at work early, start work immediately, Ants produced a lot, and they were happy. The boss, a Lion, was surprised to see that the Ants were working without supervision. He thought if the Ants can produce so much without supervision, wouldn’t they produce more if they had a supervisor! He also heard there is something called the Agile organization. He thought of trying it and hired an Agile coach to grow the organization is the Agile way. Lion hired Agile coach Rabbit. On the first day of the assignment, Rabbit decided to talk to Ants to understand the nature of work and to understand ground reality. Lion was surprised, as he expected that Rabbit will talk to him first, after all, he is the boss but he kept his silence and decided to observe and learn. After talking to Ants, Rabbit was in Lion’s office and started his interview process. Rabbit’s talk was mainly centered on - what does Lion want from the organization, what is his vision, and what is the purpose of the organization. 
After talking to many people in the organization, Rabbit came with a high-level plan. Strangely, the opening statement of plan stating that it will change as new Information is discovered. This plan has put a lot of onus on Ants to manage themselves while Lion’s, other bosses and supporting departments’ role was limited to providing the environment and resources so Ants can manage themselves.
HR and Finance departments were furious after studying the plan – no concrete dates, metrics, very little control. Rabbit was summoned to explain the plan to bosses of the organization. In his presentation, Rabbit patiently answered the questions raised by bosses who were feeling that they would lose control if Rabbit’s plan is implemented. To sell his plan, Rabbit employed very simple strategy; he leaked the details of his presentation to almost every participant and incorporated their feedback without compromising the Agile way of working. No surprises during the presentation.
Few of the bosses agreed to do small experiments in their fiefdom to try Agile way of working as Rabbit’s proposal was promising better outcome in medium to long term.
In the meantime, Rabbit also spoke with Ants and took them in confidence. The Ants were happy as their views were also taken into consideration.
Rabbit created a representative team of Ants to demonstrate the power of the Agile way of working. To conduct this experiment, he asked all of the executives and other Ants who were not part of the experiment to observe (just like kids in zoo watches the animals – just watch do not interfere). Rabbit volunteered to provide help to anyone if someone wants to set up a similar experiment. Initially, people were skeptical but as benefits of self-organizing, manager-less team started to become clear as continuous improvement in effectiveness and outcome started to flow out, other teams and executives started to reach Rabbit for help set up the Agile teams.
To support new teams in the Agile way of working, Rabbit asked Ants and existing managers if someone is interested in training and coaching and also started to hire new talent from outside with active involvement of HR.
Lion is a person of numbers. After the initial dip, numbers were trending in the positive zone. Lion was convinced that he betted on the right side. He was gung ho and wanted to roll out the Agile transformation across the organization like the big bang. Rabbit jumped in and argued to slow and steady approach like directed evolution.

Tuesday, March 21, 2017

We as a DevTeam

DevTeam consists of generalists specialists (T-shaped skill set) who can perform all work to create product increment as envisioned in the Sprint Goal. The size of DevTeam is 6±3. There is only one role in a DevTeam – Developer. Each member of DevTeam may have a specialization (say QA, front end, back end, database, etc.) but everyone is responsible to achieve the sprint goal. There are no sub-teams within DevTeam. DevTeam members follow good engineering practices. DevTeam members self-organize to achieve the sprint goal. DevTeam is a long running team and members are full time allocated to it. All of DevTeam members follow same norms and rules.
As a DevTeam, we own Sprint Backlog. During Sprint Planning Meeting, devTeam negotiates with Product Owner to keep its commitment for the sprint. Sprint Backlog represents the commitment of devTeam for a sprint. DevTeam members participate in Daily Standup and share their work and impediment if any. DevTeam is responsible to deliver product increment at the end of the sprint. DevTeam presents items to PO as soon as acceptance criteria is met. DevTeam members collaborate to complete the work. DevTeam only accepts the work as envisioned in the sprint backlog.
As a DevTeam, we participate in scrum ceremonies.  DevTeam actively participates in refinement activities to keep Product Backlog healthy. DevTeam estimates PBIs. DevTeam evaluates the technical feasibility of PBIs. DevTeam is responsible for all work to be done to deliver as committed in the Sprint Planning Meeting (in the form of Sprint Backlog). DevTeam participates in Sprint Review ceremony to collect feedback from stakeholders. DevTeam conducts Retrospective in the end of each Sprint with PO and SM to reflect on self. DevTeam helps PO to conduct Demo.
As a DevTeam, we strive for automation to keep effectiveness and productivity (velocity) curve upward. DevTeam adopts Agile engineering practices to keep the quality of product high. DevTeam members strive to learn new tools, techniques, technologies, and skills to develop T-shaped skill set. DevTeam members work closely with PO and SM to deliver consistently and effectively.
As a DevTeam we strive to deliver value with sustainable pace. DevTeam remains in conversation with PO throughout a sprint to get clarification on the Sprint Backlog Items. DevTeam has the clear understanding of Sprint Goal. DevTeam not only focuses on HOW but also knows WHY and WHAT. DevTeam is responsible for continuous delivery of valuable outcome. DevTeam is empowered to make the decision about the HOW part to complete the work as listed in Sprint Backlog. DevTeam manages information radiators. DevTeam continuously communicates with users.
As a DevTeam, we continuously educate ourselves and share learnings with technical, Lean, Agile and Scrum communities. We organize and participate in technical, Lean, Agile, and scrum oriented community events to facilitate understanding of technical, Lean, Agile, and scrum values and principles.


Friday, March 17, 2017

I as a Product Owner


As a Product Owner, I am responsible for Product Vision and its continuous evolution. I may not know everything about the product but I know, from where to get that information and how to manage competing stakeholders for limited resources and even manage conflicting views of stakeholders about the product. I am “go-to” person for product domain. I have business analysis skills. I negotiate priorities, scope, funding, and schedule. I own product roadmap as well as Product Backlog.
As a Product Owner, I do not drive technological decisions but understand and appreciate devTeam’s technical skills. I incorporate the technical wisdom of devTeam in Product Backlog’s prioritization in addition of stakeholders’ vision and wishes. I communicate WHY and WHAT of product so the Product Backlog Items. I share product vision with devTeam. I define Acceptance Criteria in collaboration with devTeam for every PBI.
As a Product Owner, I actively participate in scrum ceremonies. I lead Product Backlog Refinement effort with devTeam as well as stakeholders. During Sprint Planning Meeting, I offer Product Backlog Items to devTeam to be developed in current Sprint. I bring in subject matter expert o answer any query by devTeam. I only offer PBIs which are INVEST-able during part one of Sprint Planning meeting. I define Sprint Goal and convey the same to the team before or during sprint planning meeting. I ensure that I am always available to devTeam during Sprint. I accept PBIs during sprint as offered to me by devTeam provided they meet Acceptance Criteria. I have authority to reject any work performed during sprint. I can terminate sprint mid-way. I decide the content of demonstration of increment in collaboration of devTeam and actively participate in the same. I participate with devTeam to split PBIs. I don’t direct the team on how to perform its job. I drive release-planning effort with stakeholders and devTeam. I help the team to remove impediments.
As a Product Owner, I engage with stakeholders on the continuous basis to elaborate PBIs and create new ones. I interact with stakeholders to assign Business Value and prioritize PBIs. I utilize various techniques (Story Map, Impact Map, budgeting of story point to different stakeholders, and other techniques) to reach Minimum Viable Product, assignment of Business value, and prioritization of PBIs. I keep Product Backlog healthy – two to three sprint worth of stories are INVEST-able and prioritized.
As a Product owner, I continuously educate myself and share my learnings with Lean, Agile and Scrum communities. I organize and participate in Lean, Agile, and scrum oriented community events to facilitate understanding of Lean, Agile, and scrum values and principles.