Cyber Agility – The Next Frontier

Could Virtual Reality (VR) and Augmented Reality (AR) be tools to enable distributed Agile teaming?

Co-location and pair programming are two of several elements in enabling high-performance agility. Soon, VR and AR could be enablers for a distributed Agile team while still maintaining the same level of high communication bandwidth that was previously only afforded by face to face communication. Before I go into my ideas on how this could work, I’d like to expand on why co-location and pair programming are so important to high-performance agility.

Face to Face Communication and High Performance

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

In 2001, the signatories of the Agile Manifesto got together to discuss “better ways of developing software”. I find it interesting that most of the manifesto is about people skills, and less about software. For example, “People and Interactions” is a core value and “face to face communication” a supporting principle.

The best way I know of to enabling face to face communication, is being co-located. The tighter the co-location, the more the interactions; hence having Agile teams sitting together in open office configurations.

My friend Mark Pearl pointed out on Twitter that the reason we strive for co-location, is that it is an enabler for collaboration. I'd agree with his assessment.

Pair Programming and High Performance

If a software team were to take on only one Agile practice, then I would suggest pair programming. Seriously! It has the biggest bang for your buck as it helps with:

• Moving from a group of individuals to a team (because of the bonding)
• Increasing code quality (pairing is an extreme version of code reviews)
• Increasing creativity and collaboration (a pair’s thinking power is more than the sum of two individuals)
• Removing silos (because of knowledge transfer)
• Improving code consistency (team coding standards)
• Creating a sense of ownership by the team (collective code ownership and story ownership)
• Continuous improvement (through coaching and mentoring, your B’s will become A’s over time)
• Specialist Generalists (pairing on tasks other than ones matching your core competency)
• Fun! (it’s incredible social)

I have found that pair programming can act as a foundational practice to other high high-performancee practices: merciless refactoring, continuous integration, test driven design/development, refactoring to patterns, DevOps, continuous delivery, coding standards, collective code ownership, clean code, etc.

Unfortunately, I’ve noticed pair programming is considered distastefully by some and is not practiced by many Agile teams. I put this down to either, people who have had a bad initial experience, or, to people having never tried it because it’s unintuitive and uninviting. I’m not going to try and sell you on it here, but will leave you with the advice that if you find yourself in one of these two categories, I hope you get a chance to experience pair programming one day the way it should be practiced.

Pair programming, and mob programming (an extension of pair programming), is easier when your team is co-located. And there is my second argument for co-location: in addition to better communication and collaboration, it makes pair programming a whole lot easier.

Virtual Reality and Extended Reality as Alternatives to Co-location (and office work in general)

While I am a big advocate for co-location and Pair Programming, I could be persuaded toward a distributed team model supported by the new emergent technologies of Virtual Reality (VR) and Augmented Reality (ER).

I think we could use VR/ER to enable distributed Agile teams in the very near future. Here’s what it might look like: your office will be in your home and consist of a keyboard, VR/ER headset and special gloves that you can see where your hands are in virtual space and in relation to your physical keyboard. You have arranged to meet your team for a daily huddle at a certain time and meet in virtual space; in a virtual team meeting room. In this room you can hear and see your team mates; well, digital renditions of them, and yourself. In this room you have access to a story map, an iteration story board, whiteboards, and computers. You proceed to sync up with your team and decide on your pairing partner for the next task. Or, you may even choose to mob program en masse or in a sub group on a task/story.

Once the team has self-organized into pairs or mob(s), they go to a chosen pairing/mobbing room in virtual space that can be customized to their heart’s content. For a pairing example; I may choose to sit in a desert and my pairing partner has chosen a field of poppies. In my reality, my pairing partner is with me in my desert landscape but in their cyberspace, I am in their poppy field. You can decide on whatever environment makes you feel most productive and happy.

Continuing with the pairing example: when I look to my left, I see my pairing partner. I pull up a virtual computer screen in the dimensions, font, colours, and theme that I am most comfortable with along with my preferred IDE (Integrated Development Environment) and keyboard shortcuts. My pairing partner might have something totally different but as long as our IDE’s are in sync, we can look at the same code. Off we go code crafting; free of interruptions to focus on the work at hand in our pair programming session.

Off to one side I have yet another screen that I can use to refer to anything else I may need in this pairing session without switching away from the code e.g. supporting documents, API documents. This would be much like having a laptop next to a pairing station in the real world.

