Agile Assessment Version 1.0

Agile Profile and
Recommendations
A preliminary report on your software
delivery team's business responsiveness.

Agile Self Evaluation Version 1.0

Prepared for
Ciprian Mester, Alcatel-Lucent
July 04, 2009

For more information, contact :
Gregory M. Reiser
Principal Consultant
assessments@thoughtworks.com

www.thoughtworks.com
To schedule Onsite Assessments, email assessments@thoughtworks.com

Executive Summary
In an effort to optimize the business value delivered, many software development organizations are adopting Agile
methods. The essence of Agile is the ability to adapt in an ever changing environment, but adaptability introduces the risk of
chaos. Hence, increased discipline and proficiency in executing a set of best practices are critical success factors in the
Agile journey.

This Self Evaluation helps you determine the extent to which your development team applies Agile principles along nine
dimensions, covering both management and development practices. Based on your responses to 20 questions it identifies
opportunities for change that will help you deliver on the Agile promise.

This Evaluation is based on ThoughtWorks' 15-year experience in pioneering Agile development for the creation of both
business applications and software products.

Please note that a questionnaire-based tool is not a substitute for an in-depth assessment and improvement plan. The
objective of this online tool is to assist you in planning for a more thorough assessment leading to an improvement program.

Your Team's Agile Profile

KEY

Supports ability to change

Neither hinders nor contributes to effective agile development

Counter-productive to agility and responsiveness

Next Steps

What is presented above is a preliminary evaluation - a more thorough study of your organization is required before a
conclusive "current state" can be determined. Additional benefits could be realized via the broader and deeper adoption of
Agile methods towards a "target state", which would depend on your organization's objectives and constraints.

Moving your software development team forward along in their Agile journey should begin by forming a roadmap to go from
their current state to the target state. Implementing the roadmap requires committing to a continuous improvement
program, including periodic assessments. If you would like ThoughtWorks to be of assistance in your team's Agile journey,
please feel free to contact us.

1 www.thoughtworks.com

Table of Contents
Executive Summary................................................................................................................................................................1

Introduction.............................................................................................................................................................................2

Management Practices...........................................................................................................................................................3

Development Practices...........................................................................................................................................................7

Results..................................................................................................................................................................................10

Next Steps and Recommendations......................................................................................................................................12

About ThoughtWorks.............................................................................................................................................................13

Contact Us.............................................................................................................................................................................13

Introduction
This report provides preliminary insight into the extent to which your development/project team is applying Agile
principles. It is based on your responses to 20 questions, formed during the course of ThoughtWorks' decade-long
experience in Agile application development, Agile software tools and Agile consulting.

The online tool explores the level of agility within your development/project team, and identifies opportunities for
improvement. This report also points to several sources of information that will help a development team raise the bar on
agility.

The following analysis shows where your team, based on your answers, resides on a scale ranging from Regressive to
Agile. The Regressive state representing behaviors that inhibit the ability to adapt and the Agile state representing
behaviors that focus almost exclusively on adapting to change.

Please note that the ideal state varies by organization. That is, the most extreme Agile practices for each dimension are not
necessarily the ideal for your organization. Hence our recommendation that your next step is an in depth assessment that
results in a refined definition of current state and the definition of a target state that is optimized for your organization. Only
then can you develop an improvement program that is optimized for your organization.

The evaluation is not meant to serve as a conformance or certification tool; rather, the intention is directional. It also is
not meant to be a conclusive judgment of the Agile capabilities of the team. As discussed in the "Next Steps and
Recommendations" section, a thorough study of your development team is required, before a more conclusive assessment
of the current state of Agile maturity can be made.


Management Practices
Some of the unique Management practices of Agile include "Deliver Frequently", "Measure Value" and "Empowered Team".
There are 12 questions across 5 dimensions.

Requirements Analysis
Agile recognizes that not everything about the desired end-product can be known before development starts. Hence, Agile
teams adopt lightweight requirements gathering techniques, with a focus on business value. Read More

1. Which of the following most closely resembles your up-front requirements analysis process?

Options Your Answer Strongly Agile
We capture as many high-level statements that we can within a short period of time and then begin
development.

We employ user stories. We time-box the initial analysis work and then grow the story list while X X
developing the solution.

We develop a comprehensive list of requirements and as much detail as we possibly can before
committing to development.

