I think the recruiting process for software talent sucks.

I cringe at these emails I get seeking 2 years of xyz and 5 years of m&m and … etc. I ignore them. Hiring based on acronyms and experience is misguided. Sometimes it’s the recruiter’s fault; sometimes it’s the hiring manager’s issue. These approaches are a cop-out. They indicate laziness to perform the due diligence required to find real talent.

I seek heart and talent, or as I like to put it: attitude and aptitude. Experience, skills, college degrees, and certifications are all indicators of talent, but are not the definition of one’s capability to contribute.

I’m looking to add a few *strong* software developers to our team. Our tech stacks are Ruby on Rails, and IOS. It’d be really cool if you had experience in one of them. But if you have a solid OOD foundation with great collaboration skills and the passion and drive to learn, keep reading.

Us:

+ Well-funded start-up
+ Ruby-on-rails/IOS technical environment
+ B2B automobile domain
+ Agile done right (not scrum or XP, but generic agile – including engineering practices)
+ Co-located team just north of the Perimeter
+ Great leadership
+ Fantastic team

We are agile through-and-through. Go through the XP Engineering practices. We practice them all. Think more Kanban than scrum. Think Lean Startup.

We believe in self-directed teams. With self-direction comes great responsibility.

We do a coding dojo every Friday afternoon. We feel it is important for developers to “sharpen the saw”.

You (not necessarily in this order):

+ Comfortable with ambiguity (we’re a startup)
+ Creative
+ Interested in and possess the communication skills necessary to be effective in pair programming
+ Interested in and possess the discipline to practice
++ TDD(RSpec, Kiwi)
++ BDD/ATDD (Cucumber, Frank)
+ Passionate about your craft. Really passionate.
+ Sense of humor
+ Very collaborative (with other devs, analysts, testers, management).
+ Courageous (per the XP values)
+ Strong object-oriented design/development skills
+ Smart: strong analytical and problem solving skills
+ Crave learning new things
+ reliable and professional
+ Probably have an active Github account and contribute to open source projects

Things I might hear that indicate this might not be a good fit:

- “I only do [back-end|front-end|Ruby|IOS|ETL]”
- “[VB|Cobol] rocks”
- “I love going to meetings”
- “My degree and certifications are proof that I am qualified to do this job”
- “Quality is the responsibility of the QA department”
- “I’d rather work alone.”
- “I’m fine, as long as every requirement is documented before I get started.”
- “Where’s my cubicle?”
- “Don’t ask me to do that. I’m a dev. That’s the job of the [Tester|Iteration Manager|management]”
- “I won’t submit a solution to a coding challenge. My resume speaks for itself”

Want to join a great team?

responding to change over following a plan

and by extension to the second agile principle:

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Are iterations the only way to respond to change? No. Kanban, for instance, adapts more frequently. One could reasonably argue that that Kanban should be termed “continuous adaptation to change”.

Remember when weekly builds were all the rage? Then it became daily (Harken back to The Joel Test, circa 2000. Daily builds were in it). Finally, we got to continuous. Now we’re bridging the last mile in a continuous fashion, through continuous delivery and continuous deployment.

Iterations are today’s backlog management equivalent of weekly builds – a step in the right direction, no doubt, but not the final answer.

I’m tired of folks who argue that you’re not agile if you don’t have an iterations’ worth of estimated/analyzed stories prior to the iteration planning meeting. They’re missing the point. Having a fully analyzed and estimated backlog may be comforting to some, but in a frequently changing environment much of the effort to get there is waste. Even having enough of your backlog “fully” analyzed and estimated to peel off into the next iteration doesn’t mean you’re “agile”.

Iterations are like methadone for the waterfall heroin addict. Just as methadone helps heroin addicts come down from their illusory cloud of nirvana, so too does an iterative approach help waterfall addicts come down a bit from their illusion of predictability and control of software development. Just as methadone, however, iterations should be a stepping-stone; not an end-state.

“Why PMI-ACP Certification is Red Hot…and How You Already Qualify to Receive It.”

