According to Dalai Lama, Tibetans have a notion of contentment that they call chogshé [1].

There is no simple translation for chogshé in English, and since it is generally translated as "contentment". However, what chogshé really means is an absence of greed. Literary it means "knowing [what is] enough" or being able to find satisfaction without looking for more. In Portuguese, some people, more specifically the Spiritists, use the word "simplicidade" with this meaning. "Simplicidade" literally means "simplicity" but, in a more religious context, it has the same meaning of chogshé.

So contentment or "simplicidade", according to Dalai Lama, is "something like the virtue of moderation".

In my opinion, we have been living a quite unique moment on the software industry. So far, the old generations of professionals and researchers have accomplished a lot in terms of engineering, processes, algorithms, and the general understanding of computer science. The price we payed for so much accomplishments in so little time is that we became squared and structured. We were obfuscated by our own light. Our processes and systems became amazingly efficient but resulting in cold and sharp systems. For some time, we felt comfortable hiding our own imperfections on supposed UI limitations and well stablished paradigms.

However, Steve Jobs proved that the colorful and curved design is possible and essential. In addition a whole youth of "lazy" kids started making money with chaotic, non-structured, simplistic and pretty applications. They started to question: "Who needs Use Cases?". "Who needs software architecture?". "Who needs structure?"

My last two projects proved to me that the future is somewhere in the middle. We are learning the trade-off between excess and lack of structure. There is a way between Java architectural astronautics and stateless PHP programming. Please, I am not referring to a specific programming language, but to the software engineering and programming technics itself. (you can be very unstructured in Java if you want).

Here at CoffeeBeanTech, we are going to develop the second phase of our new product of Social Marketing. The first phase not only mixes Java with Ruby but also mixes different programming paradigms: procedural x declarative. I am very happy with the results. We still spend lots of time on Web idiosyncrasies imposed by IE and newer versions of Firefox, but it seems that it is a structural thing and has nothing to do with the software engineering itself.

During the development of the first phase, we paid the price of being more structured (some developers silently complained), but the fact is that now our software is very maintainable, stable, resilient and upgradable. I am happy with the results.

I am planning to repeat the same strategy on the next phase. This time, due to the nature of the business, the backend should be more structured. I am anticipating that my programmers will push for the technology, forcing the structure to accommodate existing GEMs. I shall counterbalance with architecture. This might be the price we will pay this time: pay more to develop without bend the ideal structure. The future benefit will be in performance and functionality. Not in stability and resiliency.

It seems that the very same ethical virtue of chogshé is valid in software engineering. We are learning what level of structure is enough. I hope that the next generation comes with this knowledge built-in on their operational system. In fact, it is up to us. We are their teachers. We need to open our minds and try to have a big picture of the historical moment we are living. Doing that, we see that there is no space for software talibans. Every language or every software engineering or programming paradigm has its application, and the virtue of moderation is the art of mixing them all. The virtue of knowing how good is enough. The virtue of chogshé.

--

[1] Beyond Religion - Dalai Lama

Last week I found myself pondering about Risk Management on Agile project environment. Google shows different opinions about that on the Internet.

I found people claiming that Risk Management is implicit in an Agile development environment and saying that it is not necessary to manage it explicitly. Those people claim that tracking risks "explicitly" in Agile is a waste. Team does that all the time with standups, review meetings etc. There is no need to track it explicitly. 

On the other side, a project is seldom contained in one sprint. So, others say that Risk Management is important and should be done explicitly.

I decided to ask Julia Checchia's opinion (http://linkd.in/qm3Pow)

Julia is the President of Project Management Institute (PMI) Sydney Chapter and has a very impressive resume. She is a lovely person and studies, teaches and lives project management with passion and energy.

Question 1

People have been saying that it is not necessary to manage risk explicitly on an Agile development environment. What is your opinion about Risk Management on Agile development environments?

Julia:

If anything, I believe risk management is even more important in agile. Risk management, ie. Identification of risks as well as opportunities is ever so important because given the 'small chunks' mentality of agile, a team may go substantially off track if the overall product goals and vision are not constantly revisited through a risk management review. 

Team meetings are meant to deal with issues, risk management is all about thinking of the impossible and assessing the impact on the overall business and project objectives.

Question 2

