Tasktop

On Friday, May the 10th, Tasktop released 2.7 for both Tasktop Sync and Tasktop Dev. This continues to demonstrate our desire to put out a major release every six months and a minor release every three months. This regular cadence helps manage scope and deliver value to our customers in a managed and controlled way. Version 2.7 was a major release with many new features, bug fixes and improvements, but I want to focus on two main themes.  The first is the release of our first PPM connector for CA Clarity PPM, the second is improvements to our IBM Rational Requirements Composer connector. Both demonstrate our continued desire to connect the world of software delivery by enabling different tools and disciplines to work from the same data and collaborate more effectively.

Support for Clarity PPM

For many developers, the world of the project office is an alien one, with its staff talking about investment portfolios, resource pools and demand management. The same can be said of the PMO when trying to understand developers who work in scrums and talk about CI and GitHub. But with the advent of faster delivery times and Agile methods, development and the PMO need to work together in more dynamic, flexible and aligned ways. That means traditional integration approaches, such as spreadsheets and email, need to be replaced with automated integration. This need led us to develop a connector for CA Clarity PPM, which enables the two teams to work together more effectively sharing work across organizational and tool boundaries. The development of this connector also reinforces our strong partnership with CA and demonstrated our support for CA Clarity Agile and CA Clarity requirements.

Building the connector has reminded us yet again that the technical side of integrating the process and data is often the easiest part. It also reminded us that getting agreement on how the artifacts flow between these two organizations is actually much harder. As we worked on the early version of the connector with a customer, it became very clear that though at the highest level the PMO and development had shared objectives, the reality of day-to-day operation was very different for the two groups. We learned a lot about how the PMO and Development can work together during this process. This learning will form the basis of a webinar titled ‘Connecting CA Clarity PPM with Development Tool Stacks from IBM, HP MS and more’,which not only will demonstrate CA Clarity PPM integrating with the development stack, but will also describe the integration patterns that make sense and the key decisions you need to focus on when building the integration. The best practices of integration continue to drive our investment in Software Lifecycle Integration, where we hope to codify and share these ideas.

Improvements to the RRC connector

As more and more people improve their requirements processes and start adopting tools like IBM RRC, it is clear that requirements can never exist in isolation and that integration is key to delivering software effectively. Requirements tools are great at improving the discipline of requirements, but without linking them to a broader ALM tool stack, the requirements start wrong and just get worse. The key to good requirements is flow and collaboration; flow, meaning that the requirements seamlessly flow between management, the business, development and test, and collaboration, meaning that every stakeholder involved has the ability to comment, discuss and more importantly disagree with the how and why a requirement adds business value. We at Tasktop are heavily involved in this dialogue and continue to improve our requirements connectors as we understand how this interaction plays out. For example, a key improvement in the 2.7 release is the ability to sync into folders between RRC and HP QC / ALM. For many organizations, a folder is more than a way to group large list of requirements; it actually includes some level of business semantics. By adding this capability, we now can share context across tool boundaries.  This is a great example of something that we learned from our customers and partners as we enable better requirements flow and collaboration with Tasktop Sync.

Download the whitepaper

For many 21st century companies and government agencies, software is the not-so-secret sauce for business innovation and competitive advantage. But with 30-70 percent of software projects delayed or failing, delivering successful software projects is still a game of chance. In response, software delivery is always under a constant state of flux, with the practices of development, test, requirements and deployment being modified and improved. But the improvement is often wasted or limited without a way of seamlessly connecting the disciplines of software delivery into an integrated, automated business process. That integration requires a new discipline, the discipline of software lifecycle integration (SLI). SLI is the ALM discipline focused on solving the problems of disconnected, fragmented software delivery. Justifying SLI requires a systematic understanding of the costs and problems associated with software delivery. In this paper, we introduce a five step process for building the business case:

1. identify integrations
2. obtain real financial numbers
3. create annual costs
4. factor in soft benefits
5. measure and learn

By applying a measured approach to SLI, it is possible to build a strong financial motivation, which can then drive direct improvements to the business process of software delivery.

Tools and processes are not integrated

Increasingly, a firm’s competitive differentiation is greatly affected by their ability to deliver innovative, high quality software at a low cost.  Accordingly, for many organizations, delivering this software is increasingly becoming a key business process. The defining characteristics for many products are not determined by the actual product but rather the software that surrounds and runs it. Given the sheer costs and potential value, programs to improve an organization’s software delivery capability are easy to justify, with benefit statements associated with reduced time to market, higher quality, improved predictability, and/or reduced cost.  However, when examining the efficiency of the business process of delivering software, it is not enough to look at the process alone; it is also important to understand the people and the tools involved in the end-to-end delivery of software.  The tools often focus on improving particular disciplines or automating gaps in the process, and the people employ their own unique working practices using the tools in a certain way.  Automated testing, model-driven deployment, build, IDE’s, requirements and project management tools have traditionally been easy to justify, but they alone do not provide the benefits promised. The missing component to success is integration. Integration, the glue that enables complex tool chains to be connected, has emerged as new tools category.

Integration is hard to justify

In the case of Software Lifecycle Integration, integration is focused on enabling different tools to connect. For many organizations, integration is similar to collaboration, or conceptually being valued, but it can be difficult to prove that value. Integration is even more closely tied to collaboration when you realize that integration is all about moving information between disparate stakeholders, i.e., integration provides the telephone lines needed for collaboration. Integration and collaboration are inherently linked, which is both good and bad.  We have all heard it, ‘improving collaboration adds real business value,’ but for many organizations who are increasingly managing growing business needs with shrinking budgets, investing in collaboration or integrations between groups is hard to justify. It is much easier to invest money in improvements to existing processes that clearly serve one role rather than breaking down the barriers between roles. Unfortunately, doing more of something that you’ve proven is inefficient is just a way of producing more of the same inefficiency.

Despite the negative connotation around silos, optimizing for the silo is easier to do than optimizing for the system as a whole.  In the past ten to fifteen years, the pendulum has swung from command and control, hierarchical, centralized IT organizations to Agile, Dan Pink’s knowledge worker freedom, and decentralized reality. In this time, we’ve had tremendous innovations in the silo e.g., Agile programming methodologies, virtualized testing, open source tooling, etc., but that has come at the cost of optimization across the silos.  With Dev Ops, test-driven development and social coding, we are seeing the pendulum swing back as organizations again try to find ways of ensuring the system is successful. Agile methods have in part caused many organizations to rethink their discipline boundaries, but Agile itself can be hard to justify outside the boundary of the development team. Hence, the reality of Agile adoptions for many organizations is ‘water-scrum-fall’. With disconnects between planning, operations and testing being left to other initiatives to solve, 30 to 70% of software projects result in failure or delays despite the advances in the silos.

