Bihar - Madhubani Arts

Madhhubani - Rural Art

Traditionally this art was practiced by women only to decorate their huts during religious and important occasions. Nowadays men have also taken up this art form and paintings are done on paper, cloth, canvas etc. But even though women in the villages around Madhubani have been practicing their folk art for centuries, the world at large has come to know about these women and to consider them to be "artists" only in the last thirty years. Even now, most of their work remains anonymous. The women, some of them illiterate, are in any case reluctant to consider themselves individual producers of "works of art" and only a few of them mark the paintings with their own name.


The colors used were traditionally derived from natural sources like plants, charcoal soot, ochre etc. Black color is obtained by mixing soot with cow dung.Yellow color is obtained from turmeric or pollen or lime and the milk of banyan leaves. Blue from Indigo. Red from Kusum flower juice, red sandalwood or rose. Green from the leaves of apple trees, White from rice powder, Orange from palasha flowers.


Madhubani paintings mostly depict nature and Hindu religious motifs, and the themes generally revolve around Hindu deities like Krishna, Rama, Shiva, Durga, Lakshmi, Saraswati. Natural objects like the sun, the moon and religious plants like Tulsi are also widely painted, along with scenes from the royal court and social events like weddings. Generally no space is left empty ; the gaps are filled by paintings of flowers, animals, birds and even geometric designs. Objects depicted in the walls of kohabar ghar (where newly wed couple see each other in the first night) are symbols of sexual pleasure and procreation.Legend says that this artform originated during the time of Ramayana when King Janak commissioned artists to paint pictures of his daughter Sita getting married to Rama.



A Madhubani painting in the Godana style by Chano Devi, depicting a scene from the myth of God Salhesa. (right) A painting of Goddess Kali in the Bharni style by Krishnakant Jha.

MITHILA, the birthplace of Sita of the Ramayana, lies in the state of Bihar, bounded by the Himalayas in the north and the rivers Kosi, Ganga and Gandak in the east, south and west respectively. Over centuries, the people of Mithila have developed their own tradition of art, popularly known as Madhubani painting, named after a district and a town in the region. What is unique about this tradition - which dates back to the 7th century A.D., and is prevalent even today - is that it is the women who mastered and practiced it.

In their earliest form, Madhubani paintings appear as aripana (floor paintings) and kohabar (wall paintings), done by the women of the Brahmin and the Kayastha castes. Painters today do it on paper. An exhibition of such paintings, titled "Mithila Paintings", was held in Kolkata from January 3 to January 12. It was curated by Neel Rekha, an art historian, whose dissertation on the women painters of Mithila titled "Art and Assertion of Identity: Women and Madhubani Paintings" is to be published shortly.

Traditionally, Madhubani paintings were made on the eve of certain rituals and ceremonies, such as pujas, vratas, or weddings. According to Neel Rekha, who has stayed with the painters and traced the roots of the folk art tradition, these paintings may have had their origins in tantric rituals. Mithila has from time immemorial been a seat of the tantric tradition, with strong leanings towards the Saiva and Sakti cults. The tradition found expression in domestic rituals, and that is perhaps why the art form was once restricted to women. But that did not stop the artists from transcending the domain of practical utility in order to create something exquisite from an aesthetic point of view.

Agile Methodology

What Is Agile?

Agile methodology is an approach to project management, typically used in software development. It helps teams respond to the unpredictability of building software through incremental, iterative work cadences, known as sprints. But before discussing agile methodologies further, it’s best to first turn to the methodology that inspired it: waterfall, or traditional sequential development.

Where Did Agile Come From?

In 1970, Dr. Winston Royce presented a paper entitled “Managing the Development of Large Software Systems,” which outlined his ideas on sequential development. In essence, his presentation asserted that a project could be developed much like an automobile on an assembly line, in which each piece is added in sequential phases. This means that every phase of the project must be completed before the next phase can begin. Thus, developers first gather all of a project’s requirements, then complete all of its architecture and design, then write all of the code, and so on. There is little, if any, communication between the specialized groups that complete each phase of work.

It’s easy to see how this development agile methodology is far from optimized. First of all, it assumes that every requirement of the project can be identified before any design or coding occurs. Put another way, do you think you could tell a team of developers everything that needed to be in a piece of software before it was up and running? Or would it be easier to describe your vision to the team if you could react to functional software? Many software developers have learned the answer to that question the hard way: At the end of a project, a team might have built the software it was asked to build, but, in the time it took to create, business realities have changed so dramatically that the product is irrelevant. In that scenario, a company has spent time and money to create software that no one wants. Couldn’t it have been possible to ensure the end product would still be relevant before it was actually finished?

Why Agile?

Agile development methodology attempts to provide many opportunities to assess the direction of a project throughout the development lifecycle. This is achieved through regular cadences of work, known as sprints or iterations, at the end of which teams must present a shippable increment of work. Thus by focusing on the repetition of abbreviated work cycles as well as the functional product they yield, agile methodology could be described as “iterative” and “incremental.” In waterfall, development teams only have one chance to get each aspect of a project right. In an agile paradigm, every aspect of development — requirements, design, etc. — is continually revisited throughout the lifecycle. When a team stops and re-evaluates the direction of a project every two weeks, there’s always time to steer it in another direction.

The results of this “inspect-and-adapt” approach to development greatly reduce both development costs and time to market. Because teams can gather requirements at the same time they’re gathering requirements, the phenomenon known as “analysis paralysis” can’t really impede a team from making progress. And because a team’s work cycle is limited to two weeks, it gives stakeholders recurring opportunities to calibrate releases for success in the real world. In essence, it could be said that the agile development methodology helps companies build the right product. Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace. In the end, a development agile methodology that preserves a product’s critical market relevance and ensures a team’s work doesn’t wind up on a shelf, never released, is an attractive option for stakeholders and developers alike.

The Scrum methodology of agile software development marks a dramatic departure from waterfall management. In fact, Scrum and other agile processes were inspired by its shortcomings. The Scrum methodology emphasizes communication and collaboration, functioning software, and the flexibility to adapt to emerging business realities — all attributes that suffer in the rigidly ordered waterfall paradigm.

business realities — all attributes that suffer in the rigidly ordered waterfall paradigm.

Scrum Methodology

For many developers in the software industry, the agile methodology is nothing new. Most folks know that agile was a direct response to the dominant project management paradigm, waterfall, and borrows many principles from lean manufacturing. In 2001, as this new management paradigm began to pick up momentum, agile was formalized when 17 pioneers of the agile methodology met at the Snowbird Ski Resort in Utah and issued the Agile Manifesto. Their manifesto is now considered the foundational text for agile practices and principles. Most importantly, the manifesto spelled out the philosophy behind agile, which places a new emphasis on communication and collaboration; functioning software; and the flexibility to adapt to emerging business realities.

But for all of the strides the Agile Manifesto made in revising a philosophical approach to software development, it didn’t provide the concrete processes that development teams depend on when deadlines — and stakeholders — start applying pressure. As a result, when it comes to the nuts and bolts of running a team with agile every day, organizations turn to particular subsets of the agile methodology. These include Crystal Clear, Extreme Programming, Feature Driven Development, Dynamic Systems Development Method (DSDM), Scrum, and others. At my organization, we use Scrum and I’ve found it to be an incredibly effective management methodology for everyone involved, including developers and stakeholders. If you’re interested in learning about the other agile methodologies, there are plenty of resources out there. This blog is designed to provide some essential background for those who are new to Scrum.

What’s Unique about Scrum?

Of all the agile methodologies, Scrum is unique because it introduced the idea of “empirical process control.” That is, Scrum uses the real-world progress of a project — not a best guess or uninformed forecast — to plan and schedule releases. In Scrum, projects are divided into succinct work cadences, known as sprints, which are typically one week, two weeks, or three weeks in duration. At the end of each sprint, stakeholders and team members meet to assess the progress of a project and plan its next steps. This allows a project’s direction to be adjusted or reoriented based on completed work, not speculation or predictions.

Philosophically, this emphasis on an ongoing assessment of completed work is largely responsible for its popularity with managers and developers alike. But what allows the Scrum methodology to really work is a set of roles, responsibilities, and meetings that never change. If Scrum’s capacity for adaption and flexibility makes it an appealing option, the stability of its practices give teams something to lean on when development gets chaotic.

The Roles of Scrum

Scrum has three fundamental roles: Product Owner, ScrumMaster, and team member.

• Product Owner: In Scrum, the Product Owner is responsible for communicating the vision of the product to the development team. He or she must also represent the customer’s interests through requirements and prioritization. Because the Product Owner has the most authority of the three roles, it’s also the role with the most responsibility. In other words, the Product Owner is the single individual who must face the music when a project goes awry.

The tension between authority and responsibility means that it’s hard for Product Owners to strike the right balance of involvement. Because Scrum values self-organization among teams, a Product Owner must fight the urge to micro-manage. At the same time, Product Owners must be available to answer questions from the team.

• ScrumMaster: The ScrumMaster acts as a liaison between the Product Owner and the team. The ScrumMaster does not manage the team. Instead, he or she works to remove any impediments that are obstructing the team from achieving its sprint goals. In short, this role helps the team remain creative and productive, while making sure its successes are visible to the Product Owner. The ScrumMaster also works to advise the Product Owner about how to maximize ROI for the team.
• Team Member: In the Scrum methodology, the team is responsible for completing work. Ideally, teams consist of seven cross-functional members, plus or minus two individuals. For software projects, a typical team includes a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers. Each sprint, the team is responsible for determining how it will accomplish the work to be completed. This grants teams a great deal of autonomy, but, similar to the Product Owner’s situation, that freedom is accompanied by a responsibility to meet the goals of the sprint.

Courtsey : Scrum Methodology