I understand and agree with you when you say that the Team may go off track if overall goals and vision are not constantly revisited. It is exactly the point of Agile. Between one "chunk" of work and another, the Team usually does a Sprint Review and (re)plan the next "chunk" of work based on the results of the previous one. Ideally, putting the team back on track.

Risk Management seems to be a good tool to be used on a Sprint Review meeting to detect when the Team is off track. But when is it too much? Vin, a reader of this blog, has a simplistic straight forward point of view: risk management should be applied "as the situation warrants". What that means?

As I have stated on another post, imprecision is a tool we use to reduce complexity. In the end of the day, what Agile does is using imprecision to reduce management complexity. In Agile, scope, schedule and roles became more fuzzy yet more tractable.  
Isn't it the same with Risk Management? Not explicitly identifying and managing risks seems to be a way to introduce imprecision and reduce complexity. Isn't Risk Management implicit when we revisit the goals and scope every sprint?

Another related question: I usually create schedules for my Agile projects, but I create them on another abstraction level, and I call them "roadmap" instead of "project schedule". Is there a way to do Risk Management in another abstraction level?

Julia:

Great long question! I would love to KISS the answer to be more “Agile”. Not sure if I managed. So, here we go...

Note that the basic principle of risk management is to assess:

1. enterprise environmental factors (organisation structure, market conditions, commercial databases, market trends, market innovation),
2. organisation process assets (outcome of other projects and organisation methodology),
3. resources,
4. project scope statement (vision, benefits, overall in scope, overall out of scope),
5. project management plan (the way we will deploy this project)   

to understand if there are negative influences that may hinder the completion of a project, project phase or “chunk”; or opportunities to accelerate the overall solution on a cost/time/quality perspective. 

I am not necessarily advocating a Risk Management Board with lots of heads thinking about what can go wrong, but a review that assess diligently whether there are opportunities or potential hindrances that can detract/attract the team from/to achieving the project objectives, product outcomes and respective business objectives. 

If the Sprint Review’s is all about the specific application scope then, the Sprint Review is not the most adequate forum for risk management. If however, the Sprint Review has a dedicated forum for assessment of the items ‘a’ to ‘e’ above, so, by all means, a Sprint Review is perfect to assess the risks. 

The matter of fact is,  if a project’s budget is a 100K, is developed by 3 -10 developers, is non-mission critical and will be used for entertainment for a non-demanding audience,  who would care about risks? On the other hands, try to put a project in production where the money of millions of people will be impacted by a resource badly trained who developed a piece of code which a newly acquired test manager assumed the developers knew what they were doing and let a “chunk” go into production without proper testing? 

And how about a newly available Microsoft component which was not available when you started your Agile project and when you were just about to start a new “chunk” development of a 99% similar Microsoft function which would take 1 month to deploy,  could be achieved with a Microsoft upgrade overnight? 

Type of risks above may express what Vin stated "as the situation warrants". 

In my opinion, imprecision of detailed scope of all the “chunks” before development takes place, can truly be a tool used to reduce management complexity. Nevertheless , when a “chunk” comes out of the production line, the “chunk” must be precise and its integration to the overall project must be precise or else you set a precedence for bad reputation, client and user dissatisfaction, low team morale, high operational incidents, high amount of problems to be managed in production, just to mention a few. 

I am not against “fuzzy” roles and responsibilities, ie when the developer is the business analyst who is the tester, the peer quality control, the implementer, the technician, the service desk, now... tell me is this realistic? Will “fuzzy” roles and responsibilities and imprecision increase accuracy, customer satisfaction, image and brand growth and team morale specially for mission critical applications? 

Sure you can create a risk “roadmap”, you can certainly create risk checklists (through domain expertise and lessons learned) with suggested risk response, with expected risk probability based on industry and technology knowledge, you can make risk management as simple or as complex as you need, it all depends on who you are delivering a project to. If it is mission critical, if the brand of your organisation is important, if your business growth is important, if customer satisfaction is important, if cost containment is important, assess your risks and opportunities and capitalize on your findings.   

I thought the link below was a very good link on agile risk management:

 http://bit.ly/oKEDh4

Question 3:

 Julia, thank you very much for your contribution! Your insights are valuable for Agile community. Do you have any final words or suggest any complementary reading?

Julia:

Rodrigo thank you so much for the attention, just some food for thought: everything old become new, before processes and methodologies were put in place there was agility because organizations relied on individual skills, there was little documentation, and risks were rather ignored because of sheer ignorance. We do not want to use Agile wrapped in ignorance, we want to use Agile for quicker, attainable and accurate immediate results. Brushing off risks in Agile may jeopardize the integration of all the components of the end-to-end solution.

Some time ago, I was having some beer with a friend of mine when she asked me: "What do you think about Astrology?". I said: "Well, as a scientist, I do believe that the influence of any celestial body on me is directly proportional to the product of its mass and inversely proportional to the square of its distance." She smiled at me: "If you do not know what Astrology is, how can you say that it is not good?".I had to agree: "Ok.. You win. Give me the number of a professional Astrologer".

One month later, I went to the Astrologer - yes, I had to wait one month for an appointment! The Astrologer was a nice and charismatic old lady. I immediately realized that she was "reading" me. Since the very first moment, when she opened the door, she was observing my body language, my vocabulary, my expressions, everything. She then started a psychic conversation about my day of birth, how it is related to planets and start, etc. This conversation was kind of amusing. She was very funny and make me relax and open myself, talk about my preferences and behavior. After half an hour of conversation, she started talking about myself and my future. At that moment I understood what it was all about. She classified me. She had a methodology to analyze me and find my psychological archetype. Knowing that, she knew a great deal about me and everything she said made sense.

I then realized that Astrology is an ancestral psychology. Based on centuries of observations of the human behavior, Astrologers found patterns and defined archetypes. As it was before the age of lights, some mysticism was used to explain the unknown. So the signs of Zodiac and their infinite combinations are nothing more than tools to simplify the complexity of the human nature and define clusters.A contemporary approach for what the astrologer did for me is the the Myers-Briggs Type Indicator (MBTI). As Romans used to say... Mutatus mutandi, it is the same: catalogue, describe and classify clusters and archetypes.

Well, what it is has to do with technology? Everything. Software is model. Astrology shows us how powerful imprecision is to reduce complexity. Even with lack of strong scientific methods and statistical tools, Astrologers did very well for centuries with Astral Maps and the hole Zodiac thing. 

Most of the decision problems we know are computationally intractable if we try the brute force. It is frustrating when you spend hours to have an exact and deterministic model of a problem to then figure out that it is not computationally tractable. In most cases, the pragmatic solution lies on the use of heuristics, imprecision an uncertainty. Just two examples: Approximate Dynamic Programming (ADP) and Fuzzy Logic. ADP allows us to address problems with far more complexity than are traditionally handled using tools such as linear programming. Fuzzy logic allows us to represent imprecise relations and do approximated reasoning.

If you ask me if I prefer a MBTI analysis or an Astral Map, I would say: "well, it depends on the Astrologer." The same on software...  What is the best modeling approach for a given problem? Well, it depends on the engineer and the user/business environment. No problem exists isolated from the real world. In one way or another, people are already solving it on their business. Humans are smart, we naturally and instinctively use imprecision and uncertainty to reduce complexity and cut corners. So why reinvent the wheel? Instead of remodeling it from the scratch, my advice is: explore the existing solution. Extract the heuristics and simplifications already used using tools like Fuzzy Logic and ADP. Find fast and first a good enough solution. Only after that try to improve in interactions, following Agile philosophy. 

To find uncertain and imprecise yet good solutions for complex problems it is necessary to be open minded. It is necessary to listen people and be opened to realize that the System Operator might have found a solution not yet found on PhD level books. It is just a matter of interpreting his myths and translating them to software. Fuzzy Logic, Rule Based Expert Systems, Neural Nets, ADP, and others, are tools that can be used for this translation and achieve a less complex and more tractable model.

Summarizing, as Engineer, I try to be a good "Fuzzy-Stochastic-Neural-Heuristic-Astrologer". :-)

One day a Java class asked an elder Software Engineer: "I keep hearing people talk about this thing called Software Architecture. Just what is Software Architecture?". The Software Engineer patiently answered: "Software Architecture is what surrounds you". The innocent Java class then asked: "but why can't I see it? Is it an UML diagram?"The Software Engineer smiled and said: "UML diagram is just a projection. Just one perspective. Software Architecture is within you and all around you. You were born in the Software Architecture. It envelops you just like your interfaces do."