To further this pairing scenario in virtual space: as we are crafting, a green interrupt notification comes up on our chat program. This indicates that one or other of our team mates or pairs has a non-urgent interruption. (There is also urgent and immediate interruptions that would alert us in other colours.) At the next convenient point in our pairing session, we open the chat session with the other pair and see what it is they want. “Hey Ron, which class was it where we…” At this junction we may choose to move to a mob programming room with the other pair, or a white board break out room, or just stay in chat mode. Can you see where this is going?

Working this way in virtual space, I would be on board with trying an experiment with distributed team members all working from home. I’m excited by this new technology and think that as well as Agile software development, most desk jobs will be conducted this way in the near future.

Until then however, I’m sticking with co-location as your best chance for success and high performance because of the higher bandwidth communication it offers and pre-requisite for pair programming. There are certainly some exciting times ahead and I eagerly await to see what experiments Agile teams take on in this space.

Supporting Articles

Pair Programming by James Shore

Sit Together by James Shore

Turn the Ship Around

This is not a blog as much as a link to a blog that I have published over on the FAST Agile website which I maintain.

I felt it had more to do with FAST specifically than agile in general so posted it over there.

The short summary is - the book "Turn the Ship Around! A True Story of Turning Followers into Leaders" by L. David Marquet is the best book I have read on the essence of agility.

Jenkins, You Can Take the Evening Off

Recently I was asked to participate on a panel organized by Electric Cloud to discuss Continuous Integration (CI). So I spent a day doing some reading and researching to polish up on my knowledge around the topic. Most teams I have worked with feel that because they have a CI server (e.g. Jenkins), then they are "doing CI". But I feel that this is not necessarily true and is only part of what CI is. In fact Automated Continuous Integration software did not exist when the CI practice first came to light so it can't be what CI is. Which raises the question, what is it?

An understanding of the history of CI will be important to understand why I am going to recommend that new teams learn CI without a CI server initially.

Note to users of Git – when you read commit or check in anywhere in this article, think Push.

History of Continuous Integration

Extreme Programming (XP) adopted the practice of Continuous Integration as one of the twelve core practices and brought it to the mainstream agile community. While CI is not part of Scrum, many Scrum teams have chosen to adopt CI as a best practice.

Kent Beck describes the word extreme in Extreme Programming to mean that he took common sense principles and development practices to extreme levels. In this way, when talking about integration testing - “If integration testing is important, then we’ll integrate and test several times a day (continuous integration)” – Kent Beck.

The What of Continuous Integration?

Continuous integration is the process of merging all developer working copies with a shared mainline several times a day.

The “several times a day” point is important as this was the evolutionary step away from a nightly build (which was the most common practice at the time).

"Mainline" is another important word to note. I'll talk more about that below in the section "Trunk not Branch".

The Why of Continuous Integration

The goals of CI are :-

• early feedback (XP value)
• avoiding merge hell
• supporting practice to collective code ownership (XP practice)
• encouraging simple design (XP practice)
• enabling merciless refactoring among a team (XP practice)
• ensure working software (the only measure of progress - Agile Principle)

All of the XP practices are there to enable refactoring. Refactoring is the core practice needed to architect a system with changing requirements.

Note that there is still no mention of CI servers or Automated Continuous Integration software yet. The technology did not exist when XP was born. This is an important point that has been lost to the masses who feel that CI is about having a CI server. I’ll talk more about where the CI server fits in later.

Early Feedback

Before CI it was common to run a nightly build. You would come in the morning to see if the build passed. That meant that your feedback loop might be as long as 24 hours! That is a big hit in a one or two week iteration (or Sprint for the scrum people). So it was important to integrate more often. We want to find out within a couple of hours if integration is going to work rather than a day. We want to find out within hours if there are architectural or design issues among the team, rather than a day or days. Days is not uncommon on teams that use Git and choose to work on separate feature or story branches and only merge them once the entire story is complete. This pattern can also cause "merge hell". Read on.

Avoiding Merge Hell

The more and longer you leave your code un-merged from the main branch, the harder and more time it can take to merge and resolve collisions. This becomes particularly apparent once a team adopts the XP practice of Merciless Refactoring. Within the scope a single task, the changes made to the codebase are not limited to the minimum amount to complete the task (a pattern seen in Scrum teams that do not adopt merciless refactoring), so can be numerous and might cover a broad swathe of application and test code.

Once the merges are numerous and there are many collisions, you are in “Merge Hell”. To avoid this, the pattern is to integrate your code every couple of hours. “No code sits un-integrated for more than a couple of hours. At the end of every development episode, the code is integrated with the latest release…” – Kent Beck Extreme Programming Explained: Embrace Change Chapter 16: Development Strategy

