Goal seeking Retrospective

I spend lots of time thinking about my teams and how to effectively use retrospective tool for Dominating Don to Silent Sara. I like to start the retrospective with an ice breaker and follow lots of different style. Some worked very nice and other failed miserably. We also focus on action items at the end. Awesome right!!!!  .

After doing almost 500+ retrospectives, one thing I have learnt that having a goal always helps. I experimented one more thing, which seems to have worked better. 

We did "High Performing Tree" retrospective with a simple twist in the language. We start every sentence with "How might we" or "Sometimes I wish". Very quickly we started filling up our tree with really clear yet individual assessment about team.   

We went over each sticky note and created our own list of important traits. Mainly focusing on, "How we can come together and work as a unit?" and "What kind of group level feedback we would require to be a performing team." Our focus was to understand, "what kind of team we actually are "and "what kind of team we imagine to become". We came up with a small plan and  quick "performing traits" burn up for ourselves. 

This was a turning point for my team. Next retrospective was very focused towards those goals and stabilizing ourselves to meet them. We always tried updating our "performing traits" burn up at the end of retrospective. 

Hope this technique will help your team as well.  Try and let me know your feedback. 

Cheers!

Manisha

How to effectively switch pair when adapting Kanban?

Let me start with little background. My team believes in XP practices and follow them religiously. We also followed Scrum process and use to switch our pair at the end of sprint after sprint review. It was going all smooth till that one day, when we decided to ditch Scrum and adapt Kanban as our delivery model.

We thought we will change pair after each story but stumbled upon issues, since each pair was starting and finishing at different times. We struggled for a while and then came up one idea. We decided to switch the pairs every week and made one-person owner of the story.  Owner took the story with them while switching the pair.

Bingo! Our problem was solved for time being. 

Thanks

Manisha

agile or anti-agile

I am big believer of agile but having terrible time wrapping my head around wide-open noisy spaces. I am not denying the effectiveness of face-2-face communication but the need to make entire organization sit together on an open floor, does not jive very well with me. I have noticed people working with headphones on. Isn't it defeat the entire purpose? 

"The most efficient and effective method of conveying information to and within a development team is face to face conversation." - Agile manifesto

I am not sure, how this line gets translated into: "Please make multiple teams sit together in an open space". I like playful environment but can't focus in too much noise. A simple disciple can solve this problem but everybody has to be on same page. 

Also in 20th century face-to-face communication can happen over Skype/Hangout/Facetime or any other channel. It isn't necessarily mean being physically present. We are in the era of distributed teams. My team is spread across three different time zones. We use hangout all the time to communicate and as a team don't feel need to be sitting next to one another.

Since the needs are changing, our adaptation should change too.  One last point, development is an art and like any other craft, engineers need their quite moments to think. During organizational transformation, we should make sure feature/product team is sitting together, but they also have places to go and think. 

Engineers should get flexibility to work from home as well. Just because we are following agile developer ONLY loses the privilege of working from home. They have to be in office all the time. Isn't this unfair?

There are few other issues as well, but may be, I should stop my ranting for today. Let me know, if you agree or disagree with my above points.

Manisha

Storyboarding/Storymaping/Journeymapping a requirement

"We don't write our stories we draw them." - Walt Disney

I am big believer of being agile but just hated using it as an excuse to be half-assed about requirements and design. Two areas whose mastery has extreme impacts to project success.

It might take little time to create storyboard but we create an understanding on paper then team can make it happen on code. Storyboard can cut off lots of unnecessary work upfront. I want to this blog in value first style, since I completely concur with Simon Sinek and like to start with WHY questions first. Hence lets start with answering our first questions and slowly move forward.

"WHY we should use storyboards?"

Short: Teams are better aligned and confident doing a change or developing a new feature. It helps in building shared understanding in the room.

