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