I posted some ruminations on PMI interpretations of agile in my post earlier today: PMI-ACP Certification – Hot or Not?.

I missed 3 out of 20 questions on the agile survey. I had some problems with some of the questions. So maybe it’s just too new. Suggest you take the survey yourself before reading my interpretation.

Here are the ones I got wrong or that I found confusing:

What is the difference between a release, and an iteration?

The “right” answer is “A release consists of many iterations”.

I answered “They are mutually exclusive”.

For one thing, the “many” in the “right answer” is misplaced. I’ve done projects where we released every iteration. That’s not “many” iterations.

Secondly, sometimes an agile team works on multiple tracks across multiple products within iterations that can be released independent of iterations and of other products. What if your team also does production support? Right – this isn’t the clean, book-learning of “a release is comprised of a number of iterations”. It’s based on the reality of teams out in the wild. If you want to test, I think it should be based on reality rather than some simplified Pollyanna view where teams work on only one product at a time and discover that their work magically fits into n-iterations. (Note to APLM tool creators).

Hence my answer: they are mutually exclusive.

What is the timing of when XP teams work on features?

The “right” answer: “Sequentially”. My answer: “In any order”.

Clearly “once all the requirements are complete” is not correct.

And “simultaneously”, another possible answer, is … well… I don’t know. I guess it could have been a reasonable response.

“Sequentially” doesn’t make sense to me, though I see how they inferred this as the correct answer. I think it’s about proceeding “sequentially” through the prioritized backlog (or – since we’re talking XP here, probably Master Story List is more apt). A couple of problems with this though:

If I have multiple dev pairs they are almost always working on different stories simultaneously.

The sequencing of the backlog (using biz value, risk, etc.) is an exercise that causes stories to flow into an iteration. Within an iteration – typically the focus of the XP Team as stated in the question, the sequence is usually not so important (unless you have dependencies or other factors driving sequence).

Of course, Kanban throws a whole ‘nother wrinkle here. Still – multiple people are working on different stories simultaneously.

What is the definition of method tailoring?

Never heard that term before, but I guessed right. More context on the question, or a rewording, would be appropriate.

On an agile project, sponsors, developers, and users should be able to maintain a constant pace for what time period?

The “right” answer is “Indefinitely”.

We talk of “sustainable”, not “constant” pace. “Consistent” may be more palatable, but still – “constant” seems wrong.

Secondly – the pace question is usually a comment on the agile team – not the external stakeholders, and certainly not the users.

I answered “for an iteration”. I have always thought of the iteration beginning and ending ceremonies – particularly the retrospective – as a break from the pace of the iteration: a time to come up for air, collect our thoughts, then hunker down and proceed. Again – Kanban has a more constant pace, so adds another wrinkle.

With respect to a sprint, what does velocity measure?

The answer is “the amount of work a team can accomplish in a given sprint”.

First – velocity is a more general agile term that is not specific to scrum. I would generalize the question/answer.

Second – velocity is not necessarily what it “can” accomplish. There’s historical velocity, for instance, which measures what a team has accomplished in past iterations. I would modify the answer to say “accomplishes” rather than “can accomplish”.

Ah well. I’ve always found these attempts at agile assessments fraught with confusion. Multiple choice tests are difficult when the content is complex and context-dependent.

I’d love to hear feedback. Did you take the test? How’d you do? Any comments on my criticisms?

I have a problem with the title of the talk, for one thing. Though the speaker lamented the “pass/pass” nature of Certified Scrum Master (CSM) certification offered by the Scrum Alliance, the title of this talk indicates that you, dear PMI member, are already qualified (without any experience or understanding ?) to receive (not just sit for the exam, but receive) ACP certification.

Second – I don’t think it’s “red hot”. I did a quick search on DICE (without geographical restriction) for ACP and got 14 hits. A search for CSM got 86. I was [pleasantly] surprised at how few hits I got on both. “Scrum” turned up 2,811 hits and “agile” turned up 8,765. I admit that some uses of the word “agile” are probably Webster’s definition, but I doubt scrum postings refer to rubgy.

