Posts Tagged ‘agile’
How we do that voodoo that we do.
How we do it
Agile, XP, and SCRUM
We use programming and project management techniques that are derived from Agile, Extreme Programming (XP), and SCRUM.
Realtime Visibility and Control
We offer client tools that allow you to monitor and control your project in realtime. Projects are broken down into “user stories” and then progress against these stories is updated continually by our engineers. You’ll always know exactly where things stand. You can also add, remove, change, or rearrange stories at any point. You have up-to-the-minute control over what features end up in the final release and in what order they get done.
Sprint-based Iterations
A sprint is a one week release cycle. By keeping the interval short, we maintain a tight focus on the most critical features. The end result of a Sprint is functioning, error-free, releasable product. This gives the stakeholders a chance to actually use the product which, in turn, influences the features and functionality of subsequent Sprints.
Continuos Deployment
During the Sprint, user stories are deployed to a test environment immediately upon their completion. This gives stakeholders a chance to see features in action before the end of the Sprint. This serves two purposes: First, the project owner can adjust the remainder of the Sprint based on hands-on experience, and Second, with new features appearing everyday, excitement about, and engagement in, the project remains high.
Test Driven Development
The first step in User Story development, is the creation of automated unit tests that validate the feature. After the tests are written, engineers then write the code that implements the feature. Test Driven Development has been shown to be more responsive to rapid changes in requirements while generating more reliable code.
Pair Programming
The concept is simple. Two engineers sit side-by-side and work together on the same code. With two minds continually refining, discussing, and working on the same problem set, fewer mistakes are made, difficult problems become easy, and designs are generally simpler and easier to maintain. Simply put, Pair Programming generates better code, faster.
Team Scalability
The smallest team is one pair of engineers but our approach lends itself to near linear increases in productivity as more pairs are added. Engineers often switch programing partners and the more sets of eyes on a given problem the easier it becomes. With more than three sets of pairs on a given Sprint, productivity gains become less linear due to the increased inability to parallelize. As business requirements change, team size can be quickly ramped up, or down, depending on output needs of the specific Sprint.
Built to Transfer
At the end of the engagement, the project will be transitioned to your internal team. Because our methodology requires that all work be readable by all members of the team, code tends to be more elegant, easier to understand, and have both clear in-line comments and user documentation. In addition, our engagement process gives you real-time access to all features, documentation, and code as it’s checked in.
Our Sweet Spot – The sorts of things we look for in a project.
At Agave Lab, we help companies and individuals affordably convert their ideas into products. This might mean transforming a napkin sketch into a fundable, high-quality beta release, or building out the feature set for the next release of an existing application.
Common themes include:
Working with clients to evolve a seed of an idea into a compelling product plan
Keeping our fees low so that our clients can afford to try take risks and try new things
A dedication to user interfaces that are clean and crisp
A belief that form should follow function
A focus on viral growth strategies
Industrial-strength code and architecture
Development processes based on Agile and Scrum
Projects That We Look for
iOS and Android
Mobile social
Feedback and reviews
Photo sharing
Come work with us!!!
We are in search of a developer to join the team here in Guadalajara. The skills that we’re looking for include: CSS, javascript, PHP, and Flex/Flash. Attitude is key in that we’ve built a really fun team and we all get along well. The candidate will have to be flexible as our development methodology (which is based on Agile) is very different from a traditional waterfall approach. We’re very picky about the projects that we do – we only do web or iphone apps that are fun, interesting, and that are pushing the boundaries of what’s possible. We’re not too hung up on university degrees or professional background. We’re looking for people who really enjoy coding and are genuinely interested in current web programming trends. If you know anyone that fits that description, please send me an email: andy@agavelab.com.
The Agave Lab Method
A Nice Pair
So lately we’ve been fetching around for a way to take advantage of Pair Programming that would work for us. Some of our projects involve building relatively simple web sites. Often times, we’re building on top of a platform like Joomla, WordPress, Drupal, or Elgg, or we’re using pre-existing patterns and/or classes. In these cases, when we were pair programming, there were long periods where one of the programmers would be staring off into space while the other was installing a plug-in, fidgeting with a CSS file, or some other pedestrian bit of work. On the other hand, when we weren’t pair programming, we’d see programmers get stuck on a particularly thorny bit of code, architect themselves into a box, or miss a critical shortcut.
.
What to do? Pair programming seemed like overkill but without it, we were often spinning our wheels. Enter the “Agave Lab Method”. Here’s how it works:
- Programmers work in pairs.
- Each pair is given two projects.
- Every morning, the pair spends 3 hours together, with 1.5 hours dedicated to each project
- After the 3 hours in the morning, each programmer works on a project solo for the rest of the day
- The next day, the same thing happens EXCEPT, after the three hours working together, the programmers switch projects.
- So, for example, on Monday programmer 1 works on project A while programmer 2 works on project B. On Tuesday programmer 1 works on project B and programmer 2 works on project A. On Wednesday, we switch back.
Okay, I know that this sounds weird and complicated but stay with me here. Every morning, programmer A has to explain to programmer B what he/she did the day before so that he/she can pick up from where things were left off. In addition, each programmer needs to plan out, with the help of his/her partner, what he/she intends to accomplish that day. This forces the right things to happen:
- It forces the code into intelligible form. If you know that someone else is going to pick up where you left off, your code has to be clean, logical, and well-documented
- Two heads are better than one. Solutions are first architected (and later reviewed) with input from two people – this leads to more elegant code.
- A set of fresh eyes can spot potential bugs, and offer suggestions on how to re-factor cumbersome elements
- Knowledge transfer is maximized
- Boredom / burnout is diminished
- Programmers get better at verbally communicating what they’re doing, why, and where they’re having problems
- If there is a particularly thorny bit of code, the pair can co-program during the 1.5 hours of shared time, leaving the more understood programming tasks for solo time in the afternoon.
Of course all of these benefits flow from standard pair programming and, for more complicated projects, we’ll still do full-time pair programming. However, by using this modified approach, we get more throughput (progress on 2 projects rather than 1) and less staring-at-the-wall time for those projects that involve a lot of straight-forward implementation.