Heather McLean

The next meeting of the Fort Worth chapter of the APLN is on September 14, 2010. For the next 3 meetings, Harry Long and Charley Seaman will be presenting Scrum basics since the group is comprised of some experienced Scrum users but many non-Scrum users. Harry and Charley have been working with Scrum / Agile for over 5 years in a wide spectrum of industries.  They worked together at ThinkCash where Scrum/Agile was at an immature state and they helped grow it to a mature state.

Contact Charley Seaman at fortworthapln@gmail.com for more information.

Interviewing for a new position is frequently a stressful and frustrating activity for everyone involved. Interviewees get nervous since they know everything is on the line in this one meeting, and more than one really good candidate was passed up because they didn’t interview well. Interviewers get frustrated because it can be difficult to cover all the necessary bases in an interview, and it’s also hard to tell between a good candidate and someone who’s just good at interviewing. It’s also difficult to standardize the interview process, since everyone who comes in to the interview has a different idea of what makes a good candidate and will confuse the interviewee with a fire hose of disjointed questions.

In my mind, interviews really should be that last checkpoint, something you do when you’ve already decided this person is a good candidate, but you just want to make sure they’re a real, live person and can fit in with the team’s personalities and the company’s culture. There are so many things you can do before the person walks in the door to make sure they’re the right person on the job.

• Make the most of your phone screening process. Unless you have highly technical recruiters, don’t rely on HR to do the phone screens. Have someone from the team take 15 minutes to talk to the person and do basically a “pop quiz.” Don’t ad hoc it; have the team agree on a standard set of questions to ask. Also, take this time to find out what the candidate is looking for in a new position, and be honest about your company and team. It does no one any good to bring someone in for an interview when you can tell long beforehand that the position is not for them.
• Rely heavily on referrals, but not too heavily. One of your best pools of potential candidates comes from existing team members. A statement of support saying, “I’ve worked with this person before and would work with them again,” should tell you all you need to know. At the same time, be mindful that some folks are trying to do their friends a favor or just want the referral bonus, so don’t allow referrals to trump your whole process.
• External references are all but useless. Really. I don’t even check them anymore. Candidates are going to cherry-pick references that they know are going to speak well of them, so there’s really no reason to waste the time making phone calls.
• Demand samples. Any potential team member should be able to provide samples of work. It doesn’t have to be from a previous job (those are typically locked under NDAs anyways), but contributions to open source/community projects, pet projects, or even just mental exercises are good. Developers can provide code, QAs can provide test cases and automated test scripts, and BAs can provide fully developed use cases and acceptance criteria. Really, anyone can put together a basic portfolio.

These tips will get you a lot farther than an interview alone. Additionally, here are some tips for the interview itself.

• Use multiple, small groups. Don’t let everything rest on one interview. Doing two or three interviews in an afternoon with different groups of people can help get a better picture of the candidate. Also, there may be interviewers in the different groups that the interviewee responds to better than others. Also, keep the interviewers down to groups of about three. This will keep the interview focused and less intimidating to the candidate.
• Plan ahead of time. There should be an agreement beforehand between the interviewers on what topics will be covered and even what questions will be asked. By no means does this mean using a script, but it helps keep the interview from being too spontaneous, and it standardizes the experience for interviewees.
• Don’t get too technical. That’s what your phone screen was for. By the time the candidate gets to the interview, you should already know that they can do some coding in C# or write test scripts in QTP. Good interview questions should relate to problem solving, teamwork, and personal achievements. On the flip side, this is a good time to have them do some technical demonstrations for you that aren’t as easy over the phone, such as whiteboard coding or stepping through a complex use case.
• Take them to lunch. Or dinner, or cocktails–whatever ends up working best with the schedule. In the grand scheme of acquiring new talent, the cost is negligible, and these sort of social situations will typically alleviate some of the interviewee’s stress and anxiety.

In my new environment, we’re growing so fast that space is becoming an issue very quickly. We now have resources spread between two offices in different cities (luckily within 10 minutes of each other, though). We’re also considering our options on hiring some coding facilities in Canada or elsewhere for support work, though we have no plans for overseas yet. Due to space constraints, we have also talked about letting folks work from home part of the time.

