It’s important to remember that investment isn’t a completely altruistic act. While investors clearly want to encourage innovation, a primary motivation is to see a return on that investment. At the end of the day, they’re gambling that your idea will make them money.

This can make investing in true innovation tricky. True innovations are those rare game-changing technologies that revolutionize an industry. They’re notoriously difficult to spot. How often have you heard that people thought Apple would fail when they released the first iPhone or didn’t believe in Facebook when it first went public? True innovation rarely looks revolutionary to begin with. So how do investors spot which ideas are worth the effort?

We spoke with Jason Warner, managing director at Redpoint Ventures, to understand the reasoning behind investments and why investors are so picky.

1. Typical SaaS companies are easy to invest in, but true innovation doesn’t follow the same model

When developers start searching for investment, it can often be discouraging. While investors might not understand the intricacies of every technology company they invest in, they can at least spot the trends. They know and understand how a Software-as-a-service (SaaS) company grows.

If a company is growing, it has a very familiar pattern. And so investors can be quite confident that they’ll see a return. They’re much more willing to take a risk and ‘YOLO’ an investment.

“SaaS companies are really well understood in terms of how they grow,” explained Jason. “There is no real investor challenge to understand that if a company is growing 2x and its enterprise sales look good then … [investors] can just “yolo” invest into them. Because they understand what these companies look like … It’s all just Excel spreadsheets.” -On the Dev Interrupted Podcast at 40:29

2. Investors often wait until the first round of funding, but developers need seed funding

If you’re developing a revolutionary piece of technology, then it’s likely that you need investment to get you off the ground. However, it’s difficult for investors to sort the good from the bad. How do they know you’ll be successful, without a few years of revenue behind you? It’s a catch 22 situation. You need the investment to get those first few years, but the investors need to see a few years before they’re willing to invest.

Look at how Netflix completely surprised the world. Nobody predicted that it would change how we watch video (most of all Blockbuster, who fatefully ignored the potential). This is a trend that harks back decades. Online shopping, personal computers, the television, even electric light bulbs were all disregarded when they were first conceived.

These industry-changing innovations need investment much earlier than typical SaaS companies. And spotting what works is more of an art than a science.

“[Investors] miss the fundamentals. They can see the ones that are the trends,” Jason said. “It should [then] become obvious in the next round or the round after that from other investors … oh yeah, that is a great company.” -On the Dev Interrupted Podcast at 41:18

3. Developers need to seek out companies like Redpoint for seed investment

If you have a truly new idea, you’ll need to find an alternative to the usual investors. A company like Redpoint, which focuses on giving seed funding, is much more likely to take the time and actually investigate whether your technology will be a success.

It will take longer, of course. And it might not be the full amount you need to get your business started. But it’ll be what you need to begin building a proof of concept, get those first few years under your belt and start pitching to other investors.

“[If you’re] talking to a Redpoint investor, you should be flattered,” Jason explained. “What we’re thinking is that you are a majorly important company in the future. You have the potential to land … If Redpoint invests in you, we want it to basically mean that we think of you as a new primitive on the Internet or in whatever sector that you are in. And other people are going to build upon you.” -On the Dev Interrupted Podcast at 41:35

Listen to the full conversation

If you’d like to learn more about what Jason thinks and how to secure yourself an investment, catch the podcast on our website.

Starved for top-level software engineering content? Need some good tips on how to manage your team? This article is inspired by Dev Interrupted - the go-to podcast for engineering leaders.

Dev Interrupted features expert guests from around the world to explore strategy and day-to-day topics ranging from dev team metrics to accelerating delivery. With new guests every week from Google to small startups, the Dev Interrupted Podcast is a fresh look at the world of software engineering and engineering management.

Listen and subscribe on your streaming service of choice today.

Discover Our Most Popular Podcasts
Join the Dev Interrupted discord

Flow can mean many things but when it comes to workflow it usually refers to that feeling, discussed by Mihaly Csikszentmihalyi, when you enter a state of intense focus and lose yourself in an activity. 

Video games are a great example. They take advantage of this feeling to keep you immersed, which is why it’s so easy for gamers to “lose time” and just get wrapped up. The same feeling usually drives your most productive and best work.

When you manage developers, their workflow should be treasured and valued. That’s why, to improve developer focus, it’s vital to avoid weighing them down with minor interruptions or non-urgent pings. 

“Flow is characterized as this experience where the task that you're doing is perfectly matched to the skills that you have.” -Katie Wilde on the Dev Interrupted Podcast at 7:51

1. Acknowledge that it take 23 minutes for devs just to get into flow

Did you know that it takes 23 minutes to get into a flow state? For some people it takes even longer. That means that for every question, disruption, email, and interruption that you or your coworkers are subjected to, it could be half an hour of productivity down the drain. We talked to Katie Wilde, VP of Engineering at Ambassador Labs, about how she manages workflow

“Say you got a Slack ping, and you're like, “oh, I'll just ask a question.” How long does it take you to find the thread again? What's that total interrupt time? It's 23 minutes…that's been measured.” -on the Dev Interrupted Podcast at 11:11

2. Defrag dev calendars

Some interruptions are unavoidable but many of them aren’t. Planning your calendar in a way that works around the needs and workflows of your team is necessary to maximize everyone's productivity. 

For instance, scheduling meetings on days when weekly meetings already occur can help preserve focus time by not disrupting other working days. 

Devs need to communicate with their managers on what times they have available away from normal workflow and then it’s up to engineering leaders to plan around those schedules. As a dev leader, you have to look at your devs’ calendars, not your own, and react accordingly. 

“If you're a manager, when you're scheduling, don't look at your calendar, and then find a time and then see where you can slot the engineer in…look at the engineer's calendar and see, where can you tack the meeting on that it is after another meeting, or it is maybe at the start of the day, the end of the day… and ask them!” -Katie Wilde on the Dev Interrupted Podcast at 12:31

3. Suck it up - schedule your work around focus time

When managing large numbers of devs, it can seem like a chore to work around many different schedules or attempting to get meetings done only on specific days. We asked Katie what her trick to juggling so many different calendars and meetings was, and she had one thing to say: “Suck it up.”

Devs are the backbone of software production and it’s important to prioritize their productivity whenever possible. To help them stay on task and be able to really focus on their work, they need to have meetings planned around their day - not yours.

Providing consistency for your devs - meeting them when they are ready, available, and focused - helps them maintain a flow state and maximize productivity. But more than that, it’s the right thing to do. Devs want to build cool stuff, not have their days ruined by their own calendars.   

Katie says it best:

“That might mean that, as the manager, you have a little bit weirder hours. I hate to say this, but kind of suck it up… There's no way to get around that.”-on the Dev Interrupted Podcast at 13:23

Watch the full interview-

If you would like to hear more about how managers can work around a developers schedule and other great insight from Katie Wilde, check out the full podcast on your favorite podcasting application, Apple Podcasts, Spotify, Stitcher, YouTube

Starved for top-level software engineering content? Need some good tips on how to manage your team? This article is inspired by Dev Interrupted - the go-to podcast for engineering leaders.

Dev Interrupted features expert guests from around the world to explore strategy and day-to-day topics ranging from dev team metrics to accelerating delivery. With new guests every week from Google to small startups, the Dev Interrupted Podcast is a fresh look at the world of software engineering and engineering management.

Listen and subscribe on your streaming service of choice today.

Discover Our Most Popular Podcasts
Join the Dev Interrupted discord

Hiring neurodiverse developers can be challenging, particularly for smaller companies that are less experienced at hiring. This isn’t because you need an entirely new process or that neurodiverse people are inherently trickier to interview. It’s that small flaws in your hiring process get exacerbated. Obstacles that cause neurotypical people to stumble, become outright blockers to a neurodiverse person.

So we asked Matt Nigh, data engineering manager at UW Medicine, to give his tips on how to make sure your hiring process suits everybody.

“I think there are companies that other organizations could mimic,” Matt explained. “I would look at Google as one of probably the best that I’ve experienced.”-On the Dev Interrupted Podcast at 25:50

