Lean Software Development

In recent years we have found that a focus on flow (lean), rather than a focus on waste elimination (agile) is proving a better catalyst for continuous improvement within software development.

Lean Software Development has emerged as its own discipline – not specifically a subset of the Agile movement but certainly related to Agile.

Lean is based on two fundamental principles – first, one must take a systemic view to improvement and second, one must do this by looking at the flow of work though the system. The first is a shift from managing people to improving the systems within which people work. The second is a shift from focusing on productivity directly to removing delays in workflow to increase productivity.

The 7 principles of Lean software development were inspired by the original Lean principles developed by Toyota.

Principle 1: Eliminate Waste

Waste is defined as; Anything that interferes with giving users what they value.

Inventory is waste; In software thats incomplete work

Requirement Churn; Software built against the backdrop of rapidly-changing or late changing requirements often means one thing – changes!

Requirements specified long before coding begins

Testing occurs long after coding was finished

Delays in integration of code into our production environment

Overproduction; Low priority/value features are developed.  66% of features in bespoke software are rarely or never used.

Principle 2: Build Quality In

Don’t focus on logging defects in a bug tracking system – avoid creating defects in the first place.

Defect tracking systems are another example of partially done work

Implement Test Driven Development (TDD) and Continuous Integration

Write Less Code – Keep your code base simple, Refactor often

Expect to change existing code

Principle 3: Create Knowledge

Software is a knowledge creating process

Validation of architecture comes as the code is being written

An early design cannot fully anticipate the complexity encountered during implementation

Expect the design to evolve

Release a minimal feature set to customers for evaluation and feedback

Daily builds and rapid feedback from integration tests

Create a modular architecture that has the ability to add new features easily

Encourage systematic learning throughout the development cycle

Don’t act as if our predictions of the future are fact – but rather a forecast.

Principle 4: Defer Commitment

Schedule irreversible decisions for the last responsible moment

Endeavour to make decisions reversible

Avoid making decisions that will lock in critical design decisions that are difficult to change

Principle 5: Deliver Fast

Find a way to deliver software so quickly that our customers don’t have time to change their minds

Organisations that compete on the basis of time;

Have a significant cost advantage
Eliminate a huge amount of waste
Low defect rates

Repeatable and reliable speed needs to be in tandem with superb quality

In fast-moving companies work is structured so our people doing the work know what to do without being told.

Our people are expected to solve problems and adapt to changes without permission

Principle 6: Respect People

Hire an entrepreneurial leader!

An organisation that respects its people develops good leaders.

Ensure your teams have the kind of leadership that fosters engaged team members focused on creating a great products

Expert Technical Workforce

Appropriate technical expertise is nurtured

Teams are staffed with needed expertise to accomplish their goals

Responsibility-Based Planning and Control

Teams are given general plans and reasonable goals and are trusted to self-organise to meet their goals

Principle 7: Optimize the Whole

A lean company optimises the whole value stream

Vicious Circle 1
Customer wants a new feature “yesterday”
Developers hear: Get it done fast!
Result: Sloppy changes made to the code base
Result: Complexity of the code base increases
Result: Number of defects in code base increases
Result: An exponential increase in time to add features moving forwards

Vicious Circle #2
The testing team is overloaded with work
Result: Testing occurs long after coding has finished
Result: Developers don’t get immediate feedback
Result: Developers create more defects
Result: Testing has more work. Systems have more defects
Result: Feedback to developers is delayed further. Repeat cycle.

A branching strategy is a convention that describes when branches are created, how they are to be named and what use your branches should have.

Communication will be clearer if your team uses the terminology correctly and consistently.

Minimise the number of branches

No matter which strategy you use, it is helpful to minimise the number of branches in play. Fewer branches means; less merges, less conflict and less misunderstanding within your team. The most extreme example being Trunk based development – a single branch with feature toggles.  For larger code-bases branching allows changes to be isolated – helping teams from disturbing each other.  Short-lived feature branches can work well, especially when used for experimentation. When branches remain in existence for too long the chances of multiple merge-conflicts mount.

Merge regularly

For many enterprise businesses deployments are still infrequent. However its essential to merge regularly. Weekly merges are a good frequency to start with. The merge should be performed by the team that is responsible for the target branch of the merge – they know best when to do it and how to resolve conflicts.

