Core Agile Practices

WHAT are Core Agile Practices and WHY do we need them ?

There is a lot of noise in the Agile Development universe. There is a lot of talk about things that are not so important or that have too few coverage. There are some core practices fundamental for getting capability/skills for being/doing Agile. Many of them are in Extreme Programming (XP), but not all. Let's try to put them together.

Criteria to select practices in Core Agile - we need practices that:

• Backup Agile Manifesto values and principles 
• Backup Manifesto for Software Craftsmanship values
• Backup Agile core capability to respond to changes: quickly, often, even to late changes and continuously
• Have Lean effect on Lean: same practices has multiple effects on optimizing work, no waste and efficiency
• Are usually mentioned by the main Agile contributors and by the engineers/teams/organizations with great experience and results
• Are part of the "Sweet Spots" (Alistair Cockburn term) of effective/efficient/adaptive software development
    

A Core Agile Practice has multiple effects. That is definitely Lean !

Common core practices to most Agile Methods

• Working Software
• Iteration Modeling, Iteration Planning
• Retrospectives
• Small Teams
• Daily meeting  

XP - Extreme Programming core practices, adopted also by DA - Disciplined Agile

• Small releases
• System Metaphor
• Simple design
• Testing First Development (TDD)
• Refactoring
• Pair programming
• Collective ownership
• Continuous integration
• On Site Customer
• 40-hour week
• Coding standards
• Exploration, solution spikes

  Disciplined Agile/Agile Modeling extension to XP 

• Proven Architecture Milestone
• Requirements Envisioning, Architecture Envisioning
• Active Stakeholders Participation
• Look Ahead Modeling
• Model Storming
• Executable Specifications (TDD as ...)
• Consumable Solutions
• Rolling Wave Planning

Method-free core Agile Practices

• Clean Code 
• Clean Architecture

Why we need Core Agile Practices?

Core Agile Practices are not "Best Practices", but a set that will provide us the Adaptive-Lean capability that will address core software development problems/traits: incertitude & changes, complexity and knowledge work.
If we do not master a set of skills that offer such capability, our work will be ineffective and not efficient on domain basic, so also endeavors as tailoring and scaling will not give the desired results. Disregarding Core Agile Practices is a major pitfall using Agile.

 Disregarding Core Agile Practices is a major pitfall using Agile.

Why are not best practices? Mastering these practices should be a fundamental capability, but is not the only one needed. We will not always use the Core Agile Practices, but also others, depending on the context. So, best practices are context related, and Core Practices are domain related. 

Best Practices are CONTEXT related, and Core Practices are DOMAIN related.

Examples - getting Adaptive-Lean (... read Agile) capability using Core Agile Practices

• Implementing Adaptive capability  here
• Implementing Lean capability here

Bibliography and references

• Agile Manifesto - www.agilemanifesto.org   
• Manifesto for Software Craftsmanship - http://manifesto.softwarecraftsmanship.org/
• Extreme programming explained: embrace change, Kent Beck, Addison-Wesley Professional; US ed edition (October 5, 1999). Note: I strongly recommend this first edition for understanding Core Agile, over 2004, 2nd edition.    
• Agile Modeling – www.agilemodeling.com
• Disciplined Agile - www.disciplinedagiledelivery.com   
• Disciplined Agile: Prove Architecture Early - http://www.disciplinedagiledelivery.com/prove-architecture-early/
• Clean Coders series, by  Robert C. Martin
• Disciplined Agile Delivery:  A Practioner’s Guide to Agile Software Delivery in the Enterprise, 2012,  by Scott Ambler and Mark Lines - http://www.disciplinedagiledelivery.com/dad-book/
• Clean Code, Prentice Hall , 2008 , by Robert C. Martin
• Clean Architecture,, Prentice Hall , 2017 (coming soon), by Robert C. Martin
• Agile Software Development: The Cooperative Game, Second Edition, by Alistair Cockburn, Addison Wesley Professional, 2006;·        Chapter 5. Agile and Self-Adapting / Agile 

Agile products - an Agile "Missing Link"

Agile Manifesto: "Customer collaborations", "Early and continuous delivery", "Deliver working software frequently", "Business people and developers must work together daily".

Extreme programming: "Make frequent small releases.",  "This is critical to getting valuable feedback in time to have an impact on the system's development. The longer you wait to introduce an important feature to the system's users the less time you will have to fix it".

Scrum: Maximizing value delivery.

Yes,  all the Agile logic it is about serving the customer business by delivering value, early and often and by a close collaboration.

That sounds great, but it is only one viewpoint.

Our software should be developed in above mentioned manner ... The product must be able to follow the customer business...But that mean should be in proper shape for a such endeavor. It is that simple? I think it is a little more complicated.

In each moment of time, the product need to be easy and quickly adapted to some new requests that corespondent do some new business needs. It is that simple?

When time = zero. The product it is new and need to be deployed to more customers - there it is a big probability that many product features to not match to the business.

When time = several years. The product it is "old" by accumulating a lot of technical debt and the respond to the changes become slow.

We need to care about customer business, but in the same time we need to care about the product! 

There is a TWO WAY ROAD TO AGILE :

• Development to Business -  DELIVER VALUE to the customer
• Business to Development - INJECT BUSINESS into the product 

 "Delivering value",  "Delivering value",  "Delivering value" ... in fact there is more than that. The delivered product will "live" in the customer business process and need to be able to evolve and adapt with that business. The BUSINESS DNA must be injected into the product, in order to accomplish such goals.

Here some useful principles:

- adapt the product to the business

