Host
Jane Nelson
Podcast Content
Increasingly, though, I am seeing cumbersome processes, senseless metrics, and people even equating SCRUM with Agile SCRUM. Processes, rules, metrics, charts, and reports are overwhelming an Agile process, making it less Agile. The manifesto called for autonomous teams, Geoffries post points out instead Agile is all too often forced upon teams, sometimes as part of their adoption. Agile environments demand metrics that teams can better understand, which help to teach and improve processes.
Agile metrics help Agile teams and their managers to measure development processes, gauge performance, work quality, predictability, and health of teams and products under development. Metrics are used by the team: Agile metrics should not be forced or measured by management, but rather used willingly by the Agile teams in order to learn and improve. The metrics are part of a particular experiment - The metrics should be used to answer a particular question about agile processes, rather than simply measured for measurements sake. The core goal of Agile metrics is value delivered to customers: Instead of measuring what or how much we are doing, we measure how that impacts a customer.
We introduce some powerful metrics that give us critical insights about agile processes. Agile test metrics can help teams measure and visualize efforts spent on the quality of software, and, to some degree, outcomes from those efforts. Scrum metrics -- Focuses on delivering working software predictably to customers.
Managers can take the lead in setting a cadence of this cycle of delivery to their teams. A Managers have a critical role to play in the delivery of development in their teams.
An agile manager may take a variety of approaches depending on individual and team needs. Agile ditches the traditional phased plan, breaking the work down to smaller, bi-weeklysprints, in which autonomous teams concentrate on one part that can be easily worked with the resources at hand. For example, creating an Agile project will involve much more than just a scrum master, sprints, and project management.
Yes, you could select an Agile dev team for this work, you could get a Scrum Master working alongside them, you could have an Agile template for project management, but big challenges await you, very quickly, if you are not working together with all relevant parties throughout your entire IT landscape. We have the product owner, we have a team of developers, and we have just hired a Scrum Master. It is also important to take into account that the people that drafted the Agile Manifesto had lots of experience.
I am not here to recommend a few tools, but we do have plenty of tools out there designed specifically to help the team on its agile journey. Over the course of almost ten years, I have worked with my fair share of teams, both big and small, helping them adopt Agile. Back in my coaching days, before anyone outside of the software industry had heard of Agile, I worked with Capital One--a slightly larger customer than most of the smaller-to-midsize private companies that I usually coached.
All this made Dans Capital One units, and Agile teams everywhere, happier, healthier partners in the business. Then, back-office units at the firm began brainstorming ways to make what elements better, testing and rolling out their new ideas on the fly.
We thought by doing this, our projects would be agile, and would produce results that were different than what we had previously done with our older methodologies. Remember, we are adopting an Agile mindset in order to improve our results, not in order to tinker around with them. What we are doing in pushing Scrum as the methodology, planning the sprint, reviewing, retrospectively reviewing, and producing reports, is simply a part of doing Agile. A successful implementation of agile requires the buildup of a lot of things.
This mindset comes from all of the Agile literature saying that you do not have one large project in front, says Brown. As a result, many software teams have abandoned architecture thinking, design in advance, documentation, diagramming, and modeling. In the agile age, too many software designers are scared of designing too much into the applications up front. Many software design teams minimize their pre-upfront designs, suggesting that details will be fleshed out during an agile process as things progress.
While such insights can help mitigate many problems plaguing teams, they also may be useful for educating management about other concrete challenges that are undermining their agile practices. By warning when waterfall habits begin to creep back into the daily operations of product teams, and undermining the Lean Agile practices championed by the Agile Frameworks (such as SAFe) that they have adopted. In an age where enterprise-wide agile is defined by heritage, today is a great time for tech leaders to revisit their agile practices. Many Fortune 500 companies and other large organizations are using flow metrics and portfolio insights to keep a tab on their Agile journey.
Agile methodologies put special emphasis on quality, as the ultimate goal is to provide working software for users -- software that is buggy or not usable is not working software. Jeffries is always careful to draw the distinction between agile and those other processes that appear to disregard its core principles - even though they use the word agile in their names anyway. Jeffries eventually encourages developers to explore helpful methodologies for development -- including, but not limited to, extreme programming -- which are faithful to the Manifestos initial principles, as well as to distance their thinking from specific methodologies that have an Agile name.
a This may work, but it has the downside of keeping managers constantly oriented toward the tasks of daily life, when they could, or should, look to the horizon of business.
A The manageras enthusiasm started to fade somewhat once I realized that I had an established Scrum team, but was not quite sure what my role was as an Agile manager.