Comparing agile teams maturity using "Aikido Shu Ha Ri model"

As per wikipedia "Shu Ha Ri" is a Japanese martial art (particularly Aikido) concept, and describes the stages of learning to mastery. It emphasizes on first learn, then detach, finally transcend.

• shu means "protect", "obey", "following" — traditional wisdom — Novice or beginner; narrowly following given practices
• ha means "detach", "digress" — breaking with tradition — Journeyman; following, but extending, perfecting, occasionally breaking the rules, 
• ri  means "leave", "separate", "fluent" — transcendence — Expert; perfecting to creating your own practice, coaching or mentoring

Our teams also differ in their maturity level and its important for any agile coach to asses that.In my opinion if your team is struggling to answer any of these WHY questions they belong to Shu level: 

• Do you understand why we are doing agile?
• Do you know the purpose of standup?
• What is the goal of retrospective?
• Why switching focus is bad? 
• Do you know the values of Scrum/Kanban/DAD/LeSS/...?
• What is the fundamental concept behind any agile methodology?
• Are they reluctant to adapt new challenges?
• and any other questions in similar path...

As per the technique, teams at Shu level are following and not questioning the practice. Where-as in our world we should always be questioning and tweaking the practices to our need. This is a big difference so while using the terminology for teams in agile space, please use with caution.

A team is at Ha level if they understand the WHYs and have tweaked the process as per their need. They should have clarity and should be able to define the intent. Here are few questions along those lines:

• Have we found anything, which does not work very well for our project or organization?
• Have we found anything, which we believe is better and would give us more milage than following what has been asked us to do?
• Have you ever failed in trying a change? 
• Do you do change or experiment a change?
• Do you do any fun as a team?
• i am confident, we can find many more questions...

Once the team has good grasps on WHY, WHAT, HOW and has tweaked a process as per their need. In my perspective they are transitioning themselves into Ri level. They should be able to take goodness from all the existing agile patterns and create their own pattern, which will be tailored specific to their organizational or business or project need. They will take the foundation and would build their own structure. I am confident such a team is very easy to spot. Never the less these questions might help:

• How different their current process is and what benefit are they getting?
• Observing how they get pass a team problem without involving anybody from outside. Do they only discuss about problem or try to solve the issue by fixing the root cause. 
• Noticing how they handle new challenges. Do they come up with something creative to tackle the problem?
• See what they care more about, process or getting value. How often do they complain vs. suggest a change. They are not process slaves they amend the it to rule. 
• Do they focus in past or future? It should be 80:20, keep an eye on future while observing  the past.
• ..... 

Knowing a team's level helps me a lot:

• I can come up with right frequency to introduce an experiments based on their maturity level vs. making them mentally excused. 
• I can focus on having a long DoD(Definition of Done) for SHU team vs. a shorter one for HA. 
• I am usually more disciplined with SHU teams vs. HA. 
• I try to coach SHU team on value and understanding every practice more vs. HA team I tend to focus more on experimenting and decision making techniques. 

Cheers!

Manisha

are we Afraid of estimation or commitment?

"We don't do estimation because we follow Kanban".

I am sure every coach must have heard this statement countless times.  Many teams moving from agile methodology to Kanban to simply escape from estimation. As per them, Estimation is:

• Waste of time 
• Useless 
• Can be stressful
• Considered harmful 

First of all, nowhere in Kanban it says, "no to estimate". It is up to the team. I am all for challenging the status quo and questioning everything. But is estimation really a waste? I believe estimation helps teams to stay focused. High level gut feeling always helps in decision making and prioritization. So why some teams are reluctant to do estimation? In most of the cases estimation gets abused or treated as commitment. This is completely wrong. The main goal behind estimation is to size your work queue and not hold team responsible. Mike Cohn has very nice article on it.

Teams might also be unwilling to estimate when they don't understand what they are estimating. So as coach we should be able to answer "why we are estimating?" I found few technique very useful while estimation discussion. Each of these tips can be used standalone and are very detailed topics on it's own: 

• Story vs. Story Maps: Story at time does not tell the entire conversation. I found Story Maps to be more useful. Map only what you need to support your conversation. . Make sure team has discussed ways to tackle the problem at high level. ( Story Map technique). 
• Brainstorm the problem enough to consider the solution. Making sure that there is nothing better out there (always within the scope and time boxed for sure). 
• Focus on making Functional walking skeleton first. This is very important step. 
• Have a high level plan to manage your budget. Budget should lead the timeline and strategy for development. Also will help team keeping focus. 
• Create a Story Board and have in the room. 

I would suggest to keep the mind open to make sure estimation is being used in the way it is useful and meaningful.

Cheers!

Manisha

What to keep an eye on?

Thought of summarizing few points for agile coaches or agents on the field.

Here are few focus areas which might help :

1. Keep you board neat and clean : Always focus on active work. Make sure inactive work is either moved back in the queue or removed. Make sure that what’s on the board is what the team is actually working on. 
2. Know the work priorities: As a manager or senior member of the team know, what needs to get done. You should take charge of prioritizing all work that comes to your team. This would require communicating with stakeholders and management. 
3. Project/feature overview: Make sure you have one board where stakeholders, team members or managements folks can get a complete overview of product features or concepts, teams are working on. Having big picture always help team member across every level. 
4. Quality: Make sure your team is making small and consistent improvement. Have metrics to track improvements. Always do something, regardless of how small, to improve the current state. People do what you do not what you say you would do. 
5. Create a helping culture: Think of it as relay race. As leader observe, how the work was passed to other teams or departments.  Was it done at the right time, in the right hand, with the right information? We should make sure we are providing every support and help to other teams effectively and efficiently. Doing it late still takes the same amount of time!.
6. Always Compare now and before: Look for trends and make them visible to teams and management. It will help you, as leader, to identify improvement areas. Always be vigilant and pick one improvement at a time.  
7. It's okay: Celebrate! Recognize the team’s/individual member's accomplishments/failures and contributions. There is always something positive. 

Hope it helps

Manisha

We are neither Jira administrator nor gate keepers

I was having dinner with few hard core developers (yes!!! they eat, breath and drink technology) yesterday and as per them they don't need any scrum master/lean delivery agent/ agile coach/ manager in their team. They don't see the value of having them.

They have a board, they do daily morning standup and collaborate beautifully with customers/domain experts/sales people and above all deploy in production 3 times a day.  So thought of summarizing our role for them. 

What we are not:

• We are neither gate keepers nor quality control representatives
• We are neither managing team members nor their schedule
• We are neither there to schedule meetings for team nor to make sure they show up on time
• Our job is also not to facilitate meeting for team 
• We are neither a lead developer nor a project manager
• We are not responsible for their personal development as well
• We are not Jira administrator as well

Now! you must be thinking, what we do, Am I right?

WHAT WE ARE!!!! 

• We are people who observes events and behaviors for long period of time to provide focus and direction for improvement. We look for what is possible in a given scenario. This is not always seen from the Visual board, one has to observe and pay attention to it.
• We should be able to understand a situation to come up with actions out of them. 
• We should be able to cultivate trust-factor between management and team about each other capability and involvement. 
• We should be able to suggest an improvement focusing on whole vs. part. Development is just one piece of entire puzzle.
• We are there to ensure, we fail as fast as possible and organization should be ready to experiment and pivot. Imbibing this culture sometime takes months if not years. It is not processes that drives improvement but it's people's initiative.  
• We should provide right information at right time to help team or organization take good decision faster. 
• We should help team to identify fastest way to deliver value
• We should take responsibility for improvement ideas
• We should separate observation from learning, to apply them appropriately. Leading using long-term thinking is our trait, by making small sustainable improvement over time in culture, technology and leadership. 
• We should make sure people have curious mindset. Any thing they try is an experiment. Try for a period of time and evaluate the result. 
• We should be able to learn from outcome, which is more meaningful and valuable than checking off improvement actions. 
• YES! We are their to help team / guide team / coach team if we feel the need of it.

GOSH!! I knew, I can do it. We are like bee on the wall, nobody can see us but are there :). I am sure this list is can be extended by many other colleagues of mine. Please feel free to do so.

Cheers!

Manisha

Is Agile or Lean really common sense?

I always hear, "Agile or Lean is not a science but mostly common-sense. If you apply your common sense you will get it right. " 

I am not disagreeing with the fact that some part of Lean and Agile is common sense but with common sense we will achieve 20% success. To be 100% successful we need to understand, in which areas common sense can be applied i.e. face-2-face conversations should get preference over email or chat, it is easy to build small artifact vs. giant one and many more. 

But when it comes to building a process, which will lead to effective and efficient delivery and happy customer, not to sure if common sense would be sufficient ingredient. To me, we need to understand culture, values, people and THE PROBLEM (they are facing).  

Culture

--------

I try to understand the culture from its employees.

• How respectful they are when they are talking about other teams?
• How managers are presenting their peers?
• Are people always complaining about situations around them and saying, "You don't know how hard it is or how bad it was? Vs. we are not perfect and it may take little time and effort to be there. 
• How comfortable people are talking to their senior management? Are they worried when they are sitting next to them? 

These are few things from a fairly long list, which helps me understand in which kind of environment I am in.  It plays very important role in designing the improvement or learning cycles. It helps in choosing the wordings for the organization as well.

Values

--------

Values are very important aspect of an organization if done right. I try to watch below things when it comes to designing a process around value.