• with the same pace with early, continuous and frequently delivery of valuable software.
• with  close customer collaboration, "business people and developers must work together daily throughout the project."
• with "small releases" (~XP), because any big release will lose contact with the busines
• with  "constant pace indefinitely", that suppose low level of Technical Debt
• with a good visibility and work optimization via a a well refined Product Backlog

- keep this business clean: easy to read and change inside the product 

• "well crafted software", "technical excellence and good design" - that enhance adaptability
• "steadily adding value"
• Test-driven development - the business value is constantly and often checked and demonstrated
•  TDD sustain refactoring and refactoring sustain adaptability
• Clean Code and less Technical Debt
• System Architecture that serve the business concerns

(Quotes, principles and practices from: Agile Manifesto, XP, Scrum, and  Software Craftsmanship Manifesto)

There are two different Agile promises
- "We are Agile and currently we can serve your business" - management practices from Agile can support a such promise - such many of the Scrum Practices
- "We are Agile and we can serve your business now and indefinitely" - that need all the engineering parts that suppose "steadily adding value" , technical excellence and management of the Technical Debt.

The product level concerns: inject the business and keep that business clean are mandatory for that second and stronger promise.

Scrum: Stop saying methodology!

Often it is used the term methodology relative to the Scrum framework. Some says that these terms: method, methodology, process frameworks are equivalent. Maybe that could be true in common language and maybe not in specific domains as software development in particular, or for process management in general.
 

For Scrum,  it is better to listen the voice of its authors:

http://www.infoq.com/news/2010/08/kenschwaber-interview-part1

 >>>

Ken, the Scrum Guide does not say who defines the Sprint Goal. It also does not say who selects the person to be Scrum Master. It ALSO does not say who defines the super-important Sprint length (it is limited to 4 weeks of less, but the Guide does not say who decides the actual Sprint length.) In the current version, exactly how the Product Owner is selected is also somewhat vague.  Question: Is Scrum prescriptive enough? If so, why so and if not, why not?

What a fine line we walk between a framework and a methodology. A methodology tries to provide answers to all situations, to be prescriptive and complete. In doing so, of course, it would be so long and hard to parse as to be useless. All contingencies can never be posited or described. I’ve always erred on the side of brevity – let intelligent people find out the best approach, what works for them in their situation. Then they are free to change the approach when it is no longer appropriate.

The “black holes” that you describe above in Scrum would be easy for me to fill. However, I’d be filling them from my point of view, and the answers would become a methodology. As I find floundering in the holes, I try to fill them with Tips in the Scrum Guide, blog entries, videos, and even talks.

But I resist making the Scrum framework prescriptive. I hate methodologies.

>>> (Interview with Ken Schwaber, Part1 - by Dan Mezick on Aug 26, 2010)

"I hate methodologies" ! - Scrum was not intended to provide all the answers and the practitioners should find the best approach in the context . 

Anyway, the Scrum knowledge is organized in levels: the basic information could be find in the Scrum Guide.  Considering the amount o (and not necessary the content) there is few information in the Scrum Guide, but - in the same time - it is the most generic. More advanced knowledge could be found in other artifacts of the two authors: books, courses or as Ken Schwaber says blogs, videos, talks. Of course, this information is less generic, and sometime are even very specific case studies.

Another aspect is the engineering part - not explicitly specified in the Scrum, but if you read again, you can find some tips about aspects that need strong engineering practices. Jeff Sutherland helped Kent Beck on XP - Extreme Programming creation and has used from the beginning the engineering practices that are part of XP as pair-programming, refactoring and TDD (or A-TDD).  

Scrum is a lightweight framework, an Agile "method" that provide very generic aspects that helps to solve complex problems by offering some instruments to practically use the Inspect & Adapt  principle. Anything else you will need to add to the process remain at your decision in the specific context and according to professions rules.

 

Hyper-productivity - just a short run ?

The Scrum marketing claims Hyper-Productivity. Sometime is true, sometime it is not. That depends on who make that claim...Which is the best way to validate that? We can measure, for example, the team velocity for a period of few months. It is that a correct approach?

Maybe the most know and severe problem in software development is the accumulation of the undesired complexity - Technical Debt. The main consequence of a such debt is the deterioration - in time - of the overall productivity and quality. 

Short "hyper-productive" runs with a lot of accumulated debt it is not Agile and it is not Scrum. Remember the principle from Agile Manifesto that require "sustainable development": "The sponsors, developers, and users should be able to maintain a constant pace indefinitely.". Scrum suppose that you will assess your work progress using the criteria of "Done": no other work is necessary on that product part, and that include very few Technical Debt.

Anyway, this kind of  "shortness of breath" it is very common and we must be able to identify and address the root causes. One cause it is the lack of skills of the involved team of developers, but another is related to the management.

"So how can you incent a Scrum team to not make a mess?"

This is a very good question, proposed by Robert C. Martin, in the article "The Land that Scrum Forgot"  that could be found here (with a forward by Mike Cohn):

http://www.scrumalliance.org/community/articles/2010/december/the-land-that-scrum-forgot/

Spoiler (from the article): "If the team goes fast and stays clean, then there is a reward!"

Usually only the project viewpoint it is the of interest for the management, because is focused on short term results. Anyway, the overall business should remain steady, and we should be interested on the product internal state, the amount of the accumulated undesired complexity.

The Scrum proposed by Jeff Sutherland it is Hyper-Productive (!), because in the same package we will found the requirement for technical excellence and outstanding enginnering practices such as TDD. For a such performance you need to read more than Scrum Guide and you need more others Agile skills and knowledge.