Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Why Agile is not agile enough
| I ran into this article by Andy Hunt on the Pragmatic Bookshelf site, which is one of the well know publishers of Agile software development books. I particular liked the section with a quote from a software architect during an Agile workshop: “The theater I did in college has helped me more in my programming career than half of my engineering courses.”—Grant Gainey, Senior Architect Developer The article goes on to discuss how the improvisational skills learned in Theater are more in line with the kind of agility “Agile” is purportedly advocating. The bigger issue that was revealed to me is something I have been thinking of for quite some time in that the field of project management, both traditional and Agile and everything in between has suffered from the tyranny of left brain thinking. This is not surprising since the majority of people who have entered the field of project management are from construction, engineering and IT. So naturally the focus is still on process and analysis and nothing really much on what makes us do what we do. I know some of you Agile evangelist will argue that its focus is on people over processes, but I don’t buy that because none of the Agile methods go deeply into the humanistic aspects of why people do what they do and how they do it. In any event, I have to admit that I have lost interest in the Agile movement and in fact am getting quite bored of it. That’s not so say that “being agile” is not important! In fact, I think Agile is not agile enough. What’s needed is a broader perspective and one where we can learn from other fields. I’m finding that the field of behavioral economics provides a lot of empirical data that supports inferences on team motivation and dynamics and the quote above, and I may be biased since my educational background was in philosophy and comparative literature, highlights that we could definitely learn from the arts and humanities. My writings going forward will focus on this idea of agility that will make Agile more, hmm agile. |
Posted on: January 23, 2014 08:17 AM
| Permalink |
Comments (3)
The CAN-DO attitude of Lean 5S
| Here's a great introductory video from Gemba Academy on Lean 5S:
What I especially like about this video is its emphasis that these practices are important and easy to follow regardless what industry you work in and the type of work you're doing. But the most interesting part was the section on the origins of Lean 5S from Henry Ford's CANDO idiom:
Whether you work in software development or manufacturing doing Lean, the principles stay the same and as you can see, it doesn't matter where it originated since the practical and useful principles are timeless. |
Posted on: January 12, 2014 08:11 PM
| Permalink |
Comments (4)
Using object-oriented design structures for project agility
|
I read this interestingI read this interesting piece from the Dr. Dobbs website by Allen Holub, in which he argues for the use of object-oriented design principles to drive Agile software development projects. One area in particular that I like is the idea of adhering to the “Liskov Substitution Principle (LSP)”:
I read this interesting piece from the Dr. Dobbs website by Allen Holub, in which he argues for the use of object-oriented design principles to drive Agile software development projects. One area in particular that I like is the idea of adhering to the “Liskov Substitution Principle (LSP)”:
It should be possible to completely change the implementation of an object without the clients of that object knowing that the change has happened. You should be able to add, remove, or modify any or all of the fields in an object, replace all the non-public methods of the object, and completely replace all the implementations of the public methods. As long as the public interface hasn't changed, the users of the object shouldn't know or care that a change has happened. This principle extends to any sort of modularized system, not just OO classes and objects.
In an Agile world, following LSP gives you the freedom of changing implementation without the effects of that change rippling out to the rest of the program, and this property is, again, essential when constant change is in the picture.
More formally, LSP can be defined for an object oriented computer program where “S is a declared subtype of T, objects of type S should behave as objects of type T are expected to behave, if they are treated as objects of type T”. An important point to note is that the LSP is all about expected behavior of objects. One can only follow the LSP if one is clear about what the expected behavior of objects is. As this Wikipedia page outlines:
The Liskov substitution principle (LSP) is a particular definition of a subtyping relation, called (strong) behavioral subtyping, that was initially introduced by Barbara Liskov in a 1987 conference keynote address entitled Data abstraction and hierarchy. It is a semantic rather than merely syntactic relation because it intends to guarantee semantic interoperability of types in a hierarchy, object types in particular.
So what does this have to do with managing Agile projects? A lot and this principle could be applied to any type of project. From just the perspective of the agreed to software functionality scoped for an Agile project, there will be expected behavior of that functionality from the customer’s perspective. If you have thought through and solicited the correct requirements and have facilitated a modular design and flexible process like Agile, then you should be able to change the implementation if needed and still deliver the expected behavior without the customer ever knowing it.
Taking this further, any project whether using an Agile or traditional approach should always be incorporating a way to ensure modularity and flexibility so as to accommodate the inevitable changes without compromising the expectations of the customer for the agreed to deliverables.
I know this is common sense, but it’s not only intellectually interesting but an important reminder to be aware of these synergies in different fields to ensure you are providing the most optimal solutions for your projects.
I know this is common sense, but it’s not only interesting but an important reminder to be aware of these synergies in different fields to ensure you are providing optimal solutions for your projects. piece from the Dr. Dobbs website by Allen Holub, in which he argues for the use of object-oriented design principles to drive Agile software development projects. One area in particular that I like is the idea of adhering to the “Liskov Substitution Principle (LSP)”:
It should be possible to completely change the implementation of an object without the clients of that object knowing that the change has happened. You should be able to add, remove, or modify any or all of the fields in an object, replace all the non-public methods of the object, and completely replace all the implementations of the public methods. As long as the public interface hasn't changed, the users of the object shouldn't know or care that a change has happened. This principle extends to any sort of modularized system, not just OO classes and objects.
In an Agile world, following LSP gives you the freedom of changing implementation without the effects of that change rippling out to the rest of the program, and this property is, again, essential when constant change is in the picture.
More formally, LSP can be defined for an object oriented computer program where “S is a declared subtype of T, objects of type S should behave as objects of type T are expected to behave, if they are treated as objects of type T”. An important point to note is that the LSP is all about expected behavior of objects. One can only follow the LSP if one is clear about what the expected behavior of objects is. As this Wikipedia page outlines:
The Liskov substitution principle (LSP) is a particular definition of a subtyping relation, called (strong) behavioral subtyping, that was initially introduced by Barbara Liskov in a 1987 conference keynote address entitled Data abstraction and hierarchy. It is a semantic rather than merely syntactic relation because it intends to guarantee semantic interoperability of types in a hierarchy, object types in particular.
So what does this have to do with managing Agile projects? A lot and this principle could be applied to any type of project. From just the perspective of the agreed to software functionality scoped for an Agile project, there will be expected behavior of that functionality from the customer’s perspective. If you have thought through and solicited the correct requirements and have facilitated a modular design and flexible process like Agile, then you should be able to change the implementation if needed and still deliver the expected behavior without the customer ever knowing it.
Taking this further, any project whether using an Agile or traditional approach should always be incorporating a way to ensure modularity and flexibility so as to accommodate the inevitable changes without compromising the expectations of the customer for the agreed to deliverables.
I know this is common sense, but it’s not only interesting but an important reminder to be aware of these synergies in different fields to ensure you are providing optimal solutions for your projects.
|
Posted on: December 27, 2013 08:43 PM
| Permalink |
Comments (2)
Scrum is NOT Agile
| Anyone involved with Agile hears that Scrum is the most popular project management method within the umbrella of Agile practices. But Jim Coplien (one of the chief founders of the Design Pattern movement) argues that Scrum’s root is really not from Agile, but rather the Toyota Production System (TPS). I’ve heard him say this in various lectures, but in this interview he states this very directly: For now I have hope that the TPS ideals, and particularly as they are manifested in Scrum, can show teams how to marry complexity with planning. I think it’s important to point out that agility and TPS often have opposing foci and, further, that Scrum is more about TPS principles than about agile principles. Agile was a software-specific manifesto penned in 2001; Scrum goes back to 1993 or 1994. We can say that agile came from Scrum, very late in the game — not vice-versa. More realistically, they both emerged from a growing realization in the 1990s of the need to support complex system development. Scrum emphasizes the systems thinking components of such changes and I hope those prevail in the intermediate term. I actually agree with this and had actually written about this in one of my earliest articles for Gantthead. What do you think? Do you agree with this assessment or not? |
Posted on: December 05, 2013 04:50 PM
| Permalink |
Comments (25)
Be Agile with your emotions
|
As Agile practitioners, our focus imainly on things like how to breakAs Agile practitioners, our focus is mainly on things like how to break chunks of work down to manageable pieces, optimize and guide the performance of the self-directed teams, etc., but those are all items related to the focus of the work, the teams and the methods and not much on the emotion involved to allow that work to be done right in the first place.
 As Agile practitioners, our focus is mainly on things like how to break chunks of work down to manageable pieces, optimize and guide the performance of the self-directed teams, etc., but those are all items related to the focus of the work, the teams and the methods and not much on the emotion involved to allow that work to be done right in the first place.
