Agile Principles #6: Have live conversations.

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

Now, the first reaction many people have when reading this is to state how much the world has changed since 2001. Now we have Slack! We have social media! We have distributed teams!

It’s true we have those things now. But we also had equivalents to these in 2001, and earlier. We didn’t have Slack back then, but IRC has been around since 1990. In the 90’s it was common to ssh into a remote host and work with developers there. Also, remote teams were common back then, whether it was teams across the country or offshore teams in a remote country. So these concepts aren’t new, and the group that came up with the agile principles was well aware of the concerns.

Face-to-face conversations are always the most effective form of communication. Even teams that are used to working in a distributed fashion find boosts in productivity when a remote team member flies in for a visit.

This should not be taken as an endorsement of bullpen seating so that everyone can be face-to-face with everyone else all the time. Absolutely not. Most of the time developers are programming and don’t need the interruptions. At most, they’re talking with one coding partner.

The main goal here is that when you do have conversations, to prefer face-to-face conversations as much as possible. Ultimately, conversations range in a spectrum from less interactive to more interactive. Communicating via paper printouts is amongst the least interactive, followed by email. Online chats like Slack are good, but can still be rather asynchronous.

Slack is better when you use the call features that share audio, video, and screens. Then it becomes a much more interactive experience. When you can’t have real face-to-face conversations, try to have the next best thing. Remember that live, interactive conversations are more productive.

Agile Principles #5: Motivation and trust are necessary.

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

A development team needs the proper motivation to give their all when working on a project. The foundation of this is a good market-level salary; employees paid below market will soon find better things to do. Beyond this, there needs to be a mission that the team can agree on. A team with a strong mission will outperform one that is just working their day job. To achieve the mission, the team needs milestone goals.

A healthy environment is also important. Too often these days, developers are dumped into a noisy bullpen filled with distractions. Open floor plans have few benefits and are detrimental to allowing programmers to concentrate on their work. Even cubicle farms are preferable to the dreaded open floor plan.

The office also needs to be healthy. If a coworker is sick, make him stay at home. Don’t let a sick person infect others. Keep the office sanitary. Allow natural light to come into the office; having windows with views of trees is ideal. Putting developers in a windowless cave is like working in a dungeon.

Give developers the support that they need. You’re going to pay over a million dollars on salaries and create a product that will bring in many more millions in revenue. It doesn’t make sense to skimp on minor expenses like computers, displays, chairs, software tools, and other supplies.

Trust the developers to do their jobs well. Avoid micromanagement. If you control every move and decision, then you are not taking advantage of the developers’ skills and experience. The team members also need to trust and support each other. This also means when a person has a problem, he needs to speak up and seek help.

Humility is very important here, as team members with big egos will not benefit from the environment. They’ll ignore the advice of their peers and refuse to help others. Always seek to have team members who value humility as a virtue.

Agile Principles #4: Collaborate with business people.

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

The most successful projects are the ones where the developers and business people are in constant, easy communication. One way to envision this is to compare two dramatically different scenarios.

In the first one, imagine a trading desk wants a new trading system. The old one has been around for ten years, and it works, but the competitors’ trading desks are starting to be more effective. There are many new features and points of functionality that are needed. So the managing director gets with the VP of technology and starts a project to create the next generation trading system.

To save money, they are going to outsource most of the development work to an agency based out of India. To be sure that all of the requirements will be met, consultants come in and spend six months doing analysis and documenting all of the needs. The contract is negotiated, and a lengthy project plan is developed. Another 18 months later, the promised system is finally delivered.

Meanwhile, across town, a similar trading desk faces the same dilemma. They opt for a different approach, however, one that will be more agile and responsive to the traders’ needs. Developers are hired and placed in seats right on the trading desk. It’s noisy. It’s distracting. But the developers rapidly become intimately familiar with traders’ needs.

Not only are the developers more intimately familiar with the needs of the business, but they’re also able to react immediately when conditions changes and the requirements need to be adjusted. Throughout the development of the product, new features are demonstrated and delivered incrementally. This results in a much more useful product, with new business value delivered more quickly.

While it should be obvious that close collaboration greatly benefits the business, this is one area that the developers sometimes have little control over. The business has to buy into this agile approach. If the business people consider themselves too busy to talk to developers frequently, it becomes difficult to maintain an agile stance.

Agile Principles #3: Practice iterative development.

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

When the engineering team can get into a rhythm of software development, healthy habits form. This process includes creating tests, writing software, running tests, refactoring the code, and releasing the latest version. In better teams, this pattern becomes the heartbeat of the organization.

When the releases happen frequently, each release doesn’t have to be a massive production. Instead of each release containing major milestones or massive feature sets, releases can be smaller and contain incremental improvements.

With each change being small, the impact of unexpected side effects can also be small. Each release improves the software incrementally. With each iteration, the software gets better, the developers learn more, and the business gains value.

Working in small iterations also reduces stress. Building a house is a lot easier if you focus on just a few bricks at a time. A pattern of successful releases increases confidence and morale. This is the kind of successful team that developers love to be on.

Agile Principles #2: Embrace change.

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

