Agile Acceptance Testing: Mitigating the Risks of Enterprise Software Development

January 6th, 2012
by Rod Claar

Here is the video from my talk at the ALM Summit at Microsoft.

 

For more information about my courses check the  Effective AGILE Development site.

Tags: , , ,
Posted in Agile Engineering Practices, Agile Testing, Scrum | Comments (0)

The PMO of the Future

November 30th, 2011
by Rod Claar

What is the PMO?

Wikipedia says that the PMO is the Project Management Office and is defined as “in a business or professional enterprise is the department or group that defines and maintains the standards of process, generally related to project management, within the organization.”  It goes on to reference traditional project management methodologies like the PMBOK and newer standards like ISO9000.

There are other references to PMO being the Program Management Office.  However most of these references still discuss program management in the context of project management.

I would like to take a deeper look into what the PMO should be to the enterprise and how the traditional focus of project management may fall short of what the enterprise really needs.

What does the enterprise ask of the PMO?

All large organizations have projects that need to be managed.  This is the traditional primary focus of the PMO. How do we know that at project is being well managed?  To understand what it means to have a well-managed project, we need to examine the goals of project management.

The common response when you ask a project manager what their goals are, their response is about the on-time and on-budget completion or the project.  That sounds like a good idea, but what does it really mean?

Obviously this indicates that there are goals for the completion date and the cost of the project.  That has an enormous hidden meaning.  The assumption is that project management knows what the project really is, what it will take to “complete” the project and the effort and skills that it will take to “complete” the project.

Second, there is an implied understanding of the risks involved in the project.  These would include platform and technical risks, business risks, competitive risks and probably domain specific risks.  Probably the most overlooked risk is the absolute risk of the organization’s ability to actually “complete” the project.

The last major responsibility that I have seen in large enterprises is that the PMO is responsible for the “efficient use of resources”.  Translation – keep everyone busy! (We are not paying them to do nothing!)

There are also several ancillary responsibilities that the PMO must often attend to for the enterprise and senior management.   The first of these is the reporting of project status, especially the roll-up reporting aligned to enterprise budgets and goals.  This is harder than it appears on the surface.  Projects are often and traditionally tracked by effort measured in some time scale like hours or by expenditures against a budget.

The PMO is also often charged with the responsibility of increasing project success over time through the development, implementation and enforcement of appropriate project templates, policies, tools and standards.

In addition to all of these, there is often a requirement to plan, coordinate and prioritize the various programs and goals of the enterprise.  This is often referred to as portfolio management.  Portfolio management often requires another roll-up of reporting across projects to an enterprise view.  Portfolio management is often a strategic coordination to meet enterprise goals.  This also means that the PMO is often responsible for the efficient allocation of scarce “resources”, skills and equipment.

At the lowest level the PMO is also expected to be self-sustaining through the training and mentoring of junior project managers.

Inherent to all these responsibilities are the expectations that the PMO will recognize and effectively deal with delays, unforeseen cost increases, changing priorities and projects that fail.

The Traditional PMO and Agile Project Mismatch

There is increasing adoption of agile approaches and methods in enterprise software product development.  The growing awareness of Scrum especially is creating an increasing pressure on organizations to attempt to compete better by implementing Scrum or at least being more “agile” in software product development.  This pressure is coming from a number of sources.  There is literature and case study evidence that enterprises can deliver business value faster, produce higher quality software, retain and attract technical talent and better understand the state of project development through the implementation of agile practices and methods.

The pressure created by the desire to be more agile creates a number of mismatches for the traditional PMO.  The traditional goals and approaches used by the PMO often create obstacles[1] to project success and the consistent and sustainable delivery of business value.  These obstacles require a reassessment of the traditional PMO goals and the approaches used to fulfill PMO responsibilities.  Alistair Cockburn says “Software is a cooperative game”.   In other words the, PMO should look at the process of software development as a goal-oriented, collaborative, group activity with a specific end.  When we look at each of the traditional responsibilities of the PMO, we can identify strategies and activities that are more effective and remain consistent with the enterprise goals.

Monitor and Manage Projects