There are many branching strategies. Here I evaluate when and where they are best used.

1) Branch by Abstraction / No Branches / Trunk based development

Your team works only from the main source tree. You do not create branches and you do not need isolation. Generally suited to small teams that do not require isolation for teams or features.

The “branch by abstraction” approach has recently gained attention due to the buzz surrounding “continuous delivery”. Our strategy is; a single branch for everything.

New features, but not yet finished, can be enabled or disabled by feature-toggles. We can use this device to release different versions of our application from a single branch, by changing its configuration. The big advantage here; it frees us from merging! Unfortunately – its not appropriate for all projects.

2) Branch for Release / Branch for Sprint / Staircase Model

For every planned release we have a separate branch. Your team creates a branch before release time to stabilise the release and then merges changes from the release branch back into the main source tree after the software is released.

3) Branch for Maintenance

You create a branch to maintain an old build ie a branch for your maintenance efforts, so that you do not destabilise your current production builds.

You may or may not merge changes from the maintenance branch back into the main tree. e.g. your team works on a hot fix for a certain number of customers that you dont want to include in the main build.

4) Branch for Feature

You create branches based on features. You create a development branch, perform work in the development branch, and then merge back into your main source tree. Your team can create separate branches for work on specific features to be completed in parallel.

5) Branch for Team

You branch in order to isolate sub-teams so they can work without being at risk of breaking anything, or they can work in parallel towards unique goals.

Imagine a product development paradigm where you build software so that it is always in a state where it could be put into production. A deployment pipeline is essentially; an automated implementation of your application’s build, deploy, test and release process.

From a business perspective, deployment automation allows you to get changes – planned or unplanned, into production reliably and quickly. This allows you to gather user feedback as early as possible and develop and maintain software that is lean, contains only features stakeholders need and avoid software bloat.

With Agile development, teams are able to create functionality ready for use more frequently. This can create a backlog for operations teams as they struggle to deploy the applications as quickly as new builds are ready.

In addition manual deployments come with a series of downsides

a) manual deployments that are not consistent across environments

b) slow; neither repeatable nor reliable

c) require documentation (often outdated)

d) manual deployments hinder collaboration as not all team members can execute the deployments

To keep pace with the increase in deployment demand you need to create a deployment pipeline. Without deployment automation, your company will struggle to unlock the full potential of Agile.

A deployment pipeline helps to deal with the challenge of feature release backlog -and bridges the gap between development and operations teams by breaking up your build into stages. Each stage providing increasing confidence until the product is end user ready.

Continuous Delivery (CD) is a software development strategy that enables organisations to deliver new features to users fast and efficiently. The foundation of CD is to create a repeatable, reliable and incrementally improving process for taking software from concept to customer.

Continuous Delivery enables a constant flow of changes into production via an automated software production line. Continuous delivery can be thought of as an extension of continuous integration, aiming at minimising lead time, the time elapsed between developers writing new code and this new functionality being used by live users, in production.

As the difference between each build decreases, the work becomes more tedious for operations teams since consecutive packages are likely to use the same set of resources and do not need major changes in middleware configuration or infrastructure. This increases demands on operations personnel and makes their job repetitious.

To achieve continuous deployment, the team relies on infrastructure that automates the various steps leading up to deployment. After each integration successfully meets these release criteria, the live application is updated with new code.

A good build pipeline will have a relatively high degree of parallelization. The pipeline tasks won’t all run in series – otherwise you are effectively daisy-chaining together a collection of build jobs, and the value of the system is significantly reduced.

For small projects parallelisation is less of an issue but with a large project that has slow unit and acceptance tests, and deployment steps take a long time to complete, then the whole pipeline may take hours to complete.

The working day could have ended before the final stage is executed. This is far from ideal because if there’s a problem with any part of my pipeline, you want to know about it fast – so that you can fix it. A good practice is to parallelise the tasks where possible. Acceptance tests, unit-test coverage and static analysis can often be performed in parallel.

You can imagine your deployment pipeline as a series of jobs or steps on your Continuous Integration server. Each job increases the confidence in the software and brings it closer to release. Initial phases are short and provide feedback as quickly as possible, later steps typically require more time and possibly require human interaction. If any build in the pipeline fails consecutive steps are not triggered. The key takeaway here is; automation. The whole process is fully automated and requires almost no human effort.

The 5 Stages of a deployment pipeline