Despite overwhelming opportunities for improvement and efficiency, for many organizations, justifying collaboration and their integrations is undermined by:

• Ownership.  It is easy to define who is responsible for improving one discipline, but who is responsible for the interaction between two disciplines? For example, who would be responsible for improving the relationship between development and test? Often it requires a third party to get involved, but that in itself can pose a problem as neither group trusts the input of a third outside party.

• Geographical, organizational and political boundaries. The reality of any large organization is that organizational structures evolve and are supported by both managerial and political boundaries. Breaking down these barriers is often very difficult when you are pursuing approaches that by their very nature bring down barriers between groups.    In our example between test and development, most organizational hierarchies have separate testing and development functions and the common manager is often too senior to be close to the challenges that are blocking the improvement.  With outsourcing and remote work a reality of software development, it is rare that QA and development are under the same roof, let alone on the same continent.

• Measurement.  Software delivery has a history of poor measurement, but even that limited measurement often focuses on one discipline such as testing, development or planning. Integration by its very nature changes the flow of work, adding value in unknown ways; thus its value does not necessarily fit nicely into existing measurements.  Additionally, measuring across fiefdoms is always a challenge to get the right information and to get that information to match up so that it is meaningful.

• Inertia.  Change is hard, and organizations have a certain inertia which slows down or stops change from happening. Integration often means organizations need to both think about the overall business process of software delivery and each discipline and make changes to their process models to integrate more effectively.

Vendor integrations are limited and hard to use

Connecting tools into one integrated business process sounds like the responsibility of each tool vendor.  After all, the tool vendors are supposed to offer Application Lifecycle Management (ALM) tools.   Tools provide individual value for one discipline but miss the much greater value that comes when integrated into a broader process, and many vendors provide out of the box, and sometimes free, integrations. But integration is not the focus for those vendors. Integrations are often created to appease clients, support migration, or make a sale. This leads to integrations being limited and hard to actually deploy in the complex, customized, and unique working environment that is the norm in today’s enterprise. The reasons tool vendors struggle to provide the best integrations include:

• You get what you pay for. For the majority of commercial software companies, integration is not a profit center.  Integration teams are funded by other revenue generating groups or paid for out of services and support budgets.  That leads to these teams not being able to keep up with the maintenance and support of integrations, and it often means that when new versions of other tools come out, the integrations are not updated or tested.
• Integration and migration are synonyms. Many ALM vendors have broad and comprehensive stacks of development tools. Integrating with competitor products is hard to motivate when management would much rather move those customers to their own product. This leads to competitors closing up API’s and making it harder and harder to get access to the underlying data. In turn, the competitive vendors do the same with their tool, and a vicious cycle continues with the customer losing out.   Even when tool vendors build their own integrations, they are typically set up as a one-way integration, bringing data to their tools from a competitive alternative.
• Licensing and competitors make it hard. In general, competitors do not like working together.  Licensing is one example of where vendors make integration difficult by explicitly stating that competitors cannot use the product or purchase it.  This leads to lawyers reviewing where and when a competitor’s tool can be used and reduces the likelihood that the vendor will build an integration.

Building your own integrations is complex and a maintenance nightmare

For many organizations, the need to integrate point tools has led to them creating internal integration teams who build custom integrations between tools. Even if the building of the initial integrations are outsourced to a systems integrator, the organization often still requires an internal team to maintain the integrations as the point tools update, as required fields change, and servers are renamed, etc.  These tool integration teams provide custom-made software, sometimes extending vendor-based integration frameworks or using integration platforms such as Tibco or Websphere. Though the initial cost of building the custom integration is easy to justify, the ongoing overhead of running these teams is often not accounted for when doing ROI and resource analysis and planning. What often starts out as a simple connection between two systems for one team with very specific requirements slowly evolves into a business critical operational system with a variety of use cases never foreseen when the initial integration was conceived. This is made harder when:

• You have to build skills in multiple tools. Each tool comes with its own quirks, implementation models and connection patterns. The more tools you integrate, the more skills the integration team needs to manage. For many tools, the integration points are poorly documented and require extensive ‘experimentation’ to implement. This learning is hard to document and often leads to custom built integrations being difficult to maintain by people other than the original creator.

• Update the tools when new versions come out. Traditional tool vendors release new functionality once or twice a year (the pace of new releases has gotten faster in recent history) whereas SaaS vendors release software with a much higher cadence. Keeping custom bespoke integrations up to date with the latest functionality is a large overhead. Also, many organizations support a number of different versions of a particular tool requiring integration to support multiple versions of a particular product.

• Testing and support are a burden. Ultimately, creating the integration is far less effort than supporting those integrations over time. Over time, integrations become a mission critical back end service requiring rigorous testing prior to release to avoid data corruption, missing records and process breakage.  That level of testing is a huge burden requiring multiple test environments, test plans and associated test infrastructure. As soon as the software is considered mission critical, any operational and release overhead will have to be applied to this software, requiring formal review and sign-off before the software goes live.

The value is obvious; it just needs the numbers

The value of connecting up separate tools, disciplines and processes seems obvious to many software delivery professionals. After all, the business processes for sales, logistics, accounting and operations were integrated and automated in the 90’s, ironically largely through software as a medium for the automation and integration, but there is a big leap between knowing something is of value and being able to prove it. There are numerous examples that demonstrate the value of integration. An often cited research study from IDC states that that the cost of not finding information is $3,300 per employee per year. But the IDC study focuses on finding the right information and its effect on productivity.  It ignores the powerful added value that collaboration creates when two groups that traditionally did not see each other’s information are presented with it. For example, by connecting the developer and the tester, existing requirements can be re-evaluated, giving the opportunity for a smarter solution. Daniel Moody and Peter Walsh describe the increased value of information in their work ‘Measuring The Value Of Information: An Asset Valuation Approach‘ as ‘in general, sharing of information tends to multiply its value – the more people who use it, the more economic benefits can be extracted from it’. By focusing on the value of sharing, connecting and being able to report on information, application development professionals will be able to provide context on the cost associated with integrating this information.

Give the right people the right information at the right time in the right form

Providing instant, correct information to the right people is the dream of any information system, and the business process of software delivery, like any other business process, is an information system. The majority of software delivery processes rely on manual processes, rekeying information, meetings, or email to connect key disciplines. Processes such as planning, requirements, development, test and deployment are disconnected, working in different tools and using different approaches at different cadences to solve the same problem. Not only does this provide massive process disconnects between groups, but it also undermines the information that should flow between them. Key artifacts such as requirements, defects, tasks and builds go through several transitions between inception and implementation. For example, a requirement needs to be transformed into a plan to be managed that can then be transformed into a set of activities for developers. The requirement also needs to be transformed into a set of tests to ensure that the business requirement is met.  Currently, in most companies, each transformation is manual and error-prone with key context information being lost. Transformations are undermined by: 

