Introduction

The Agile coach is a critical role in helping leaders, teams and individuals understand, adopt and improve Agile methods and practice. For new and aspiring coaches, starting a coaching engagement can be daunting. It is easy to become distracted from the original mandate and get embroiled in the issues and politics of the team. The following tips were put together to help Agile coaches stay focused and achieve successful outcomes.

Before beginning an engagement with a team try to define success in terms of measurable outcomes and a realistic timescale. Share the outcomes with the team and sponsor to ensure there is a shared understanding of what you are trying to achieve. This will help clarify your role within the team and can help reduce any fears the team may have about the coming changes. Setting a clear end date will also ensure that both you and the team are clear that the team have to own and understand their way of working.

Showing the team how it is done the first time then supporting them as they take ownership of the new way of working is a great way to bootstrap new practices and build trust in new practices. Role model behaviours you want to see in the team. If there are techniques or technologies you cannot model yourself, you may need to mentor an enthusiastic team member or bring in an expert.

There is always a temptation to get involved and help with the team’s delivery work – especially when you see them struggling. While this may offer some short term help and can be useful as a learning exercise, it is unlikely to help in the long term. Becoming part of the team will also make it difficult to have tough conversations with team members, call-out unproductive behaviours and stay focused on your coaching objectives. Try to stand back, your role is to support the team and let them take credit for their success.

The team has probably faced a majority of the issues long before you got involved. If they are to own the solution after you have gone, it is important to have them involved in the decision making process. Remember you are trying to help the team learn to work without your help. This sometimes means you have to let them make a decision that goes against your best judgement. Teams need to learn by their mistakes (and sometimes their idea works out which means you can learn something too).

People can adapt to change more easily when it happens slowly and they see how it aligns to an overall plan. Additionally, change becomes natural when you are able to create a safe learning environment for the team that encourages experimentation. Try to change the practices that are causing problems first replacing them with simple alternatives. If you take away all the old practices that a team depended upon they can lose their way and not see the dysfunctions for themselves.

Asking questions is a fundamental skill for an Agile coach and can be used to drill down to the root cause of problems a team is facing. Don’t be afraid to ask “why” a couple of times to get to the facts behind a problem or to introduce the elephant in the room. As a coach you are in the privileged position of being able to raise sensitive issues and to legitimise discussion of difficult issues.

Helping the team identify what is important (especially from a customer’s perspective), making it visible and updating it regularly will focus a team. Example metrics include: throughput, cycle time, delivered value and many others. The corollary to this suggestion is that you need to be careful what you measure because you can incentivise behaviour that has the potential to be counter-productive.

Although the Agile journey is important, Agile perfection is not the end goal. What does matter is delivering what your stakeholders want in a sustainable way. For this reason it is important to use Agile maturity assessments and other metrics with care. Helping a team become agile should focus on instilling Agile values and principles, while selecting and adapting Agile practices to help the team deliver.

Summary

Becoming an Agile coach requires a deep understanding of Agile, the confidence to drive change and a willingness for self-reflection. The role of an Agile coach is a rewarding one that allow you to use a wide range of skills across technical, social, business and communication disciplines.

Senior management often view automated testing as a silver bullet in reducing testing effort/costs and increasing delivery speed. While it is true that automated tests can provide rapid feedback on health of the system, all approaches to automated testing are not created equal and there are some gotchas that should be avoided.

1. Envy

Flawed comparison between manual testing and automation

Automated tests are not a replacement for manual exploratory testing. A mixture of testing types and levels is needed to achieve the desired quality mitigate the risk associated with defects. This is because testing is not merely a sequence of repeatable actions. The automated testing triangle originally described by Mike Cohn explains the investment profile in tests should focus at the unit level and then reduce up through the application layers.

2. Gluttony

Over indulging on commercial testing tools

Many commercial testing tools provide simple features for automating the capture and replay of manual test cases. While this approach seems sound, it encourages testing through the user-interface and results in inherently brittle and difficult to maintain tests. Additionally, the cost and restrictions that licensed tools place on who can access the test cases is an overhead that tends to prevent collaboration and team work. Furthermore, storing test cases outside the version control system creates unnecessary complexity. As an alternative, open source test tools can usually solve most automated testing problems and the test cases can be easily included in the version control system.

3. Lust

Loving the UI so much that all tests are executed through the UI

Although automated UI tests provide a high level of confidence, they are expensive to build, slow to execute and fragile to maintain. Testing at the lowest possible level is a practice that encourages collaboration between developers and testers, increases the execution speed for tests and reduces the test implementation costs. Automated unit tests should be doing a majority of the test effort followed by integration, functional, system and acceptance tests. UI based tests should only be used when the UI is actually being tested or there is no practical alternative.

4. Pride

Too proud to collaborate when creating tests

Test driven development is an approach to development that is as much a design activity as it is a testing practice. The process of defining test cases (or executable specifications) is an excellent way ensuring that there is a shared understanding between all involved as to the actual requirement being developed and tested. The practice is often associated with unit testing but can be equally applied to other test types including acceptance testing.

