Lots of experts will tell you how you should be running your business, even when they don't know anything about your business. You know far better than any experts what the real issues are that your business faces. I can't tell you how to run your business. Nobody can. Only you can do that.
What I can tell you, though, is what your competition is up to: they are changing their business processes and developing and using IT in new ways to increase efficiency, reduce risks, maximize return on investment, and take your market share away from you.
This book tells you how they are doing it. It reveals the specific techniques that your most successful competitors are applying right now.
How you respond to that is up to you.
The business world is more competitive than ever. Your competitors are working harder than ever to grab your market share. The rules have changed. Gone are the days when you could say "there is room for us all". Today's top players are looking to completely dominate their markets. In short, to put you out of business.
How are your competitors working to steal your market share from you? By more efficiently developing IT and business processes together, to reshape and dominate markets. In short, your competition is getting more business value for less effort than you are.
That's all well and good, but how do you go about doing that?
We all know that businesses these days have to be light on their feet: to react and adapt quickly, seize opportunities, and become more and more efficient.
There is lots of talk in business circles about employee empowerment, business process improvement, learning organizations, and so on. As good as these ideas sound, they are often high on philosophy and low on details of the actual principles and practices that get you there.
At the same time, there has been a lot of talk in recent years in IT circles about getting better, lighter, faster. Unfortunately, a lot of the early evangelists talked mainly about philosophy, and told you to let go of control of your business, live on the edge of chaos, and wait for the magic to happen. Well, I don't know about you, but I am not happy to hand over the future of my business to "emergent order" and other chaotic principles. We are not looking to resurrect the Wild West.
Likewise, your competitors view much of the philosophy and hype with a healthy skepticism. Instead, they have turned to concrete principles and practices that give them the edge.
The job of top management isn't to spout philosophy from on high, but to commit to a firm set of principles and practices to steer the business. It is vital to have the right principle and practices. Outdated principles and practices simply hold your business back. Today’s most successful companies have dropped old habits and taken on board the values, principles, and practices of Agile software development to increase effectiveness and beat their competition.
Agile software development hasn’t come from some ivory tower. It is not based on abstract theory. Businesses have had enough of theories. Agile doesn't give a damn about what sounds good; it focuses only on what has been proven to work in practice.
Agile emerged from studying thousands of businesses in the real world, to see what worked and what didn't. The things that worked were folded in, and those that didn't were thrown away.
Agile software development started officially in Snowbird, Utah, in February 2001. Before that, there were many different groups each promoting similar ideas, each grounded in what works in practice. In Snowbird, seventeen such grounded experts got together to come up with an Agile Manifesto to declare their common beliefs, and ultimately to form an Agile Alliance around which Agile experts and practitioners could group and share experience.
The Agile Manifesto is not a unified Agile process. Each of the members of the Agile Alliance still promotes their own Agile way of working (such as Extreme Programming, Scrum, DSDM, Crystal, and so on). Instead, the Agile Manifesto declares four values which all the signatories share:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The Agile approach prefers the things on the left of each of the four points (e.g. individuals and interactions) whereas more traditional approaches tend to prefer the things on the right (e.g. processes and tools). The main argument from the Agile Alliance is that although the things on the right sound good in theory it is the things on the left that are more helpful in practice
To rephrase this in a paragraph:
Processes and tools can only help up to a point; at the end of the day, project success mostly comes down to the quality of the people on the project and how effectively they work together as a team. Documentation can support such a team in achieving its project goals, but the focus should remain on delivering working software, without being distracted by unnecessary bureaucracy. To find out what that software needs to do, the team can’t expect the customer to have a completely clear understanding up-front, but should keep working closely with customers to uncover those needs together. Over time, those customer needs will change. For the software to remain valuable to the customer, it needs to evolve continually to support those changing needs, and often in unpredictable ways.
In the months following the original declaration, the same seventeen folks elaborated the four values of the Agile Manifesto with twelve common Principles in which they also believe:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity--the art of maximizing the amount of work not done--is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
We will expand on each of these twelve Agile principles in later chapters.
Value and principles are all well and good. In my experience, though, what companies are really looking for are specific practices they can follow on a daily basis.
Perhaps surprisingly, the Agile Manifesto doesn’t define any practices at all; it stops at the principles on which those practices should be based.
The Agile Alliance leaves recommending specific practices to the various Agile processes. There are many existing Agile process, each created and promoted by different Agile experts. The most prominent Agile processes are Extreme Programming, Feature Driven Development, Scrum, DSDM, Crystal, and Adaptive System Development. We will dig into each of these Agile processes, and their specific practices, later in the book.
The owners of the various Agile processes - by signing up to the Agile Alliance - have committed that their practices adhere to the values and principles of the Agile Manifesto.
Going Agile, then, means buying into the values and principles from the Agile Manifesto, and then taking on board specific practices that live up to them.
Deciding on which are the right practices for you isn’t easy. Should you sign up to a single Agile process and if so, which one? Should you combine ideas from several of the Agile processes or just stay with one of them? Should you come up with your own practices or stick rigidly with the established ones?
These are hard questions, and this book will give you guidance.
Always remember, though, that it is the Agile principles that count. You have probably heard people talk before about best practices. What really matters, though, is best principles, to which the practices should adhere.
If you just look only at the Agile practices, it becomes too tempting to drop those that look hard and painful for you to implement. Often, companies will only take on board the practices that are easiest for them to do - that fit into their current culture without too much effort. The danger is that they end up dropping the very things that would help them the most.
By looking first at the principles, and not just the practices, you can better grasp what you are gaining from Agile, and what you lose by dropping various parts of it.
If there is a single message from this book is it this: As long as you stick to the Agile principles, you won't go wrong. You can then change the practices all you want, to better fit the specific needs of your own organization, and still get the benefits.
Agile, then, isn’t merely something you do, but something you become. It is not just another set a practices to be followed slavishly, but a mentality that completely changes your outlook. The Agile principles help you learn to think agile, not just act agile.
In the remainder of this book, we will dig into each of the Agile principles one by one, helping you understand them deeply, and uncovering why the most successful companies have committed to them wholeheartedly.
Along with the Agile principles, we will explore established Agile practices that satisfy those principles well and have proven themselves time and again in real world projects. You are free to adopt those proven Agile practices directly, or adapt them (based on your own specific circumstances, and sticking to the Agile principles) into what will be best practices for you and your own organization.
In chapter XXX, the whole of the book is pulled together into a specific Agile process that you can follow as written. Impatient readers might want to jump ahead to this chapter.
The process described in chapter XXX will get you started. Be careful though: no process, Agile or otherwise, can fit all circumstances. To really beat your competition, you need the process to be optimal for your own situation.
After working for a while with the process as described, come back to the earlier chapters to get a deeper understanding of how and why it all works.
When you have enough experience, you can keep on improving the process, to make your project teams continually more productive, and your organization continually more effective, in today’s highly competitive business market.