How to use Agile Correctly

September 27th, 2016 | Posted by Vidya Vrat in Agile-Scrum | ALM | Best Practices - (1 Comments)

Abstract

This article uncovers the various aspects of Agile software development technique and Scrum framework to enable an Agile team/ team member to understand various issues any software development team sails through and how to come over those challenges.

Where Did Agile Come from?

In 1970, Dr. Winston Royce presented a paper entitled “Managing the Development of Large Software Systems” which criticized sequential development.

He asserted that software should not be developed like an automobile on an assembly line, in which each piece is added in sequential phases. In such sequential phases, every phase of the project must be completed before the next phase can begin. Dr. Royce recommended against the phase based approach in which developers first gather all of a project’s requirements, then complete all of its architecture and design, then write all of the code, and so on. Royce specifically objected to this approach due to the lack of communication between the specialized groups that complete each phase of work.

Developing a Solution for Customer

Any software project starts from Gathering Requirements phase and many times what is developed is not exactly what end user wanted, and many software projects fail during implementation.

Value Delivery Impediments

In today’s world teams have huge dependencies on various stakeholders of the project including Users <-> Developers <-> QA <->Operations etc. and it’s proven that we need regular communication and collaboration to deliver the value.

Any communication gap or lack of collaboration between these team(s) or individuals will have impact in following areas

Plan Driven Vs Value Driven Approach 

Old school of software development has taught “waterfall” approach of software development.  In waterfall approach, one phase’s output becomes input to next phase and those phases are distributed across the project timeline as shown in the image below.

Today’s software development technique is “Iterative“ and “Incremental” I.e. Agile. In Agile, team run through all the phases within a Sprint as briefly shown in the image below.

In waterfall, development teams only have one chance to get each aspect of a project right. Whereas in Agile team has better understanding and learning from previous Sprint on what to emphasize upon and what to avoid to reap better results.

Why Agile

  • Agile development methodology provides opportunities to assess the direction of a project throughout the development lifecycle.
  • This is achieved through regular cadences of work, known as sprints or iterations.
  • At the end of which teams must present a potentially shippable product increment. The results of this “inspect-and-adapt” approach to development greatly reduce both development costs and time to market.

Agile Manifesto

Perfect Agile Team, does it really exist?

Success of any project depends on Team. I.e. it’s critical to have an awesome team to have rocking results. But in reality this doesn’t happen as team consists of individuals with their own attitude, aptitude, work style, ethics, behavior and issues etc.

Bruce Tuckman’s team development model is a perfect example how team can come together and start functioning.

Agile team’s Success heavily depends upon “self-Organized” team.

Scrum Process

Sprint Length and Team Size

Sprint is to Run at full speed over a short distance. Ideal Sprint length is 2 weeks. My recommendation is as following and I have experienced that it really works well.

  • Ideal Agile teams must be 7 to 9 +/-2 members.
  • If you have more candidates in a team, then divide teams and have separate agile teams.
  • A representative of each team might want to attend other team’s standup for critical issues, follow-up and announcements etc.

Most wanted thing in Agile – Velocity

Velocity is the account of work team completes and delivers in each sprint. Ideal sprint duration is 2 weeks and highly recommend this to any team.

I have seen better results when team works towards a pre-defined code complete date for instance, today is Tuesday and sprint is for two weeks, team can agree upon a code complete date of Wednesday of 2nd week. I.e. team will try to complete all the work by that day and have it ready for QA.

This just gives a deadline to accomplish the work, however there will be situations where work couldn’t get complete or even rolled over to next sprint and that is fine in some cases.

Here are some of my recommendations:

Give as much time as possible to Developers, SDETs and QA to fulfill their commitment. I.e. less meetings and hindrance.

Have at-least 2-3 sprints worth work well-groomed and available for the team as “ready for development”.  Two reasons:

1 – At times for unforeseen reasons or instances a user story may be pulled out of current sprint. In such situations you lose story points you committed to. In such scenarios other US can be delivered.

2- Sometimes team or an individual is able to complete the work early and available to pick more work, in such situation well-groomed loaded backlog can come very handy.

