The feedback loop is critical in Agile methodologies
The feedback loop is critical in Agile methodologies
The feedback loop in Agile software development is fundamental to most Agile practices

Imagine a process where your Agile team could show work to users. Those users could provide real and honest feedback. Which your team could use to reinforce ideas and to learn. Wouldn’t that real feedback be so helpful? That process exists! It is the feedback loop, which is part of the demo process used on Agile teams.

What is the feedback loop? The feedback loop is a more generic term, for the repeating cycle between parties, where information is shared, evaluated, updated, and shared again. Team members can share information, assumptions, and work products with users to get an evaluation. That evaluation is then used to make decisions on how to move forward. The feedback loop applies to so much more than just a demo of software products though. It should also be used to refine information, assumptions, and validations. Refining those through real feedback will only strengthen them. …


Image for post
Image for post

There is so much negativity going on! So much so, that it helps to take a min and remember this fact. We are stronger together! Remember that we have achieved so much together already. Remember how we achieved such great things. It was through united purpose of the people.

Different opinions are not the enemy. Differing opinions get combined and mixed together, and that can create solutions. Better solutions than single opinions can on their own. Don’t forget this, that we are a team. Together, teams will create the best solutions. Teams provide the best answers as they use the combined knowledge, skill, expertise, and work of the entire team. …


Image for post
Image for post

In an environment where the team now practices Agile methodology, and previously practiced Waterfall, there can be some carry over habits. I am not trying to sell either methodology here. I am just exploring some ideas to help with the scenario of a team moving to Agile, from Waterfall.

Focus on priority, over due dates and timelines

A primary focus of the Waterfall methodology is defined pieces of work in specific time frames. The intent there is that you have known project work, you know when you need to have it delivered by, thus you organize the work to meet the due dates. Where this typically goes wrong is with the understanding of the work to be done. Also with understanding how long that work will take. Quite often, 1, or both, of those items require more than was planned. …


Image for post
Image for post

What are best practices for documentation in agile software development? Documentation, its always a question. It is needed with any piece of software, application, process, etc. How much should be documented? When is it too much? How do you navigate complex environments and communicate effectively? Keep a good balance of meaningful information. Avoid too many details. Documentation in agile development also needs to be well organized. Following are thoughts to help guide useful documentation. Without the issue of over documenting. Ultimately arriving at something that is useful. Use these ideas for Documentation in Agile to streamline work and be more effective. …


Image for post
Image for post

In working with a new team recently, this new team mostly had experience in waterfall methodologies. They have not worked much in Agile SDLC. This got me thinking, what are some common things that team members hold onto, or carry over from Waterfall SDLC to Agile SDLC. I am not saying you need to make that switch, just if you have, what are common traits the team still shows in the new SDLC. Below are the top things that I see team members hold onto.

Team members want approval on the solution.

Traditional waterfall relies on more formal approval processes. In large, the reasoning there is because the timelines are extensive. So you have to take measures to ensure the work is right. Contrast with agile however, where timelines are often much shorter. By timelines, I refer to the time between sprint or iteration deployments. These shorter timelines have the benefit of a quick build and learn process. Where you can build small pieces, and then you have the opportunity to learn from what work was done. If changes or a pivot is needed, it can happen then. Where only a small amount of time has been used. If work or time is a waste, it was relatively small. …


Working from requirements is outdated and this practice blows it away
Working from requirements is outdated and this practice blows it away
Working from requirements, or a better path, which would you choose?

I just completed working from an extensive and detailed list of requirements. The team had delivered a quality product. More so than that, they had put a lot of time and effort into this work. Then, the product was delivered Immediately, the users said, “well, what about this….”. We were a bit dejected, to say the least! We had worked from the requirements and thought we delivered what was needed. Just to find out the hard way, maybe there is something better to use than requirements.

In software development, requirements are often the driving factor of the output. They are treated as the end-all and be all. They are what the team is trying to deliver. Requirements are used to tell the team what it is that they have to deliver. Often they are a stringent list of details. To guide the team to the final product. …

About

TJ Rerob

A Product Owner and Systems Analyst with 15 years in info tech. I leverage this to learn/build new ideas. I have worked in Fortune 500 companies and startups.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store