A Personal Manifesto

May 28, 2017 — Posted by Al Shalloway

Background and the Agile Manifesto.

I have been asked several times to help in the rewrite of an Agile Manifesto.  After having been involved in Snowbird 10 (the reunion of some of the original Agile Manifesto authors along with some others from the Lean/Kanban community) I realized there is no “Agile” community. Rather we have many sub-communities that are so diverse it is hard to think of them as being under one umbrella. 

As much as I’ve respected the value of and positive impact the Agile manifesto had, it has never been my guiding light for what work I am doing.  Its principles were useful.  It’s values, however were actually about what to do (e.g., “individuals and interactions over processes and tools.”)   The lack of systems-thinking in the manifesto has always struck me as a limitation on where it can apply. While people are critically important, they are a part of the complex system we call software development. We cannot pull out pieces and say “this is more important”. This is because each piece interacts with the others.   We must look at the bigger goal.

Please do not take any of this as a chastisement of the Agile Manifesto. That is not my intention.  One of my favorite quotes is Teddy Roosevelt’s “man in the arena”

 It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood; who strives valiantly; who errs, who comes short again and again, because there is no effort without error and shortcoming; but who does actually strive to do the deeds; who knows great enthusiasms, the great devotions; who spends himself in a worthy cause; who at the best knows in the end the triumph of high achievement, and who at the worst, if he fails, at least fails while daring greatly, so that his place shall never be with those cold and timid souls who neither know victory nor defeat.

I was not in the arena and I’ve never meant a criticism of the Agile Manifesto.  I am sure I would not have done better and do not even feel I would have contributed.  I hold all of the Agile Manifesto’s authors in high regard even when I disagree with them.  My concern is that 16 years later many are still holding onto this “doing and principles” as a definition for what we are up to.  This ignores that we’ve learned a lot in the last 16 years both in what to do and what principles are underneath this.  Perhaps more importantly, Agile has expanded from the team to the organization.

The begged question is “what is our purpose in attempting to improve software development?”  Is it just for the development teams or the entire organization?  Interesting to note the Agile Manifesto mentions the team 17 times, the customer 3 times, business twice and management not at all.    

A Turning Point

Agile at scale is in the process of crossing the chasm having expanded from the team to the organization. This shift brings new challenges to be met.  The insistence by many that team level approaches apply equally well to organizational challenges has much evidence against it.  It is also another instance of ignoring systems-thinking.  A team’s way of working and being was often within their control.  Part of the Scrum Masters role was to protect the team (from interruptions or management depending upon the author’s attitude about management).  Be clear I am not equating Scrum with Agile, but many have, and until around 2009 it was the de facto Agile approach.

At the organizational level we need different “doings” and additional principles. We must address the fact that we are no longer talking about local optimization (that is, the team).  But, perhaps, more importantly, we must recognize that we are now talking about an organization’s culture and not just the culture of a team.

Unfortunately, the typical business culture has us leave our individual purpose and dreams at the door.  While it was safe to have these within the team, most businesses require its employees to follow the purpose of the business.  Alignment with business goals by individuals is often not present, nor is their engagement.  There are, of course, notable exceptions.  Richard Sheridan’s Menlo Inc, being an inspiring one. But the fact that he wrote a book about it (Joy, Inc, which I highly recommend) proves my point.  We don’t need books about everyday things.  When an organization creates a space for people to live their purpose it is something worth taking note of and learning about.

A Personal Manifesto

I am not going to attempt a manifesto for the industry.  But I would like to provide my personal manifesto and hope it shines some light for people to better understand their own.   I formed Net Objectives in 1999 with the goal of “Effective Software Development Without Suffering.”  The idea was that hard work and sacrifice don’t make us suffer (good parents do this all the time).   Suffering is demonstrated by victims and martyrs who are actually flip sides of the same thing – not taking responsibility.  A victim says “oh, look what is happening to me, woe is me” while a martyr says “oh, look what is happening to me, but I am strong and will overcome it.”  I was attracted to Scrum because it laid out responsibilities where they should be. The product owner got to say “what” to build and the teams got to say “how and how long that’ll take.”  I liked that Scrum gave the right responsibilities to the right people.  There were no longer victims or martyrs, there were just people working together.  Having to work hard was not precluded in Scrum, it was just now people had ownership for their work.

