Basics

Principles Behind the Agile Manifesto – Part 1: Satisfaction, Changes and Frequency

Zan The Basics , ,

Hello everyone! I’m back with another installment in my Back to Basics series. If this is your first look at the Back to Basics posts, or want a general overview of the Agile Manifesto and its principles, please check this post. This time, I’ll be talking about the first three principles listed, which will likely make this a series of four posts, covering a few principles each time.

Customer Satisfaction

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Well that’s a good way to start. We’ve already identified the most important thing, no matter what you’re making, building, or doing: Our highest priority is to satisfy the customer.  It doesn’t matter what industry you’re in, what your job title is, or who you report to. Every job, position, project or undertaking has a purpose behind it, and generally that purpose is to help someone. That someone is your customer. If your highest priority isn’t to satisfy that person, someone else will. Of course this principle also goes into how we can provide satisfaction: early and continuous delivery of value. Even if you’re not in software, this can still apply. Instead of holding all the value until you have a “complete product”, deliver working pieces of the product as soon as possible to ensure the customer is on the road towards satisfaction, then continue to deliver to keep that relationship positive.

Change is Power

Welcome changing requirements, even late in  development. Agile processes harness change for  the customer’s competitive advantage.

This ties right back into the first principle. If we want to satisfy our customer, then if the customer needs something to change, we must make adjustments. Regardless of how good a plan one has, or how long you’ve followed it, the plan is not valuable if it does not represent true value in the present. If your requirements seem to be fine, but then a sinkhole opens in front of you, are you going to change your plan, or jump right into the hole?  This seems simple, but changing momentum is hard, and having the courage to do so is even harder! Those who can harness change, however, will find greater satisfaction with the product, knowing that the best product possible was delivered.

High Frequency

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Once again, we’re tying right back into principle numero uno here.  Deliver early. Deliver often. The shorter the time between delivery points, the more likely you will be to know what your customer needs. If you’re on the right track, they’ll be happy. If you’re not, you’ll change, and then they’ll be happy.  Some Agile teams deliver value so often, they are continuously integrating new features, taking even less than one day to complete and deliver a feature!

In Summary

The first 3 principles of the Agile Manifesto focus on delivering value and increasing customer satisfaction. By delivering early, often and frequently, and by allowing requirements to change whenever it is needed, we can ensure we deliver the most valuable product to our customers, thereby increasing the customers’ satisfaction! Happy customers make for happy workers!

Thanks for reading, more will be on the way soon. Please feel free to leave comments below!

Advertisement

Customer Collaboration: No Magic 8 Balls Here? Agile Manifesto Value #3

Zan The Basics , ,

Welcome back to my continuing Back to Basics series. This time I’ll be covering Customer Collaboration: Agile Manifesto Value #3. If this is your first look at the Back to Basics posts, or want a general overview of the Agile Manifesto and its principles, please check this post.

Nostradamus Doesn’t Work Here

There is a shortage of functioning crystal balls in the world, and most fortune tellers are more concerned with your love line and your lucky numbers, not telling you what software will work for you once it’s built.  When we talk about customer collaboration, we have to look once again at how projects are traditionally made. With traditional software projects, it turns out you needed all of that comprehensive documentation from value number 2, because how else could you make a proposal to earn the contract for the project?  Contracts needed to spell out exactly what you wanted, because you were going to give it to a company and they would take it, go away for a while, make some magic and poof, its software!  I hope you and Doc Brown came back from the future knowing exactly what you need, otherwise chances are what you’ve asked for isn’t going to end up being what you need, and that’s assuming the magic men making your software are able to return exactly what you asked for with no issues.

With Agile, we value not only our own interactions like back in value 1, but interaction with the people who will be using what is being produced.  We not only want to know what they think they want in the beginning, but we want to work hand in hand with users as often as possible.  As we create, we constantly want customers to work with us, refining their vision of what will be useful based on what’s been created. It may so happen that with a few small changes, the customer may determine they may only need a portion of what they originally thought to meet their goals. Seems wasteful on both parties to continue at that point, doesn’t it? It may also happen that the customers are completely wrong about what they thought they wanted, or a major change in their industry completely invalidates their plans.  Once again, without collaboration, they would receive (and pay for!) something completely worthless.

New Types of Contracts

We obviously still value contracts. After all, from the developer point of view, we want to know we’ll get paid, and how much.  However, we now value new types of contracts, which allow flexibility and collaboration to ensure useful software is created and time is used efficiently. Contracts based on time and materials, flexible contracts with out clauses, and contacts based on incremental delivery are just some of the new forms of contracts that have come out of the Agile movement.

Summing It Up

Working software is only half the battle. Working software that doesn’t do what’s needed is less than useless, it is costly and wasteful. Comprehensive contacts are far more likely to produce software that doesn’t do what’s needed.

Working Software: Much Better Than Software In Paperwork. Agile Manifesto Value #2

Zan The Basics , ,

Welcome back to my continuing Back to Basics series. This time I’ll be covering Working Software: Agile Manifesto Value #2. If this is your first look at the Back to Basics posts, or want a general overview of the Agile Manifesto and its principles, please check this post.

