One thing led to another and there I was contemplating the job req for what I would look for in (and what I strive to be as) a software development leader.
Experience:
- Development experience - preferably within the last decade
Aptitude:
- Can tell a crappy architecture from a sound architecture
- Can tell a crappy implementation from a sound implementation
- Can tell the difference between someone who is busy and someone who is productive
- Can discern the difference between a good candidate for a position "on paper" and a good candidate for real
- Demonstrates a deep understanding of what quality means for a software product (including non-functional requirements like performance, supportability, and extensibility)
- Can tell when an architect, developer, QA, BA, or business partner is blowing smoke up his hind quarters
- Can speak the dialect of business - ROI, NPV, customer acquisition cost
- Can relate to business stakeholders and build collaborative relationships
- Can connect to team members on a personal level
- Has a good sense of humor
- Understands the difference between a prototype and a production application
Attitude:
- Will call out a crappy architecture and drive change
- Will call out a crappy implementation and drive change
- Will call out the busy-bees and the smoke-blowers
- Will demand demonstrable quality (including non-functional requirements)
- Will demand reasonable tests (unit tests, component tests, system tests)
- Does not suffer fools gladly
- Will not sit through a PowerPoint that depicts supposed progress without demanding demonstration of said progress
- Will not abide bubble gum and duct tape solutions to production (or development) defects
- Demands continuous improvement
- Demands root cause analysis (5 why's)
- Demands customer involvement in product development
- Continuously seeks to improve efficiency by asking "why" and "how can we do this more efficiently" (e.g. - PMO requirements for excessive documentation)
- Is willing to fight for the resources required by the team to deliver
- Cares deeply about the team
- Cares about the career development of team members
- Cares deeply about product quality
- Will celebrate true success with the team (no gratuitous applause please)
- Will always give credit to the team for success
- Will remove team members when necessary
- Has a coaching mentality
- Is willing to get hands dirty (writing code, writing/running/debugging tests, fetching pizza)
- Is always available to the team
- Exhibits patience, when appropriate
- Exhibits impatience, when appropriate
Integrity:
- Tells the truth - for instance about project status
- Is clear to team members on expectations and performance on a regular basis (not just at review time)
- Is willing to stand up and fight for the team
Ah... it's late. that's as far as I got. I felt like the integrity section was short, but many of the integrity issues bled into attitude. What did I miss? What do you disagree with?
Monday, December 22, 2008
Sunday, December 21, 2008
Dysphemism and cross register synonyms
I love learning new words. During a conversation in our open-space collaborative software development team environment last week, I used the term euphemism incorrectly. Thanks to Steve Moyer for pointing out the error of my ways.
Apparently, the subtlety is that a euphemism substitutes a less harsh term for another term. I can't remember what I said, but it was akin to saying "The head" was a euphemism for a restroom. Since "The Head" is harsher, it was not a euphemism, but a dysphemism.
Had I said that "Powder Room" was a euphemism for "The Head", I would have been correct in my usage.
By the way, these two terms are considered cross-register synonyms. Cross-register synonyms vary across some orthogonal degree on their subject. For example - dysphemism and euphemism are cross-register synonyms that vary in their degree of harshness. I found a good description of this particular cross register synonym and cross register synonyms in general here: http://www.linguistics.ucsb.edu/faculty/cumming/ling50/euphemism+dysphemism.htm.
Apparently, the subtlety is that a euphemism substitutes a less harsh term for another term. I can't remember what I said, but it was akin to saying "The head" was a euphemism for a restroom. Since "The Head" is harsher, it was not a euphemism, but a dysphemism.
Had I said that "Powder Room" was a euphemism for "The Head", I would have been correct in my usage.
By the way, these two terms are considered cross-register synonyms. Cross-register synonyms vary across some orthogonal degree on their subject. For example - dysphemism and euphemism are cross-register synonyms that vary in their degree of harshness. I found a good description of this particular cross register synonym and cross register synonyms in general here: http://www.linguistics.ucsb.edu/faculty/cumming/ling50/euphemism+dysphemism.htm.
Saturday, December 13, 2008
Agile Pants
I found these "Puma Agile Pants" when doing a search on Amazon for agile literature:
Agile Pants... don't pair without a pair.
Agile Pants... don't pair without a pair.
Friday, December 12, 2008
Test Lookup
Kris Kemper has a nice blog entry on finding tests related to code you are changing that lines up well with a concept I've been pondering today.
I have a colleague who asked me to look over a rather large C# software system, made up of many (>20) .NET projects. In the best agile way, he is relying on his elegant structure and well-named/concise tests to serve as the documentation for anyone who might try to understand the code.
Being self-aware, my colleague understands that he is too close to the subject to be able to determine "understandability" of the code by others. So he asked me - an outsider - to take a look. I think he was also hoping that if I - as a supposedly post-technical project manager - could understand it then he could brag that his code was so understandable that "even a PM can understand it". (Reminds me of those old Life cereal commercial where Mikey, who never likes anything, likes the cereal and his siblings declare "Even Mikey likes it !")
So I picked a class at random. Nice short methods, but reading the code didn't give me as much insight as I hoped. Then I thought... ah the tests. I'll read the tests. So I right clicked, searched for usages, and navigated to the location that had "unittests" in the name. Then I thought - wouldn't it be nice if I could right click on a method name, or a class name, and - instead of asking for usages - I could ask for tests.
That got me to thinking - what would constitute a test? A unit test that simply invokes a method or instantiates a class may just be using it for setup or for supporting scaffolding. But then wouldn't that be a smell? Shouldn't that irrelevant setup junk be in a setup, or injected or...
Anyway, Kris gets to much of these points... my main extending thought is simply - wouldn't it be nice if the tools could help us navigate to tests and sniff out those smells (rather than force them by removing the method, as Kris's technique suggests)?
I have a colleague who asked me to look over a rather large C# software system, made up of many (>20) .NET projects. In the best agile way, he is relying on his elegant structure and well-named/concise tests to serve as the documentation for anyone who might try to understand the code.
Being self-aware, my colleague understands that he is too close to the subject to be able to determine "understandability" of the code by others. So he asked me - an outsider - to take a look. I think he was also hoping that if I - as a supposedly post-technical project manager - could understand it then he could brag that his code was so understandable that "even a PM can understand it". (Reminds me of those old Life cereal commercial where Mikey, who never likes anything, likes the cereal and his siblings declare "Even Mikey likes it !")
So I picked a class at random. Nice short methods, but reading the code didn't give me as much insight as I hoped. Then I thought... ah the tests. I'll read the tests. So I right clicked, searched for usages, and navigated to the location that had "unittests" in the name. Then I thought - wouldn't it be nice if I could right click on a method name, or a class name, and - instead of asking for usages - I could ask for tests.
That got me to thinking - what would constitute a test? A unit test that simply invokes a method or instantiates a class may just be using it for setup or for supporting scaffolding. But then wouldn't that be a smell? Shouldn't that irrelevant setup junk be in a setup, or injected or...
Anyway, Kris gets to much of these points... my main extending thought is simply - wouldn't it be nice if the tools could help us navigate to tests and sniff out those smells (rather than force them by removing the method, as Kris's technique suggests)?
Monday, December 08, 2008
Halftime
In American football, the game is divided into four 15-minute quarters. There's a short break between the first/second quarters and then between the third/fourth quarters, but the middle transition is longer. It's called halftime.
During halftime, teams return to their locker rooms for respite, but more importantly, coaches use it as an opportunity to adjust the game plan and motivate the team.
Much is made of the halftime break in football. I think the concept is equally useful in ... agile software development.
I introduced halftime on a couple of agile software development teams to step back and look at iteration (or sprint) goals at the midpoint of the iteration, to see where we stand, and adjust our approach. It has been a good opportunity to refocus, adjust sprint content, and address issues.
In a recent halftime, I pointed out that the scope for the iteration was 63, and that we had burned up 20 points. I used the analogy that our opponents had 63 points and we had 20 and that we need to figure out how to make up the difference. We adjusted our approach, removed some scope and went on.
If you're stuck in a project where the iterations are too long (e.g. four weeks), suggest introducing a short halftime (30 minutes) to refocus the team and adjust. Even if you're in 2-week sprints, doing a checkpoint/halftime at mid-iteration can be useful. It's also a good segue into shorter iterations.
During halftime, teams return to their locker rooms for respite, but more importantly, coaches use it as an opportunity to adjust the game plan and motivate the team.
Much is made of the halftime break in football. I think the concept is equally useful in ... agile software development.
I introduced halftime on a couple of agile software development teams to step back and look at iteration (or sprint) goals at the midpoint of the iteration, to see where we stand, and adjust our approach. It has been a good opportunity to refocus, adjust sprint content, and address issues.
In a recent halftime, I pointed out that the scope for the iteration was 63, and that we had burned up 20 points. I used the analogy that our opponents had 63 points and we had 20 and that we need to figure out how to make up the difference. We adjusted our approach, removed some scope and went on.
If you're stuck in a project where the iterations are too long (e.g. four weeks), suggest introducing a short halftime (30 minutes) to refocus the team and adjust. Even if you're in 2-week sprints, doing a checkpoint/halftime at mid-iteration can be useful. It's also a good segue into shorter iterations.
Subscribe to:
Posts (Atom)