• Rekeying information. A common solution as an artifact is transformed across disciplines is to manually enter information into each tool.  Although this seems like a simple activity, as work moves from planning to analysis, design, development, test and deployment, each artifact is never quite translated completely.  In many cases, the individuals used to handle the manual data entry are either too junior and don’t understand the business processes involved, or those who do understand the business process are wasted doing work they abhor that should be automated.  Even if the individual doing the data entry is at the right level, manual data entry is fraught with mistakes, and the individual’s perceptions often cloud the transformation.  Context, intent and history are often lost when it is moved between disciplines. A great example is a requirement; when defined for planning, it means one thing and is described in that way. The plan that is used to drive requirements work has a simple list of requirements on it but no context and thus the business analyst will take that requirement and enter the details they believe to be true, which may be very different from the original intent of the requirement. All the context from planning is lost as it is translated into the requirements discipline.  The next transition to design again can suffer from these transformations. The process of software delivery starts to resemble the child’s game of Chinese Whispers or Telephone, where everyone converts what they hear to their own perception and changes its intent.

• Email is a nightmare. For many organizations, the glue that connects the disciplines is email. Artifacts are handed off via email, bugs discussed, and requirements described in often complex and sometimes heated email exchanges. Email however, is a poor proxy for capturing real collaboration, and the results of interactions are often poorly communicated and documented.  Email overload often results in missed communications as different people are included on the ‘to’ and ‘cc’ lists and documents are branched in different email threads.

• The amazing spreadsheet. Spreadsheets are used to store requirements, defects, priorities, issues and many other artifacts that drive software delivery.  But often these very important documents become large and difficult to work with. Also the challenges of version control and integrating information from a spreadsheet to other artifacts makes spreadsheets a great way for getting started but difficult to use for long-term integration. A great example is the defect spreadsheet bemoaned by everyone, as it quickly becomes out of date and difficult to work with. How many times have you been on a call where the first ten minutes is spent working out which version of the spreadsheet everyone should be working from?

• Status Meetings.  A normal solution to the challenges of spreadsheets or confusion in emails is a meeting.  Meetings are great for driving collaboration and clarification but are often difficult to schedule with disciplines in different time zones, language barriers, and busy schedules.  As the cadence of software delivery increases, having meetings in a timely matter becomes that much more difficult. Also, add to that the reality of team members being involved in multiple projects and initiatives; not only does this mean that an individual will be attending far too many meetings, but also they will have to context switch, which may mean losing information about a particular artifact.

Agility requires reporting from many sources

Today, the term Agile is used as the catch-all term when describing any improvement to the practice of software delivery. But at the heart of Agility is responding to the environment or building in a feedback loop. Feedback requires rapid, real-time data on how the team is operating, the software they are delivering, and what the customer wants. Daily standup meetings and backlog maintenance requires an integrated understanding of the project. When you add distributed teams and complex software supply chains, it is clear that some form of integration is required. Some of the challenges that arise when integrating for Agility include:

• A person with a clip board is expensive. Manual processes for gathering project status information and customer feedback are often the preferred method for many Agilisters, but the overhead associated with capturing this information is large. Add to that the increased cadence of Agile projects, and you have created a huge cost for the project manager, scrum master or team. This leads to the scrum master being a full time status checker rather than adding any value to the team, they spend their time updating the whiteboard, spreadsheet and communicating progress and status information to their management.

• Out of date information means wrong decisions. Agility is about responding to the situation in the most appropriate fashion. Response requires information, and that information needs to be up to date to enable teams to operate in the most effective way. Running a standup without current defect lists or customer feedback reduces the value of that standup and may lead to wrong decisions being made by the team.

• An individual updating a spreadsheet is error prone. Adding stories, defects and tasks to a ‘super’ spreadsheet is for many teams the answer, but the reality for most software teams is that the spreadsheet is always an afterthought, and the information it holds is never quite up-to-date. The spreadsheet also suffers from version control problems, as many members of the team wish to update it at the same time. Add distribution to the mix, and misunderstandings start to creep in on what people mean by the values on the spreadsheet.

Traceability and compliance is hard to take

For many software projects, the record of the truth is actually held in the heads of the development team. Agile practices accept that realization and encourage practices to share and communicate that tacit knowledge throughout the team. Tacit knowledge is not an adequate way of ensuring compliance and auditability. Having clear, connected software artifacts is key when external parties assess a projects adherence to company or regulatory policy. Also, that information is important when projects have been implemented and problems occur. Software development compliance is often undermined by:

• Manual steps. Having a clear process that is documented is one thing, but actually ensuring that people follow it is quite another. Manual process steps are likely to be ignored when time becomes of an essence and problems with the plan occur. To ensure compliance, manual steps need to be replaced with automation which is enables ease of audit and manageability.

• The breadth of information residing in many tools. The sheer complexity of many software projects makes it difficult to provide clear and concise information flows.  Multiple tools, coupled with external organizations and reliance on external APIs make reporting from one tool near impossible without integration.

• No one really thinks bad things will happen. It is true that the likelihood of litigation for most software projects is small, but as software plays a more important role in a business’s ability to operate, then transparency becomes more important to senior managers. Not only is the risk of litigation or audit a key motivator for improved traceability, but the underlying value of the business is reduced when management cannot really see the impact of change X or the ramifications of change Y.

A five step method for valuing integration

The value of integration will vary greatly based on each organization’s unique situation. Thus, it is impossible to say making defects available to both developers and testers in their respective tools has value $X. Instead the value of the information can only be determined by that particular integration, for that group with one set of data. For example, the integration between development and test would focus on the bugs and builds being generated from each group. That information would drive work for both groups. It is then possible to evaluate the costs / value of different types of integration (see table 1).

table 1 – example cost/value table

Step 1 – Identify integrations

It seems simple, but there are many different integrations possible in the software delivery flow, including requirements to development, development to test, test to requirements, and project management to all disciplines. Each integration has value and risks associated with it. For example, the value of connecting test to development is huge, but when every developer uses a different tool, the integration can be very difficult and thus increases the risk of the integration working or the associated cost. A quick scan of all the possible integrations and a risk, value gut feel is a great place to start (see table 2).

