Working remotely comes with many challenges. There are issues with collaboration and time management. And of course battling distractions and sometimes even time zone differences. Today there are tons of tools available to help with collaboration – like Google Hangouts, Git, Slack, Jira, etc. However, how do you substitute face-to-face encounters?
Having remote teammates makes it difficult to have water cooler time and off the cuff conversations. These encounters are important because as engineers we get to offload and exchange our software war stories, and problems we face with whatever we’re working on at the time. How do we do that with a remote team? How do we build a level of empathy that can cross physical boundaries when working remotely?
At some point last year I came across the Idea Flow framework that aids in communication between engineers, management and the software they are writing. This is especially important in a remote setting where you may only speak with your teammates once a week. And of course frequent interruptions can often hurt more than it helps when stuck on a problem and seeking guidance from our co-workers. So what is Idea Flow and how does it help?
“IdeaFlow is a metaphor for the human interaction in software development.
Think of Idea Flow as the flow of ideas between the developer and the software.”
Janelle Klein – Founder of Open Mastery
When developing software, we associate problems with something called technical debt. Technical debt is the cost of trading off a solution that is hard to implement for a solution that is easy to implement. The easier solution may work, but it may not be the correct way to solve the problem. This is where Idea Flow comes in – as it helps identify the experience with software development as software engineers work.
Take the graph above, with the Idea Flow framework as you work through your day you log your current mode of flow. The graph highlights three main work points – Learning, Progress, and Troubleshooting. What do these modes mean? Learning is the mode of understanding the problem and crafting a solution, Progress is the flow of building the solution without experiencing friction, and Troubleshooting is when your expectations are not met when executing the solution.
This helps us understand that “technical debt isn’t always the problem”. By being able to visualize the “friction” of the engineer’s experience, we get to see the human side of the software development. This allows us to have a better conversation about the friction experienced in the software development process.
So how do we about apply this framework? Check out the following Idea Flow Communication Model:
Janelle Klein who developed this model defines each step as follows:
- Learn – with any task, we have a goal in mind. We have to read the code and build a conceptual model of how it works, in order to develop a strategy for reaching the goal.
- Modify – next, we modify the software to do something new. This is where all of the coding happens to complete the feature.
- Validate – after we finish an increment of code, we run experiments to observe and validate the behavior.
- Confirm – if the behavior matches our expectations, our understanding of the software is confirmed. We feel as if our understanding is stable, like we “get it.”
- Conflict – if the behavior violates our expectations, we experience a sense of conflict. Our attention snaps immediately to reconciling our understanding, and we usually have trouble focusing on anything else until we resolve our concern.
- Troubleshoot – once in conflict, we have to search for information that will help us make sense of the unexpected behavior. Troubleshooting usually means running more experiments.
- Rework – once we identify the cause of the unexpected behavior, we usually have to rework the code so it matches our intentions. If there’s a bug, we need to fix it.
By using this process we begin to measure the experience instead of measuring the code with unit or integration tests. We can catch problems sooner rather than later because we have a visualization of the engineer’s experience over time. This visual output proves valuable to management and other engineers within an organization because it immediately conveys any problems and allows the team to properly steer away from hitting a wall in the software development lifecycle.
So how do we use the Idea Flow framework at Jeeng today? First off, the framework is still in beta. So instead of using the framework with the graphing tools, we actually write down when conflict occurs during our workflow. This is actually the preferred method of beginning to use the framework so that engineers can get comfortable with the workflow before they have to remember to hit a button on the screen. At the end of the week our team gets together and we discuss our conflicts and from those discussions arise solutions, be they documentation, advice or new plans of action. In the end I feel that we build a more cohesive unit because we have a better and more in-depth conversation about our software development process.
