Interface Vision Version 0.1

Introduction

Today is a bit of a milestone. We’ve been able to create an iPad/iPhone app using the Interface Vision Framework. The cool thing… The framework requires no coding to use. Ok, that isn’t exactly true but read on… (erichosick at interfacevision.com, twitter).

About the Video

The video shows a very simple OpenGl demo program running on an iPad. Nothing new there. The new thing is that everything about the program was created using configuration code: about 460 lines of it. Currently, this involves a lot of calls to constructors and the setting of properties. However, in the future, the configuration will be stored in json and serialization used to create instances (this is when the no coding part is realized).

Example Configuration

Here is an example configuration. In this case, it is the OpenGl shaders:

ISimpleClass shaderList = new AggregateArrayList {};
shaderList.actionInsert = new ProgramShaderNative {
  shadingScript = new Vision.Core.String {
    withString = @"
      attribute vec4 position;
      attribute vec4 color;
      varying vec4 colorVarying;
      uniform float translate;
      void main() {
        gl_Position = position;
        gl_Position.y += sin(translate) / 2.0;
        colorVarying = color;
      }"
  },
  shaderType = ShaderType.vertexShader
};
shaderList.actionInsert = new ProgramShaderNative {
  shadingScript = new Vision.Core.String {
    withString = @"
      varying lowp vec4 colorVarying;

      void main() {
        gl_FragColor = colorVarying;
      }"
  } ,
  shaderType = ShaderType.fragmentShader
};

Here is an example of the OpenGL “camera”:

ISimpleClass result = new Camera
  sceneToRender = new ProgramGlslNative {
    uniforms = uniformList,
    attributes = attributeList,
    shaders = shaderList
  } ,
  onCameraSetup = new GlClearColorNative {
    color = new Vec4f {
      r = 0.0f,
      g = 0.0f,
      b = 0.0f,
      a = 1.0f
    }
  },
  onSceneRenderBefore = new GlClearNative {
    clearValue = ClearBufferMask.colorBufferBit
  }
};

Future

There is a chicken and egg problem with all of this. Eventually, we hope to be able to configure behavior of Interface Vision within Interface Vision itself. However, for now, we have to resort to the Macintosh to finish out the framework and setup the configuration files.

Conclusion

For us, this is quite exciting. It is a good test of the framework. The fact it takes so few lines of configuration code to get a program up and running in OpenGL on an iPad with user interaction is a great test of the technology behind Interface Vision.

Posted in C#, NoMethods, framework, iPad, iPhone, interface vision | Leave a comment

You see Coding as a Loosing Game if You Focus on Testing

Introduction

Focusing on testing is like assuming we are going to lose the game and we only want to loose by a little bit: we assume there will be bugs – a negative approach.

The thing we should focus on is the User Experience (UX). Testing should be our second line of defense.

Focus on the Features and UX

Focusing on the UX, the behavior, the features is a positive approach. We focus on the wining game: delivering exactly what the stakeholders want (1).

  • Behavior Driven Development (BDD) assures we are implementing only what the stakeholders want (1). We are “testing” the features before we even think about testing code. This is our first line of defense.
  • Test Driven Development (TDD) provides the robustness and engineering – it is our second line of defense.

Use Both BDD and TDD

Behavior Driven Development, using a DSL like gherkin, provides the glue between the stakeholders (aka the UX) and the code. This glue drives our development and, following red/yellow/green/refactor, assures that every line of code written is directly related to implementing the behavior (aka the UX) (2).

BDD does not assure robustness and there may be overlooked edge cases that would require additional behavior (aka UX).

Test Driven Development, as our second line of defense, is where the engineering comes in assuring the software system is robust. Additional behavior may be discovered, such as what to do with errors, and TDD is a good way to discover such edge cases. TDD feeds back into BDD allowing for the discovery of additional behavior perhaps missed when mocking out that initial UX.

Conclusion

Don’t focus on testing your code, focus on implementing only the behavior asked for by the stakeholder.

Use BDD to assure that the minimum lines of code are written.

Use testing to assure robustness, good engineering and as a feedback loop to fill in missing behavior.

(1) – Business still needs to figure out what stakeholders want to assure minimal behavior (Minimal Viable Product). This process should be as painful as possible. The more pain, the less behavior. The less behavior, the less code. Less code means less bugs.