1. Interview processes should be conversational

If you use a lot of formal language, jargon and needlessly complicated words, you’ll make it much harder for your interviewee to understand what you want them to do. It also makes the interview artificial and cold, which can lead to unnecessary stress and anxiety in your interviewee. This is true for everybody, but for a neurodiverse developer, it can be much more potent.

 

“The most inclusive interview process I ever experienced was at Google,” Matt said. “And the reason I felt they had such an inclusive process is that it was wildly conversational. They were incredibly good at explaining what they were asking and what they were looking for. And to me, it was an incredibly friendly process.” -On the Dev Interrupted Podcast at 24:10

2. Neurodiverse developers prefer straightforward and clear instructions 

When giving instructions, particularly in practical tests, it’s important to make sure that you’re being clear and straightforward. Leaving ambiguity can cause problems, especially for neurodiverse developers. That ambiguity can distract away from the actual task at hand. The clearer your instructions, the better you’ll test a developer’s actual skills.

 

“I would say the reason I failed the system design interview was (and this is an example of what autism will do during an interview) it was the first system design interview I ever had. And I spent half the time trying to understand the language that the individual was using, rather than solving the problem, trying to make sure we’re just on the same page with what we were saying,” Matt said. -On the Dev Interrupted Podcast at 24:40

3. Neurodiverse developers need diverse recruiters, and stick around for longer once hired

Everyone has their own biases. While we should all strive to overcome those, it’s not always possible. The best way to avoid those problems is to make sure your interview team is diverse. Some coping mechanisms and strategies can seem strange to a neurotypical recruiter at first.

For example, someone with ADHD might ask you to repeat points or be typing as you speak. While it could initially look like they’re answering emails or not paying attention to you, it’s more likely that they’re taking notes to make sure they follow your instructions properly. The more diverse your recruiters, the fewer false assumptions you’ll make.

“Most recruiters are used to looking at neurotypical applicants, and they essentially have mental flags that come up with certain things, certain questions or anything like that,” Matt said. “Companies should ask: Do I have inclusive recruiters? So say, for example, at Google, they had incredibly inclusive recruiters. I was recruited by a deaf individual, for example. So this person very clearly understands me and anything that was going on.”-On the Dev Interrupted Podcast at 25:13

4. Neurodiverse developers could be more productive, and worth changing your processes

A program at Hewlett Packard Enterprise hired over 30 neurodiverse people in software testing roles at Australia’s Department of Human Services. The initial results from the program seem to suggest that those testing teams are 30% more productive than others, according to an article in the Harvard Business Review, called neurodiversity as a competitive advantage.

 

It would seem that, while a neurodiverse person might struggle in some areas—like the social anxiety brought on by an interview—they could exceed in others, such as pattern recognition.

Watch the full interview

If you’d like to hear more from Matt on neurodiversity in software development, you can watch the full podcast on our channel.

Starved for top-level software engineering content? Need some good tips on how to manage your team? This article is inspired by Dev Interrupted - the go-to podcast for engineering leaders.

Dev Interrupted features expert guests from around the world to explore strategy and day-to-day topics ranging from dev team metrics to accelerating delivery. With new guests every week from Google to small startups, the Dev Interrupted Podcast is a fresh look at the world of software engineering and engineering management.

Listen and subscribe on your streaming service of choice today.

Discover Our Most Popular Podcasts
Join the Dev Interrupted discord

Fact: Over 26% of adults in the United States have some sort of disability. To ignore such a massive part of the population would be ill-advised for any company, legally, financially, and above all, ethically. How can you stay ahead of the curve when it comes to maintaining a progressive and responsive organization? 

We reached out to two experts - Alwar Pillai and Perry Trinier of Fable – on the topic of designing products that have inclusivity for people with disabilities at their core. Here are the 3 things they think every engineer, developer and product designer needs to know about inclusive design and how it will inevitably affect the future of their companies.

1. Inclusive design has already brought us Alexa, Siri and countless other smart gadgets