The slide deck from the presentation I attended includes a visual of a “Crossing the Chasm” example (from Geoffrey Moore’s 2002 book of the same title) showing that, though Scrum Alliance (not Agile Alliance or any other org mind you) were useful for Enthusiasts and Visionaries in the beginning, PMI is “better positioned” to “cross the chasm” with Pragmatics, Conservatives, and Skeptics. He may be right; they have 500,000 members and a 40-year track record. But the content I’ve seen from PMI on agile indicates that the understanding is not yet there. And I’m not sure their certification approach is well-equipped to deal with an empirical process. (For the record, I attended a 10-week PMP training session – before my agile exposure).

Some areas of misunderstanding I’ve seen from various sources:

Mapping a work-breakdown structure to agile feature decomposition as a simple matter of terminology misses the subtlety of vertical slices and defining progress through “working software”. A “story” is not just a WBS “activity” in different clothing.

Mapping “similar” roles from classic project management to agile by suggesting that a senior project manager is like a product owner and a junior PM is like the scrum master misses the whole customer involvement and product owner as a customer proxy concept.

Agile is sometimes depicted as having a primary focus of avoiding waste or providing productivity improvement. This focuses on efficiency and misses the more important (my opinion) matter of effectiveness. Getting the wrong product out without waste helps nobody. Effectiveness – “doing the right thing” is about listening to the customer and adjusting your preconceptions based on observation. Agile is not just about eliminating waste (e.g. useless documents). It’s more about getting to the right destination – even if more slowly. I know it’s harder to sell that way.

Showing a cone of uncertainty that is narrower at the beginning based on iteration length misses the point. I am not more certain at the outset just because of the iteration length I’ve chosen. I haven’t thought deeply about this yet, but it seems to me that the only impact of iteration length on the cone of uncertainty is the fluidity of the narrowing. That is – with 4-week iterations, you get a more marked narrowing every 4 weeks where with 1-week iterations, you get a more fluid narrowing – smaller narrowings, but more frequent.

Presenting SCRUM in its 2002 form (ala Beedle/Schwaber) with 30-day sprints is crazy. I’ve never seen anyone do 30-day sprints. Imagine scheduling a recurring meeting for, say, your sprint review, at “every 30 days”. It would be a different day of the week each iteration. 4-weeks, 3-weeks, 2-weeks, 1-week, and 1-day are the variations I’ve seen. I also can’t believe that people still show slides that depict 4-hour sprint planning meetings and 4-hour sprint reviews (regardless of iteration length). The problem here is that you cannot codify an empirical process. You can only provide guidance, rules-of-thumb, and context/environment for which to account. Here is where PMI faces its most significant hurdle I think.

I’m accused sometimes of answering questions with “it depends” more often the people would like. I once had a client who insisted that I should be able to tell him the optimum agile team size. People often ask for the optimum iteration length. There’s no one answer for these questions. They are all context sensitive. The good thing is that, in an empirical process, you try something, see how it works, and then adjust over time. (I’ll leave the incongruence of this empirical approach with antiquated “tell-me-up-front” budgetary approaches for another discussion).

I think classic training is ill-equipped to convey the complexity of empirical processes. Think back to your high school chemistry classes. Did you learn more from a book, or from the experiments? Game approaches (ala Innovation Games and GameStorming) are, I think, the only hope we have to teach empirical approaches like agile/lean (not just scrum) effectively.

It’s easy to critique from the outside. I’m sure the PMI-ACP folks have the best intentions. I’m undecided about whether it’s worth spending time to pitch in to help, or to write it off as yet another useless certification.

Next post – I took the ACP survey on the PMI site. My results and comments will follow. (I missed 3 out of 20 questions).