(2) – The ability to regression test our behavior is a huge benefit but pales in comparison to the benefits from assuring the minimum amount of code is being written.

(erichosick at interfacevision.com, twitter).

Posted in bdd, mvp | Tagged | Leave a comment

Feeling Dirty on Hacker News

I now feel dirty for trying to work with a startup on Hacker news. Or should I?

Why?

I ran into a Show HN post about an interesting startup called Tinyproj. I posted a short project on Tinyproj because I like to work with like minded people: entrepreneurs.

Then comes a post from a pseudonymous named Edward Case (http://news.ycombinator.com/item?id=3015677, http://www.betabeat.com/2011/09/19/why-80-percent-of-web-projects-are-total-bullshit-a-freelancers-rant/).

(Edit: Note the short project description was supposed to be private and Edward Case did not have permission to make it public as was done in their blog)

I’m Not Anonymous

I have no reason to be anonymous. My name is Eric Hosick. I’ve been programming since I was 13. I’ve written hundreds of thousands of lines of code. I’ve lectured at a college for a few years in IT and BIS. I’ve started a few companies: even a few offshore. I’ve been successful and I’ve failed: both quite a few times now.

So, when someone, anonymously, says something like this:

“I’m sure I’m not the only programmer that can sniff out a fake nerd.” – Edward Case

And tries to oust me call me out as that fake nerd. Well. Ya. You’ve got a lot to learn about people on Hacker News. Generally, we know our shit.

The 1000 Char Limit

I was limited to 1000 characters on Tinyproj. I did have more detailed requirements. The 1000 char limit was a pain, I have to say, and I was going to quickly give up on Tinyproj. But I am going to have to give cudos to Tinyproj for getting out that Minimal Viable Product. Good on you! It was the right move. So, I stuck in there.

I clipped off most of the requirements. I knew anyone really interested would just ask for more detail.

And it was worth it, because the entrepreneur has been really helpful.

Conclusion

Thanks for reading.

If you are interested in working with someone who is and respects programmers, please do drop a line (erichosick at interfacevision.com, twitter).

I think I have some rather amazing stuff coming down the pipeline.

Posted in hacking, mvp, rant | 9 Comments

Developers: Give Each Other a Fighting Chance

Introduction

Figuring out an API can be difficult. Using one that is fraught with bugs and bad error messages is almost impossible.

My Plead – Give Each Other a Fighting Chance

Development is hard enough without having APIs fraught with bugs and no good error messages. It seems to me, that over the years, APIs and frameworks aren’t getting better. Instead, they are becoming more fragile than ever before. There are probably a lot of reasons for this but I think one of the main reasons is a misunderstanding of what software development really is.

Quick Point – Seeing Software Development as Automation of a System

Software Development is no more than the automation/simulation of systems (that is a strong statement to make so take a second to think about it.). The development process takes a system that is/can be done manually and automates that system via software run on a computing device.

A real world system, like manufacturing a cell phone, has an optimal process: the process to follow when there are no problems in production. However, in every system, there are situations that occur which are not optimal: parts not shipped on time, power goes out, machines lose their calibration, cost of material goes up, etc.

As such, not only is the optimal process of a system written down, but also actions to take when events occur within a system that are non-optimal.

The Solution – Software Developers must Consider non-optimal Aspects of the System

When automating a system, as engineers, we have to take into account all of the aspects of the system we are automating: not just the optimal outcomes. Further, we have to view the computing device itself, and the software running on it, as another part of the system being automated. That means, unexpected outcomes, such as out of memory errors, must now also be considered within that system (even at the business level #1).

So, when writing an API, make sure to put as much, if not more, thought into the non-optimal aspects of the system. Further, provide adequate “error handling” or “error messages” so that the users of the API are able to act accordingly.

A good API considers both the expected and unexpected events within the system being automated.

The reason why I put “error handling” and “error message” in quotes is that, in a system, there is no such thing as an “error” as such #2. There are unexpected outcomes that require an alternate process. The only reason why we call them errors in software development is because we, as software developers, have failed to understand the purpose of software development: to automate systems.

Really, if you are going to write an API, you have an obligation as an engineer to consider all aspects of a system you are automating and provide the right exception and/or information allowing users of your API to make the correct business decisions.

Conclusion

The APIs of today need to be more developer friendly. This can be achieved by software developers realizing that the software they write must automate both the optimal and non-optimal processes within the system: including those non-optimal processes injected into the system because it is now using said computing device.

Developers really need to start providing APIs that are not fragile and provide adequate information when “errors” occur. This give the users of their APIs a fighting chance in using the API successfully.

Give your fellow/fellowet developers a chance to be successful in their development efforts.

The Story – Why This Post

I was trying to use a console based API (I will not flame the API) and was getting an error message “File not found”. That would be a fine error message except for the part where the command line options required four different files. I did try to pass each one separately, and in each case the “File not found” error did not occur: replaced by the error “Missing option xyz”. There was also a debug option which was also of no help.

What good, in this case, is the error message “File not found”? What could I learn from it? Nothing… In fact, I spent more time trying to figure out what was wrong than I spent writing this post.

The bad part is that this API was created by developers to be used by developers. So, the question becomes…

Do developers actually care about helping other developers become successful?

#1 - As an example, I may want to restart a process if it starts taking up too much memory or I might want to start a new server instance running in my cloud computing environment. This is a business decision made by the product owner.

#2 - I realize that there are edge cases that are difficult to find. I also know that no systems are closed, and as such it is not practical to cover all edge cases. However, knowing those edge cases and not accounting for them should not be called an error. It should be called an incomplete API and a failure to automate that system.

Posted in API, Development, framework, systems | Tagged , , , | 2 Comments

How to use BDD to discover value-add for your startup

Introduction

I’ve seen chatter on Hacker News about how BDD adds no value to a startup (this post here in response to this).

This blog post will:

  • clear up misunderstandings of BDD
  • provide reasons why your startup should use BDD
  • show how BDD helps you focus on value-add

What BDD is NOT!

BDD is not only about testing or test coverage. In fact, BDD is such a mind boggling amazing improvement to software engineering that regression testing and testing are merely a measly nice to have side affect of BDD. It is not the reason why you do BDD.

BDD is not TDD. They can overlap but they are as conceptually as different as structured programming and object-oriented programming.

BDD, FDD, BVADD, ATDD – It’s all the same

Behavior Driven Development (BDD) could also be called:

  • Feature Driven Development (FDD)
  • Business Value Add Driven Development (BVADD)
  • Acceptance Test Driven Development (ATDD)
  • Story Test Driven Development

What is BDD/FDD/BVADD?

Behavior driven development drives the development of code from behavior defined through scenarios.

You don’t drive development by chatting about it (CDD), by having meetings on it, by thinking how to test your system (TDD). You simply take the behavior/features of your system and build software against that.

What are scenarios?

A scenario is a description of how your system will add value for both your business and your customer. BDD has a “standard” way of describing these scenarios known as Gherkin. By standard, I mean that once you’ve described that value add in Gherkin you can implement it in Rails, PHP, C#, Ruby, Java, etc using Cucumber, Behat and SpecFlow.

How do I find these “value add” scenarios?

BDD doesn’t find that value-add. That is up to the visionaries of the startup. However, it does allow you to add value to your company immediately by allowing you to start describing your value-add in that standard way.

The best place to start is with mocking up your system. You can use paper and pencil or a tool like Balsamiq Mockups. Once you have that, you can find the behavior (features) of your vision within the mockups.

Finding that value-add is basically done by:

  • Mocking up the features
  • Write about and discuss them using in Gherkin
  • Chose which ones add the most value.
  • Implement the feature

That fact is:

If you can’t clearly describe your value-add in a hand full of features and scenarios then you shouldn’t even begin coding.

And if you do accomplish that amazing feat you are almost half-way done with your product. No work was lost because you can now take those scenarios and implement them!

Now, and only now, should you start coding!

So BDD can help me focus on the value add of my company?

Yes! Yes! Yes!

If you spend all that time chatting about your vision to a lot of people that time is lost.

If you spend all of your time chatting about your vision to other people and mocking it out and write scenarios describing that vision then it is a great start.

If you can do all that and find that sweet spot of value that you want to deliver your customer… Well then,  you can hand that to a developer (or yourself) and know they are only developing EXACTLY what was asked for.

What this means is:

It is not possible for someone to program or spend time programming any more or less than exactly what you need to get that value-add to the market as fast as possible.

Wait! So BDD can also help describe my vision to developers?

Oh ya! I almost forgot to mention that aspect of BDD.

If you thought it was hard getting your vision understood by those who you want to invest/accept/embrace your vision then it is just that much harder to get developers to understand and stick to that vision.

Not that developers can’t grasp you vision. In fact, it is just the opposite and they might start trying to improve on it for you. That can also have it’s advantages and dis-advantages.

BDD help you get that vision across to developers and helps them stick to your vision.

Advantages are numerous

  • You can’t break behavior so your system can’t break
  • Easy to change engineering direction
  • East to move to a new technology or implement in multiple technologies
  • Can regression test code and verify requirements
  • Can be used as a bridge between the Product Owner and Team
  • Heavy usage of off the shelf DSLs (Domain Specific Languages) can lead to Scenarios that require ZERO lines of test code to be written (Webrat and Pickle to name a few)
  • Assures that only what you ask for is being coded
  • Can verify that requirements are being met. There is an actual connection between a requirement and code.

Counter Arguments for using BDD at a startup

Here are some quotes from a few of the posts on Hacker News.

  • Argument: “BDD assumes you know the problem and are coding to create a solution. In startups, however, you do not know the problem.”
  • Counter argument Question: If you don’t know the problem then why are you even coding?
  • Argument: “Startups are all about providing value — not flexibility, not bug-free code”
  • Counter argument: BDD is not only about “bug-free” code or flexibility. It is mostly about helping to provide that minimal viable product – that value.
  • Argument: “So [BDD] a waste of time.”
  • Counter argument: Actually, there can be no time wasted in BDD (unless you think figuring out that best value add and MVP are a waste of time). It is very possible to write ZERO lines of test code using BDD. There are off the shelf DSLs out there that have done all that for you already.
Posted in agile, bdd | Tagged , , , , , , , , , , | 4 Comments

MonoDevelop With A Custom Version of Mono on the Macintosh

Introduction

This blog post will tell you how to develop using MonoDevelop with your own custom version of C# Mono.

Status and Code Completion

Currently, everything seems to work and I am able to compile programs using my own version of Mono in MonoDevelop. Code completion using a custom compiled Mono seems to be intermittent. I’ve seen code completion include new properties for the object class but many times it doesn’t.

What you Will Need to run MonoDevelop

You will need to install mono on your mac if you don’t already have it. Be sure to install the correct binary based on your mac. Intel, PowerPC or Universal. You can get mono here: http://www.go-mono.com/mono-downloads/download.html.

Of course, you need to install MonoDeveop. You can get MonoDevelop here: http://monodevelop.com/Download.

Compile Your Own Version of Mono

Get the mono source code here – http://ftp.novell.com/pub/mono/sources-stable/. The specific file is http://ftp.novell.com/pub/mono/sources/mono/mono-2.8.1.tar.bz2 if you are using version 2.8.1

Extract this into a directory where you will be working on the base mono code. I like to use ~/projects/mono/mono-2.8.1.

Setup Where Mono Will Compile To

You can read here on how to compile mono for the Macintosh – http://www.mono-project.com/Compiling_Mono_on_OSX

We will place our version of mono where MonoDevelop also looks for the unmodified version of Mono.

Create a directory where your mono version will be installed:

$ sudo mkdir /Library/Frameworks/Mono.framework/Versions/2.8.1-mine

You will need to change the owner to get make install to work.

$ sudo chown monoUser /Library/Frameworks/Mono.framework/Versions/2.8.1-mine

We can now configure, make and install our own version of mono.

$ cd ~/projects/mono/mono-2.8.1
$ ./configure –prefix=/Library/Frameworks/Mono.framework/Versions/2.8.1-mine/ –with-blib=embedded –enable-nls=no
$ make
$ make install

To verify, change to your new install:

$ cd /Library/Frameworks/Mono.framework/Versions/2.8.1-mine/bin
$ ./mono -V

and you should see that your version of mono was compiled today:

Mono JIT compiler version 2.8.1 (tarball Sun Dec  5 13:04:58 ICT 2010)
Copyright (C) 2002-2010 Novell, Inc and Contributors. www.mono-project.com

NOTE: The mono package comes with everything you need to make and install mono. Make sure you have the correct binary type (Intel, PowerPC or Universal). All libraries need to be compiled using the same binary type. The mono package has done this for you. If you use something like Macports you may end up with a library using the wrong binary type giving you the errors described on the bottom of  http://www.mono-project.com/Compiling_Mono_on_OSX.

Using Your Version of Mono

Run MonoDevelop and go to MonoDevelop -> Preferences. Select .NET Runtimes and your version will be there automatically! You just need to set it as the default library (this doesn’t seem to stick at the time of the writing of this document).

If you have a project open you can go to Project -> Active Runtime and see your version listed there. Select this version and you will be using your version of the .NET runtime.

What Next?

Well, go to ~/projects/mono/mono-2.8.1/mcs/class/ or /Users/erichosick/projects/mono/mono-2.8.1/mcs/class/corlib/System if you want to start with Object.cs and start hacking!

Amazement and Awe

I just want to say that after working with proprietary system for most of my life, I am totally inspired and awed by the ability to take something as big as Mono and simply hack at the root of the system (Object.cs). I really want to thank everyone who has spent their time adding to this amazing product! Thank you!

Also special thanks to Michael Hutchinson for helping me with this.

Posted in C#, computer language, hacking, mono Runtime, monoDevelop | Tagged , , , , | Leave a comment

Being a Product Owner – The Achilles’ heal of Agile

I often consider the product owner to be the hardest hat to ware in Agile. You are the Achilles’ heel of Agile. A few of the things your job requires are:

  • Getting consensus from all stakeholders: that vision
  • Giving that Vision to your Team
  • Planning and prune the backlog (Project Management) for the next iteration.

You are the voice of reason. You work with everyone involved to find that minimal viable product. You work with sales people, customers, engineers, designers, marketing and so on.

Along with that you have to do project management. Unlike a project manager, you don’t need to actually plan how work is done. You also don’t have to be responsible for estimates. In Agile, those tasks fall onto the team. However, you do need to keep the backlog full of work.

This is no easy task. It requires a lot of project planning. It requires keeping your eye on where development is going and constantly validating what you are providing with what the stakeholders want.

A good Agile shop can deliver product weekly or even daily (at East Agile we deliver daily). This means, as a product owner, you need to be able to approve work done almost every day. A single pair can complete one or more stories that may take anywhere from 4 to 20 minutes to accept. The means a full team of 4 pairs could eat up 80 minutes a day in simply reviewing what has been delivered.

You might think that Agile is creating a lot of work for you. Nope. In the long run, it isn’t any more work than any other process. Agile can simply deliver more product in a shorter amount of time. As the product owner, you still need to take the time approve that work and validate it with the stakeholders and customers.

And once you’ve done that for the day, you will need to get ready for the next iteration planning meeting: finding that sweet spot of work for the next iteration.

There is a huge reward for this however. You are able to provide something to your customers weekly if not daily. And you are assured that you receive exactly what you ask for. You write the specifications and a good Agile shop using BDD (see Behavior Driven Development – An Invaluable Tool) will deliver that exact specification.

Of course, if you mess up it can be devastating. Weeks or months worth of work can be lost. Which is why the Product Owner is the Achilles’ heel of Agile.

Are you ready?

Posted in agile, agile management, product owner | Leave a comment

Interface Vision and Behavior Driven Development (BDD)

Where Interface Vision Was Before

We are a few years into the code base for Interface Vision. An executive decision was made to rewrite the entire system using BDD.

This isn’t exactly an easy decision because there are many hundreds of thousands of lines of code. Over the years, the code has been re-written as we discovered mistakes in our original approach to engineering Interface Vision. However, the current version is architecturally strong.

Of course, a lot of the tricky stuff has been solved and the re-write will not be as difficult as the original so I don’t see it taking two years.

It Is Well Worth It

I’ve just finished my first big step of re-writing Interface Vision using BDD and all I can say is that it is amazing! During this 6 hour session I did not even one time ask myself if I had introduced any bugs. Not one time did I have to debug the code.

I had one mistake in the Gherkin due to an upper-case/lower-case mistake. Other than that, I am confident that my code base is 100% covered.

And it is a really nice feeling.

Feeling of Oneness

After programming for decades and even using TDD I never felt confident that I wasn’t breaking my behavior: I wasn’t breaking how the system worked.

For the first time ever, I don’t have a single worry in my head that I’ve made a mistake. I don’t have to worry that something isn’t right. I know that within all that code I’ve just added, there will be no horrible debug session waiting for me. I now have a feeling of Oneness with programming. I am not fighting programming anymore! It is really relaxing.

I Hate Debugging

I can not even start to describe how much I hate debugging. I’ve been doing it since I was 14 when I wrote my first program. I’ve been doing it up until recently. Now I know I will NEVER have to debug again.

The worst part about debugging is that it really slows me down. Not because it is more difficult than programing or that I’m not good at it. It slows me down because I always procrastinate when I know I have to start debugging something. Sometimes I’ll stop working on something for days because of it.

BDD Is Here To Stay

As I’ve said before, and if I haven’t then I guess I’ll say it now, BDD is the biggest advancement in 20 years both in terms of the concept and tools that implement it. BDD, conceptually, may have been here for a while. However, it is now so easy to drive your development using it… Well there is no reason not to do it.

Conclusion

I will never have to debug again! I hope. :-)

Posted in bdd, interface vision | Leave a comment

Running an Agile Company – Keep An Agile Master Around!

COO Of East Agile

Recently I was made the COO of East Agile. What is interesting about Agile is that you can fit most of the concepts on a few pieces of paper: the agile rules as you will. It is, or should be, really easy.

I’ve had a chance to observe some of the companies that practice Agile on a large scale (involving 50 to 100 employees). As advanced as they were at Agile, I was surprised to see that they only apply a small part of Agile to their entire process. They were doing a great job but I saw a lot of room for improvement.

I think I could say that East Agile is ahead of most people in the “Agile” game. But it isn’t easy staying agile. In fact, it is really hard to do. Below are some examples why.

Oh, but if you haven’t read it yet, please see my blog on Agile branding.

An Agile Master Is Always Needed

I was lucky enough to be trained by Mike Cohn and his classes on being a Scrum Master and Estimation (I highly recommend his classes on estimation). I though that being an Agile Master would require some training of the Team initially. However, what I have found is that you have to continually observe and make suggestions on how to apply Agile itself.

Planning Poker Example

A quick example is the Estimation process and planning poker. I’ve chatted with our different teams about Estimation and the dangers of contamination when estimation. Contamination is when one person in the team (or a product owner or stake holder) provides an estimate before other people have had a chance to think about the estimate themselves. This taints the estimate.

Often times, team members seem to “get into” the estimation process and yell out estimates during the Iteration Planning meeting. So, from time to time, I have to remind people to not “yell out the estimate”. Of course, eventually I pull out the poker playing cards to stop this from happening.

Initially, it feels a little funny to use cards to do planning. However, it becomes obvious very quickly that estimation gets out of hand without them.

Product Owner and the Team

Sometimes I will see the team working on a story that was not estimated. When asked why, the say “Oh, the product owner said we don’t have to estimate.” Ahhh. Ummm. Another time, product owners have said we don’t need to do BDD or TDD on this because we just need to “get it out”.

Conclusion

If you want to run a company that uses Agile you are going to need an Agile Master. That Agile Master needs to stay on their toes at all times. Of course, this means that their training is going to come in almost all the time. The most important part of that training being communication and allowing teams to form naturally. However, at the same time remembering that you need to keep people on the Agile path.

Posted in Uncategorized | Leave a comment

Out With the Branding – In With Agile Terms

Branding and Agile

I wanted to quickly talk about agile and branding.

Instead of using branded names like XP and Scrum, I thought I would try to generalize terms coined by these great systems. I took the advice of Mike Cohn on this. So, for example, Scrum Master at East Agile is Agile Master. Daily Scrum is the Daily Planning Meeting. A sprint is an Iteration, etc.

I did this because I wanted to focus on what makes Agile great – The Agile tools. Agile itself is a collection of the best of best known practices. In fact, there is nothing “new” about agile per-se other than Agile brought together this best of the best known practices.

Here is a list of why I removed the branding from Agile:

  • Generalizing the terms made it easier for me to iteratively implement and introduce new Agile processes.
  • Misconceptions or bad experiences with some of the brand made people uncomfortable with implementing them.
  • Can pick and choose from different “brands” like XP, Crystal and Scrum without confusion.

Credit Where Credit is Due

I do want to point out that I have great respect for those who created the Agile Manifesto. In no way do I want lesson their contribution to software engineering and the community as a whole.

Conclusion

If you are going to apply Agile in your company, try and generalize terms so you can pull the best from each brand. Implement Agile tools and processes iteratively. Don’t allow any “bad experiences” with Agile hold you back.

Remember to pay tribute to the original twelve.

Posted in agile, agile tools | Tagged , , , , , | Leave a comment