Often times people assume that tech companies are driving innovation through focus groups or trying to cater to the average consumer, but that’s not always true. Some of the greatest recent innovations in tech have been found by designing technology to be as accessible as possible to people with disabilities. By keeping the designing process inclusive, you maximize potential for growth.

Alwar Pillai: Each of us today use technology that’s been designed for assistive technology users first, from as simple as an electric toothbrush, which is designed for people with motor impairments, but this is something that everyone uses now… you have voice to text was for people with disabilities again. And now we have... Siri, and Alexa, and like dictation, and all of that existed because it was designed for people with disabilities first, so it is already proven that when you practice inclusive design, and design for the edge cases, there is that broader impact.

2. Inclusive workplace culture draws in better talent

When you put inclusivity and accessibility at the front lines of your work culture and development process, you not only maximize your potential customer base but increase your pool of applicants and make your workforce more efficient. Some of the best talent in the world of inclusive design comes from people who use accessibility technology daily. Maximizing your accessibility to potential employees gives your company the best shot at finding the right person for the job. What does it mean today to build an accessibility first dev culture? 

Perry Trinier: I think it's like sort of the opposite of saying that accessibility is an afterthought. In this case, accessibility is absolutely primary. And it's also like a shared understanding on the team that accessibility isn't an extra feature or like a defect that they can backlog. It's just a table stakes dimension of the quality of what they build, and that they kind of aren't finished building what they're doing if it's still inaccessible.

Alwar Pillai: There's a lot of barriers when it comes to trying to build an inclusive team, to just the workplace tools that are out there, you know?... And so we've had to do a lot of... custom workarounds for some things. But it has resulted in every single person in the team understanding the impact of accessibility and taking that extra initiative and make sure whatever they're sharing with... each other internally is easily accessible to everyone.

3. Inclusive design’s influence is set to explode

There seems to be a cultural divide when it comes to inclusivity and many companies are hesitant to make the necessary changes to fuel a more accessible work culture. Making the effort to enact real change is necessary for the health of your business and the respect of the individuals who need accessible technology. More and more individuals and companies are seeing the need to stay current with inclusive design or, better yet, lead the way to establishing new and exciting ways to stay inclusive.

Perry Trinier: I think it's important to invest in helping the team members to build the knowledge and specifically set goals for reports to, for example, complete a course in accessibility. It's an important skill, just like security and performance are for front-end developers. And it should be treated in that same way for professional development. And there are tons of resources online courses on LinkedIn, Udacity. And there are lots of blog posts and talks by experts in the community like Marcy Sutton, and they’re directed to developers, like front-end developers who just need to learn what they need to know to be able to test their interfaces and to build experiences that everyone can use, so I would say that's the place to start is just with building up that capability.

Design is changing… Moving towards a more inclusive future

There is a fundamental gap in what is provided and what is needed for many people who use accessibility technology. The way of the future is to practice an inclusive design culture and keep every person in mind in your design process. 

Alwar Pillai: The way we build digital products right now is broken. There is a digital divide between the experiences of people with disabilities and people who are able bodied. And we as people who are part of engineering teams and engineering cultures, it's our responsibility to make sure we change the way we build products and make the process more inclusive, so that more and more people have access to the products that we're building.

__________________________________

If you want to know more about Fable and their ability to help your company evolve and grow while staying accessible to everyone, please visit www.makeitfable.com. Be sure to listen to and review this interview’s podcast and many others on Apple Podcasts, Spotify, Stitcher, YouTube or any of your favorite podcasting apps. Also, be sure to join the Dev Interrupted Discord community where we have conversations about topics just like this going all week long.

 

You're Invited to INTERACT on April 7th

Join engineering leaders from Netflix, Slack, Stack Overflow, American Express & more at LinearB's virtual engineering leadership conference, INTERACT on April 7th, 2022.

1 day, 20 speakers, 1,000s of engineering leaders - all driven by the Dev Interrupted community. If you are a team lead, engineering manager, VP or CTO looking to improve your team, this is the conference for you!

>Learn more here<

Following a recent interview on the Dev Interrupted Podcast, OutSystems CEO and founder Paulo Rosado joined us to chat about his path to founding the company, advice for successful leaders, and the growing threat of technical debt. The conversation below has been edited for length and clarity. 