• How well Values and Goals are interwoven together? 
• Does everybody understand the purpose behind those values and why they are important?
• Do they have values for employee personal development? 
• Do Values drive their day-to-day work?

Knowing values obviously will gives me confidence in coming up a solution which will work in that organization and is aligned with them and not some out of box solution.

People

----------

What to say here? This is for sure common sense :D. This is most difficult albeit most important aspect for anything and every things. YES THEY are the CORE of the system. I like to watch out wording used in team rooms. i.e.

• I give up vs. I am sure we can find something, would anybody like to help
• I don't understand this vs. I am missing something and need sparing partner
• It's okay should be heard more often vs. gosh I don't know what to do now? 

These are just tip of an iceberg but something in those direction tell me whether people are positive or afraid towards changing or adapting new things. It lots depends upon CULTURE and VALUES. They are the driving factor of "IT'S OKAY" culture. 

Solution to Solve the Problem

--------------------------------------------

This is no brainer that any solution should solve some problem which we are having. Don't adapt something because you heard about it or you thing it is cool but always start with WHY. Why are we doing this and what problem are we trying to solve. Propose a solution to solve the problem. Don't be process slave but be a change agent. 

 

SO it is lot more than common sense after all!!!! I will try to cover each topic in detail in next blogs. 

Thoughts!!!!!!

Manisha 

Why stories should only flow continuously forward?

Before we start, let me set the stage right for all of you :)

Old Scenario (Dancing Stories,   Story keeps dancing between phases/states till it gets ultimate nirvana of doneness.) :

      Sven a handsome developer picked a story from "Ready to Be Developed" column :D.

• He moves it to "Analysis/Planning" column to have a clear understanding of story. He collaborates with PO and Team subsequently.  After his analysis he either moves his story to " back for PO to update" or "In Progress to start the work". 
• After finishing the story, he moves the story to "Ready to Be Reviewed". Like before this can also result in backward or forward movement. 
• Then comes the Ready to Be Product Owner Review phase. Similar pattern follows in this phase too. The story moved in "In Progress" if PO finds some anomaly (:D) otherwise Ready to Be Deployed. 

     Problem: 

• Board is not representing the real state of story vs. just helps in understanding who is working on it.
• It encourages silos of responsibilities within team vs. enforcing swarming culture
• Helps very little in identifying the true weakness of system. Using this approach it will longer to identify bottleneck.

Refactored Scenario, with only one COOL rule, FORWARD Please :):

 Sven, same old, handsome developer picked a story from "Ready to Be Developed" column :D.

• He moves it to "Analysis/Planning" column to have a clear understanding of story. He collaborates with PO and Team subsequently. Since he can't move the story backward, he pairs with PO to ensure readiness. If PO needs time, then he assigns the story to PO but story DOES NOT CHANGE state/phase. After finishing his Analysis he moves it to "In Progress to start the work". 
• After finishing the story, he moves the story to "Ready to Be Reviewed". Like before story has to live in same state until it has fulfilled the current state. The responsible person can change but not the state. i.e. Sven assigned it to "Michael" for code review or to "Mike" for QA verification. During this time, he is either pairing with appropriate person working on story or uses this time to prepare about next state of story or helping other team members in finishing their task. In any case he is not starting any new until current work is done. 
• .... Similar pattern would follow across the board.

As always, after introducing this new rule, Sven was super upset and came running to his favourite LDA ( Lean Delivery Agent): 

Sven: This change is ridiculous and will slow us down. Why we have to do it?

Manisha: We introduced this change hoping it will help us in identifying bottlenecks in our system. For example:

• If "Analysis" is taking longer than we might have to involve Architect during technical feasibility more  
• If "In Progress" is taking longer than might be story was not sized properly or scope creep is happening. 
• If PO Review is taking longer than we might request POs for in time feedback or would involve them early may be during development.

Sven: It will definitely slowing us down since I am not being able to start something new after I am done working with my story? 

Manisha: You mean, when the story is deployed on live and usable. I thought for us DONE means story is deployed and usable in production. (YES!!!!!!)

Sven: No, I mean when I finish coding of it.

Manisha: Aha! Simply because finished coding does not mean you are done dear :). You still need to make sure you keep your focus on the story and involve people effectively and efficiently.

Sven: Why can't we move the story backward, AGAIN? I am working on it since it failed verification, it should be In Progress. 

Manisha: You are working the story continuously till it is deployed, aren't you, may be with different people. Hence "In Progress" is not the only column, which shows that you are working on it. The  status/phases represents the state of the story not who is working on it. On the other hand whomever the story is assigned to, is the Person working on the story. Let me be little more explicit on collaboration piece:

• During analysis, you are collaborating with Team or Architects or PO to understand the story
• In Progress, you are writing code based on your understanding
• In PO Review, you are collaborating/supporting PO to get your story approved.
• In Deployment, you are collaborating/supporting devops/live deployment/doing it yourself to get your story deployed 

