Why we do agile – implications for people in an agile organization

As my company has grown over the last few years, I’ve had to hire (and let/seen go) a fair number of people. We’ve interviewed dozens of candidates. One of the most challenging things we find is in hiring people with the right culture fit. Agile is one of those cultures that unfortunately comes with many hidden implications I’d like to discuss in this post.

Why do we do agile?

Most software development professionals, whether it’s developers or managers (PO’s) these days use what they think is “agile methodology”. They know about working in sprints, Scrum, backlogs, stories, sprint goals, retros, etc. In a practical sense, they use agile but when asked, they don’t actually understand why.

In interviews I’ve asked people, “Why do we use agile?”

I’ve yet to get a satisfactory response. Some say “Because it’s not waterfall, waterfall is bad.” Or, “Agile is just better.” (Ok, but why do we use it?)

The reason for using agile is that creating software is so complex that there are more unknowns than there are knowns. Agile shortens the product development cycle into small increments that can be used so that real requirements emerge. The project evolves over time.

What is agile then?

At the core of agile is embracing that everything is ambiguous (and that your hypotheses and assumptions potentially aren’t correct). In product development, there are more unknowns than there are known.

Embrace life as iterative, incremental and emergent. My interpretation from Principles by Ray Dalio. I find this a great illustration for what it means to have an agile mindset.

The main idea of agile is in working iteratively, incrementally and continuously. Each feedback loop enables you to check if you are delivering value.

While the term “agile” is most popular in software development, it is becoming more commonplace among organizations (see this and this). ArtStation is considered an agile organization with our own structure called Organiq (will write about it in another post).

Interestingly while reading Ray Dalio’s Principles, he illustrates the looping ascent in one’s career/life. One sets audacious goals, fails, learns from them, improves, then sets higher goals. I found that illustration apt to describing agile philosophy. Product development, companies, careers can all take this iterative, compounding philosophy.

From Ray Dalio's Principles — From Principles by Ray Dalio

What are the implications of agile for people?

The “experts” are actually those with an open mind who are willing to test assumptions

The main implication of agile is that you accept that there are more unknowns than known, and that your assumptions (perhaps based on your expertise & experience) might not be correct.

For staffing, this presents a landmine. We’ve hired people who get frustrated and leave because they’ve brought assumptions under the broad banner of “expertise & experience” that they are unwilling to yield on. In agile, that expertise & experience is a great starting point but the assumptions must be tested, validated, observed and measured. Some people just can’t take that kind of examination and have a hard time in a truly agile environment.

You might hire someone who has decades of industry experience. This person brings a wealth of knowledge and experience but is unwilling to have those assumptions tested. And when they are and the results are questioned, they get offended and ask “Why did you hire me for my expertise if you’re going to allow other non-experts in the organization to scrutinize it?” It’s a great question, and it’s why agile is challenging to truly accept. From my experience, the real experts are the ones who balance their expertise with the mindset that their assumptions (based on their experience) might not be completely correct under the present circumstances and are willing to test that.

If you have key people in your organization who are not willing to test and challenge their own assumptions, it is a sign that they haven’t embraced agile or maybe they just aren’t of that mindset. Agile is very challenging in this respect. You can have very experienced, senior people who have a title and position, and if they are trying to assert authority with those things, it creates tension in what is otherwise supposed to be a fluid, learning environment.

Titles & positions become tenuous – this is a problem

Therefore, because agile is a learning environment where you’re constantly testing hypotheses & assumptions, it becomes challenging to hide behind titles, positions and broad expressions of expertise and experience. Especially if you assert authority with those things.

The issue is that common assumptions hold that the title or position of a person commands authority. For example, if you’re a designer, common wisdom dictates that you should not be challenged on design unless it’s by another designer, preferably more senior than you. If you’re a marketer, common wisdom dictates that you should not be challenged on marketing unless it’s by another marketer, preferably more senior than you. It’s exacerbated by the mistaken belief that agile is something that only engineers use, and is not something that should be applied to other disciplines. Scrum (at least the V1 of the Guide in 2013 and removed in newer versions) adds insult to injury by stating that “Scrum recognizes no titles” — a big problem for people who have worked hard in their chosen profession and earned their position & title, only to be challenged by others on the team who aren’t from that profession. How dare they!

