What does it mean to be an Agile software developer?

The principals of agile software development are well documented and extensive. On the ground, day to day, what does it mean for a group of engineers?
I think there are two simple attributes that really matter:

• Clear short term focus on adding value
• Willingness and capability to change focus

The clear short term focus on adding value is well understood. It follows from a good user(customer) story that breaks down into tasks. The focus is collectively and iteratively on design, implementation, testing and documentation to make the customer requirement a valuable reality, adapting to requirements changes as necessary. The appreciation of value as perceived by the end user rather than the engineer is also important.

The willingness and capability to change focus is a little more subtle. Willingness is important, without it there is no hope of agility, but more important is the capability to change. The capability must be learned because it is embedded in the context of the team and workplace. Consistency is key I think. Consistency in engineering practices across teams around things like build systems, code style, development and design tools. Consistency and simplicity allows individual developers to change focus because the underlying infrastructure does not change (too much). With consistency, moving from one task to another or from one team to another is not only possible, it is fun.
I understand that rigid restrictions are often considered the antithesis of creativity but they have their place and can be beneficial. Consider:

• Constraints often provide the motivation for innovation.


• Discipline predicates habit, habits allow our conscious mind to focus more freely on the task at hand.

Helping a FOSS project tip over the technology adoption curve

When does a new FOSS project take-off, become really popular and move in the main stream?
What are the necessary pre-conditions or attributes of the project that allow it to tip-over the adoption curve?
I will hazard a guess at a few relevant attributes:

• Useful: the project must do something useful. Either it is a better or novel solution to a known problem or it is a new solution to a new problem. Whatever the case, it must help solve some problem. This is a necessary, if not obvious, pre-condition.



• Honest: honesty is important because it builds trust. Trust is important because it is the basis for an on-going relationship and the basis for a technology adoption decision. Honesty is easy to achieve. It is about simply ensuring that the project 'does what it says on the tin'. That it is fit for the purpose for which it is intended. If the project is a first step in the direction of a solution with a bunch of explicitly identified known-limitations, that is ok also. The key point is that there is no world domination marketing blurb, no spin, no claims about un-tested or un-implemented features, no ifs or buts etc.
  Honest revelation is important for two reasons. First, because it is the truth and because it forces identification and analysis of the current reality. Second, because you can be found out. The source is open and the truth is in the code. The type of people an early FOSS project needs to attract can and will read the source-code.
  If a FOSS project is honest, the users first impressions will be a valid reflection of the project. There can be no disappointment. If the intent is perceived as useful, the user can decide to adopt, track changes or get involved. In essence, the project stands solely on its 'usefulness' merits.



• Extensible: The architecture of participation is important. Successful projects get this right from the beginning. Outsiders are presented with clear opportunities to contribute to the project.