What is Agile Data-Driven? The Agile Data-Driven methodology was born from the need of engineering leaders to be able to measure their teams’ performance with real-time metrics and reports, aggregated directly from Git repos, by using . Git Analytics tools The Agile Data-Driven methodology is not meant to replace the Agile and Waterfall methodologies. It’s meant to add a layer of data to the current Agile processes, bringing a real-time, quantifiable view of engineering output. By switching to the Agile Data-Driven methodology, managers and executives will be able to gain visibility into potential roadblocks, reduce time spent creating reports, and increase delivery velocity. The Agile Data-Driven method also helps software engineers remove distractions. The importance of engineers’ workflow is highlighted by in his essay According to Graham, the way engineers and managers work is very different. While a manager has no problems in organizing his work around meetings, for an engineer this has a high productivity impact, as they usually end up losing half a day over a simple meeting. Paul Graham “Maker’s schedule, Manager’s schedule.” He recommends taking into account the Maker’s schedule as not to interrupt the engineers’ workflow and help them achieve a higher productivity. The Agile Data-Driven methodology helps its users do that by providing automated reports for each team member and their peak productivity hours. Doing this as an engineering manager will help run non-disruptive meetings while making engineers less likely to dread the necessary meetings. A bit of history from Waterfall to Agile to Agile Data-Driven In 1985, the United States Department of Defense the Waterfall method in their standards for working with software development contractors. The Waterfall methodology’s reign was stopped short by the appearance of a new methodology in 2001 – Agile. mentioned It was born in the USA when people came to the conclusion that companies lost sight of what really matters – delivering products that please their customers. The companies needed a shift in their focus, from unending planning and documenting their software development cycles to a more flexible approach. In 2020, we believe that the current Agile methodology needs some tweaking. With the Agile Data-Driven approach, we want individuals, teams, and organizations, to reach their full engineering potential. Waterfall In 1985, the United States Department of Defense mentioned the Waterfall method in their standards for working with software development contractors. The nature of the waterfall approach is highly sequential and consists of six phases, each following the other, that have to be completed one by one. One phase can’t start without the previous one being completed. The phases of the waterfall methodology are: Conception: The phase when developers decide what they want to design and why. Initiation & Analysis: This phase consists of gathering and documenting what the software development project will require. Design: Now, the developers determine how they want their piece of software to work and assess what needs to be coded. Construction & Coding: In this phase, the developers start coding each unit of the software and testing it along the way. Testing: The time for testing the software system-wide; it includes user testing, bug testing, and even going back through to fix specific issues. Implementation: Most of the time, this means delivering the ‘finished’ product to the customer or rolling out the system-wide software. Agile Agile was born in the early 2000s, in the USA, when 17 people met to discuss their discontent about the current state of project management within software. While they didn’t agree about everything, they came to the conclusion that companies lost sight of what really matters – delivering products that please their customers. The companies needed a shift in their focus, from unending planning and documenting of their software development cycles to a more flexible approach. Agile is based on the idea of iterative development. Agile teams deliver work in small but consumable increments. One of its strengths is the ability to respond to change quickly because Agile teams are able to evaluate requirements, plans, and results continuously. The Agile development process generally looks like this: Establish initial requirements – in this stage will be created the documentation that will list the initial requirements. Design – the team will tackle the visual design and the structural architecture of the application. Develop – this phase is about writing code and converting design documentation into the actual software. Test – in this phase, the team makes sure that the software is bug-free and compatible with everything else that the developers have written before. Deploy – this phase consists of deploying the application on the servers and providing it to the customers — either for the demo or the actual use. Evaluate the outcome – in this phase, the team gathers to review the progress made towards completing the requirements and introduces their ideas toward resolving the problems that appeared during the previous phases. Collect feedback – in this phase, the customer and stakeholder feedback is collected and introduced into the requirements of the next iteration. Establish the requirements for the next sprint based on feedback. Repeat the outcome cycles until the final product. Agile is a method that comes in a few frameworks. The most widely used frameworks are: Scrum, which encourages creative and adaptive teamwork in solving complex problems. Lean, whose focal point is the continuous elimination of waste. Kanban, which emphasizes reducing lead time and the amount of work in progress. Agile Data-Driven The Agile Data-Driven methodology is enabled by Git tools. Thousands of organizations store code in the cloud, which opens the opportunity to track the engineering output and help managers make decisions based on data. We believe that the Agile Data-Driven methodology is the next step in software development, whether you are using Agile, Waterfall, or a mix between the two of them. It is designed to help engineering leaders spot roadblocks, identify coaching opportunities, provide concrete feedback, drive constructive conversations, and increase the overall velocity and quality of their delivery. Agile vs Agile Data-Driven (similarities & differences) With Agile, you can engage your clients throughout the development cycle, give them a greater understanding of the delivered product, and enable fast decision making. By using an Agile Data-Driven approach, you can effectively communicate the impact of each decision with the clients. The Agile Data-Driven method inherits its flexibility from Agile. However, with the addition of real-time insights, issues can be detected earlier in the development cycle, thus saving development teams time and resources. Traditionally, Agile doesn’t incorporate any code collaboration metrics. However, the Agile Data-Driven methodology provides insight into how engineering teams work collaboratively. This enables engineering managers and executives to track and measure the velocity, thoroughness, and code collaboration effectiveness in software development. In Agile, reporting is done manually by managers and engineers. In the Agile Data-Driven methodology, reporting is done automatically. Therefore, engineers can focus solely on delivering value to the business. Why is it better? The end result of incorporating data into your teams’ workflow is the improved quality and velocity of delivery. There are quite a few reasons why we believe that the Agile Data-Driven methodology is better than traditional Agile approaches. We have studied and documented some of its benefits: Increases team productivity and the overall satisfaction of the engineers. It does this by minimizing the number of redundant meetings and the time spent reporting, allowing engineers more code time. Empowers an effective code review workflow across the organization by providing a framework designed to support knowledge sharing and code collaboration. Improves managers’ visibility over potential roadblocks, enabling a faster time to market. Improves customer satisfaction by mitigating the risk of spiraling costs and missed deadlines. Easier to implement into teams as it is designed to require no process change in the engineers’ work. The Principles of the Agile Data-Driven Methodology The Agile Manifesto and the 12 Principles were written by a group of software developers (and a tester) to address the issues in software development. Here is our take on of the Agile Manifesto: the original 12 principles : Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Then : Our highest priorities are satisfying the customer through early and continuous delivery of valuable software, while keeping team members happy. Now : Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. Then : Welcome changing requirements, even late in development, but acknowledging the underlying costs of changing requirements, such as increasing costs and delayed deadlines. Now : Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Then : Deliver working software frequently, while maintaining a steady cadence. Now : Business people and developers must work together daily throughout the project. Then : Provide business people and engineering leaders access to Git Analytics reports, while allowing developers to focus on code Now : Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Then : Build projects around motivated individuals. Give them the environment and support they need, trust them to get the job done, and provide them with the feedback required for growth. Now : The most efficient and effective method of conveying information to and within a development team is a face-to-face conversation. Then : The most efficient way to communicate within a development team is through one-to-ones, supported by individual data and reports. Now : Working software is the primary measure of progress. Then : Working software is one of the measures of progress, along with the insights provided by Git Analytics tools. Now : Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Then : Agile Data-Driven processes promote sustainable development. Managers should help engineers to maintain a constant pace. Now : Continuous attention to technical excellence and good design enhances agility. Then : Technical excellence and good design are byproducts of the Agile Data-Driven methodology. Now : Simplicity — the art of maximizing the amount of work not done — is essential. Then : Maximize the amount of work not done and aim to optimize the work in progress. Now : The best architectures, requirements, and designs emerge from self-organizing teams. Then : Encourage autonomy within teams by letting data speak for their performance. Now : At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Then : Engineering managers should use data and reports when providing feedback, consequently helping engineers become more effective. Now Data-Driven Scrum Scrum was created as a framework that helps teams work together more efficiently. Scrum’s main goal is to help teams continuously improve by learning through experience and self-organizing when working on projects. Data-Driven Scrum, compared to the traditional Scrum, is an Agile Data-Driven framework improved by the addition of real-time data and automated reports generated directly from Git repos. Used together, they help engineering teams manage their work more effectively. Scrum vs Data-Driven Scrum Adding the data-driven aspect to the Scrum framework doesn’t impact its simplicity. The rules, artifacts, events, and roles remain the same, but with an added notion of data. Data-Driven Scrum users can analyze the effectiveness of their team members to tailor the Scrum framework to the organization’s needs and capabilities. The semi-prescriptive approach and the use of real-time reports will remove the ambiguities in the development process. The Data-Driven Scrum will allow enough room for organizations to introduce their individual flavor to it. Data-Driven Scrum will facilitate the organization of complex tasks into feasible user stories. The development cycle will benefit from the use of the framework. The clear delimitation of roles and the planning of the events will translate into transparency and ownership throughout the process. Quick releases will keep the team motivated and the users happy, as they can see constant, incremental progress. If already familiar with the Scrum framework, mastering Data-Driven Scrum will not be a challenge, especially if the development team is already adapted to it. The concepts of smaller iterations, daily scrum meetings, sprint reviews, and identifying a scrum master will remain the same. Teams will just benefit from the addition of data to Scrum. In the end, Scrum’s success in developing complex software products across diverse industries and verticals makes Data-Driven Scrum a great framework for any organization to adopt. Why is it better? Successful sprints are often measured by the completion of items. That’s the most basic measure of success. Success is also tied to technical debt. We suggest avoiding introducing technical debt with reopening tickets, bugs spawns, quality errors, and more, via the newly created code. Engineering teams now have data available, to monitor and diagnose any outliers in the software development process. This enables them to deliver consistently and avoid introducing new technical debt. Future Scrum ceremonies will be influenced by the patterns that engineering managers identify in retrospectives, the actions they agree to take in response, and the target ranges they will set. Data-Driven Scrum helps you run effective retrospectives and plan sprints better. Using the Data-Driven Scrum framework, engineering managers can spot developers that may need more assistance during the next sprint, make more informed resource allocation calls, and ultimately help their team align toward common goals. The time spent in a data-driven retrospective brings teams closer to those recurring meetings, mission, alignment, and calibration. Engineering managers can run a more actionable retrospective by integrating the key metrics they’ve identified as the most relevant for their team and then driving conversations around those trends. The data-driven approach to daily standups Daily standups are meetings that gather the core team: developers, product owners, and the scrum master. These meetings unfold differently for each team. Most oftenly, their structure is defined by these questions: What did I work on yesterday? What am I working on today? What issues are blocking me? The reason why these questions are used frequently by teams is that they focus on progress and finding the blockers. However, the Agile Data-Driven methodology supports . It suggests that engineering teams run two daily standups per week – one at the start of the week and one at its end. a different approach to daily standups The reason why daily standups can be reduced to two per week is because Git Analytics tools can answer the questions mentioned above, with no input required from engineers. Moreover, as Paul Graham highlighted in , meetings have a negative impact on engineers’ productivity. They usually end up losing half a day over a simple meeting. The Agile Data-Driven is designed to reduce the meeting load of engineers, so they can focus on delivering business value. his essay Some of the reports that enable data-driven daily standups are: Work Logs, which display a map of team activities in code, pull requests, and tickets, so that managers can understand what everyone worked on the previous day, identify roadblocks, and drive productive discussions centered on data. Time Cards, which show when engineers are committing most. Engineers are most effective when they work in big blocks of time, so making sure that meetings are scheduled outside peak productivity hours is important to team effectiveness. Sprints reports, which create a sprint risk forecast based on historical and present data. Using this report, engineering managers can keep a pulse on their sprint progress, identify capacity issues, scope creep, and make sure that their sprint is on track. Data-driven one-to-ones One-on-ones are scheduled meetings between engineers and managers to check-in and see how everything is going. These are meant to build rapport, uncover potential issues, discuss and , and recognize achievements. diagnose performance The Agile Data-Driven methodology supports a data-oriented approach to one-to-ones. With data, engineering managers can drive conversations to uncover and address potential issues, making one-to-ones more meaningful. Git Analytics reports, such as the Developer Summary, help managers discuss, diagnose, and recognize performance, helping them build rapport with engineers. When engineering managers support their team’s narrative with concrete data, they can communicate to the organization before the release is delayed, so there are no surprises. They can show the consequences of ambiguous requests. They can advocate on behalf of specific team members, justify additional budget needs, and connect the dots between their team and the outcomes of the business. Upward communication is different from team communication. We could say that it’s the inverse of it. If communicating with the team is about autonomy and over-communicating may prove to be distracting or condescending, upward communication is the opposite. There is no such thing as too much communication, especially in large organizations. The multitude of updates serves as valuable reminders to the stakeholders about all pieces currently in play. Senior leaders need managers to push information up to them. They want to know more about what each team is focused on and how they’re progressing. One-on-ones can be a great place to showcase the work each team is doing. When engineering managers are pushing information up, we recommend using data to support their narrative. By coupling data with qualitative analysis, they can help nontechnical stakeholders and senior leaders process the information more effectively. In doing so, in pushing visibility up while using concrete data, managers are simultaneously building trust and credibility for their team. A data-driven code review workflow is intended to find and fix unnoticed mistakes in the development phase, improving both software quality and the engineers’ skills. In an ideal environment, everyone on the team is actively involved in the review process, collaborating to improve solutions to problems and ensure that the work meets the team standards. Code review Reviewers are providing thoughtful and timely feedback, and submitters are responding to that feedback, engaging in discussion, and incorporating suggestions. But oftentimes, real-life processes don’t work like that. This is where the input of data can help organizations improve their code review workflow. The code review process is intended to improve the quality of work before it goes into production. A healthy code review process reduces the risk of introducing bugs and enables knowledge transfer and code collaboration within a team. Some of the reports that can help engineering managers improve their teams’ code review workflow are: Review Workflow reports, which can highlight long-running pull requests that are keeping engineers blocked and pull requests that went through without any review, which are more likely to cause problems. Review Collaboration reports provide insight into teams’ code review velocity, thoroughness, collaboration patterns, and potential knowledge silos. PR Resolution reports are designed to help engineering managers identify outliers in their code review process, along with potential delivery bottlenecks. The cycle time is tied directly to concepts that many engineering organizations identify with, such as creating smaller stories, providing quick, meaningful feedback, and iterating. While Scrum is designed to help engineers iterate swiftly and ship faster, undetected bottlenecks along the way can upset any development schedule. This is why the Agile Data-Driven approach to Scrum aims to bring visibility into the engineering teams’ code review workflow. Data-driven retrospectives Retrospectives are an occasion for the team to reflect on the previous sprint. Engineering teams discuss their successes and failures. Then, they collaborate on what actions they can take to improve the process and the product in the next iteration. A commonly used framework for facilitating team discussion in retrospectives is ‘start, stop, and keep.’ Engineering managers might use this framework to drive a round table discussion. During this discussion, team members are asked to share approaches they would like to be added to the team’s process, such as specifying early acceptance tests with customers. When asked what they would stop doing, team members will express changes that would help the team save time or find better solutions. This could mean a change in how the team interfaces with external stakeholders or when they run daily standups every day. Managers can prepare for data-driven team retrospectives by identifying relevant data points in their team’s workflow using data aggregated by the reports mentioned above. Then, they need to gain an understanding of what target ranges signal healthy development. After that, the Agile Data-Driven framework suggests using that information to facilitate discussions around any differences between the target ranges and actual values. Afterward, engineering managers can have discussions about what they’ve learned, and the learnings can be applied to the next sprint. Photo sources: https://agile-lounge.com/18-years-of-agile-manifesto-for-software-development/ ( : ) Disclaimer The author is CEO & Co-founder Waydev