We employ use-case analysis, supporting UML models and other artifacts. Use cases are 1 to 5 pages
long as needed.

Not Sure.

Traditionally project teams are taught to capture all requirements up front, and then achieve customer sign off. This process inhibits
change, whereas most software projects demand constant change. Ideally, development teams should capture "just enough" detail to get
started and then use an iterative development process to evolve the requirements.

2. What is the longest amount of time expected to develop any single business requirement?

Every requirement can be developed in less than 5 days. X

Every requirement can be developed in less than 10 days.

Some requirements will require more than 10 days of development time. X

Not Sure.

Agile is about constant feedback loops between the customer and the development team. If the customer does not frequently have a
chance to see what is being built, there is the risk that the team may build something of sub-optimal business value.

3. Which of the following most closely describes the ratio of business analysts to developers within your organization?

1 business analyst to 4 or fewer developers. X X

1 business analyst to 7 or fewer developers.

1 business analyst to 8 or more developers.

Not Sure.

In Agile, Business Analysts take on the role of "product owner" - prioritizing stories and developing acceptance tests along with the
customer. Development team members should have constant access to subject matter experts. Any delay in getting questions answered
will decrease throughput.


Business Responsiveness
Agile originates from the idea of the customer having the ability to change their minds in response to business imperatives.
Responsiveness measures how easily such changes are accommodated. Read more

4. How are change requests handled?

We have a formal change control process; all changes require approval and sign-off.

Change requests tend to come in constantly and be of high priority, so we do what we can to get them
into the next release.

It joins the backlog and gets prioritized along with everything else. X X

Not Sure.

Formal high ceremony processes such as a "change control board" inhibit agility. Agile teams should accommodate new or changed
requirements till the "last responsible moment" which will vary by project. Change requests (prioritized by business value) should be added
to the product backlog.

Collaboration and Communication
As with any creative endeavor, software development benefits from skill blending with strong communication.
Communication is reinforced by co-location, tools and other techniques. Distributed staff, if any, should be treated as an
integral part of the Agile team, even if they are geographically remote. Read more

5. How is work assigned?

People are given specific tasks to perform (coding, analysis, etc.) by leads / managers.

People choose what they are going to work on from a backlog. X X

Not Sure.

Agile pivots on the idea that assignments and work flow should be determined by the highly skilled team members whose primary
responsibility is to deliver customer value. Managers need to balance team autonomy and flexibility with just enough control to prevent
backsliding into ad hoc development.

6. When significant new technical tasks are discovered and estimates change:

The Product Owner re-priortizes the backlog and the Development Team determines how work should X X
be re-assigned.

The Project Manager re-assigns tasks.

The Development Team works as hard as possible to accommodate the change and get the project
back on track.

Not Sure.

The entire team (not just the manager or a few individuals) should own delivering customer value. Changes are expected, routine events -
there should be minimial ceremony around accepting and executing them.


7. The project team consists mostly of:

Generalists who can work on just about any part or section of the project. X X

Specialists who work on specific areas of the code or within specific technologies.

Not Sure.

Team members should share responsibilities to the extent that their expertise allows. Too much specialization reduces throughput and
quality as people focus exclusively on "their job" and not the product. When developers own specific modules it creates a concentration of
knowledge that puts the project and the organization at risk.

8. Team communication takes places primarily through which of the following:

Requirements and specifications are explicit and detailed; developers reach out to analysts with any
questions; change requests and defects are logged and / or coordinated.

Meetings are held frequently (daily / weekly) among developers, analysts and users all in the same X X
forum to discuss requirements.

People generally seek out whoever they need to see to get an answer.

Not Sure.

Status should be visible to the whole team at all times, so that there is near-real-time prioritization of functionality. Tools like wikis and
bulletin boards should be used to capture ongoing status. Over and above that, The Project Manager should facilitate periodic (say,
weekly) iteration meetings, so that the entire team is on the same page.

Project Management
The core Agile challenge is to balance time, scope and cost while constantly delivering business value. Read more

9. Which of the following most closely describes how you manage the release plan?

We're feature driven: we'll delay a deployment to make sure all features are included in what we
deploy.

We're date driven: we'll defer a feature to make sure we have something to deploy on a target release X X
date.

Not Sure.