Confucius said, "fish forget that they live in lakes and rivers;" Programmers tend to incarnate their own code. Doing that, they cannot see the Software Architecture, yet they do know what it is. (well, sometimes don't).

If you are a developer, try to keep the big picture in mind, even when you focus the details. 

Don't forget that your software lives in a sea of Zen.

*freely adapted from "Zen Speaks"

The Brazilian theologist Leonardo Boff once asked to Dalai Lama: "Your holiness, what is the best religion?" He answered: “The best religion is the one that gets you closest to God. It is the one that makes you a better person.” Leonardo Boff then asked: “What is it that makes me better?” He answered: “Whatever makes you more compassionate, more sensible, more detached, more loving, more humanitarian, more responsible, more ethical.” In my opinion Dalai's perspective also applies to software engineering and project management. The best one is the one that makes you a better person.

Early stages of software development is all about humbleness and sensibility. Mr customer wants you to help him understand his needs and bring value to his business. To accomplish it software engineers and project managers should see the world from the customer eyes. Understand what is behind his words. The true meaning of his sentences. For that it is necessary to put aside our own beliefs and our arrogance. 

During software design we have the opportunity to be more creative, organized and structured. As a foundation of something bigger, software design and architecture should be strong but also expandable and resilient. It is a reminder to revisit our own foundations. Are we strong, "expandable" and resilient enough? Are we getting too narrow minded or too focused on our own convictions (design patterns)?

Programming is an exercise of love and responsibility. To write a good piece of code, you should love what you do. Writing comments and follow codification standards is also an act of love. Love for your co-worker and your company. It is also an act of responsibility. Executing with love and happiness our tasks, spontaneously promotes the high level tasks and goals. 
Sharing your personal logs and concerns is an opportunity to exercise trust, and also humbleness. When you share, you open yourself. It is not easy. You must be prepared to share and receive feedbacks. It is also a reminder that we are not the center of the world. 

During stand-up or any other project management meetings, we have the opportunity to embrace diversity. We must remember that each person has his own way to act. From this perspective, controversial issues should be discussed with fraternity. Do not polemize. When you are systematically against an idea or someone you promote exactly the same feeling about you. That's action and reaction (Newton's third law). 

Testing... Oh testing... Is there a better opportunity to exercise patience?    

Each company or software development team has its own culture and its own processes. Dalai Lama gives us another perspective to make choices. We must not only take decisions that make sense from the technical and commercial point of view, but also decisions that make us better persons.

In practice, the theory is different, but nothing is more practical than a good theory!! In Software Project Management, Engineering and Architecture one size does not fit all. Agile, for example, is nice! But there are still people who need to realize that it does not negate everything else. Instead of being a Taliban software engineer, blindly following one holy book, I advocate we should follow a software engineering scrapbook.

Since the industrial revolution, we have been continuously improving our engineering methods. Having formal mathematical background we, engineers, instinctively try to create processes and specifications that are certain and indisputable. For many engineering areas, it is unacceptable when two people, following the same process, arrive on different results. The same applies to specifications and blueprints, we instinctively want them to be absolutely certain.

Software Engineering is an exception. In this case, the result of the engineering process is a product of our mere imagination, not a physical object of reality. This make specification and constructing process much more subjective.

Inspired on our previous experience on other areas, we first tried to have full control of the software production. After some time we realized that there is no such thing as a perfect documentation. As far as the documentation refers to reality, they are not economically feasible; and as far as they are economically feasible, they do not refer to reality. The same applies to process and planning. As far the project schedule refers to reality, it is not manageable; and as far as it is manageable, it does not refer to reality.

Agile software development methods came for the rescue. Among other things that I will not mention here, it assumes that the specification is not complete and the schedule is not detailed. It is a tool to manage complexity and uncertainty.

The problem I have been facing on last few years is that the new generation of engineers are blindly embracing a misleading interpretation of the Agile philosophy. For most of them, software requirement and architecture documentation is unnecessary. They do not even think on data model and algorithm complexity up front. When they do, they do it superficially.

It is clear for me that we moved from one extreme to another. As usual, the truth is somewhere in the between. Every segment of software industry is finding a different trade-off between formalization and agility. I had the privilege to lead the development of different nature of software products: algorithm intensive; client side GUI intensive; database intensive; web applications; embedded systems; and others.

On software development, my experience says that one size does not fit all. My advice is: do not follow the books - create your own. Your own scrapbook.