5. Sloth

Too lazy to maintain automated tests

The cost and rapid feedback benefits of automated tests are best realised when the tests are regularly executed. This has the effect of highlighting failures and providing continuous feedback about the health of the system. If your automated tests are initiated manually rather than through the CI continuous integration system then there is significant risk that they are not being run regularly and therefore may in fact be failing. Make the effort to ensure automated tests are executed through the CI system.

6. Rage

Frustration with slow, brittle or unreliable tests

Unreliable tests are a major cause for teams ignoring or losing confidence in automated tests. Once confidence is lost the value initially invested in automated tests is dramatically reduced. Fixing failing tests and resolving issues associated with brittle tests should be a priority to eliminate false positives.

7. Avarice (Greed)

Trying to cut costs through automation

Testing tool vendors often try to calculate a Return-on-Investment based purely on labour savings. This analysis is unreliable and under values the importance of testing, the investment required to adopt automation practices and the ongoing maintenance costs.

Summary

Automated testing is not without pitfalls and some of these are identified here. There are of course many other anti-patterns for automated testing that justify further discussion.

Agile methods have been found to improve the reliability of project delivery in complex environments, by decomposing the scope into small manageable parts, then completing these parts in order of greatest value. Although Agile and Lean methods share many common values and principles, Agile methods have not been properly investigated as a means of reducing the overruns associated with large scale construction projects.

In the presentation below I explore the similarities and differences between Agile, Lean and Construction.

STANZ is the region’s premier software testing conference and this year is being held in Melbourne and Auckland. The conference has attracted speakers and authors from around the world including Karen Johnson (Co-Author of Beautiful Testing) and Goranka Bjedov (Capacity Engineer at Facebook).

The key artefacts we discussed are linked below:

• Defining Quality Workbook
• Quality Focused BVC
• Agile Test Strategies
• Agile QA Practices

At the recent Agile Australia 2011 conference I discussed the nature of technology Startups and the application of Agile principles, practices and tools. Additionally,I shared some real life experiences in the application of Agile in Ennova through the development of Envision.

Each team was set the task of building the same lego model. Team A started with drawings for each build step and a box of unsorted lego parts. Team B started with the same drawings and the same lego parts. However, they were also provided with a part list for each build step and the parts were pre-sorted into groups. The teams started at the same time and within minutes both teams had self-organised and were progressing with their models.

The progress of each team was tracked and plotted against time then displayed on a big screen to demonstrate the productivity of each team. Within minutes Team B was able to demonstrate the benefits of WorkFace planning by achieving progress milestones in substancially less time than Team A. We included some real-life complexities in the exercise such as missing parts and site delays. These further demonstrated the benefits of WorkFace planning.

The exercise was well received and the ensuing discussion provided the inspiration for a discussion paper on using ideas from Kanban systems to support the visual management of Work Packages.

Agile Australia 2010 was one of the best conferences I’ve been to in a while. The following are my brief notes from the sessions I attended.

I really enjoyed the conference and met some great people – looking forward to next year.

I discussed some of the Agile principles and practices relevant to a startup and demonstrated some of the tools used by Ennova. Despite numerous technical issues (which rendered the video unusable) the content stimulated heaps of questions.

Craig Smith and Fiona Mullen have reviewed the presentation and the full slide pack is now available on SlideShare.

Thanks to all those who attended.

In the example discussed below, I was asked to create a process for developing an estimate that satisfied the above requirements. Rather than simply creating process flow and swim-lane diagrams, I tried to consider how the process could be adapted and matured over time as the organisation changed over time. In doing so I found the many agile/lean principles were being subtly introduced.

Strategy

As is common with most things, your first design isn’t going to be perfect and it will require progressive enhancement. With this in mind, my approach was to start simple, develop the most minimal process and then provide support in the form of training, infrastructure (tools, templates etc). Realising that my first iteration of the process would be a tactical solution allowed me to move past trying to make it perfect and enabled me to focus on the bigger picture of how the organisation could adapt and mature the process.

Establishing the Current Issues

To begin with I reviewed the state of the current estimation practices from a number of different perspectives including developers, project managers, business analysts and solution architects. I have included the results together with comments below as the issues are probably common to many larger organisations.

Key Training and Process Concepts

Based on the identified issues, I designed the training materials to focus on a number of key concepts. Additionally, I structured the process documentation inline with the following methodology for process design.

1. Design
   Purpose
   Context
   Documentation
2. Metrics
   Derivation
   Uses
3. Ownership
   Identity
   Activities
   Authority
4. Infrastructure
   Tools
   Templates
5. Roles
   Skills
   Knowledge
   Behaviour

This approach is based on work by Dr. Michael Hammer and is simple, but ensures that the major process areas are considered.

What is an Estimate?

An estimate is an informed assessment of an uncertain event. Informed means that there is an identified basis for the estimate, and uncertain recognizes that multiple outcomes are possible.

Why Estimate?

There are many reasons why estimates are created, but here are three important ones.

