Agile in the Context of a Holistic Approach

Jon Kern has strong views on what makes Agile succeed. You might not agree. 

Below are a set of critical practices that serve to build up a holistic view of the project, from which all else proceeds. Fail to do a good job at taking the systems view, and your project will likely not go as well as it could. It might even fail.

I finally accepted that I do Kanban process

I have long remarked that building software is like a big to-do list. I have used everything from sticky notes to Jira (since their beginning), to run projects. I used classic Scrum-style sprints for years, but in a highly unconventional way. Sprints to me were just another organizational “bucket” to provide broad-based prioritization -- a grouping mechanism, so to speak. You will read below that I rarely cared if we completed the issues in the Sprint. I mean, sure, in the beginning, I used to chase the burndown chart to see that we completed what we estimated. But then it began to dawn on me: “so what?”

So finally I decided to just admit that I have really been doing Kanban shrouded in a Sprint disguise. And now we just do Kanban.

In my opinion, the most important aspect of any process you choose, is to ensure you are working on the right things to the right “level” at the right time, and working them through to delivery. In other words, you must have a list of prioritized business features for the team to work from. So at least you always know that the team is doing the next most valuable thing...

Sprint planning and estimation

How do I do estimates? I try not to.

Well, at least not in the conventional sense where each issue is sized or estimated with story points, which are then used to determine the number of issues that can “fit” into a sprint. Meh.

Even when doing Sprints (in the recent past), I almost never did Sprint Planning or Estimation. (I think it is a backlash to the 10 years of my career where I spent time to do bid and proposals for Navy-related contract work.) My team and I would routinely joke at the Jira Sprint Report burndown graphs; sometimes the lines went up, or started to go down at the right slope, and then stayed flat. 

That’s because we did not waste any time wondering how many issues we could get done in the Sprint. We only cared that the issues that needed to be done were properly sized and in the proper priority order. We always moved the unfinished issues to the top of the next Sprint (assuming they were still needed).

Notice I said “properly sized.” Therein lies some implicit “planning.” We do not let an issue into the mix if it is a two-week effort. Instead, we break that “epic” down into meaningful, smaller issues. Larger issues might even have an opportunity to negotiate with the business to build the feature to a different level of depth, and save effort to start. We can always add more to the feature as time goes on and users give good feedback.

What works for me?

Whether for an entirely new project, a new major feature, or an addition to a legacy system, I begin by trying to understand the requirements. This process is used to build up a holistic view of the overall system, or the impact on the existing system if appropriate. By the term “holistic” I mean thinking about the many aspects that comprise your system, or that your system interacts with, and that “touch” your system or make demands of your system (including users and the “business”).

My “go-to” first principles

• Discover the business needs
• Build a sufficient domain model
• List out the top story maps/features
• Factor in any critical impact “drivers”
  • Immutable deadlines (e.g. trade show unveil)
  • Crazy performance demands
  • Crazy service level agreements
  • etc.

The number one ingredient is to have a good understanding of the business problem being addressed (aka, requirements), and build up a domain model to reflect the business. I also build a vision for the product design and maybe some overarching themes. And finally, I come up with the architecture -- maybe it is a “run of the mill” responsive web application, maybe it is cutting edge and requires a special architecture (e.g., Semantic Web). In short, I like to do just enough “up front” design to make me comfortable that there are no glaring risks that we haven’t understood well enough.

“Just enough” is subjective, of course. It probably comes from years of practice to intuit what matters more and what matters less. Nonetheless, you should try to think whether adding more detail about a particular feature during early design matters or not. Maybe you can wait to get details until you are building that feature.

Maybe I can give some extreme examples. 

As I listen to the subject matter experts and/or users describe their world and their needs -- maybe via user stories or writing down features/cucumbers, I build models of their business domain (aka, the problem domain). These models include properties, methods, and associations. In the beginning stages of requirements elicitation, I care mostly about the big picture classes and the basic features. Typically knowing that a user exists, and that the user is a borrower (e.g, in a lending application), may be sufficient. Even though the subject matter expert wants to tell me about the 20 properties of the borrower at the outset, I might hold her off. I will politely ask if there are any specific properties that impact any special requirements that we need to delve into. If not, I suggest we can get the details later. Conversely, if the business expert casually mentions a computation or compliance requirement, I might ask a few questions to ensure it is not a killer requirement with extreme complexity.

Extreme example: If the user class needs a name, that is often good enough to start. Does it really matter to the architecture or affect complexity if the “name” is eventually comprised of: first, last, middle, salutation, title, etc.?

The point is to not get extra clutter early on in the process if it does not materially affect the design. All it will do is obfuscate or cloud the important elements. 

On the flipside, I had one client purposefully withhold some details until later in the process -- he thought it would be best to wait. Except, once he revealed it later, I wished I had known about it earlier, as it affected how I thought about the design. (It was a technical aspect of pump dynamics that I now forget what the details were about.)

This technique works for me because I employ a holistic systems engineering approach to software development. Building that mental (and paper) model of the system allows us to visualize the relationships and think about impact.

Be impatient and be lazy. Get just enough requirements and do just enough design to get started -  but do no more!

Scaling agile

When I hear the term “Scaling Agile” it makes me wonder… Is that like “scaling Java?” Or “Scaling Rails?” Certainly, if you are working on a web app with five team members, it is a much different “size” than a team of 100+ building a health care application.

Unfortunately, I rarely let “size” or “volume” immediately equate to greater complexity. 

Now certainly, a project with many interdependencies and interactions with other systems will be more challenging and costly. The key is to minimize the “tax” that large applications can end up facing, by understanding the holistic nature of the systems and subsystems.

Regardless, my first line of attack is to rely on my first principles as outlined herein for building software in an agile manner. Larger projects will undoubtedly require more up-front work and more coordination than a small team project.

I would do everything in my power to turn a giant project into a bunch of smaller, quasi-autonomous projects.

I would never, ever run a 100+-person team. I might run 20 5-person teams ;-) Or more likely, be able to do the work of 100 mediocre developers with a group of 25 or less high-performing developers.

My advice: learn decomposition skills, how to architect via interfaces, and generally how to decouple systems such that large behemoth problems are turned into more reasonable-sized problems that need not have so much overhead.

The State of the Agile Manifesto

Sometimes I am asked if I would go back and change the manifesto if I could. 

“No” is my answer. 

If anything, we need to strive to (re)educate folks on what we intended when we wrote the Manifesto. 

One such effort is the Agile Uprising, a group that interviewed me (over some craft beers) about the Agile event in Snowbird. They have also interviewed almost all of the other co-authors. Check out their website, sign up and listen to some riveting discussions! They are trying to get the word out about what we authors were thinking all those years ago!

Modern Agile is another effort, headed up by some friends of mine (Joshua Kerievsky, Tim Ottinger, et al.). My only beef is with the name… What? Is the original “Agile” too old now? Not modern enough? 

When (or why) in the future of software development will these four bullets no longer apply?

• Individuals and interactions - over processes and tools
• Working software - over comprehensive documentation
• Customer collaboration - over contract negotiation
• Responding to change - over following a plan

About the Author 

Jon Kern, co-author of the Agile Manifesto, is passionate about helping clients succeed in delivering business value through software. He has a knack for taking the long view, seeing the big picture—yet knowing the details, and driving business success at every turn.