As time went on I learned that setting goals in the positive is better than setting them in the negative (e.g., “without suffering”).  I came up with “effective software development with joy” but didn’t have the courage to put that on our business cards as the “no suffering was.”   But, as I am getting older (64) I am also getting bolder (hm, never noticed how similar those words are).

So what is joy?  It is perhaps the wrong term to use because true joy comes from within and is not the result of an external event.  Nevertheless, I like the connotation.  This is why Richard’s book (Joy Inc) had such an impact on me.  It was inspiring to see someone with the courage to do it and not just talk about it.

So what is my manifesto?  Or, more clearly stated, what is my purpose?  Simply stated, it’s helping organizations create a culture that supports the purposes of the individuals working in the organization be aligned to the purpose of the business. 

The Dilemma

Unfortunately, one cannot work on culture directly.  David Mann gives a lucid explanation of this in Creating A Lean Culture:

Annual reports proudly refer to company culture as an invaluable asset, and so on.

Should a company target its culture in its efforts to transform its
production process and all the positions – high and low – associated with it? It is tempting to answer: Yes! But, that would be a mistake.

Culture is no more likely a target than the air we breathe. It is not something to target for change. Culture is an idea arising from experience. That is, our idea of culture of a place or organization is a result of what we experience there. In this way, a company’s culture is a result of its management system. The premise of this book is that culture is critical, and to change it, you have to change your management system.

So, focus on your management system, on targets you can see, such as leader’s behavior, specific expectations, tools, and routine practices. Lean production systems make this easier, because they emphasize explicitly defined processes and use visual controls.

What We Can Do

So what do we do?  I am not using the above as an endorsement of Lean (although I believe there is value in it).  I am suggesting that the evidence we have says we must focus on how our organizations work, the eco-system people find themselves in, the responsibilities we allow people to take on.  How do we do this?  I have found a combination of things are required, and describing them is well beyond what has already turned into a long blog.   But I believe a key is to keep learning and to help others learn. 

People like quick solutions and vigorously defend them – especially when their livelihood or their perceived value as an individual is at stake.  The “Agile” community has turned into a set of tribes, with each attacking the other while defending their own ideas.  I have fallen into this trap myself more than once. 

Our preferred approach is actually one of seeing where our client is, what they need, and how they can start, starting where they can and continuing to learn as they go. While we incorporate Scrum, Kanban, SAFe, Lean and others, none by themselves define our approach. The idea that no one-size-fits-all and that one is on a journey, while attending to the needs of the people on the journey (they do need something tangible) is the over-arching concept.

We must remember that any solution, no matter how good (or bad) becomes a barrier to learning the moment we hold it as a solution.  I’ll close this with my favorite quote from Bucky Fuller:

I am enthusiastic over humanity’s extraordinary and sometimes very timely ingenuity. If you are in a shipwreck and all the boats are gone, a piano top buoyant enough to keep you afloat that comes along makes a fortuitous life preserver. But this is not to say that the best way to design a life preserver is in the form of a piano top. I think that we are clinging to a great many piano tops in accepting yesterday's fortuitous contrivings as constituting the only means for solving a given problem. Our brains deal exclusively with special-case experiences. Only our minds are able to discover the generalized principles operating without exception in each and every special-experience case which if detected and mastered will give knowledgeable advantage in all instances. Because our spontaneous initiative has been frustrated, too often inadvertently, in earliest childhood we do not tend, customarily, to dare to think competently regarding our potentials. We find it socially easier to go on with our narrow, shortsighted specialization's and leave it to others primarily to the politicians to find some way of resolving our common dilemmas

Al Shalloway

PS If this resonates with you, please drop me a note.  I am working on somethings to be announced shortly that I'd like to keep you informed of. alshall AT netobjectives.com





Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.


Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban