Posts Tagged agile
Using Tracker for Agile projects
I first got exposed to the Agile methodology when I took a “Thinking in Agile” course. It was a two day course, and they walked you through what it meant to be agile, the processes involved, etc. But thinking back, I fell into the same trap I did back in college. It was mostly talk, and not enough action. I learn by doing, and ipso facto, nothing really stuck. One and half years later, still at google, I became part of an internal project, which needed a kick start. And lo and behold, we decided to subscribe to the agile philosophies and not half ass it as many do. And we decided to use Tracker to manage the project.
The basic ideologies of Agile (and Tracker) are as follows. You work in short iterations (preferably a week or two). Every iteration, the entire team gets together to talk about what got done, and what is up next. You interact directly with the customer or his proxy, who gives you things to do in the form of stories. For a company search app, a story might look something along the lines of “As a product owner, I want to be able to search for a particular employee, so that I know what he works on.” Notice that this story is very well defined, especially for you as a developer. It tells you the target audience, what functionality is needed and why. The why is important because sometimes (not always), you might be able to think of a better way to do something, in which case you can pipe up with said suggestion. The example project below ignores that suggestion and I didn’t spend time to change the demo to meet my suggestions.
Tracker screen
Now tracker allows you to add and move stories around. You can move a story from the Icebox (which is where stories end up by default) into the Backlog, which are the things you need to work on. You can arrange them to order them by priority (and it is all immediate, so someone else with tracker open can see those changes as they happen). Now finally, during your iteration meeting, you sit as a team, and estimate how much each story is worth.
The most important point here is that clients are the only ones allowed to request stories (though you can probably figure out exceptions if you really think that some chores should get points). Customers get to decide what stories need to happen, and what order they need to happen in. Nothing more, nothing else. Now as developers, your role is to estimate how long it will take for the items in order. You can start off with some estimates like, “A point is one days work.” initially, when you are new. You can play planning poker to estimate, which is a fun little activity in itself to make sure no one is influenced by anyone else’s estimates. Now what tracker will do is it will measure how many stories you end up actually delivering per week, and calculate what we call your Average Velocity (pointed out in the screenshot above). This basically denotes how much tracker thinks you can do in the next iteration, assuming that your estimate base remains constant.
Another important thing to note, that only things that the customer cares about, or is customer facing, should be stories. These are thing the customer can see when delivered and brings value to him. So that refactoring you need to do to come out of that hole you dug for yourself? Guess what, its a chore and does not contribute to your velocity. Want to move database schemas to make it easier for yourself? Fixing that bug you introduced in trying to rush through all the stories? The customer doesn’t care (well he probably cares about the bugs, but you are not delivering value, you are cleaning up after your own mistakes), so no cookies nor any points for you.
So a basic flow for an iteration (after estimations and planning poker) is as follows ;
- Customer / Product owner prioritizes stories / chores / bugs in the backlog
- Tracker looks at average velocity and figures out how many it can squeeze into the next iteration
- Developers click start on a story / task when they start to work on it.
- They click finish when they are done implementing on it, but do not click on Deliver
- Pushmaster / Release Engineer clicks Deliver when those changes are pushed to a customer visible place
- Customer gets to try out each story, and then can decide whether it meets specifications, and decides if he wants to accept / reject.
Rinse and repeat, and you have a great way of managing requirements, release plans and so much more. You can figure out who’s working on what, you also get a great host of charting, including burndown charts, charts which allow you to figure out where you are spending the majority of time (whether stories, bugs, chores, etc). Example chart below :
An example burndown chart from Tracker
Did I mention Tracker is currently free to sign up and start using? Regardless of whether you are a product manager who wants to keep his project in line, a developer interested in using agile practices, or just plain curious about what this thing is all about, Tracker has something for everyone. So, what are you waiting for, a personal invitation? You don’t need to be an Agile team to try this out for yourself.
Two heads are better than one
Pair programming is an agile concept and is frequently used in XP (eXtreme Programming). At its core, it is nothing but having two people sit and code instead of one. And while that may seem like an obvious timesink and a doomed concept, considering two people cannot type and code at the same time, it is surprisingly effective for many reasons, some of which I will try to outline with examples from my brief experience.
When you work as part of a team, there is usually a process (sometimes a series of flaming hoops even) which you have to jump through before you can submit your new, super amazing, code which breaks all previous latency records. Or something just as amazing. And for a lot of groups, that involves a code review process, where someone familiar with the architecture of the system or understands the programming language and the problem goes through your code, points out issues (as if there are any in my code !!!) and so on. And while this is a good way to ensure that the quality of code that is submitted to your code base remains above a certain threshold, it becomes a huge timesink. Especially the more you know about the codebase, as everyone and their aunts start sending code reviews your way.
How is this solved with pair programming, you ask ? Well, consider this. While pair programming, assuming one guys starts coding away. What does the other guy do ? He (aha, you shout, as you understand even before I say it) reviews the code as you type, suggesting corrections and optimal solutions in case you start going down the wrong route. But then, you ask, isn’t that a huge waste of time, considering you are basically getting one person to just sit and permanently review ?
Here is where the beauty of pair programming really shines. Its called pair programming for a reason. For one, both programmers take turns in writing up new code, while the other looks on and makes sure the code is up to the amazingly high standards. Another, how many times have you written this super awesome function which took you half an hour to think of, only to find someone tell you in a code review to use this existing library function that does the entire same thing ? Now imagine that guy is, instead, sitting right next to you and telling you this before you even start coding this up.
Furthermore, what if I am a new guy joining a team with a very stable, settled code base. How do I hit the deck running, other than sitting for hours reading up on documentation ? Well, I go find a senior guy who loves pair programming (which is easier than it sounds if a team loves Agile practices) and go pair with him. Instant knowledge dump, and easier transition. This was the case with Arthur, a guy who joined our group for a short period of time. Instead of spending, say two weeks reading design and architecture documents, we started pairing with him from day one. By the end of day three, he had already fixed two bugs (both of which were on the first day itself!!!) and had made quite some headway into designing his first full feature. Now this intensive pairing (some might even call it hand holding) might have caused us to loose some productivity in the first few days, but by the 4th day, we had a new engineer who was capable of working independently if need be while pairing on the initial designs and features.
Also, Pair programming helps increase discipline and productivity. How you ask ? Well, I tend to loose focus quite easily, and love to be caught up on my emails (the thousands that spam me everyday, sigh!). And replying to my IMs takes precedence, often interrupting my thought process. Now I was pairing on the other hand, out of respect to my pair, I usually end up closing all such external annoyances, and often get two to three hours of uninterrupted work. Does wonders for my productivity, which is why I often roam around look for people to pair with.
Of course, if you need to convince management why you need to do pair programming, you need but point them at the multitude of studies that have been done which show an increased quality in software developed while pairing as compared to individuals. Also, if a person ever does end up leaving the team, there is someone on the team left who has paired with him and thus there are no systems which are alien to everyone on the team ever. And hey, its fun to pair, think out loud and bounce ideas off of each other. Seemingly impossible problems may seem easier as well when you pair. Often times, I seek out a teammate to bounce ideas off of, and more often than not, he will say “Alrite, let me get my keyboard. Lets pair on this.” Then it would take two hours to churn it out, and we would have a working, tested prototype by the end of it.
Of course, on the other hand, there is the intimidation factor of pairing with someone who seems much more knowledgeable and would eat you for lunch. Not to mention possible ego clashes and the fact that some people might find it akin to tutoring if they are paired with someone new. But these are pitfalls that can be overcome quite easily with a dedicated team.
And pair programming works really great when you do Test Driven Development. TDD is the art of writing a failing test before going and writing just the amount of code to pass the test. When you practice something known as ping pong pair programming with TDD, it becomes quite interesting and fun. In this, one person writes a failing test, and then the other person goes and writes the bare minimum code to get the test to pass (That is the key, the bare minimum. Don’t do speculative programming). And then, they switch. So the guy who wrote the code the first time now writes the next test, and the other person implements the functionality. This ensures that both people get turns at writing code and tests, and can make sure they cover all the cases. You end up with well tested code, but just enough code for your need. No speculation, no unneeded generalization, nothing extra.
And of course, no agile practice post is complete without an obligatory dilbert comic, so here goes :
Recent putbacks