One of the roles I play in the little software communities I belong to is a bit of an ambassador. I am approachable, easy-going, and tend to flit about between communities. If people feel like they don’t “belong” at a “Agile” event, a “Test” event, or a “DevOps” event, they might know me, and feel a little bit more comfortable. One of the ways I do that is through Lean Coffee.
At its heart, lean coffee is a way to put just enough structure around a meeting with no formal agenda. In about an hour, a group of strangers can meet, align on what to talk about, help solve each other’s problems, and leave as … something more than just strangers. As a conference speaker, it has been my pleasure to run Lean Coffee at over a dozen places over a few years.
The format is deceptively simple. Here’s how to run Lean Coffee in one image, created by Gerry Kirk, who I met at Agile&Beyond in 2015 and used with permission:
Five or so years ago I was working at an early stage startup in the anesthesiology space. We were making a product for anesthesiologists to document cases in real time that would help them navigate away from traditional pen and paper solutions. The development team I worked with was building and delivering software one week at a time. The business was inventing and designing software 6 months to one year at a time. Once a quarter or so, the company would get together and listen to a meeting about our product road map. This told us about the customers that were important, and what software changes they would need over the next 6 months.
Seems nice to have that much certainty, right?
Yet many of the individual teams I work with don’t see benefit from SAFe. The pertinent questions seem to be: What problems does SAFe Solve – and do you have those problems? Continued »
No, not hard, actually impossible.
I tried to explain this to one of my fellow project managers, who I will call Valerie. She said “Yes, I understand, it’s challenging. I’ve been on hard projects before.”
No, not hard. Actually mission impossible.
She didn’t believe me. She said there is no such thing as an impossible project. You can always succeed. I asked when her project was due, she said in thee months.
If what Valerie said is true, then senior management should move her deadline the very next morning at 9AM.
Sometimes, it is a mission impossible project.
Here’s what to do about it.
I wouldn’t say that I’m a disagreeable person, I’ve just been in a field that requires analysis and asking questions for so long that asking those hard questions is second nature. I was just plain bad at this early in my career. Years ago, I was in a transitional meeting. We had been developing features for months and were flipping over to a “hardening” phase where we (the development team) were supposed to mainly focus on discovering and fixing problems. We were still wrapping up feature work at that point, and it would have been another week or so before that was done.
I (with out tact) asked why we were calling this hardening since we obviously weren’t there yet. In exchange, I got an hour lecture right on the spot and a meeting with my manager.
In his 1951 Paper “The Imitation Game“, Alan Turing proposed a simple test of artificial intelligence. Put a real person in a room connected to a teletype machine, sending messages back and forth to some other entity. If the entity could be a human, or it could be a computer, and the person cannot tell the difference, then we can say that we have achieved real Artificial Intelligence.
This sort of thing is happening in small ways right now — and is just about to hit mainstream. Continued »
In January, I wrote a little bit about how to do a better job slicing up stories. In my experience, there is always a healthy amount of debate around what size a story should be. Should we make this a 3 or a 5, a 5 or an 8? Inevitably we have to revisit the question of what a point even means. Are we talking about hours of work or difficult or ideal work days (whatever that means)? I don’t think these conversations are terrible useful unless we are intentionally driving to make a piece of work smaller.
So, that begs the question of why do I care whether or not a piece of work is smaller?
I have worked under a few different employee structures in my tech lifetime — all employees on site and in the office all of the time, all employees in the office except for that outsourced team (which quickly grows into several), everyone remote and working from the office or wherever they feel like being that day, and everyone in the office with exception of one or two people. I’m working in that last scenario today. The team is mostly on site, and there are two developers including me that work remote.
Working from home has always been my thing, it’s a comfort zone. I have personal space, and can be hyper productive. Being one of the few people on a team that is remote is an interesting dynamic, though.
Most of the job descriptions I read are either in the form of a job advertisement, or a job description on an internal wiki. Neither are particularly helpful. In the past, I have either avoided applying because the ad listed every skill on earth when what they really needed was a junior. Or, I ran forward and applied to advertisements that were completely understated and well out of my skill range. Bad internal job descriptions can be used like a sword when it comes time for skill assessment and review.
Getting these right always feels like an impossible chore with not a lot of upside. I like to focus on two areas with these, skill and culture.
I got that email a few years ago at an awkward time; I was in Germany at the Agile Testing Days Conference.
So I wrote the email you might expect. For a duration of less than a week, we are talking about consulting, at this rate. At two weeks to six weeks, here’s a second rate. For six to twelve weeks, here’s a third rate. At over twelve weeks …
And so on. There was a lot of “if” and “or.”
Looking around the room, I saw Ilari Henrik Aegerter, known as a sharp negotiator in business. I asked Illari what he thought of my proposal.
His evaluation boiled down to “too many words.” That is, all I needed was one sentence, a single hourly price. If I had an ideal contract length, I could throw that into the email. So the reply could be as easy as “Assuming about six months, we’re looking at $X/hour.”
Done, one line. Yes, we got the deal.
These sort of brief replies will massively improve the chance of success when trying to get to a decision.
Today I’ll tell you why. Continued »