For many organizations, the integrations to focus on have been pre-decided because of existing process problems, audit concerns or serious communication problems. Thus, any holistic identification of all the integration opportunities is pointless; instead concentrating on the integration required tends to be the focus. However, reviewing the application lifecycle as a whole rather than a series of disconnected disciplines provides insight that is often missed.  It is too easy to focus on one particular integration or aspect of the lifecycle without thinking about how that flow connects to other flows. For example, considering test and development is a great start, but reviewing that in the context of operations and requirements will help you identify business changing epiphanies.

Step 2 – Obtain real financial numbers

Determining value in terms of high, medium and low is a great way of defining which integrations to focus on, but integrations have a cost, thus it is important to identify the potential fiscal value of integration.  The costs of integration are a great place to start in identifying information value. For example, by using a similar process that IDC employed in how they calculated the cost of finding information, ask a team how long it takes them to find the right build or defect list. Look at the number of emails asking questions about requirements and build status. That information should then convert into real time and effort, which has a real cost for each role (see table 3).

table 3 – example value

It is also important to factor in the cost of geographic distribution and organizational separation. For example, when teams are in different time zones, traditional techniques for aggregation such as spreadsheets and emails become quickly out of date and cause friction between groups. Distribution is therefore an amplifier of any cost.

Step 3 – Create annual costs and look for overlaps

Often the numbers that surface when looking at the costs and value of locating, aggregating and tracing get everyone very excited, but this needs to be balanced with reality. Factors such as release frequency, distance, and cost overlap can amplify or reduce the value. Also, annual costing implies some assumptions as to the work year, staff utilization and the general flow of work.  Rather than spending too much time calculating the perfect model, concentrate on a best case, worst case scenario, allowing for risk to be calculated into the model (see table 4).

table 4 – example costs and benefits

Step 4 – Factor in soft benefits

Not all benefits can be measured in terms of monetary value. Some benefits are not predictable; for example, the “a-ha” moment created by providing additional information to a developer about the test plan is hard to predict as it is dependent on the information and the developer paying attention to certain data trends. Also integration provides support in areas such as compliance and governance, but measuring the value of governance on a business is difficult to achieve at the micro level. Everyone is able to appreciate the value of compliance, as everyone can tell a story of a company who did something that was not compliant and dealt with the consequences.   For some organizations, compliance is mandated, and thus the value of integration is easy to define as it is in replacement of manual compliance reports and processes.  For example, the consequences of non-compliance in regulated industries can take the form of fines, limitations posed on a business, and negative branding.  Even in non-regulated industries, reserves for potential lawsuits, errors and omissions insurance, potential for business process optimization, etc., all have costs and benefits that may result in the soft benefits outweighing the hard, easy-to-measure benefits that we describe above.  Qualitative soft benefits can be found by asking the team and other stakeholders involved in software delivery what their biggest problems with collaboration and process flow are and then using integration to solve those problems.  Additional intangible benefits include:

• Improved visibility and transparency. Insight and intelligence gained from information across the value chain being available to all disciplines to improve each individual discipline not just individually but as part of a whole

• Replacing internal development team.  By adopting a systematic approach to Software Lifecycle Integration, it is possible to reduce the overhead of running the business process. For example, moving some of your best programmers off of internal facing IT / DevOps and on to far more valuable opportunity creation has an associated value.

• Long term trending and a data warehouse. By exposing an end-to-end process and applying automation to the solution, it is possible to use the information in different ways. One great way of using the information is within a data warehouse, which can be used to explore trends and do analytics which you could never do without a consistent integrated view of the software delivery process.

Step 5 – Measure and Learn

The initial business case is a moment in time and is created by spot analysis and time and motion studies. To achieve true long-term process improvement, a continuous measurement process is required, allowing that measurement data to feed into improvement initiatives and Kaizen opportunities. It is therefore important for any software delivery organization to put in place a repository of measures over time. There are many metrics that add value to software projects, but from an integration point of view those metrics include:

• Batch size – How many requirements, defects, tasks or test plans are moving around the system. Larger batch sizes make sense for well understood systems, smaller are more appropriate for applications where there is a large amount of unknown? By measuring batch size, it is possible to identify opportunities for improvement based on the relative size of the batches.

• Flow – How does work flowing between the different tools provide insights into bottlenecks and disconnects between tools? Flow is crucial for process success. When an artifact is created in one system and does not flow quickly into its next state or system, those disconnects are often indicative that there are problems with the process and integrations.

• Artifact change rates – Defects, requirements, test plans and tasks will all change during their lives on a project, but it is important that this happens in a continuous and managed way. Heavy requirements churn or defect creation spikes can indicate certain issues with the process.

What SLI means to you

Software Lifecycle Integration (SLI) is an emerging but important discipline that requires organizations to invest. SLI is the glue, connecting the disciplines that enable software delivery to be treated in the same way as other business processes.  By doing so, SLI provides direct returns on the investment but also allows greater returns on the investments made in each discipline on its tooling.  However building the business case for SLI is always difficult, as integration is less tangible than other tools such automated testing, but the ultimate value is much greater as information is made available in multiple places and different contexts. Application development professionals should:

• Treat software delivery as a key business process. For many organizations, software delivery is the last key business process to be evaluated, optimized and automated. By treating this business process in the same way as other key business processes such as sales, operations, accounting and logistics you will not only focus the organization on improving its value, but you will also be able to apply the decades of learning on business process improvement. That kit bag of ideas and focus enable you to apply financial management and build a stronger case for automation and integration.

• Look at the end-to-end flow. The key to building the business case for integration is to consider the end-to-end flow, from inception to implementation and maintenance. By not looking in detail at each discipline, but instead focusing on the transitions between the disciplines, it is possible to optimize the software delivery process without massive process change.  The beauty of SLI is that integration facilitates improvements without causing disruption in any one silo.  Each group can continue to work with their own tools, with their own workflows, but still gaining the visibility and benefits that comes from information being synchronized in real time.

• Apply the five step process for building the financial model for integration. By understanding the opportunity, the current cost and associated benefit of integrating each discipline it is possible to build a financial model for integration.  Spreadsheets, manual processes and email are easy opportunities for elimination to be replaced with automation via integration.

Look to company initiatives to connect to. Agile, Lean, DevOps and enterprise PMO initiatives are great candidates to associate the cost of change with. These initiatives often have strong leadership looking for tangible benefits that can be achieved with integration. Many of these initiatives require improved flow, better collaboration and cross discipline / tool reporting that software lifecycle integration will provide.

Download the whitepaper

Putting the L in ALM – Making the case for Lifecycle Integration

I think everyone agrees that software delivery is not an ancillary business process but is actually a key business process, and the ability to deliver software faster, cheaper, and of a higher quality is a competitive advantage. But delivering software is difficult, and if you believe the Standish Chaos report, anywhere from 24 to 68 percent of software projects end in some form of failure.