• Estimates enable assessment of value. An estimate enables the customer to determine if the cost of the deliverable matches the expected value.
• Estimates enable prioritisation of work. Once the estimated size of a task is known its value can be determined and therefore priority assigned.
• Estimates assist planning. The process of preparing an estimate begins the process of planning a project and identifying task, skills, constraints, etc. This process adds value during project implementation.

Who is Accountable?

It is common for project costs and/or timescales to be exceeded and for the person who developed the estimate being held to blame. To discourage this type of behaviour I tried to create a culture where everyone involved is held responsible for developing an estimate. In the event that the estimate is wrong, the whole business suffers, therefore it is in everyone’s interest to get the estimate as accurate as possible based on the given requirements.

Redesigned Process

1. Design – Overview

As mentioned earlier, I created a minimal and generic process because the majority of estimation tasks are different and this approach would provide the necessary flexibility and business agility. The process encourages collaboration and communication by incorporating 3 separate meetings and a number of progress discussions.

The process starts with a discovery meeting that occurs once a request for estimate is received together with a definition of solution requirements. This meeting is intended to set expectations around project scope, maturity, estimate timing and estimate uncertainty. Coming out the meeting is a decision verifying that the maturity of the solution matches the expectations for an estimate in terms or timing and uncertainty.

Moving forward, an estimate leader is assigned who has the responsibility of coordinating the creation of the estimate by drawing together the relevant technical inputs. As the time taken to gather the necessary data may span weeks (especially if key staff needed to be scheduled), it is suggest that the estimate leader provides progress advice to the customer/project manager to ensure that the process does not become a black-box.

Once the majority of technical tasks are identified and estimated a peer-review meeting is arranged to provide an independent review. Typically, experienced technical staff would review the estimate ensuring that lessons from past projects are incorporated and the estimate can be properly justified – especially when compared to previous similar projects.

The handover meeting is intended to discuss the final estimate with the customer and project manager and review task breakdown, estimate, confidence level and assumptions. Once accepted the estimate is closed and the documentation and register updated.

2. Metrics

Without metrics, a process cannot be properly measured and evaluated. The metrics proposed were intended to encourage practices that would address the identified issues.

3. Ownership

A single person (and their role) was nominated as the process owner. This helps facilitate process change as they are able to approve process improvements.

4. Infrastructure

The infrastructure for this process consisted of templates that assisted the preparation of an estimate. The templates help ensure that the process can be consistently followed. Additionally, a file structure was established to support organisation of the documents supporting estimates as shown below.

5. People

The responsibilities for the roles of Project Manager, Solution Architect, Business Analyst, Application Architect and Estimate Leader were clearly articulated in the training documentation.

Improving Estimates

While there are numerous references in estimation, I tried to extract some key principles that would be easily adopted as part of the process. These included:

• Leveraging past experience on similar projects
• Capturing better quality requirements
• Utilizing multiple estimation methods
• Prioritise requirements to ensure estimation concentrates on high priority
• Scheduling resources rather than relying on just effort estimate

Task Breakdown

I always recommend using as many different methods as possible to arrive at an estimate but starting with an initial task breakdown is a good starting point and helps with planning the project. The following are some guidelines on task breakdown.

Decompose tasks into activities that can be estimated.

• Tasks smaller than ½ day is probably too small
• Tasks larger than 1 week are probably too large

Link technical tasks to functional requirements where possible – or to a general/common group. This helps when a functional requirement is removed the effort to change the estimate is minimised. For every task consider the following:

Everyone has different preferences on which tools are best for task planning but I generally use a spreadsheet as tools vary between organisations and spreadsheets offer good flexibility. In some cases I have setup template spreadsheets but rolling your own is pretty straightforward.

Adding Uncertainty

Typically uncertainty is added as a percentage of the estimated effort for the task. The effect of applying the uncertainty is that upper and lower limits of the estimate are created. These effectively provide a range that the actual effort/costs should fall within.

It is important to remember that the upper limit should be used for reserving budget, while the un-adjusted estimate should be used for scheduling tasks and resources. This is because schedule typically drives cost so planning effort against the unadjusted effort gives the most realistic requirement of resources. Planning against the upper value of effort would tend to keep resources working against a task longer than expected and therefore tend to increase costs.

Adding Contingency

Generally an estimate is based upon the most realistic scenario, and then contingency is included to account for uncertainty (known unknowns NOT unknown unknowns). It is important to be transparent about where contingency is being added so that (a) contingency it is not added in more than one place, and (b) contingency is not assumed to be included when it is has not been included. The need for contingency arises from things like staff skills and experience, project familiarisation, staff availability, task management, meetings, progress reporting, etc.

Summary

Estimation is a deceptively complex activity and I have tried to simplify and incorporate into a process that can be easily adopted by a large organisation. However, it is important to remember that processes have a level of maturity which often includes deficiencies, gaps or missing decision points. Therefore, for a process to be successful, the participating people need to collaborate and use the process as a guideline. Over time a process matures and the tools/artefacts improve and the tacit knowledge penetrates into the business, hence attitude and support is critical to the success.

The session title is “Leading the Future: Is a new management paradigm a precondition for sustainability transition”. The other panelists have interesting backgrounds so hopefully we’ll get some good discussion and audience interaction. I’ve included an overview of the conference below.

Conference Overview:
The conference is designed to attract a diverse local, national and international audience including community organisations and NGOs, large and small business, all spheres of government, academics, social enterprises and philanthropic trusts, writers, artists, community development practitioners, policy makers, and environmentalists. Participants from over 30 countries from the Oceania Region and around the world are expected to attend.

Normally this is a pretty fail-safe approach (used by consultants globally) but I was a bit disturbed by how little information related to this activity. Apart from one excellent post and subsequent discussion – there was little to go on.

As I got further into the project I found there were some significant challenges in applying Agile methods to a large systems integration project. Below is a summary of the challenges faced for this project in utilising an Agile approach.

Project Background

The project involved a major upgrade to the transportation (rail and ship), materials handling (conveyor, stackers/reclaimers and stockpiles) and logistics planning systems for multiple port facilities. The customer had the opportunity to undertake a upgrade of the existing systems and planned to eliminate some legacy systems and to improve the overall functionality.

Historically, the customer had managed projects using a methodology based around PMBoK but realised that benefits exist in leveraging Agile methods to reduce delivery timescales and risks. Unfortunately, the customer had no experience in executing a project using Agile methods.

Challenges and Strategies

One of the first challenges was to increase the general understanding and awareness of how Agile methods compare with traditional project execution methods like PMBoK, that are much better understood by the customer. I found The Software Project Manager’s Bridge to Agility by Michele Sliger and Stacia Broderick and excellent resource – especially the mapping between Agile methods and the PMBoK processes.

The other challenges are identified in the table below, together with the mitigation strategies.

Functional Coding Style: programs return values, rather than modifying things in memory or in the model.

Declarative Coding Style: there is no “begin” or “end” to a KBE model – only a description of the items to be modeled.

Runtime Value Caching and Dependency Tracking: the system computes and memorizes those things which are required – and only those things which are required (no more, no less).

Dynamic Data Types: Slot values and ob ject types do not have to be specified ahead of time. They are inferred automatically at runtime from the instantiated data. Their datatypes can also change at runtime. In fact, the entire structure and topology of a model tree can change, depending on the inputs.

Automatic Memory Management: When an object or piece of data is no longer accessible to the system, the runtime environment automatically reclaims its memory.

The paper is well worth a read as it provides some interesting historic insight into KBE systems and the deficiencies of pseudo-KBE systems such as CATIA Knowledgeware.

The launch of Google’s Chrome browser has triggered media hype around cloud computing issues.

The ABC’s Background Briefing has a very entertaining podcast and the show page has some great links for further information.

My favorite is the song about life down on the Server Farm.

This image is an interesting picture I found on Brian Solis’ Blog that groups social media web sites in terms of the forum they provide for sharing information, ideas and conversations.

Executable Specifications: Approach, Tools and Benefits

Ideally, requirements would be written in a way that makes it easy for the development team to verify the system against them. Making them executable enables the team members to run them as often as necessary. Executable specifications can be based on stake-holder defined stories and are therefore a means for improving communication and clarifying interpretation.

The benefits to this approach are very compelling. Firstly, there is a much tighter link between the customer and the development team. Secondly, it provides a tool that helps reduce the gap between what your customer wants the system to do, and what the system really does.

RSpec is a Behaviour Driven Development framework for Ruby providing a story framework for describing application behaviour and a spec framework for defining object behaviour.

FitNesse is another tool that is based around a Wiki that enables the collaborative definition and execution of tests.

Both tools present the tests in a form that is more user-readable than your average unit test. This allows stake-holders to see and understand the tests as well as seeing and understanding the test results. In theory it also allows stake-holders to write tests, but in practice this rarely happens.

Engineering Design Verification

Numerous computational tools exist for verifying the structural integrity of an engineering design. These tools are generally based on either finite-element or classical analysis methods. While these tools are very effective in verifying design conformance against specific engineering requirements, they do not provide an effective means of either representing or verifying the design against stake-holder defined requirements.

Additionally, there are tools emerging that support automatic verification of 2D drawing and 3D model representations of a design. An example is the iCHECK product developed by INCAT. iCHECK can help organizations minimize the risks associated with poorly-produced CAD data by applying a series of automated checks.

The available checks include:

• Model meta-data (filename, properties, tags, associations, …)
• Modeling practices (properly constrained sketches, allowed features, feature order, sizes…)
• Model annotations (dimension styles and overrides, line types, colors, …)
• Model visibility setting (render settings, part visibility, …)

One of the benefits of a tool like iCHECK is that a stake-holder can define their own checks and share this directly with the engineering design team enabling them to automatically verify the design for themselves. Although this approach can be effective, it does not verify the design against the actual stake-holder requirements for the part or assembly. This is because the tests focus on verifying the model representing the design rather than the design itself.

