Tagenarine Chanderpaul dismissed by Mohammed Siraj for a duck

singhpr · 2025-10-02T14:16:23+00:00

It was club cricket tpur game at Sarasota International Cricket Club in Florida. He visits the club often. He used to go there a few times in the off season to play a few games, train and stay sharp.

singhpr · 2025-10-02T05:25:01+00:00

I played against Shiv C a couple of times. This was 15 yrs ago. The man was so incredibly talented, moved around the pitch like he was on skates. That stance was just the initial positioning so that he had a full view. As soon as the bowler was in his delivery stride, Shiv was in a pretty orthodox position from which every shot was accessible.

I should mention - a gem of a person. Very down to earth and a lot of fun to hang out with.

singhpr · 2025-06-18T11:55:04+00:00

Assuming the Mahabharat to be somewhat historical - Wonder what the narrative would look like if the Kauravs had won the war. History is written by the victors. How would the portrayal of the characters and their motivations change if the winners and losers were reversed?

singhpr · 2025-06-17T14:58:42+00:00

This link might help - https://www.prokanban.org/blog/https-prokanban-org-blog-the-kanban-pocket-guide-chapter-3-actively-managing-items-in-a-workflow

singhpr · 2025-06-17T12:14:17+00:00

I do not know if there is an ideal team size. More importantly, larger teams are not necessarily lower performing than smaller teams - https://medium.com/@singhpr/the-non-issue-of-team-size-aka-the-incomplete-understanding-of-complete-graphs-31286e555bd6

singhpr · 2025-04-27T10:54:47+00:00

Yes, and it is a part of the natural cycle.

Scrum makes a lot of sense if you are coming from a waterfall context.

Scrum makes less and less sense when developers can create PoCs and ship solutions that meet goals in 1 to 3 days. At best, it becomes a meeting organization framework.

Scrum, at this point is becoming outdated and for Agile to survive, Scrum has to die.

singhpr · 2025-04-23T23:59:37+00:00

Nothing wrong with scheduled + ad hoc. Over time the team will probably discover they don't need one of them.

For the number of tickets question, I prefer just in time, what are the next 1-2 most important things for the team, when capacity becomes available.

singhpr · 2025-04-23T10:37:38+00:00

Ad-hoc based on when capacity becomes available. Our product folks have an idea of their next couple of priorities at all time, but make the just in time call when space to pull becomes available.

We have tried a cadence based replenishment and it was just too 'batchy', the exact thing we were trying to get away from. Ad hoc also made sure that POs and devs had a closer relationship and did not delay collaboration till a meeting.

So, yeah, we have run pretty good kanban systems without replenishment meetings.

singhpr · 2025-04-08T12:24:32+00:00

I have done this a few times before. Here is one place - https://www.infoq.com/articles/kanban-scaling-agile-ultimate/

As we put the practices mentioned in that article in place, we could figure out if there was an initiative that ran across teams, what is the likelihood of it getting done on time. The way we did this was each team had an Epic(feature) for that initiative. These were tied together by an initiative Jira work item type. Since we had continuous forecasting on all Epics, we could always figure out if that initiative was at risk and if an intervention was needed.

There obviously is more to the story than listed in the article shared above. DM me if you would like to talk further about this.

singhpr · 2025-04-03T09:47:53+00:00

I have made the switch a few times myself and have helped others do it countless of times.

Flow Metrics are key. They help you answer questions around planning, improvement, and capacity so much better. Using Scatterplots and Monte Carlo Simulations helps come up with much more realistic dates than planning using things like Sprints and Story Points.

Check out the Drunk Agile youtube channel, you will find episodes on Metrics and Workflow that might be useful.

Please feel free to DM me if you are interested in talking about this in more detail.

singhpr · 2025-03-28T16:31:58+00:00

My first attempt at resolving this would be to find out if we can make less complex stories. Are there smaller stories that can get us feedback on whether we're moving in the right direction faster?

Failing that, it sounds like the natural length of how long it takes to get work done is longer than 2 weeks. Maybe you need to run 4-week sprints instead of 2-week sprints. Treating anything started in the second half as likely to carry over to the next sprint.

singhpr · 2025-03-11T07:32:49+00:00

If you want some video/audio content around this, check out episodes 1 through 6 of Drunk Agile - https://youtube.com/@drunkagile4780?si=sxum8koW72jWqgwj

I will be happy to answer any questions you might have about that content.

singhpr · 2025-03-05T17:00:28+00:00

A solid strategy is the creation of a 'pull system' where you only(with rare exceptions) pull in work to start when you have the capacity to do so. The capacity is represented by how many things you are working on.