There is a natural tendency to fight against change. You’ve worked so hard to build things a certain way. You invested many hours in requirements gathering, analysis, architecture, and development. You are confident that you have implemented (or are well on your way) this feature exactly the way the business needs it.

That doesn’t matter.

When the business needs change, the development team needs to respond with an appropriate shift in strategy. Priorities change. Details change. Requirements change. If you don’t embrace these changes, you will no longer be building valuable software.

You can’t deliver valuable software if those values have changed.

The whole point of an agile approach is to be able to rapidly respond to change. In a slow waterfall approach, a change in requirements would call for extensive contract renegotiations. It could be months before the development team gets back in alignment with where the business needs them to be.

Furthermore, a company that can rapidly respond to changes in business needs will have a competitive advantage over companies that do not. Compare a company that releases daily against one that releases only twice a year. The faster company could have very important features for several months before the competition can react.

Agile Principles #1: Release early and often.

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

Early delivery reduces tension. At the beginning of a project, there is a lot of stress and uncertainty around when the product will start to take form. When will the first demo occur, when can the business start pilot customers on the system. The sooner you can deliver the minimum viable product, the better. That minimum is often much less than anyone expects.

After the first release, it is important to have regular, frequent deliveries of software. The less time there is between releases, the better. The problem with many large waterfall-based projects is that months go by between releases. During such a long period, the business needs change, the market demands shift, and the product people learn more about what it will take to ensure success. Having rapid releases reduces fear and uncertainty. If anything is wrong, they know that the next release is not far away. When it becomes easier to effect change, the business gains trust in the development team.

Another key element in this principle is one of value. Valuable software means having features the business owner can perceive. Simply doing a release that contains some refactorings or maybe a new version of a component does not benefit the business directly. As a result, such changes do not count towards releases of valuable software. It may be unfortunate, as such changes are necessary at times. The best you can do is to package such changes with features that add value. The business owner determines that value.

Finally, the feature backlog is priorities by value. The business always desires features that will greatly increase revenues before features that provide small improvements. The sooner the business can recognize that value in the form of new sales, the better.

Make an effort.

Those who try harder get more done.

Tenacity is one of the most important traits of successful people.

Lesser people give up. When things get difficult and they don’t know what to do, some people stop trying. They seek a simpler, easier goal.

The world is full of challenges and some of them are indeed quite hard. Only those who are truly committed to success will keep going. They never give up. Sure, some people have innate talents and abilities. Some may have initial advantages. But because most people lack the tenacity to keep going, the driven individual can learn more, get more done.

When you’re choosing your personal values, tenacity is a great one.

Look out for comments at the end of a block.

They may seem helpful, but they’re also a bad sign.

Sometimes when you see some complex code, the programmer will have comments at the end of a block to help identify which block is ending. This often happens when loops are nested several layers deep.

For example imagine an if statement inside a while statement inside another if statement inside three nested for loops. At the end of all this you find a half dozen end braces and you’re not sure which loop or condition is ending. Comments next the brace can seem like very helpful information at that point.

There are a couple problems with this. The first is that after a code refactoring in the code, the blocks may get rearranged. The comments can turn into lies. It’s pretty horrible to have comments that are no longer true.

The second issue is that code should never be so complicated that you need these kind of comments in the first place. Refactor the code, extract logic out. Keep doing this until the loops and blocks are obvious and easy to read. Simpler code is always easier to maintain, and you never get lost in the hell of multilayer blocks.

Code shouldn’t need an explanation.

Sometimes comments are a red flag.

When a block of code is so complex that it needs comments to explain what it does, that is a sure sign that the code itself is too complex to stand as is.

This isn’t to say that all comments are bad. Some comments that explain why a method exists or provide some of the history as to what brought this method about are good things to have here.

It’s just when you start writing paragraphs that explain what the code is actually doing that things have gone wrong. First of all, you run the danger of the comments and the code falling out of synch, as code changes over time, and sometimes people forget to update the comments.

But the primary concern with comments that explain the code is that it’s a huge red flag that the code is too complicated to begin with. A method should be short. It should do only one thing. The variables / objects should have names from the business domain. If you follow these, it’s hard to imagine a case where you would need comments to explain the logic.

So when you see a 100-line method with 50 lines of comments that explain how it works, you really should refactor that method in the much smaller chunks. Always prefer simplicity over complexity. It’s fine for a class to have dozens of methods.

If the casual reader can understand at a glance what your code is doing and no comments are necessary, then you’ve managed to get your code to the right place.

Don’t put cusswords in your code.

They’ll come out at the wrong time and appear to the wrong people.

Inappropriate language should never appear in the codebase. Keep it out of your object and method names, comments, test data, and examples. Also keep it out of the commit messages and pull request comments in your source control tools.

These things will bleed out at the most embarrassing time.

You could be doing a code review when a director enters the room, only to see that you’ve named a report generation class runStupidReportForJerksInMarketing(). You can be sure he’ll never forget that. Maybe he’ll find someone who actually doesn’t find the job “stupid”.

Test data can likewise leak out to a production system by accident. Next thing you know, a customer is seeing evidence of cuss words in the system. When the business finds out, they’ll be on the warpath.

Unprofessional behavior like this will scare off clients. If you can’t be a professional, then you should seek a different line of work.