For example, I once heard a presentation at a software architecture user group meeting from an agile practitioner. The guy presenting had done agile for a couple of years, all at the same company; he had no diversity of experience and had found the way to implement agile within his context. The examples were all slanted towards what his team had found to be effective, yet they were not explained that way. For example – “you always do a burn-down within a sprint and a burn-up for a release”, without discussing the differences and explaining why they did it that way. The audience had no agile experience and almost came away with the perspective that agile was just another process.

If this guy had spent 5 years in the same environment, I think he’d have had the same myopic perspective of agile. If he took a job as an agile coach, he probably would have coached what worked for him in his old company without considering the client’s context.

I think there are other factors that are at least as important as tenure to seek in an agile coach.

Seek diversity in your agile coach.

That is – diversity across

• technical stacks (not just yours)
• business domains (not just yours)
• team sizes (both large and small)
• multi-team and single team.
• local and distributed (across both building floors and oceans)
• internal and external projects

Seek experience doing (working as a part of an agile team) as well as experience coaching. Agile coaches (or coaches in any endeavor) can lose perspective of the practical challenges in implementing agile if they dedicate all of their time to coaching. On the other hand, a good practitioner is not necessarily a good coach.

Seek strong communication skills. Find someone who is comfortable and effective communicating to the team, to project managers, iteration managers, and line managers and to executive management.

Seek a coach who is more pragmatic than dogmatic. For example avoid a coach who might seek to change your estimation scale at the outset, or who insists that all stories should be broken into tasks without understanding the context in which you operate.

One of my favorite questions I suggest you ask a potential coach: “What do you suggest we seek in an agile coach?”. If the first answer is certification, be wary.

In any question you ask, beware answers that do not take your organization’s context into account.

Some of the steps in his test are still relevant, but not as much of an issue today. Some are antiquated. These are yes/no questions. He suggests that if a team has a score of 10 or lower, the team has serious problems. Here’s my take on his 12 steps, particularly in light of the popularity of more collaborative and agile software development methodologies, like XP and Scrum.

1. Do you use source control?
• Still relevant, but I’d say if you don’t have source control, you have serious problems, regardless of the rest of the questions. There’s simply no excuse today with all of the open source options.
2. Can you make a build in one step?
• Still relevant, and many folks have caught up with this capability with the tools available today compared to 11 years ago. In fact, the problem has moved beyond dev builds (which I presume he is discussing here) to deployment to different environments (QA, UAT, etc.). Deployment in one step is rare, but desired. This should be the new test, I think.
3. Do you make daily builds?
• This should say “at least” daily. Continuous Integration is the current practice for evolved teams.
4. Do you have a bug database?
• I don’t see this as relevant. On agile teams, for instance, the team is collectively responsible for managing quality. A card on the card wall representing the bug can be a great mechanism for managing your bugs. I suspect this made the cut because Joel’s company’s flagship product at the time was fogbugz – a bug tracking tool.
5. Do you fix bugs before writing new code?
• I don’t like this one simply because the priority of what gets done is based on business needs. If the bug you want to fix first is a typo in the copyright statement, sure it should be fixed, but not necessarily right away. It should be prioritized against everything else.
6. Do you have an up-to-date schedule?
• Agile projects emphasize continuous planning. I would rephrase this to ask if planning is done on a regular basis and if everyone on the team understands where the project stands and what needs to be done to get it to the next release.
7. Do you have a spec?
• I’m not quite sure what kind of spec he’s talking about. Spec is very generic, and could refer to a functional spec (i.e. requirements), architecture spec, design spec, security spec, etc. In an agile environment, we emphasize evolving the requirements and design over the course of the project, rather than stating it in a document up front. I might reframe this to say “Are requirements and design decisions managed and properly understood by the whole team?”
8. Do programmers have quiet working conditions?
• Many agile teams prefer an open collaborative environment over quiet corners for programmers to crank out code on their own. Pairing is a great model for programming collaboration and certainly makes for a less-than-quiet environment.
9. Do you use the best tools money can buy?
• I think the reference here to money is antiquated. Back in the 90’s, open source was not nearly as prevalent. I think I would say “Do you use the best tools for the job?” or something like that. Then again, ask an IntelliJ guy to debate Eclipse, or Maven vs. Ant, or … you get the picture. “Best” is interpreted through the eyes of the technology religion sometimes.
10. Do you have testers?
• I would ask “Are testing responsibilities understood and covered by members of your cross functional team?” for an agile environment. “Having” testers does not imply much – particularly if they test the code at the 11th hour – right before release.
11. Do new candidates write code during their interview?
• I like this very much. But I wouldn’t say it’s necessarily “during” the interview, perhaps simply “part of the interview process” (e.g. code submissions in advance). Still – sitting down with someone to write code is a great test of a programmer’s skill.
12. Do you do hallway usability testing?
• I would ask instead: “Is the customer represented within your process to provide regular feedback on your product?” Hallways are interesting, but at a software firm, you get a “software developer” slant on the feedback. This is probably good if you’re developing Fogbugz or an IDE, but if you’re creating a website to appeal to the retired community, your usability testing will likely be misguided.

