|Damon Poole, creator of Hyper Agile|
That said, I'm a big fan of agile development, and I've been working hard to get it adopted. You've developed the Hyper-Agile methodology. What are some key principles, and how does it differ from Scrum, XP or Crystal?
The ways it is the same are short iterations and automating everything. Those are the two principle ideas, especially automation. The idea is if a little agility is good, a lot is better.
Where it's different is it doesn't specifically call out that you need to do all practices to be agile. Some methodologies say if you're not doing agile exactly, you're not doing it. People are emphasizing too much the frameworks and not the benefits and productivity. Where [Hyper] is also different is it's designed to scale up to large teams, so there's no emphasis on small teams or co-location. It does emphasize the use of tools. Hyper Agile is using automation everywhere you can -- requirements gathering, SCM (software configuration management), issue tracking.
Another [difference] is virtual pipelining. One thing agile tries to do is compress that pipeline. There is a lot of benefit that comes from [traditional] waterfall, but it's associated with long iterations. So think small waterfall, but with short iterations. The idea is those steps don't have to be done by the same person; you can have one person doing the coding, another testing, etc. And it's virtual in that the pipeline can go anywhere; you don't need a co-located team. Doesn't the term "waterfall" have a negative connotation now?
I don't mind being associated with waterfall. I think a lot of folks in agile have in some ways gone too far. There are a lot benefits from the waterfall methodology, just not when it's linked with long iterations. What other Hyper Agile practices may differ from other agile methodologies?
One is development hierarchy. Often in small agile teams you have everyone working on the same code line -- in SCM it's a branch -- but the problem in large teams is if hundreds of people are working on the same branch, you're stepping on toes. This takes the idea of developers working on private branches or isolated work spaces and scaling out. With development hierarchy you might have individual developers, feature groups or teams, teams of teams, etc. The idea is you do the continuous integration of agile, but instead of one level of continuous integration you have as many as you like. As you combine the results of the different pieces, you get more mature and have less things breaking; this allows you to be going even faster. With a large agile team working on the same branch, one group has to pause while the code is stabilizing. With development hierarchy you can isolate [things] so you're always working. You also have adopted some practices from the open source community.
There are a lot of ideas out there to help scale agile teams, meritocracy is one of them. If you have folks well suited to certain areas [and a project] might seem outside of what they work on, they get a chance to prove themselves. Transparency is another idea from the open source community, where you have open discussion and a clear trail from inception to delivery. There are a number of things you can use, such as forums and wikis. By using an issue-tracking system, whether it's commercial or open source, everyone can see. With 3x5 cards it's hard for everyone to see. The other part of transparency is doing regular demonstrations, so folks that aren't directly involved can see the progress. Hyper Agile also incorporates the practices of "ranking" and "quality quotient." Can you explain?
Ranking is similar to backlog in Scrum. The biggest difference here is a number of agile methodologies say predictability is not possible so don't try. But the idea here is using ranking to plan future releases/milestones, say in a year you will do all the work and break it into milestones. So you rank it out for the time frame and attack it in iterations. Of course over time you will re-plan, but you're not coming into a new iteration and doing the planning from scratch. This gives management more comfort that you know where you're going—you're not just seeing where you end up. This is controversial as most agilists go. With any project you know you won't end exactly where you anticipated, but you do have an overall plan and you adjust as you go.
Quality quotient is under development; it's an ongoing target. The idea is you want a framework where you compare the quality of two releases. Now it's done anecdotally. We say it has 10 fewer defects, or it's holding up better than previous releases. The idea is to set up a hierarchy of components in the system and look at how each one is tested, the impact they have, and then get as fine-grained as you like. You can develop a framework, but even without one it gives you a way to think about how to structure testing. If there's an area that gets a lot of testing but doesn't get a lot of use, maybe it can show a lower priority. You can decompose the system into lots of modules and show where you put your quality efforts. You might think this is not connected to agile, but the connection is if you're doing agile and doing releases on a regular basis, you really want to keep an eye on quality.
There are a lot of examples [of better quality]. There is less waste introduced by working on the wrong thing. [With] short iterations and either frequent releases or demos to the customer, you can change direction early. So you deliver more value. Quality is not necessarily fewer bugs but how usable is the software, how much do people want to use it. Talk about the development of AccuWorkflow and how you used the Hyper-Agile methodology.
The idea was conceived in April 2006. It had to ship by December 2006 [to meet a contest deadline the company wanted to participate in]. We used all the Hyper practices. One of the most useful was regular demos. Early on there were some questions as to was this the right thing to work on. The demos were helpful in solidifying support for the project. Also meritocracy was very useful. The amount of resources we had committed were a little short from what it required, so we were able to get some volunteer work, people who worked on something they wouldn't normally work on, so we got more resources.
[Regarding virtual pipelining, you can see a sample workflow on our site that is similar to the pipeline we actually use. It required more discipline than we anticipated; it was probably a 10- to 15-step pipeline for each issue.
I'm 100% sure that without using agile, it would not have shipped on time, Hyper or otherwise. Hyper was particularly helpful, but without the short iterations we wouldn't have made it. We've been slowly moving to agile internally; this is our most visible agile project.
Damon Poole is founder and CTO of AccuRev, provider of process-centric software configuration management (SCM) solutions. He is the architect of the company's AccuRev and AccuWork products, and an industry expert on SCM. Poole has developed a methodology based on Agile that he has coined "Hyper Agile," which was used to develop AccuWorkflow, a new product that embeds application lifecycle workflow within the SCM context.