Long: A picture worth thousand words. Storyboards are extremely useful, when we have a very long narrative to explain. It brings the communication overhead down by multiple notch. It helps in creating a shared understanding where developers can apprehend, what the client or product owner is imagining and why. It is not that a person is right or wrong but with sketches and sticky notes around, we evolve our shared understanding in the room lot quicker which is super-hard with just words alone. It is very easy to make changes and alteration on storyboards vs. on real projects. We can't measure shared understanding but after trying storyboards my teams definitely feel more aligned and confident.

"How we start with storyboards?"
I always like to start with an empty template, like below: There are lots of templates available on google (search world story board template). Or make one, which works best for your team. Choose the one you like.

Start off by visualizing your product or feature. Tell the requirement in the most simplest form before you start building them in most complex form.

Close you eyes and start to think about desired out come.  Who it is for and why are we building it. Think about the tasks a user would perform. Imagine big picture and include pains and joys of user. Write them down on sticky notes and arrange them from left to right flow (also called story telling flow). Try to use verbs to specify tasks. Write phrases in your user language. You must have noticed that each sticky note is a step, and hidden in between each sticky note is the nifty little conjunction phrase, "... and then I ...".  Keep in mind when you are thinking about user using your product. They might have different goals. They may use it in different contexts. This may evolve different types of users or things. Explore other types of users.

Use the goal-level concept to aggregate small tasks or decompose large tasks. Alistair Cockburn uses an altitude metaphor where sea level is in the middle and everything else is either above or below sea level. A sea-level task is one we would expect to complete before intentionally stopping to do something else. 

So far we got all happy path. Now start to think about ".. what about..". We will get some alternative variation for our storyboard. By now, you should get pretty wide board and little deep if you have explored few tasks. 

Now if you will step back a bit, you will find bunch of stories that seems to go together. Cluster these task which seems to go together to help reach a bigger goal. Put another sticky on top of these tasks and write a short phrase on it that distills all the tasks underneath it. This will help us in identifying high level tasks or activities. 

To slice out minimum solution that would both delight people and help reach it's goal, Identify minimum set of tasks that would make that outcome possible. Bingo! In short

• Tasks are short verb phrases that describe what user do.
• Tasks have different goal levels.
• Tasks in a map or board are arranged in a left to right narrative flow.
• The depth of a map or board contains variations of alternative tasks.
• Tasks are organized by high level activities across the top of the map.
• Activities form the backbone of the map.
• You can slice the map to identify the tasks you'll need to reach a specific outcome

Don't forget so far all these are hypothesis so don't forget to add stories for risk and how to measure our hypothesis. Now it's time to develop things which we identified. Focus on risky things. first

In gist building a map helps you see a big picture, to see the forest for the trees. That's one of the biggest benefits of story mapping but if you are the one responsible for building the forest, you make sure to plant one tree at a time. Two most important things which makes them work :

• Use storytelling with words and pictures to build shared understanding
• Don't just talk about what to build: talk about who will use it and why so you can minimize output and maximize outcome.

What are storyboarding or storymapping?

"What I was thinking of was the way users sometimes tell stories about the cool new things the software they use does. [ For example,] if I type in the zip code and it automatically fills in the city and state without me having to touch a button. I think that was the example that triggered the idea. If you tell stories about what the software does and generate interest and vision in the listener's mind, then why not tell stories before the software does it?"
                                                                                                                             - Kent Beck
So the idea is telling, and you know you're doing it right if you're generating energy interest and vision in the listener's mind. That's big and it sounds a lot more fun than reading a typical requirements document. But folks who start using stories for software development and who still have a traditional process model in their heads, tend to focus on the writing part and gets frustrated.

If you are not getting together to have rich discussions about your stories, then you are not really using stories correctly in your project. To get that experience sketch your requirement then tell the stories to explain those sketches during discussion capture the facts as acceptance criteria.

There's some evidence that a fact wrapped in a story is much more memorable than the fact presented alone - 22 times more memorable, according to psychologist Jerome Bruner.

Enjoy mapping your stories
Manisha 

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

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

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

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