Agile teams hold time as a constant, establishing a regular cadence of production delivery. An Agile best practice is to go "live" (even
internally) with a reasonable feature-set and then let user feedback guide future releases.

10. Planning activity is best described as:

We plan up-front and periodically review performance of the team against the plan.

We plan frequently, periodically adjusting the plan. X X

We plan constantly, making new plans as things change.

Not Sure.

Project planning should be a collaborative process that features continuous prioritization (at a release and iteration level) involving the
customer. Projects should employ short iterations, and the plan should be relooked at every iteration.


11. What is the length of time of the typical project plan?

We plan for a very short period of time, rarely more than a week or two forward.

We plan for a short period of time, in detail for only a month to 6 weeks forward. Plans are high-level X X
beyond that.

We plan for a long period of time, with details mapped out for 6 months or more.

Not Sure.

Agile recognizes the fact that long-term detailed planning is futile. Details mapped out for long periods could lead to inflexibility in adapting
to changing requirements.

Governance
Governance should not be a hurdle to agility. It should reduce suprises, increase trust and confidence, and help the team
execute in line with business strategy. Read more

12. Which of the following most closely describes the role of governance for your project (or within your organization)?

Governance is a formal, structured process requiring periodic process and/or technical audits
conducted by an independent organization.

Governance is an informal activity implemented via "management by walking around" by senior
leaders who "spot audit" projects at irregular intervals.

Governance is a shared responsibility. Standards are developed jointly by project teams and senior X
technology management; and compliance is enforced via unobtrusive processes.

Governance is a bit chaotic; everyone seems to thinks that they have governance responsibility over
some part of IT.

Governance is limited or non-existent. X

Not Sure.

Business stakeholders should be fully engaged in the Governance process, with an understanding of its value. This becomes easy when
Governance is focused on removing obstacles to project success, and not just standards enforcement.


Development Practices
Agile development practices focus on implementing solutions that accommodate change. Practices that embrace and
support the following principles are key: "Test Everything", "Release Frequently" and "Simple Design". There are 8
questions across 4 dimensions.

Simplicity
The flexibility afforded to the business is rooted in the ability to easily change the end-product. This allows most future
requirements to be ignored with a corresponding increase in team efficiency. This dimension reflects the extent to which
design may be just-in-time. Read more

13. Which of the following best describes who is responsible for Technical Architecture?

Architecture is the purview of an architecture group.

Architecture decisions are the responsibility of development teams. X X

Not Sure.

Evolutionary architecture takes place close to where software is written. Agile teams have direct responsibility for shaping solution
architectures.

14. To what extent are future requirements accommodated by your systems' architecture/design?

We strive for highly configurable solutions that can accommodate anticipated requirements.

We implement designs that attempt to accommodate all known requirements because change is very
expensive.

We only implement what is needed right now. We use a "first solution that works" strategy in an effort
to maximize throughput.

Although we only focus on the most immediate requirements, we use design patterns and automated X X
testing strategies that make it easier to change the system later on.

We don't try to accommodate future requirements. Our systems are hard to change. So we focus on
the most immediate requirements, stabilize the solution and then ship it.

Not Sure.

New and maintenance development work evolves organizational learning and exposes both risks and opportunities. The essence of agility
is that by "making change cheap" the architecture can evolve to its optimal form.


Build Management
Teams should give a good deal of thought to what constitutes a successful build (passes unit tests, passes integration tests,
passes code quality tests, etc.). They should ensure that the latency of feedback from all of these assessments of code
committed is minimized, and that this feedback is visible and a priority source of information to every team member.
Read more

15. How often does the team create a complete build of an entire product stack?

Once or more times per day. X X

Once per week.

Less than once per week.

Once or less per month.

Not Sure.

Frequent builds of the entire project stack give developers constant feedback on quality, enabling them to fix errors early. Ideally, builds
must be fully automated (no error-prone manual processes) and should be backed up by automated tests and continuous integration.

Configuration Management
Rapid change by multiple developers is common with Agile teams. Code libraries and other change management tools
should support this environment. Read more

16. Which of the following development artifacts are maintained in a configuration management system? : Source Code,
Data Model, Database Scripts, Requirements, Test Data.

All. X X

Some.

Source Code only.

None.

Not Sure.

All important artifacts should be help in a configuration management system that supports versioning, roll-backs, branching, tagging and
labelling. Configuation Management Systems should be transparent to the delivery team behind the build process, and they should have
the ability to tie stories back to source control check-ins.

