About

Traditional implementations of scrum have run their course. Sadly more frequently than not what’s left is the wrote practice basic meeting archetypes and agendas without a core understanding and demonstratable value behind them. The evidence for this is shown in several ways. Firstly we have the diminished role of the scrum master. Most scrum masters have been reduced to glorified meeting facilitators. Secondly, we have the evidence that most organizations are not using scrum is defined by the scrum guide. Thirdly and lastly, we have the popularity of the scaled agile framework (SAFe) which in some ways builds off of Scrum but in other ways contradicts it. We believe we can do better and we have developed and are continuing to develop strategies and a new system that supports agile core values fitted for the 21st century. 

The Next Evolution of Agile

A la cart design. If it doesn’t apply, let it fly. What our component-based approach we don’t require a full sell acceptance or application of everything that we promote. Each component is intended to be a tool in the toolbox that can be leveraged if teams find the useful. Our system is also not a consultant base system. The starting point of implementing it is not to hire a host of transformation specialists. Our system is more akin to a development technology they can be used by professionals if there is a fit. You don’t need to employ a team from amazon to begin using AWS services. Looked at in this way the dragon agility group promotes something more akin to DevOps process engineering rather than a branded agile methodology. 

System-Level Design

Any local optimization will be suboptimal for a system as a whole. Nights basic systems theory. So if one is talking about large-scale software delivery meaning the coordinated release of software between multiple teams one has to talk about things at a systems level and that’s above the team level. The most popular sailing approach safe tries to do this with the program increment, release trains, and an emphasis on business value. There are some real problems with these because the program increment contradicts the atomic value that the single increment is supposed to provide, the Release Train contradicts the supposed autonomy that the individual teams are supposed to possess, and the emphasis on business value is typically not within the sphere of controllable things for an individual software team. Our first agenda is to perfect the delivery side of software agility. If the business has the wherewithal to select features that do in fact bring measurable value to end-users then that’s great but the engineering team who typically has no say on what those features are should not be occupying itself with those concerns. Doing so invariably results in confusion of roles responsibilities and frustration. 

Learning-Centered

You’ve probably already seen the pattern in a million other places. And organization starts having short meetings every morning called daily scrums and bi-monthly status reports and ounces that they have become agile. Changing meeting lengths and a few words around will not fix an ineffective process or toxic culture. Those things will only be changed with New Attitudes new ideas and shared vision. We believe the best way to produce those things it’s not through a road application of specific practices or even a series of rousing speeches but the rate systemic and large-scale realignment and we think that one of the best tools to achieve that is through a shared curriculum. It’s for this reason that a key component to our approach to agile transformations is the production, delivery, and evaluation of learning. Call it the University of your organization. It is the critical and essential reinvestment of your organization’s capital into its own growth and development. If the members of your org share the same mental space on your product space, solution patterns, and values, you will have created I’m more effective and resilient team than any proposed scaling solution could hope to accomplish.

Document Driven

If the revolution of DevOps was infrastructure as code, the post agile Revolution we seek to endorse could be compared to processes code. And to draw this analogy out a little further any good Repository starts with a readme. A top-level document that describes what the code does, how it’s organized, and how to use it. In a similar way, the dragon agility group endorses a document-driven approach to describing what your organization does, how it’s organized, and how it can be used. This is nothing entirely new as we’ve always had employee handbooks and even the scrum guide its self is intended to be a manual for how to deliver work. But we want to take this further and instead of producing and seeking to follow a generic pattern of delivery, our aim is to create a mechanism whereby organizations can capture what they’re currently doing an explicit document form so that it can be more closely examined modified and improved and then used as a blueprint organizational-wide change. 

Remote Native

The benefits of distributed remote teams outweigh the benefits of collocation. Full stop. There we said it. Feel free to throw tomatoes. But that’s the funny part. Very few engineers on teams actually want collocation. The only people crying out for collocation are the theorist not actually doing the work. And we’re married to a system that is obsessed with collocation. Until we not just get comfortable with but completely embrace organizational decentralization we will not be able to capitalize on its benefits. The benefits of a distributed Workforce in terms of speed flexibility and work-life balance so far outweigh the old emphasis on colocation that organizations that adopt it and execute it with intention will blow past their competition and will in time make it look like their competitors are still using typewriters. 