Sven: Yeah, Yeah we always do that. Who would be benefitted most with this change, since we sit close by and are aware of things happening around it.

Manisha:  As said earlier, The status represent the story's life cycle state, which would help stakeholders/distributed team knowing the current status of the work. i.e First time In Progress would take longer and hopefully addressing PO comments would be quick. So it will help in expectation management. 

Sven: Okay! lets give it a try :D.

Yeeeehhhhh!!! That's the spirit.. Lets give it a try

Manisha

System: What it is?

I came across awesome definition of System in "Thinking in Systems" book.  Thought of sharing :).

Definition from Thinking in Systems book:

"A system is an interconnected set of elements that is coherently organised in a way that achieves something. System must consists of three kinds of things:"

• Elements 
• Interconnections
• A function or purpose

Few examples: 

• Digestive System:
  • The elements of your digestive system include teeth, enzymes, stomach and intestines. 
  • They are interrelated through the physical flow of food 
  • The function of this system is to break down food into it's basic nutrients and to transfer those nutrients into blood stream ( Another System)
    
• Football Team:
  • The elements such as players, coach, field and ball
  • Its interconnections are the rules of the game, the coach's strategy, the players communication and laws of physics that govern the motions of ball and players.
  • The purpose of the team is to win games or have fun or get exercise or make million of dollars or all of above

How to identify a System (How to know whether you are looking at a system or just a bunch of stuff)

• Can you identify parts? ... and
• Do the parts affect each other? ... and 
• Do the parts together produce an effect that is different from the effect of each part on it's own? and perhaps 
• Does the effect, the behaviour over time, persist in a variety of circumstances?

Most difficult Part:

• It is easier to learn about a system's element than about it's interconnections:
  • Many of the interconnections in system operate through the flow of information. 
  • Information holds systems together and play a great role in determining how they operate?
• The least obvious part of the system, it's function or purpose, is often the most crucial determinant of the system's behaviour.
  • It dependants upon complexity of the system

"You think that because you understand "one" that you must therefore understand "two" because one and one make two. But you forgot that you must also understand"and" " - Sufi teaching story

Cheers!

Manisha

Definition of Ready (DoR) - "Aha! we get it feeling"

I am trying to make my teams root strong and in the process, I am questioning them about the purpose of each and every agile ritual or document they have. I strongly believe the need of understanding the purpose before starting to do it.

Today was the turn for DoR and Board Work Flow. During my preparation I compiled few points from various blogs and thoughts of sharing with you all.

Purpose of DoR:

• It helps to keep the backlog items actionable
• It gives the opportunity to team understand the value of backlog items vs. working on junk stories
• Avoids wastage of time of both when a story is started and after a few days' work (if more information is needed to complete the story, the work on it stops).
• Reduces requirements churn in development.
• it makes sure team builds what is required
• It expose inherent weaknesses of the system.
• The Product Owner and Delivery Team work at different cadences. They focus on different things at different times. This checklist initiates the necessary discussion between Product Owner and the rest of the team.
  

What DoR should contain : 

• What:  Is the goal or end-result of the story clearly defined?  i.e., is the expected behaviour or coverage goal as clear an unambiguous as possible at this stage of development?
• How: Have you considered how to build the feature?  It doesn’t have to be much, but some thought about how to build and integrate the product story into the existing working product.
• Who / Resources:  Are all the necessary resources (i.e., people, tools, IT infrastructure) available and committed to the product story to have a reasonable chance of completing within a reasonable amount of time?
•  The DoR checklist is a living document and should be kept up-to date with the learning. 

I know my team gets very furious at times when they don't see a fully prepared story but I always insist them to work with POs to complete it.  In my opinion stories does not need to be 100% defined with all acceptance criteria. But it should be READY ENOUGH so that team can work on it without waiting in between. It should always be made 100% ready together with during grooming or similar kind sessions.

Board flow discussion was super exciting and would share the outcome in next blog.

until then!

Manisha

DoD : does it really help continuous delivery?

Short Answer: Yes if done right :).

Long Answer:
We are trying to come with DoD (Definition of Done) for my teams. We came up with our DoD, which is pretty much taking care of entire 9 yard, from code to validation.  It has checks for 

• meeting acceptance criteria
• making sure we are doing code review
• release check list 
• making sure automated test in written for code
• architectural review
• .....

This set looks almost identical with my previous teams (may be with 10-20% variance).  After the entire exercise, I am honestly challenging myself on how much DoD would help my team in delivery? Does anybody really cares for DoD in real day-to-day work? 

I thought of gathering some understanding on the true purpose and scope of DoD. For Teams who are doing continuous deployment and development, how is this artifact relevant? 