Still, in a fully agile environment this poses some difficult challenges. The agile culture has emphasized team co-location and face-to-face interactions heavily as a best practice, but obviously in this scenario that’s not likely to be possible. This disrupts team interaction, project visibility, and a variety of other positive aspects of the agile methodology.

There is a never-ending plethora of tips for distributed agile teams, but obviously there is no one-size-fits-all solution. I’ve been brainstorming for a while, and over the next couple of weeks I’m going to try and prepare some solution proposals for the executives here. I’ll let you know what I discover.

If you have any suggestions of your own, feel free to share them.

Just a small update today… I’m finishing up my first week with my new project on the e-commerce team at GameStop. I’m very much excited to be working in the retail/e-commerce space again, and there are a lot of great challenges presented. The group I’m working with is in the process of transitioning to agile methodologies, and we’re working on refactoring and modernizing the software that runs the gamestop.com web site.

There are a lot of opportunities for growth here, so if you’re interested, feel free to contact me. Developers, QAs, project managers, whatever.

The next meeting of the Fort Worth chapter of the Agile Project Leadership Network will be June 10, 2010. The speaker will be Julie Chickering.

Julie Chickering is an Agile Coach with Rally Software in Boulder, Colorado. Her passion is coaching teams to a better, more fun work life. She has the proven ability to transfer job knowledge and skills to all levels, including distributed teams, and has a solid track record leading teams through the challenging transition from waterfall to Agile practices. Julie brings more than 15 years of experience in the software development industry – most recently at Travelocity.com as an Agile team mentor and at a leading global Agile consultancy as a Senior Consultant.

Julie is a board member of the Agile Project Management Network (APLN), dedicated to connecting, developing and supporting great project leaders. Julie is a co-founder of the Dallas chapter of the APLN. Julie is a Certified ScrumMaster and holds a PMP certification.

Please contact Charles Seaman at fortworthapln@gmail.com for more information.

As another code exercise, I decided to look at RFC 4122 (“A Universally Unique IDentifier (UUID) URN Namespace”) and create an object in C# that was capable of handling all five versions presented in that document. I wanted to see if I could successfully interpret the algorithms as described by the document without looking at any reference implementations.

I think in the end it was quite successful and offers a pretty robust implementation of version 1 through 5 UUIDs, including a version 4 UUID which is compatible with the native System.Guid implementation. There is one class called Uuid which can represent any version of UUID, and it is used similar to the aforementioned System.Guid to either create a new unique identifiers or represent existing ones. It also supports explicit casts to/from System.Guid.

Uuid existingUuid = new Uuid("9b1ea5f8-702b-4ad5-97f0-34bb10a28602");
Uuid newUuid = Uuid.NewUuid(Uuid.UUID_VERSION_1);

A battery of unit tests is also included to help verify the implementation. You can download the code from my Code page as usual.

Scrum fails. Spectacularly. Or does it?

In reality, most teams that I’ve seen fail at Scrum aren’t actually failing because of Scrum, they’re failing because they don’t understand what agile really means. Agile project management and processes are designed to be adapted and modified to respond to the particular environment in which they’re used. People who try “Scrum by the book” rarely find that it works, because they’re too focused on following the process and not focused enough on improving/adapting it for their particular needs.

On the flip side, there are also all those who practice ScrumBut¹. I.e., they’re practicing Scrum but they left out some important pieces or deviated so far from Scrum as to break some of the basics. Maybe they aren’t doing daily status meetings or they’re not estimating and committing as a team. Either way, by leaving out or modifying some of the very important core principles, they’ve done themselves a disservice… but they’ll still blame Scrum.²

So obviously, the way to succeed at Scrum then is to modify and adapt it to our needs, but don’t change it?

It is a small conundrum, but easily explained: as with all things, moderation is the key. Also, if you’re going to practice Scrum, it’s important to adhere to some of the core principles. Do have a daily stand-up meeting. Do have planning sessions and retrospectives as a team. Do have fixed-length, consistent iterations. Do have a Product Owner and a Scrum Master. Beyond that, feel free to tweak things. Change up the questions asked in the daily meetings. Play with different styles of planning and estimating. Have one week iterations instead of thirty days. The possibilities are endless and completely mutable, so stick to the Scrum guns as it were, but don’t stifle your ability to adapt by refusing to make changes.

