An Introduction to Hyper Agile Development

Hyper Agile (aka Hyper) is a development methodology designed to smoothly scale out from small teams to large teams and to maximize the potential of the development organization from a return on investment (ROI) perspective. I’m still working on documenting Hyper in full. In the meantime, here is yet another preview. Except for the practice of short iterations, each of the individual practices are best practices in and of themselves and can be implemented in conjunction with any development methodology.

Short Iterations - It has been widely stated that the benefits of Agile Development are producing value, maturity, and feedback faster; allowing early feedback to inform requirements to produce a better product, and increasing business flexibility. In my opinion, all of the benefits of traditional Agile Development can be directly attributed to the practice of short iterations, everything else is an enabler.

Automate Everything - The practice of automating everything is an extension of the Agile Development practice of writing automated test cases and fully automating the build process in support of the practice of continuous integration. If our main reason for existing as software developers is to automate manual processes, shouldn’t we be using automation more and more instead of less and less? Of course it makes sense that if we are going to be doing something new, there may not yet be off the shelf automation that fits the bill, but when there is, shouldn’t we use it?

Massively Parallel Virtual Pipelining - this is the process of breaking the lifecycle into as many separate steps as possible and then applying that lifecycle to each user requirement on an individual basis in parallel. This enables a high degree of asynchronous activity which in turn facilitates short iterations. I say a virtual pipeline because various stages of the pipeline may overlap with the same stages in other pipelines and because the various stages may be performed at different locations.

Development Hierarchy - A development hierarchy is simply a representation of the dependencies between groups that includes process steps such as integration, quality assurance, and code reviews. It encompasses a number of best practices including multiple isolation levels, gatekeepers, checkpoints, and always moving from a known good state to a known good state. It provides the structure for the parts of the virtual parallel pipelines that are associated with actual code. The fundamental building block of a development hierarchy is a branch.

Work Item Ranking - Work Item Ranking is done by putting all of the planned items into a single list. The first item is the highest priority item and the last item is the lowest priority item. This is also known as backlog in the Scrum Agile methodology. This practice vastly simplifies project planning, keeps you focused on your target market, and helps to prevent feature creep.

Estimation - At first glance, it might seem like estimation is a relatively simple and mundane task. Think about the task, compare it to your experience, give a rough guess and add a little padding. Actually, there is a surprising amount of literature that focuses solely on estimation. In the end, I think the most important part of estimation is to do it. I suggest you use the PERT method. It is widely used, and it is very simple. Take the least possible amount of time, add 3 times the expected, add in the most time it could possibly take, and divide the sum by 5. That’s it.

Writing Tests Early - Tests and requirements are very closely related. In order to write either one, you need to know the answer to the question “what is this supposed to do?” If the person responsible for writing the tests is struggling, it is a good early warning that it is not clear what the software is supposed to do. If it is not clear what the software is supposed to do, it is unlikely that anybody will be able to write the software to satisfy the end user. Thus, it makes sense to write the tests first to reduce the chance of writing code that does not reflect the needs of the end user.

Quality Quotient - One of the frequent objections to Agile (believe it or not) is related to quality. Since there is no good way to determine the exact quality of a product, it is difficult to empirically compare one iteration against another iteration to help to determine whether or not an iteration is ready for release. A quality quotient is a systematically calculated approximation of the quality of a particular iteration. The data that is compiled as part of the calculation of the quality quotient can also be used to guide future quality and process improvement efforts.

Meritocracy - Meritocracy allows developers to contribute outside of their traditional areas, to build trust in their capabilities, and to allow them to naturally gravitate to the areas where they are the most effective. An efficient way to implement meritocracy is to allow developers to create branches where they can implement their ideas. If they are successful in implementing their idea and the result is accepted, it is then a simple matter to incorporate the change into the development process.