1) Commit stage

The purpose here is to provide fast feedback for developers and prepare application binaries. It checks out new sources, compiles them, executes unit tests, executes simple smoke tests, prepares the application package ready for deploy, executes static code analysis tools, possibly verifies there are no architecture breaches. This phase executes fast – no more than 10 minutes. A successful finish states that the application works correctly at a technical level.

2) Automated acceptance test stage

The purpose here is to assert that the system works at both the functional and nonfunctional level. This stage ensures us that the application delivers value to the end user. To achieve this you would usually deploy the full application and go through the most important and common user paths. This phase is significantly longer than the commit stage; it could take hours.

3) Manual test stage

Commonly known as User Acceptance Testing (UAT). Testers can deploy the application with one click on a chosen environment. The application is possibly deployed to staging environments. This phase involves human verification of the current application. This stage should only involve tests that cannot be automated and integrated into to the automated acceptance test stage.

4) Capacity stage

Depending on how close the application is to final release is to verify application performance. The phase can be done in parallel to the manual test stage.

Typically load tests are run to verify that the system can serve a defined level of service under “live” load conditions. It is assessed whether the application is fit for purpose from a non-functional perspective in regards to response time and throughput. While it can be almost fully automated, the outcome usually depends on a human decision as to whether the current stage is acceptable.

5) Release stage

The goal here is to deliver the application to end users. Depending on the scenario, you could be upgrading a production environment, sending packaged software or deploying an update on client devices. Fully implemented Continuous Delivery might perform this phase automatically if all previous stages were successful. Typically it will be a human decision to release the product here.

1) TargetProcess

Targetprocess is a tool to visualise and manage Agile projects with native support for Scrum, Kanban or even a customised Agile methodology. With enhanced visualization functionality, Targetprocess gives the visibility you need across teams, projects and your entire organization.

Targetprocess re-invents the workflow board, by combining Trello and typical issue trackers and project management systems. Create views to slice the data and drag and drop between grids to change properties of the cards. Customise the app to fit into your workflow in a way that is not possible with many other tools. This is superior to customising your workflow to fit the app!

Everything from complex reporting and data insights to very custom workflows and notifications is possible with TargetProcess. You can even add your own mashups to extend the functionality.

Keep track of all your projects with separate team workflows. Multiple view options to filter down what you need to see. Comprehensive reporting options, a full and well documented API coupled with great customer support makes TargetProcess the winner for Agile Product Development.

2) VersionOne

VersionOne has a clean, intuitive user interface. Customize your projects for any style of Agile your team uses eg DSDM, Scrum or XP. Users can pick up VersionOne and quickly learn how to drag-and-drop on the project boards, make comments, and keep in touch with their team. VersionOne integrates with a host of Application Lifecycle Management tools, including Jira, GIT, HP Quality Center, and Microsoft Visual Studio.

VersionOne is an agile project management solution for development teams of all sizes. You get; project boards with epics, stories, goals, issues and defects; sprint planning; project roadmapping; release planning and test management.

The collaboration tools offered by VersionOne include “Conversations”, which enable status sharing, questions, and discussion forums. “Ideas” provide a platform for your client ideas to be voiced through automated data submission. Ideas can then be voted on and prioritised.

The VersionOnes TeamRoom provides interactive Storyboards and Taskboards for team collaboration, while the PlanningRoom provides a space for product managers, owners and agile planners to manage projects through tools such as Epicboards and Portfolio Timelines.

3) CA Agile Central (Rally)

Rallys software and cloud services help teams manage complex software projects and include functionality for team collaboration, managing projects, portfolios of work, diagnostic analysis, and platform integration.

Rallys suite goes beyond bug tracking and version control and integrates the entire Agile cycle, from gleaning customer feedback to publishing the latest version of a new product.

Rally provides visibility of progress across a large number of teams and also provides product management visibility of their product features. The open API is allows integration to other systems you may be using.

The cloud-based agile lifecycle management platform scales to an unlimited number of teams and features custom pages and dashboards to automate various development processes.

4) Pivotal Tracker

If issue tracking features are an important to you, you should know that Pivotal Tracker allows users to resolve issues through multiple workflows. This means that issues in your new product development project can be handled differently than bugs in your latest build.

