The power of feedback loops

Working in software development requires that we find the right techniques to achieve quality and customer satisfaction. Learning about development and flow techniques from experienced peers can be helpful. But if the team has a lack of senior peers or insufficient commitment, we may have to find alternative routes.

While studying how to improve my methods, I watched an interesting video wherein Noel Ford explained how useful feedback loops are in software development. Working from that premise, I started collecting and applying the best practices that could most help developers deliver software that meets customer expectations while also improving code quality.

First of all, let’s define a feedback loop. According to Wikipedia, “Feedback occurs when outputs of a system are ‘fed back’ as inputs as part of a chain of cause and effect that forms a circuit or loop.”

Any Agile or Lean framework incorporates this concept, but I think the closest implementation of feedback loop is defined inside kaizen with the PDCA cycle.

PDCA cycle

PDCA stands for “plan-do-check-act” and in kaizen is a technique used for continuous improvement of a company’s standards. The team tries first to analyze a problem, retrieve the metrics in the current situation, define a strategy for improvement toward achieving the intended result, and finally retrieve the metrics of the process to assess whether improvement really occurred so the team can adapt strategy to obtain better results and create a new standard.

This is a continuous process that should be carried out several times to aim for the best possible results.

Source: http://upload.wikimedia.org/wikipedia/commons/a/a8/PDCA_Process.png

Feedback loops in software development

As software creation follows an empirical process, we need to create several interim checkpoints to determine whether what we’re producing is really what our customers are looking for. Often during development we don’t realize how much time (and money) we waste simply because we don’t gather good specifications or show the progress of our work to the customer. Just because the waste is to a certain degree hidden doesn’t mean it is without cost; we often invest more time and expense than we realize, yet with a few shrewd tactics could actually prevent such loss and achieve what our customers really expect.

We can add several types of feedback loops during development to help accomplish that. The key rule of any feedback loop technique is “shorten, and often”!

Let’s go through the different types of feedback loops we can apply:

TDD/BDD/Unit Test

Test-driven development, behavior-driven development, or simple unit testing is the first feedback loop that should be established on any project.

It’s helpful for the healthiness of your project not only because helps you to better define the requirements, design better APIs, and obviously check the sanity of what you’ve written or refactored but also because testing gives you feedback on your work in seconds, and you can have this feedback every time you save a code file or when you push the code in your version control system.

Static analysis

Often we avoid proper static analysis in the belief that we lack the time to define what we need to analyze, but it doesn’t really take a huge effort to establish a good strategy, and the potential benefits are important.

Static analysis can help you immediately recognize areas in your software that could be simplified or improved without deep-diving inside the code. It supplies a powerful feedback loop that in seconds or minutes can provide metrics to analyze during the whole development life cycle.

One of my favorite metrics techniques is cyclomatic complexity. Applying this metric during the whole life of your software will help you understand the healthiness of your project and what areas need attention.

Code coverage is another useful metric, as it can suggest the extent to which your system is covered by tests. Unfortunately, though, it doesn’t give you feedback on the test quality.

Pair programming

Introduced by XP, pair programming is a powerful loop technique that provides peer feedback in seconds while letting you consolidate your knowledge and explain problems or solutions to someone else. Developers often skip this option when the business department deems it too expensive to have two people working on the same piece of code, but research demonstrates it’s not as costly as one might think. In fact, several studies show that while pair programming lowers developer productivity by a mere 10 to 15 percent, it increases the robustness of your software, consolidates and improves the skills of developers, and, most important, helps detect bugs and architecture mistakes more than any other technique. If executed in the right way, it can be a great investment for both your company and your software.

Code review

Code review definitely improves project quality and normally should be performed every time a developer in the team makes a pull request directly inside the version control system. Unfortunately, they are often skipped or, worse, ignored because we trust our peers too much or don’t have time. But if applied properly this technique can improve the code quality and architecture of your software to an amazing degree.

Usually it takes days, not seconds or minutes, so bear in mind that with this technique your developers don’t have the kind of frequent feedback afforded by the previously described techniques.

Agile Modeling

Several books describe and discuss this topic; I suggest scheduling one or more sessions at the beginning of any project to architect enough of your software that you can start development and review the design and implementations iteration by iteration (possibly with every sprint). You’ll see a constant improvement in your code without a huge up-front effort, meaning less need to accommodate changes for future business requests and more likelihood that your architecture and design decisions will faithfully reflect the project specifications. Usually these feedback loops are the only ones that maintain overall code structure and architecture sanity as viewed with an “eagle eye.”

Daily stand-up

This ceremony, used not only by Scrum teams but in many Kanban implementations, primarily provides an opportunity to synchronize team member efforts as well as a starting point for discussing potential improvements. As the name suggests, it’s a daily activity whose value hinges on not only on the technical aspects but also team communication and the big picture behind the project. These aspects are fundamental, because often developers are so focused on details they miss the perspective that could keep them from spending unnecessary work or time on secondary features (remember the Pareto principle).

Retrospective

An Agile retrospective, if well organized, is the most effective ceremony inside the Scrum framework to produce feedback that really helps improve projects and promote healthy teams. I facilitated several retrospectives and I’ve always gained a lot from them; if you can create a good atmosphere, defining properly what you want to achieve, you may reap surprisingly good results. For this purpose the retrospective is organized at the end of each iteration (usually every two weeks), but I really suggest more often if the team is recently defined or has more than one new member, to help newcomers feel part of the team and acquire its mind-set and to permit review of the resulting team performance as a whole.