I’ve seen companies in Careers 2.0 convey their Joel Test as “8 out of 12” and “10 out of 12”. Joel’s perspective is that anything below an 11 suggests you have serious problems. If you want to use his test as a metric, OK, but Joel’s view (11 years ago, anyway), is that it represents serious problems. I’m not sure you want to convey that to your potential candidate pool. Or… maybe you do. It certainly is more candid and honest than not pointing out the issues.

Aside: I wonder if Joel would still tout Microsoft’s preeminence as he does in the article (“companies like Microsoft run at 12 full time”). I wonder what Joel would say.

I didn’t get a chance to talk to him, but here is my advice.

First, discuss the topic with the team. Ensure that there is agreement that long stand-ups are negatively impacting the team. It may be (but it’s unlikely) that the content of the long stand-ups is important to everyone,

Determine root cause. I find a couple of causes that can be addressed in different ways.

Long-winded people offering irrelevant input or input that is relevant to only one other person: Record the contributions of each of the long-winded folks and review with them. Identify specific content that is not relevant to the team.

You’ll often find paycheck rationalization offerings (e.g. “I had my one-on-one with my manager yesterday”).

Or you may find someone simply regurgitating their calendar (managers are likely to be the offenders here).

Or it could be politically driven public thrashings that are more appropriate to share in private (“David – you seem to be checking code in without any tests. Remember, we agreed that we would write tests”).

I’ve seen stand-ups where multiple team members will regurgitate events in which the whole team participated. If the whole team attended the iteration planning meeting, there is no need to mention this in the stand-up.

Start timing folks. If anyone talks more than 2 minutes, make them stand on one leg, or ask them to extend their arm holding a heavy book while talking. Or use a timer (obnoxious alarms are best).

Conversations that are not relevant to the whole team: Institute a “parking lot” flip chart or white board where topics for further conversation can be captured for discussion after stand-up. Ask the whole team to help identify potential parking lot items when they occur; add them to the parking lot when identified and move on. Ensure that those follow-on conversations occur (else you run the risk that folks will continue to insist on in-stand-up dialog).

Use a speaking token and ask the team to be rigid about not talking when they don’t have the token. As conversations occur, the token passing will make it obvious that a conversation is occurring, which should help folks to self-identify opportunities to use the parking lot.

Explain to the team that the stand-up is not the only opportunity for conversation during the day.

Use a laser pointer to have folks point out the relevant stories/tasks on the physical card wall as they speak. They will be less likely to pontificate on irrelevant details if they have no card to point to.

I’ve attended stand-ups of over 40 people that have taken less than 10 minutes. That’s less than 15 seconds per person. Granted, these were teams that were pairing, so oftentimes the contribution of the second of the pair was of the form “ditto Joe”. Still – if a team of 40+ can get it done in 10 minutes, there’s no reason why your “2-pizza team” cannot.

Another, less frequently cited agile tenet is to do the riskiest work earlier. The idea here is that you avoid late surprises when risky work turns out to be expensive. Better to discover this expense earlier.

