Getting back to Agile

Continuous Delivery is one thing but do you have Continuous Adoption?

I understand the principles say “….continuous delivery of valuable software“, but perhaps it is time to change valuable to “useful” and remove any debate over when a development team’s job is done. “Valuable” could be theoretical but useful is practical. Valuable conjures images of money and worth while useful signifies a purpose. It wouldn’t be a big deal except when this seeps into practice where the act of “Delivery” somehow enables teams to realize a “value” without regard to adoption. Restating in terms of use with “useful” fixes that by allowing creation of processes that extend the work to include user adoption measurement beyond delivery and also requires making the product in a manner where this can be measured.

So I propose: “Our highest priority is to satisfy the customer through continuous delivery of useful software.”

We should look at a few other principles as well – after all, it has been over 15 years since their creation and in the spirit of embracing change, it’s time for some retrospection.

Customer, not Business

“Principle: Business people and developers must work together daily.”

I wonder if the term “Business people” was used “for lack of a better term”? Perhaps it was the developers way of saying “the others!” However, it seems that this is one principle that we have had no problems institutionalizing – to the detriment of the whole purpose. There’s always a “Business” team that tells developers what the Customers want. This is also often a sub-Business team, primarily serving as the interface to the development team. As they spend more and more time telling developers what the customers want, they spend less and less time learning what the customers actually do want. They end up communicating what the customers used to want. That was why we had delayed requirement changes in the first place – when those actually practicing the business found out what Business was telling developers. Many development teams learn of true requirements only when they attempt to deliver to Business while executing acceptance test with the real practitioners. It’s time to end proxies. The Business is a process not a principle.

So I propose: “Customers should work together with developers.”

I didn’t want to say must and I didn’t want to say daily. Even without those it may still sound shocking, but Customers, especially the paying ones, are more than ready to do this. They are eager and wanting and willing as they know what the developers produce can greatly help or greatly hurt them – especially as we digitally transform operations and reduce manual work of Business people. So, we need to move Business to a process and Customer to the principle. It is fine if this is implemented as “Business must enable Customers to work with developers…”

There’s good reason to implement it that way. Business is very much in the picture but needs to work differently – serve as a conduit instead of a proxy. Facilitate rather than control. Business’s involvement is essential to make sure there’s fairness in implementation when several customers are involved, non-pollution of intellectual property and competitive advantages, and most importantly, the scope is within what the customer has paid or agreed to pay for.

Now, this will also require developers to grow up – from hands-on to pants-on. Brogrammerism won’t work. No Proxies also means No Shields.

Teams, not Projects

“Principle: Build projects around motivated individuals”.

A motivated individual is too precious to waste on a project! The whole notion of a project is harmful to “Continuous”. However, we do need those, primarily for planning, then budgeting and accounting. We also want Continuous Technical Excellence, Continuous Collaboration, Continuous Integration, Continuous Delivery, Continuous Adoption and Continuous Improvement.

So I propose: “Build teams around motivated individuals” and assign projects to teams. Don’t build teams for projects.

This is important, not just a subtlety or clarification of intent given how we operate. Often development teams are not kept intact and everyone they interact with also change: the PM, the “Business people”, the test team, deployment, training. Friction is caused by not what you do but who you do it with. Projects don’t improve, teams do and shuffling them over and over again resets gains. Technology set does not matter. Good teams will solve the problem regardless.

Work/Life Integration, not Balance

“Principle: The most effective method of conveying information is face-to-face conversation.” I suspect the primary intent was to say “…not through documentation”.

So I strongly propose that we drop “face-to-face”.

While I would never argue that true face-to-face doesn’t add unique impact, implementation has been so counter to conversation and common sense. Face-to-face has been prioritized over conversation in the implementation of “short standup meetings”. Face-to-face is used to argue global teams can’t collaborate as an Agile team. Face-to-face is cited as the cause to cancel virtual offices and work-from-home plans. Together, face-to-face implementation has created rigid boundaries by region destroying constant integration and new, diverse ideas. Face-to-face has disabled tapping of talent unless they are at a given location. A global, distributed and inclusive development model is not just efficient but is exciting and educational, and implementing that without functional boundaries and integration-friction requires us to appreciate that it can only be accomplished by work/life integration, where we don’t set rigid rules for when work ends and life begins. Face-to-face precipitates this rigidity.

Iterations, not Sprints

While this is not a matter of principle, it is a principal matter nevertheless. The thought behind iterations was that not everyone got everything right the first time. This was not just about customer input. It was often what you decided for yourself you would revisit. The framework and processes that allowed for this iterative development have been taken over by the processes for incremental development and made worse by tools for continuous delivery. So while incremental development has been well realized in Sprints and To-Do/Done cycles with measurements for velocity and cycle-time, iterative development has been forced out and with it, refactoring. Teams often find that post-release, there’s no payor for refactoring and no blessing for doing it better.

What about “the Others”?

Speaking of lack of payor, the principles have offered very little guidance to teams other than developers – all of whom make software successful, perhaps as they were not represented in its formation. Finance and compliance for instance are often left to invent alignment and often after the fact. How and when do you declare capital growth with continuous delivery? How do you account for all the costs associated with deleted code due to refactoring? Was that expense? If we welcome change, are we allowing suppliers of needs to be careless in the first place? Is it not true that resistance is the mother of introspection and acceptance can precipitate complacence?

Agile is serious business

Finally, as you are constantly producing with Agile, it is imperative to realize that when Agile projects fail, they cost more. You have not just produced some designs and documents, you have produced and released product. Agile projects don’t have the luxury of slow burn at start. Too many people are actively involved right from the start, so decisions have to be made with analytics, careful thought and deliberation. So, play games if you must but don’t call it Agile! Five-hour work days is not Agile and workout sessions as standup meetings is not Agile. Imagine this: You have surgery tomorrow and the surgeon says, “Don’t worry. I got together with the nurses, the technicians and the anesthesiologist and we quickly discussed how we will operate as a team over downward-facing-dog!” You’ll be dead.