Value of Standup

I am continuing my WHY series and here I go for standup.

Outcome of Standup:

We as a team should come out of standup, "knowing how to better attack our day". 

Standard 3 questions:

• What did you do yesterday or from the time we met?

• What will you do today?

• Are there any impediments in your way?

Why behind each question:
1) What did you do yesterday or from the time we met? (10-20% of time) 

• By sharing, what we finished yesterday, we get a sense of accomplishment and also helps in keeping us committed to our yesterday's promise.

• It is an opportunity to share any quick learning with the team

• It is also a good segue to the next questions.

2) What will you do today? (50-60 % of time)

• It helps us in planning our team day and allowing us to effectively plan and execute 

• It helps, team member/s raise a concern, if their plan, intersects or conflicts with your plan.

• It allows team member/s to share their knowledge or offer help to you, if they have better knowledge around the area.

• It allows team member/s to share their bad experience around the area.

3) Are there any impediments in your way? (20-30% of time)

• We raise them to be able to resolve it as a team as quickly as possible.

Benefits of a stand-up:

• It is short. 

• This saves everybody's time, as most of the issues raised will likely only require two people to be involved.

• It is effective in giving all team members an overview of where, for example, a project is.

Who should be part of it: 

I like the below story, since it best describes the situation.

Chicken: "Let's start a restaurant."

Pig: "Good idea, but what should we call it?"
Chicken: "How about 'Ham and Eggs'"
Pig: "No thanks. I'd be committed, you'd only be involved."

All the Pigs should be part of it and Chickens should be refrained from distracting team. 

Other things, we can discuss after standup:

Any thing, which impacts entire team can be quickly discussed after standup. Since the team is already together, one should take advantage of their focus switch. We may discuss topics which required entire teams attention. For example:

• Grooming a quick story

• quick project update

• quick environment update 

• Can be anything which impacts team

• reminding people about upcoming holidays 

Things not to share:

Any information, which does not help the team in planning the day better should not be shared. For example:

1. I was in feedback meeting with Mariam.
2. I was part of interview yesterday
3. I was looking into JIRA-xxxx 
4. Today I will be attending 1n1 with Mr. Blah Blah

References:

http://martinfowler.com/articles/itsNotJustStandingUp.html

https://www.mountaingoatsoftware.com/agile/scrum/daily-scrum

https://www.mountaingoatsoftware.com/blog/should-the-daily-standup-be-person-by-person-or-story-by-story

 http://scrumtrainingseries.com/DailyScrumMeeting/DailyScrumMeeting.htm

https://www.scrumalliance.org/community/articles/2014/july/7-mistakes-during-the-daily-stand-up-meeting

Execution of Retrospective in Kanban world

No No, don’t worry I am not going to bore you with the benefit of retrospective. Retrospective is great tool if done RIGHT. My last blog touches on done right point little bit and will do a deep dive into done right topic soon.

But right now, I am wondering about a perfect way to do retrospective for teams following Kanban. Yes! you read it right! PERFECT WAY. So thought of sharing my experience on the execution aspect of retrospective for teams following Kanban.

My teams in past have been engaged in retrospective ceremony in following way : 

1. Regular 1 or 2 weeks cadence like the one scrum prescribes: Teams meet regularly and do their inspections in a regular rhythm. 
1. Advantages: Team is taking time to think and focus on continuous improvement at regular intervals. 
2. Disadvantage: Team members need to remember or recollect things on retrospective day.
2. Retrospective Item (RI) Limit based Cadence: Teams will have chart on the wall in team room or in confluence or google doc to collect retrospective items. Specifying the RI LIMIT for the team.  Something similar to WIP Limit. Team would meet as soon the limit is met. We should always keep 2-3 weeks upper bound limit. i.e. if they can't reach their RI Limit in 3 weeks they should huddle around to discuss points for improvement.
1. Advantages: Team controls the limit and does it, what feels right for them. My earlier team had done it and they kept the RI Limit to 3. The person writing 3rd item was responsible for scheduling a meeting on teams calendar. Agile Coach was responsible to remind them incase 2 or 3 weeks limit was broken.
2. Disadvantage: Team members might miss the retrospective since there is no fix cadence. Team with very low maturity level might feel overwhelmed..
3. Just in time Retrospective: Do it when you need it. Team members would call a meeting when they will feel the need of it. 

1. Advantages: Team members have full autonomy to call for a meeting, whenever they feel the need of it. The topics are fresh in they mind and they can find better solution by discussing them. It comparatively takes less time but requires high disciplined team.
2. Disadvantage: Same as earlier one, team members might miss the retrospective since there is no fix cadence. I would not suggest this style for any new team. This is definitely a good tool for mature and fully performing teams.

These are the three styles of retrospective cadence my teams have followed in past. Do share if you have tried something else and have worked well for your teams. I am trying to find a best way for distributed teams and my hunt is still on.

So long

Manisha

.  

Why we need Agile Retrospective?

Retrospective was designed to address Twelfth Agile Principle, which states: "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly." 
 

Prime directive

“Regardless of what we discover, we must understand and truly believe that everyone does the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand.” 

Purpose of Retrospective

Using Retrospective :

