Developers
Work my way
The thing I love most about Kiln is how easy it makes it to work the way I want without any risk of negatively impacting my teammates or our customers. Branch repositories give me the flexibility of using my own workflow, and Kiln, with the help of Mercurial, makes it simple to move the changes I want from that branch back into the main line of development as soon as I'm ready. That means I can write experimental code and easily share it with other developers but never risk a broken build. Kiln also makes it easy to continuously pull changes from the main line of development. So even if I'm off working for a while, I rarely ever experience the merge hell that you get with a centralized tool. This kind of freedom was never easy to come by with Subversion, and it sucked to feel trapped by my tools.
Keep up with the team
And even though everyone can have these sandboxes, Kiln makes it easy to stay on top of what's going on. I keep the Kiln activity feed, filtered for the project I work on, open in my browser all the time. Whenever I'm curious what other people are working I switch to it and scan for interesting changes. It's easy to quickly scan all of the changes and decide if I want to know more about a particular change.
Communicate about code
If I do find a change in Kiln that I have a question about, I use the the built-in code reviews to start a discussion about it. The code review interface makes it easy to link my questions and comments to specific lines of code, and that keeps the conversations short and to the point. In fact, when I am working on a feature, I'll open up code reviews as the feature progresses to get feedback from my teammates instead of interrupting them to ask a question. Having code review built directly into the source control system means that these conversations stay connected to the code history. That kind of audit trail is useful when tracking the progress of features or investigating the origin of bugs.
Track features and bugs
When I'm not working on new features, I am usually fixing bugs, and the Kiln web UI makes it much easier to figure out where and when bugs were introduced as well as what versions are affected by that particular bug. File annotation and the electric DAG make it possible to quickly figure out what changeset introduced a particular bug and see what tags include that changeset. With that information, I can quickly create a branch, go back to where the bug was introduced, fix the bug, and merge the fix upstream.