Note: This post was co-authored by Chad Michel. The rest of this 5-part series can be found here:

Part 1 – What and Why
Part 3 – Maximizing Productivity
Part 4 – Processes Can Be Fun
Part 5 – A Layered Approach To Quality

In our previous post, we covered how we think software development shops can instill some sort of culture and processes that help their teams realize the motivations that got them into this industry in the first place. We call it “funability”, and break it down into seven major components:

  • Frequent delivery of value to customers
  • Being part of a team
  • Maintainability of systems
  • Effective management of technical debt
  • Consistent quality of product releases
  • Productivity and efficiency of the developers
  • Sound software design

But once we have it defined, what do we do next? While it may sound like most of what we emphasized can be managed through office layout and agile processes, there’s actually much more to it. But at the same time, we don’t want to diminish the importance of these two factors. So let’s start with them.

Office Layouts

Who doesn’t want a cool office? Many of us started out in very strict environments, so any kind of laid back environment is a welcome change. But even developers who have only worked in the 21st century, t-shirt and jeans shops are not achieving their full potential with simply a loose approach to dress-codes and office aesthetics.

This isn’t to say they aren’t important. We feel that our space – its layout, amenities, and other flourishes of fun – definitely contributes to not only our culture but our effectiveness and productivity. It increases socialization among the engineers, which is essential for collaboration. Our recruiting efforts are also made easier with our unique space. So because of this, we can’t understate the impact physical environment has on getting the right people on your team (and keeping them).

But the spaces in which we work can’t be everything.

Agile Processes

Agile is not a silver bullet. Let’s just get that out of the way.

Don’t get us wrong, we believe that it provides one of the best (if not the best) approaches around which to center most software development. It allows our teams to operate lean, fast, and efficient, which are three essentials for nearly every shop but especially those in the startup world.

Like we’ve said before, our use of agile methodologies is not a dogmatic adherence. Rather, we leverage the basic principles and adapt them into our processes when they’re most applicable. And it’s this kind of flexibility that makes us as effective and productive as possible.

But agile methodologies alone are not a magic pill for solving all of our difficulties. This is due to the ever-increasing complexity of the problems that we’re trying to solve with our software.

We came up with this simple table to paint a more concise picture of which aspects of funability are addressed by office layouts and agile processes. As you can see, there are plenty of gaps that need to be filled.

So how do we fill these gaps? Our first strategy is to look at the key roles within our development team that can significantly impact funability.

Key Team Roles

Taking time to reflect on how our teams are thought of and organized has really helped us. It gave us time to be honest with how we can most efficiently function at every point throughout the software lifecycle. From scoping to deployment, we have a really good idea how everyone works together. And by just having this bit of knowledge is essential to our funability.

As you can see, we place quite a bit of emphasis on two main roles: Developer Leads and Project Managers. While obviously everyone on the team is important, there’s special emphasis placed on these two roles. And for good reason.

Strong Developer Leads

Most development shops have the position of “Lead Developer” or “Senior Developer” on their teams. These are usually engineers who (almost always) have the most development experience, and hopefully have great leadership qualities and the willingness to mentor younger or less-experienced developers. But we take this a bit further.

For our “Lead Engineer” role, we give them the duties of the traditional “leader” role and include these responsibilities:

  • In charge of maintaining conceptual design
  • Maintains the “big picture” of the product
  • Responsible for the performance of the product
  • Ensure engineers are testing their code

We’re sure that most Leads or Seniors at one time or another have been stuck helping others get Visual Studio set up, guide them in getting familiar with the particulars of your development environment, and other menial “getting started” tasks. We’ve all been there at some point. And while those just come with the position, that is not what we’re talking about. We task our Leads with being the “vision holder”. We need to have strong technical oversight throughout the lifecycle of the projects. Without that, it’s too easy for engineers who are in the code all day to stray from sound principles, established design criteria, and best practices.

So when the vision, design integrity and principles are maintained, funability is increased. Avoiding as many violations of these objectives as possible helps pave a better road forward. Nobody is going to have fun if the project takes a turn down the wrong road and additional work (or re-work) is necessary. We need to put greater emphasis on fixing the broken windows as soon as possible and avoiding breaking them in the first place.

Strong Project Management

