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