• Is it a reminder for us to do our engineering job i,e commit your code, write acceptance criteria or automated test cases
• we need DoD to have one understanding of Done
• Use to DoD to get Story Points in the same iteration vs. next
• Is it a big checklist for us to remember our mistakes
• It helps teams to be more disciplined
• Improves teams credibility amongst stakeholders
• it helps team find weakness in the system
• It reduces the risk of misunderstanding as well as the communication gaps between the teams and stakeholders.
• it is something else. 

Relevancy is dependent upon the context you are in... Here are some tips which worked very nice for our team in past: 

• Automate as many check as possible 
• Don't let it collect dust. it is not static document.
• Break checks across all columns vs. doing it at the end.
• Try making your DoR big, so only right stuff can entire the work pipeline. And try to keep DoD short and concise.  

Again, until DoD is part of daily ritual, I doubt, it would bring the desired result. For DoD to allow us to focus on delivery, it has to be part of our daily routine/discipline. 

Hope it helps

Manisha

What is an Impediment?

One of my team always says "Wish we did not have this meeting today" or "We are still waiting for our server rule to be created" or "Thoughts on how to get feedback sooner from architectural group" or "We are still figuring out whom to ask for getting rights for TFS server". Their comments made me think, how can I help them and what to do to raise their concern.

During this thinking process, I asked myself, are these impediments?

At present, we have mechanism to flag stories or tasks in Jira as blocker or impediments. We, agile coaches, get alert whenever somebody marks an issue as impediment. We all work our best to remove it as quickly and as efficiently as possible. Impediment for us is anything, which stops team from doing its work. 

What if we change the definition to, "Impediment is anything which is preventing our teams from achieving continuous flow as fast as possible." it can be anything like delay in getting new server for testing, getting feedback from other group, too many meetings complain etc... Most of the times team members do not specify them as impediment but these things effect our flow. Hence keeping an eye on them is very useful and can help teams a lot. 

Alongside, we facilitated a retrospective called Angel retrospective. We asked team members to wish for one thing which will help them in achieving their goal in most effective and efficient way. We collected their wishes and it was starting point for our impediment list.  

I am still working on finding techniques and methods to collect impediments and work on removing them.

Let me know your experience

Manisha

Estimate Size and derive duration

Planning should enable us to do right and reliable decision making. - John Maynard

I am big proponent of doing estimation. I think it has advantages if done right. For doing it right, I personally found Mike Cohn's "Estimate Size and Derive Duration technique" very useful.

In this technique we separate the step of Estimation from the step of Deriving the Duration.

In Estimation step, we figure out the size of the work to be performed. It can be done in any unit your team prefer i.e. story points, ideal time or any other unit. Once we have the rough number for size then we estimate our pace i.e velocity or cycle time.  After having both the numbers, finally we derive the duration.

Example:

Lets say we are building a new analytics dashboard. I request my team to estimate the backlog in ideal time (Time Spend doing the work) by making three assumption.

1. It's all you work on
2. no one interrupts you
3. and everything you need is available

I request them to do a rough estimation, it does not need to be precise. Then I convert the Ideal Time into Elapse Time (Time is from start to finish of the work) by taking into account their daily meetings, their other distractions etc.

After doing my above math I try to find their pace. If the team is new to agile methodology, I prefer to wait for couple of sprints/stories to finish before guessing their pace. Otherwise I like to average the velocity or cycle time by removing the out liars.

Once I have above two units, I simply divide to derive duration.

Estimation / Pace = Duration

Hope it helps
Manisha

PrOpER coaching cycle

I leant a technique from Agile Coaching book, which I find very useful in my day to day life and thought of sharing.

Lets look into each term closely:

Problem: Pick a problem to work on. Watch how the team works. What needs to be improved? 

Options: Consider your options. What could you try that might influence the situation for the better? List at least three options. You can choose to brainstorm with team by persuading them via thinking questions. i.e. How often do you think about this issue? or Can you spot any gap in your thinking etc. 

Experiment: Pick one option to try and run that experiment for 2 weeks or more, depending upon your situation. Making change an experiment helps focus the team on the benefit because you’ll need to discuss how to evaluate whether the experiment is a success. If they can measure an improvement, this gives the team a reason to continue. So, start the team off making some small changes, such as redesigning the work- space or introducing a regular team lunch, to get them ready for bigger changes.

Review: Review the outcome after experiment is over. Did you improve things? Even if things haven’t improved, have you learned something? 

I use above technique almost on every problem, which is thrown at me. I also like to start with WHY question at time. Use "why" questions technique carefully, sometimes it is better to ask, "What you have in your mind" or "Are you satisfies with the results" question vs. starting with why. We will end up with less offended  team member.  More coaching cycles for you: 