This is a constant struggle. I find myself educating, and now being smart enough to not hire people who are after the title/position. Instead, I look for people who are open minded, humble and have a learning mindset. Even with experience, expertise and a good title, being able to say “This is what I think, but let’s test it and see what happens” is great. The whole organization benefits from having an agile mindset where everyone can learn.

I want to point out that generally having people who throw their weight around based on their title/position isn’t great anyway. Having someone say “I’m the [insert position/title] and you should do what I say” leads to tension in the team regardless of whether it’s agile or not. The point is that you want people who are humble enough to engage in healthy discourse and have an open mind. In Ray Dalio’s Principles, he puts forward the “idea meritocracy”, which is an environment where the best ideas win. The best ideas are determined by the quantity and quality of empirical data, not by positional power or title. In any case, this is challenging for many.

Scrum: You are delivering small increments to test in the market instead of a blockbuster release (though you can marry the two)

When working in Scrum, each sprint is essentially a timeboxed feedback loop. That’s why it’s important to try to deliver a working increment and get feedback from users and stakeholders.

More often, I see people’s understanding of Scrum to mean that they are phasing delivery in sprints but essentially it is still a big waterfall. E.g. having a UI design sprint, technical design sprint, implementation sprint, testing sprint, deployment sprint. This misses the opportunity for each sprint to be a feedback loop. This is just a phased waterfall.

The main benefit of agile is to be able to deliver small increments to users and stakeholders, get feedback, and keep iterating until you have something that is generally accepted (and delivering value). It is said to be iterative, incremental and evolutionary.

This does have implications for marketing and “when do you actually release?” What we try to do is to have features tested with subsets of users, get feedback and iterate quickly sprint to sprint until we get to a general availability. When everyone has access to the feature, that is the blockbuster release where we do the announcement and fanfare.

The pace is quite fast – too fast for some

When working with agile, the pace of release is intentionally quick. You’re getting increments in front of stakeholders quickly to get feedback and continuing to iterate. This can feel unnatural for people who are used to bundling releases over months and doing a big drop to users.

It is challenging to get the team’s mindset into the rhythm of just getting an increment in front of stakeholders to get feedback quickly. The natural tendency is to polish the feature until it feels “ready”. To our above point about actually releasing though – it’s not necessary to release the feature to everyone on production. The point is to get something in front of users so that they can test it, and get the feedback to continue iterating. For some features that we’ve done, that’s meant bringing users/customers to sprint reviews to get feedback directly, even though the feature is only on a review/dev server.

Is Waterfall Bad?

You know, it’s funny. When I chat with people, the understanding is that “Waterfall is bad”, but when you dig in, they are using waterfall themselves by phasing Scrum. They don’t understand the real reason behind taking an iterative, agile approach to product development.

I personally don’t think that a waterfall or phased approach to a project is inherently bad. Especially if it’s a short timeframe. In some cases waterfall is just the most appropriate way to do something.

In software product development, waterfall is problematic when the release cycle takes so long and has so much effort exerted that it risks missing the mark. The longer you spend without releasing to users, the more risk you layer on. You could spend months working on a release and get it out only to find that it does not completely solve the problem. The whole point of agile is to slice it up into smaller increments, deliver early, and with each delivery discover the real requirements based on actual usage of the product.

Closing thoughts

That’s some thoughts on agile, why (when it’s appropriate) to use agile, and its effects on people in an agile organization. I think that most people want to be agile, but in practice, the mindset change and its implications are too much to handle. I believe that everyone can benefit from an agile mindset, but its implications are challenging to accept. The problem I feel is that many organizations pay lip service to agile. They want to advertise themselves as agile, but when it comes to it, are still running fairly rigid phased processes with traditional power structures based on title & position.

Leo

Building My First River Coffee Table

Over the last 3 years I’ve fallen in love with woodworking. My journey with woodworking began with our new home. It needs a lot of work. I learned quickly that hiring contractors to build many of the cabinets and things that I wanted was not only quite expensive, but that we wouldn’t be able to get exactly what we wanted. Personally, I prefer to build each of the things as a bespoke piece, rather than a mass produced IKEA type of furniture.

