Imagine for a moment that you step into a therapists office, complaining of stress. You ask what to do and the therapist asks you for your ideas. You suggest running, watching a ball game, taking a nap, having a few beverage with friends, talking a walk, or watching TV. The therapist replies “It sounds like you have some good ideas.”
Today I’m going to talk about a totally different way to manage stress. Continued »
A few years ago I was on an overworked team. Big surprise there, right? We were working on a long list of work for an upcoming release. We through everything was documented in our bug tracker, but you know software, the more you dig into the work the more new scope you discover. We would work on a change, and discover that there were hidden requirements, or that the code base was a rats nest that had to be addressed before we could actually get work done.
Our development team usually took care of this by either documenting the new scope in a card and getting it queued up for future sprints, or they would get the changes done at night or on the weekend without it ever hitting our bug tracking system.
Sometimes this was good, sometimes it wasn’t.
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.