GROW (Whitmore)	PrOpER	PDSA (Sheward)	PDCA (Deming)	PDSA
Goal
Reality	Problem
Options	Options	Plan	Plan	Plan
Will	Experiment	Do	Do	Do
	Review	Study	Check	Study
		Act	Act	Adjust

I like PrOpER because of it's Experimental nature. 

Thanks

Manisha

Continuous review and delivery - can they go hand in hand ??

Background: 

We use to be Scrum shop and then moved to Kanban a year ago. ( For good reasons :D). Our stakeholders were use to Scrum Review where they could give feedback before things move to production. We had defined cadence for review. 

Important points, I am not talking about Product Owners review or feedback. They are very closely involved in our DNA. I am talking about upstream and downstream communication to real stakeholders. In Scrum world they had chance to give their feedback during Scrum Review which become impossible for us to sustain when we switched to Kanban. Why:

1) We do deployment for each tiny chunk.  2) We could not predict when each story would be done. Getting stakeholders to review a story on-demand is close to impossible. 

For above reasons, we swapped the Review with Demo where they could get update on live stories once in month. After almost a year and lots of chances in our board, our stakeholders complained about not getting involved early and continuously enough to provide their feedback. They are missing something like scrum review process is our assumption.

We definitely had below constraints before proposing a solution:

• We don't want a solution, which will create bottleneck in our continuous delivery flow. 
• We don't want to increase the operational cost of our stories
• We do want the system to be self maintainable 

We started studying our Jira produced data to understand what is the average life of stories in our system in PO Review column. For first round of experience we proposed two changes.

Experiment 1: We will run this for two weeks before introducing second experiment. This will give us sometime to collect data and fill our power grid.

• We would modify the JIRA ticket to add stakeholder list for each MMF 
• Once the story related to MMF would move to "Ready for PO Review " status, JIRA would generate an automatic email notifying the above list of stakeholders. Or LDAs would get notify and they will send the email. 
• The email will have link to staging environment for feature.
• Stakeholder would get notification and can provide their feedback to responsible PO/s, but we will not wait for their feedback. PO/s still have full authority to approve the story as before.

Advantage: 

• This will be seamless to current process and would generate passive information for people to react and consume. 
• Will also tell us about our most interested stakeholders in grid. 
• POs can also send update based on that reminder.
• All stakeholders would be notified only interested one would get email.

Disadvantage

• People might not notice the information and it might just reside in their emails

Experiment 2:

• Creating a fixed rhythm of meetings may be bi-weekly (or something else) review meetings to ensure the stakeholders are up-to date
• We can review all the stories, which we have been moved to done.
• Each team can nominate one person and they can present the stories to stakeholders. 
• We would need to create a calendar for team
• Based on stakeholders comment, POs can align their stories better in future. (Inspect and Adapt)

Advantage:

• Stakeholders are involved directly 
• Team members and POs are getting their feedback directly and doing a direct collaboration 

Disadvantage:

• Stakeholder not coming to meeting bi-weekly (We can always adjust the frequency)
• Might be little too overwhelming for stakeholders to see so many stories at once.

Experiment 3: We need to change lots of code to incorporate it.

• Deploy every story with a switch in pre-production environment. (Propagate to other environments vs. Notify Developer with changes) 

Advantage:

• Stakeholders can test feature with production data and can rollback || propagate changes.
• Stakeholders have fun control over the feature. 

Disadvantage:

• Stakeholders need to be really proactive.

I will share results of our experiment on my blog for others to learn. 

Thanks

Manisha

What is exactly being productive means?

How can we improve our productivity? / What can we do to improve our productivity? / How can we effectively measure productivity? and many more questions related to same topic arises everyday. So what is productivity?

Is productivity means keeping entire organization busy all the time on most important thing?

As an organizations, our focus is always on Net Profit, ROI and Cash Flow.  To make money we need to increase net profit while simultaneously increase return on investment and cash flow. If the goal is to make money, then, an action that moves us towards making money is productivity. And an action that takes us away from making money is non-productive. So, "Productivity is the act of bringing a company closer to the goal (of MAKING MONEY). "

Making money is definitely the end result of a goal but might not be the direct goal of your company. Your company might have target like 10m new customers in next quarter or being #1 company in advertisement field etc to achieve making money goal.

Knowing those tiny goals and keeping focus on those goals are very important. To make an organization productive everyone part of it should have clear picture of their goals and should understand all the tiny steps required to achieve those goals.

I believe in agile environment, we expect too much out of our POs (Product Owners). I feel, as if we expect them to behave like superheros. They are responsible for entire engineering team's productivity. We don't expect engineering team to have much power when it comes to deliver business value.