Conclusion

Feedback loops help on a daily basis with project improvement and delivery success; more feedback loops mean greater control of software quality and better customer satisfaction, exactly the goals you are trying to achieve every day. Don’t be afraid to try new techniques to improve your team and your company. Fail fast, retrieve metrics, and learn from them; the worst that can happen is that you really improve!

Approaching Scrum

Have you ever felt disappointed because you don’t finish a project in time?
When you try to estimate a project you feel like a poker player?
Have you ever wrote bad code because you were overtime and you needed to delivery as fast as possible?

If you think that there isn’t a way to escape from this nightmare you are completely wrong and I understood it in the las few months as well!
I don’t want to say that with Agile you can solve everything, but what I can say that for sure it can help you to achieve your goals and deliver in time with the best quality and value for your customers or users.

Let’s start from the beginning…

What is Scrum?

Scrum is an iterative and incremental Agile software development framework for managing software projects and product or application development. Its focus is on “a flexible, holistic product development strategy where a development team works as a unit to reach a common goal” as opposed to a “traditional, sequential approach”. Scrum enables the creation of self-organizing teams by encouraging co-location of all team members, and verbal communication among all team members and disciplines in the project.

A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called requirements churn), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner. As such, Scrum adopts an empirical approach—accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team’s ability to deliver quickly and respond to emerging requirements.

From Wikipedia.org

When you start to read about Scrum a lot of things seem impossible to apply in your daily job but I think that, like any transition period, you can arrive to work completely in Scrum in less than 6 months if you really want change your organization and improve it.
From my experience Scrum is a good framework that should be used extensively if you are working in products that will be delivered to the final user, otherwise you have to train up your customer to be Agile; but in the real world it could be more difficult.
Mainly because you need to have a good trustability before start to involve them in an Agile process and sometimes there isn’t enough time to do so.

Why have I to use Scrum?

That’s a good question, it was the same that I asked me few months ago and finally I’ve an answer, if you are a developer think when you started to write the first lines of code, obviously day by day you increase your knowledge and your code became even better until to the procedural code it wasn’t enough and you try to look to something more.
Then you have discovered OOP concepts and maybe design patterns, after few times you started to work with MVC, MVP, MVVM or your favourite architecture and probably after many years if you look back you won’t write procedural code anymore.
Does it sound familiar?
In the same way of Design Patterns and a micro-architecture that drive you to create solid and maintainable project, Scrum can help you to organise your projects creating a great business value, knowing every time the next steps and the actual status of the project, estimating better the goals and the time to achieve them and last but not least to drive the risk in a better way than the “traditional” methodology (waterfall model for instance).

How does Scrum works?

Scrum diagram
Scrum

As you can see from the diagram above, Scrum is an iterative workflow that happens in a small amount of time (usually 2 weeks or 4 weeks at least) where with few documents and a lot of communication you can achieve the best trade off between the business value for your final customer and the best quality of your software.
Scrum is composed by some actors (Product Owner, Scrum Master, Development team and Stakeholders), some meetings (Release Planning, Backlog Refinement, Daily Scrum, Sprint Planning, Sprint Review, Sprint Retrospective) and few artifacts (Product Backlog, Sprint Backlog, Burndown chart, Product Increment).
The most important concept that you have to keep in mind is that Scrum is easy to use and to understand but if you want to have its benefits you have to follow its rules.
To enter in this interesting world you have to keep in mind the 3 main concepts of an empirical process like Scrum:

  • Transparency
  • Inspection
  • Adaptation

Without this 3 fundamentals principles, Scrum it’s not useful at all!
Transparency means that you and your team don’t have to hide anything to anybody, if there are any impediments or problems or bottleneck following Scrum you can find and resolve them.
Inspection means that you and your team have to analyse what you have done after a small amount of time (Sprint Retrospective) and find what positive or negative was happened during that period.
Adaptation means that everything is not binary (0 or 1, true or false) but you have to adapt your way to work day by day improving yourself inspecting what you have done and being agile!

If you want Scrum is not only a good approach to work, it could be a good approach for life as well!
(Check also this useful article on Scrum Alliance website that explains Scrum in 30 secs)

Ok, now I’m really interested in Scrum, where to begin?

There are many books that allow you to enter in this amazing world, the first one that I can suggest you is Essential Scrum: a practical guide to the most popular Agile process

Essential Scrum
Essential Scrum

In this book you can really understand how the Scrum framework works and how to use it in your daily job.
I also suggest it if you are planning to join in a Scrum training course, it can really help you to have a good preparation for the course and for the following certification exam.

Next steps

What I’d like to share with you is my notes about Scrum studied on books, read on blog or social networks and share with my fellows, my idea is to fix few concepts on this blog that could be helpful also for people that is approaching Scrum right now or they would like to know more about it.
There are really tons of things to know and you’ll never finish to learn (as usual) so I think a blog it could be a good resource to share the basic of Scrum and in the future, going more in deep with real case studies related to my daily job.
I hope you will enjoy this information that are not what you usually find in my blog but maybe could be interesting as well, as usual any suggestion will be very appreciated so don’t be shy and share your thoughts!