Groom Often (Backlog Grooming)

  • Usually Sprint 0 is dedicated for backlog grooming and then team start to deliver in Sprint 1 and onward.
  • Considering any Enterprise Line of Business (LOB) application, sprint 0 can’t suffice the entire backlog groomed at once.
  • Hence, team must regularly have backlog grooming in small chunks of time instead of lengthy full day meetings.

Ideally, grooming is a lengthy process and hence groom in short chunks and team lead can be present in the regular or small grooming sessions with PO or business and team can continue to focus on their work. However, team must be present at Sprint Planning time.

Brainstorm Together (Sprint Planning)

  • Everyone is invited. Many teams ask only Dev’s to attend and excuse the QA team members.
  • Understand the problem 1st.
  • Ask Questions and clarifications.
  • “Well defined” Acceptance criteria is a must.
  • Confirm that User Story is ready for development.
  • Nothing should fall from the cracks, document all within the User Story.

Daily Status Check

Just three things, no more; no less

  1.  What have you done since yesterday?
  2.  What are you planning to do today?
  3.  Do you have any blockers preventing you from accomplishing your goal?

I recommend, that if you have to discuss something related to a User Story or bug or some reported a status on something etc. then “Post Scrum” that. I.e. discuss that when team has given the status and now you can drill into the detailed discussion.

Many times Dev’s start going into technical details of the issue, design of solution, architecture, code review comment details etc. during their status. This is not right way of doing it. Just Post Scrum all that; if you have to discuss anything other than those three absolute must.

I am Blocked

It’s is obvious that someone at some time is blocked on something. You can help, by asking just:

  • Really
  • On what
  • What is the issue
  • Who is POC (Point of Contact)
  • What is ETA (Estimated Time of Arrival) I.e. delivering solution to you.

I will give you a scenario, let’s say I join a team which works on some third part control library and my license of that product is pending or not yet processed. Am I blocked. Well in a way; yes, but I can use trial version up to 30 days and when my license information come I can punch those.

Also, many times we just tell other team that we are blocked on something and we are expecting the endpoint or JSON format etc. but we don’t always ask what is ETA and convey the timelines we have to adhere. If this has any impact on your team’s deliverable than you need to re-prioritize, escalate etc. so either that work is delivered to you on time or that user story is pushed to next sprint and you pick next item on Stack rank (priority) from the Product backlog.

Scrum Master must help you to get unblocked.

Is there time to Think?

Many people and teams think that Agile has no time for following:

  • Researching a solution
  • Brain storming on the solution architecture.
  • Share your thought process, design, approach with the architects, PO etc. to get the insight.

Well, there is and it’s called “Spike”. In agile software development, a “Spike” is a user story that cannot be estimated until a development team runs a time boxed investigation. The output of a spike story is an estimate for the original story.

Some examples of spikes:

1- Discussing authentication mechanism and partner team’s flexibility to apply / accept those changes.

2- Discovering or researching for an off the shelf solution work flow solution.

Technical Debt

Every team has it, generated it, accumulate it; not a problem. Just make sure you pay it off.

Technical debt is a terms which is used for the work which team or an individual didn’t prioritize upon while pushing the deliverable, and require improvements.

  • First and foremost, poor coding style and standards.
  • No unit test cases.
  • Not following OO design principles and developing long monolithic classes and code libraries.
  • Not envisioning on proper candidate technology, architecture or approach and then hitting a wall. I.e. when application is little bit mature you start to feel the hit on User experience, performance, scalability, code maintenance etc.
  • Code files has a lot of comments. I.e. code is completely documented. Many developers write few lines of comment for each line of code.
  • Code is not self-documented.
  • Magic strings (hard coded path and endpoints etc. in the code)
  • Dead code in project. You must have seen or left some commented code in various code files. This is dead code and needs to be cleaned up.

Read my detailed article on Technical Debt

Branching and Merging

Branching enables parallel development and delivery by providing each development activity a self-contained snapshot of needed sources, tools, external dependencies and process automation.

Continuous check-ins pollute the branch.  Have a separate Release branch per Release.

Basic Dual Branch is an Ideal branch plan, have a Main, spin a Dev branch for development and have RI (Reverse Integration) and FI (Forward Integration) to merge changes between Child and Parent branch respectively.

