As a developer on a scrum team, you have likely watched helplessly as the pressure from stakeholders mounts. Despite each sprint containing a multi-hour planning meeting, and producing a Gantt or Burn-down charts, your leaders never seem to be satisfied with the progress. Situations like the one described are often due to a lack of trust. Trust is not built only with charts and graphs, but by making work visible to management.

I want to briefly speak to you about the strategies that I use when writing technical documentation on my teams. You may be wondering how you can write a document about the steps to deploy your application to your staging environment. In this case, I feel you should favor automation over writing documentation — as it is valuable to deploy an application or services in an automated fashion at a regular cadence.

“Welcome to Techtro,” says Tim, as he writes the daunting term on the whiteboard in black marker. The tall blonde man boldly stands in front of his bewildered team jammed in a conference room. He calmly returns their awestruck stare while placing the marker back on the ledge of the movable whiteboard. “Tech-what,” Mike asks with exasperation, turning to his coworker Liz, looking for a companion in his confusion. Her brown eyes echo Mike’s frustration, and he exhales in relief.

Our process has failed us! The payment feature went offline, our team doesn’t have shippable code, and a user story has been in progress for two weeks. In order to deliver software at a consistent pace, it is essential that agile teams iterate on how they work. Below I describe the steps to facilitate a retrospective to address these problems. So that this post is useful as a reference, I have made each facilitation step a header followed by a recommended time box.

While I was researching different ways for teams to increase their throughput, I stumbled upon a distinction that is often not made. Framework is often used to refer to both the framework pattern and subsystem pattern. Here is a short description of those two patterns and their tradeoffs. Frameworks Frameworks are skeletal structures of programs that must be fleshed out to build a complete application — Rebecca Wirfs-Brock Examples Spring and Rails are examples of frameworks.

Product and engineering need to see each other as co-signers on technical debt. The idea isn’t to say “no” to all technical debt, as you will definitely have to take some on. Rather, we need to have open and honest discussions about the state of the code and why certain design elements need to be fixed now and which ones can be deferred. Collectively balancing the need to deliver in the short vs long term.

Writing software is at its core a production system. The goal is to produce a product with just the right quality, at just the right time, so that customers find it valuable. With that in mind, let’s look at the types of things that can stop us from producing on time or at the right quality. There are 7 types of waste in a production system. They are: Defects — product is low quality Over processing — product has excess quality Waiting — people are blocked Transportation — moving product in a way that doesn’t add value Inventory — product is stuck between phases Motion — moving people that doesn’t add value to the product Excess production — producing quantity than is valuable to customers Blocked Stories Are Inventory I want to focus in on one of these types of waste, inventory.

Years ago, I watched Kent Beck’s talk on finding ease at work. He described death marches and unsustainable pace. He told stories of people having their humanity ignored, resulting in burn out and depression. Though, I was yet to experience life as part of a development team, my college experience allowed me to identify with those stories. He went on to discuss the pendulum swing between two states of engineering, the highs of being the team hero and the lows of being a failure.

Is your development team frustrated? Do they seem like they are going slower? Maybe you ask yourself, “Are they working hard enough?” They need something called slack — no not that chat app. They need time to reflect on their processes and try new ones to see if they can work more effectively. “How is that possible,” you ask. The answer is a techtro. Techtro: is short for technical retrospective. It is a chance for your software team to focus in on the technical process, reflect, and take action.