Practicing agile theory

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 man...

  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 ...

Well, by now I’m sure you must’ve understood about the topic of the post and what it is all about – servant leadership of course! One of the attributes of a scrum master is “being a servant leader”. But what are the attributes/actions that qualify a scrum master to be called a servant leader. Let’s look at some of them below – Serving others and not yourself; in other words, selfless management of team members Being a servant means you do not or should not command others. On a lighter note, does your housecleaner/household help ever give you instructions regarding what to do? No right?   Let go of the command and control that our traditional managers are used to exercise as part of their role, in your journey to become a scrum master.   Leading by example & helping people develop and perform as high as possible Think of the Scrum Master as a personal trainer who helps you stick with an exercise regimen and perform all exercises with the correct fo...

Almost every software development company today is rushing to adopt Agile scrum as their preferred software development methodology. Little attention is paid to the nuances of agile as can be understood from bits of conversations below - “The client wants us to deliver fast and so they want us to do Agile” ... was what I heard from an onsite person visiting the ‘xxx’ offshore office in India. “We are running behind schedule and need to expedite the delivery. Let’s increase the velocity of the team to ensure that we deliver on the date committed to the client” – was what my program manager said for a project for which the product backlog has been ever growing and the goal always looked far off without changing the delivery date. “We are doing agile, right? So why can’t you make this little change … what is the problem? – was what a business stakeholder said in a review meeting to the SOS scrum master. The business requirements were so volatile that they changed many a time...

Part 2 – Perception of points; views of stakeholders & the recommendation As discussed in part1 - " what's the point in a story point " post, product backlog is a collection of product requirements (stories, epics & themes) and delivers “value as a whole”. Scope of the product or size of the product backlog is a sum of the points of all user stories (of all sizes) in the backlog. Completion of backlog for a release is tracked by the key metric called “release burndown”. With time/days on the x-axis and total planned story points for the release on y-axis, the burndown shows the rate at which the team is burning these story points. It’s obvious that the faster the team burns down these story points, the sooner they’ll reach the goal (release goal). But should the focus be purely on burning points to reach the milestone? If the team’s focus is anything but delivering value by burning points and meeting the definition of done, the product/release i...

Part 1: talking of the point Story points are estimates of effort as influenced by the amount of work, complexity, risk and uncertainty ( https://www.mountaingoatsoftware.com/blog/what-are-story-points ). When we estimate with story points, we assign a point value to each item. The raw values we assign are unimportant. What matters is the  relative values . A story that is assigned a 2 should be twice as much as a story that is assigned a 1. It should also be two-thirds of a story that is estimated as 3 story points. Not delving into the details of how to estimate and what these numbers should be (linear vs. non-linear series or Fibonacci numbers), the focus of this post is to discuss how these points affect the life of a scrum team (development team, scrum master & product owner). A story adds “value” by delivering functionality that the business has asked for, and can/will use depending on whether the story is a part of potentially...

Theory vs. practicing the theory Part 3: Practicing Agile – “the other anchors in the sailboat called Agile”   As discussed in part 2 of the “theory vs. practicing the theory”, are people (management/business) the only possible challenges to successfully practicing agile? Well, they may be the ones, but they are definitely NOT “the only ones”. Trying to execute an Agile methodology without understanding it well, in itself creates problems in the long run. Organizations often choose to execute projects/programs using Agile without even being very clear about  (and this may not be an exhaustive list) – What problem are we trying to solve? Will Agile solve all the problems? Or will there be others that’ll need to be approached and addressed differently? Are the ways of working and the expected outcomes clearly understood by all the stakeholders and the team(s) on the ground? What is the common understanding of VALUE and is the focus more on deliv...

Theory vs. practicing the theory Part 2: challenges in practicing agile theory So … we looked at the agile manifesto and the “people side” of things that it talks about in part 1 of “theory vs. practicing the theory”. The second part focusses on - What makes agile theory difficult to put into practice? We’ll get a better understanding if we start by looking at who’s involved in software development using agile methodology (and I’ll stick to scrum here to keep it simple). Here are the key players –   The three roles in scrum : product owner (PO), scrum master (SM) and the develop ment team Various management roles (you can’t do away with management, can you?) – project manager, program manager, delivery manager, engagement manager or whatever name you like to give to that “authority” Business stakeholder(s) or those representing the market Project/program sponsor(s) putting their money into the venture Looking at the list of key players above, it do...

Theory vs. practicing the theory Part 1: recap of the manifesto This post on my first blog in the "agile space" talks about the theory of agile - the methodologies, frameworks etc. and discusses why it is difficult to practice what is suggested in theory. But first things first, let me tell you why am I obsessed with Agile! I love Agile, primarily because of the fact that it stresses on keeping things simple & focuses primarily on "people" and the "people factors" influencing software development.  If you look closely at the agile manifesto , below are some of the things you'll observe - Two out of four manifesto items are people-related - Individuals and interactions (over processes and tools) Customer collaboration (over contract negotiation) None of the items in the manifesto talk anything about processes to follow or "best practices", so to say! The manifesto doesn't stress on what tools or methodologies to use ...