Vu Tung Lam

Interesting thought from Rework:

The second something goes wrong, the natural tendency is to create a policy. "Someone's wearing shorts!? We need a dress code!" No, you don't. You just need to tell John not to wear shorts again.

Policies are organizational scar tissue. They are codified overreactions to situations that are unlikely to happen again. They are collective punishment for the misdeeds of an individual.

How true! You've probably come across ton of similar examples: "Someone has been Skyping all day!? We need to ban usage of any messaging tools during office hours!" "Some smelly code spotted!? We need to have formal coding standards and detailed guidance documentation that everyone signs off for!"

It is observed and shared by Bas Vodde in a recent Agile Singapore 2014 Conference event that when a company sees a problem, it creates a management role for it.

Continuous attention to technical excellence and good design enhances agility.

So your team has been practicing agile for a while now. It started off so well; your team delivered nice increments of working software consistently, kept retrospectively looking for room to improve, and in general made business stakeholders happy with visible progress. Perfect!

Well, almost perfect. Overtime you have accumulated a growing number of software defects, which never seems to beat those cool new features in pecking order to implement/fix. You introduced unit testing and refactoring but gradually those best practices find their place in a “guilt list” – things you know you should do but never quite get enough time to do it. Oh.. not to mention task estimation seems to be so wrong no matter how much “buffer” time you allocated. Your team’s velocity is getting unpredictable and you start to hear whispering over the wall whether agile works in your organization.

An excuse one often hears is that as the software gets bigger and bigger, so does its complexity and, thus, the required effort to add new feature or to make changes. However intuitive this logic sounds, the truth is complexity is a sign of technical immaturity; and the purpose of software engineering is to control complexity, not to create it (Pamela Zave).

If your project shares similar symptoms as above, maybe it’s time to call for rather dramatic actions: halt the whole new features development, go back to fix your code base, refactor your architecture, and eliminate the bugs. The next step is to commit to zero bug tolerance and enforced engineering best practices, unless you want to fall into the trap again.

If you fail to maintain technical excellence, you fail agile!

But it’s never too late.

(Photo credit: Lynne Cazaly)

Barely over 200 words, that manifesto become the foundation for a movement that has changed the world of software development forever. Endless writing and speaking has explored the various ways the manifesto could be interpreted, and many specific frameworks and methodologies (such as Extreme Programming, Kanban, Lean, and Scrum) have been developed to formalize its principles. A whole “Agile industry” has emerged, with successful companies offering tools, training, consulting, certification, and other products and services. The economic engine behind the Agile movement as a whole is massive. - forty.co

Manifesto

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Principles

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

Simplicity–the art of maximizing the amount of work not done–is essential.

The best architectures, requirements, and designs emerge from self-organizing teams