Many CAD systems have attempted to integrate tools that capture engineering product knowledge and design rules directly into the model. An example is the CATIA Knowledgeware suite of tools. These tools have focused on the capture and application of business knowledge in an attempt to automate or generatively create, CAD based design data. Unfortunately, the business knowledge required to make these tools effective is generally not available in a suitable form. Additionally, these tools have lacked the technical maturity to be used reliably and the captured knowledge is not in a form that can be persisted or repurposed separately from the tool.

There are two problems that these tools are trying to solve:

1. Automated/generative design based on product knowledge; and
2. Engineering design verification based on product knowledge.

For the solutions to these problems to be effective, there needs to be a recognition of the importance of stake-holder involvement in the capture and execution of the business knowledge (or requirements) that drive the engineering solution. It is often the case that as an organization attempts to capture engineering knowledge a number of recurring problems emerge. Some of these include:

1. Staff generally resist documenting knowledge as part of normal working practices and are even less enthusiastic in supporting specific knowledge led initiatives.
2. Staff tasked with eliciting and documenting the engineering knowledge are too inexperienced to appreciate the significance and implied context.
3. Lack of a commonly used and recognized standard for storing and persisting knowledge.
4. Lack of commonly available tools for automating the capture and persistence of engineering design knowledge.

Note: The last two points may be challenged by those with specialist skills or experience in knowledge management – but I would argue that the lack of industry acceptance suggests that there are still significant opportunities for improvement.

So how could these tools be improved? Could the Behaviour Driven Development approach used in the software industry be applied?

Acceptance Tests as Engineering Design Requirements

As introduced earlier, acceptance testing frameworks are gaining momentum and provide a medium for stake-holders and software developers to communicate a common understanding a how a system should behave. Therefore, one approach would be to facilitate the definition of stake-holder requirements using a structured software approach. This would enable the definition of acceptance criteria for various aspects including structural integrity (strength, stiffness, service life, …), geometry (interfaces, fits, space-envelope, …) etc to be captured. The output from this could be a series executable tests that could be shared by the stake-holders and the engineering designers to run automatically to verify the design as it progresses.

So what would these test look like?
Basing the syntax on RSpec, the tests would be defined as plain text stories.

Story: prevent vibration induced driver fatigue
  As a vehicle driver
  I want to reduce vehicle vibration
  So that I get a quite and comfortable ride

  Scenario: vehicle driving on dirt road
    Given my vehicle has Velocity of 60km/hr
    When my vehicle has RoadRoughness of 1000mm/km 
    Then the Time to reach a VibrationDoseValue of 8.5m/s1.75 is greater than 6hrs

  Scenario: vehicle driving on sealed road
    Given my vehicle has Velocity of 60km/hr
    When my vehicle has RoadRoughness of 200mm/km 
    Then the Time to reach a VibrationDoseValue of 8.5m/s1.75 is greater than 12hrs

As you can see keywords like Given, When and Then would then be translated into software based tests. Additional domain specific keywords (Time, Velocity, RoadRoughness and VibrationDoseValue) together with the associated units (hrs, km/hr, mm/km and m/s1.75) would also be used in the generation of test cases.

There are however a number of enabling technologies needed to make the suggested approach possible. These include:

• A domain specific language or standard for defining engineering acceptance tests similar to that demonstrated above
• A testing framework enabling the execution of tests.
• Closer integration and interoperability between CAD, FEA, CFD and other modeling or analysis tools to facilitate test execution.

As far as I am aware there are currently no initiatives that address items 1 and 2. Progress towards the last item is largely a commercial issue with different engineering software vendors unwilling to trade competitive advantage for data interoperability. Standards for representing engineering data such as ISO 15926 and ISO 10303 are of benefit, however vendor adoption is slow, especially for more advanced definition of geometric features.

Finally, the relationship between engineering industry standards like Vibration Exposure – could be used to form the basis for a series of executable specifications. Together with the normal textual definition of compliance criteria, a set of software based test codes could also be provided to assist stake-holders and engineering designer to verify designs.

The following list is by no means exhaustive but does identify some of the major open source solutions available in the computational engineering domain.

A Complete Package

CAE Linux is a LiveDVD Linux distribution dedicated to computer aided engineering based around softwares Salomé, Code_Aster, Code_Saturne and OpenFOAM.

General Numerical Analysis

Scilab is a platform for numerical computations similar in capability to MATLAB.

Octave is also a platform for numerical computations with a command line language that is equivalent to MATLAB.

SciPy is a software library for mathematics, science, and engineering with a very large community and its own conference.

CAD and Geometry Tools

BRL-CAD is a powerful cross-platform open source solid modeling system that includes interactive geometry editing, high-performance ray-tracing for rendering and geometric analysis, image and signal-processing tools, a system performance analysis benchmark suite, libraries for robust geometric representation, with more than 20 years of active development.

SALOME is a generic platform for Pre and Post-Processing for numerical simulation.

Open CASCADE Technology is a software development platform that includes components for 3D surface and solid modeling, visualization, data exchange and rapid application development.