Even the criteria for success has been questioned by many, as ‘on time, on budget, delivering the functionality requested’ can still mean software that fulfills requirements but adds no business value. Billions of dollars a year are spent on software development tools and practices in the desire to increase project success and reduce time-to-market. Each year, development, testing, requirements, project management and deployment roll out new practices and tools. Many of these additions bring value, thereby increasing the capability of each individual discipline. But ultimately, the problem is not the individual discipline; the problem is how those disciplines work together in pursuit of common goals and how the lifecycle is integrated across those disciplines.

It has been a year since I joined Tasktop, and during numerous customer visits and partner discussions, two things are very clear: 1. the landscape of software delivery tools and practices is going through a major change, and 2. to be effective in software delivery you need to automate flow and analytics.

The ever-changing face of software tools and practices

Add Agile, Lean Startup and DevOps to a large amount of mobile, cloud and open web, and not only do you have the perfect book title, you have all the ingredients necessary for a major change in the practice of software delivery. Agile and Lean encourage rapid delivery, customer feedback and cross-functional teams focused on delivering customer value. Mobile and cloud are changing the landscape of delivery platforms, architectural models and even partner relationships. Never before have we needed to build flexible development processes that encourage both feedback and automation. Imagine spending three months writing a specification for your next mobile application when your competitors deploy new features on a daily basis. Imagine not connecting your new sales productivity application to LinkedIn, where your sales people have all their contacts. Our development approach needs to not only include partner organizations and services but also deliver software at a much higher cadence.

Automation of Flow and Analytics (reporting) is key.

I have noticed a strange relationship between increased speed, reporting and integration. When you increase the speed of delivery, traditional manual processes for reporting and analytics stop working or become an overhead. For example, one customer spent two days compiling the monthly status report spreadsheet across development, test and requirements. This two day effort required meetings with numerous people and emailing the spreadsheet around for comment and review. When the organization adopted two week delivery sprints, this work was an overhead that no one wanted to endure. Now the company had a choice: drop the status report, or look to an automated solution. Because more frequent releases meant the need to collaborate better, they opted for an automated solution that connected the test, development and requirements tools, providing a report that described the flow of artifacts among these three groups.

The automation not only resulted in creating the report but also improving the flow between these different disciplines. Suddenly there was clarity as to the state of a story or when a defect should move into test. This clarity was avoided in the manual approach, which left large amounts of ambiguity. The report drove the creation of automated flow, which resulted in a better process, which then fed the report with better data.

That means there is a sixth discipline in software delivery

Lifecycle Integration is emerging as a key discipline for ALM. It provides the glue that enables the disconnected disciplines of requirements, development, testing, deployment and project management to connect. It unifies the process and data models of the five software delivery disciplines to enable a unified approach to Application Lifecycle Management (ALM).

Without integration, many of the disconnects go unrecognized, and the flow between groups is never optimized. The larger your software delivery value chain, the more pronounced the impact of these disconnects. Factor in external organizations, either through outsourcing, application integration, service usage or open source, and these impacts can mean the difference between not just project, but business success and failure.

Perhaps we in the software industry are suffering a bit from the ‘cobbler’s children syndrome,’ with integration being a first-class citizen in the traditional processes we have integrated for our business clients for years. But the time is right to apply these lessons and build a discipline around lifecycle integration for the practice of software delivery.

Having just returned from the fantastic ALM Summit in Redmond it is even clearer to me that there is a lot to talk about when discussing ALM. The event in Redmond is focused on the Microsoft platform, but the discussions were far broader. Technology impacts such as cloud, mobile and open source coupled with process changes driven by Agile and Lean Startup mean the very fabric of ALM is changing. The announcement of TFS and GIT working in perfect harmony is illustrative of this shift. But even after 3 busy days there is still lots to talk about, which brings me to the ALM Connect, an event that myself, the Eclipse foundation and a team of great people have been working on. The event, which is scheduled for March 25th through 28th in Boston MA has all the ingredients for an amazing conference.

Deep Dive Into Content

All the sessions in the program are great, but I would like to draw your attention to a few that caught my eye during the call for papers.

• Moving towards ALM 3.0 by Forrester Analyst Jeffrey Hammond. Not only is Jeffrey a great speaker, but always fills his presentation with lots of data that you can use back in the office. In this talk Jeffery is highlighting the major shifts in the fabric of ALM. Looking at the data this talk is based on we might see a redefinition of the ALM category, which is very exciting!
• What ALM knowledge you can expect from CS graduates by Gary Pollice, professor at WPI. The emerging skills crisis in software engineering is going to affect us all so I am excited to hear how you can better hire CS graduates and make them more productive. This talk also helps to remind us that ALM is more than just tools, but includes processes and people.
• Continuous Integration at Google Scale by John Micco, Google. CI has emerged as the lifeblood of modern software delivery, and on paper seems easy, but for the majority of large organizations with complex builds, heavy dependencies and nasty test environments building a workable CI environment is difficult. In this talk John describes how a very complex CI environment can be built and maintained in a very changeable business.
• Building Mylyn 4.0 by Mik Kersten, CEO of Tasktop. Mylyn has defined how Eclipse developers interface with systems of record such as bug trackers and project manager tools, but the underlying model has not changed for over 5 years. Mik is going to describe what needs to change to get Mylyn ready for next generation ALM.

Bring your boss to ALM Connect Executive Event

ALM Connect will provide a rich set of ideas for practitioners to take back to their teams, but without management support many of those ideas will never be implemented.

Above: EclipseCon 2012 ALM Panel with Mik Kersten, Dave West, Melinda Ballou and James Governor

Solving this problem was the motivation of running an Executive event on Wednesday the 27th of March. This event is aimed at decision makers and is by invitation only.

Content highlights include:

• Twitter and Github kick off the event talking about the future of ALM and how the next generation of software development is being undertaken. These presentations will show how you can marry innovation, rapid delivery and complex development teams into an Agile delivery capability.
• ALM in action case studies. Still working on the fine print, but we will have two high profile companies who are going to present their experience with ALM and how they are using ALM to form a competitive advantage. These sessions are aimed at telling all the dirty secrets of ALM, the motivation for adopting ALM and the reality of ALM in their companies.
• The user is the center: Apps in the world of engagement by Lee Nackman from HP. Lee has been involved in ALM for many years and was one of the executives responsible for IBMs involvement with Eclipse. In this talk Lee will describe how systems of engagement have changed the face of ALM and how that is only to get worse. I expect some sneak previews of the HP’s future ALM strategy in this talk.
• Agile 2.0 software development in the era of the social graph by Israel Gat Fellow at the Cutter Consortium. Israel a leading management light on ALM and the economics of software delivery will describe the social side of development. Describing how social graphs and other mechanisms can be used to better manage and enable software delivery.
• Scrum – Success ends with middle management by Ken Schwaber co-creator of Scrum. Having Ken, one of the drivers of the Agile movement at the event will add a level of Agile pragmatism to the proceedings. In this talk Ken will present the audience with framework for taking Agile to the next level, but be warned this path is not for the faint of heart.
• The future of ALM panel – This session includes Sam Guckenheimer from MS, Lee Nackman, Jeffrey Hammond and Mik Kersten on what the future of ALM looks like and how it will affect the audience. I will moderate, so expect an exciting and thought provoking session.

