The continuous fruition of new opportunities created by emerging markets and the need for solutions to previously unexplored (or non-existing) problems has long ago created a blissful environment for sofware developers and customers alike. Considering this, the improvements made in both physical technology and means of communication have made it possible for developers to think about and create these solutions.Doubly so because there is an ever-increasing demand by end-users, content providers, service providers, resellers etc. to make good use of these solutions. Whether the fulfillment of these needs is for personal pleasure, increase of productivity or providing higher quality services makes no difference to the market of sofware development. There is a massive demand for high quality software in often barely known territory at a pace matched only by the industrial events governed by the work of Nikola Tesla and his contemporaries.

To meet all these demands and fill in the constantly emerging blanks of the market, developers soon realized their biggest problem: themselves. Keeping up with the dynamics of their professional environment required effectiveness and efficiency. These two keywords are the backbone of all software development methodologies. Be it waterfall, spiral, incremental or agile, all of these ideas were built upon the principles of doing the things right while doing the right things. Each of these have proven valuable in different environments, although agile practitioners often evangelize a third principle: doing the things better. Agile methodologies like Scrum, Kanban or variations thereof have become immensely popular because of this. Through visualization, retrospectives, constant communication and so on, these methodologies have been able to refer to themselves (like the developers did earlier) to tackle their own problems.

The self-reference of a human being or system is what makes it "intelligent", it's the key to self improvement and, subsequently, possible excellence. In the more technical world of software development we can see similar "self-referential" paradigms. Code that looks at and inspects code so that it can tell the developer where things are broken or improvements could be made. Continuous integration tools and unit testing frameworks are proving their worth time and time again. Coincidence?

While self-reference is apparently thriving software development and it's methodologies, the time has come to look in the mirror and ask how we can improve our methods and thoughts even more. Considering the (often hard-learned) lessons is fruitful as it might bring us closer to the excellence we require to meet the ever-changing demands of the challenging evironment that is surrounding us. We can certainly do things better, but not without an open mind to evaluate the results of our self-reference. Here are some of my thoughts and ideas on how agile methodologies can fail miserably or improve both your efficiency and effectiveness.

Semi-related sidenote: Should this concept of self-reference intrigue you, I can strongly recommend Douglas Hofstadter's classic "Gödel, Escher, Bach".

Task boards don't make you agile

