CodeOverEasy.com

Tag: agile

  • Career Retrospective 2010

    One of the tenants of the Agile methodology for software development is the Retrospective.  Essentially, the Retrospective is a time when a team can look back on the last body of effort, and ask themselves the some variant of the following three questions:

    • What did we do well?
    • What did we do not so well?
    • What can we do to improve?

    I must give some credit to Ben Griswald at JohnnyCoder.com for the idea, but it seemed quite relevant at the end of the year to apply the principle of Retrospective to my career as a software developer.  Moving forward, I will try to post a Career Retrospective on at least a quarterly basis.

    What did I do well in 2010?

    My first instinctive response was simply “I stayed employed.”  I don’t mean to suggest that I have a hard time holding down a job, but more so acknowledge that in the current economic state of our country, there are a lot of software developers who do not have jobs.

    Further, in 2010, I got a new job, which means at the very least that I successfully stood out from other candidates in the eyes of my new employer.

    I started this blog. As I mentioned in my inaugural post, my hope is that this venue will let me talk about the craft of software development and the things that are important to me in that space.

    I launched a new product. The second iteration in the HomeSpot line is HomeSpot AgentPro, which went live this month.  There will (hopefully) be many posts in 2011 about the outcome of that effort.

    What did I do not so well in 2010?

    I’ve been thinking through this question a lot.  It’s always hard to find negative or imperfect patterns or trends in one’s own life.  That I am willing to be introspective at all is somewhat significant.

    In light of all my work in 2010 being as a contractor, I have found that I lacked a certain passion about the work to which I was contributing.  Contractors are by nature transient, and while I did not hold any specific fear of arriving at the office one day and being shown the door, I always held the job to be temporary.  When coupled with my own venture taking time in the evenings, I think the net result was my job became one of duty, not of passion.

    I know that I cut corners in some of the coding and design I delivered.  Sometimes it was due to time constraints.  Sometimes because the client had simply not asked for what I felt was the ‘complete’ solution to a problem.  But either way, as one who stands up to say that the craft of software development is rooted in quality and pride, taking shortcuts is not the pattern I want to find myself adopting.

    What can I improve in 2011?

    I have always considered myself a goal setter.  Perhaps not always as much of a goal achiever as I would prefer, but it is in my nature to establish a target outcome and work to move towards it.

    Thus, in identifying areas of improvement for the year ahead, I certainly look first to those spots where I didn’t do so well – namely passion and quality.

    For Passion, I need to move past thinking of a ‘day job’ as a necessary evil while I do other things.  Rather, every opportunity to get my hands on code – no matter who wrote it, what it does, or who it is for – should be embraced. I have always believed that all learning is cumulative – that we do not unlearn.  Consequently, every chance to see, critique and improve code serves me as an education.  Rather than trying to muster passion for my particular employer or client, my passion should reside in becoming the absolute best software developer I can be.  From there the excitement about some client’s particular issue will inevitably flow.

    Secondly, in as much as I have time and opportunity, I want to expand my particular skillset.  The simplest approach this can take is learning a new language, but even within my area of primary proficiency (that being the .NET platform) I know there is a great deal more I can learn and master.  One approach I have considered to this end is working towards earning a professional certification, not so much for the credential, but rather as a structured way to move towards mastery.

    Finally, in 2011 I want to be more deliberate about participating in the larger community of developers, namely through participation in my local user groups, but also through venues such as Stack Overflow, Linked In Questions and other forums.  Putting myself around other like-minded individuals will benefit me as a developer and professional in many ways.

    And so, here’s to 2011 being a new year of quality, passion, community and progress.

  • Lessons learned from a great team.

    In the midst of transitioning to a new job, I felt it would be wise to take a minute to reflect on some of the lessons learned working with the talented team of developers at the North Carolina Housing Finance Agency.

    When I joined this team in August of 2009, they had recently gone through the departure of their department manager, and in response were adopting Agile as a development methodology. They faced the uphill battle of reestablishing trust among the other business units, and were in the process of migrating a legacy system in preparation for adding new features.

    In 16 months time, we completed the system migration, and delivered on two major business initiatives, earning high praise from both the end users and organization’s leadership. Additionally, we implemented and migrated our work to Team Foundation Server, conducted a pretty significant architectural overhaul, and doubled the size of our team as new work emerged.

    I feel proud to have been part of the team at NCHFA, and it is in their honor that I share these lessons learned. I hope to be able to apply these lessons as necessary with the team I am joining.

    1. Planning and prioritization is a daily discipline. Nearly every activity our team spent time on fell in to one of the following categories of planned work:

    • In-Sprint project work – tasks specifically contained in our Agile sprint.
    • Helpdesk items – end user support of our production systems, under 40 hours
    • Pipeline items – projects in excess of 40 hours of work
    • BPI (Business Process Initiatives) – multi-project initiatives in excess of 100 hours of work.

    Every week, in a standing, Monday at 10am meeting, our entire team would provide status and updates on all work across these categories.  This simple practice of routinely reviewing, re-prioritizing and re-assigning work as necessary allowed every member of our team, as well as our management to have a complete picture of the entire team’s workload and progress.

    2. Trust the process of debating an issue. During our sprint planning, and especially during the lead up to re-architecting our systems, there were many instances when we as a team didn’t always see eye to eye.  More than any other team I have been a member of, the level of honest and respectful debate that we had was significant to our success.

    3. Start manually, then automate. There is no lack of tools to help teams manage the Agile software development process.  But for nearly the first year of working together, our team relied on index cards and sticky notes.  By adhering to a fully manual process, it allowed our team to work out the necessary adaptations and adjustments to our usage of Agile and become experts both individually and collectively of the methodology.  At the point in time when we elected to implement a project management tool, in our case Microsoft Team Foundation Server 2010, we knew how to run our sprints and manage our stories so well that adopting the tool was nearly effortless.  The result is that our usage now of TFS was able to take full advantage of its features for planning, reporting and tracking our progress.

    4. Demonstrate your results across the organization. With few exceptions, we provided an open invitation to the entire organization to attend our end of sprint product demonstration.  In these meetings, we used a few Powerpoint slides to review all our previous sprints, which reminded the business groups of the overall project progress and decision points along the way.  We then gave a full, live demonstration of the new functionality we delivered in the last sprint.   By showing our progress along the larger project timeline on a routine basis, our team established a significant level of trust from the business groups.  We simply let our delivered, working code speak for itself.

    It was my pleasure to be part of the team at NCHFA, and I look forward to hearing from them about the results they will continue to produce in the months to come.  Congratulations to Joe, Tim, Dan, Eric, Steve, Dev and Jaime for all you’ve achieved over the last year.