Building your roadmap to agility

I was talking to an ex-colleague of mine, who asked me, "Do you have any good material on agile transformation, more about phases and steps to move up maturity scale?". I had a face palm moment.

In my point of view, we can discuss ways towards team adapting agile or organization transforming but we can't have a mechanical point of view. We need to change our mindset since all these things depends upon the very system we are in and it's need. I am not being philosophical but being very practical. I definitely can share some practices which has worked in past for other clients but can't guarantee if those would work in your scenario as well.

In my mind, being agile means we have ability to delivery things in production in small batches over coming any obstacles. This requires great development skills. Organization who are ready for agile transformation needs lots more Jenkin's knowledge vs. Jira knowledge. We need to know, how to do development right before picking up agile transformation.

With this base, now let's me share things which has worked in past for me.  Below picture describes one of few approaches at very high level.

I will explain each step and it's execution style in it's own separate blog series.

Basic foundation to start the transformation is to request Organizational Leadership and Management's to change it's mindset. And ask them what are they looking to gain from agile adaption. Ask specific KPIs towards transformation so we know we are making progress. 

More to come soon on it.

Manisha

Interconnection between elements of Feedback

This is the third blog in the "How to delivery effective feedback" series.  You can read the first and second blogs here. 

In this blog we will look into the elements of a feedback system. 

As stated in above slide, a feedback has 4 elements. 1) Receptor, 2) Stimulus, 3) Effector and 4) Response. If you will notice, Receptor and Effectors are organs, which means, they are physical things. Whereas Stimulus and Response are the actions, which those physical things perform.

Let's understand them in the context of a "Speed-Sign" example.

You see a speed sign and one of two things might happen. If you are going fast then you will try to reduce your speed or if you are going slow then you may speed up. So in this example Eye is a receptor and Foot is an effector. And imagine you are going at the speed of 38 miles per hour, which is your stimulus then your response would be slow-down. If you are going at the speed of 22 miles per hours then your response would be to speed-up. 

We will try to look at the Models for Giving Feedback in next blog. 

Thanks

Manisha

Estimating versus Sizing

We were having a discussion in our team room, around the importance of using right term during grooming or planning. Should we use word Sizing vs. Estimation. 

In my mind, the word estimation brings along it's own baggage. We have all been held accountable to estimate that we've regretted. As per Nassim Taleb, we are bad at estimation because there is a whole bunch of randomness just waiting to pounce on our lovely estimated. And as we know randomness in our project goes only in one direction; more money, more time and more scope. We try to manage the randomness by trying not to:

- Estimate in detail, since it can't be accurate anyways so why bother taking so much time.

- Estimate precisely, we try using range or complexity rather than hours or days 

- Estimate big stories vs. try to bite off small chunks, 

But I still have seen fellow team members trying to be accurate while providing estimation. So how about we stop estimating and instead start sizing using Story Points. In brief, Story Points are meant to offer a way to size user stories. For instance, a user story might be marked as small, medium and large. Another way to size stories is to use fibonacci sequence like 1, 3, or 5 etc. I don't want to discuss Story Points in this blog. It is another topic on it's own. 

We can figure out some abstracted buckets with team and use them in our grooming/planning conversations. Those conversations will move lot quickly since the amount of debate between developers is dramatically reduced. We should always look back later to see how we did and adapt. We want to have discussion around good user story but not waste our time on how it's estimate looks like :). 

Let's RIP ESTIMATING! 

Manisha

Looking at Feedback using System Lens

This is the second blog in the "How to delivery effective feedback" series.  You can read the first blog here. 

"System thinking begins when first you see the world through the eyes of another- C West Churchman".   

Like any other topic, feedback can’t be understood completely without using system lens. As we all know, System theory has a very simple premise, everything is a system, and system are made out of small system.  So as per system thinkers, what do you believe a feedback can be?    A SYSTEM!!! (Yayyy!! You got it)

System lens provides us a wide-angle view of a situation. It forces us to understand the art and science of inferring a behavior by developing an increasingly deep understanding of underlying structure/surroundings. To get an deeper view of the word system, please read my previous blog. If you think yourself as a system, you are constantly getting feedback (input) and you are constantly applying those input to produce desired result. Someone again gives you feedback based on those output. This is a loop and hence the origin of word Feedback Loop.

Feedback loop is a system which help us understand a behavior over time. There are two types of feedback loop.

• Reinforcing Feedback Loop 

• Balancing Feedback Loop 

Reinforcing Feedback Loop 

A feedback loop occurs when a change in something ultimately comes back to cause a further change in the same thing. If the further change is in the same direction it’s a reinforcing loop.

In other words, Reinforcing loop is where feedback either amplifies/accelerates a behavior or it suppresses/diminishes the behavior. i.e. it caused someone or something to be done more or less. An example of a reinforcing loop is Population Growth. As population goes up, so does births per year. As that goes up, so does future population. The loop goes round and round, growing exponentially until the loop hits its limits. 

Remember reinforcing loop is not good or bad feedback but they are one kind of feedback, which generate change in the same direction.

