October 20, 2018

Lessons learned as a Juror, For the Young Woman

As I mentioned in my prior post, I served on a jury earlier this month and it was a real eye-opener. The prosecuting attorney talked about the consequences of getting drunk, the symptoms of the hangover. The consequences are rightly a headache, nausea, vomiting, fatigue, dizziness, shakiness, and the like. The consequences are not rape. They are not sexual assault. Alas, crime should not exist, but it does. Don't get me wrong: putting yourself at risk does not excuse the person who would commit a crime. We should all be able to get drunk and go wherever we wish. Perpetrators should all be caught and convicted. Nevertheless, it is prudent to take precautions.
  • Being drunk makes you an easier target for crime.
  • Having another person there with you will not guarantee your safety. There is safety in numbers, but a person can easily be separated from one or even two others. And with more than two others, attention is divided such that one person can be put in danger.
    • Further, your friend may be unable to convince the police that you were kidnapped.
    • If your friend can convince the police that you were kidnapped, an additional crime against you will be over before the police can use things like pinging your phone to find your location.
  • Drunk people are terrible at providing protection, and even worse at coming to your defense.
  • The perpetrator's defense attorney will try to discredit or defeat DNA evidence, and they can be successful.
  • When there is DNA from 3 or more persons (the victim + 2 or more, or when there is sperm from 2 individuals), DNA testing cannot separate the DNA from the various individuals in order to make a match to any individual.
    • And even if they could, you'll find that a conviction is unsatisfactory.
  • Cell phone location records are kept for only 18 months. It may be impossible to use such records for proof since…
  • It can take months for DNA evidence to be tested. Your perpetrator's DNA profile may not yet be in the crime database. It can take months for DNA from another victim to be tested. It can take time to find the defendant, to get his DNA, and months for his DNA to be tested. By then, certain other evidence is no longer available.
  • Although there are cameras everywhere, they are never where the victim needs them to be, or they aren't turned on, or they aren't recording, or the technology isn't working, or the video or audio isn't clear, or it's been so long since the event that the recording has been lost.
    • Even the police's car cam audio may be ineffective because the car isn't pointed in an ideal direction, or because of glare from other lights, or because of the radio being on. Police officers rightly use music to keep them alert during the night shift. They might not turn it off before they get out of their car.
  • Although there are eye witnesses everywhere, eye witnesses are terribly unreliable, and the police will testify to that in court. Eye witnesses don't pay attention until it's too late. Once the witness realizes something is going wrong they will have missed the opportunity to make a rational observation and to commit important details to memory. That can work to your disadvantage, rarely to your advantage.
    • Example: "We took a ride with someone. We were in the car with him for half an hour. Maybe more. But I generally trusted and ignored him. Then, suddenly, after I was out of the vehicle, I realized something was going wrong. After the driver was gone, with my friend still in the car, I realized that I never really looked at him. I can't describe him at all. DAMN IT! And I couldn't get the license plate."
  • The GBI specifically, and the state and district DAs have a large backlog of work and limited time and funds. They will not do everything possible for your case. They will do what they think is just sufficient, and efficient.

I don't believe young women understand how easily they can be abducted; nor do they realize how hard it is to catch the perpetrator; nor how little satisfaction would come from a conviction. The victim will live with and relive the pain the rest of her life.

The same goes for parents. I live in a safe, upscale neighborhood, more safe than most, but perhaps not the safest since it's not a gated and guarded community. Nevertheless, I feel safe. My family feels safe. Yet, in the case in question, there was a point in time in which this newly convicted felon lived within two miles of my house. One of his crimes was committed within three miles of my house.

I don't suggest living in fear. I do suggest living one's life with aplomb and gusto, to the fullest. But also with prudence.

Lessons Learned as a Juror, For the Young Man

I served on a jury earlier this month. It was an eye-opener to me. So many decisions are made as one grows up, the odds of making a wrong turn are great. Each bad turn can lead to another; or to repentance and a better direction. "There, but for the grace of God go I." Given this experience, I thought I'd write down some of my thoughts, first for the young man. Later for the young woman.
  • Having sex with someone who is inebriated is rape (assuming no prior valid informed consent for the sake of this article). An inebriated person cannot give informed consent. If a female's judgment is impaired in any way, she cannot give informed consent. If you think she gave consent, you better think again.
    • The penalty for rape can be life imprisonment.
  • If a male has sex with someone who is inebriated or who can claim to be so, she can claim she didn't give consent to the sex.
    • In fact, that person can claim rape even if she wasn't inebriated. Unless there is testimony or video that the jury believes, you can be (justly or unjustly) convicted of rape.
  • You don't realize how much DNA and other evidence you leave behind.
    • A condom will not conceal all evidence, particularly not even all DNA evidence.
  • If you run from the cops, you will get caught. Perhaps later.
    • Running from the cops makes you look guilty of more than you may be guilty of.
  • Being inebriated can cause you to make mistakes and get caught doing stuff that you would not get caught doing if sober.
  • You are more likely to get noticed by cops and pulled over after dark.
  • Certain evidence for your defense such as cell phone records are only kept by the phone companies for 18 months.
    • You may need those records for your defense for longer than that.
    • Evidence for your conviction, however, is kept around for what would seem like a sufficiently long time.
    • This will not work out in your favor.
  • There are cameras everywhere. There are eye witnesses everywhere.
    • Witnesses are unreliable, but that will not work to your advantage.
  • The jury will not believe your explanation. It will sound fantastical to them. Imagine the people in the jury. Do you think any of them have ever been in your situation? Not likely.
  • Public Defenders (state provided attorneys) can be surprisingly bad at their job. While they can also be surprisingly good, and they can be better than private attorneys due to the number of cases they handle (lots of experience) and their knowledge of the juries, of the local law enforcement, of the prosecutors, and of the judges, the big problem is their backlog of work. Their heavy caseload limits the time they can spend on your case.
  • The GBI (or your state bureau of investigation), prosecuting attorneys, law enforcement and DAs have limited funds and will therefore not do every test and collect everything possible. Nevertheless, they will try to win their case.
    • “About 90 percent of the cases end with a plea bargain, and of those cases going to trial, about 90 percent end in a guilty verdict,” (Something I found on the internet -- sorry, I'm quoting this without attribution.)
    • "In the United States, the federal court system, the conviction rose from approximately 75 percent to approximately 85% between 1972 and 1992. For 2012, the US Department of Justice reported a 93% conviction rate. The conviction rate is also high in U.S. state courts. Coughlan writes, "In recent years, the conviction rate has averaged approximately 84% in Texas, 82% in California, 72% in New York, 67% in North Carolina, and 59% in Florida." Wikipedia

If you are a defendant in a criminal case, don't think you'll fare well with a jury. Don't make up a story. Plead guilty, repent, beg for forgiveness, and throw yourself on the mercy of the court.

I don't believe young men realize what constitutes rape; nor do they realize how severe the penalty is. Likewise for any list of crimes. Perhaps that should be taught in school: crime and punishment.

For a biblical perspective on this, consider how this comes about and grows: "But each person is tempted when he is lured and enticed by his own desire. Then desire when it has conceived gives birth to sin, and sin when it is fully grown brings forth death." (James 1:14-15, ESV)

Yet, even if one were to make some big mistakes, he can still have forgiveness from God, salvation and eternal life.

  • For all have sinned and fall short of the glory of God. (Romans 3:23)
  • For the wages of sin is death, but the free gift of God is eternal life in Christ Jesus our Lord. (Romans 6:23)
  • But God demonstrates His own love toward us, in that while we were still sinners, Christ died for us. (Romans 5:8 NKJV)
  • If you confess with your mouth that Jesus is Lord and believe in your heart that God raised him from the dead, you will be saved. For with the heart one believes and is justified, and with the mouth one confesses and is saved. (Romans 10:9-10)
  • For “whoever calls on the name of the LORD shall be saved.” (Romans 10:13 NKJV)
  • So then faith [comes] by hearing, and hearing by the word of God. (Romans 10:17 NKJV)
Yes, it's that simple. You can feel hope once again. You can feel love once again.

October 16, 2015

A Personal Kanban & a OneNote Folder for Every Client, Project, Aspect of Life

For the last couple years I have almost always had 5 to 10 active Personal Kanbans in Trello along with a folder in OneNote and another in Outlook or gmail (one for each PK). I have one of these trios for each client. I also have a trio for personal/home projects and another for church projects. I can access all 3 of these on my Mac, my windows laptop, and my Android phone. Sweet!

I'll generally work on one client or one project per day, or for a week, or even a month at a time. Whenever I finish for the day I endeavor to ensure my PK and notes pages are all up to date and in a state that will help me pick it back up tomorrow or some other day. Whenever I switch contexts, it's a simple matter to switch which Trello board and which OneNote folder I'm viewing.

I really like the way these work together. It's helping me become paperless which is a bonus given my travel and the number of notes I need to search for (and the sloppiness of my handwriting). This approach has segregated notes and tasks and emails into specific views so that I don't get distracted by what I don't need to focus on at the moment.

Seeing people take notes on a laptop, or open laptops in general, can be off-putting to many people. This is especially true when working with many different people or with a newish client, where we're still gaining trust and feeling each other out and haven't had many (or any) interactions yet. So I tend to take notes on paper whenever I'm having a conversation in person. Then I'll transcribe what is important of those notes into my PK or OneNote. Rewriting them (I'm told) helps to digest, consolidate, and remember what is important, a skill I never got the hang of in school. Many of my colleagues use those fancy pens to record handwriting and automatically convert it to text. I can see the benefit of that, but I'm a late adopter of new technology, due in part to being overly frugal. (I used a paper PK for a long while, until I found Trello.) I think I'll stick with manually reviewing and transposing the notes for a while.

All of this has gotten my life very organized. David Allen's Getting Things Done has helped too, but I've covered that in a prior post.

This may be the fastest blog post I've ever cranked out, one of the few I've cranked out in one sitting. I didn't know where the post was going to go until I wrote it. I just thought I'd share something about this system since it's been so powerful for me. I figured there was a blog post to be written about this, but I didn't/don't know what my readers would want to know. 

What have I not covered that you'd want to know?

September 11, 2015

What do you estimate and when do you do it?

Pick up most any book on agile or Scrum and see what it says about planning a product backlog or planning a release or about computing an end date for a project. It will say to identify the stories, estimate them in points, add up all the points, and compare the backlog point total with your velocity to figure out how many sprints it will take to implement all those stories. Then reserve some room for unknowns and for changes (agility).

So, that implies identifying and estimating stories far enough in advance to match whatever your planning and commitment horizon is. This implies that estimating story points in sprint planning or just before sprint planning or even one sprint in advance is likely not far enough in advance unless you are ultra-agile and aren't making commitments or setting date expectations more than a couple weeks out.

Most companies I work with have a planning horizon that is 3 to 6 months out. So, we put together a 4 or 6 month plan. That plan is going to be based on what we can know in advance, namely, user stories. (Sometimes we do this at the feature level, but that's another blog post.) We won't know research stories or spikes or defects or production support in advance. Whatever goes into the plan is what should go into the velocity metric. Stated differently, you shouldn't put anything into your velocity metric that you can't plan for 4 to 6 months in advance. Which means you shouldn't bother putting points on defect or on research stories. If you are going to compare apples to apples, your velocity must exclude unplannable stuff.

That's why I put points only on real user stories. Here is a series of blog posts I did on each of these topics:

Now, some people try to estimate this unplannable stuff. They try to quantify it in points and include it in placeholders in their plan. You absolutely should track this unplannable stuff, and you should reason about whether it will be more or less in the future, but trying to back it into points or plan it using points is folly. 

February 26, 2015

Don't Spike Defects

I've recently seen a small number of teams create Spikes for defects. That seems strange to me. If you have a good reason for doing this, please let me know.

It should be rare that we’d have a spike to research a defect. Defects almost always have some amount of unknown research and debugging to them. It would seem strange to me to have a SPIKE to debug a problem which would then be fixed under a Defect.

The exception case may be if we want a triage/debugging step where we figure out what’s wrong and estimate the effort to fix before agreeing to fix it. But typically with defects, once you know how to fix it, actually fixing may be faster than all the debugging. By the time you’ve got it debugged, you know exactly how to fix it. I rarely find that approval step necessary these days.

I haven't heard of spiking defects discussed in the agile community so I assume it's generally accepted that this is not a recommended or common practice.

February 12, 2015

How Many Stories per Sprint? Rules of Thumb

I'm often asked how many stories you should have in a sprint. People are looking for guidance.

I've heard some coaches recommend “3-6 stories per iteration per developer”. That's a bad rule of thumb. For a team of 7 developers you would have over 20-40 stories which is likely way too many. That kind rule of thumb also subtly takes the focus off of swarming and puts attention toward a developer per story, a story per developer.

My rules of thumb:

5 to 15 stories per sprint are about the right number, particularly for the clients I often work with in which there are maintenance teams knocking down a backlog of small defects and teams doing Web work with lots of small changes to do. 4 stories in a sprint may be okay on the low end from time to time, and 20 is an upper limit for me.

Most stories shouldn't take more than half the sprint to develop and test. Having 1 story each sprint that takes more than half the sprint is about all I would advise, and in that case all the other stories should be very small. For a 2 week sprint, it's better if every story can be completed in 1 to 3 days. (Adjust that for longer sprints.)

I need to elaborate on my comment that it's better if every story can be completed in 1 to 3 days. After stating that I'm often asked whether that's the developers working independently or all together. The answer is "whatever you are doing today." It is best if the team can swarm stories such that multiple developers can work on a story at the same time. If  2 or 3 devs can work on a story at the same time, then you can have larger stories finished within that 1 to 3 day rule of thumb. But if the team isn't there yet, if that's not the way they work today, then having stories that are too big given the way they are working is counter productive.

What's the maximum number of points for a story? How big is too big? How many points is too big for a story varies according to the team's pointing scale. I've known teams that start with 5 (5, 10, 20, 30, 50, 80). For them, 50 and 80 were too big. I've also known teams where a 1 point story would take less than half a day. For them, a 13 might not be too big. If a 1 takes more than a day, then 13 is probably too big. Generally, too big is an order of magnitude larger than the typical small story.

Here's an example: Assume my 1 point story takes a day or two and once in a while we have something that is truly tiny and we call those half a point. The 1 pointer is my typical low end of the range. I have something smaller, but it's not typical. A 13 is an order of magnitude larger that 1 point story. It's very difficult to keep the scale linear when there is that much diversity in your story sizes.

February 10, 2015

Story Splitting: Where do I start?

I don't always follow the same story splitting approach when I need to split a story. It has become intuitive for me so I might not be able to write about everything I do or what goes through my mind or how I know. But I can put here what comes to mind at the moment:

Look at your acceptance criteria. There is often some aspect of business value in each acceptance criteria that can be split out into a separate story that is valuable to the ProductOwner.

Consider the tasks that need to be done. Can any of them be deferred (to a later sprint)? If so, then consider whether any of them are separately valuable to the ProductOwner. If so, perhaps that would be a good story to split out.

If there are lots of unknowns, if it's a 13 because of unanswered questions, make a list of the questions and uncertainties. For each, ask whether it's a Business Analyst (BA) to-do or a Tech to-do. Also ask for each whether it's easy and should be considered "grooming". If it's significant enough and technical, maybe you should split that out as a ResearchSpike. Then make an assumption about the likely outcome of the spike, or the desired outcome of the spike, note the assumption in the original story, and reestimate the original story given the assumption.

Look in the story description for conjunctions since and's and or's are a clue that the story may be doing too much. Consider whether you can split the story along the lines of the conjunctions.

Other ideas:
  • Workflow steps: Identify specific steps that a user takes to accomplish the specific workflow, and then implement the work flow in incremental stages
  • Business Rule Variations
  • Happy path versus error paths
  • Simple approach versus more and more complex approaches
  • Variations in data entry methods or sources
  • Support simple data 1st, then more complex data later
  • Variations in output formatting, simple first, then complex
  • Defer some system quality (an "ility"). Estimate or interpolate first, do real-time later. Support a speedier response later.
  • Split out parts of CRUD. Do you really really really need to be able to Delete if you can Update or Deactivate? Do you really really really need to Update if you can Create and Delete? Sure, you may need those functions, but you don't have to have them all in the same sprint or in the same story.
Some of the phrases in the above list may have been inadvertently recited from Dean Leffingwell's book "Agile Software Requirements".

January 20, 2015

Airplane Etiquette: 12 Rants

How about a little airplane etiquette?

Surely my readers don't commit any of these blunders, so my suggestion is to print a copy of this to bring on board. This works especially well because those who have a lower airline status tend to be more unaware. Slip this in a seat-back pocket in the row in front of you before the others board. This paragraph won't (shouldn't) print with the rest of the page.

Here's my rant for the year.

# 1 - Avoid cologne and perfume. Many people, like me, are actually allergic to cologne and perfume. Our sinuses get stuffy, we get a headache, and our eyes start to itch. Very uncomfortable for a flight of any duration. Use Beano®. Use deodorant. But don't try to mask it with cologne.

# 2 - Before reclining your seat, look back first to see if you're going to squash a laptop or bump a head. Give a polite warning. Then recline your seat back SLOWLY.

# 3 - Don't flop down in the seat. Doing so can crush whatever is going on behind you.

# 4 - Don't punch the seat-back display. The person in front of you can feel the lightest taps through the headrest.

# 5 - Similarly, the person in the seat in front of you can feel everything you shove into the seat-back pocket, especially if you let the elastic on the net snap back. (I'm a big offender for this one. I'm working on being more considerate.)

# 6 -The middle seat armrests belong to the guy in the middle seat. The window seat has an armrest by the window… AND the window. The isle seat has an armrest at the isle… AND the isle. The only thing the dreaded middle seat has is… nothing. Give the poor sap in the middle a couple of arm rests.

# 7 - Ugh, a plane full of roller-bags. I wish the airlines would charge for carrying on more than 1 item and for any item that's the size of a roller-bag. Checking bags should be free. Come-on people. Let's travel light out there.

# 8 - The window seat has the prerogative to raise or lower the window shade as desired. Still, it is polite, but not required, to consider the others. Lowering it a little is kind if others are watching a movie, using their laptop or sleeping. Raising it for someone reading a book is a kind gesture. If you aren't by the window, ask very kindly if you'd like the shade adjusted.

# 9 - Turn off the ringer and alert tones on your phone. Completely. There are enough dings and beeps on the plane. We don't need phones beeping and dinging for every email that arrives and meeting that we are missing. Keep your reminders to yourself.

# 10 - Unbelievably, I see people play movies, games and music on planes without headphones. Some yack on the phone loudly while boarding, sometimes even on speakerphone. Use headphones. Speak softly.

# 11 - Pay attention. If you intend to wrap up in a blanket or a big coat and sleep, ensure that you haven't thrown the end of your cover over onto another person.

# 12 - Sometimes flight attendants will suggest we stay seated after we reach the gate to let those with tight connections off first. Certainly, if we're arriving late, I support that. If we're arriving on time, I'm not so sure. I don't have a lot of sympathy for anyone booking a flight that doesn't give them sufficient time to make their connection. I should probably rethink that. There could be people who got a tight connection because of some other canceled or delayed flight, or some fault not of their own. Yeah, it's good to be considerate.


Bring an orange. Eat it on the plane. The smell of citrus is most often welcome on a flight.

November 21, 2014

Repair a Leaky Cuisinart

My Cuisinart Grind and Brew developed a leak. There was a small hole in the plumbing. It would leak all over the counter. That made it more of a Cussinart in my household. Here's how I fixed it with a little metal epoxy that I got from the local hardware store.

Most of the posts I see online about leaky Cuisinarts blame a clogged thermos lid, using too much coffee, using too finely ground coffee, or a clogged filter. If yours is leaking clear water like mine did, the problem isn't any of those. Before I opened it up I suspected a leaky hose or a cracked reservoir (though there really shouldn't be any reason for the reservoir to crack).

There are 4 hex or torx-bit screws holding the bottom panel on. My tools weren't skinny or long enough to fit in the narrow hole, so I just drilled the holes out. I probably used a 7/16" bit.

When I opened it up I saw a rusty (and cheap) clamp on those big orange hoses. I thought that might be the problem. But I also saw some discoloration in a spot on the aluminum pipe. Now that I had the bottom off I filled it up with water to find the source of the leak. I saw that it was leaking from the aluminum. So, I sanded the area of the leak and cleaned it off. That made the hole more visible. I patched it with some epoxy made for metals that I got from the local hardware store. The smallest size cost $6 and is much much more than I'll ever need, but that's cheaper than a new Cussi..., er, Cuisinart.

Since I drilled out the bottom I can't just reattach it with the original screws. I'll use a little glue (not too much) to hold the bottom on. Superglue might work. JB Weld would work well. Some other assorted craft glues that I have lying around should work.

If yours has a leaky hose, that should likewise be an easy fix. You can get a new hose from your hardware store. Zip-ties and new clamps are easy to come by.

Good luck! Let me know if you find this useful.

April 8, 2014

My Recent Posts on LeadingAgile

I started working with LeadingAgile in 11/2012 on some complex enterprise agile transformations and other lean management consulting. Related to that, I've done most of my recent blogging over there on LeadingAgile's blog. Here are some of those posts:

I Don’t Estimate Software Defects, but it's not as simple as just that. If you follow my advice, you'll also have a zero-defect mentality and you'll fix defects as soon as you find them. In general, I want a conservative measure of velocity, so I don't record in my velocity anything that was unplanned. Therefore, I likewise Don't Estimate Spikes.

I'm fond of The Theory of Constraints and Brooks’ Law. In that post I evaluated Brooks' Law in light of the Theory of Constraints in a way that I hope helps the reader understand both concepts.

Lack of Predictability is Your Biggest Problem. The senior leadership in most organizations I work with seem to agree. They aren't very interested in agile's agility. They want their design-build-test teams and their program teams to be able to make and meet commitments so they can make appropriate capacity constrained commitments across the portfolio and to external stakeholders.

Agile Health Metrics for Predictability was perhaps my most popular post on LeadingAgile's blog.

In Bottom-Up Implementation & Top-Down Intent, I discuss my recommended approach to agile transformations.

Related to that, I wrote a post arguing that you should fix your Structure 1st: Why You Should Not Start With Practices

Part of your structure involves your design-build-test teams, also known as your Scrum teams. In Use Feature Teams. Yes, Use Component Teams I explaining these approaches and why I recommend using both.

What do Scrum teams do during the Release Sprint? Good question. This post has the answer. In short, many things, but not developing code that can't be tested immediately.

Oh, I also published an article in Agile Journal entitled Identifying and Improving Bad User Stories along with my friend and co-author Chuck Suscheck. We put another article up on sticky-minds: The Problems with Overachievers on Agile Teams.