When you are ready to deliver the shippable product at sprint completion then spin a Release Branch and deliver the product out of that.

Feature Branch Plan is slightly complex and requires more merge efforts but at the same time it give entire isolation of work being done in a feature branch for entire time; until it’s ready for merge to Dev branch. One major issue with this plan is that your feature branch will have old and stale code and when you will Get Latest / Pull from the changes then you will get some conflicts etc.

Just saying

“Save your creativity for your product… not the branch plan.”

“Your branch distance from main is equal to your level of insanity”

Unit Testing

Many teams don’t invest in Unit Testing. For any Agile Team Unit Test is the most critical thing and team must continue to increase the code coverage of the tests. Even based on Test Triangle as shown in the image below, Unit Test has the larger scope in Software Testing.

Read my detailed article on NUnit with Visual Studio

Read my article on Visual Studio and .NET’s Unit Test Framework

Read my article on Inside Out: TDD using C#

Benefits of Unit Testing

  1. Unit Testing gives an opportunity to think as User of your code, instead of an implementer of the production code.
  2. Reduce bugs by identifying all the use case scenarios to reflect intent (end user’s mindset, business needs, expected functionality and business validations etc.)
  1. Less-n-less time on debugging.
  2. Avoid collateral damage. I.e. a fix in one area may break functionality in another possibly
    related/unrelated area.
  3. Helps you achieve YAGNI– You Aren’t Gonna Need It. I.e. saves you from writing code which you
    don’t need

Tips for System Test

  • Must know how much to test, drive your Test cases from Acceptance criteria.
  • Avoid duplicate test steps.
  • Make sure that all your Test Cases are Mapped to Acceptance Criteria.
  • Try to combine similar behaviors in a single test case.
  • Do not go above and beyond to identify every corner case or hack the system. I.e. above a beyond the acceptance criteria. I know this is tricky and someone may want to debate on it. I didn’t mean to say that don’t test any areas of application which might have direct impact of a User Story or what not. But there is always a fine line on what to test and what not.
  • Time box for ad-hoc testing. I.e. in each sprint time-box some time

Continuous Integration (CI)

  • An important part of any software development process is getting reliable builds of the software. – Martin Fowler
  • Continuous Integration (CI) is the strategy and practice of making sure that changes to a software project’s code base are successfully built, tested, reported on, and rapidly made available to all parties after they are introduced.

Advantages of CI

  • Increase ROI (Return on Investment).
  • Guarantees successfully compiled software.
  • Visible progress reporting and problem tracking.
  • Low TCO (Total Cost of Ownership).
  • Improve development standards, consistencies and accountability.
  • Rapidly identify bugs, who created them, and where it is.
  • Quickly push high quality change updates to testing.
  • Reduce development integration effort.
  • Increase amount of quality code.

Successful Build

An aggressive goal for a successful build would include:

•       All the latest sources are checked out of the configuration management system.

•       Every file is compiled from scratch.

•       The resulting object files are linked and deployed for execution.

•       The system is started and a suite of tests is run against the system.

•       If all of the above execute without error or human intervention and every test passes, that is a successful build.

Let the Team see what is happening

  • Must have Gated builds and nightly builds to ensure value delivery of the functionality.

You can use this build monitoring tool from https://teambuildscreen.codeplex.com/

Continuous Delivery (CD)

CI mainly focuses on development teams. The output of the CI system normally forms the input to the manual testing process and to the rest of the release process.

You’re doing continuous delivery when:

  • Your software is deployable throughout its lifecycle
  • Your team prioritizes keeping the software deployable over working on new features
  • You can perform push-button deployments of any version of the software to any environment on demand

I am speaking at Seattle Code Camp and my session topic is “How to use Agile correctly“. It’s totally FREE community event. Please register and spend the weekend in learning all you can.

My session will be in Room#204 at 1-2 pm.

Introduction

Technical Debt is a term that is commonly used in agile-scrum team process. Technical debt is used for the work which team or an individual didn’t prioritize upon while pushing the deliverable, and  either left some unwanted code in various project artifacts, such as – .cs, .config, .cshtml, .js, .sql etc. or didn’t use the right technique to accomplish the goal. But in real world software development process this is expected and totally fine as long as team takes the responsibility to pay off the Technical Debt.