• we focus on learning and understanding instead of blaming 
• we should find the root cause of the problem vs. just finding the symptom 
• we Inspect in past and do the changes in FUTURE to get adapt according to our environment.
• we are improving our future work.
• we are extending the usefulness of current and future activities.
• team understands what went wrong together so they can change their way towards betterment.

What Agile Retrospective is not

• History Lesson learnt 
• Hot air (Blame Game)
• transform into complaint sessions: (People do not complain with bad intentions. They simply exteriorise what is affecting them. They have needs that are not being fulfilled and they need to express their emotions. Problems occur when the receiver is put off by the complaint and immediately enters defensive mode and counterattacks. )
• Change the world 
• Wishful thinking
• Ideas fest
• After action review 
• Postmortem  
• Project Review

Structure of a Retrospective 

• Set the stage ( What you can expect to get out of this exercise and choose right style for facilitation.)
• Gather data ( What )
• Generate insights ( So What )
• Decide what to do ( Now What)
• Close the retrospective ( Action Items)

Thanks

Manisha

Finding Jira SprintId for Rest API call

I woke up with a very simple wish of printing my stories rather than writing them. I imagine, it to be a very very simple task since I did something similar couple of years back.

I looked at the Jira Rest Agile API documentation and found a rest endpoint, which will make my life simple.

https://jira.yourdomain.com/rest/agile/1.0/sprint/{sprintId}/issue

Now, I wanted to find a sprintId and to my surprise, it took me longer than I excepted. So thought of making a note. 

I had to hop around little bit to finally get that number. Here is what I did?

1) Clicked on my Project and then clicked on Reports sub-menu. 

2) Choose "Sprint Report" from the drop down.

3) The current sprint is usually selected and the URL on the address bar, has the sprintId https://xxxxxx/yy&sprint=9999.

I believe, now I am all set to print my stories :D.

Enjoy

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

Understanding the Stages of Team Formation

Of-late teams are my favorite subject of study and understanding different stages of team formation was very helpful to me as an agile coach. It helped me in understanding my team and I was being able to help my team become more effective more quickly. 

Lets discuss what are stages of team formation. As per psychologist Bruce Tuckman, every teams has following stages: Forming, Storming, Norming and Performing.  He published his article in 1965 about development sequence of small team. He used it to describe the path that most teams follow on their way to high performance. Later, he added a fifth stage, "adjourning". 

Lets see how we can use this model to build a highly effective team: 

Forming

-----------

In this stage, most team members are positive and polite. Some are anxious, as they haven't fully understood what work the team will do. Others are simply excited about the task ahead.

As leader, you play a dominant role at this stage, because team members' roles and responsibilities aren't clear.

This stage can last for some time, as people start to work together, and as they make an effort to get to know their new colleagues.

Storming:

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

Next, the team moves into the storming phase, where people start to push against the boundaries established in the forming stage. This is the stage where many teams fail.

Storming often starts where there is a conflict between team members' natural working styles. People may work in different ways for all sorts of reasons but, if differing working styles cause unforeseen problems, they may become frustrated.

Storming can also happen in other situations. For example, team members may challenge your authority, or jockey for position as their roles are clarified. Or, if you haven't defined clearly how the team will work, people may feel overwhelmed by their workload, or they could be uncomfortable with the approach you're using.

Some may question the worth of the team's goal, and they may resist taking on tasks.

Team members who stick with the task at hand may experience stress, particularly as they don't have the support of established processes, or strong relationships with their colleagues.

Norming

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

Gradually, the team moves into the norming stage. This is when people start to resolve their differences, appreciate colleagues' strengths, and respect your authority as a leader.

Now that your team members know one another better, they may socialize together, and they are able to ask one another for help and provide constructive feedback. People develop a stronger commitment to the team goal, and you start to see good progress towards it.

There is often a prolonged overlap between storming and norming, because, as new tasks come up, the team may lapse back into behavior from the storming stage.

Performing

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

The team reaches the performing stage, when hard work leads, without friction, to the achievement of the team's goal. The structures and processes that you have set up support this well.

As leader, you can delegate much of your work, and you can concentrate on developing team members.

It feels easy to be part of the team at this stage, and people who join or leave won't disrupt performance.

Adjourning

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

Many teams will reach this stage eventually. For example, project teams exist for only a fixed period, and even permanent teams may be disbanded through organizational restructuring.

Team members who like routine, or who have developed close working relationships with colleagues, may find this stage difficult, particularly if their future now looks uncertain.

As a leader our goal is always to help teams reach Performing stage as quickly as possible. Identify the stage your team is in and then slowly move forward towards Performing stage. Based on team's stage adjust your approach and behavior towards your team. Provide enough help during Forming stage, would be my suggestion. During Storming give them structure and try identify their strengths and weaknesses. This stages is usually the hardest. Give them context and autonomy to resolve things on their own but do help if need arise. Once you are over this stage, you should simple step back and your team should take over the responsibility of moving forward. Once Norming stage is over, you should pat your back and go for vacation since your job is mostly done. Last stage happens a lot in all organization, so celebrate before leaving each other and remember. 

"The world is round and the place which may seem like the END may also be the beginning" -Ivy Baker Priest

Enjoy

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