Is there a new emerging bigger umbrella of values, principles, and practices for web software businesses? Of course it includes Agile, but also adds in values/principles/practices related to synergistically collaborating with customers and partner companies, uses and produces open source, open data open standards, public APIs, has best practices for continuous deployment and delivery, solves the feedback gap/gulf of mixed tool stacks, helps companies roll out changes safely and better diagnose deployed bugs, and includes principles of Lean Startup for product/customer development, and ...
A very successful entrepreneur asked if there is name for such a collection of values, principles, and practices. I had helped his company adopt Agile in 2007. He said it greatly helped his companies internally, and helped him better communicate with customers and partner companies. He now feels the need for the next level of umbrella. He wants to buy the new book that's analogous to the Pragmatic Programmer, but focused on the bigger picture of how to build and deploy software for modern web businesses. He wants to read it, and give it to all people in his companies, and point it out to his customer companies and partner companies.
I asked which companies this entrepreneur thought we're doing things well. He and his lead dev listed: Square, Homefinder, Rackspace, Orbitz, NetFlix, PagerDuty
Any suggestions on where to find such an umbrella, or collection of umbrellas? A meta manifesto of sorts. ("The Synergistic Software Business Manifesto" ?) If not, is it time to create such a manifesto?
Comments welcome to kelley at kelleyharris dot com
You can get more Agile in small steps, the next time you code. Start with small, seemingly tiny, improvements in the code. They will add up over time. Martin Fowler calls this Opportunistic Refactoring. Uncle Bob characterizes as a boy-scout rule, of leaving the code in a better state than you found it.
A great start is to learn & use simple refactorings, such as renaming for clarity (e.g. Rename Method), breaking long confusing methods into smaller focused methods (Extract Method), and one of my favorites, Compose Method, as recommended by Joshua Kerievsky, in which you code intention-revealing steps, at the same level of detail.
While there many sophisticated refactorings, just doing these few simple ones will help clarify the code, help your skills, and reveal bigger opportunities. (Some Editors/IDE's make it even easier.) When you get a chance, observe how experienced Agile developers often to do these refactorings as natural part/foundation of working on bigger challenges. Sure there are concerns about breaking working code, especially when you don't have the safety net of automated tests. But you can use your engineering judgment about the stage of code development. At the very least, you can do it in your local changes before your next commit. Small improvements will add up quickly. In the code, and your skills.
If you'd like to receive more "Agile Steps", email More Agile Steps.
What if software was developed based on truth; with customers, with stakeholders, up & down organizations, between teams, within the teams, between managers & developers, and with ourselves? We could call it "Truth-Driven Development" (TDD2) It might look something like the picture Uncle Bob paints in his blog post: The New CTO, http://blog.8thlight.com/uncle-bob/2012/09/06/I-am-Your-New-CTO.html Sounds like it would help everybody. So basic. So powerful. Let's do it.
So you want to get the benefits of Agile, etc. That's great. While grand sweeping organizational changes sure are tempting, they frequently go astray. They can be disruptive and expensive. They can even backfire big, and very publicly.
There is another way. You can get the benefits of Agile and Lean practices in smaller steps. You can focus on your urgent priority issues first, and use Agile practices opportunistically. These small process improvements will add up. After years of helping organizations, I'm more and more recommending this simpler approach to change:
Your organization can get more and more Agile, in small steps, without big disruption, risk, and expense. Real lasting change is usually more like a marathon anyway. Relaxed persistence, and some smiling, helps along the way. And, there is no real finish line anyway. You can keep improving, as you meet new opportunities and challenges, and keep learning and refining your business. Or, of course you can always just stop, when you decide your organization has learned enough. The decision is yours.
Ward's new Federated Wiki project is getting better and better. I've been fortunate to be able to watch Ward in action, over the last couple months, via weekly video team meetings, pair programming on Skype, etc. He graciously invites new people into the project. He makes them feel welcome. He finds ways for them to contribute. He learns from them. He does it all with such sincere openness, interest, patience, humility, and kindness. No ego. No hype. Here's one of the fathers of Agile/XP methods making progress with minimal ceremony and Agile jargon, just making steady progress coding and coaching. Wow. I'd appreciated Ward's work and writings over the years, and been fortunate to interact with him at various conferences. But interacting with him on the Federated Wiki project has been the highlight of my career. I encourage you all to check out the Smallest Federated Wiki in Github. (https://github.com/WardCunningham/Smallest-Federated-Wiki) Try it out. Consider finding a way to contribute. It's a priceless education.
Are you wondering how to surf the unknown future? Stay relevant? Out innovate your competitors? What do you do when a situation is completely new, when both the problem and the solution are unknown? What does your competitor do?
What does an unknown situation mean for your organization? Who you hire? How you plan? Is some part of your organization fearing the unknown and clinging to the known? If so, it will be hard to adapt and make progress. But your competitors are facing similar challenges.
If you can get really good at surfing the unknown, you've got a real advantage, and can even welcome change and the unknown. It will give you an on-going advantage.
As the world changes more rapidly, and we need to innovate faster, we all need to get comfortable surfing the unknown. It helps to get fluent at it for small stuff, so that you're ready when the stakes are high. It can be learned, it can be practiced. It can give your organization a long-term competitive advantage.
Agile is part of the answer. It's not the whole answer. It's a great way to implement software, especially when you're sure you have the right product for the market. But the world is changing fast and so is the market. Combining Agile with other principles can help you more than Agile alone. For example, customer development and rapid iterative market validation, can feed requirements to the implementation team, and the implementation team can provide tools, insights, and software to help test the market. That combination is more powerful than Agile alone. Eric Reis points this out very well in The Lean Startup. There are many other complementary principles and practices to consider.