For me, the “river table” or more specifically, an epoxy resin live edge table, was at the top end of the woodworking scale. It was something I aspired to create. I started with cabinets and got quite good at building them, but I wanted to challenge myself to build a river table that could end up being a special piece. They are bespoke art pieces and a coffee table like this can cost at least $1000+. A dining table can cost at least $5000+.

Process

Buying and cutting the wood slab

The slab, cut into the river table shape. Notice that there are gaps under the right piece. I learned later the hard way that you should use a completely flattened slab.

Building the form

The form was built from spare pieces of plywood. This part is fairly straightforward. Use Tuck Tape on the surfaces that will require water-tightness. As I learned the hard way (see below), make sure that your form is slightly larger than the pieces of wood. The wood should not touch the walls of the form so that it doesn’t push it out. Seal both the inside and outside edges completely with silicon sealant. Water test it!

Doing the epoxy pour

The epoxy pour itself is the easiest part of this whole process. It’s all in the preparation and what comes after the pour that is a PITA.

In this video, you can see how I did the epoxy pour. It became a neighbourhood event with many curious neighbours coming over to see this being done.

Also see below for all the lessons learned in doing an epoxy pour like this. The main thing is to only do the pour when the temperature range is correct. I did it on one of the hottest days of the year, which caused everything to cure much faster than it should have.

The slab after removing the form. Notice all the bubbles – that’s actually really not good and is a sign that the pour went wrong.

Flattening the tabletop

Flattening the tabletop turned out to be a complete pain. It was the worst part of the project. See below for all the lessons learned. I can honestly recommend that you should just bring the tabletop to a shop that has something like a Wood Wizz or CNC machine to flatten the table.

Finishing the tabletop

I finished the tabletop by sanding, sanding, and sanding some more down to about 300 grit. I found out later that you can sand the epoxy even more to get it shinier (but it damages easily).

I used a 45 degree router bit to chamfer the edges, so that my kids wouldn’t cut themselves when they smashed their heads into the table. Kids are prone to doing that kind of thing.

I used Osmo Polyx wood oil – satin clear finish. This stuff is amazing and I now swear by it. 3 coats of this stuff, one per day, and the surface was just absolutely gorgeous.

Lessons learned

Lesson #0: Unless you are a woodworker, just buy one.

The biggest lesson I learned from doing this project is that I now know why they cost so much! The epoxy unexpectedly costs more than the wood, and I’m not using cheap wood either. It is finicky and very time consuming to do this kind of project. You need the right tools, the space, and it’s still a good challenge. I know some people who have seen me do this and now think that it’s simple to do – one even committed to making one for his friend even though he hasn’t got the tools, the space or done one of these before O_o.

Now, if you’re a woodworker and you’re up for the challenge, I think it’s a great project. I’m satisfied with the result.

Lesson #1: The epoxy costs more than the wood

This will completely blow your mind. Most people just don’t realize that the epoxy resin is extremely expensive stuff. Think “oh it’s just plastic, that’s cheap eh?”. Volume-wise, the cost of the Ecopoxy is generally more than the cost of the wood! It’s freakishly expensive!

Lesson #2: You need a track saw

Originally I was using a circular saw hooked up to a Kreg Accu-cut track. This was fine when cutting plywood for cabinet making. However, for cutting through 2″ thick live edge wood, it was causing the blade and the wood to burn. In one case, it actually caused kickback and damaged the track when the whole saw kicked off the track. This is dangerous and bad.

The issue with circular saws (most of them anyway) is that they do not have a riving knife. A riving knife pushes the wood away from the blade as you saw through it. This minimizes kickback and burning.

I ended up buying a Dewalt track saw system. Why? All my other tools were Dewalt, and it was significantly less expensive than a Festool system.

Lesson #3: You need a completely flattened wood slab before attempting to do an epoxy pour

I was very excited about having a piece of wood, and I assumed that it was already flat because the place I buy it from generally sells already flatted slabs. This slab was not flat (not entirely anyway). The issue with a non-flat slab is that once you pour in the epoxy, it can lock in the air in certain spots, then suddenly when you are waiting for it to cure, the air can escape as bubbles. This is exactly what happened. I was certain there were no bubbles after pouring and leaving it for several hours, then when I came out the next morning to check, there were huge bubbles encased in the epoxy! 😦 Lesson learned: really make sure that the slab is really completely flattened. For the next project, I bought 2 slabs of wood and got them to flatten them both on the Wood Wizz.