Like it or not, our emotions play a large if not largest part in the success of our projects. The central idea in Agile of facilitating a collaborative and learning environment is predicated on the emotional stability of the management and teams involved and if this emotional aspect is not stable, then it WILL drag down the performance of your project no matter how well people “do” Agile correctly.
So it was nice to read this article on the Harvard Business Review on the need for “Emotional Agility”, for as the article states:
In our people-strategy consulting practice advising companies around the world, we see leaders stumble not because they have undesirable thoughts and feelings—that’s inevitable—but because they get hooked by them, like fish caught on a line... We regularly see executives with recurring emotional challenges at work—anxiety about priorities, jealousy of others’ success, fear of rejection, distress over perceived slights—who have devised techniques to “fix” them: positive affirmations, prioritized to-do lists, immersion in certain tasks. But when we ask how long the challenges have persisted, the answer might be 10 years, 20 years, or since childhood.
Clearly, those techniques don’t work—in fact, ample research shows that attempting to minimize or ignore thoughts and emotions serves only to amplify them. In a famous study led by the late Daniel Wegner, a Harvard professor, participants who were told to avoid thinking about white bears had trouble doing so; later, when the ban was lifted, they thought about white bears much more than the control group did. Anyone who has dreamed of chocolate cake and french fries while following a strict diet understands this phenomenon.
Effective leaders don’t buy into or try to suppress their inner experiences. Instead they approach them in a mindful, values-driven, and productive way—developing what we call emotional agility. In our complex, fast-changing knowledge economy, this ability to manage one’s thoughts and feelings is essential to business success. Numerous studies, from the University of London professor Frank Bond and others, show that emotional agility can help people alleviate stress, reduce errors, become more innovative, and improve job performance.
The idea of “emotional agility” is a great one and one that should be discussed and articulated more in the Agile community. I know as hardcore software engineers who currently dominate the Agile industry that you will perceive such things as “touchy-feely” topics that have no real bearing on your Agile projects, but consider that this is the most essential component of who we are as human beings and if Agile is such a proponent of a more “human-centric” approach to managing projects than this topic must be addressed.
This may be a topic for which I write a more detailed article!
So it was nice to read this article on the Harvard Business Review on the need for “Emotional Agility”, for as the article states: chunks of work down to manageable pieces, optimize and guide the performance of the self-directed teams, etc., but those are all items related to the focus of the work, the teams and the methods and not much on the emotion involved to allow that work to be done right in the first place.
Like it or not, our emotions play a large if not largest part in the success of our projects. The central idea in Agile of facilitating a collaborative and learning environment is predicated on the emotional stability of the management and teams involved and if this emotional aspect is not stable, then it WILL drag down the performance of your project no matter how well people “do” Agile correctly.
So it was nice to read this article on the Harvard Business Review on the need for “Emotional Agility”, for as the article states:
|
Posted on: November 17, 2013 09:17 PM
| Permalink |
Comments (4)