Most Rails developers know of PeepCode but I know only a few that have actually purchased a screencast from them. I’m really happy that they’ve reintroduced their year subscription. There’s no excuse now - go and buy this! After watching two or three I can say it’s already paid for itself.
Interestingly, I’m enjoying the pdf’s just as much as the screencasts. Keep it up PeepCode!
If you’re a cheapskate, start out over at RailsCasts - but if you like them, help Ryan out and buy some PeepCode material.
We’ve considered utilizing staffing firms in our constant search for talented additions to our team. Staffing Firms call on occasion and we’re always inclined to be cordial and leave the door open. Unfortunately, some firms just go beyond aggressive sales tactics. Here are some things not to do from a client’s perspective.
Building a Relationship Based on Trust Starts When a Lead is Qualified
If a prospect tells you that you’ll reach out to them in a week or two, do your best to have the confidence that they will call. When it goes a few days after the expected date, then feel free to follow up. I personally get annoyed if you call the next day to follow up when I communicated that we’d reach out in a week or so.
Clients Don’t Want to be Sold
If we did opt to work with a recruiter, it would be about establishing a relationship and not about engaging right away or the breadth of your offering. As a client, I want a staffing firm that would be interested in the culture of the organization and what the job description entails - not a firm that wants to get interviewees on the calendar with an incredible sense of urgency. With people, especially as it relates to hiring, fast is slow.
Have Clear Fee Structures
This is pretty self explanatory, but if a client has to ask about your fee structure, then your proposal is unclear. Keep it simple, and keep the client in mind.
Sorry there’s been a void of posts here. My career has been changing very rapidly. I’ve become a part of a great company, and I’m looking forward to pursuing the opportunity there. There is extreme potential both in the business model and in my ability to grow and learn. I’ve recently been tasked with managing the software development process and with leading a great team.
With that, it is time to take a look at the subject matter of this blog. I’m hoping to gear my content more towards my daily experience as an Agile Software Developer and Project Manager in a startup rather than freelance development and entrepreneurship. I hope you’ll enjoy the small shift in focus as I learn along the way. As always, your feedback and input is what makes this a discussion rather than a monologue. I hope we can all learn from each other’s experience here.
For a long time, I’ve been looking for a decent system to manage Second Rotation’s user stories. I have to say, I’ve been very impressed with Mingle. Last week, I worked on refining the story statuses for the life cycle of a user story once it is slated for an iteration. Here’s what we came up with:
Awaiting Information - the engineering team is waiting on the stakeholder for information
Ready For Development - the developer assigned the user story has all the information needed to commence work
In Progress - the developer is working on the user story
Ready for Staging - the developer has finished work on the user story, and it’s ready to be sent to our staging environment
Staged - the story has been sent to our staging environment and is ready for testing
Ready for Deployment - the story has been validated, both from a QA and stakeholder’s perspective. This means the user story is green lighted for production
Complete - the story has been deployed to production
The value of defining these statuses within Mingle is the ability to define transitions. For example, I can report to stakeholders an average delay per user story because I track when a story enters and exits the Awaiting Information status. I can also track how well a developer is fulfilling requirements. If a user story is consistently Staged and then reverted to In Progress, This is all done automatically as the story owner moves it through the life cycle we’ve created.
Another huge analytic - I’ll be able to track estimation quality by comparing planning estimates to the duration of a story having the status of “In Progress”
Eventually, I want to refine these story statuses to reflect what’s done before a user story is assigned to an iteration.
One thing I wish Mingle had that causes a major gap in my regular status reports is the ability to correlate many user stories to a project. Business stakeholders do not usually respond well to a long list of stories, so being able to report status on a project by project basis would be ideal. Thoughtworks (the developers of Mingle) reports that this will be a feature in an upcoming release.
If you’re managing an Agile Software Development project, I highly recommend you check out Mingle.