How is Technical Debt created?

Technical Debt is like financial $$ debt; if you don’t pay off previously owned $ amount but keep borrowing more than you are getting into messier situation. I assume you are not the one who like debt that much; whether it is technical or financial. Anyways, just to be aware; if you don’t take good care of the following items then you are potentially seeding “Technical Debt” situation in general, later on which needs to be paid off.

  • First and foremost poor coding style and standards.
  • No unit test cases.
  • Not following OO design principles.
  • Developing long monolithic classes and code libraries.
  • Not envisioning on proper candidate technology, architecture or approach and then hitting a wall. I.e. when application is little bit mature you start to feel the hit on User experience, performance, scalability, code maintenance etc.
  • Over engineered application. I.e. things which can be done in simpler way are done using very complicated mechanism. For instance, to do encryption data, custom code is written or taken from internet which causes a lot of security holes and performance hits.
  • Code files has a lot of comments. I.e. code is completely documented. Many developers write few lines of comment for each line of code.
  • Code is not self-documented. I.e. Classes, functions, variables etc. are given improper names. For example, a function is named Salary instead of EmployeeSalary or a variable is called double sal instead of double employeeSalary.
  • Shortcut approach is taken to push the functionality to meet the code complete deadlines. Such events trigger further refactoring to be performed later. For instance, created one thick bulky Model class with a lot of classes within. Or hard coded various paths and endpoints into the .cs code rather than putting those into a web.config and reading web.config Key in the code for the related value (key-value pair).
  • Dead code in project. You must have seen or left some commented code in various code files. This is dead code and needs to be cleaned up.

Based on above mentioned points, now you will be able to understand that why Technical Debt is also known as Code Debt or Design Debt. In addition, anything in your software development work; which slows you down or looks odd, or can be improved is a “Technical Debt”.

How to handle Technical Debt

First step is, not to cause any technical debt from your end; if at all possible. However, in agile development it’s common to have some technical debt accumulated over the period of time, if so then move to second step. Second step is to report any technical debt which you have either caused or came across.

Please don’t get into blame game or point finger to any individual. Let’s say you come across some code blocks in a file you are working on and then you see some dead code. Rather than start cleaning it up, I recommend create a Technical Debt item and let the team decide.

How to Report Technical Debt

Technical debt items are usually reported as Issues or as a “New Product Backlog Item”. Also, Technical debt items are supposed to be logged in a separate backlog. I.e. don’t report those to Production or sprint backlog. In many teams and as per my experience with agile-scrum I have always worked on a separate dedicated “TechnicalDebt backlog”

Having a separate TechnicalDebt Backlog allows the team to stay focused on Sprint backlog and don’t interfere with business requirements which are logged in the Product Backlog.

Creating Technical Debt backlog

Creation of backlog and modifying process templates etc. are usually done by an admin on your team project. In an agile team setting this duty is usually performed by the scrum master.

If your team doesn’t already have a Technical Debt backlog, then it’s time create one.

  1. Go to VSTS (Visual Studio Team Services) Team Project’s Web Portal and in control panel under work, click on Areas.

  2. Under the “Areas” click on “New child”

  3. Name it as “TechnicalDebt_<YourTeamProjectName>”. TechnicalDebt prefix helps you differentiate it with other areas and makes it self-explanatory.

  4. It will now appear under your Team Project as an area.

 

Let’s see it from Developer’s angle

Developers usually interact via Team Explorer from within Visual Studio IDE.

Select Work Items and then click on “New Work Item” and based on your team process template; usually either Agile or Scrum, you can select Product Backlog Item or Impediment or Issue as item type to report the Technical debt.

Filling in the details

Usually, any item in any backlog needs to have ample information to describe what the issue is. In the below example, it is briefly pointed out that some classes need code cleanup. Some questions might still be unanswered and those will be discussed during backlog grooming and sprint planning.

When to work on Technical Debt

Just like Product and Sprint backlogs, Technical Debt backlog also needs to be groomed I.e. each “Technical Debt” item needs to be reviewed and groomed by the team to identify its validity, impact on overall team’s development experience and software quality team is producing. Once, team is in agreement to pay off a technical debt item or items then those items are transferred to Sprint Backlog and many times a new User Story is created for each technical debt.