If you are interested in attending the executive day, or have boss who is interested then please let us know. You may also wish to view the Executive Day landing page, or the event announcement from the Eclipse Foundation for a detailed agenda. I can promise the event will be exciting, thought provoking and inspiring. It is rare to get so many leaders on ALM in one room and at one event.

Energy, passion, Christmas markets, large beers and a crazy 80’s band are not what you would expect to associate with HP. But the annual HP Discover Europe event, which happened in Frankfurt, Germany from December 4th through 6th, included all that and more, and Tasktop was there…

I am always blown away by the sheer size and scale of HP Discover. The event brings together the whole portfolio of software, hardware, and services into one integrated message. For many industry pundits, who predicted the demise of HP, the event is a showcase of why HP is far from dead. Yes, there are issues, complexities, contradictions, and even a few false starts, but HP has enough ideas and energy to continue to deliver customer value well into the 21st century. In particular, I would like to draw your attention to two innovations in software which have made me stop and think – and yes, Tasktop is involved in one of them.

HP Anywhere
Okay, vendors, even my Grandmother has a mobile solution, but I was surprised by the sheer scope of HP’s story. The first release of this technology has concentrated on allowing HP legacy software to be accessed from mobile devices. Cynics may say ‘lipstick on a pig,’ but HP, like its customers, has to somehow navigate its legacy and heavily used software into a mobile world. To solve its own problems, HP is building a platform that can also help solve many of its customers’ issues. But HP Anywhere has a much grander vision, providing a framework to enable applications you create to be written once but deployed to many platforms, service hosting for simple connections to legacy software and development tools to enable mobile development. An interesting move, and it will require a fundamental shift in focus for software teams, who traditionally have not worked with developers or been aligned to a particular platform.

Agile Manager
Speaking of developers, Agile was also a key focus for HP Software with the release of Agile Manager, a SaaS offering that provides support for Agile project management, planning, and execution. Tasktop worked closely with HP in developer tool support, updating the HP OEM’d version of Tasktop Dev to include Agile Project Manager artifacts such as stories, tasks, and epics. This means that the team can plan in Agile Project Manager, and developers can work in their IDE on the same work items, updating them and then having them flow into HP ALM. This provides an end to end Agile solution from HP and with ALM / ALI folds into development management supporting the connection to the subversion change set in ALM. As you can imagine, there were lots of interesting discussions on what future integrations would look like with both HP product management and customers, but this was a great start.

The buzz at the booth
Exciting HP strategy and technology discussions were only part of the fun. The Tasktop booth attracted numerous people who wanted to discuss how to connect HP ALM to other tools and extend the L of ALM for their company. Lots of conversations about Atlassian JIRA, IBM RTC and MS Visual Studio TFS, but also some interesting conversations about PPM tools, service desk automation and customer lifecycle management platforms. Software development seems to be moving up the stack, with ALM being connected into broader and broader business systems. As an advocate of ALM and its mission, it was very exciting to hear ALM mentioned in the same breath as other more traditional business processes. And, for many organizations, ALM is a key business process!

An exciting three days, and I am already looking forward to HP Discover 2013 Europe, which will be held in Barcelona!

In my role as Chief Product Officer at Tasktop I am lucky enough to visit lots of clients and talk to them about their ALM strategy. I get to sit in rooms with very smart people talking about their current tool stack, their challenges and where they think tools are going in the future. These talks are always enjoyable and give me the opportunity to observe at first hand the growing importance that software delivery tools have in delivering real business value. Tool strategy motivations are often led with phrases like ‘we want to deliver software faster’, or ‘the business wants us to move into mobile’. It is a fact, software delivery is a key business process, and thus the tools that support it are crucial to the business as well. Every increase in velocity, quality or reduction in cost has a major impact on the bottom line, either delivering business value faster, keeping customers happier or freeing funds up that can be spent on other important things.

Ok, I hear you say, get off your soap box Dave, we have heard it all before. But, bear with me for a moment because here is something you have not heard before. Frequently I have to admit these conversations are not as structured as they should be and I feel that I am missing something. As an analyst you would never have heard me say this – but yes, I feel that I am often poorly equipped to structure these discussions to a positive and effective outcome! I feel that we need to apply the practice of software architecture to the discipline of Application Lifecycle Management (ALM).

Now I have done a bit of Architecture work, even co-authored a book on the topic, so I have had some experience in architecture development, but frankly I never associated this work with ALM. Always thinking that ALM was just a strategy discussion, never an architecture problem – I was wrong. If you apply architectural thinking to ALM I believe that the resulting view of your ALM domain will be more insightful, better structured and the resulting strategy will be robust.

So, what does an ALM architecture look like? Applying some standard architectural models you need to think about :

	What are the objectives of ALM – Without a clear understanding of the reports you want to find, or the objectives those reports help you execute on, it is very hard to make any decisions about long term architecture.
	The information / data model – A model that describes the key entities and their relationships. For example, how is a defect associated with a requirement, or how are requirements composed in terms of flow, functionality, behavior etc.? This can also be the model where ownership is described.
	The process model – Not as detailed as a SDLC, but in general terms describe the major phases a project or release goes through. Now, this process model should be agnostic to particular process flavors such as Scrum or Waterfall, but instead concentrate on the major steps work goes through.
	The states the key entities move through – Thinking about the entities and their life history. These state transitions can be mapped to the process model, allowing some level of validation and completeness.

Now, some of you will be thinking – Wow, another opportunity to build complex UML diagrams and spend weeks doing analysis and design and I am not proposing that. Instead I would encourage ALM process owners to instead focus on asking the questions these models ask, and then documenting the findings on the whiteboard. The act of architecture is often more interesting than the actual architecture itself.

Once a high level understanding of the ALM architecture is achieved it is possible to then start overlaying tools, departments and then mapping that back to the objectives. This often highlights problems with the existing tools, or their implementation and encourages particular integrations or additional data storage.

If you are interested in this topic then consider taking part in a webinar on ALM architecture which I am hosting: Make your ALM Architecture Lean. The challenges and importance of defining your ALM Architecture.