_____________________

Tell us about OutSystems' founding story. What inspired you to start the company?

In February 2021, OutSystems was valued at $9.5 billion dollars - but it certainly didn’t start out that way. The idea behind OutSystems was decades in the making, and its mission stems from what I observed after moving to Silicon Valley back in the mid-nineties. 

My journey in technology began when I graduated with a degree in computer engineering from Universidade Nova de Lisboa in Lisbon, Portugal and moved to the US to get my Masters in Computer Science from Stanford. Afterward, while working in Silicon Valley, I began to understand just how much of a problem technical debt was. 

While working on a very large engineering team, we were faced with tackling a gigantic project in Java and I realized the issues of releasing and maintaining code sustainably. The lack of productivity in the software development process was appalling. Fixing this problem is ultimately what motivated me to found OutSystems. 

Before founding OutSystems, there was a small company I founded and later sold, which focused on internet and intranet projects. It wasn’t a bad company, but we kept failing. Projects were never delivered on time or on budget. 

We would think to ourselves, “We’re smart. How is this possible?” Our inclination was to blame the requirements of the project, labeling the scope as incorrect and adjust from there. However, we began to realize that the companies hiring us for these projects wanted us to make changes as we were developing in response to rapidly changing environments. 

The issue we began to face was the continual accumulation of technical debt. We would reach first production and realize we had built something users didn’t want, requiring us to go back and rework the stuff we had just built. 

“We came up with this realization that the problem was not that the requirements up front were wrong. The problem was that the cost of changing wrong requirements, which are a fact of life, is very high.” - on the Dev Interrupted podcast at 6:03

 

This phenomenon was occurring in 90% of projects at the time. Things were always over budget and always late. 

Today, it’s easy to take this for granted because concepts like Agile, DevOps, CI/CD are mainstream. But at the time, you had to build software the same way you build a bridge.  

Why is technical debt a challenge for companies now? How has this problem changed?

Technical debt has become a large problem for businesses, and one that only compounds with time. Tech debt doesn’t have a singular cause - it’s the accumulation of several factors. 

Over the course of my career, I’ve seen first-hand the complexity brought about by the evolution of software development. For instance, we’ve seen an explosion of languages, paradigms and frameworks that can all be used to achieve a solution. Often these languages are dispersed with no connections between them, so tracking these dependencies requires a great deal of sophistication. 

In addition to this, turnover within the development team is a critical problem that leads to technical debt. The moment a company loses a developer, the knowledge accrued by that developer also departs the company. The hole left behind is complex, including code,  frameworks and intent behind how their systems are structured. 

It’s been my experience that a lost team member can take as much as 20% to 30% of the fundamental knowledge of a system with them. Reverse engineering their work is both time-intensive and inefficient. 

Companies have tried to corral this problem by investing in coding standards. While these constraints can help mitigate the loss of a valued developer, our research indicates turnover remains a significant problem. 

OutSystems recently released a study on the effects of technical debt. What were its findings? 

Recently, OutSystems surveyed 500 large companies around the world to examine the cost of technical debt facing businesses and uncover the challenges companies face as they confront its causes. The results from the companies surveyed were many of the same things I’ve observed throughout my career. 

It’s important to note that while the causes of technical debt have largely remained the same, the pace at which technical debt occurs has grown substantially.

And so it's a hack, right? What we call a hack at OutSystems, they did a hack to just release the software quickly. And those hacks compound into technical debt.” - on the Dev Interrupted podcast at 27:11

The survey we conducted isolated three major causes of technical debt. They are as follows: 

  1. The amount of developer frameworks. An increase in frameworks leads to an increase in technical debt. 
  2. Developer erosion. Employees leaving an organization and taking legacy knowledge with them. 
  3. Compromises in quality of architecture and code. Often caused by a shortsighted view that what needs to be done now is more important than long-term stability of the codebase.

In the past, companies believed they could buy their way out of this problem, but that strategy has proven ineffective. The reality is, the most successful companies must build the software they require to meet their business needs. 