Plenty of small software development teams have adopted an agile methodology, aiming for higher quality software and flexibility towards change requests while ensuring on-time delivery. One of their office walls is most likely decorated with a task board full of information (if they haven't adopted one of the readily available agile planning tools). Each morning there is the traditional stand-up meeting after which everyone starts or continues their task.

It's a great start. People are keeping track of progress, have a reasonable understanding of who is doing what and have a daily opportunity to report serious problems. Nonetheless, this approach still often leads to unmet deadlines, buggy releases and recurring troubles. Even though task boards, stand-ups and a flexible approach towards change are of great value, the real strength of agile development is what happens beyond the board, in evaluation, communication and the mindsets of all people involved.

Being agile is more than just tracking your progress. It's about facing facts and constantly improving your workflow, identifying your weaknesses as a team and looking for simple ways to make them your strengths. Your task board should help you identify these weaknesses where retrospectives provide an opportunity to discuss and obliterate them. Remember that even daily stand-ups can be used to improve your current workflow.

The right people, the right environment

I've written earlier that the true strength of agile development is unleashed by looking beyond the board. The first thing we encounter there is the people standing in front of it each morning. Scrum masters, product owners, analysts, developers, testers... All of them are at least involved in the process and have a different influence on the results it yields. A good product owner knows exactly what he wants, good developers can translate those requirements into high quality code that can be released with a minimal amount of bugs after it's been through various rock-solid testing flows.

Unfortunatly, not every team has the kind of indispensable trust, quality and coherence to achieve a near-perfect agile experience. Each individual has its weaknesses. It is his or her own choice and responsibility to minimalize those weaknesses and further develop their personal strengths. It is through individual self-reference that we get to know these weaknesses and accept them. When we bring this theory to the next level, we can broaden the focus of the self-reference and look at the team as a whole. A Kanban board can help in visualizing the workflow throughout an entire team, allowing for easy recognition of weaknesses or bottlenecks. Needless to say, knowing your team's weak spots as such doesn't get you anywhere. It's the acceptence of those weaknesses and the actions of the team to minimalize their impact on the process that paves the way for success.

Note that I'm not just (for instance) comparing the amount of broken unit tests per capita. By weaknesses I mean everything that might have a negative influence on the development process: inefficient communication, incomplete requirements, reluctance to admin mistakes... Issues like these can be identified and improved by a single individual. He could be acting as a missing link, introducing alternative approaches to testing or urging people to speak up on a retrospective. It's important to talk about these realizations so that other members might sharpen their senses and identify similar opportunities for improvement.

In short, it's not the individual's skills, but the open-mindedness and willingness to minimalize the entire team's weaknesses of everyone involved that yields the best results.

Expand your horizon

Considering the members of an agile team, I am convinced that best results are often achieved with members that are willing to go beyond what they already know. A team consisting of an analyst, a designer, a developer and a tester might work pretty smooth when all of them have a similar working rhythm, it often falls apart when one of them fails to provide the next one in line with sufficient tasks or information. The efficiency problem is easily solved when the members are willing to step outside their comfort zone and team up. The concepts of limiting work in progress and extreme programming have already proven their worth in various Kanban teams and I feel that polyvalent members make teams even more suited for these simple but efficient agile techniques. Encouraging your fellow team members to diversify their individual skills is a key factor to increase the team's agility.

Extreme Unit Testing

In the previous paragraph I briefly touched the popular agile concept called Extreme Programming. The idea of two developers working on the same piece of code seems awkwardly inefficient at first, but it has proven to increase code quality and reduce lead time. The combined skills and ideas of multiple developers not only benefits your team's efficiency in the short run, but turns out to be valuable later on. Code written by two people can be maintained or refactored by either of them without spending time trying to understand what was written in the first place. On top of that, the reduced lead time increases the value of the deliverable at hand as it can be tested and deployed if need be.

Unit Testing is an indispensable part of a development cycle. Developers have known this for a long time, even though most of them will tell you they prefer to write real code. Inspired by the XP paradigm, we can define a similar approach for writing automated tests that keeps developers from having to write both the code and the tests for the same deliverable. If you are working in an environment where developers are not too fond of writing unit tests, you might want to give this approach a shot.

Instead of working on the same piece of code, two developers can be assigned an individual task. Each developer writes the required unit tests for that task and hands it over to the other. This approach yields results similar to XP because both developers are aware of all implemented features. The lack of increased lead time is compensated many times by having a high code coverage and is easily recovered when doing refactorings or implementing new features.

Knowledge sharing

I have already hinted at the importance of sharing knowledge in the previous chapters by describing the benefits of polyvalent team members and XP approaches. Even though most developers despise the thought of having to write documentation (can't you look at the code?), it's still the default way to share knowledge on both functional and technical aspects of the product at hand. I have, however, often found myself rewriting pieces of code after finishing the documentation due to new insights. Writing documentation allows a developer to approach challenges and problems from a completely different perspective. The impact of natural language combined with the fact that you're trying to explain the solution to people who are most likely unaware of the problem is impressive and will lead to a better understanding of the problem and, a lot of times, to a better solution.

Another interesting and effective means to learn your team member's code (and spot issues early on in the development cycle) is the concept of code review. I'm not talking about in-depth reviews of code by senior architects, but small, intra-day checks of your fellow team members' code. As almost any agile development team works with a version control system, the easiest way is often to add email logging to the repository. At each commit, an email is being sent to all the developers in the team, containing the username, revision number and diff overview of all changes. The amount of immediately spotted issues by fellow developers is staggering and improves overall code quality. On top of that, developers get a feel for who is doing what and how without having to ask. If your agile team doesn't have commit logs, I can seriously recommend the approach. If it doesn't do any good, at least it doesn't harm anyone (given a good inbox filter) and it has proven its worth time and again. Besides, what is not to like about improving code quality by spotting other people's mistakes?

And you?

What are your agile experiences? Have you encountered serious pitfalls in the standard agile processes? Is your team using certain techniques that have vastly improved both quality and quantity of your team's delivery? Feel free to link or elaborate on them in the comments below. After all, it's the experience that hands us the lessons, but it's the open mind that makes those lessons valuable.

More geek talk at http://www.geektalk.be.

Tags: Methodology