Rants
Questions
Soapbox
Best Practices
Apply today for a FREE subscription to CIO Magazine!
Mon, Jun 29, 2009 18:16 EDT

|
Posted by: Michael Hugos in Soapbox Topic: DevelopmentBlog: Doing Business in Real Time
Current Rating: |
Agile practices hatched in the IT world are also relevant to business and there is a pressing need to advance agile practices in both realms - “When the going gets tough, the tough get agile”. Fellow agile practitioner and CIO.com blogger Eugene Nizker and I have been conducting an ongoing discussion/debate about agility and its implications for the future of IT and for the future of business.
In Eugene’s words, “Agile is based on a simple philosophy of common sense. It puts forth a key axiom and a few related propositions and gives some very simple answers.” So we’ve organized our thoughts by listing the key axiom of agility and then we present a short list of propositions that follow from that axiom. For the axiom itself and for each of the propositions, we respond with some observations on agile philosophy and techniques. Eugene’s responses concentrate on the impact of agile on IT, and I add my two cents on how agile relates to business operations.
Key Axiom: Uncertainty of Outcome is a Reality
EUGENE N: Do we (or our client) know what we need to get at the end? Yes, but only in general terms. This sets a very different paradigm for the software development industry.
Indeed, the industry still works based on set of signed off requirements and uses approved set of “best practices”. It still uses this dated set of prescriptions that was not working even when it was just created. Expectation that following a set of instructions can produce desirable results is inherited by the software industry from manufacturing and construction industries. Although some of the principles that work well for those industries are applicable to software systems development, this applicability is rather limited. In today’s enterprise development the majority of software projects, related to business processes, have a completely different nature.
Indeed, in manufacturing or construction the vision of the project exists before the project is commenced. In software development a vague and incomplete vision exists at the beginning of the project. In manufacturing or construction the requirements are more or less stable (for example, we do not expect changing the number of stories in the building half way through the construction). But do we often (or ever) see stable software requirements?
Major (if not all) design decisions in manufacturing or construction are made before the commencement of the project – but every software developer makes design decisions every day. Testing in manufacturing or construction is usually partial and non-destructive, unlike in software development.
But more importantly, client’s expectations differ too. Clients are rarely surprised at the end of a construction project – and we know how often they are really surprised seeing a system for the first time that was developed for two years in an ivory tower by a group of techies.
This suggests that we are dealing with a very different matter indeed when developing a piece of software. Our world is not fully deterministic, but only partially deterministic.
So, after we agree on the only partially deterministic nature of software development and business evolution (let’s call it the Great Axiom of Software and Business Indeterminacy - GrASBI), the rest is easy. In order to adhere to GrASBI, several traditional IT and business postulates of the past need to be modified.
MICHAEL H: About 80 years ago in the scientific world a scientist named Werner Heisenberg put forth a then radical idea that upended the traditional Newtonian belief which said if you took enough measurements you could confidently predict what would happen and when it would happen. Heisenberg said if you knew the position of
First of all my short answer... "AMEN!"
Now for the longer one...
So many of us want to say it, and so many of us think it, and have thought it for a long time...but Mike gets it!
We've all been slaves to 5-year strategy sessions, 1+ year project plans, and a variety of fancy terms for very uncomfortable bracelets and ankle jewelry that keep some IT organizations a mundane, uninventive part of the organization. Everyone is so obsessed with NEVER EVER making a mistake that we plan, plan, and plan some more, until we propel ourselves full-bore into an irrelevant outcome. Plans are followed, to the letter, while the business needs changed during the project lifecycle. Are these projects successful? Absolutely not. But they followed the plan! Sure, bring a basketball to a football game and you'll find yourself irrelevant quickly.
We are obsessed with time and money, and somehow lose track of RELEVANT results. A grand complication watch tells the time as well as a Timex, but neither give you more time to do anything. Quicken doesn't create money, and only tells you where it all went. We are obsessed with time and money because we believe we can control them, and subsequently control outcomes, which is a farce, but we all pat ourselves on the back when we do it "right." Agility gives an initiative an element of relevance, not simply a list of a deliverables, by a certain date, for a certain price. Make it cheaper, it could still be irrelevant. Make it faster, it could still be irrelevant. Spend too much money, it could be irrelevant. Spend way too much time, it could be irrelevant. Make it agile, and check its relevance often enough, your outcome will always be relevant.
In comes agility. Agility is your ability to maneuver quickly when someone yells "Iceberg!" instead of staying the course, because that's what we PLANNED to do when we set sail. I've measured project successes based on our team's ability to deliver to expectations, in terms of *what* and *when* but I also measured it by how many *changes* we were able to implement along the way, to measure our *agility* as a team.
Next comes the feedback loop. I couldn't agree more. Case in point, GM (General Motors). The pinnacle of agility - absolutely not. Did GM really ever ask the customer base what they wanted in any way? Obviously not in an effective manner, as they were pumping out something completely different than what was wanted or needed by the marketplace. This is not a place where you'd want to land yourself, by ignoring the feedback of your customer, or client, both internal and external.
Finally the "think big, start small, and deliver quickly." This is the time to do it, and there NEVER is a better time to be agile than when all the lumbering relics of the Industrial Age are chasing their tail, or worse, preparing some serious 5-year strategic plans to combat their inevitable extinction (at least in their own minds).
I also agree that time to market is absolutely key whether it's a product or service for the public market, or a technology implementation that enables business agility. I would say yes, *efficiently* get a product or service out quickly, and at a low cost, but if anything -- "plan for success." It it so much easier to ask for money and time when you've created demand, versus speculation. Oil companies and the Big Three counted on speculation, and so did a few banks, and I'm only talking a few months ago! I'd love to be a fly on the wall at some of the not-so-celebrity roasts of a few key decision makers, who came up with some hard-core long-term plans, and missed the boat.
During these recent times of uncertainty, isn't interesting to find that China, who lived for centuries by long-term planning, was agile enough to develop a low-cost battery chemistry and electric car technology, while GM lumbered and fell, as well as information technology to manage and track complex financial transactions, such as derivatives, while we still are picking up the pieces from the economic crisis of late. And they have four times the US population, so you can't say that you need to be small to be agile! This is not legend, but truth.
If you are a 5-year-planner type - ask yourself if when you drew up your strategic plans some five years ago, did you include the impact of social networking, socialized healthcare, increased financial market regulation, or perhaps the complete financial meltdown of our world economy?
Don't feel bad if you didn't. But hopefully, you are agile enough to maneuver and adapt, when you heard the resounding cry of "Iceberg!"
Your final question is really the crux of the matter - "Are you up to it?" In business it seems that people rarely want to be involved with your core effort here, which I think could be referred to as - 'Brilliance In Motion' - there is a love for seeing it on the playing field - witnessing it at a bit of a distance - but being engaged in it is judged as to edgy, perhaps to hair-raisingly exhilarating - as in Excellence is Exuberance!
Michael's AMEN says it all, already,
but I want to give you additional thanks to his long reply.
I'll give this to a few of my client's CIOs and CEOs to show them where they're heading when they don't change the way they run their business.
Thanks
Olaf
A few words commenting Michael S. Bogovich’s comment.
Michael, I can’t agree more with you regarding long-term planning in a dynamic world. I spend half of my life in Soviet Union. Tell me about 5-year plan!
However, one thing we need to keep in mind: it’s iron-hard long-term plans that Agile doesn’t value much, but agile values planning highly. In fact, agile planning is much more stringent than traditional one. It requires much higher discipline from everyone involved.
After the big picture is more or less clear as a result of initial light-weight planning, agile planning focuses on a piece of work at hand. We progress the plan as the project progresses. The team is involved into permanent, ongoing planning, but we plan something that we know we can achieve: the next month, the next week, the next day. This is the difference!
Now about time and money. We did not touch on this matter in the post, but I agree with you, we need to talk way more about these infamous “on time and in budget” metrics that are so-o detrimental for the business and serve no-one but been counters.
Which brings me to another point we didn’t touch. Corporate politics. As one of the recent articles mentioned, “traditional” methods are so popular because they are safe for those who can’t deliver. Indeed, “Look at our plans and how we followed them. We applied best practices! The papers we produced prove that we did everything right. The problem might be elsewhere…”
Why people still use useless practices? You think they don’t know better? You think you need to educate them? Relax. They know pretty well that agility brings transparency with it. Transparency, which will expose their uselessness. It will remove their CYA cushion. And you want to convince them? It’s not going to happen. They will do everything to stop you, starting with very popular “We tried baseball, and it didn’t work” approach (http://www.xprogramming.com/xpmag/jatBaseball.htm).
This is, I think, is the biggest road block that Agile – and anyone who wants to bring value – faces these days.
Regards,
Eugene Nizker,
Evident Point Software
Greatly enjoyed the article. The discussion of uncertainty and SD's dissimilarity to construction/manufacturing ties to one of my favorite books, The Laws of Software Development. Good points, well-written -- I have bookmarked and will re-read later, and share with others.
Having said that -- there are some points that I think need to be called out. I don't think that you necessarily mean to imply the following, but for what it's worth, I want to list them for the benefit of myself and others reading.
Nothing Fixed in Stone: the article casts a certain post-modern ambiance that says that everything is uncertain, even Agile itself. I think this is absolutely correct in terms of business needs and functionality. There are things, though, that ARE fixed in stone in any software development effort. To use old-fashioned requirements language, these are specifically business rules and constraints. If we have a rule that sales tax is 5%, and the system charges 6% and on the wrong items, it fails. If the system uses too much network bandwidth, it fails. And etc and etc.
As I said, I'm sure you are nodding your head in frustration and muttering, "But of course." The problem is that in our rush to be Agile, we may also be stupid, and without SOMETHING to help us not be stupid, such things may happen. And they can't always be specified by the Product Owner, or seen in the demo.
Some early Agile writings talked about "less programmers, but more experienced." I wonder if part of the reason for that was to be sure the team doesn't do anything stupid, based on the innate knowledge of the senior members of the team.
No Best Practices: You note that "best practices for a fee" is a common selling point from high-end consulting companies, and that the idea that what worked for Company A will automatically improve Company B is just silly. And of course, you're right.
What you don't call out specifically is that there ARE best practices in certain areas, mainly technology, and we ignore them at our peril. People are incredibly agile, projects need to be agile, businesses need to be agile ... but computers are almost 100% non-agile. We can't apply theories about methodology to these bits of silicon with fixed instructions in the CPU.
Examples -- coding queries a certain way to minimize network traffic and database churn. There are best practices for these, and they are best practices in almost every instance. They should be taught, and followed -- and if there are exceptions those should be taught too.
Again, I wonder about the role of senior programmers in this. There is a reason that peer code review is one of the most quality-increasing things you can do in a software organization.
::
Okay, those are my two big points. I'm sure you've thought of both of them, and if you'd had more space you would have made them yourselves. I just wanted to throw them on the table for discussion.
Thanks for reading.