The Agile Manifesto in English - 17

Principles

Agile principles are concretization of agile values.  Agile manifesto lists 12 principles. These principles are iterated in the form of assertive statements.

12.     At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Do I know everything? Do you know everything? I am sure answer is NO. Even for a small subject, hardly anyone can claim that he know it all. We are learning beings.  

In any dynamic environment, we commit mistakes and learn from it and next time tries to do it better. In reality we all do small experiments. Most of the experiments fail; we learn from them and get ready for next one.

The main thing is learning from the failures. To learn from failures, we need to reflect as individual and team.  This is an ongoing exercise of improving self, to become more effective and efficient over time period.

Learning from mistake is not only true for devTeam but of stakeholders as well.

But before doing experiment, we need to analyses and understand the probable blast radius of failure. The consequences of failure should be analyzed well. To keep the impact of failure small, we do smaller experiments. Organization should also provide the support the teams and individuals for failed experiments.

Also reflecting should be a learning endeavor not the find the punching bag exercise. 

In scrum, kanban, and devOps frameworks, this principle is reflected in following practices:

• Daily Standup
• Retrospect meeting

 

The Agile Manifesto in English - 16

Principles

Agile principles are concretization of agile values.  Agile manifesto lists 12 principles. These principles are iterated in the form of assertive statements.

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

In traditional command and control hieratical management, boss knows the best and he know who can do what and when even how. But in agile way of working, those who would do the work are responsible for organizing the work as well how to do it.

This might be heresy for traditional management gurus but here you may have to consider few things in context to software development and maintenance:

• Software development & maintenance is mostly devoid of repetitive tasks. In most of the cases as soon some repetitive task is discovered, team automates it.
• In software development and maintenance interactions are mostly among individuals instead among machines and/or machines & human as in manufacturing and assembly line jobs.
• The general level of education of persons working in software industry is significantly higher than working in manufacturing and assembly line.
• Software development and maintenance  is in very nascent state of becoming engineering (if it can ever become!), it is still largely a craft
• Technologies underlying software development are changing very rapidly. 

Keeping these factors in consideration, it is observed that Taylorism does not work with software development and maintenance teams. Also do not forget that in Maslow’s Hierarchy of Needs software professionals are striving for top three. 

In “Drive – The Surprising Truth About What Motivates Us “Daniel Pink says that people are motivated by autonomy, mastery and purpose. In my experience, I find Pink is saying true and these factors are by product of any self-organizing team.

To create great software (so the different aspects of software like – architecture, design, and design), provide autonomy to software teams so it can self-organize.

A self-organizing team:

•  sets direction for itself;
• design performing units for its work;
• manages (allocation, reallocation, estimation, re-estimation, delivery, rework) and monitors its work;
• executes the work;
• sets its rules and norms to achieve goal;
• has feeling of ownership and commitment;
• is self-driven, pull out work for itself to meet goal;
• requires mentoring and coaching;
• asks lot of questions to understand not only requirements but to understand reasons;
• gives lot of suggestions;
• intra team communication is spread across formal and informal channels;
• continuously enhance skill set;
• has high level of trust among team members; and
• sticks together for long time.

In scrum, kanban, and devOps frameworks, this principle is reflected in following practices:

• Sprint backlog
• Retrospect meeting
• Estimation of work by devTeam
• Daily standup
• Visual information radiators

The Agile Manifesto in English - 15

Principles

Agile principles are concretization of agile values.  Agile manifesto lists 12 principles. These principles are iterated in the form of assertive statements.

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

As software development and maintenance proceed, all stakeholders learn and apply those new learnings to current and future work. But most of the time, we ignore the unlearning part. We hardly unlearn the things which are not relevant in new context. 

Just look into your product backlog, how many stories have become irrelevant because of changed context? You should delete them or at least archive them.

Use Pareto principle (80–20 rule) - 20% of invested input is responsible for 80% of the results obtained.  You may realize that you are tempted to delete most of the remaining 80% stories due to changed context.

In scrum, kanban, and devOps frameworks, this principle is reflected in following practices:

• Continuous product backlog grooming/refinement
• Prioritization of product backlog items
• Time boxed events