Simply purchasing what you need doesn’t solve your problems because even purchased systems must be cobbled together, requiring unique API’s, unique UI’s, unique portals, and unique mobile applications. 

Does OutSystems play a role in helping companies cut tech debt? 

The core of what we do at OutSystems is focused on tackling those three fundamental problems. We understand that technical debt amasses slowly over time, through a myriad of decisions that appear much smaller at their onset than their totality would suggest. Once these “tiny” decisions become a major problem, they inhibit investment in current operations and future innovations. 

The increasing pressures of today’s fast-paced business environment often push companies toward decisions that spiral into technical debt. The good news is that by creating a development process that marries short-term deadlines with long-term strategic goals, it’s possible to “pay down” that debt. 

I believe that any company is capable of whittling away technical debt with the correct tools and processes, and I founded OutSystems because companies shouldn’t have to choose between building fast and building right. 

To learn more about technical debt, how to combat it, and what to expect in the future, you can download the 2021 Technical Debt Report on our website.  

_____________________

Starved for top-level software engineering content? Need some good tips on how to manage your team? This article is based on an episode of Dev Interrupted - the go-to podcast for engineering leaders.

Dev Interrupted features expert guests from around the world to explore strategy and day-to-day topics ranging from dev team metrics to accelerating delivery. With new guests every week from Google to small startups, the Dev Interrupted Podcast is a fresh look at the world of software engineering and engineering management.

Listen and subscribe on your streaming service of choice today.

I try not to get involved in arguments - but when a debate started in the Dev Interrupted Discord about if exceptional continuous improvement (CI) or continuous delivery CD) makes a group agile or not, I had to jump in. I’ve helped build many high-performing teams with agility, and I know that neither CI/CD nor Scrum makes an organization Agile.

 

It’s Not What You Do, It’s How You Respond

Probably my favorite way I’ve ever heard someone describe agility was that it’s about moving away from believing we can predict and plan everything to sensing reality and responding to it instead.

Consider two extremes. In the “predict and plan” view of the world, we build a feature list, come up with screens, represent that in a backlog, and dutifully execute in two-week chunks. This approach focuses on accurate plans and predictions in the early stages. Mistakes in the early stage compound rapidly later on. 

Are these folks agile? What did they sense and respond to?

A different  group has a sense of problems to solve and their relative importance to one another. This group decides the goal for their next investment in a sprint. Every day they look at what happened and determine if they need to change course. They frequently shift direction mid-sprint because they’ve learned something new. Are they agile? What are they sensing and responding to?

Both teams are following Scrum’s rules, but one has lost all its ability to respond to new information, and the other, while it seems chaotic, is using near real-time data to guide their next steps.

Regardless of how you do it, agility is a lot more like the second group than the first. You can tell this not  by the meetings they have or titles like Scrum Master, but rather by the frequency with which they make decisions that significantly change their direction.

You Have To Have Working Feedback Loops

A way to detect weakness in a group’s pursuit of agility is to examine the strength and length of their feedback loops. 

Scrum is a framework, which is a weird way of expressing that it has a few useful pieces and room to figure feedback loops for yourself. The parts it does have, though, are a series of events and structures that provide feedback loops.

A feedback loop is an activity where you can pause to look at the results at the end. A chef that tastes their own food as they prepare it  creates a feedback loop. A chef that never tastes their own food or waits until the dish is finished to take a taste, does not.

If you think about the events of Scrum in terms of feedback loops, every activity has a counterpart that closes the feedback loop. Sprints have Retrospectives, Increments have Reviews, and each day has a Daily Scrum.

All too often a Sprint Review is nothing more than a team saying they did a bunch of stuff with no actual feedback happening. The same can be said of Retrospectives, where the team produces many stickies, but no change manifests. The Daily Scrum Is a daily feedback mechanism, but all too often reduced to merely a task status update.

Scrum puts the potential to leverage these feedback loops in place, but they don’t work by themselves. So you can easily wind up with a team building a two year roadmap, executing on that roadmap, but never recognizing the signals that there is actually no market for what is being built.

Sponsored Section

