Feedback continuum over Binary judgment

Almost everything in life lies on a continuum … not in binary states. For example: it’s a simplification to say that you’re either introverted or extroverted. More sophisticated Myers Briggs tests (and others) will give you an indication of the degree to which you favor one end or another of a dimension. For example: I’m slightly extroverted, but I’m off the charts with my “N” and “T” – the second and third dimensions in Myers Briggs.

Employee performance, similarly, is not binary. And it’s not a one-dimensional continuum, like Myers Briggs dimensions. We’re all good at some things and not so good at others. I’m better thinking out of the box than being put in a box. It doesn’t mean I can’t function in a box – just that I’m not as capable or satisfied there.

Another example: there are not good cooks and bad cooks. There is a continuum of skill on which we fall. And some are great a grilling, but not good in the kitchen. It can be a multi-dimensional continuum.

“Are you agile?” is not as good a question as “To what extent to you embrace and live the values/principles of the agile manifesto?”

I’ve seen leaders judge people, throughout my career, based on a binary judgment of personnel. You’re a hero, or you suck. Some of the <slightly> more sophisticated define (but don’t discuss) a middle ground: “I’ll tolerate you”.

When I say “leader” – I don’t limit this to anointed leaders. Many are leaders on their teams in different ways – in spirit.

Some leaders make these binary judgments, don’t share them with the person in question, and make significant career decisions (or provide significant input to decision-makers) for these targets without their knowledge or feedback. Or they provide the feedback to the target (usually electronically) in an abrasive, accusatory, judgmental way. I’ve seen all of these throughout my career.

Great leaders don’t sit back in their chairs, fold their arms, and judge from a distance. They leverage their colleagues’ strengths and coach them through their weaknesses. Sadly, I find that the art of coaching and constructive feedback to be on the wane.

Posted in Career, Feedback, HR, Leadership, People Management | Leave a comment

Weekly status – in an agile environment

I’ve been asked by clients in the past to provide weekly “status updates” on agile projects.

On one project, where we were using a sophisticated agile project management tool (Mingle), I simply sent a url within the tool to the current state of affairs – driven from the actual data. Piece of cake. Not sure the recipients were appreciative of my conveying “how to fish” vs. my sending them the fish. It was appropriate.

The agile manifesto suggests that we measure progress by “working code”. This extends to other organizational activities. For example, I coordinate most of the hiring for my team. I could send, in my weekly status, the number of interviews I did, or resumes I screened. But in the end, it’s not noteworthy. It’s simply activity. It’s justifying my existence. In the end the important point is: who did I hire.

I’m fortunate, in my current role, that my COO considers reporting “activity” as a waste of time. He wants to know what’s getting finished. He’s wiser than his years.

Posted in Agile, communication, Hiring, Metrics, Project Management | Leave a comment

Positive Feedback

Good software engineers have an engineering mindset. We are problem-solvers.

We also have a critical mindset. That is – we are more apt to identify flaws and fix them than to recognize success or progress.

This penchant for critical analysis extends to feedback on colleagues. I’d like to see a bit more positive feedback proffered in the  software development industry.

Posted in Feedback, HR | Leave a comment

Buy Aptitude; Rent Acronyms

It amazes me to this day that recruiters and companies are still advertising for talent based on initialism matching.

  • 2 years of XML
  • 6 years of Java
  • 4 years of zoological research
  • 12 years of breathing

The software development recruiting process is broken.

Seek attitude and aptitude – not acronyms and accolades.

Trouble is – screening folks based on attitude and aptitude is harder than simple initialism matching. So the lazy folks don’t get to look deeper. Good for me. I get to hire the  deeper talent.

Posted in Recruiting | Leave a comment

Developers wanted

I think many of the job listings out there are pretty boring. Here’s one I created for hiring developers on my team here in Atlanta in an attempt to stand out a bit:

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.


+ 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?

Posted in Hiring | Leave a comment

iterations ~= methadone

The agile manifesto is the foundation of agile software development. Various branded versions (Scrum, XP) promote “iterations”. Iterations are these methods’ approach to facilitating agile’s value:

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.

Posted in Agile, Kanban, Uncategorized | Leave a comment

The PMI-ACP agile quiz – a critique

I took the Program Management Institute (PMI) Agile Certified Practitioner (ACP) survey to assess my knowledge of agile this morning. I was prompted to check into it after having attended a PMI session called:

“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?

Posted in Agile, Certification, PMI, Project Management | Leave a comment

PMI-ACP Certification – hot or not?

I attended a PMI session this week called “Why PMI-ACP Certification is Red Hot…and How You Already Qualify to Receive It.”
It’s rare that I attend user group meetings in my home town, as I have been traveling for projects for most of the past 7 years, but this subject was right up my alley. I was eager to hear how the PMI is addressing agile (after practically ignoring it for most of the past 10 years of its existence).

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).

Posted in Agile, Certification, PMI, Project Management | Leave a comment

Anti-If campaign

I have joined Anti-IF Campaign

Posted in Programming | Leave a comment

Hiring an agile coach

A colleague of mine was once asked for help in creating a job description for an agile coach. One of the suggestions was “5 years of agile project management experience”. Though longevity is certainly helpful, it is not sufficient to find a good coach.

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.

Posted in Agile, Coaching, Hiring | Leave a comment