Many Agile experts say that a team must not carry Technical Debt beyond a sprint, just like you should not carry Credit Card balances over to next pay period. I.e. pay off full Credit Card debt in the same billing cycle. But, it’s not always possible, so it doesn’t happen in software world for Technical Debt as well.

Summary

I personally recommend that as a developer you should not cause any technical debt due to the code you have written or currently writing. Be honest, about any improvements your code might need and explicitly call out what changes can be made to make it better. Avoid any over engineering or unwanted design patterns and technology implementations to be called out as Technical Debt. If you are not sure whether a particular code / technique is Technical Debt or not, call out a short brain storming session. In today’s software development industry it’s not easy to avoid technical debt, we all live with it, but be aware that you have to get rid of technical debt to achieve complete Technical Freedom.

Introduction to VSO

VSO (Visual Studio Online) a cloud based collaboration tool (can be considered as TFS online). VSO provides a set of tools that work with Visual Studio to effectively manage your application.

VSO Capabilities

VSO offers various capabilities which various team can utilize to build great software and really depend upon.

  •   Version control.

  •   Tools for Agile Software Development teams

  • Continuous Integration

  • Support for even Non-Microsoft Languages and Tools

  • Integration support for various 3rd Party Tools

  • Infrastructure Grade SLA

Note: All above images are taken from https://www.visualstudio.com/products/visual-studio-team-services-vs

Back in 2008

I do remember the earlier days when Microsoft 1st started this concept of VSTS (Visual Studio Team System).

You can click https://www.microsoft.com/en-us/download/details.aspx?id=16338 to visit the page as shown in image above

On-Premise VS Azure

Many work places have applications which they want to have access to anytime, anywhere and continue to build the applications using integrated, powerful, cross-platform, enterprise-level Agile tools ; so team(s) can share source code, build often, test early, and ship faster with less time to market.

Like many software companies “on premise” source control in form on TFS on their own servers has served the business need. Whereas for many cloud was the choice to set up a Team Services account,  connect their dev tools, share code, invite team members, and start working.

In these business scenarios TFS and VSO has been an answer respectively.

Rebranding made is meaningful

Recently, Microsoft re-visited the Branding idea of VSO and renamed/re-branded it back to VSTS. But now “S” is not System instead it’s “Services” as this is Azure based solution hence, Services make complete sense. I.e. VSTS (Visual Studio Team Services) which is Software-as-a-Service offered by Microsoft for organization’s ALM needs.

  Note: This image is taken from https://www.visualstudio.com/products/what-is-visual-studio-online-vs?WT.srch=1&WT.mc_ID=SEM_MqzVAfsq

Summary

In my view VSTS provides better value to development team(s) and better ROI to management; as it enables and empowers the developers to collaborate anytime from anywhere. In addition it helps the organizations to reduce / cut-down the DevOps cost and needless to mention Zero investment into serves/disk spaces. Whether you are a dev using VSTS or on-Premise TFS you are not missing any features and capabilities from any of the flavor, VSTS is just a preferred/better way (in my view).

I am now also contributing to Microsoft Channel9.
More videos are in production and will be available soon.

https://channel9.msdn.com/Niners/dotnetauthor

Please do Comment, Like and Subscribe to my Channel.

Watch YouTube Vide Here…

Abstract

Agile is a software development methodology which I becoming popular day by day. It defines the mind set of many software development teams working across the globe. This article will walk you through the entire agile-scrum process and how as a developer you can contribute in agile way and deliver value. BTW, agile means ability to move quickly.

Agenda

  • Life Cycle of a Developer
  • Barriers to value delivery
  • Agile Adoption
  • Plan Driven Vs. Value Driven
  • Agile Manifesto
  • Scrum – End-to-End Process
  • Agile Estimation
  • Scrum Status Board
  • Agile Tools
  • Conclusion

Life Cycle of a Developer

 1st interaction a developer have is with BA, they are responsible to document, track and describe the user requirements. But many times there are gaps in understanding the needs; which causes issue by various means.  Image below shows what user wanted and what happened when it is implemented.

Stop the blame game