PivotalTracker provides an informative overview of your project and current sprint. You have a single view into the project allowing you to see exactly what is happening fast. The interface is simple and sprints are created automatically based on defined estimates. Your project practically runs itself!

You can create stories to segment large projects, while simultaneously keeping everyone up to date on their section of the project. This makes projects more manageable and improves communication on projects tremendously.

PivotalTracker does very few things, but it does them all exceptionally well. Easily organise your tasks by status and tag them for additional organisation. Pivotal Trackers basic built-in reporting is somewhat limited compared to other solutions, however their API allows third party applications to enhance their reporting capabilities.

5) Sprint.ly

Sprint.ly is a SaaS tool created to power a more productive relationship between development teams and management. Sprint.ly is designed to be transparent, flexible and usable. Cross-functional teams can more reliably deliver higher quality software products.

Sprint.ly gives you a full view of what your team is currently working on across all stages of development. Sort and search for items based on owner, type, stage, date range or by tags. Sprint.ly allows you to view resource utilisation to ensure work is balanced across your team.

Sprint.ly features market-leading integration with GitHub. Items can be updated and their status can be changed automatically from within a GitHub Commit message or Pull Request. Sprintly supports multiple repositories syncing with a single Sprint.ly project. In addition, Sprintly integrates with development tools such as BitBucket, Beanstalk, Crashlytics, Rollbar and Slack.

The user interface is very good looking! Sprintly is easy on the eyes, and when you have to look at a tool all day, that’s a plus.

Ironically Sprint.ly doesn’t use sprints. Instead it uses a tagging system rather than having unique fields for tracking sprints, milestones and components.

6) Atlassian Jira

Jira by Atlassian is a popular tool for tracking development tasks. Originally a bug tracking tool – Jira has been expanded to include Agile functionality. Enable your teams to organiae issues, assign work, and follow team activity.

Jira is highly customisable, almost anything can be adjusted to suit your needs.

Theres configurable workflows that allow separate life cycles for each project. Organise your JIRA dashboard any way you want and create as many dashboards as needed. This can help you when preparing for team meetings and generating reports.

Atlassian JIRA has very powerful permission settings so you can create workgroups with particular access levels, to control who can see what information and what they can do with it.

With all the power and flexibility comes a price; complexity. Setting up Jira exactly how you want it can cause major headaches. It has a feeling of a monolithic piece of software that could benefit from being reimagined from scratch. The “Agile” aspect of Jira appears bolted on. To administer Atlassian JIRA for a medium to large company can become a full-time job for at least one member of staff.

7) Mingle

Mingle is a proprietary project management and collaboration platform that is built by ThoughtWorks Studios. It is an agile project management solution that helps your teams stay on top of evolving requirements in collaboration with business users.

Scaling Agile works best when each team can effectively integrate Agile into their own process. Mingle is designed to integrate with a team’s current workflow. Once teams are effectively practicing Agile, Managers can use Mingle’s Planner feature to define objectives for the organisation, track a plan’s progress, and receive alerts when a plan changes.

Mingle provides ways for a team to share information about a project. Mingle shows the status and progress of project tasks on drag and drop Card Walls that simulate an Agile Story Wall. There are Wikis for project collaboration, and you can associate instant messages with project tasks through a feature called Murmurs. Mingle can generate burn-down charts showing work remaining, velocity charts showing actual versus expected progress, and pivot tables for grouping data by one or more attributes.

8) Trello

Trello uses the Kanban concept for managing projects. Projects are represented by boards, which contain lists. Lists contain cards – corresponding to tasks. Cards are progress from one list to the next mirroring the flow of a feature from idea to implementation. Users can be assigned to cards. Users and boards can be grouped into organizations.

Trello is clean, light and fun and provides an interesting and flexible solution for supporting collaboration and managing projects. Trello is super stripped down. You get no reporting tools, time-tracking features, or traditional tasks as you might know them. If you are searching for something non-traditional, visually oriented, and flexible, Trello may be for you.

9) Basecamp

The company behind Basecamp; 37signals, is renowned for its customer-centric collaboration software. Co-Founder Jason Fried is a thought leader. His manifesto “Rework” is a New York Times bestseller, and outlines the company’s philosophy: speed and simplicity is the key to success.

Basecamp lets you quickly set up an account and jump right into project management. Simplicity and usability go hand in hand and Basecamp certainly is intuitive. Basecamp does not offer the collaboration and communication functionality found in other similar tools.