The other essential role we have at Don’t Panic Labs is that of Project Manager. They perform tasks that are just as important as the engineers. Without them, we sometimes wonder how far any of our projects would go. Many of their responsibilities include:

  • Central communication for the project
  • Tight coordination with Lead Engineer, UI/UX, QA, and product manager
  • Decision tracking and documentation
  • Release plan development
  • Task/action item tracking
  • Project status monitoring/reporting
  • Project health monitoring/reporting
  • Information/decision coordination
  • Conducting retrospectives
  • Management of external communications
  • Lead daily standups
  • Keep sprint planning to less than an hour in length

But what we consider to be the primary role of the Project Manager is that of “process facilitator”, and this makes them key to funability (although we’re not sure they always think of it as fun). They are tasked with keeping track of all the little project details so that the engineers are freed up to focus on their projects. Once again, it’s all about clearing the road ahead for the developers and removing unnecessary mental weight.

What’s Next

Here we’ve covered how you can use your office space, adhere to your processes, and leverage your leadership roles to increase funability for your teams. But there’s still more.

In our next post, we’ll look at the importance of protecting engineers’ schedules and how that helps increase funability by providing long stretches of uninterrupted time to focus.

 

 

This post was originally published on the Don’t Panic Labs blog.

Note: This post was co-authored by Chad Michel. The rest of this 5-part series can be found here:

Part 2 – Leverage Your Leadership Roles
Part 3 – Maximizing Productivity
Part 4 – Processes Can Be Fun
Part 5 – A Layered Approach To Quality

We’ve been in the software business for quite some time. Between the two of us, we have nearly 45 years in. That’s a LONG time, especially in this relatively young industry. So when you’ve been part of a profession for that long, it can be easy to forget what initially attracted you to it.

We bring this up because we believe that there are some fundamental aspects of our industry that are missing and they’re causing us damage. Maybe not initially, but they’re slowly hurting us over time.

And if we’re hurting, our products can will suffer.

As with so many industries, we in the software development sector too often reduce our workforce to the lowest common denominator of function. In our industry, that means turning our workers into little more than robotic programmers who just pound out code all day.

Add that feature. Fix this bug. Death marches towards impossible deadlines. And all this to what end? A check mark placed next to another hastily-implemented new feature?

There is more to this, right? There is a way to bring some semblance of life to the desert of code >test >release->fix->test->release, right?

Yes, there is! Of course we are talking about fun.

But we aren’t talking about video games, free meals, beanbag chairs, and indoor slides. While those can be fun, we believe that “fun” needs to go deeper. We’re talking about finding true enjoyment in the work itself. Because if we find honest satisfaction in what we are creating, how we are tackling problems, and why we are changing something for the better then we can consider “fun” the curtain that – when pulled back – reveals a rarely-achieved level of personal and professional fulfillment.

While starting Nebraska Global and Don’t Panic Labs over six years ago, we knew that we had to take a different approach to software development. Anybody can build out a fun workspace, but we knew from our past experiences that we needed to go beyond the creature comforts typically found in the startup world. We needed to identify the real, soul-feeding fuel that gets us out of bed every morning and drives us to get our best selves in front of the day’s challenges.

To do this we had to examine where pain points existed within our daily routines and get them out of the way so our engineers could focus on projects and enjoy the journeys through them. But to find that seed of gratification, we had to remind ourselves why we originally chose this career.

As we thought back through the years (no old-age jokes, please) we came up with this list of motivations that informed and drove our initial passions for software development:

  • Rapid return on our efforts
  • Work on tough problems
  • Build tools that people use
  • Enrich our lives
  • Build something innovative
  • Impact lives
  • Save money / create wealth
  • Automate complex activities

These are what we wanted to pay attention to, make them the focus of our daily work. In other words, we wanted an environment where what we enjoy outweighs what we loathe.

Too often we found that our days looked more like this:

So as we were thinking through all of this, we came up with a term that describes it: funability. We defined it as “the measure of how well our culture and processes enable us to realize the motivations that got us into the business in the first place”. Since we have so many other “-ilities” in our work lives (scalability, maintainability, etc.), we felt this word made sense in a clever sort of way.

What Contributes to Funability

As soon as we defined what we wanted, we had to figure out how we were going to keep it at the forefront of our culture and daily practices, and keep our engineers engaged in our culture, company, and software development processes. We came up with seven points that we felt best encompassed our philosophy of funability.

Frequent Delivery of Value to Customers

This comes from our agile-inspired development environment. Earlier in our careers, we were pushing out releases only two or three times a year. It was a slow build-up that, in many ways, was made slower by less-than-ideal practices. And when you build up that much code over that much time, it can create a lot of pain before it even makes it out the door. There was a lot to pull together. Through that, we found that if we can increase the frequency at which we deliver fresh bits to customers we not only increase their satisfaction, but our own satisfaction too.