In many team settings, a developer is considered to be responsible for everything, right from understanding requirements to code to support testing, help in deployment and then resolve production issues. Well, I always believed that entire software development is a team effort. But at the end, in most cases developers bear most of the blame. So its no longer a Developer’s responsibility to own everything rather team owns it.

Team Barriers = Value Delivery Impediments

All .NET Development teams want to deliver value but on realistic grounds what are barriers which stops a team to deliver value.

Every team has dependency within and on people outside, the communication gap and lack of understanding of common goal is the root cause of Value Delivery Impediments.

Impact of Team Barriers

Well, most of the issues any software teams runs into has following outcomes:

Increased Cycle Times – This means that you have to work longer to get work completed.

Increased costs – More time means more money.

Dissatisfied users & Stakeholders – End user missed the milestone of feature being available and so it raises concerns for stakeholders as well.

Lost value opportunities – You are potentially not going to have more work from same client.

Agile Adoption

 

Agile-Scrum is most widely accepted methodology of Agile development. Term scrum is taken from sport rugby in which whole team works get the possession of the ball.

Plan Driven Vs Value Driven

 

Plan Driven (waterfall approach) is an old school which defines software development life cycle. Many teams are still doing that though but in waterfall plan takes precedence over value.

Value Driven (agile approach) is new way of building software, it gels teams, stakeholders and user very well and help them team receive early feedback and fail fast.

Manifesto for Agile Development

17+ people gathered in a ski resort and they came up with agile manifesto.

Understanding Type of Backlogs

In agile-scrum there are two type of backlogs

  1. Product backlog
  2. Sprint backlog

Product backlog is larger list of work items (in agile world known as User Stories), it is like a “Functional Specification Document” or System Requirement Specification Document or “Business Requirement Document” or whatever your organization likes to call it.

So whatever user requirements we have, all are stored in Product Backlog, backlog.

Sprint Backlog, Sprint is defined time, teams work on to deliver certain items from product backlog. But before teams start working on those items (User Stories), those need to be properly defined.

Scrum – End -to-End Process

Agile Scrum Ceremonies

Team works on a sprint for anywhere between 1-4 weeks. Ideal sprint duration is 2 weeks. So from Product backlog some User Stories are moved to Sprint Backlog and then team works on those for 2 weeks. During those two weeks following ceremonies are performed.

Sprint Planning, this is 1st thing which takes place before any work can begin. In this meeting team looks at User Stories which Product Owner thinks team should work upon in the next sprint. Team looks in detail at the given requirements, brainstorm, define/review acceptance criteria or the work, estimate and assign the work to team member(s).

Daily Stand-Up, this is status meeting among team(s) members, in this meeting each team member gives status on three criteria’s.

  1. What I did yesterday.
  2. What I will do today.
  3. Am I blocked?

Sprint Review, this takes place after each User Story is completed, so Product owner can accept the work.

Sprint Demo, this given an opportunity to the whole team and larger group of users to see all the work team has completed and see end-to-end functionality.

Sprint Retrospective, this gives opportunity to the development team to discuss three things

  1. What went well?
  2. What went wrong?
  3. What we want to improvise?

Agile Estimation

Agile offers two type of estimations:

  1. Story Points, this is most commonly used agile estimation technique.
  2. T-Shirt Sizing, some teams estimate User Stories in T-Shirt sizing.

Scrum Status Board

Agile, enforces daily status reporting and so many teams use various ways to track and show the progress on each user story. I found that a detailed board like following provides more visibility and track each task/activity related to a Sprint Item.

Agile Tools

There are many tools available for agile-scrum teams, but I have found TFS and rally widely used in industry. Both work on similar agile-scrum concepts and are very user friendly. Below are the screenshots of TFS.

Sprint View in TFS

Workflow for Task Status

Drag and Drop support for ease

Conclusion

Though agile seems very easy to understand and implement, but it’s very challenging to apply it correctly and many organizations are not in agreement with what agile brings and its way of delivering things. Startups are usually known to follow agile rather well established companies at organization level. I.e. In a company a team might be doing agile but various other teams or company’s mindset might still be waterfall based.  But agile is an amazing methodology to deliver more value; regardless of you are working in agile team or not it’s worth knowing about agile-scrum process.

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas

Source : http://www.agilemanifesto.org/