FEA Codes

FETK is a collection of adaptive FE software libraries and tools for solving coupled systems of nonlinear geometric partial differential equations. The FETK libraries and tools are written in an object-oriented form of ANSI-C and in C++.

Code_Aster is a FE solver capable of linear and non-linear analysis for statics and dynamics, fatigue, damage, fracture, contact, geomaterials, porous media and multi-physics coupling. English summary document.

CFD Codes

OpenFOAM is a CFD toolbox that can simulate a range of problems including complex fluid flows involving chemical reactions, turbulence and heat transfer, to solid dynamics, electromagnetics and the pricing of financial options.

CFD Online provides online center CFD resources.

Mesh Generation

Gmsh is an automatic 3D finite element grid generator with a built-in CAD engine and post-processor.

NETGEN is an automatic 3D tetrahedral mesh generator that is capable of working with constructive solid geometry (CSG) or boundary representation (BRep) geometry.

Visualization Tools

ParaView is a multi-platform application designed to visualize data sets of any size.

MayaVi2 is a general purpose visualization engine.

Wordle is a toy for generating “word clouds” from text that you provide. The clouds give greater prominence to words that appear more frequently in the source text. You can tweak your clouds with different fonts, layouts, and color schemes. The images you create with Wordle are yours to use however you like. You can print them out, or save them to the Wordle gallery to share with your friends.

I ran this site through it and it generated the image below. Hours of fun!

Note: The NASTRAN source code costs around $4000 USD.

These include:

• Inappropriate technology or language selection
• Poor architecture and strong coupling between components
• Inadequate or non-existent testing

As a result they often spend much of their time fighting with the software instead of solving the design or research problem. Additionally, the reuse and extensibility of the software is limited, resulting in significant rework.

Software Carpentry provides an excellent online course based on Open Source content intended to give scientists and engineers the fundamentals of software development.

Potential Benefits

• Reduced project delivery schedule / elapsed time (time to market)
  This is a clear benefit, but may result in higher overall projects costs compared to an equivalent project completed by a co-located team because of the additional communications overhead.
• Access to global resources at lower costs
  This only becomes a valid cost saving in the case where the operating and labour costs are much lower, such as in locations like India or China. In my experience the additional cost of communicating requirements and changes on a daily basis erodes the labour cost savings for all but the simplest business problems. This is probably why call and support centres are able to function (maybe not well, but well enough) using this model.
• Facilitate and enhance international partnerships
  The case for building international partnerships is only valid when there is an appropriate business motivation and therefore not valid in all cases – especially for outsourced projects. A valid example might be the case of a business acquisition and need to harmonise organisational culture and working practices.
• Leverage skills and experience across all sites
  The potential to leverage a broader and/or deeper skill base is a valid benefit and can offer a business unique skills otherwise unavailable and therefore provide an important competitive advantage.
• Frequent peer checking leading to increased quality
  Peer review is a valid benefit and consistent with agile principles, but assumes that the same task is being progressed at each site rather than simply being divided amongst the sites. Peer review can be achieved in many other ways but the turn around time in this model is a real advantage.
• 24hr availability without shift working
  Business functions that require 24hr availability, such as call or support centres, can benefit from this model. However these business functions rarely involve the task being passed from one time-zone or location to another and so the required communication and infrastructure is significantly reduced.
• Reduced software licensing costs
  In certain situations the cost of software tools is a significant proportion of the project costs. This is often true for specialised engineering tools (particularly CAD, FEA and CFD). When software licensing permits, there is a potential opportunity to share the license costs over more than one time zone thereby reducing the total number of licenses required.

Potential Costs

• Reduced customer contact and engagement
  Software development and engineering design typically suffer when customer contact is reduced. However, there are instances when the constraint of limited customer contact has the effect of focusing the communication and ensuring that the limited time is used effectively. Communication can also be enhanced with web-based project management tools such as Basecamp or Unfuddle.
• Increased infrastructure complexity needed to facilitate data sharing
  Information security policies typically restrict the sharing of company data across the open internet. As a result, additional infrastructure is needed to secure access to private networks.
• Higher start-up costs associated with resource allocation
  The additional complexity and communication overhead associated with making the necessary resource available for a project typically increases the start-up costs.

Making an Objective Decision

• Clear business objectives
  It is important to be clear about why a Follow the Sun or Remote working model is being considered. In the present case, when we began to discuss the issue in detail it was unclear if we were; (a) attempting to create a global development team, or (b) trying to maximize the opportunities to share developed software or (c) trying to forge stronger links between the two businesses. As it turned out the business objective was both (b) and (c) and these can be achieved without attempting to use a Follow the Sun working model. In any case, the set up costs are significant and so it pays to be clear about the objective as this will determine what benefits can be realized.
• Challenge the assumption that costs will be reduced
  The advancement in communication technology has somewhat fuelled the hype around global teams and working practices. Despite this enthusiasm, the benefits can only be realised in certain situations and therefore it is important to challenge the benefits to ensure they are achievable.
