Practicing agile theory

Understanding Predictability in Agile Team Outcomes   "Understanding Predictability in Agile Team Outcomes" refers to the study or analysis of how consistent and reliable the results or achievements of a team practicing agile methodologies can be. This involves examining the factors that contribute to the team's ability to deliver on time and within scope, as well as identifying potential challenges or obstacles that may impact their predictability. By understanding these dynamics, organizations can better manage and optimize their agile teams for more consistent and successful outcomes. In today's rapidly changing world, the significance of accurate weather forecasts cannot be overstated. Similarly, in the world of software development, predictability is crucial for Agile teams. The ability to deliver outcomes predictably is a key factor in Agile team success. Achieving predictability can be challenging for Agile teams due to various factors such as capacity planning

Limiting WIP & reasons for high WIP My first post on Kanban  deserved a sequel for sure! While it isn’t possible to have literally no work in progress, the overall goal of a project team is to finish as many things as they can, and not be in a state of continually starting. Having too much #WIP makes this goal even more difficult.  The impact of too much WIP on efficiency and throughput is one of the reasons it is often regarded as a concern. According to studies, the cost of context change is frequently far more than people anticipate. It is evident that dropping one object and taking up another cannot be done in such a way that no time or energy is spent between the two. However, there is sufficient evidence to suggest that the loss is rarely worth the gain. These apparent consequences of having too much going on are easy to identify once you know what you're looking at. Looking around the team, you'll notice that there are many tasks open, few of which are done, and many

- A Key Ingredient for Agile Success Introduction: In the fast-paced world of software development and project management, staying on top of tasks, priorities, and progress is essential. The Daily Scrum, often referred to as the Daily Standup, is a cornerstone of the Agile methodology. It's a brief, focused meeting that empowers teams to synchronize, collaborate, and make data-driven decisions. In this blog post, we'll dive into the what, why, and how of the Daily Scrum to help you harness its potential for your agile projects. What is the Daily Scrum/Daily Stand-up? The Daily Scrum is a daily ritual (a scrum event) that brings the entire team together for a brief, time-boxed catch up. Its primary objectives are: Synchronization: Ensure that everyone is on the same page regarding the sprint goal and knows what to work upon given the priority. Collaboration: Encourage open communication among team members. Identify and Remove Obstacles: Highlight any impediments that need res

 -  Back to basics It has been more than 2 decades since the agile manifesto was incubated and eventually published. For those who understood the agile values & principles well, 'agile' has been more than a  word in the English dictionary - they have been living agile or being agile . The others, have 'generally' been doing agile with full cognizance & often, labelling it not good for managing project lifecycles - often calling it a misfit . No offence, but this population believes that "agile  is a gas pedal "  & just doing agile will help deliver outcomes faster & sooner . Talking of outcomes, quite often it is perceived that "no matter what project management methodology or technology you use, in the end - all that matters is the outcome!" Is it? Really?!? What about the journey or team hardship, change in plans (etc.) enroute to the destination or simply put  the outcomes ? This ability to change course/action plans is what I'

  A wise man once said-   Agile is more than just standing up and burning down!  Talking of KANBAN, one of the key principles is – Visualize the flow of work In other words,  "manage work instead of people" . It says "people tend to manage people because it's visible . If the work cannot be seen, the human nature tends to measure what can be seen, but that doesn't make it the right thing to measure"      Best,    Jasdev Singh ( S crum S ervant)

Here I discuss the curious case of mixing story points and person days and using them synonymously, not understanding what a monumental difference it is, in terms of arriving at a schedule using the two. While the team is using T-Shirt sizing (or planning poker) to come up with a backlog size in Story Points, they are using the words "Story Points" and "Person Days" interchangeably. As a prologue to my previous post https://practicing-agile.blogspot.com/2019/08/when-you-equate-story-points-with-time.html - the objective in this one is to find the answer to the question -  "How does a backlog estimate in terms of Story Points translate to how long will it take for the team to deliver the backlog, given that requirements, technology and a lot of various other factors influencing estimates are bound to change?" In other words, if the backlog size is 120 Story Points, its equivalent to saying that the backlog is worth 120 PDs of work! A derivatio

Agile becomes fragile! When you are "doing" agile (most likely because it's in vogue) but have not come out of the "sequential " SDLC execution syndrome or the traditional waterfall way of thinking and executing a project, you are most likely headed for a disaster! Of many things that may or will go wrong, is the estimation of work . The traditional methods of estimation like function-point analysis helped us answer the question - "how long (or duration) will a piece of work take to complete?". On the contrary, Agile keeps it simple and takes a minimalistic approach to estimation. In my opinion, estimation in agile is no rocket science as long as you are clear with the basics and understand "what story points are" and how to use them. Visit my blog post on story points for an understanding. Story Points vs. Time (Person Days) Mike Cohn shares a mantra that makes estimation easy - " Estimate size, measure velocity, derive

I n my earlier post , I discussed about self-organization/spontaneous order as a process, its trigger and the result of self-organization. In this process of self-organization, I also mentioned about "collective animal behavior" and the emergent properties of groups formed as an outcome of this behavior.   In this post, I go further to discuss about the formation of this group of animals and what's so special about it in a "non-homosapien" context. Allelomimesis: The act of any groups of animals swarming together in unison appearing as one m ulti-individual creature is a behavioral process known as ' allelomimesis '. The flight pattern emerging out of self-organization has multi-fold advantages for birds: The most obvious being that since each bird is slightly behind the next, all the birds can see the lead bird, and the bird immediately in front and to the side, allowing them to coordinate their flight paths and not cr

I start this blogpost with a visual illustration of what I had seen and captured in my "then new" Nikon D750 (Full Frame) , as an excellent real-life example of self-organization. Picture credit: "Lightnlens Fotographie" by Jasdev Singh| Web: www.lightnlens.net Self-organization , also called spontaneous order (in the social sciences ), is a process -  where some form of "overall order " arises from local interactions between parts of an "initially disordered " system . The process is spontaneous , NOT needing control by any external agent.  Trigger for self-organization: It's often triggered by random fluctuations , amplified by positive feedback . The resulting organization is wholly decentralized and distributed over all the components of the system. Such an organization is typically robust and is able to survive or self-repair substantial perturbation.    “Collective animal behavior ” is a form