It is hard being a Product Owner. POs are responsible to align their day to day work with mission/vision statement of the company. If PO fails to prioritize properly, it effects the bottom line.
They are also required to keep up changing market demand, creating proper specification for all engineers, being responsible for business flow and value etc. They are human after all and can make mistakes.

I strongly believe it is not only PO who need to understand organization goal, its everyone's. That's what being productive means. It is responsibility of every member to make sure they are on same page and speak same language. And it starts with selecting right items to work on.

I would recommend management to do first round of prioritization by selecting high value items (HVI I call them H6 list) (Lean Enterprise has awesome formula #WSFJ).  Then broadcast or share (via OKRs) H6 list with everybody. This could be the first step towards creating a common platform. POs would still be responsible for articulating and bringing the ship to island. But engineers can raise a flag incase they notice something which is not part of the H6 list.

Until everybody is aware of organizational goal and necessary steps to achieve it, being productive does not hold much meaning.

Lets build something which matters the most to the customer :)
Manisha

Journey from no automated test to some

In the world where code is legacy, the minute you deploy it to a production system. Every developer is touching some piece of code which is legacy and does not have sufficient test coverage. Team might be running manual test for their releases. But as we know running manual test might take significant amount of time. It would make continuous development/deployment impossible for any agile team. I would think any agile practice would fail without proper automated test coverage.  Forget about teams who does not have manual testcases.

Imagine above project where we had 10 features to start with and team slowly developed more functionality. Our manual testing time also gradually grew from 1 hour to 4 hours.  The amount of manual testing would go up with every feature unless team takes measures to stop this from happening. 

In my old project we started with identifying easy to automate, we started automating steps which were repeated in most of the testcases. i.e. login, mouse clicks and loading of menu bars etc. Our application was very difficult to automate because it was not written to keep automation in mind. 

During step identification process, we decided to develop automated tests for our new features. We were being able to stop our situation from deteriorating. Our goal was to add automated test for all new functionality we were developing. This was the most difficult step. We modified our DoD ( Definition of Done) too. 

Honestly this was big step for us and we gained lots of confidence by doing it. We slowly used our Kaizen time to convert existing manual testcases over the period of time. 

Trying doing the same thing for your codebase, I am sure you would see success too. Try reading http://www.thoughtworks.com/insights/blog/test-automation-who-should-be-involved article.

Cheers!

Manisha

Estimation meeting getting dragged for hours?

In our organization all Product Owners (PO) fear or simply run away from estimation meeting. We started following Kanban and one major consideration amongst others were relief from those hour long estimation meetings.

Basically we made estimation meetings so painful that POs stopped asking for it. We started arguing about value of those estimation meeting.  I am sure this scenario is not common to us. I felt, as if these developers have been burnt by giving estimate before. I am confident, management hold them accountable for the numbers they spoke. 

I would try to resolve these issues by encouraging team to give honest estimation. I would also assured them that the number will not be taken against anybody if it turns out to bigger than what they feel. Also never use their estimates against them i.e. in reports or some charts. Remember estimates are not commitments. We estimate and then if necessary we commit. One of the most important factor in converting an estimation into commitments, are cost of being wrong. A team facing high cost for being wrong would give a different commitment from being a team which pays no cost at all. 

I would recommend explaining them the benefit of estimation meeting from team's perspective. We all know why estimation is important for client/customer/PO but why it is important to team. (Mike Cohn gave an awesome tip, which I love to follow.). Team develops credibility by giving an estimate and sticking to it. If team has track record of providing estimate and meeting them. Business will listen when team says certain deadline is impossible. I am sure every team likes to be heard. 

Cheers

Manisha

Estimating Product Backlog Items - why to do it?

In our team we have stopped estimating product backlog items.

In our context I believe it's fine not to spend our valuable time estimating product backlog item. Because, there is no need to tell, where the team would be in two or three months. Also since team is working on small small features PO wants all of them. For us having estimate will not change any behavior, so I would say it's okay. 

In my past projects we always estimated PB. An estimate represent the cost of an item and helped PO successfully prioritize the items. Also estimation helped us doing the rough long term projection on when team would be done with the product backlog items. We estimated product backlog items during our PbG ( Product backlog Grooming) meeting. We use to have PbG meetings 2 to 3 days before sprint planning meeting. This gave enough time to PO to get the backlog prioritized and ready for sprint planning meeting. At times we did adhoc Product backlog estimation based on PO's need. 

It is nice to experience both side of spectrum. 

Thanks

Manisha

How To Groom Product Backlog

Product Backlog Grooming (PbG) means keeping the product backlog well maintained. This concept has become very popular amongst teams over the past few years. Teams realize that Sprint work gets lot easier if the product backlog is in good shape. i.e. Well Groomed.