17. How frequently do developers check in changes?

One or more times per day. X X

Once per week.

Only upon feature completion.

Not Sure.

Developers should be encouraged to check-in changes into the codebase as frequently as possible.


Testing & Quality Assurance
Testers should be engaged participants, rather than disengaged auditors. By collaborating from the early stages of the
lifecycle, and executing continuously throughout, Agile QA works as a value-added partner that directly contributes to an
increased understanding and gradual evolution of a business solution. Read more

18. QA analysts test:

Large collections of functionality (e.g., use cases) delivered after long intervals (longer than one
month).

Small collections of functionality, delivered after short intervals (less than one month).

Whatever development has produced is what is tested (varies). X X

Not Sure.

Agile teams test continuously. It is the only way to be sure that the features implemented during a given iteration are actually done.
Continuous testing ensures continuous progress.

19. QA analysts:

Are full-time participants in a project team. X X

Are significant but part-time participants in a project team.

Operate as a "shared service" across many teams.

Not Sure.

It is critical for Developers and QA analysts to collaborate constantly in order to achieve the principle of small, iterative and incremental
releases. Developers and QA professionals should have constant access to one another.

20. What percentage of automated test coverage do project teams typically have over the code base?

More than 65%. X X

Between 25% to 65%.

less than 25%.

Not Sure.

Developers should not write any code until there is a failing unit test. So if there is a new feature to be added, first write a unit test that will
only work if the feature is there, then make that test work.


Results
Overall Profile
Based on your responses above, your Agile Profile is presented below.

Your Profile Across 9 Dimensions
Your team's current state of agility on the nine dimensions of this Agile Self Evaluation, is presented below.

KEY





Management and Development Practices

KEY





Next Steps and Recommendations
As mentioned earlier, this is a preliminary assessment. A much more thorough investigation that includes direct interaction
with practitioners and managers is required to gauge the current state of Agility within your organization.

While modifying behavior should lead to broader benefits, every organization has different objectives and constraints.
Thus, it is appropriate for your organization or project to strive for different levels of maturity on each of the nine dimensions.
Further, the objectives may vary by the experience of the team and any vendors involved, the readiness of the organization,
and the Agile potential for the specific project (especially if the project enhances an existing system).

Once the target state of Agile maturity is determined, an executable roadmap may be prepared. Consistent with Agile and
Lean principles, we recommend a continuous improvement program so that your team may adapt to ever-changing
business and technical environments.

ThoughtWorks has a long history of helping organizations in these four stages.


About ThoughtWorks
ThoughtWorks kick-started the Agile business era with pioneering software delivery practices and world-leading
development tools. Today, clients approach us to solve their toughest business problems, and we deliver some of the
world's most sophisticated custom applications to hundreds of world-class companies.

Our products division, ThoughtWorks Studios, was established in 2006 and makes cutting-edge Agile software
development tools, like Mingle (Agile Project Management), Cruise (Release Management) & Twist (Functional Testing).
Other ThoughtWorks products include CruiseControl, the first Continuous integration system and Selenium, the popular
web testing framework.

Founded in 1993, ThoughtWorks is headquartered in Chicago, and has offices in Australia, Canada, China, Hong Kong,
India, Singapore, Sweden, the United Kingdom and the United States.

Some of our websites:

Application Development and Consulting: www.thoughtworks.com

Products: www.thoughtworks.com/studios

Agile Assessments: agileassessments.thoughtworks.com

Our Chief Scientist: www.MartinFowler.com

Our Products:

Download Free Trial Download Free Edition Download Free Trial

Contact Us
We will be happy to work with you on any aspect of Agile - application development, products, consulting.

Onsite Assessments & Onsite Assessments & Products
Application Development Products (Europe, Asia, Australia)
Gregory M. Reiser John E. Guerriere Parvinder S. Kalra
Principal Consultant Vice President (US) Head - Sales
assessments@thoughtworks.com assessments@thoughtworks.com studios@thoughtworks.com

You can also reach us at assessments@thoughtworks.com


Agile Assessment Version 1.0

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (11)

Similar to Agile Assessment Version 1.0

Similar to Agile Assessment Version 1.0 (20)

Recently uploaded

Recently uploaded (20)

Agile Assessment Version 1.0