• Peak Oil and travel costs
  The case for remote working and less onsite travel will strengthen as the cost of travel increases. This will probably result in more emphasis on local resources, however the advances in communication could counter this effect.

Ruby on Rails achieves this goal by simplifying web application development and removing configuration decisions so that the developer can focus on solving the business problem. With this in mind I thought there may be value in exploring an equivalent framework for mechanical part and assembly design.

The Basic Framework

The framework would be based on a file structure with names that follow the Principle of Least Surprise. The file structure would encourage engineers to organise their data and working files consistently across teams and projects. The default file structure would be generated and supported by scripts and file templates. Scripts would also be used to create new assemblies, parts, references, and generate reports. Additionally, the framework would leverage a number of established standards for engineering data – for example MatML for material property data. The following is a first pass at how this might look.

At the first level the framework would contain directories for configuration, management, references, scripts, templates and work.

The configuration directory would contain vendor, supplier and project details together with specific framework configurations.

The management directory would contain typical project management documents including customer supplied data, reports and commercial and technical quality plans. Registers of the data would also be included as XML and could be potentially maintained automatically using scripts.

The reference directory would contain engineering reference data such as MIL Handbook or ASME data that is used across the project and is approved by the customer. In some instances this data may be public domain but the majority is likely to be proprietary to either the customer or the vendor and would be separated accordingly. An important assumption (convention) would be that all data would be current and approved for use. Ensuring this assumption holds true may be difficult, especially on larger projects, but this is something the framework could help maintain using automation. Reference data would be separated into design, analysis, manufacturing and materials. Ideally data and methods would be stored in neutral formats to maximise reuse opportunities.

The scripts and templates directories would contain standard scripts and templates together with any customised functionality. Templates would be defined in XML and styled using XSLT.

The work directory would contain the parts and assemblies structured according to the part hierarchy. An XML file would store these relationships for interrogation or reporting purposes. Part numbers would be used to uniquely identify part and assembly directories. For each component the design inputs and outputs would be separated. Inputs would be further separated into geometry, applied loads and materials and ideally stored as XML files. The outputs would be representative of the design lifecycle and resulting data formats, typically CAD, FEA, structural analysis reports and manufacturing plans. The maturity of the design could be captured in an XML file for each part according to a standard product lifecycle.

Framework Infrastructure and Automation

A scripting language would be needed to support the framework and the obvious choice would be either Python or Ruby. Since the framework is intended for the engineering community, Python might seem like a prudent choice as it has always had a strong association with the scientific and technical computing community. However, the clean expressive nature of the Ruby language together with the Gem system for package management makes Ruby the preferred option.

Users would interact with the framework in the same way as they do with Ruby on Rails. For example from the command line:

% engfwk project_name vendor_name client_name

% ruby script/generate assembly assembly_name parent_assemby_name
% ruby script/generate part name parent_assembly_name
% ruby script/generate material source_filename.xml
% ruby script/generate load source_filename.xml

% rake report:progress

% rake verify:project

% rake stats

Benefits

In my experience, on large engineering design projects the approach that different engineers take when they design or analyse parts is largely dependent on how they did it last time, rather than best practice guidelines or company standards. The benefits of coercing the design and analysis activity into a standard structure is that users know exactly where to find and store data. While this may sound minor, on large projects this makes a huge difference to team productivity, ensuring the right reference data is used and the ease with which engineers can pickup another engineers work. Another benefit to structuring data in a consistent and predictable way is that engineers would be able to developer tools or pluggable extensions to the framework that could be reused across other projects.

Concerns

The main concern with this idea is that the proposed framework could be considered just a simple, file-based PDM system. This is a valid concern, but the low costs and flexibility of the proposed framework probably negates this concern.

Next Steps

The best way to explore the potential benefits of an engineering design framework would be to try applying it to a design problem. This will be my next step…

Small Regular Deliverables

At the heart of agile is the incremental delivery of projects in small regular intervals, rather than one large delivery at the end. Each of the delivery iterations is a subset of the entire development lifecycle and is demonstrated to the customer. This has the effect of reducing the risks associated with the development progressing in a direction that is not consistent with customer requirements. Applying this principle to engineering design does have some limitations, particularly since the cost and complexity of construction usually prohibits multiple iterations. However, within the design phase of an engineering project, there are good opportunities to use this approach and it is this part of the product life cycle that has been considered.

During the design phase of an engineering project, milestones are often introduced to mark preliminary and critical phases of the design. These milestones do encourage incremental delivery, but they are neither small enough, nor regular enough to be consistent with agile principles. Modern CAD tools enable rapid development of digital mock-ups that can fulfil this objective. The CAD model can contain sufficient design detail to accurately represent the product and surrounding structure. As a result the CAD model can be used as the basis for verifying many different acceptance criteria. Additionally, rapid prototyping systems enable the creation of physical mock-ups that greatly enhance customer engagement and interaction with the design process.