PbG is where top priority backlog items are assessed against Definition of Ready(DoR) or Conditions of Satisfaction or Acceptance Criteria. Whatever you would like to call them in your system, is basically high level test to verify the backlog item. By doing this in advance of Sprint Planning meeting, Product Owner (PO) gets a chance to add any missing details to the item before Sprint Planning meeting.  Grooming a product backlog usually involves handful of separate activities.

1) New items can be added into backlog with rough estimate from team.
2) Reprioritization of backlog items based on customer feedback, usage pattern etc.
3) Discussing top big items and breaking them into smaller items to fit them into next Sprint.
4) Adding details to the items as per DoR
5) Throwing away the items which are not needed

I would not suggest entire team to participate in PbG. However PO, Scrum Master and one or two team member should be sufficient. Lots depend upon the team semantics. Scrum Master may ask the team during standup, about their availability for PbG meeting, anybody who is not too busy during the Sprint can participate. Everybody should get a chance to participate once in couple of Sprints.

In my perspective it is lot advantageous to designate a specific time in the Sprint and do it on regular basis vs. thinking of doing it real time. i.e. whenever needed. It should be good to do it before 2 or 3 days before Sprint Planning (SP) meeting.

Thoughts

Manisha

Task finish late more often than they finish early, why?

"Failure to plan is planning to fail"     -  Winston Churchill. 
"It is better to be roughly right than precisely wrong." - John Meynard Keynes 

Planning should enable us to take right and reliable decision. Don't get me wrong, I am not asking for precise estimation.

I strongly believe in quick and rough estimation which evolves as time pass through.

In this post, I am leaning more towards what impact, human behavior and type of work we do, make on our rough estimated number.

Student Syndrome or waiting till last responsible moment ;)

Student Syndrome, refers to waiting to start a task until the last possible moment that does not preclude on time finish. (This is human nature and very difficult to change.) Lets take same feature A example. As a developer, I thought task X should not take more than 3 days but I kept one day buffer and said 4 days.

When we think we always think like below: Work (3 days) + local Buffer (1 day)

But while executing we feel very optimistic to finish the task in 3 days and we start with cleaning technical debt, preparing some flow for project or documents etc.

We behave reverse i.e. Local Buffer (1 day) + Work ( 3 days)

Finally I started my work and my work took 4 days. I ended up delaying the schedule vs. finishing on time. I had local buffer but it did not help. Therefore having shorter iteration in development cycle might help in keeping the focus vs. big iteration.

Lateness passed down (Central Limit theorem does not apply for software)

Software tasks are mostly dependent upon each other, hence the impact of delay of one task may cause delay in other another too. Let me elaborate what I mean by this. Lets estimate a feature A, which has 3 tasks X, Y, Z.  Task X would take 4 days to finish. Y and Z subsequently would take 2 days each. So initial estimate for feature A is 8 days.

For some technical reason task A took 5 days. Now obvious question would be to think what impact would it have on tasks Y and Z? Developers would mostly say other tasks would finish in 2 days each, since I learnt a lot while finishing task X.

You might think that our new estimate for feature A is 10 days vs. 8 days.  If the tasks in feature A are independent to each other, than this new estimate might be good but in most cases if task X took 1 days longer there are possibilities that task Y and Z might take longer too.  Therefore for any revision, look for inter-dependency within tasks for more accurate estimates.  

my experience
Manisha

Scrum master committing to master

One of my colleague commented this and somehow this sentence walked with me home. It definitely made me ponder more on this topic. Some of my random thoughts

People, I meet most of the time, who are process advocate have little connection with software but they know how to come up with a process for development team. It makes me wonder how can you come up with a process for something you have never experienced. No offense to any of gurus, it is truly my view. 

To me a process is dependent upon:

1) your organization, 

2) team, 

3) technology, 

4) project and 

5) never the less upon culture. 

With so many variables how can one process definition be sufficient. My confusion does not end here. Lets look at the other side of coin. We have hundreds of processes available. Each process has flavors and your can mix and match process too. i.e Scrumban, Scrumlite, proto-kanban etc etc.. 

Question is how I select which process would be best to start with?

1) I usually like to start with understanding my variables. Once I have understanding about my variables I move next.

2) I go on to understand which values are most important for my organization and team. 

3) My hunt further continues in process area, which process would help me in delivering those values in less friction way. 

Now to do any of the above you really need to know and understand developer's heartbeat. Things which can go wrong during development process. Knowing developers instincts. So being a process advocate who can code would not only give you above advantages but would also let you come close to the team, will make your more reliable and will make you a good leader which your team might look forward too.

More importantly, which I feel missing in any process is. how to keep your team motivated and happy. 

A happy team can do miracles. Any process will fail if you don't have right people in your team. So what is more important process or team. In my perspective it's team. If your team is nice and you have people with right mindset they can make any process work. Other way round seems very very difficult to me....

Thoughts

Manisha