Agile. Leadership. Coach.
Have you ever heard a developer say, “Agile has too many meetings!”
In my years as an agile developer, development manager and agile coach, this is the top complaint I hear from developers when their team “goes agile.” This complaint demonstrates a lack of engagement or lack of support for the team’s agile transformation. What techniques do we normally use to address this and why don’t they work?
Continue reading “What do you do when a developer says “Agile has too many meetings””
I had the opportunity to attend and present at TriAgile 2016. It was my third time attending and my second time presenting.
Details of my presentation are here.
As always it was great to be among so many thought-provoking speakers and engaged attendees. I think there were around 650 attendees, which was a new record for the conference.
One of the things I love about this conference (and Southern Fried Agile) is the affordability. Advance tickets are around $100 which makes it easy to self-fund your way to the conference. Or if your company is paying, they can send a lot of people for very little money. These conferences provide an exceptional cost-to-value ratio.
Here are my highlights…
As told in the excellent book A Whack On The Side Of The Head by Roger von Oech, a few centuries back there was a plague in a small village that caused people to go into a death-like coma. Most of them eventually died, but occasionally someone would be mistaken for dead and accidentally buried alive.
When the villagers discovered this, they started working on a solution…
I thought the story was over. The shelves were built and I walked off slowly into the sunset.
However, sometimes you can’t predict the future. There was an unfortunate incident that caused both garage doors to need to be replaced.
One of the garage doors came in contact with a minivan. We may never know who moved first, but suffice it to say, mistakes were made and the garage door paid the ultimate price.
I recently had the opportunity to give a lightning talk at a local agile meetup. If you’ve not been to a lightning talk (which I keep wanting to type as ‘lightening’…probably because it resembles ‘enlightening’) these are presentations you give that last 5 minutes or less.
You can use slides or not, but you will have to fit what you have to say in 300 seconds. It is a great opportunity to try out an idea on a friendly crowd. And I find that the time constraint forces you to examine, distill and re-examine your ideas in a healthy way.
For visuals, I had a single slide with 3 images on it. The rough transcript of the talk is below.
Now that I’m at the end of this set of articles, a retrospective is in order.
I’m very pleased with the final shelves. They’ve been doing everything I need a shelf to do for months now, with no maintenance required. You have to love a feature that doesn’t require any support after go-live.
When I started writing these articles, I was curious what would come of it. I made a few key mistakes that prompted me to explore the project from an agile context, but I wasn’t sure what I would uncover.
Along the way I realized that “agile” is at risk of becoming a meaningless term. People are throwing “agile” in front of everything (including articles on home improvement projects).
The nice thing about agile is that it is a set of principles; a philosophy. And like any philosophy it has its strict adherents and its loose followers. It has those espousing the “right” way to practice agile and those that are bit more loose in their interpretation.
This can lead to ambiguity or confusion, but it also provides an opportunity for each of us to identify what we mean when we use the word “agile”.
This set of articles forced me to articulate what agile means to me.
If I reduce it to its basest essence, being agile to me is about assuming that you are wrong.
Each shelf has 4 hanging supports. Each support is made of 2 – 12 inch pieces of slotted angle iron. So with 2 shelves left, I needed to attach 16 pieces together to make 8 pieces.
For the first set of shelves, I did this in-place by attaching the first piece to the ceiling mount and then the second piece to the first piece. It worked fine, but was a little slow going since you are working on a ladder with your arms above your head.
I decided that since I’d proved my design worked on the first set of shelves, I could optimize this process.
Hanging SupportsI measured the length of a hanging support from one of the first shelves and then pre-assembled the 8 remaining hanging supports I would need. To save time, I didn’t leave the bolts loose, I went ahead and fully tightened them with a wrench, saving another step I wouldn’t have to do later on the ladder.
Impressed with my own cleverness, I started to build the last set of shelves. I hung one shelf and then tested by opening the garage door.
With the first door done (two shelves), it was time to work on the second one. I had a mini-retrospective at this point. I asked myself what I’d learned and what I wanted to do differently. A few things came to mind. First was: More Power
First, a little more planning…
As far as the length of the brackets, I wasn’t sure if my ceiling joists would line up with where I needed my shelves to be. Rather than take the time to figure it out, and potentially end up with smaller shelves due to where the joists were relative to the garage doors, I decided to be less efficient in my use of materials.
I decided to use larger brackets and hang them across several joists. This would allow me to position the shelf wherever I needed, rather than locking me into the location of the ceiling joists. In programming terms, I created loose coupling between the ceiling joists and the location of the shelf.
This would be more expensive. I would have to buy longer pieces of angle iron to bridge the gap between the joists, but it gave me two key advantages. First, I didn’t have to determine up front exactly where the shelves would hang. It reduced up front planning and allowed me to defer key decisions. Second, I didn’t have to reassess the size of the shelves relative to where I could hang the ceiling brackets.
I had to remind myself that my goal was a set of 2 foot by 4 foot shelves over each garage door. That was the only goal that mattered. Optimizing to use less materials (optimizing to reduce cost) was going to take me away from my goal. I also realized a secondary goal: To finish the project quickly. Because I was doing this on my own time and I highly value my time, I was willing to make some concessions on cost.
In terms of the iron triangle, I fixed my scope, wanted to control my schedule and was willing to give a bit on cost. Which, now that I think about it is not the way most software projects run…
Ok, so I was inspired, but wasn’t ready to build anything just yet. I started where most research starts these days–the internet. Specifically Google and Amazon. I was looking for a Commercial Off-The-Shelf (COTS) solution to my problem. Basically, something I could buy and it would just work. This is almost always a great place to start, but a difficult one for some software teams to embrace.