From an agile perspective these deliverables are important for customer engagement and verification of the design direction. However, prototypes that do not add directly to the final product are not valued as highly as actual progress toward the final delivered product. That said, there is still significant opportunity to make incremental deliverables part of the design process and no technical reason why this cannot occur throughout this phase of an engineering project.

Deliverables Measure Progress

Customers often propose an earned value schedule for a project that is based on deliverables and is linked to either financial payments, or the release of additional project funds. These types of earned value measures are compatible with agile principles, particularly if they are granular enough to encourage close customer involvement in the project.

For engineering design projects, the CAD model is increasingly becoming a digital representation of the complete product including geometry, materials, manufacturing details and even the original design intent. Measuring the progress of CAD model maturity and conformance with acceptance criteria will provide the most agile measure of project progress.

Customer Collaboration

Customer satisfaction is considered important in engineering design projects, but the value of customer involvement in the development and review of the design as it progresses, is not widely utilized. Many project resource models fail to consider the benefits that can be achieved through close engagement with the customer, even for tasks that may appear well defined and understood.

Traditionally, the approach has been to develop highly prescriptive specifications and then negotiate changes with the customer using forms and documents such as Engineering Change Notes. In an agile environment, changes are driven by the customer and embraced by the development team. During the design phase of an engineering project there appears no reason why the same approach cannot be used. Additionally, when collaboration occurs between the customer and the engineering design team, the customer will tend to accept a greater level of responsibility for decisions as they can clearly see their impact on scope, schedule and cost.

The Scrum model advocates meetings that occur daily and at the end of each delivery iteration or sprint. The daily meetings involve the customer and all team members and are an opportunity to discuss each team member’s progress, plans and any obstacles. The iteration review and planning meetings also involve the customer and is their opportunity to prioritise the order in which features are implemented. This ensures that the development team are always working on the features that are of the highest value to the customer. These meetings may not always be practical because of team size, geographic locations or prior commitments; however, even at a small scale they have significant value. In large projects where the majority of engineering design work occurs in a separate location, a daily telephone or internet conference call with all team members will achieve a similar result and is a technique that is very valuable.

Simplicity and Design

Starting with the simplest possible solution that satisfies customer requirements and then maturing the solution during course of the project, is a common agile practice. This approach is somewhat at odds with software architecture design principles, which often need to be addressed early in a project. The conflict is typically resolved by developing software in such a way that it can be re-structured as easily as possible.

The main techniques for achieving this include: maintaining loose coupling between components and implementing automated tests. The loose coupling provides the opportunity to easily replace components or restructure the overall design with minimum impact. Automated tests allow architectural or component changes to be verified quickly thus further lowering the cost associated with changing and evolving the solution through the course of the project. This process is often referred to as refactoring.

For engineering design projects, implementing the simplest possible solution is an implicit assumption for most engineers and therefore compatible with agile principles. What is lacking however, is automated testing that verifies design changes. Significant work has already been done to automate structural analysis methods using both computational and classical analysis methods. However, this analysis is generally performed manually as a supplementary activity, rather than a concurrent activity that is automated. Therefore an opportunity exists to implement automatic design verification against customer defined acceptance criteria.

Embracing Changing Requirements

Traditionally, engineering project management practices have emphasized the need to control change. This is partly because project change has been closely associated with project cost, especially within a fixed price environment. Conversely, agile principles are based around an assumption that change will inevitably occur during the course of a project and that it is better to position the solution and working practices so that they can easily adapt. Furthermore, in an agile project it will be necessary to compromise at least one of either project; scope, cost or schedule and customers need to appreciate that they are responsible for guiding this compromise.

The agile practices of refactoring and automated testing help, software projects adapt to change, while the close customer involvement ensures that changes are identified as early as possible. For engineering design projects these principles can be applied as equivalent technical solutions exist, however the costs associated with automated testing can be very high. Consequently, engineers typically question the return on investment associated with automated verification. Additionally, engineers often take a conservative approach to alternate design methods and therefore changes are typically met with strong resistance. That said, there is generally a trend towards engineering automation and this is likely to evolve into automated testing.

Pair Programming/Working

Pair programming has attracted controversy because managers typically assume that having two developers implement the same functionality is only half as efficient as conventional working models. As an agile practice, pair programming has the effect of increasing software quality through peer review. Quality is critical as it ensures that the resultant software is in a state where it can be adapted to meet changing or additional requirements.

In a typical engineering design environment, the practice of pair working is uncommon. This maybe in part because of how tasks are broken down and matched to people with appropriate skills and experience. Another reason maybe the perceived cost ineffectiveness. Either way, the clear benefits that pair working provides should justify its adoption more widely.

With this in mind, there may be better ways to decompose engineering design tasks so as to exploit the skill and experience combinations that pair working offers. An example could be pairing a structural designer and analyst, instead of having the designer initiate structural layouts and the analyst size the structural features. This would encourage a more concurrent approach and result in a higher quality design and less rework.

Summary

Agile methods have become the default approach for software development projects. Many of the agile practices and principles can be more generally applied to other disciplines including engineering design. The opportunity for engineering design organizations is to improve the reliability of project success and the quality of resultant designs.