Working Software: Just As Simple As It Sounds

In Agile, we value working software. That sounds like a no-brainer, right?  Who doesn’t value working software? Taken out of context, this doesn’t really tell us much. So lets contextualize it. If we value working software, then we infer that we do not value software that doesn’t work. Taken to its logical conclusion, software is only valuable once it works, or in other words, once it can be used.

Now to the layperson, you might be tempted to take that to mean that software is only valuable once every single feature is complete. After all, how can you use software that’s not complete?  Let’s examine that. Take your favorite piece of software. For our example, let take a word processor like Microsoft Word.  Microsoft Word has loads and loads of features, some you might not even know existed (for example, Word can convert a table to a graph without any external software. Who needs Excel?). How many of those features do you actually use when you’re writing a document? Could Word be valuable, even if all you could do is type words, or type words and print? Sure it could, that’s why Notepad exists.

So what is “Non-Working” Software? Well, that’s a little bit harder of a concept. After all, code will generally run when executed, and a database exists once you create it, right? Here’s the “Tree Falling in the Forest” question for that: If a database exists, but nothing is connected to it, is it really working? What is more valuable, one table connected to an input form, or 100 tables connected to each other and nothing else?  All this is not even getting into testing, ensuring that your “working software” actually works like you think it should.

Comprehensive Documentation

Beyond the context I talked about above, the Agile Manifesto contextualizes this value in contrast to “Comprehensive Documentation”.  Let’s examine why.

It’s important to remember that the Agile Manifesto was not created in a bubble. At first, software projects were treated like every other kind of project: write out all the requirements into “Comprehensive Documentation”, and then complete each stage of creation as a discreet step, for example design then develop then test. There was only one problem with this. It didn’t work. Development took so much time to match the features, and when it couldn’t the documentation needed to be updated. Testing got pushed so far out, there was no time to actually develop fixes for bugs. Even if you did complete all the features you documented, there’s no guarantee what you created is useful, since you took a year to finish everything. The world can change in a blink of an eye, and while you were away building all that comprehensive documentation, Google came by and already did it faster and better.

Projects do not need to be documented up front. Some projects don’t need more documentation then commented code and a list of user stories. Agile says its always better to create what you need now than what you think you need someday, and that includes documentation.

Summing It Up

With Agile, we value something tangible that works, as opposed to a theory that might work. Even if your “working software” doesn’t end up being the real solution, the sooner you find out, the better.  Anything that is not real is still imagination, and its really hard to use imaginary software.

Like what I’m saying? Don’t like it at all? Leave me a (working) comment below!

Indviduals And Interactions: You Mean I Have To Talk To People? Agile Manifesto Value #1

Zan The Basics , ,

Welcome everyone to the first in my Back to Basics series: Individuals and Interactions: Agile Manifesto Value #1. If this is your first look at the Back to Basics posts, or want a general overview of the Agile Manifesto and its principles, please check this post.

Individuals

It’s easy to look at a company/department/team as a box or machine. You input the instructions and materials(most often money) and out comes a product. Of course, this is not really the case.  What ever this group is, it is made up of individuals. With Agile, we value each individual for all of their real and potential contributions. Without the individuals, the group does not exist, and nothing can happen.  Humans are not resources, and shouldn’t be treated as such. However, individuals working alone can only get you so far, which leads to…

Interactions

Interactions are fun. Much like chemical reactions, we take individuals, and mix them together. The results can be mundane, or they can be amazing, or even explosive!  This stems from a single idea: communication is the key to success. The frequency and value of interactions and communication between individuals determines just how good any output from said individuals will be. If your people don’t interact, then no reactions can take place. If people do interact, then as with chemistry, the whole can become much more than only the sum of its parts.

Interaction Killers: Processes, Tools and the Oxymoron of “Agile Processes”

So if we value the interaction of individuals, what does that have to do with processes and tools, and why do we value them less? First off, let’s be clear: there is still value in processes, and there is still value in tools.  However, when processes and tools interfere with individuals interacting, the processes and tools lose their value.  Let’s take some concrete examples. Jira, RallyOn and the like are great tools. Many an Agile team have used them to great success. However, if a team were to allow these tools to interfere with interactions, say by using task tracking in place of speaking face to face, the tool looses its value. Strictly defined processes, the cornerstone of the Waterfall SDLC, can destroy interaction, as we continue to act on others instead of interacting together.

So what is an Agile Process? I’ve seen it stated that there are no “Agile Processes”, only Agile teams and the environment for the Agile team to be Agile. I believe that teams will come up with their own processes internally, and if done with an Agile mindset, these processes will define how that team is Agile. There is no one size fits all process that will make a team Agile. Even Scrum, the most popular incarnation of Agile in software, is just a framework. It’s a restrictive framework which enforces the values of Agile (including Individuals and Interactions), but the processes the team comes up with to be Agile are their own.

Summing it up

Agile values the interactions of individuals over anything that will cause interactions to be interfered with.  There are great tools and processes out there, but if they interfere with people working together as a team and interacting, they can be damaging.

Want to interact with me? I welcome your feedback. Leave me a comment!