The mantra that I was taught when learning XP was to “Commit early, commit often”. This, I feel, is the first aspect of CI that a team needs to learn!

Collective Code Ownership and Simple Design

These benefits will become apparent in the Learning Continuous Integration section below under the headings with these same titles.

Merciless Refactoring

Once a team begins to refactor mercilessly, you will find yourself in merge hell more often than not unless you integrate with each others code frequently. If you have an agile code base (to support an agile project i.e. one where the requirements are changing) - you should be refactoring mercilessly. If you don't, you will be incurring technical debt and end up with a legacy system. I have written a blog on the topic of Iterating Toward Legacy which describes this in more depth.

The How of Continuous Integration

I recommend a team learn CI without a CI Server. (Which is what the title of this article is hinting at.) Once you have the core practices down, then, you are ready for a CI server. I like James Shore's description of How to Practice Continuous Integration. Probably the best I have read apart from the original white book by Kent Beck. Below are the core CI practices a team will need to learn :-

Note - We will assume that you have source control already set up and the team are proficient in it's use.

Automated/Scripted Build

Create scripts to build your code and have them committed to source control. This will often involve learning to use a build tool such as maven, gradle, grunt etc. Technically, you can still do CI without a scripted build but this is rare and so I will not cover it. The build scripts need to include running a test suite and failing the build should any tests fail. For more information on build automation see James Shore’s website on automated build or his book The Art of Agile. You can see an example script here.

The Ten Minute Build

This practice is a refinement on the automated build. Because we must run a complete build before we commit (or Push if you are using Git), then we need to keep the build to under Ten Minutes. This can be challenging for some teams who already have longer build times. You are able to do CI with longer builds – but the pattern is to try to reduce your build time in order to shorten feedback time, reduce collisions within a team and avoid build races.

Maintaining a fast build is an ongoing discipline of an agile team that requires a team to track the build time. It will require a team to change and refactor the build scripts and test code with the same attention that we give to our production code. In a team that is practicing Collective Code Ownership, everyone in the team is responsible and capable of editing these scripts, the source and test code.

Commit Early, Commit Often

In the early computer science days we were taught the mantra of “Save early, Save often”. With the advent of source control this became “Commit Early, Commit Often”. If you have gone a day without a single commit, it’s an indication that you may have gone down the rabbit hole of over complexity and need to roll back your changes and start all over again.

It’s not a bad thing when this happens - and it does happen. When this happens, you've learned what didn’t work and in doing so probably worked out how to break the problem down into smaller chunks and which order to tackle them in when you come back to it.

Trunk Not Branch

This one is always contentious with the git folk. If you are using git, it is not that you shouldn't create branches, it is that you need to merge your code with trunk with the same cadence that we spoke about above. Martin Fowler has an excellent article on the challenge of CI with Git. His closing line is a quote from Paul Hammant :-

"I wonder though, if a team should not be adept with trunk-based development before they move to distributed"

The reason that we stay on trunk is to avoid merge hell. If you must use branches, then try to ensure they are as short lived as possible.

Side note - In a highly distributed team this may not possible. But then being highly distributed is already an agile anti-pattern.

Side note - If you are considering Git for your source control then consider the Centralized Workflow implementation.

Build Token

This works best with a co-located team working in an open office space.

The idea of the build token is that when you are about to kick off a build on your computer (or for a beginner team a dedicated integration computer), you take the build token. This is a physical item that all the team recognize. In most instances I have seen, it is a rubber chicken or other similar frivolous yet fun toy that typically can make a sound when squeezed.

Whilst others are able to build without the token, they are unable to commit their code (by team agreement).

This practice is to stop a build race. As the holder of the token, if your build passes, then you are able to commit your changes to trunk. At that point you initiate the token’s noise and return it to the ready location. The noise is an indication to the room that they need to merge changes into the code they are working on ASAP. This is where the continuous part comes in. Because now you are continuously merging in changes and keeping in sync with the whole team and continuously integrating changes to head/trunk. (Actually, continually would be a more correct word if one was going to be pedantic.)

Refactor Mercilessly

When a team begins to really practice Merciless Refactoring, then in the scope of any task, you could find yourself in parts of the code that you did not imagine before you began coding. This is not to be discouraged. The knock on effect of this though, is that you are far more likely to be colliding on classes and methods with other team members. When these collisions happen, you want to find out sooner rather than later so the two pairs (assuming that you are practicing the XP practice of Pair Programming) can get together and have an architectural discussion to resolve. This is part of fast feedback and how emergent design works!

Emergent Design and Rapid Feedback