Features you might expect from an online project management solution are not included in Basecamp out of the box. You can get Gantt charts, time-tracking and invoicing; but you will have to look for 3^rd party add-ons to deliver this functionality.

In summary, Basecamp is great for project tracking – and can be used to Agile projects with a little creative thinking, but its impossible to classify Basecamp as a complete Product and Project Management solution.

10) Huddle

Huddle combines powerful workflow tools with the ability to work seamlessly across devices and virtual teams. Intuitive project management features allow you to unify project tasks, content, approvals and team communication within a single dashboard.

According to the guys at Huddle; Huddle has less, does less, and aspires to do less. The interface is clean, clear, and highly modular.

Huddle is not as full-featured as Zoho It has made an attempt at differentiation through specialization, a specific tool for collaboration and file management.

Despite these limitations, Huddle does execute what it does do well. Simple menus, consistent user interface, and plenty of tutorials make Huddle easy to master.

Collaborate with geographically dispersed employees or freelancers video conferencing built into the tool

You cannot generate reports in Huddle, so if you want to analyze your project data, you will have to use another program. This could be an issue if you like to use the data youve gathered about tasks, budgets, and resources to help you make decisions about new projects.

11) Zoho

Compared to simpler services such as Basecamp or Huddle, Zoho packs in more features and services. The tradeoff comes in the learning curve. Zoho is a feature-rich online project management platform. However, getting to those features can be challenge. Once you have got used to the interface you could find Zoho Projects worth the time investment.

File Storage, Google Docs-integration and team collaboration all come as standard. Share by message, status, or announcement, post on forums or wikis, and chat by Instant Messager. Zoho provides a full suite of paid apps if anything is missing.

The most compelling qualities of this software are its flexible and inexpensive pricing structure, rich variety of integrations, and communication tools documents and files online in real time. Be aware some of the best features are only available with the more expensive plans.

Customer support is not the best according to many independent reviews. The UI can appear cluttered – especially as projects grow in size. Zoho Projects could be a good fit for small enterprises without a PM team. In addition, as Zoho is a 360 solution with everything included – then you are good to go. But if you are looking for software to sit alongside your existing workflow, Zoho Projects might not be the right fit.

The premise of waterfall software development is that complex software systems can be built in a sequential, phased manner where all of the requirements are gathered at the beginning, design follows, and the final design is implemented into production quality software.

Waterfall was first proposed in an article written by Winston Royce in 1970, primarily intended for use in government projects. The waterfall methodology attempts to equate software development to a production line conveyor belt.

The approach assumes that complex systems can be built in a single phase, without going back and revisiting requirements or ideas to reflect changing business or technology conditions.

1) Nobody is in charge of requirements

There is a need for a formalized role to compile the system specifications into a requirements specification document with a typical waterfall project. Often the role to sanity check requirements is missing and therefore requirements are thrown together by a motley crew of various stakeholders. Once sign off is complete – in a best case scenario requirements are put in front of a user experience specialist and a technical team lead to “design” the software. Once the design technical and creative diagrams are complete they are passed to the “developers” who implement the code from the design.

Under the waterfall approach, managers have made efforts to craft and adhere to large-scale development plans. These plans are laid out in advance of development projects using Gantt charts to map detailed tasks and dependencies for each member of the development group months or years into the future.

Studies of historical software projects show that only 15% are on-time and on-budget. So why does waterfall fail in so many cases? First lets define; What are requirements? From the stakeholder’s perspective, the requirements are the features and specifications of the system. Requirements define what developers should build.

2) Requirements take too long to compile

The biggest problem with waterfall is that it assumes that all project requirements can be accurately gathered at the start of the project. With waterfall we spend weeks or months compiling every single feature that the proposed system must include into a comprehensive requirements document.

On completion the requirements document is thrown over the fence to the designers while the requirements analysts move on to the next project. Is it possible for a customer or internal stakeholder to list every single feature they require? The simple answer is no. The list of potential areas of consideration are almost limitless. For example business rules, scalability, browser support; user roles and permissions, interface design.

It is inevitable that attempts at up-front requirements specification will miss out important details simply because the stakeholders cannot imagine everything the system needs to do at the start of the project.

Ultimately requirements will change outside of the requirements phase of the project in the form of “change requests”, and in waterfall projects these requests are costly. By virtue of a requirements change, the intricately planned design can be affected dramatically, which will in turn affect any implementation and test strategies.