How do we know when an aspect of Scrum is succeeding? That part is actually pretty easy: watch what people do in the absence of controlled direction. If the daily stand-up meeting is succeeding, people will continue to participate in the absence of direction from the Scrum Master. If planning methodologies are succeeding, velocity will increase and estimates will become more reliable, and the team will be committed of their own volition. Good habits will be copied from person to person and team to team.³

Lastly, remember that Scrum is not a “magic potion that heals leprosy and cures blindness.”⁴ Keep your expectations, and remember that moving from waterfall or other rigid, top-down methodologies to agile methodologies Scrum is a learning experience and a culture shift. Successful implementations come from the ability to react and adapt to the organization, not enforcement of strict policies.

I have a new page just for the recruiters out there. Not that they’ll actually read it, but one can hope.

(Sorry to the non-recruiter readers for spamming your RSS readers with this.)

I was reading this article over at Doolwind’s Game Coding Blog (video game development is a bit of a morbid curiosity of mine) where Alistair posits an interesting theory regarding “fun over features,” his own addition to the agile manifesto. In essence, the product team for a video game should focus more on adding fun to the product before throwing in more features, therefore adding actual value instead of perceived value. In other words, by focusing on the qualities proven to sell a game as opposed to all the bells and whistles that the team or stakeholders want to add, we get a real return on the investment.

In the world of business software, I would say a good analogy to this concept is “usability over features.” In other words, focus on adding that things that increase the customer’s productivity and satisfaction on core features rather than adding all the cool stuff that your competition doesn’t have. While there are sometimes provable competitive advantages to having a feature that your competitors don’t, more often than not it is the software that does the core things better that wins the race. If your word processor makes it difficult for the users to actually compose documents, they’re going to spend more time complaining about the pain of using the product rather than using all the other “cool” stuff that you added. Or, more likely, they’re just going to use a competitor’s product that edits documents better than yours.

The user experience is paramount. If you can’t focus on that aspect of the software and make it pleasurable (or at least efficient) to use your product, then you’re dead in the water before you ever even get to sell the customer on everything else that it can do. When developing a new product or even maintaining a mature one, I would consider it best to prioritize your backlog in a way that promotes the core set of features. First get the engine and the wheels on your car right before you worry about the color of the paint.

Successful software projects require participation and commitment from both the stakeholders and the development team. All too often, business owners like to brainstorm a list of requirements, which is typically an unprioritized jumble of “must-haves” and “nice-to-haves” with no direction, then throw those over the wall to the IT department to implement in a vacuum. Without ongoing feedback to determine priorities and success, any team dealing with this situation is bound to fail. Sadly, most teams accept this state without argument, since that’s “just how things are” in the IT world.

True success requires an ongoing conversation between business and IT at the very least. In an ideal scenario, we can break down the traditional barriers between business and IT that have been erected in most organizations and quash the “us versus them” attitude. This typically means having a full-time product owner on the team who can provide direction and timely decisions regarding the product. It’s actually quite disheartening to see how many teams try to plow through a project without this crucial guidance. Is it any wonder that the customers are often disappointed with the end result?

What demoralizes the team even more at this point is that they are often blamed for not fulfilling or understanding the requirements they were given, and the stakeholders are seen as inculpable for the failure since they are certain that they provided all that was needed. This is simply not true; no matter how good your requirements, design documents, and project plans are, nothing is a substitute for ongoing, active participation with the people who are actually delivering the software.

I believe that most of this stems from the misguided notion of running IT as a business—in other words, an internal vendor completely separate from the rest of the organization. This furthers the disconnect between the stakeholders and the product team and reinforces the artificial barriers I mentioned earlier. Also, the notion of “chargebacks” pushes the stakeholders to treat IT as they would an external vendor: with little trust and without direct participation. To fix this, IT must be integrated with the rest of the business in such a way as to be part of the team rather than a separate entity unto itself. Likewise, they must be given a healthy budget to do both maintenance and growth, just as if they were any other division of the company, rather than relying on chargebacks to fuel projects.