Consider that we were able to discover an architectural issue within hours (rather than a day) and can quickly resolve it thereby minimizing the disruption to the flow of coding and likelihood of having to roll back changes. Consider also how easy it is for a co-located team to resolve an architectural issue via a quick face to face huddle in front of a white board. This is one reason why XP recommends development team members being collocated. It increases communication and can eliminates time lost because of distance issues.

Were you only integrating daily instead of multiple times a day, how does it feel to come in in the morning ready to start a new task after a good days work yesterday, only to find that you need to go back and change the code from yesterday? Integrating 2-4 times a day enables a much finer grained level of Rapid Feedback. I believe the effort/cost of fixing issues increases exponentially over time. The sooner you find and fix it, the cheaper.

Simple Design

Another way to avoid collisions, and a pattern to refactor the code when you do have collisions, is to make classes and methods smaller. This is one of the rules of Kent Beck’s "Four Rules of Simple Design" and it's a good OO practice in general.

Simple Design is one of the XP core practices. I hope you are starting to see how all the XP practices work together and why you should take them all on as they are supportive of each other.

Side Note - If you are doing the XP practice of Test Driven Development (TDD), you will find it naturally encourages smaller classes and methods. See what I mean about the XP practices all working together?

Collective Code Ownership

Collective Code Ownership is another XP core practice. The heart of an agile project is a self-organized, self-managed team. (In XP that team is co-located and sit together in an open office environment. Scrum does not enforce this practice.) The idea of Collective Code Ownership is that anyone can edit any code. We are trying to break down silos of knowledge within a team. (Pair Programming is the quickest way to reach the point of Collective Code Ownership within a team.)

CI has been described as a prerequisite to Collective Code Ownership. By integrating often in the day, you will be keeping up to date with all the code changes that are happening by all of the team. You are staying in sync with all the team by continuously reading each others code changes every few hours when you integrate.

Step 2 - Automated Continuous Integration

OK Jenkins - You can come back now

Once the team has all this down pat, then it is ready for an Automated CI Build Server - such as Jenkins.

Again, this requires some learning and should be owned by the entire team now that we have established Collective Code Ownership. You do not need to throw away any of the above practices. Instead you now add to it. I highly recommend that a monitor and speakers be in the development environment so that notice of any build or integration failures found by the CI server are immediately obvious to the team.

The rule/practice for the team is this:-

The teams highest priority is to maintain a green (passing) build.

Should the build break, the team should stop everything, have a huddle to determine the cause of the break, identify who will fix and and make that the highest priority for the team. Swarming and/or mob programming is a good practice here.

While the build is red (broken), no one is permitted to commit any code (by team agreement).

Here is another brief description of an Automated CI process.

Continuous Deployment, Continuous Delivery(CD) and DevOps

These are whole topics in and of them self and also the latest buzzwords in agile. Core to these practices is the CI server. Some clever folks worked out these automated build machines can do more than just build and test. They can also become gateways, package, deploy, monitors, run broader environment and package testing. And so, Continuous Deployment, Continuous Delivery and DevOps were born. Enough said.

Closing and summary

I'm not going to go into any further detail on the uses or setup of a CI server such as build triggers, chained builds, breaking out test suites, stress testing, bench marking, testing environments, continuous deployment etc. They are each topics in themselves and take me away from the main topic of this article.

I'm hoping that you noticed the interrelationship between CI and all the other XP practices that have been mentioned in this article. The practices/disciplines are designed to work together in this way and work best when ALL of them are practiced. That is why I prefer to keep XP intact rather than breaking it into a smaller subset of the practices and calling them agile development practices or technical practices. Don't mess with Grandma's recipe. If you want CI, then do XP.

The main points I want to reiterate for my closing summary :-

The first rule of CI is - Check in Early, Check in Often

You should be be committing (and therefore building) your code 3-4 times a day. That is why they call it "Continuous"

CI is so much more than a CI server. Learn all the other practices before installing a CI server

Get adept with trunk-based development before moving to distributed

Do ALL of the XP (Extreme Programming) disciplines and not just part

Further Reading

Martin Fowler's blog article on Continuous Integration

Iterating Toward Legacy - Scrum's Achilles Heel

Of the various software delivery processes under the agile umbrella, scrum became the most popular and is the most common implementation of agile in Corporate America. I like Scrum. I like its simplicity. I think that scrum's popularity is due to the fact that you can get quick business gains because it is quick to adopt ¹. It is exciting to be able to watch a software system grow and change direction at will. This is in fact why agile exists and why it is called - agile. Managers like this concept and sign up for Scrum heartily for this benefit.