Data-Based

Show me the numbers. (Yelled Jerry McGruir style). We recently spent two weeks interviewing new agilist candidates for a new position we were trying to fill. The questions we ask them was “what makes an effective team?”. We receive many answers. Good communication, collaboration, teamwork, etc. What’s interesting is not a single person said anything about how successful they were in accomplishing the goals of the team. The efficiency sustainability or predictability of their software process wasn’t on the radar and any of these answers. This leads me to ask “what would you say if I told you that such and such team was the best team in the NFL but didn’t win any games?”. This is not to say that communication, collaboration, and teamwork don’t matter but what’s really telling is it the people who give these answers are also not doing anything to measure those things either. We can do better than this. The dragon agility group is dedicated to empirical, demonstratable, and measurable metrics of the key features of effective software delivery. To this end, we have partnered with other like-minded individuals to produce Animus BI, an analytics tool that helps teams plan and predict their work. 

Tools & Automation

One doesn’t scale software delivery with more meetings or more carefully crafted meeting agendas. These may help but they will only get you so far. An analogy could be drawn in the same way to source control. If you had a group of software teams not using Source control, they may be able to do a little bit better with some carefully crafted meetings and agendas, but those things alone cannot make up for the lack of basic tooling and Technical processes. In a similar vein, many of the scaled agile approaches propose that software delivery can be scaled by patterns of human interactions when in fact some scaling is only possible with very specific technological prerequisites and tooling implementations. Currently, there’s this never-ending preoccupation with managing dependencies and coordinating work between teams but we suspect this entire preoccupation is entirely misguided. We should be eliminating dependencies and the need for coordination between teams. It should cause someone to pause and give thought when the leading scaled agile framework prescribes multi-week-long planning sessions included by every team in the program (PI planning). You really have to stop and think have we somehow arrived at a place that’s the exact opposite of where we set out to go. A good counter-example of how this could look as seen in the example of Jeff Bezos in the API mandate. The best process of all is the one that is entirely invisible, automated, and requires zero cognitive overhead.

Program Agilists

The Scrum Master is dead. There, I said it. I’m sorry. But the writing is on the wall and a lot of people already know it. 

Long live Program Agilists. If you marry a few Concepts together that are very important and prominent right now you can see how several different disparate things coalesced together to paint a picture. The first is the marriage of the knowledge worker and technological tools. The idea here is that it’s not that machines are going to rise up and take all human jobs, but that the humans who are most skilled at leveraging technological tools will take the other humans’ jobs. They will be a kind of superhuman in their effectiveness and reach and influence. The other trend is workers as artists. This concept is painted pretty clearly in Seth Godin to book the linchpin. It argues that the days of employees just showing up and being asked what they should do and following directions is becoming less and less valuable but those individuals who are passionate and driven and who seek to present solutions and their customers that don’t even know that they need rise to the top in their fields. They’re the “artists” of their trades. Taking all of this together it should be no surprise that many people who found themselves in the role of Scrum Master being flushed out of the system where does that leave those who real Excel and Leverage Advanced tools to do the job with even greater influence? Naturally, it’s going to push them up to another level of abstraction and they’re going to seek to make changes at the program level the produce greater scales of return on investment. 1 2

Supercharge Your Delivery

Are you in a leadership position to determine the course of your software program? Do you have a sense that things may be good or bad but don’t have a real concrete or empirical demonstration of that feeling? Do you like a clear sense of where the greatest areas for return on investment might exist among your teams? Drop us a line. This field and this whole space is our entire passion. Would love the opportunity to analyze measure examine and produce some baseline data and a potential road map for how you might supercharge your delivery process. 

Join the Movement

Do any of these ideas spark something within you? Are you frustrated with the current state of Agile, Scrum, or software delivery in general? Does something deep down inside of you say that there has to be a better way? If any of these things are true and you want to join the conversation and developing Advanced these ideas and many others that could be added to them, please send us a message. We’d love to talk to you and to get to know you and work together to bring about something truly amazing. If you’re passionate about software delivery, we need you. Send us a message