Lesson #4: Do not pour when the temperature is out of range (especially when it’s too hot)

I did my pour on 1st July, which turned out to be one of the hottest days of the year. It was 30+ degrees celsius with high humidity. This caused the epoxy to cure much faster, which resulted in bubbles not having enough time to dissipate. I ended up getting huge bubbles in the epoxy.

Lesson #5: Do not try to remove bubbles by torching them

Combined with Lesson #4, I attempted to remove the bubbles by torching them. The idea was that it would heat up the air which would cause the bubble to rise up. Yes, it does work for surface bubbles but definitely not for the big bubbles that are in the middle of the epoxy. What ended up happening was that the epoxy got heated up and cured much faster, which sealed the bubbles in the epoxy. Hot weather plus torching is not a good idea.

Lesson #6: To avoid leaks, use silicon inside AND outside to really completely seal the form, make your wood slightly smaller than the form

My form leaked. I had water tested it. I had sealed it only on the inside.

The issue was that the wood was the exact correct size for the form, and when I put the wood in, it must have pushed the form out one end, which caused the seal to break. Epoxy went everywhere and I was scrambling to hot glue, tuck tape and seal the leak. Not good no.

For the next project (which was successful), I completely sealed the form inside and outside, water tested it, and also cut the wood slightly smaller than the form so that it would not even touch the walls of the form. Yes, it means that some epoxy will run around the wood, but that’s better than having epoxy leak everywhere!

Lesson #7: The pour is the easy part, flattening the piece after is extremely challenging

As I discovered, doing the epoxy pour itself was the easy part. You just pour it in! As long as you follow all the steps correctly, you can just leave it for 3 days and generally it will settle and give a very good, bubble free finish.

The hard part was flattening the table afterwards! I went to the trouble of building a router sled, then planed down the table using this.

My first pass completely ripped up the epoxy and left huge chunks cracked out of it. 😦 I learned that you can’t just use any router bit. You have to use a special surface planing (bottom cleaning) bit used on CNC machines ($$$). I bought one on Amazon.ca and it worked much better but it was also only 1.5″ diameter so you end up doing many passes. When you are hunched over flattening a large piece with a 1.5″ bit, you really end up questioning your life choices!

Also, a router sled comes with its own set of problems including:

Ensuring that the guide rails are really very very flat.
Ensuring that there is no vertical movement on the guide rails.
Dust/shavings collection. You need excellent dust collection. I use a cyclone hooked up to a shop vac.
Overheating bit. When the bit overheats, it can cause damage to the epoxy that you’re trying to plane down.
Going too fast and too slow. When you go too fast, it damages the epoxy. When you go too slow, it overheats which also damages the epoxy.

I tried doing this on the garage floor, then realized that the garage floor itself wasn’t flat. 😦

In the end, I did manage to flatten the table after messing with it for several days, and swore never to do it myself again, especially for larger pieces. My back was very sore.

I found out that my wood shop KJP Select Hardwoods has Wood Wizz machines that could just flatten the tables and it wasn’t that expensive either. For the next project, I would use this service instead of attempting to flatten anything myself.

Lesson #8: The vast majority of people don’t notice your mistakes

Despite all the problems that I had with this table, the saving grace was that everyone who has seen the table is unable to tell any of the mistakes. To them, it just looks amazing.

Which goes to show that only the artist sees their own mistakes. Everyone else looks at it and enjoys the finished piece.

Links and Resources

If you want to learn how to make a river table properly, check out these links:

Jeff Mack Supply: How to Use Ecopoxy Liquid Plastic – This is the best written tutorial I’ve come across on how to do it.

Ecopoxy: How to build a river table

This video by Ecopoxy is good for explaining the overall process and using the Ecopoxy product, which is actually the easiest part. The hardest part is all the preparation and what comes after the pour. I recommend having a relationship with a shop that has the right tools to properly flatten slabs like this.