I think it is about time we got a bit more structured about ALM and architecture is a good place to start…

In 1995 the Standish Chaos report cited the lack of good requirements practices as the principle reason why requirements fail. Since 1995 our industry has strived to improve the practice of requirements with approaches ranging from the Rational Unified Process to Scrum techniques such as storyboarding and JAD sessions. But there is still one frontier left to cross. That frontier is the ability for practitioners to access requirements in the context of their different tools / disciplines. For example, a developer seeing requirements in their IDE or a tester getting access to the requirements in their test tools. Improving the discipline of requirements only goes so far without the ability to make these requirements available to everyone working on the project. Availability is not just about communication and comments, but also includes context to the requirements and updates the process associated with the requirement.

With Tasktop Sync’s 2.4 release, we have extended our integration ecosystem to include requirement tools, allowing software developers, testers and project managers within their tools to access the same requirements that the business analyst or product owner is working on in their tool of choice. To put this into context let me tell you a story about a project that Tasktop worked on with a vendor where requirements were held in two disconnected systems and the pain it caused us. Of course, I have changed the names to protect the innocent (or guilty for that matter).

Time for a bit of dog fooding…

The project was a simple integration project between Tasktop and Vendor X. The Vendor was developing some additional capabilities to their tool and we were providing integration between their tool and the wide ecosystem of tools we support. In other words, a project we have done many times before, and have a lot of experience with. Because of time constraints and not yet having Vendor X’s integration available as a Sync end point, we did not use our own technology to connect their requirements tool to our development tool. In the past we, have bootstrapped on almost all of our ISV partners’ solutions when delivering an integration the moment it was showing tasks. Instead, we agreed to the practice of sending a spreadsheet every week to describe the progress of work and discuss any dependencies. Everything looked like it was working fine. Progress was being made and both their development and ours was running on schedule. That is what we thought until testing got involved.

Both our companies have testing teams, with Tasktop’s testers using the same tool as our developers to log defects, while the vendor’s team uses a different tool. Suddenly chaos started creeping into our project. Things that we assumed were working and that we understood were being debated. Defects on the requirements started popping up and both teams started blaming each other. The spreadsheet, which was used to discuss the work suddenly, became a thing of terror and argument. And emails started flying around to resolve issues and problems. Often it was hard to tell what the true state of the project was without searching through emails, the spreadsheet and your own defect and requirements system. The pain level on the project reached epic proportions and we almost missed the release date, a hard thing to swallow for a team that prides itself at always delivering on time. We did deliver, but it required heroic management by both teams and relied on two people keeping everything in their heads. Ironic that a company that helps its customers to integrate their ALM systems of record did not follow their own advice. Version two of the project did not make the same mistake with all three systems being sync’d, allowing our tools tracker and their JIRA and HP QC systems to be integrated. Email is only used now to remind people to look at these systems and for a regular ‘thank-you’. We learnt the following key points:

1. Ensure that you have one view of the truth even if it is in two or three systems. The overhead of managing a spreadsheet in addition to each organization owning a system of record was too much for both our teams. By getting both teams to work on the same stories, even if they are in two different software tools, it helped us ensure that everything was on track and many debates about what version of the truth can be negated.

2. The “e” in email stands for “evil”. Replace the heavy use of email between the different teams with a real system of record. That means that the number of emails can be used as a measure of system success. The larger the required number of emails the less the system is working. Emails seem like a simple solution to collaboration and communication, but too often emails are answered out of order, different people are emailed and there is no way to get a true picture of the truth.

3. Spend time up front even if you are very smart to define the flow. We have been building integrations for years, and so thought that we did not need to spend time creating a working system with the vendor up front. But actually deciding on the process flow, and resolving process issues such as what we mean by BP1 or Priority A allows for a much more simple life. I am not saying that disagreements will be removed, it is a software project after all, but at least you will be arguing about the right things.

4. Get real time information. The weekly spreadsheet and email became slow, with teams looking for other processes to get the right information, and because of time zone differences those processes often meant yet more email. By connecting the systems in real time our two companies created a continuous communication model. Also because the comments and discussions were being held on the original stories we had one place to look for history.

The cynical amongst you are saying “well that is a great story to sell your product” and yes you would be right, but there is nothing better for a product company than to experience the same pain as their customers. But immaterial of if you use Sync or just adopt one tool throughout your organization the value of concentrating on flow up front, and putting the process front and center is immense. Adding requirements to the Tasktop Sync story allows you to extend the flow into the requirements processes and helps to ensure that requirements are not to blame for project failure.

If you’re interested in hearing more from me and others on the topic of Agile and how traditional requirements management has created a world of Water-Scrum-Fall, see the EclipseCon 2012 Analyst Panel with myself, Melinda Ballou of IDC and James Governor of RedMonk.

We are pleased to announce a new partnership with CA to deliver OEM versions of both Tasktop Dev and Tasktop Sync for CA’s Agile Vision and Product Vision products. Over the last decade CA has built a reputation for delivering tools that enable better management of projects and programs. Their Agile Vision and Product Vision products provide focus on visibility, planning and requirements management for projects that require strong customer orientation and speed to market.

These products act as the beach head to CA Clarity, the market leading PPM tool. This allows teams to work in an Agile way whilst integrating into a broader portfolio view managed by CA Clarity. Tasktop Sync and Tasktop Dev for CA Vision extend that story into a broader development ecosystem. Through Tasktop, developers working within their IDE can directly access CA Vision artifacts and connect those artifacts with other development tools used in testing or deployment.

The solution enables customers to:

		Use real-time traceability, visibility and reporting across diverse third-party tools for cohesive management of software projects in heterogeneous IT environments
		Report on accurate development status and time tracking information collected at the source and rolled up to Agile Vision and CA Clarity
		Employ enhanced developer experience and productivity tools for CA Agile Vision developers
		Connect with other ALM products from vendors such as Microsoft, IBM and HP
		Collaborate with distributed teams and tools
		Reduce ALM deployment risk by avoiding rip and replace strategies and extending the life and ROI of existing ALM investments

The partnership with CA continues to re-enforce Tasktop’s mission of connecting the world of software delivery. Over the coming weeks we at Tasktop will continue to post more information on how you can take advantage of this OEM.

The press release can be found here.

Contact us at info@tasktop.com for more information about the new CA integrations or feel free to reach out to me at dave.west@tasktop.com if you have any questions.