Traditionally the PMO is expected to monitor and manage projects.  The concept of control is commonly used in this context.  The idea of control often includes steps, gates and sign-offs. One example of this is to track the progress against measures like fully completed and signed off documentation.  This documentation provides a plan or roadmap to the completion of the project’s features and deliverables.  This roadmap facilitates the creation of a timeline and budget for the project.

The PMO of the future should track the software game.  Are we going to win?  What is the score?  Where are we in the game?  How are the players doing?  Is the team healthy?  Consider the manager or coach or a sports team. Does the field manager or coach “control” the game or the team?  Consider the length of a game.  Does a team in baseball win by playing 9 innings? Consider the reality of the score of the game.  Does the strategy of a football game change when the score is lopsided?

The PMO needs to understand the score.  Are the features being developed at a pace that will result in a release that will deliver appropriate business value?  Will the expectations of stakeholders and management be upheld at the pace the team is on?  How can the PMO monitor the project to provide the enterprise the ability to select the best course to deliver the most business value as early as possible?  To answer these questions, the PMO of the future should be able to measure business value and the pace at which it is being developed and delivered.  The PMO of the future should be able to report on this progress in the terms of the system capabilities being delivered and the business capabilities they will enable and support.

Develop and Implement Standards

The traditional approach here is to develop and enforce a methodology to achieve a consistent ability to measure and monitor the projects.  The result is the institutional adoption of a process aimed at measuring “performance” against the plan developed to fund and authorize the project.  That performance is often stated as a rate of expenditure compared to a budget and timeline.

To track the game and the score, the PMO needs to develop measures that support the goals of the project.  To win the game iterative and incremental planning and development are combined with the close business involvement and frequent retrospectives of Scrum.    This means the “score” needs to be known in terms of business value or actual business capabilities delivered rather than dollars, bugs or stage gates.  Most successful Agile teams use a story based approach to work breakdown and properly defined stories can be sized in such a way as to increase predictability and measure business value delivery.

Managing Multiple Projects

The approach for managing multiple projects is often to flow job specialties over multiple projects in a sequential process. In other words architects and business analysts should finish their work on a project early so that the coding, testing, documentation, integration and release can be done on schedule as the people with those specialties become available.  Often this results in individuals working on 4 or more projects simultaneously because of the need to revisit areas of the project where previously “completed” phases need to change to meet new requirements, new learning or technology changes.   This increases the contention for scarce skills and equipment further delaying the delivery of business value.

The use of a business value, story driven approach where all aspects of a story are developed collaboratively in the context of the current state of the product architecture and release goals, can deliver more business value faster and result in less rework later. This allows entire deliverable increments of business value to be developed and delivered more quickly than the traditional multiple project phased approach.  While the prioritization of all projects against each other is required, normally the most important projects are delivered earlier.

Strategic Planning and Road Mapping

Most organizations believe that they do strategic planning for software development. However the approach is commonly one of loading as much as will possibly fit in a milestone or release in an effort to maximize efficiency and throughput.  This impacts the project planning process and obscures the internal complexity of the solution as well as the real relative priority between various business capabilities.  This approach also makes it difficult or impossible for the enterprise to quickly change priorities due to the very heavy investment in partially done work.

The breakdown of work at the portfolio level for enterprise agility involves the identification of business capabilities and the required system capabilities to deliver them.  This is often a matrix of business and system components that can and should be prioritized to deliver business value early and often.  It is not uncommon for such an analysis and road map to deliver some features with significant time and cost savings due to the leveraged priorities of the components.  From a code quality point of view, this also can deliver components that are truly reusable with higher maintainability which can result in an increasing pace of business value delivery.  The strategic adoption of the goal to deliver smaller components more often rather than the full feature bus approach is the key to igniting this engine of performance.

Facilitating Enterprise Learning

The auditing of projects against up-front plans and schedules seldom has a positive impact on the teams and the organization.  Attempting to hold matrixed individuals accountable to aggregate project goals is almost nonsensical.  The desired outcome of project auditing should be a better chance that the next project will deliver more business value faster.  However measuring against a traditional up-front project plan has very little chance of improving the next project or providing an accurate view of the current project.

Yet there are lessons to be learned. The audit report indicating that a particular feature was late by 50% of the original estimate should trigger the question of why that happened and more important, how can the organization be more predictable and/or deliver business value sooner in the future?  There is an aspect of this problem that does relate to the skills required to provide workable estimates.  Agile teams do learn to have better estimates over time.  However the learning to improve predictability often has little to do with hours, days and weeks.  Teams need to understand the nature of the work and have the authority to do the best work in a given time frame.  I’m not going to delve deeply into the use of non-time based sizing, but what is important in this context is to understand that the PMO should treat the work to get the funding as a discrete project,separate and with different goals from the project of delivering the best business value as soon as possible.  The culture of constant prioritization of user focused business capabilities, right sizing stories and allowing the team to do the best quality work possible can lead to more predictable and faster delivery of business value if the process includes the effective use of automated acceptance and unit tests, checkpoints and retrospectives to identify errors and correct them as early as possible.

Conclusion

The enterprise expects the PMO to provide value through the management of programs and projects.  Managing projects is the primary responsibility of the PMO.  When the organization or the development teams decided to change their process to adopt Scrum, things will change for the PMO.  The focus of Scrum and the foundational principles is the delivery of business value faster.  The PMO of the future will need to monitor and manage the various projects in relation to the delivery of business value.

To be able to provide this business value relevant progress reporting and help the organization understand the status of the projects, the PMO will probably be involved in the creation of sizing, planning and tracking systems that use the relative ROI sizing concepts used by Agile teams.

Most enterprises have more than one software product under development.  This almost always means that there are some cross-project priorities that need to be managed.  Many times there is a significant opportunity for a PMO to actually accelerate the pace of real business value delivery by taking a portfolio, business capability and system capability approach and delivering smaller packages of business value more often.

The world is changing at an increasingly rapid pace.  Dealing with this rapid rate of change is often about creating knowledge and making it available to be leveraged by team members.  The PMO should take a central role in enterprise knowledge capture and availability.

Involving the PMO in the adoption of Scrum is required to meet the goal of delivering more business value faster.  The PMO is central to the management of organization change in software product development. This responsibly is the charter for the PMO of the Future.  Delivering more business value faster and the right business value is an enormous undertaking.  Involving all the players and employing and enterprise view on top of the small team process of Scrum can dramatically change the pace and accuracy of business value delivery.

I would enjoy your comments and questions.

References and Reading

“Identifying Forces Driving PMO Changes” -PMI Project Management Journal, September 2010


[1] Mike Griffiths, PMP, ACP

Tags:
Posted in Project Management, Scrum | Comments (0)

Setup Fitnesse for .NET Testing

November 12th, 2011
by Rod Claar

When new pilots are in training one of the most unnatural things to learn is the repeating back of instructions to the control tower or Air Traffic Control.  Sometimes these instructions are pretty complicated and the pilot has to write the instructions down and read them back.  Obviously the reason this is so critical is that the controller needs you to carry out his instructions and the first step in this is that you correctly heard these instructions.  But that is not all there is to it.  The pilot must understand these instructions to carry them out and maintain the safety of flight operations.  After the pilot hears, writes and repeats then the training tells the pilot check his understanding of the instructions.  If they are not understood the pilot must ask for a clarification and the whole process starts over again.  In this domain, the pilot generally understands the instructions because their preparation and training make most of these instructions routine.

As software developers, when we get our “instructions from ATC”, that is our requirements, they are often written rather than spoken. How well we understand those instructions depends on a number of factors starting with how well they were understood by the person writing them and their skill in putting them into words.  However a document does not have the built-in feedback loop that is required of pilots!  It is also very common for us to understand every word in the document, yet not have a clue what they are talking about or even worse think we understand perfectly when we really don’t have a clue.

Using the process of Acceptance Test Driven Development is one of the quickest and easiest ways to increase the pace and quality of business value delivery from your software development team.  Stating back our requirements to check understanding, while valuable, would be expensive and boring if all we did was create a new document and rewrite the requirements in more technical terms.  However if we could create this early validation that we understand the requirements in such a way as to be able to check the product’s progress toward meeting those requirements, then we might have something valuable and not so boring!

There are a number of tools being used to create Agile Acceptance Tests, but by far the most well known and popular is the FIT/Fitnesse family tools that allow you to create Agile Acceptance Tests for a number of different languages and platforms.

Introduction to Fit



Setting up Fitnesse requires a little history. FIT: Framework for Integrated Test was developed by Ward Cunningham and several collaborators.  I found pages on fit.c2.com from as early as 2001, so needless to say FIT has been around for quite a while.  In the introduction, Ward states that great software requires collaboration and communication.   FIT provided a basis for that two-way communication between the stakeholders and the team members.  Through the use of the various tables that were used to explicitly demonstrate the requirements, the team could create automated tests to check the current status of any requirement set up with these top-down tests.

While this is a great idea and a pretty good implementation, more was possible.  Bob Martin and his collaborators wrapped the FIT testing engine in a Wiki (which was a Ward Cunningham invention) and created FitNesse.

Here is how Wikipedia defines a Wiki:
A wiki (/ˈwɪki/ wik-ee) is a website that allows the creation and editing of any number of interlinked web pages via a web browser using a simplified markup language or a WYSIWYGtext editor. Wikis are typically powered by wiki software and are often used collaboratively by multiple users.

By wrapping the test engine in a Wiki, Martin and his collaborators enabled even more communication between the stakeholders and the development team.  Ideally the stakeholders would either record the requirements in the FitNesse Wiki and describe the scenarios with examples.

The original FIT was developed in Java.  Many developers added other platform implementations enabling the the use of FIT and FitNesse on the majority of application development projects.  This was a good thing, but there was a big problem.  Because of several factors including the desire to one-up other implementations, all of these implementations were different.  When I first started working with FIT, I downloaded it, installed it and then tried to use the included instructions to use the then current .NET implementation.  I tried for several hours!  After some searching, I found a nice article that discussed the setup for a .NET project.  This article was written by Gojko Adzic who remains a big contributor in the FIT/Fitness space.  My experience was typical and others spent days trying to get the FIT/Fitnesse port on their platform working.  The main problem was that all the implementations were different.  You could not always use what you learned on the Java implementations to set up the platform you were working on.

A few years later Martin and his team offered us an alternative to the FIT testing engine that makes this process much easier.  The Simple List Invocation Method is an alternative to FIT.  It is built into FitNesse.  Slim keeps the HTML processing, comparisons and the results output in FitNesse. In other words when you are using Slim, it does not call out to the FIT server to process the test results.  The big advantage is the fact that Slim is very slim.  It is easy to port because the calls to an external port are made with the same loosely coupled calls that are used with the internal Java implementation.  This allows all of the ports to be identical from an external API point of view.

Today FIT and FitNesse with Slim combined with the port for your platform provides a very powerful and capable set of tools to create and run top-down Agile Acceptance Tests.  FitNess and the .NET port of Slim and FIT are all in active development and you can use various online resources to get help and advice from other users and even the authors.

Setting up FitNesse

The place to start is the home of FitNess at http://fitnesse.org/.   Not too surprisingly this is a FitNesse implemenation.  It contains links to download the Java Jar file, Java source code and links to all known plugins and accessories.

FitNesse Plugins

First you need to downlaod the fitnesse.jar .  Save it to a convienet location on your computer.

A Java Jar file is just a zip file that contains the folders and files of the application.  It is roughly analogous to a .dll.  Fitness.jar is an executiable Jar file.  It is run by calling the Java runtime engine.   If you don’t have a Java runtime on your computer you will need to download the latest Java runtime engine from Java.com.

Next you need to decide where you want to put your FitNesse implemenation.  I like to keep my primary installation on the root drive of my computer.  I create a folder called FitNesse and copy the fitnesse.jar file there.

The next thing you need to decide is what port you are going to use for your FitNesse server.  Running the FitNesse.Jar file the first time unpacks the FitNessRoot which will be the repository of your wiki pages.  Then it starts the FitNesse server.

The command line looks like this…

java -jar fitnesse.jar

There are a number of optional command line switches, but the most important one is the -p which sets the port where the FitNesse server runs.  If you don’t use this switch it will try to run on port 80 where your web server probably runs.  It is a very good idea to include -p switch with an unused port like 8080.  So the full command line would be like this…

java -jar fitnesse.jar -p 8080

I don’t like to type that much, so I create a batch file to run the command put it in the fitnesse folder.  It would look something like this…

start java -java fitnesse.jar -p 8080

If all goes well you will get something like this is the command window that was opened by the batch file.

If the server does not start, take a look at the page on the fitness.org site http://fitnesse.org/FitNesse.UserGuide.FitNesseWontStart .

Then you can open your server with your favorite browser.

http://localhost:8080

Mine is going to look a bit different, but you should get the Fitnesse server.

Configuring FitSharp

At this point you have the base Java system up and running.  To enable .NET testing there is one more component and some configuration to do.

On the plugins page you may have noticed the .NET Slim implementation by Mike Stockdale.  It is located at https://github.com/jediwhale/fitsharp/downloads .  The site has both .NET 3.5 and 4.0 builds. Download the one that is approriate for your development environment.  The latest download has all the source and the entire binary history of the product.  Extract the files from the zip and copy the files from the latest binary into a folder on your system.  I put this folder in the fitnesse folder where you copied the Fitnesse.jar.  You can name this folder anything you want,but you will need to reference it in the next step.   I use dotnet2 with is a legacy name for me because of having tests set up from when support for .NET 2.0 was the latest.

When that is done, you are ready to go.  A future article will go into the details of how to use the system but for completeness on setup, there is one more step.

At the top level of a suite of tests ( or on any test page where the configuation is different ) we need to define four variables.  The first is the test system to be used.  This is how it would look in edit mode on the wiki for a slim test.

!define TEST_SYSTEM {slim}

Next is the command pattern which includes the full path to the fitsharp.dll.  Note  your path may be different.

!define COMMAND_PATTERN {%m -r fitSharp.Slim.Service.Runner, C:\Fitnesse\dotnet2\fitsharp.dll %p}

Next is the test runner.  Again your path may be different.

!define TEST_RUNNER {C:\Fitnesse\dotnet2\Runner.exe}

And last is the path to the .dll with the tests.  Put the full path and file name on the line.

!path

Here is what it looks like in edit mode…

And after you save, the page will look like this…

That’s all for now!  Watch for a new article every couple of weeks or so.  The next article will be an overview of the Slim tables and how to use a simple Decision Table.

Feel free to post messages with your questions so others can share in your experiences!

Tags: , , , ,
Posted in Agile Engineering Practices | Comments (1)

Claiming PMI PDUs for Your Scrum Training

August 9th, 2011
by Rod Claar

As you PMPs know, you need to continue to learn and progress to keep your PMP designation.  The good news is that your CSM and CSPO training probably qualify as PDUs with the PMI.  I say probably because it is the PMI that decides, not me!  ;>)

The process to claim your PDUs is pretty straightforward.

Go in into your PMI profile and go into claim PDUs
Use category 4
Select whatever areas of the PMBOK you think the ScrumMaster training covered – knowledge areas/industries/etc
Put in RippleRock, LLC as the provider

RippleRock address:

RippleRock, LLC
9465 Counselors Row
Suite 200
Indianapolis, IN 46240-6423
Phone – 863-949-4420

You can claim 14 PDUs for a 2 day class.

It will be reviewed by the PMI and approved – usually this happens in a day or two, sometimes immediately.

Tags: , , ,
Posted in Scrum | Comments (0)

The Application Process for Scrum Alliance Certified Scrum Developer

August 9th, 2011
by Rod Claar

So you have taken the required training for your Certified Scrum Developer from the Scrum Alliance and you are wondering how to actually get the certification.  Here is how it works today.

This certification requires 5 days of training.  The first two days could be a CSM class or a CSPO class.  RippleRock and others also offer other approved training that does not lead to a certification but is approved for CSD.  The other three days must come in the form of a Scrum Alliance approved engineering practices course.  Our Effective Scrum Developer course is the first such class that provides training on the .NET platform.  Our Scrum for Teams and Certified Scrum Developer Training Week programs are SA approved to provide all 5 days and if the instructor is a Certified Scrum Trainer, they also provide the CSM designation.

The next step is to get the application form.  You can download it from the SA site at http://www.scrumalliance.org/pages/certified_scrum_developer .  The application includes the information about how to sumbit your application.  You will need the course names, dates and instructor for the qualified training.  This information is available in your Scrum Alliance profile on the SA site.

Once your application is reviewed and verified by the SA staff, you will recieve an email with a link to pay the $150 fee.  Once you complete this process you will be able to download and print your CSD certificate.

Currently there is no assessment for the CSD certification.  The instructor and class are approved by the SA and the instructor certifies that you attened, partcipated and learned.  This may change in the future.

Tags: , , ,
Posted in Scrum | Comments (2)

The Current Certified ScrumMaster Process

August 9th, 2011
by Rod Claar

I’m getting a lot of questions about how someone who has taken a Certified ScrumMaster class like my Certified ScrumMaster Workshop goes about actually securing their CSM.

The CST will upload the list of attendees for each class and pay the fee for your initial Scrum Alliance membership.  This associates you with the class you attened.  At this point the Scrum Alliance site sends an email to the address uploaded by the CST with a link for you to take the assessment.  If you did not recieve that email, please check your spam folder and then contact your CST and they can cause the SA site to resend the email.  Note that this is only done if you have never logged on to the SA site because this resend process also resets the member’s password.

Using the link in the email from the SA site you can take the assessment.  Currently this is just a personal assessment.  Everyone passes.  However you can use the results to see where further study or experince might be helpful.  Your CST cannot see your personal score, but we can see the average score for each class.

Once you take the assessment you will recieve another email from the SA and be able to print your CSM Certificate.

Tags: ,
Posted in Scrum | Comments (0)

Effective Agile Testing

July 15th, 2011
by Rod Claar

No Bugs!We are pleased to announce the launch of a new course designed to help enterprises deliver more business value faster by improving the quality of their software products with Agile Testing.

Agile Testing is not a new idea, but with this new course, we are bringing all the concepts together in a team based course.  The first release will be for .NET developers, but the concepts will be applicable to any development platform.

As with my other recent courses, I started with a single user story to drive the development of the course.

As a Tester on a Scrum Team, I want to work to prevent defects in the system and clearly define the business goal so that the team can deliver the right business value with an appropriate return on investment.

This is really saying a lot.  The course is aimed at developers who do testing on a Scrum team.  Then it talks about the prevention of defects rather than testing for defects. Lean principles tell us to build quality in.  Agile testing works for this goal by moving testing forward in the process.  Traditional testing often has little to do with actual code quality and insuring that the team builds the right solution.

Course Objectives

  • Scrum Team Collaboration
    The teamwork and collaboration on a Scrum team
  • Agile Acceptance Testing
    The principles that help teams understand and deliver the right business value with a requirements by example ap-proach.
  • Test Driven Development
    Using the practice of Test First to help ensure the require-ments are well understood and automated tests can be added to the build process to validate the system in the future.
  • Refactoring
    The process of improving the design of software to increase the understandability and testability of the code and allow for easy and safe additions to the system in the future.
  • Automated Acceptance Testing
    The process of creating and running automated acceptance test suite using the appropriate tools and techniques for the application layer being built.

For more information, please check the course page on the Effective Agile Development web site or feel free to contact me directly.

Tags: , ,
Posted in Agile Engineering Practices | Comments (0)

Agile Technical Software Product Specification

May 7th, 2011
by Rod Claar

Technical Software Product Specification

In a Complex Regulatory or Standards Based Domain

Our approach to the process used to develop technical specification in a complex regulatory or standards base domain includes appropriate, timely and effective inspect and adapt cycles. Software development professionals who believe in the principles of Scrum, Agile and XP often point to issues relating to up-front design by discounting the ability of the design team to create suitable design, architecture and specification at a point in the project where the team knows the least about the project. They also often point out that the creation of a comprehensive technical specification is inherently wasteful and actually delays the real start of the project, thereby delaying the delivery of business value. While there is significant validity to these statements, we believe that a pure story driven approach is also flawed. The originators of eXtreme Programming often are accused of relying totally on the TDD process to evolve architecture and design. While many XP teams used this as an excuse to do not up-front planning the true originators did have a basic model that was developed early in the development phase. However, all too often this model was not updated and became outdated and useless.

Identification of Technical Risks

They key in an effective Agile approach to complex project design and architecture is to provide and utilize inspect and adapt cycles for the design to grow as the development progresses. Some initial analysis and design work is required to prime the process. In most instances this process starts with the analysis of potential technical risks in the project. This can include items like new or updated languages, new or updated platforms, new integration points or methods and standards or regulatory compliance requirements. This initial phase may include some investigation of the new or unique areas in the form of samples, spikes and prototypes. However, reliance on these methods is also rarely sufficient.

Initial Architectural Design

The next step is to define an initial high-level architecture. Traditional approaches to architectural design are often focused on classification and organization of system components. This can be done relatively well where the problem lends itself to a layered design where the logical layers coincide with the concepts in the problem domain. Other approaches include the “nouns and verbs” method or tall, inheritance driven, Object Oriented designs. There are several other similar approaches that result in designs that are difficult to understand and maintain, use multiple inheritance, are too tall from an OO perspective or only seek to make functionality easy to find in large codebase.
We believe that architecture should be more about identifying the major areas of concern or concepts in a system rather than creating an organizational scheme. The goal should be to separate these concepts so that as the design evolves or new requirements emerge, they can be accommodated by adding to the solution rather than changing previously developed components.
Once these concepts are identified and briefly described, the relationships between them will begin to be discernable. Many of these relationships will be recognizable as examples of or similar to software design patterns described by the leading experts in the discovery, description and use of software design patterns.
Care must be taken to not add too much detail at this point as the team has only begun to identify the problem domain and it is very easy to define a system where tall class hierarchies are used for specialization of behavior.
The appropriate use of the abstractions identified in the discovery of the concepts can lead to a more maintainable, flatter class hierarchy that is easy to extend while preserving understandability and maintainability.

Identification of Appropriate Layers and Layer Interfaces

Once this initial design is defined it is often appropriate to identify the logical and/or physical layers or workflow steps in the solution. This often results in the grouping of concepts into these conceptual layers. Caution must be exercised to leave the design open to extension through the appropriate use of abstract classes and Interfaces. Here again software design patterns will be identified. Particular attention should be given to the programming interfaces between the concepts and layers that have been identified. These interfaces should be simple yet sufficient.
As these concepts and layers are identified, it is very beneficial to be aware of the concept of dependency inversion. Simply stated, the service class should be dependent on the needs of the client class for the interface of the service class.

Prioritization of Target Scenarios to Mitigate Risks

At this point the analysis can turn to the target scenarios that will help mitigate the risks identified. These scenarios would be packaged into an early release of minimal functionality intended primarily to provide a vehicle for mitigating the top risk issues.

Development of Initial Product Roadmap and Release Plan

Then the initial Product Roadmap and Release Plan can be started. This analysis only needs to be at a high level and should only commit to the customers and/or stakeholders the features that are truly must-have for a minimum release. The goal should be to release the smallest set of features possible that deliver any business value. We recognize in a standards or regulated environment, this may be more than we would normally recommend, but the traditional approach of trying to get absolutely everything in a release in still inappropriate.

The Delivery of an Increasingly Capable Product

In most cases, the calendar time to reach this point should be a few weeks and the cost should be significantly less than a traditional full analysis and specification project. Yet the risk will be significantly reduced. This Product Roadmap and Release Plan should identify a minimum scope for initial commercial or internal viability. This set can be used to set the initial budget for the project, which should be significantly less than the budget for release of a traditional project. In fact, in many cases a large proportion of the anticipated full functionality can be delivered for less than half the traditional initial budget.
The process of identifying the next set of minimum, focused, value centric features continues at the fastest pace possible, consistent with the ability of the target market to accept and deploy low risk, incremental deliveries.

More Business Value, Less Business Risk

Scrum and Agile are about the mitigation of risk in software product development. It has been proven many times that the traditional approach of trying to specify and estimate the project in project approval phase leads to poor results, especially in domains where technology and markets are changing rapidly. The approach we use will enable an enterprise to deliver significantly more business value faster with much less waste and risk compared to traditional methods. This is not a simple transformation for the existing enterprise and almost always requires outside help to be successful. However the market advantage gain can be enormous.

Tags: ,
Posted in Scrum | Comments (0)

Clearing the air on Scrum Alliance Registered Education Provider Program

April 28th, 2010
by Rod Claar

There have been a lot of negative comments about the new Scrum Alliance Certified Developer program lately. One web post referrs to the organizers of the program and presmuably the participants as “festering money-grubbers” .

Let me clear a couple of things up about the CSD program. For full disclosure, I’m on staff with the Scrum Alliance helping administer the program.

