Buddha’s fourth noble truth discusses how there is a path to the cessation of suffering. This is explained
in further by what is detailed in something called the eightfold path. In a nutshell (enlightenment
for dummies), I like to think of it as the middle ground. Not too self-indulgent but also not too self-
mortifying either. Or simply put ‘don’t fall into the trappings of compulsive living’. It also describes
the nature at which craving, clinging, ignorance, delusions and such will gradually lesson as you make
progress on the path. This path also covers many lifetimes so patience is a virtue.
This describes a perfection that is strived for but not necessarily obtained within this lifetime. Not too
different than the agile process when you look at from a philosophical view. One should visualize their
adaption of agile as something that has not yet achieved nirvana but should be moving along the path
towards it. It will take time to get there so once you accept that suffering is inevitable along the journey,
peace will follow.
Agile acknowledges that things may not always go smoothly by planning a retrospective meeting after
every sprint. This meeting provides the chance for the team to improve the process that makes them
work more efficiently one sprint at a time. To make this meeting strive towards nirvana, allow the
team to focus on an inward introspection versus an outward one. What I mean by this is that too many
organizations get wrapped up by what is written in text books or labeled by the word ‘repeatable-process’.
What should be happening, in my opinion, is introspection into what makes the most sense for the
individual company or team regardless of what is going on externally. This can facilitate a true root-
cause-analysis of what are some of the stumbling blocks to this team based upon the conditions specific
to that team and how to solve them. What is a solution for one individual or team to get to perfection may
not always be the same for others as they are each at a different juncture on the path.
What can be achieved by allowing the team the autonomy to improve their own process through creativity
and innovation is increased efficiency and velocity in my opinion. Some might even call that nirvana....
Tuesday, April 19, 2011
Wednesday, April 6, 2011
The Third Noble Truth of Software Development
Buddha’s third noble truth states that ‘The cessation of suffering is attainable’. This expresses the idea that suffering can be ended by achieving dispassion, the unmaking of sensual craving and conceptual attachment. The result is a state of Nirvana, which can translate to freedom from all worries, troubles, complexes, fabrications and ideas. Sounds great, huh. I don’t know about you but I’m ready for Nirvana right now.
The phrase ‘fabrications and ideas’ is interesting to me here. My first inclination was that this meant ‘design is bad’ as one should let go of having any idea of the future. Upon further examination, my opinion is that this is not necessarily translating into ‘design is bad’ but is more in line with the second noble truth in that the future is constantly changing. One can only truly design for today. Design is ‘good’ if it is simply a construct of how the product should evolve from a technical perspective but allow for a shifting future. This is one of the things I like about SOLID architecture principles in that my opinion is that it allows for this easily changing components. So now you have a ‘basic’ design in place using architectural principles such as SOLID to allow for shifting futures, how do you manage the day to day development team with the thought that cessation of suffering is attainable?
The beauty of Kanban is that by limiting throughput of feature requests or change in general, you limit the wandering of the mind into things of tomorrow that may never come to be. Suffering from a developers viewpoint occurs when time is wasted on events (or designs) that never come to fruition. The ‘worries’ of tomorrow can be shielded from developers by limiting the throughout of the backlog. The team only looks at what is truly prioritized for the immediate cycle. This acknowledges that the future is constantly shifting so why plan on things that you may never do. The product owner simply moves the next important requirement at the time into the backlog when one is needed for replacement. Only plan for what can be managed in the short-term of a release duration.
Developers pull an item from the backlog into the ‘in-progress’ bucket when they are ready for work. The in-progress bucket is also limited in throughout so that it reduces distractions as of the result of working on too many tasks at one time. The length of time for task completion can also be reduced by allowing for this mindful focus. Developers get the satisfaction of getting more frequent visualization of completed tasks and spend less time in wasteful futures planning.
So can Nirvana be achieved in software development? I like to think so and believe Kanban is the noble path to achieve this which leads us to the fourth noble truth which talks about the path. We will get into that discussion next.
The phrase ‘fabrications and ideas’ is interesting to me here. My first inclination was that this meant ‘design is bad’ as one should let go of having any idea of the future. Upon further examination, my opinion is that this is not necessarily translating into ‘design is bad’ but is more in line with the second noble truth in that the future is constantly changing. One can only truly design for today. Design is ‘good’ if it is simply a construct of how the product should evolve from a technical perspective but allow for a shifting future. This is one of the things I like about SOLID architecture principles in that my opinion is that it allows for this easily changing components. So now you have a ‘basic’ design in place using architectural principles such as SOLID to allow for shifting futures, how do you manage the day to day development team with the thought that cessation of suffering is attainable?
The beauty of Kanban is that by limiting throughput of feature requests or change in general, you limit the wandering of the mind into things of tomorrow that may never come to be. Suffering from a developers viewpoint occurs when time is wasted on events (or designs) that never come to fruition. The ‘worries’ of tomorrow can be shielded from developers by limiting the throughout of the backlog. The team only looks at what is truly prioritized for the immediate cycle. This acknowledges that the future is constantly shifting so why plan on things that you may never do. The product owner simply moves the next important requirement at the time into the backlog when one is needed for replacement. Only plan for what can be managed in the short-term of a release duration.
Developers pull an item from the backlog into the ‘in-progress’ bucket when they are ready for work. The in-progress bucket is also limited in throughout so that it reduces distractions as of the result of working on too many tasks at one time. The length of time for task completion can also be reduced by allowing for this mindful focus. Developers get the satisfaction of getting more frequent visualization of completed tasks and spend less time in wasteful futures planning.
So can Nirvana be achieved in software development? I like to think so and believe Kanban is the noble path to achieve this which leads us to the fourth noble truth which talks about the path. We will get into that discussion next.
Subscribe to:
Comments (Atom)