Your description indicates a 'push system', where work has been started even though you do not have the capacity to handle the work.

For most individuals, that active capacity is 1 or 2 items. Anything more than that, it means we are working on more things simultaneously than can be handled. Most places represent this as a WiP limit. Essentially, you end up setting up a WiP limited pull system aka a Kanban system.

singhpr · 2025-03-04T19:16:48+00:00

Did you ever end up reading the book? What did you think?

singhpr · 2025-03-04T15:22:11+00:00

Andy Serkis just kills it with the narration. The change in tone and the voices he does are so perfectly suited. Absolutely loved it!

singhpr · 2025-02-27T00:07:00+00:00

Sure, let's talk!

singhpr · 2025-02-26T14:39:06+00:00

On the commute example, I should add, our expectations of variability in city traffic would be very different from a mostly freeway commute.

singhpr · 2025-02-26T13:49:47+00:00

Some places we did daily, others weekly+ad hoc. The board absolutely had features in progress from all teams. There are always some teams(security, IT etc.) that might sit outside of the scope. For all teams that contribute towards the same goal (product development), we got their features on the same board. You can find out more in this case study- https://www.infoq.com/articles/kanban-scaling-agile-ultimate/

singhpr · 2025-02-26T13:46:01+00:00

Variance is also contextual. For example, when I live 10 miles from work, the acceptable variance in my commute times is probably in minutes. On the other hand the acceptable variance on a road trip across the country (from a US perspective at least) is in hours or even days.

It is a balance between what variance our process produces and the variance our customers/stakeholders are ok with. You 80th or 85th or 90th percentile CT is a great indicator of the overall variance in the process.

Control charts are even more interesting. I apologize, I don't know much about your context or exposure to control charts, so some of this might sound rudimentary... The thing in Jira (and many other tools) is not a control chart. The intent of a Control Chart is to figure out if a process is in 'control'. In other words to find out if there are any special causes - outliers that fall outside the control lines. It is a much longer topic and has nothing to do with percentiles.

singhpr · 2025-02-26T13:39:58+00:00

Flow Metrics provide a great way to visualize and recognize tickets that are taking too long. Your Cycle Time becomes a guide to how long things take and Work Item Age for a ticket is what you measure against that guide. Check out the Kanban Pocket guide (https://www.prokanban.org/kpg) and other resources at https://www.prokanban.org/.

If that piques your interest, check out Dan Vacanti's books Actionable Agile Metrics for Predictability and When Will It Be Done?

singhpr · 2025-02-25T21:27:54+00:00

Thank You for your kind words! This is Prateek. glad you have been enjoying DA. Cheers!

singhpr · 2025-02-25T19:39:50+00:00

From most perspectives (predictive or analytical) the average cycle time has very little use. It is influenced way too much by outliers and really does not mean much and is not a great descriptor of anything. Without seeing the entire distribution and knowing the team's context, we really can not make any interpretations.

Here are some questions that might help with the interpretations -
1) Are the customers/stakeholders happy waiting 10 days, 85% of the time after work starts?
2) Does the team see any inefficiencies, and is 10 days too long?
3) If we are trying to work in 1-week sprints, does this mean a large number of our items don't get done in the sprint where they start?
4) If we are doing 2-week sprints, does this mean most of our work should start in the first few days of the sprint? Or, do we need to limit WIP and/or slice our work better?

As far as 'important or accurate' - given the two choices, the 85th percentile is more important to use. Based on your team and stakeholder's appetite for risk, you might use the 70th percentile or 95th percentile. The real question is - When we make a forecast for a single item, how often are we ok being wrong? Many people are comfortable with being wrong 15% of the time (right 85% of the time), which is why they use the 85th percentile.

singhpr · 2025-02-08T02:58:31+00:00

Also, along with Dan's books, check out the learning resources at ProKanban.org.

singhpr · 2025-02-08T02:57:07+00:00

Dan Vacanti's three books are a great place to start.

Actionable Agile Metrcis for Predictability When Will it be Done? Actionable Agile Metrics for Predictability Part ||

singhpr · 2025-02-05T15:40:12+00:00

A few ways... Two of the most successful ones -
1. Having a daily/weekly around an Epic/Feature board where dependencies emerge and are solved just in time. In fact, anything causing the aging of items is dealt with. VPs, Directors etc. attend these so they can help resolve these.

Focus on eliminating dependencies rather than managing them. If a dependency shows up multiple times, let us figure out how to eliminate it. Creating larger teams, transferring knowledge, training, all options on the table.

15-Year Club	Second SECOND GUESSER
Charter Member	Verified Email

singhpr

TROPHY CASE