One way to ensure quick feedback loops internally? Cutting the review time for code in your development process. WorkerB developer automation tools by LinearB can give your team proactive notifications of changes in their PRs and update developers on long PR review times while correlating the PR to the relevant project issue. 


Just turning on WorkerB with LinearB helped Illuminate Education decrease their cycle time by 44%!

Learn more about how WorkerB can increase organizational efficiency.

Quote about WorkerB Personal Alerts

The Rut of Following Form 

I often see groups espousing that they are agile because of some activity they do or capability they have. In fact, that very behavior is what inspired me to write this article. 

It can be tempting to look at agility as a feature list or series of checkboxes that, if you complete enough, you’ll summit the mythical agile mountain. But if those things aren’t so important, are the rules important at all?

Well, they are, but it’s just not enough.

Organizations and teams put a lot of emphasis on getting the basic structure of Scrum in place but tend to get into the rut of standing pat with those structures, and so the promise of agility remains elusive. These groups similarly work hard to cut things that they’ve been told are not agile anymore. Basically, they focus too much on the form, and not enough on the function.

You have my permission and support to keep using work-breakdown schedules as you pursue agility.

On the one hand, you need the form to be correct, or you can’t get the benefit. On the other, if you only follow the form, you stand in place.

So with my teams, I look to see if our process is “alive.” With a clear purpose for each activity, I can quickly see which of them are exhibiting signs of weakness that will disrupt feedback. Then I can intervene and bring the form back to accomplish its purpose.

For example, in a talk I give about Daily Scrums, I say, “The purpose of the daily scrum is to begin the day’s collaboration and coordination towards a sprint goal.” Most daily scrum meetings miss the mark of that purpose.

Looking at things from this angle, we can mature our forms and get the benefit back.

Change Takes Time

There is a fascinating intersection between these concepts where we recognize we want to address weaknesses in how we practice agility, but have difficulty estimating how to move forward and how long these changes will take. 

One aspect to this is that we do need those forms to be in place before we can sense and respond to it. In my experience, a change in these forms takes about three months to normalize in a group.

When I introduce more advanced concepts like Test-Driven Development or Work-in-Progress Limits, I introduce those forms and also hold them in place for three months. This time frame might feel slow, but it comes down to how we as people handle change.

What we’ve done in our past is what frames what makes sense to us today. Our brains crave that feeling that the world works a specific way. When we disrupt that, people’s instincts are to reject the change. Even if it is a rational and logical change, we’ve disrupted what is normal. The three month adjustment period seems to be enough to allow change to take hold and for a new normal to be realized.

During that whole time, though, the form has to be sustained.

So as much as adherence to form can be a trap, it also is the scaffolding for change.

Learn to be Comfortable with Change

My honest advice for leaders who want to make things a bit better is to get really comfortable with microscopic change for a while.

An example might be phrasing a question differently --  a small change.

Take an honest look at how you view things working best along a spectrum of plan and predict and sense and respond. Make sure to compare how you think you do to the actions that actually take place. There is usually a disconnect there.

Next, look at an opportunity within the existing forms to strengthen a feedback loop. Using something as simple as phrasing a question differently -- a small thing -- can completely alter the course of a Review or Retrospective or Daily Scrum. A thoughtful question that encourages feedback can easily improve things..

From here, you can continue this pattern of making small adjustments to how you and others move towards sensing and responding and leveraging the forms of Scrum to become truly agile.
.
.
.

______________________________________________________________________________________________________________________________________

If you haven’t already joined the best developer discord out there, WYD?

Look, I know we talk about it a lot but we love our developer discord community. With over 2000 members, the Dev Interrupted Discord Community is the best place for Engineering Leaders to engage in daily conversation. No salespeople allowed. Join the community >>

______________________________________________________________________________________________________________________________________

If you haven't already heard, Dev Interrupted is hosting INTERACT, our biggest event yetThe interactive, community-driven, digital conference takes place September 30th. Designed by engineering leaders, for engineering leaders INTERACT will feature 10 speakers, 100s of engineers and engineering leaders, and is totally free. 


 

<Register Now>