Firstly, focusing on the CSD is a little short sighted. Certified Scrum Developer is the first training program in the new Scrum Alliance Registered Education Provider program (SA-REP) http://www.scrumalliance.org/SA-REP. The Scrum Alliance is seeking applications from training organizations that have something to offer the Scrum community. There are 10 organizations listed right now and several more are in the final stages of approval, including a branch of a major university. These organizations are screened for experience and demonstrated expertise in developing and administering training programs. The application process also reviews the resume of each course designer and trainer submitted by the applying organization. Lastly each course is reviewed relative to the leaning objectives for the program. Once a new SA-REP is approved and they have approved courses and trainers they are given the ability to list public courses on the Scrum Alliance site.

The SA-REP program is also setting up to assess and review the courses and trainers that deliver training in the program. The details of how this will be administered is still under development, however the goal is to help improve the quality of training and give students they information they need to select training that is valuable to them.

The CSD program is an SA-REP program. Every SA-REP that submits a course and trainers for CSD-Eligible status are reviewed as I described. The program includes Scrum knowledge as well as an aggressive set of technical learning objectives for developers working on Scrum teams. These include the practices of Test-First, Test Driven Development, Continuous Integration, Agile Analysis and Agile Architecture.

So far we have 2 Java based programs approved and one .NET. We have applications currently being reviewed for Ruby and another Java program. There are training opportunities currently available on four continents.

With the massive improvements in Visual Studio 2010 and the new Application Lifecycle Management abilities of the new Microsoft Tools the Scrum Alliance is seeking qualified and experienced trainers on the platform. This why the application asks if the trainer is qualified in this area thought the programs listed. The application process reviews the Scrum training ability and experience of all applicants and if any trainer does not have demonstrated experience in Scrum, the Scrum Alliance will work with the organization to partner with an experienced Scrum trainer to help them with that part of the program.

BTW, I don’t see any “festering money-grubbers” listed as SA-REPs. Who are you referring to? I see qualified, experienced training organizations offering much needed training for developers and other professionals working on Scrum teams.

If you have any other questions about the SA-REP or CSD programs, feel free to contact me directly.

Rod Claar
SA-REP /CSD Program Community Liaison
rclaar@scrumalliance.org

Posted in Misc | Comments (0)

INDUSTRY VETERAN ROD CLAAR JOINS RIPPLEROCK TO LEAD THE NORTH AMERICAN AGILE PRACTICE

March 25th, 2010
by Rod Claar

LONDON, INDIANAPOLIS, Mar. 26, 2010 – RippleRock recently recruited industry veteran trainer and Agile Coach Rod Claar. Rod is an internationally recognized leader in the area of software development. His special focus is on large teams and projects to increase the velocity of software development through coaching, training, and consulting. He has spent considerable time in the classroom training on Design Patterns, Test Driven Development, Scrum, and Agile Methodologies. Not only does Rod speak to all levels of an organization effectively, he also spans many technologies in the Application Lifecycle Management (ALM) space to take advantage of software tools to increase visibility and productivity of teams. By combining methodologies and tools along with world-class training, Rod is a powerhouse of experience and wisdom. His witty sense of humor and gaming theory is also a pleasure to work with. “Rod’s passion, caliber and experience are a huge asset to our team, really strengthening our hand for our mission of enabling better software. I am absolutely delighted to be working with Rod!” said Founder Colin Bird. The Company along with partner Microsoft® are assisting customers with services ranging from training to technical implementation of best practices to reduce cost and improve quality.

ABOUT RIPPLEROCK

RippleRock formed in 2009 with the mission to assist customers drive dramatic improvements in their software development capability. The Company applies expertise across the full lifecycle; facilitating organizational transformation to enable Agile practices, all the way down to improving engineering practices within the teams.

The team at RippleRock has a strong track record in the Agile space, coming together from various organizations in the industry to bring together a new company unheard of in the Agile consulting space. As a specialist in this area, the Company also offers access to the most experienced Agile coaches, trainers and consultants with a particular mix of skills required to work with people, process, organizations and tools.

RippleRock has bases of operation in the UK and US and travel to Europe and India as part of engagements.

Tags: , ,
Posted in About Rod | Comments (0)

SEO Powered by Platinum SEO from Techblissonline