Technical Debt

There is an anti-pattern that I have noticed as a consultant working with Scrum implementations. While management is happy with their agile process and seeing new functionality being added every sprint, typically they are not budgeting for any maintenance.

In the early days, this is easy to get away with, particularly on a new codebase or greenfield project. However, unless you are cleaning up after yourself continuously (particularly if you are cutting corners in the sprint) and fighting to keep the code clean, you will be incurring technical debt. It is subtle in the early days, and you will not notice it, but it starts to add up.

The reason that we call it debt is that you need to pay it back at some point. The longer you wait to pay it, the more interest it has accrued and compounded. Not only are you not paying the compounding interest back, but you are also continuing to add to the debt by adding complexity to complexity and sloppy code onto sloppy code increasing the already compounded debt. The longer you leave the debt unpaid, the more effort and time it takes to fix the mess. This is what agile looks like without any discipline around cleaning up the code during each sprint and being vigilant to improve the architecture as it evolves. This is agile done wrong - which I see all too often in Scrum implementations, and has been called "Flaccid Scrum" ². To dig yourself out of technical debt, it is going to cost you - a lot.

In short, the scrum Achilles heel (or blind spot) is this:

 On a long term project / large product, scrum (done poorly) creates technical debt. Too much technical debt left unpaid results in a Legacy System.

Legacy Systems and Cost of Ownership

I was working with an agile client that had implemented scrum as their software delivery process. They were on the second version of their product. That is to say; they had re-written the first system and were very proud of their new second system which was now using more modern languages, technologies, and frameworks. They retell the stories of the horror of working in their legacy system. Stories like:

• it took weeks to deploy
• the code was hard to understand, and only a handful of developers knew how to work on it
• it was extremely fragile, and they were always breaking the system when trying to add a new feature or even fix a bug
• adding any new functionality took a long time
• the system was bug ridden
• bugs took a long time to find and remove

The bullet points above describe a legacy system. Any of it sound familiar? Alas, it is not an uncommon situation.

These are some questions that I asked to provoke thought and insight into how they managed to get into that mess in the first place:

• Did you have senior architects and senior developers when you created the original system?
• Did they intentionally architect a legacy system? (I'm being facetious on purpose.)
• Now you have a new system, what are you doing differently to ensure this doesn't happen again?

Ouch!

Then I point out that every day that I sync my laptop to their codebase, I am pulling in hundreds of new files. That is just not sustainable! They are on track to hit the same technical debt wall that they had in their original product and create a Version 2 Legacy system.

If you carry on sprint after sprint delivering business value while disregarding code quality and architecture, you will end up with a legacy system.

In a legacy system, the rate of adding new features decreases and the cost of adding features increases. You will not necessarily notice a drop in velocity however as the size of the stories starts to increase (to account for the complexity of working in a legacy system). Velocity will stay the same but the rate of adding new features decreases. (Which is one reason you should not use velocity as an indication of a team's performance.) You will also notice the bug count going up and much more time spent on fixing bugs. At this point, a business knows that things are going slow, but it can't work out why and starts to lean harder on the engineering department to produce more, which only results in them cutting more corners, writing more bad code and compounding the mess.

Once a company realizes that they have dug themselves into a technical debt pit, they scramble to get out. A typical (anti) pattern I see is creating technical debt stories (or even sprints!), refactoring stories and technical stories. If you find yourself doing this you need to change your development process as stories, by definition, are supposed to come with business value. More information below on how to improve your development process.

You pay for quality one way or another. You either pay for it as you go (by building quality into your process) and create a system with a low maintenance cost that you can continue to build on, or you pay the price toward the end of the project (where it now costs more) and have high maintenance costs. The option that makes most economic sense is to pay your debt as you go.

The solution to technical debt - Refactoring (Mercilessly)

The only one tool to stop the natural code entropy toward technical debt is - Merciless Refactoring.

Code Refactoring Definition :  Code refactoring is the process of restructuring existing computer code - changing the factoring - without changing its external behavior.

Each sprint you have to build SLACK into the sprint, so that you can MERCILESSLY REFACTOR the code, evolving the architecture (EMERGENT ARCHITECTURE) and keeping the code clean (CODE CRAFTSMANSHIP) to enable the business to be able to change direction on a moment's notice and keep the cost of change low.

Refactoring is a scary word, particularly to conventional QA specialists and to management who struggle to see what value refactoring can bring. Which is why it is often not only avoided but actively discouraged. In fact, I agree that you should be scared of refactoring. Without other supporting disciplines/practices, refactoring is very dangerous!

What are these other disciplines that support refactoring? Well, there are eleven of them, and when you package them up with refactoring, you have - eXtreme Programming (XP). The practices all work together to support each other. If you are going to implement XP, don't mess with Grandma's Recipe (well at least until you are proficient) by trying to do just part of it. (This is why I dislike it when I hear "Engineering Practices" or "Technical Practices" used in place of "XP." It only encourages the misuse of Grandma's recipe.)

Extreme Programming is a suite of twelve disciplines, designed to work together to ensure code quality and enable refactoring, which in turn allows emergent design/architecture, which enables having a delivery model of changing requirements (agile).

The goals of refactoring are:

• remove dead code
• reduce complexity (often reduces lines of code)
• remove duplication (including tests)
• make code easier to read and understand (to support collective code ownership and ease of future changes)
• change an underlying architecture to a better one as the system emerges (emergent design/architecture)
• change an underlying architecture to match a change in requirements

Because refactoring returns no new functionality, management often struggle to see value in the practice.

The main value of refactoring is that you are not accruing technical debt and can therefore continue to add features and alter your system ad infinitum (with few to almost no bugs to boot).

This goes part way to addresses the agile principle behind the manifesto of sustainable pace.

Sustainable Development

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely - Principle behind the agile manifesto.

Scrum has no answer as to how to achieve the principle of sustainable development where XP does. Consider these graphs below of two long term projects. One delivered with Scrum and the other XP:

This is a graphic illustration of the sustainable nature that XP will give to your development process over scrum. The state toward the end of the graph is Scrum as a legacy system. In fact, XP helps fill in many more agile principle gaps that scrum leaves unanswered. Read on.

Scrum is not enough

Scrum is a framework, and its implementation is left up to you. Much of the implementation of today's corporate scrum has come from XP. This includes Stories, Story Points, Velocity, Continuous Integration, and Release Planning.

When you take all the Principles Behind the Agile Manifesto and map them to Scrum and XP practices, it becomes pretty clear as to why you should be supplementing scrum with XP; supporting my claim of - Scrum is not enough.

Agile Principle	Scrum	XP
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.	Sprint Review - Demo	Small Releases On-site customer Simple Design Continuous Integration
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.	Sprint Review Sprint Planning	Refactoring Emergent Architecture On-site customer Planning Game Feedback (XP Value)
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.	Iterative Development	Iterative Development Continuous Integration Small Releases Simple Design
Business people and developers must work together daily throughout the project.		On-site customer Stories Feedback (XP Value)
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.		Co-located team Play to win Collective Code Ownership
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.	Scrum (daily standup)	On-site customer Co-located team Pair Programming Feedback (XP Value)
Working software is the primary measure of progress.	Sprint review - Demo Definition of Done	Continuous Integration On-site customer (signoff) Small releases Agile Testing (including TDD) Clean Code / Craftsmanship Simple design No Bugs
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.		Refactoring 40 hour week (no overtime) Clean Code / Craftsmanship Collective Code Ownership Simple Design Emergent Architecture No Bugs Slack Agile Testing
Continuous attention to technical excellence and good design enhances agility.		Simple Design Emergent Architecture Clean Code / Craftsmanship Refactoring
Simplicity--the art of maximizing the amount of work not done--is essential.		Small Releases Simple Design YAGNI (Similar to MVP)
The best architectures, requirements, and designs emerge from self-organizing teams.		Emergent Architecture Co-located team Pair programming On-site customer Simple design Refactoring Play to win YAGNI
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.	Sprint Review - Retrospective	Retrospective Continuous Improvement
Other Aspects of Development (not included in the agile principles)
Code Quality		Agile Testing Coding Standards Pair Programming Simple Design Clean Code / Craftsmanship No Bugs Continuous Integration
Iterative development	Sprint Planning Sprint Backlog Sprint Review	Planning Game Last week's weather Velocity Emergent Architecture
Agile Requirements	Product Backlog Increments Product Owner	Stories YAGNI Simple Design Small Releases On-site customer

Scrum + XP = A More Complete Agile Process

It is recommended that Scrum be complimented with XP ³, and it has been recognized that there are significant speed (5-10x) and quality advantages ⁴ in doing this.

So if it is recommended, why are there so few Scrum implementations that do this? According to the State of Agile 2013 survey, out of the total of scrum agile implementations reported, only 15% are doing Scrum + XP! (Of the entire population sample, only 1% are doing just XP.)

Scrum's Weaknesses

Scrum on its own fails to address

• removing technical debt
• maintaining a sustainable pace
• code quality
• emergent architecture
• small releases

XP fills in these gaps, and more. To be successful in iterative development (e.g. Scrum), your developers need new skills and understanding.

Software developers moving from waterfall to an agile delivery environment need training in agile development practices and ways of thinking in order to deliver software incrementally and architect a system while requirements are changing.

Most Scrum transformations/adoptions I have seen have focused only on changing business processes without spending any resources on training the developers and setting them up for success (or leave it late in transformation by which time bad development habits have already set in). Developers need new skills and understanding to deliver in an agile environment. XP training and coaching can provide these skills. This includes:

• Incremental delivery
• Incremental and emergent architecture
• Emergent design
• Merciless Refactoring
• Agile Testing (The Agile Testing Pyramid)
• Continuous Integration
• YAGNI and Simplicity
• Simple Design
• Choosing technologies that support testing and refactoring

Summary

If you carry on sprint after sprint delivering business value while disregarding code quality and architecture, you will end up with a legacy system (i.e., crippled with technical debt) with a high cost of ownership and many bugs.

Code suffers naturally from entropy. A software system tends toward technical debt and legacy (if left unchecked). The ONLY way to fight this entropy is code refactoring.

To refactor code requires supporting practices e.g., agile testing. There are at least eleven other of these practices/disciplines, and the sum of all these practices are packaged together as eXtreme Programming (XP).

XP gives developers skills in delivering and architecting a system for changing requirements - which Scrum does not.

In a long-term software project, you need to supplement scrum with XP.


Side Note - I came to this conclusion independently, but in writing this blog and researching references, I discovered that some of the content isn't particularly new. The thoughts of Bob Martin, Martin Fowler, Michael Feathers, and other thought leaders, in many cases, match my own observations. I find that encouraging.

Agile Terms and Lingo

XP - eXtreme Programming
MVP - Minimal Viable Product
YAGNI - "You Ain't Gonna Need It". The similar thought process in XP to Minimal Viable Product (MVP) in Lean Startup
TDD - Test Driven Development
Agile Testing - The suite of testing practices exercised by XP developers that follow the Agile Testing Pyramid paradigm
Refactoring - Code refactoring is the process of restructuring existing computer code - changing the factoring - without changing its external behavior
Technical Debt - A backlog of improvements to the code and/or architecture that will help make it more maintainable, easier to read, and robust
Legacy System - A computer system that has a large amount of technical debt
Incremental Delivery - The process evolving a software product by delivering working sub-portions (increments) of a system (typically on a cadence). Each increment typically builds further functionality on the previous, growing the complexity of the system incrementally.

References

1 - Agile Principles and Values, by Jeff Sutherland
http://msdn.microsoft.com/en-us/library/dd997578.aspx
"the Scrum framework for software development was designed to get a team started in two or three days, whereas engineering practices often take many months to implement. Therefore, it left the question of when (and whether) to implement specific practices up to each team. Scrum cocreators Jeff Sutherland and Ken Schwaber recommend that Scrum teams get started immediately and create a list of impediments and a process improvement plan. As engineering practices are identified as impediments, teams should look to XP practices as a way to improve. The best teams run Scrum supplemented with XP practices. Scrum helps XP to scale, and XP helps Scrum to work well."

2 - Flaccid Scrum, by Martin Fowler
http://martinfowler.com/bliki/FlaccidScrum.html
"What's happened is that they haven't paid enough attention to the internal quality of their software. If you make that mistake, you'll soon find your productivity dragged down because it's much harder to add new features. You've taken on a crippling Technical Debt, and your scrum has gone weak at the knees."

3 - Scrum and XP: Better Together, by Mike Cohn
Availble via wayback machine internet archive to article now removed from Scrum Alliance Site

4 - The Origins of Scrum, by Jeff Sutherland
http://jeffsutherland.com/2007/07/origins-of-scrum.html
"Few implementations of Scrum achieve the hyperproductive state for which Scrum was designed (5-10 times normal performance). Those that do all implement variations on XP engineering practices"

More from other Authors

The Art of Agile - James Shore
My favourite book and blog on XP right now.

The Land that Scrum Forgot - Bob Martin

Ask me Anything session - Jeff Sutherland
"Ken Schwaber convinced me that Scrum would be easier to adopt and work anywhere if we didn't mandate specific software practices."

XP is the Mac of Agile - Jonathan Rasmusson

Working Effectively with Legacy Code - Michael Feathers

A great example of why developers need to refactor - Manuel Bernhardt
"It is one thing to get to a reasonable functionality in a short time, and another one entirely to build a piece of software that can be maintained or worked within a team over an extended period of time. It is all too tempting to leave working code as-is, without refining it or improving it in a timely fashion. And before you know it, someone else has picked it up, or you have picked it up again, copy-pasted it (god forbid!) or increased its complexity where there would have been a simpler solution would you have given it some more thought."

Code Refactoring - Wikipedia

An Exercise to Illustrate to Teams and Managers how Scrum without XP creates Technical Debt

The Scrum Gauntlet of Debt

Developing First Class Software with the Developers that Google Reject

Or – why you don't need to hire heroes

Before I start, please understand that I am not trying to belittle anyone here, or infer that they are a second or third-rate developer. I personally could not make it through the Google interview process, so include myself in the category of “developers that Google reject”. (Though, I'm pretty sure I could have gotten through the interviews when fresh out of college, when all the math and computer science algorithms were fresh in my head. With that in mind, I find it no surprise that 98% of the company are under 30!)

The Software Giants have hired all the top-shelf developers

“We can only hire middle to low-end developers here at our company. Google, Microsoft, and Amazon pay more than we can, leaving the market with only second and third-rate developers. Even if we had the money, there aren't any first-rate developers around, because these software giants have sucked them up from the development pool.” This is a rough quote I heard from someone working at a software firm in the Pacific Northwest. His perception was that in his years at this firm, the quality of developers and development has been steadily falling in his company. The firm used to be able to attract high-level talent in the Pacific Northwest, but found that it now was unable to match the salaries and packages of its very wealthy software giant neighbors. I assured him that all was not lost, and in fact, the firm is in a better position than he thinks! Read on.

Teams can do things that geniuses can’t

The collective capability of a team is larger than that of a genius. Agile development is based on self-organized and self-managed teams. The synergy of a team’s collective mind and skills will give you the same, if not better, results than the genius approach, along with some other added benefits. These include:

• You don't have the “win the lottery” or “hit by a bus” scenario to worry about
• Knowledge is spread among the team, so vacation time doesn’t affect your project plan
• It is cheaper (as you are able to hire juniors and the middle-shelf developers)
• You’re less likely to have to deal with large egos (that you often find with elite devs)
• Working with a team is fun
• Recruitment is easier (as you have a larger pool to pick from)
• Teams come up with more options when problem solving, as there are many points of view

Creating a team

Are you sold? If so, you will need more than just lumping a group of devs under one project and calling them a team. That is a group, not a team. The real magic happens when this group of devs have had time to gel together and go through the forming, storming, and norming phases to become a team. To foster this, I recommend co-locating the team in a collaborative (open space) environment, and preferably near the customer that they will be working for. This team will come up with creative solutions above and beyond what a single genius developer could. OK, now we have the start of a team. Next is a process to ensure that the same results (complex algorithms) can be achieved, similar in result to a genius.

A Software process that will get you to the same point as the genius

Enter Extreme Programming (XP). The processes of simple design, TDD and merciless refactoring will return the matching results that a genius would. These practices are a repeatable and reliable way of producing code of high quality and complexity.

The genius interview process usually entails complex questions or scenarios that require a very clever algorithm to solve, and the test is to see if you can come up with the correct algorithms and approaches that they have in mind. Now, if you were to create a set of acceptance criteria and tests that would determine that the result met your requirements, then I can fairly much guarantee you that I can solve the problem. Particularly, once I understand what you are trying to achieve so I can iterate from simple through complex, and get feedback throughout. And that, my friends, is XP in a nutshell.

The Extra Perks

There are more perks that come with XP and with an Agile team approach:

• Individuals can come and go from the team throughout the process, and progress carries on regardless (though you want to minimize team changes – team persistence, pair programming, collective code ownership)
• The code is easy to read, maintain, and quick to debug (collective code ownership, coding standards)
• You will not be accruing technical debt, which would ultimately result in a legacy system (merciless refactoring, sustainable pace, automated testing)
• Minimal to no documentation is required (code as documentation, tests as documentation, refactoring tests)
• New and junior developers have a very short lead time to reach full productivity when joining an XP team (simple design, pair programming)

Summary

A persistent cross functional team practicing XP will get you high quality results and code quickly and cheaper than if you were to rely on top shelf developers only.

Cross Functional team examples

Getting a paralyzed rat to walk
The Mayo Clinic team approach
The Philosophical Breakfast Club

Update - Sep 2015

I stumbled across a similar article on Forbes - We Don't Need The Best People, We Need The Best Teams