The Implicit Agile Principles

The Implicit Agile Principles

 

The essence of Agile is supposed to be brought out by the Manifesto and 12 principles. However, there are few Principles which I believe are extremely critical for ‘Being Agile’, and these appear to be either unstated or implicit. Following are the ones I could think of:

  • Build Quality In

 It’s quite surprising that the word ‘Quality’ does not find a mention anywhere in the Agile Manifesto and Principles.  Better quality is perhaps one of the most underrated benefits of Agile (assuming Engineering Practices are also implemented, Practices like writing Acceptance Criteria upfront, Test Driven Development and Test Automation, combined with QA collaborating with the BA and Developers throughout the development cycle has resulted in Quality usually being a non-issue. Agile promotes the notions that Quality is the  responsibility of every single member of the team and that Quality is to be built in right from the beginning.

 If the list  12 principles is to be expanded, this principle should be right at the top of the list

  • Shorten Feedback Loops

Almost all Agile Practices help in getting early and robust feedback from various dimensions:

  • Feedback from the ‘Product, through Unit Tests and Continuous Integration
  • Feedback from the Customer, through Acceptance Tests and Showcases
  • Feedback from the Team, through estimation and scheduling based on prioritization
  • Feedback within the Team, through Retrospectives
  • Feedback between the above mentioned entities

 Shortening feedback loops across all entities as mentioned above helps to take corrective course of actions more quickly and effectively, and also enables a culture of Continuous Improvement

  • Fail Early, Learn Fast

A principle similar to Early Feedback, this principle too is extremely valuable for both Business and the Development Team. Businesses love Agile because they can the MVP to the market, and come to know if early if it is not going to work, thereby save on costs which they would have to spend if they had taken the ‘Big Bang’ approach. By showcasing Working Software at frequent intervals, any mismatch between expectations of the customer and what has been developed can be identified early  Engineering Practices like using Assertions in Unit Tests can help detect typo mistakes immediately, which can otherwise not only lead to, for example,  mysterious slowdowns of thee system, but also make it quite difficult to detect the defect. Given that the cost to fix a defect rises exponentially from the time the defect the defect is to introduced to when it is fixed, the ;fail fast’ principle in writing code is immensely valuable.

Agile recognized that if failure has to happen, it should happen early so that it provides an opportunity to learn/correct and, as in case of Early Feedback, adjust course more quickly.

  • Practice Brutal Transparency

 Transparency is an absolute precondition for being truly Agile. Transparency helps in avoiding unpleasant surprises, mitigate risks and, most importantly, build Trust.  Transparency is about having the Courage, a core value of both Scrum and XP, to share bad news early, about acknowledging one’s limitations and asking for help, about making the work pipeline and key metrics visible through ‘single source of truth’. 

This is probably the most difficult principle to follow in true spirit. However, without Transparency, chances of succeeding in implementing Agile are very bleak.

  • Accuracy over Precision

Given the nature of software development, and perhaps any other knowledge driven work, the unknowns and uncertainties between providing the estimate and delivery are far too many. The situation was very similar to days of ‘Carpet Bombing’ when technology was not advanced enough to deal with the uncertainties between the dropping the bomb and it reaching the target. Being precise about dropping the bomb on the target was not working and hence multiple bombs were dropped with the hope that at least one or some would hit the target.

The reason why Estimation and hence Planning have much more credibility is because Agile recognizes that precision is immaterial and it is accuracy that matters.  How useful it is the precise estimate that something will get done in 11.75 days, knowing very well that it is highly likely to change, or that it will take approx.. 2 weeks, for planning purposes? 

Agile is helping us move away from having pointless precision to having meaningful accuracy. Hence, this principle, though explicitly unstated, is quite important.

  • Embrace Discipline

One of the stated 12 principles is ‘Build projects around motivated individuals’. There is perhaps an implicit assumption here that motivated individuals, who belong to a self-organizing team, are disciplined. In reality, this is often not the case, as the importance of discipline is not clear in the stated principles.

Agile is about team enjoying autonomy, and also about team practicing ‘brutal’ discipline. Imagine the amount of discipline which is needed to deliver working software regularly at very short intervals. Examples where discipline is always expected include the ‘ceremonies’ (stand up meeting etc.), writing unit tests, regular check-ins etc.  Discipline is an essential ingredient of a self-organizing team, which is such a critical element of Agility.

Can you suggest additions to this list?

Rekha Narayan

Program Management. Transforming Organizations. Leading Teams and Programs.

9 年

@Sunil Mundra - my view on fail safely is around teams and people feeling safe in attempting and failing. Failure commonly leads to the blame game in most organizations so sometimes people try not to report it or mask the issues. An agile culture opens up the team to admitting and most important, learning from failure safely.

回复
Adrian Lander -Agile Practitioner, Coach, Board Advisor, Author

Independent Professional-, Agile & Senior Management Coach | Trusted Advisor | Founder & Co-Author Agnostic Agile (NPO) | Co-Founder & Co-Author Agile 2 | Change Catalyst | SW Developer | 15K+

9 年

@ Sunil, there is some overlap there, I agree. When I first saw your post the table did not show. I love maximising the art of work not done. And that comes from simplicity, or discovering the real highest needs. Work smarter, not harder. Discovering the level / detail of work needed also reduces "work not done" - but from a slightly different angle. Just in time sometimes I compare to the concept of "lazy evaluation". Making deciscions when they are really needed and we have more info - "automatically from the process, anyways" - also reduces work.

Rash Khan

Engineering Digital Agility

9 年

Great thought proviking article Sunil! Thank You. I would add, 'Focus on being consistent not fast'. Faster delivery is an 'outcome' which will take care of itself if we are consistent across the board in our Agile practices and most importantly Agile Mindset.

Rekha Narayan

Program Management. Transforming Organizations. Leading Teams and Programs.

9 年

Fail early, fail fast and fail safely. Promoting safety while failing is key to creating and fostering a great self organizing team.

回复

要查看或添加评论,请登录

Sunil Mundra的更多文章

  • The power of a small gesture

    The power of a small gesture

    Today I got the opportunity to give a talk to the students doing their Master’s degree at my Alma Mater, viz. School of…

    9 条评论
  • Distributed Development Enablers Part 2: Process

    Distributed Development Enablers Part 2: Process

    In this series of articles on Distributed Development, this is the third article. The first article was about…

  • Distributed Development Enablers Part 1: People

    Distributed Development Enablers Part 1: People

    Having examined the Challenges of Distributed Development (https://www.linkedin.

    6 条评论
  • Challenges Faced in Distributed Development

    Challenges Faced in Distributed Development

    By definition, Distributed Development is difficult due to the ‘tyranny of distance’. In fact, in the early days of…

    14 条评论
  • From ‘Taylorism’ to ‘Druckerism’

    From ‘Taylorism’ to ‘Druckerism’

    It is an undisputed fact that Frederick Taylor’s work, ‘Principles of Scientific Management’ was path breaking and that…

    22 条评论
  • Be Like Salt

    Be Like Salt

    What does salt have to do with consulting? Please read my blog, published by ThoughtWorks, to find out. https://www.

    11 条评论
  • Where is code created?

    Where is code created?

    Are you surprised by this question? You are thinking the answer is so obvious, isn’t it? Of course, the code is created…

    14 条评论
  • Maximizing Benefits from Agile Adoption/Transformation

    Maximizing Benefits from Agile Adoption/Transformation

    Given that being Agile has a direct correlation with business benefits, viz. Time to Market, Efficiency, Quality and…

    19 条评论
  • Doing vs. Being Agile

    Doing vs. Being Agile

    Many teams believe they are Agile because they are following the prescribed Agile practices. E.

    43 条评论

社区洞察

其他会员也浏览了