When most folks talk about the backlog order, they refer exclusively to business priority.

I think ordering or sequencing the backlog must take more than just business priority into account. Yes, business priority is important, but so are a whole host of other factors, such as early exposure of risk. Balancing these factors is part of the art of project management.

Factors to incorporate into sequencing decisions:

• Business Priority

• Dependency Order: Despite our best efforts to decompose the backlog into independent stories, the fact is, the tension between the INVEST priorities sometimes cause us to define stories that are dependent on other stories.
• Mixture: The Rock/Pebble/Sand metaphor is helpful here. Consider a bucket at the beach. If you fill it only with rocks, you have a great deal of wasted space in the bucket, due to the space between the rocks. Though it may be unable to accommodate another rock, you may be able to slip in a handful of pebbles, to fill the spaces. Following that, you may be able to slip in some sand, to fill the spaces that the pebbles were unable to occupy. So it goes with an iteration. You don’t want to fill your iteration bucket with only large stories, because you’re losing the opportunity to slip in smaller stories. For example – if a developer finishes a story at 3pm on a Friday afternoon, you’d probably rather have him knock off a small story in the next couple of hours rather than start a large story.
• Crowding: Many advise that agile development teams define iteration themes. This is a good concept in theory, as it allows the team to focus on accomplishing a larger goal in the iteration. The risk here is that you have your whole development team working in the same parts of the code base. This can merge issues as the team commits code to the code repository. Consider the source-code crowding problem when sequencing the work.
• Risk: As mentioned above, the earlier you schedule the risky elements of the project, the more insight you have into your completion date. One element of risk is embedded in non-functional requirements. For example – if you have performance or scalability requirements that are risky, it’s better to implement the stories that are sensitive to those requirements earlier.
• User Feedback: If you have elements of the software for which user feedback is critical to making the right decisions, schedule this work earlier. If you delay these features towards the end, the need to change the system in response to the feedback becomes a schedule surprise. Worse, if you decide not to incorporate the feedback in order to make your date, your users are not just unhappy; they’ll feel that their input has been ignored.
• Exercise the architecture: Scheduling the highest business value work first may avoid elements of the architecture into later in the development cycle. For example, perhaps the “happy path” of execution is deemed the higher business value. This might delay consideration of elements of exception handling to the end of the release. First pass implementations within an architecture are always riskier, and could introduce schedule surprise. It is wise to exercise all elements of the architecture as early as possible.

As I mentioned, these factors are often competing. The context of your project defines which of these dimensions are more or less important. Yes, do the highest business value work earlier, but don’t forget to consider these other factors as well.

Verbal, constructive feedback over written evaluations
Measuring output over measuring input
Frank feedback from colleagues over speculative management judgment
Real-time, frequent feedback over periodic high-ceremony assessments

Though the things on the right are commonplace and often dictated by antiquated HR policies, I value the things on the left more. Much more.

Principles

Giving feedback

My highest priority in giving feedback is to help my colleagues improve – to benefit them individually and the organization collectively. I always preface my feedback with this sentiment.

I understand that not all recipients are comfortable with feedback. I choose the time and place of delivery to respect this sensitivity.

I always ask the recipient if he/she is willing and receptive to feedback at that time/place and graciously accept “not now” for an answer.

My feedback focuses on behavior and outcomes – not the person.

When providing critical feedback, I consider the constraints and challenges in play at the time of the performance for which I am providing feedback.

I acknowledge intelligent risk-taking as a necessary component of creativity and delivery of value and incorporate my appreciation for it in my feedback.

I ask for feedback on my delivery in order to continually improve my ability to give constructive, valuable feedback.

Receiving feedback

I welcome critical feedback about my performance as a gift, and express my appreciation accordingly, regardless of whether I agree.

If I am not in a good place to receive feedback, I respectfully request an opportunity to reschedule.

I refrain from defensiveness or questioning the motives of the person giving me feedback in order that I can absorb the essence of the feedback.