Balancing Feedback Loop
Balancing feedback loop is equilibrating or goal-seeking structures in systems and is both source of stability and resistance to change. Balancing loops are where feedback supports a system to stabilize and move towards a stable goal. Great example of a balancing loop is a Thermostat. Suppose you set the target temperature to 65 degrees. The higher the target the greater the temperature gap. The greater the gap the more heat that flows into the system. That increases the temperature. As this goes up the temperature gap goes down. It keeps going down until the gap is zero, at which point the system has reached the target

We have just scratched the surface here. Feedback loops are the main reason a system’s behavior is emergent. Please refer to "Thinking in Systems"  by Donella H. Meadows for further read. 

We will try to look at the Interconnectionbetween Feedback's elements in next blog. 

Enjoy

Manisha

How to deliver effective feedback?

I recently gave a talk on ways to effectively give and receive feedback at "Path To Agility" conference. This topic is so very important to me so thought of writing a blog on the same topic as well.

I divided my presentation in 5 parts. 

1) History and Importance of Feedback

2) Looking at Feedback using System Lens

3) Interconnection between elements of Feedback

4) Models for Giving Feedback

5) Models for Receiving Feedback. 

My goal for this blog is to share all the learning so we all can live in a state where we can constantly grow and be more effective with the feedback without getting scared. Let’s beginning.

"We can't solve the problems by using same kind of thinking we used to create them. - Albert Einstein". 

History and Importance of Feedback

I was wondering why we call it a Feedback vs. “Talking to each other” or “Get ready for humiliation”.  I found out the term feedback was coined in 1860s during industrial revolution to describe the way that outputs energy, momentum or signals are returned to their point of origin in a mechanical system.

In 1909 Karl Braum was using the phrase, feedback, to describe the coupling and loops between components of an electronic circuit. It’s only after world war 2 the terms begin to be used in industrial relationship when talking about people and performance management. Feed corrective information back to the point of origin, that would be you! The employee.

Did I mention the term performance management!!! I would like to share some numbers around it. Estimate suggests that 50 to 90% of the employee will receive their performance feedback this year. And across globe 825 million work hours (a cumulative of 94,000 years) are spent each year preparing for and engaging in annual reviews.  Oh Boy!!!! To successfully utilize these hours we really need to be good in giving and receiving feedback.

Feedback can be important for various reasons like “Identify areas of improvement”, “Motivate behavioral changes”,  “Help when you are  stuck”, “For  recognition” or “Tool for continuous learning”.  We all pretty much aware of it’s goodness.  But still to few of us the receving critical feedback sometimes feels like colonoscopy.  It is because receiving Feedback sits at the cruxs of two very human needs:

-       The need to learn and grow (which is so very hard wired in us).

-       The need to be accepted, respected and loved just the way you are now. 

The fact of feedback is making sure that how you are right now! is not A OKAY and tells us that there is something to change. Critical feedback will still going to hurt us but if we will remember few tips, we will be able to handle and engage in conversations more skillfully to attain maximum benefit . 

We will try to look at the Feedback word using System lens in next blog. 

Thanks

Manisha

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

Value of Sprint Planning meeting

As per Scrum Guide, "Sprint planning" meeting is held to identify/plan the work to be performed in the Sprint. It is a time-boxed event, where teams collaboratively plan the work of the entire sprint. Also, we should try answering two questions in the meeting :

• What can be delivered in the increment resulting from the upcoming Sprint?

• How will the work needed to delivery the increment be achieved?

In my mind, the Sprint Planning meeting should create a shared understanding of the piece of work. POs should make sure team understand the value and can visualize the real objective behind the work. 

Also, I don't like one big fat meeting. I am a big fan of backlog grooming meetings, which happens regularly and almost part of any scrum cadence. I would suggest doing it every day like stand-up. May be just after standup, team pick up one top backlog story and discuss with POs. They together try to understand the story. Doing everyday has following advantages:

• Not taxing to your brain: Since sitting in a long meeting for hours makes every one very tired. Towards the end, everyone just wants the meeting to be over and lose the sprint of asking questions.

• Keeps it focused: Doing one everyday is lot easier and PO feel less pressurized about the decision since it is not at the eleventh hour and he can give patient hearing to teams point without getting worries about the sprint commitments.

• Teams can re-iterate over single story multiple times and get proper clarity. 

• Team members are more involved during this mini planning session vs. big fat one. Also they are in the team space, which makes things lot simpler for them to look or clarify. 

• Sprint Planning meeting becomes a breeze. We finished our meetings in 30 minutes :).

I did face little roadblocks at times in this process: 

•  At times team member's memory needed to be refreshed because either they forgot or they were on holiday that day. 

We use to have three columns before backlog column:

• Feature/Story Requested - PO adds them to be in the backlog as per DoR

• Feature/Story Discussed - PO discusses them with entire team and they size the card

• Feature/Story Ready to be prioritize - It is ready to be pulled into the sprint

Never stop the collaboration because you have time pressure, would be my suggestion. Let me know things which you might have tried in your team.

Thanks
Manisha