In my previous blog ‘a call to action for our industry – it is time for Lean ALM’ I described if, as an industry we do not change our approach to ALM, our ability to innovate and deliver value will decrease. I use the analogy of auto manufacturing, describing the need for an approach akin to Lean to transform the way we approach software. My call to action was that it was time to adopt “Lean ALM”. It is time to drop the dogma of sequential, inflexible, poorly automated and traditionally managed approaches and replace it with an approach that takes the ideas of Lean and combines them with ALM to create a next generation way of approaching applications lifecycle. But what is Lean ALM?

Lean is increasingly an over loaded term, so we should start with the basics. At the macro level Lean is the focus on value whilst reducing waste. To reduce waste and build the perfect value creation process, organizations must focus on the value stream, create transparent measurement, empower people to be able to change and improve the value stream. Lean then provides the practitioner with a large array of techniques such as A3, Kanban and the 5 whys to aid them in their pursuit of perfection.  Lean is as much philosophy as it is technique; with Lean followers all approaching the organization in a Scientific method and ruthless measurement oriented way. The result is organizations that are not only efficient, but also driven to deliver superior customer value.

ALM is what PLM (Product Lifecycle Management) is to product development providing a unifying management approach to the practice of software engineering. It focuses on breaking down barriers between the disciplines of software engineering such as requirements, development, test and deployment and creating a unified approach to the management of the application.  ALM is also described as the way of automating the SDLC and promoted by vendors as the motivation to introduce integrated tool platforms. But ultimately ALM is all about business management across the complete lifecycle of the application.

Lean ALM, applies Lean Thinking  to the lifecycle of the application. Lean is a natural complement to ALM providing not only a set of practical techniques, but more importantly a philosophy focused on increasingly value and reducing waste. By adding Lean to ALM an organization can think of not only applying management techniques to software engineering, but in the context of a set of principles that drive customer value. This leads us nicely to 5 principles that become crucial:-

Lean ALM, applies Lean Thinking to the lifecycle of the application. Lean is a natural complement to ALM providing not only a set of practical techniques, but more importantly a philosophy focused on increasingly value and reducing waste. By adding Lean to ALM an organization can think of not only applying management techniques to software engineering, but in the context of a set of principles that drive customer value. This leads us nicely to 5 principles that become crucial:-

1. The Applications Value Stream – Lean is a process oriented approach, thus it should come as no surprise that the flow of work on an application is a key element to Lean ALM. Understanding the flow of creation, improvement and support is crucial to successfully improving its value and reducing its waste.
2. Autonomy – When talking about improved productivity, Peter Drucker describes, how knowledge workers need to be free to decide how they work. With increased innovation demands being placed on software engineers the need for autonomy and freedom only increases. Allowing developers to decide how they work, what tools they use and even what machines they work on provides an environment that is both motivating and efficient.
3. Adaptability – At the heart of Lean is the desire to have flexible, dynamic and responsive systems. The classic feedback loop that Eric Reis wrote about in ‘Lean Startup’. Agile methods are cited by many for providing flexibility, but the reality of Agile is its focus, for many is the development team. Lean ALM requires a much broader view of the value stream applying Agile and other processes as necessary.
4. Transparency – To enable a flexible and responsive system Lean ALM must provide information to all the people involved in the system. This information must be real time and in the context of their usage and environment. By providing transparent information you equip people with the ability to see what is happening, and react.
5. Collaboration – ALM is a team sport. Enabling a collaborative environment where both structured and unstructured information is shared is crucial for the development of the software, but also its maintenance. For example, wouldn’t it be great for support to see the known defects and the discussions associated with them.

Thinking about Lean ALM provides a great foundation for transforming the value chain of software delivery and maintenance. But it application will require change – change to the way in which delivery is thought about and valued. Also it will create a new role, one of process owner, ALM architect or sensei. This role is crucial for success, as someone needs to drive this change into an organization.

So what should you do..

1. Start thinking about Lean – read books like the machine that changed the world by James Womack.
2. Identify your sensei – Finding someone who wants to drive change into the organization and is respected and valued by their peers.
3. Look to your measures – what can and should you start measuring to deliver change and value into your software delivery capability.

And of course listen to a recorded webinar.

It would be hard to miss the sheer volume of applications being thrust into the market on any day. Apps seem to have grown to the point where everything you do in life requires an app to support it. Add to that volume of code being pumped into every device that you switch on and you are seeing an explosion of software the likes of which we have never seen before. Oil might be the commodity that the media talks about the most, but frankly software is the commodity that drives innovation in our economy.  Unlike the commodity oil, software is not found by exploration; instead it is created by a select group of people. The number of people who can create, manage and deploy software has a direct effect on its price and value. It therefore comes as no surprise that a crisis is looming.

For many people reading this blog, crisis may seem too strong a word – After all the oil crisis in 1973 left Americans waiting in line for gas, and as a child I remember the coal miners’ strike in the UK in the 70’s that let me spend Tuesday and Thursday afternoons at home.  They were real crisis’s – crisis that everyone is talking about. The situation with software surely is not of that magnitude! Well tell that to an employee of Blockbuster, Borders or Tower Records. The inability of those companies to exploit software fundamentally destroyed their business.  And increasingly it is affecting companies in other sectors ranging from manufacturing, to retail. Software is eating your lunch, and you don’t know it!

As software development pro’s we are perhaps the best placed to see the change. A change in our economy that has our friends, parents and even our dentist talking about their latest app, or how Groupon saved them money on a fantastic dinner. But unfortunately, though we see the change we seem unable to accept that this means our lives will have to change. We accept that we will have to use different technologies and programming models, but our jobs, the process that we follow, and how we collaborate with other practitioners will also have to change. For many Agile defines that change – describing a set of practices that will fundamentally improve our lives, allowing us to adapt to the unknown in a much more effective manner.  Agile does provide a great set of practices that help teams build software just a little bit better, but does not provide guidance for radical change of the complete value chain for software.  It does not equip our management with the tools necessary to manage the software assets inside and outside of their organization. Application Lifecycle Management does. It provides a management discipline to the practice of software delivery. But ALM needs to change in response to the crisis.

Perhaps the only other industry that has gone through such a transformation is the automobile. In the 70’s a fundamental change happened to the discipline of manufacturing. In response to changes in the market, the practices of Toyota made their business much more effective than those of their rivals. This led to Toyota becoming the poster child of the automotive industry, and Detroit having some rocky times that it has only just started to emerge from. The practices that allowed Toyota to succeed have been described as ‘Lean’.  The focus on reducing waste, whilst increasing value with empowered workers supported by information and techniques drove a different manufacturing process, but also sparked a revolution in many industries. It is time that ALM adopted those same principles. It is time for Lean ALM.

Still interested in the whole idea of Lean ALM? Come to the webinar on May 31 and hear a more detailed description of what it means.

Lets get the dialogue going…