3) Waterfall cannot cope with uncertainty

Software Development is more akin to New Product Development than Manufacturing. Software development is a complex field with multiple variables impacting the system. Software systems are imperfect because they cannot be built with mathematical or physical certainty.

Building a bridge relies on physical and mathematical laws. Software development has no laws or clear certainties. Therefore software is typically flawed. The building blocks of software are normally other software systems; programming languages and databases. These systems are never 100% reliable. It is import for companies to understand creating new software will involve variables that are outside of the teams control. Software development is resembles new product research and development than assembly line style manufacturing. Software development is innovation, discovery, and artistry; each new development project throws up new and difficult challenges that cannot be solved with cookie-cutter solutions.

4) Cost of change is high

The cost of change in a waterfall project increases exponentially the further the project develops. If the business needs are emergent waterfall cannot cope with this scenario. In todays rapidly evolving digital world rapid change is inevitable. Is locking a business into a rigid long-term project with high cost of change a good idea? The web and mobile markets force the software development community to respond with a flexible development plans that reduce the cost of change. Stakeholders need to see and feel something before they know what they want.

5) Stakeholders don’t know what they want until they see it

The “I’ll Know it When I See It” (IKIWISI) law says that software development customers can only describe what they want after seeing clicking on functional software. You are asking stakeholders who may not be experts in the digital to picture in their minds eye how something will work. Most stakeholders simply cannot do this effectively. But with waterfall that is what we are asking customers to do. Imagine the complete system without periodically interacting with the product make adjustments to the solution.

Waterfall is an “over the fence” methodology. Requirements are gleaned from the user and at a future date the finished product is shown to the user. This is a flawed approach because customers find it hard to specify software perfectly without seeing it evolve and progress.

6) Waterfall leads to bloated products

In the scramble to document and build every conceivable feature – prioritization of features often doesn’t happen. According to research two thirds of features in a new piece of software are rarely or never used. As there is no inspect and adapt with waterfall, what tends to happen is everything is a priority 1 feature. All features are built because that’s what the client wanted. Only towards the end of the project when it is running late and over budget do features have to be cut. This obviously has a negative impact on client satisfaction as high priority features may end up not being included to meet launch deadlines.

7) Waterfall projects run late

Tying in to the lack of feature prioritization – waterfall projects often run late. Why? The requirements capture and design phase eat up too much project time. Secondly all those medium and low priority features are included in the spec – bloating the list of deliverables. Whats left is a compressed window for development, testing and UAT to occur. Inevitably deadlines have to be moved to accommodate all those missing features.

8) Waterfall projects cost too much

A long drawn out discovery and design phase coupled with building too many low priority features results in one thing – too much time and resource spent on the project. Of course time and resource equals money. Waterfall projects often cost more than estimated. In many cases its as much an estimation issue as a delivery issue. As the specification document grows in size it becomes harder and harder to accurately estimate – under estimating resource required to build features is common. In addition, in the interests of winning new business or gaining the green-light for a new product – the budget for waterfall projects often fail to increase significantly above an initial “ballpark” as new features are added. In the final reckoning a waterfall project can become dramatically over budget.

9) Waterfall projects lack quality

As the software is created and added to the system, testing is performed to ensure that it is working correctly and efficiently. Testing is generally focused on two areas: internal efficiency and external effectiveness. The goal of external effectiveness testing is to verify the software is functioning according to system design, and that all features are working as intended with no bugs. The goal of internal testing to ensure that code is efficient, standardized, and well documented. As waterfall projects tend to run late the final phase of the project ends up getting squeezed. What is the final phase? Testing! In the rush to get the product out the door, testing is often cut short. The result is defects are not uncovered and appear in the live release of the product.

10) Waterfall projects are not fun to work on

Waterfall projects can start to go wrong early in their lifecycle. Sooner rather than later the team starts to feel they are on the back foot. Time is slipping away and progress is slow. Morale is then effected which compromises productivity. The project can quickly enter a downward spiral. With the inevitable “crush” that happens towards the end of the late running waterfall project – an already demoralized team is now forced to work late to save the project from missing its launch deadline. All in all the team will only feel relief and little satisfaction upon delivery of the product. This is hardly the culture any organization wants to foster.