Being Part of a Team

Obvious, right? Maybe not so much in some environments. In the military, we have the term esprit de corps, a feeling of pride and a common loyalty among members of a group. We believe that with a spirit of mutual accountability among the team members we can be freed up to run a very flat organization. There are no managers; the teams run themselves. And it’s that kind of empowerment that deeply instills a feeling of ownership and personal achievement, which is tough to create in other ways.

Maintainability of Systems

Here’s an aspect that is probably easier said than done. Building software that can be easily read, understood, and debugged is a big deal. And once it’s done right it will reap benefits for many versions down the road (if the initial principles are upheld). Making it easy for engineers to jump right into a system and quickly understand the impact changes will have is really quite valuable.

This robust base from which a system can grow and change gives team members that sense of “yeah, we’re getting stuff done”. And as I’m sure we can all attest, that beats the alternative of spending what can seem like countless hours deciphering what others have done in the past.

Effective Management of Technical Debt

Ah, technical debt. It will always be with us, but we can limit its drag on our projects by first recognizing when choices will lead to an increase in our level of technical debt. Typically (and at the most basic level) this means not implementing features the quickest way possible but taking the time necessary to understand the tradeoffs that may lead to a less than optimal design. In the ideal case we can find a path to avoid taking on the debt but when this cannot be avoided we need to at least acknowledge the risk and plan (e.g. via a new backlog item) for how we will deal with it down the road. Maybe the most important part of this is the conversation and the shared understanding by the team of the choices being made.

Consistent Quality of Product Releases

Back in the early 2000s, we (along with a few other DPLers) had developed and were managing an eCommerce platform. Releases were done only a few times a year, and for good reason: we were on pins and needles the whole time. Would it work? What would break? How seriously would it break? How quickly could we fix it? It was a very stressful time that to this day still gives us anxiety by just thinking it about.

These past headaches are one of the driving reasons why we approach releases the way we do today. The importance of having smooth releases cannot be overstated, especially when you’re updating mission-critical systems. Living in dread of release days does not make for healthy work environments.

Productivity and Efficiency of the Developers

One of the best things we can do for our developers and engineers is to reduce their distractions, “clear the road” so to speak. By doing this, we’re giving them enough time to get into a problem and work it out. Allowing them to be constantly interrupted by numerous meetings or additional side-tasks just creates frustrations or, even worse, less-than-optimal solutions.

There are a variety of things we do that fall under the category of productivity and efficiency: the role of project management, how we physically organize the office space, the structure of our teams, and the way we design the software itself.

Sound Software Design

Maintaining some sort of consistency in your conceptual system designs is key. Providing consistency across your entire platform is what makes flexibility possible within your team. When everything is designed and developed using the same philosophies and concepts, moving team members around to different projects becomes a lot less risky and inefficient. We believe this is one of our strengths at Don’t Panic Labs.

For example, if a project requires a short burst of extra development muscle, we can augment a team with additional engineers very quickly. By keeping our methodologies consistent, it doesn’t take much for the “new guys” to get up to speed on the project. They can get going very quickly.

Consistency also prioritizes simplicity over cleverness. Sometimes a clever approach to a problem can be fun, but most times it adds undue complexity which can act not only as a speedbump for someone needing to learn the code base but also cause problems when new features are implemented. Our discipline in this area has also helped us scope projects for estimation. Nearly everything becomes more predictable when we stick to known and repeatable processes and patterns.

This is the bedrock of our culture and is something we’ve been doing since Day One. We’re not dogmatic about much, but this one may be the closest thing to religious adherence we have.

Now What?

In this post we’ve covered what we see is a fundamental problem within the software development industry and how we’re addressing it in our immediate world through the concept of “funability”. But what strategies and techniques can be implemented to increase the funability of development shops? Stay tuned for our next post for our recommendations.

 

 

This post was originally published on the Don’t Panic Labs blog.

Last Thursday we hosted an open house as part of Agile Lincoln’s monthly meetup. We were blown away by how many people showed up to see who we are, learn what we’re doing, and hear me talk about our approaches to software engineering.

Since then a number of people have requested the slides and recording of the presentation.

Special thanks to the Lincoln Agile Group for providing the Periscope recording!

If you have any questions or want to learn more, we’d love to continue the conversation. Leave a comment below or email us at [email protected].

You can also sign up for our monthly newsletter to keep up with what we’re reading, writing on the blog, and local events.

 

 

This post was originally published on the Don’t Panic Labs blog.