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) –
  1. What problem are we trying to solve?
  2. Will Agile solve all the problems? Or will there be others that’ll need to be approached and addressed differently?
  3. Are the ways of working and the expected outcomes clearly understood by all the stakeholders and the team(s) on the ground?
  4. What is the common understanding of VALUE and is the focus more on delivering value rather than meeting schedules?
  5. Do we have a clear and well understood definition of MVP (minimum viable product) and is it something that gets refined with the stakeholders periodically, based on changing business/factors driving the market?
  6. Do we have the right tools (CI/CD) and/or practices (XP, DevOps etc.) in place to support continuous delivery of value (by making inspect and adapt processes transparent, effective and frequent)?
  7. While the teams may bend and twist the processes, and use the agile lifecycle management tools in the way they like, does everyone share the same mindset - the one that’s recommended in the agile manifesto?
  8. “A tool is only as good as the user is”, and if teams think that using the best tools in the market will fix all the issues then they’re digging their own grave!
  9. Are teams able to identify “waste” and eliminate it thereby leading to continuous improvement?
  10. How lean are organization processes? Do these processes allow teams to focus more on creating and delivering value rather than managing reporting requirements, creating/maintaining artifacts and appraising stakeholders of the progress?
More to come and if you all have more items to add to this list, please do. Signing off for today!
 
Happy reading,
Jasdev Singh (PMI-ACP, CSM)
https://in.linkedin.com/in/singhjasdev
 

Comments

Post a Comment

Popular posts from this blog

When you equate story points with time...

Image
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
Read more

What's the point in a story point?

Image
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 shi
Read more

In theory, practice is simple. But, is it simple to practice theory?

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
Read more