Вы находитесь на странице: 1из 16

Leaning IT: Applying the Principle of “Pull” to Scale Agile Teams

By Jean Tabaka and Ryan Martens

Abstract:

Reaping the benefits of Agile software development beyond the team level is an enticing proposition. In fact, in today’s competitive climate and brutal economy, perhaps it is even more than that — it is a necessity. Based on documented successes, organizations are recognizing the business imperative to “go big” with Agile and as a result, they are confronting the confusion and churn of when and how to scale their Agile adoption.

This white paper introduces the Lean principle of Pull and applies it as a theme for prioritizing actions and practices within Agile Teams and Programs. In this paper, you will learn:

• The specific practices that adhere to the Pull discipline

• Methods to keep you on the right path

• Roadblocks to success

• Expected results of successful adoption of Agile for the Program

• Tooling to support the successful adoption

Is your organization ready for this Agile “means to an end” or is Agile adoption inadvertently creating a classic “fix that fails?” Can Agile truly work at the Program level?

This white paper is based on actual experiences of professionals who helped steer many of the largest Agile implementations done over the last five years. Dedicate yourself to creating great Teams and superior Programs with the guidance provided here around the Lean discipline of Pull. Your reward will be the poise to gracefully continue to scale, mature, and win with Agile.

Copyright ©2008 Rally Software Development Corp. All rights reserved. www.rallydev.com

Leaning IT: Applying the Principle of “Pull” to Scale Agile Teams

I. Setting the Context: Lean Principles and the 5-Step Enterprise Agile Adoption

Agile software development has classically emphasized project management and engineering practices for small, co-located teams. These teams deliver high-quality software in a short and regular rhythm. Maturity is measured in terms of team and product disciplines. How do we continually improve our team and engineering practices, product quality and code robustness? We do this by inspecting and adapting our practices in the context of team agreements and commitments. We rely on team-oriented metrics to guide how these agreements bring greater team commitment and increased value delivery.

The Agile team creates its own culture of reliability with engineering practices, social pacts, communication mechanisms and contracts with the business. In turn, business owners, such as product management, product marketing and program management, take this team-based set of practices for value delivery and quickly create similar success in a larger context. Team success plays the inadvertent role of an organizational trampoline: success in a small context attempting to “spring” into success across the organization. This presents a problem because team-based practices do not translate immediately or obviously to greater scales.

The challenge becomes more difficult when attempting to scale team successes to the program level. Have pilot teams absorbed enough discipline to act as a model for other teams of teams? What should be the basis for how a program inspects and adapts pre- defined patterns? Are these patterns the right path to scaling?

A. Using Lean Principles to Guide Agile Growth for the Organization

In their book on Lean Thinking 1 , James Womack and Daniel Jones distill the work of Lean manufacturing into five key principles:

• Specify value

• Identify the value stream

• Flow

• Pull

• Perfection

The first two Lean principles match two fundamental principles of Agile: value definition and value delivery. For the first principle, Agile methods such as Scrum call for the implementation of a prioritized product backlog to emphasize value definition. With the second principle, Agile teams continually inspect and adapt their value delivery by examining their metrics and practices over time. What does it cost us to deliver value? What is sitting in our value stream that is getting in the way of our value delivery? Through demos and reviews, Agile teams regularly peer across their value stream to evaluate tweaks that may improve their value delivery. Reading more about what Womack and Jones say about these two principles can help teams boost the power of their inspections.

But there is more to learn from Lean Thinking. What do the Flow, Pull and Perfection principles lend to Agile software development? And, how can they steer successful enterprise Agile adoption?

Leaning IT: Applying the Principle of “Pull” to Scale Agile Teams

Like many other industries, the software industry is continually seeking ways to deliver value faster and more reliably. Agile software development steps up to this challenge in a big way by calling on teams to take on dramatic development process changes. For small collaborative teams, the changes work well in decreasing the time required to produce high-quality features with reduced expenses. But, can the Agile equation be translated to more than one team, to teams of teams or to an entire organization? What can both scaling and maturity of Agile look like? How can we formulate both while avoiding the risk of failure in either? This is the point where we take Agile and overlay the three remaining Lean principles and find our guidance for scaling to Agile programs:

• Flow provides guidance on how to grade and steer an Agile team’s maturity

• Pull provides structure for programs (teams of teams) to continue maturity while scaling

• Perfection (which we refer to here as Innovate) provides the set of practices for organizational scaling and maturation of Agile

B. Lean and the 5-step Enterprise Agile Adoption Approach

So, what do we really mean by Flow, Pull and Innovate with regard to what we refer to as Enterprise Agile Adoption?

Our five-step approach, structured around three Lean principles, establishes the order and ranking of enterprise Agile adoption:

1.

Establish Agile practices with a single team that emphasizes the Flow principle.

2.

Mature more pilot teams to Agile practices using the Pull principle.

3.

Once in Pull mode, scale to teams of teams by maintaining your adoption of Agile practices in Flow and Pull.

4.

Scale to multi-organizational adoption by maintaining the Flow and Pull principles in selecting and perfecting practices.

5.

Apply the Innovate (Perfection) principle in order to scale your adoption of Agile to the enterprise level.

Our overall framework takes on this stair-step look:

level. Our overall framework takes on this stair-step look: Figure 1: The 5-Step Enterprise Agile Adoption

Figure 1: The 5-Step Enterprise Agile Adoption Approach

Leaning IT: Applying the Principle of “Pull” to Scale Agile Teams

Think of Flow as a rhythm or drum beat that guides development teams to deliver high- quality products consistently. There is no churn, no turbulence — none of the waste- packed, non-sustainable practices of linear software development, only a continuous, smooth flow of value from the team.

Pull empowers a team or program to define release requirements, resulting in good, functioning software increments that are not dependent on completing the overall project. In a highly disciplined practice of Pull at the program level, two levers are at work. First, the teams of teams can always pull ready and valued feature definitions from the involved business units. Second, the business can always pull ready and valued features for delivery from the program. There is no pushing of requirements or pushing of low-quality features. To scale across programs effectively, an organization must find a way to replicate Pull across the entire context of software/IT of multiple dependent programs.

Finally, Innovate guides entire organizations in how to bring the maturity of Flow and Pull beyond the development organization. Innovate invites high quality, high productivity and high visibility across the whole of the organization, all its divisions and levels.

While this white paper focuses on Pull as guidance for Agile teams and programs, its guidance sits in the larger context of a 5-step Enterprise Agile Adoption; that is, Team Pull adoption assumes a successful adoption of Team Flow. And, the Multi-Team Program Pull is actually recommended as a step before scaling to the Multi-Program Organization in an Enterprise Agile Adoption.

As you follow these 5 steps, you can envision scalability of practices from Team to Program to Organization as follows:

practices from Team to Program to Organization as follows: Figure 2: Practice Overview for Team to

Figure 2: Practice Overview for Team to Program to Organization for Enterprise Agile Adoption

Leaning IT: Applying the Principle of “Pull” to Scale Agile Teams

Given our 5-step approach, before teams or programs can move to a Pull mode of operating, they must first exhibit the characteristics of Agile teams in Flow:

• Are empowered and collaborative in decision making

• Begin to define a definition of “done” for how they make commitments to value delivery

• Use a time-boxed rhythm of high-quality product delivery

• Define, build and test every committed feature within the time box

• Engage in inspection and adaption practices that amplify their learning about team agreements, process and their definition of “done”

To then enable adoption of the Pull principle for programs, let us first establish a basic view of Pull; that is, what does a team in Pull look like? From this base, we can then evaluate how teams of teams, that is programs, act when in Pull.

II. What “Pull” Looks Like for One Team

The discipline of Pull empowers teams to define release features, resulting in good, functioning software increments that are not dependent on other project teams. In a highly disciplined adoption of Pull, pilot teams use two levers. First, the teams can always pull prioritized, ready, valued feature definitions from the backlog maintained by the business. Secondly, the business in turn can always pull ready, valued, “done” features for final user and system testing with potential customers. Gone are the days of pushing requirements onto teams or waiting for drop points to do final acceptance tests on key features or system performance.

Figure 3 is one team’s definition of “done” that shows its discipline to maintain a Flow of value delivery and a true readiness of Pull for the product team.

delivery and a true readiness of Pull for the product team. Figure 3: A Sample Definition

Figure 3: A Sample Definition of “Done” for an Item (Story) Ready to Pull

Leaning IT: Applying the Principle of “Pull” to Scale Agile Teams

With this definition of “done,” any item that passes these criteria is considered completed by the delivery team. In turn, it is considered ready to be pulled by the business. As the team matures, it continually inspects this definition so that readiness continually “attacks” any impediments to the business’s ability to pull ready valued items.

The Pull discipline also has a bit more to it with regard to business discipline. It constrains over-elaboration of requirements either too soon or too late. Pull sets up the business to say, “Here is what needs to be accomplished in the next two weeks.” Pull doesn’t allow surprises about business requests. It simply eliminates the waste of waiting for the prioritization and definition of the items. Pull also ensures that the business is only elaborating the highest-value items. Teams do not wait for all items to be completely detailed in order to pull work forward.

Critical to setting up Pull is an effective release planning mechanism. This mechanism begins with a product roadmap to guide the prioritization of features across themed releases. This, in turn, defines a release time box that is broken into groups of iterations. The discipline of release planning helps both the business and development teams. The business benefits from a longer term view into the delivery team’s best work at estimating a sequence of stories. Delivery teams, in turn, can anticipate upcoming stories to pull off the release backlog in a way that reduces risk and speeds feedback on high-value stories.

A. Characteristics of a Team in Pull

Given what we have just described, Agile teams in a state of Pull exhibit the following characteristics:

• The team has no surprises and no waiting in pulling sufficiently detailed value definition of items from the business’s backlog.

• The business is always working one or two time boxes ahead in its own Flow so that items are always in a ready state to be pulled from the prioritized backlog.

• The business always has the option to pull “done” RTF (Running Tested Feature) value items at the end of each time box.

• The team has a multi-release roadmap and commitment to the scope of the current release.

• The team holds a policy of collaborative emergent design based on simplicity and the feedback from the “done” items.

• The deliverable is stable, has zero defect backlog and therefore invites more possibility of shift in the eventual set of valuable features for release.

B. Potential Roadblocks

There are potential roadblocks to adopting the Pull discipline including:

• Lack of collaboration from the business: Agile asks product owners, such as product managers, business analysts or architects, to be much more engaged than in traditional waterfall approaches. A team’s ability to mature can be stopped in its tracks due to distracted or inaccessible product owners. Teams may also unearth unclear acceptance procedures that were hiding in the Quality Assurance (QA) phase at the end of their projects.

Leaning IT: Applying the Principle of “Pull” to Scale Agile Teams

• Organizational change ceiling: Because of this new, highly visible demand on the business organization, Pull maturity may encounter bumps and bruises. Pull also requires that testing be fully integrated into the team, as this is no longer an optional part of the definition of “done.” Pull discipline requires the organization to consider an organizational change backlog, critical once we move to the next level of scaling and maturity.

• Weak feedback loops on value: Without product ownership engaged, a disciplined team will still push up against a roadblock of delayed feedback loops on value delivery. Are priorities right? Are the delivered features meeting customer expectations? Does the cost of delivery (team and organizational resources) provide sufficient ROI to continue the effort?

Once team Pull is established, there are many benefits. The highest-priority features, and the ones most likely to be used, are completed first. The percentage of Work in Process (WIP) at any given time is decreased. In addition, the team releases fully-tested increments more often and, as a result, customer feedback is frequent and improved.

What do we see when a team is in Pull? Teams begin to think about the product from a higher view: The team “sees the whole” and has a clear path to delivering a high-value product. A release view of the product elevates the visibility of each iteration’s impact on the product for the team, the customer representative and all stakeholders. With this higher view, and the ability to pull only ready backlog items, the Agile team pushes back on backlog items that aren’t ready. They are able to recognize that these items that are not ready will adversely impact their commitment to release goals.

will adversely impact their commitment to release goals. Figure 4: A Team Planning a Release Across

Figure 4: A Team Planning a Release Across Time Boxes 2

When Pull discipline is fully embraced and visibility is raised to the release level, release quality is fixed. Teams now work with a zero defect mentality across time boxes and the entire system, not just within a time box for new functionality.

Leaning IT: Applying the Principle of “Pull” to Scale Agile Teams

C. Tooling the Agile Team for Pull

When implementing Pull, tool requirements for visibility and signaling increase. Teams in Pull track tasks, acceptance criteria, automated-testing requirements and defects. Teams “signal” in real time how to work more effectively and measure “done.” For visibility into release success, teams must also have access to cycle-time metrics. For example, “How long did it take me to fix that defect?”

Finally, the Pull discipline requires a highly visible, real-time automated and prioritized backlog. At any time, the business must be open to discussions about what’s coming next in the backlog, and be ready for the delivery team to plan and estimate. In this automated, prioritized backlog, business owners must be able to show emerging elaboration of information about the items. Backlog items open themselves up for 24 by 7 scrutiny.

Just-in-Time Requirements Management and Doneness Traceability provide: Shared release readiness reporting Visible

Just-in-Time Requirements Management and Doneness Traceability provide:

Shared release readiness reporting Visible system-level quality Reinforcing story by story work and pulling tasks Complete cycle time metrics

Figure 5: Project Visibility of a Team in Pull

Leaning IT: Applying the Principle of “Pull” to Scale Agile Teams

In addition to a real-time project management system that allows them to see the complete status, teams need to fix their functional- and regression-testing batches by implementing automated functional testing and system-build capabilities. See Figure 6 below.

testing and system-build capabilities. See Figure 6 below. Figure 6: Continuous Quality in Pull Testers and

Figure 6: Continuous Quality in Pull

Testers and product owners can now pull builds as required to provide rapid quality and functional feedback to the Agile team.

What are the benefits of teams in Pull? Teams become much more adept at:

• Not overstuffing their time boxes, resulting in cost savings from smoother Flow

• Providing the business market with deployment decisions based on truly “done” value items

• Fixing their quality thresholds (as a result of lessening the accumulation of technical debt)

• Increasing value gained from direct feedback from a fully engaged product management/ownership organization

• Making deployment/release decisions based on completed items, and taking in a wider view of the product, beyond one time box at a time

However, Pull discipline at the pilot team level has its limitations. Quality and throughput benefits are still limited to the scope of any single one of the pilot teams. Now is the time to scale these practices, tools and processes beyond a single team, up to a collection of teams that can deliver large-scale and complex systems.

Leaning IT: Applying the Principle of “Pull” to Scale Agile Teams

III. Scaling the Pull Discipline to Programs

Scaling the success of independent pilot teams to multiple, interdependent teams requires the same disciplines guided by the Flow and Pull principles. But now the stakes are higher. These disciplines have to be embraced and synchronized across teams of teams, or what we refer to as programs. Program Pull disciplines and practices support teams that must rely on each other either for resources, feature completion or release readiness. Adopting Agile with Pull discipline within a program is a true test of an organization’s intent to scale.

To scale Agile adoption to Pull for the program, an organization must first consider the best way to “seed” the Agile scaling effort:

• Bring in members from the pilot teams that matured through Flow and Pull.

• Bring in outside Agile coaches familiar with the disciplines required to succeed at the program level.

• Combine the two approaches and establish a “train the trainer” practice of growing the program’s own staff of seasoned, disciplined Agile coaches.

Any Program Pull approach for scaling and maturing Agile has to involve all employees in the program community. Just as in the pilot teams, all program community members are empowered to bring insights, and, with all members engaged, learning is greatly amplified. However, total participation can bring up other concerns. For example, a functional manager who owns all the QA resources might worry about how this new way of doing business is going to impact their overall QA organization’s processes and tools. This is where organizational commitment to Pull is essential. An oversight team, the program steering committee, must engage to knock down organizational barriers and incent a “whole program” view of success.

Remember, Agile requires that teams grow by splitting into teams of teams within the program versus one big team. The ensuing hand-wringing regarding splitting teams requires a well-articulated organizational rollout plan for the program. The rollout demands true, engaged executive sponsorship. For distributed program teams, the challenges only increase. And yet, the Pull discipline requires program managers and the organization to engage the entire program membership in the success of the product release.

In addition to executive support, the program has to know how it’s going to scale up to the next level. If there is no detailed plan for moving forward, or if the program doesn’t address all the valid concerns about organizational change, you’re likely to hit a glass ceiling at a single program level.

A. Characteristics of a Program in Pull

So, given these requirements and concerns for moving a program to a discipline of Pull, what are the ultimate characteristics of such a program?

• A cross-functional program steering team that clears obstacles and tends to the vision

• Company infrastructure that supports cross-program, cross-team integrated builds

• Adaptive Agile work standards that are fully embraced across all teams and continually inspected and adapted

Leaning IT: Applying the Principle of “Pull” to Scale Agile Teams

• Large-scale release planning meetings that establish a synchronized schedule and dependency mitigation strategies

• Cross-team resources balanced on a synchronized release schedule

resources balanced on a synchronized release schedule Figure 7: The Agile Program in Pull Has Intense

Figure 7: The Agile Program in Pull Has Intense Practices

B. Roadblocks in Moving an Organization to Program-level Pull

With so much to absorb for success in program-level Pull, an organization can run into seemingly insurmountable roadblocks:

• Functional fiefdoms or silos: The QA functional manager mentioned earlier or an operations team is not prepared to work at the pace demanded of an Agile program in Pull.

• Lack of infrastructure investment to coordinate distributed teams. The organization may be unwilling to acknowledge that the Pull discipline requires investing in infrastructure/tooling for increased signaling, visibility, tracking and quality.

• Other parts of the organization don’t know how to handle the program’s pace:

Marketing says, “We can’t release that fast because our customers can’t handle it.” The support and operations organizations may also be reluctant to take on the faster schedules and more feedback, despite the obvious benefits for product value delivery.

And yet, programs willing to invest in the time, training and discipline to move to Pull can reap serious business benefits:

• The teams get to market faster with a higher-value, higher-quality solution

• The teams embrace increased feature and resource complexity

• There is a unified program vision

• The quality of the entire solution increases dramatically

Leaning IT: Applying the Principle of “Pull” to Scale Agile Teams

C. A Successful Pull Example

In 2004, BMC Software, headquartered in Houston, Texas, decided it needed to move to an aggressive release schedule for one of its product lines. Their objective was to get to market 50% faster than previous releases. In doing so, BMC wanted to be able to protect quality standards and not allow defects to accumulate for the sake of product deployment. For this effort, they formed a program of teams of 93 members (developers, testers, tech writers, and architects) and adopted the Pull approach of Agile product delivery. The program held regular cross-team coordinated release planning meetings and adopted a Program steering committee to maintain the vision, remove impediments and continually invest in the tooling and infrastructure.

What was the result of this Pull discipline? BMC delivered a product with 600,000 lines of code four-and-a-half times faster than the industry average. Their overall program team was twice the size of the 45-person average, but delivered 11 percent fewer defects than average. When compared to comparable 93-person teams, they had 70 percent fewer defects. As a result, BMC surpassed its competition and is enjoying incredible success. This is the big benefit of program Pull: finished products, not just single-team software increments and faster time-to-market than competitors’ products. Rally coaching on the Pull discipline supported by Rally tooling contributed significantly to BMC’s success. This case study is part of the larger QSMA Agile Impact Study available at www.rallydev.com/ agileimpactreport.

D. Synchronized Calendars and Disciplined Program Pull

To reach BMC’s level of success, a great deal of coordination must be built into a program’s cadence. Program teams synchronize their release calendars through a full- team release planning meeting. All team members participate in the discussions, the planning and the release commitment. Everyone plans the entire product release together (see Figure 8). Every aspect of the program is lined up and synchronized, including measurement spots and iteration planning.

The program steering committee, up one level from the teams, is also on the same schedule. All the meetings and product demos are disciplined. Demos need to be conducted every iteration so that Team A knows that Team B is going to deliver what is needed. If not, feedback must be given immediately so that features, resources and schedules can be adjusted as soon as possible.

Leaning IT: Applying the Principle of “Pull” to Scale Agile Teams

Applying the Principle of “Pull” to Scale Agile Teams Figure 8: A Program Release Train Across

Figure 8: A Program Release Train Across Teams in Pull

The program steering group is managing a set of teams in Pull when:

1.

Large-scale release planning allows every team member to see the whole. The release train synchronizes schedule, dependencies, and rhythm across teams.

2.

Steering committee rhythm clears the prioritized organizational impediments. Daily and weekly rhythms match the teams’ rhythms.

3.

A set of norms emerges to enable scaling and program agreements. These are derived from collaboration and full-participation.

4.

Quality is visible daily across teams. A unified build is used to signal “stop-the-line” to all developers.

E. Tooling for Program Pull

Supporting program Pull requires tooling that elevates the signaling and tracking beyond just an Agile team level. Each team structure and its status must have a view and impact into the overall program structure and status. The Program needs to be able to delegate dependent work and do rollups across all the program’s teams. In addition to shared status across teams, a program in Pull needs visibility into system quality across components, multiple levels of planning and just-in-time requirements management.

In this way, the program is passing what could be called an amateur level and moving toward a truly expert level. If it doesn’t aggressively embrace the Pull discipline and try to scale, it will fail. The teams will remain a group of amateurs and potentially embrace the mentality of complacency, “Now that I can do this, I will just keep doing it the same way.” It’s very important now to invest in and raise the visibility of the incremental wins, and celebrate success. Also, consider re-investing the program’s ROI benefits to add more infrastructure for testing or integrating the complete software lifecycle for better feedback management.

Leaning IT: Applying the Principle of “Pull” to Scale Agile Teams

ROI & Adoption Requests Defects Business Prioritize & Define & Test & Harden & Deploy
ROI & Adoption
Requests
Defects
Business
Prioritize &
Define &
Test &
Harden &
Deploy &
Case
Schedule
Develop
Accept
Release
Support
Collaborative
Development
Task, Code, Build, SCM
P
r
o
d
u
ct
&
P
or
Agile Lifecycle
M
a
n
tf
a
g
e
ol
m
io
Management
en
t
C
us
to
m
&
er
O
p
M
er
a
at
n
io
a
g
n
s
e
m
e
n
t

Figure 9: Entire Software Lifecycle

IV. Conclusion

Agile is an approach that was originally formulated for single co-located teams. To grow our industries and build software to solve the world’s toughest challenges, we need to scale and mature. Paying attention to these guidelines around Team Pull and Program Pull can put you on the road to becoming an Agile expert beyond the team. Our approach requires leadership, discipline, dedication, and a partner like Rally who works closely with your company to make sure you reap the full benefits of the Pull solution. Rally is not simply selling an Agile tool, but success through expertise, business value, partnership, a total integration strategy and a complete solution backed by a company that is an Agile expert.

If Team Pull and Program Pull are implemented correctly, Agile and Rally can dramatically shorten your development cycles, increase quality and productivity, speed value delivery, and put your entire organization on the path to being truly innovative. Rally’s leadership can help your organization break free of older, plan-based methodologies and siloed tools while avoiding the pitfalls of a non-disciplined Agile adoption plan. Teams in Pull can lead to programs in Pull and ultimately organizations that Innovate.

Leaning IT: Applying the Principle of “Pull” to Scale Agile Teams

To move through these steps successfully, consider a timeline of organizational actions and Rally training and coaching as follows:

actions and Rally training and coaching as follows: Dedicate yourself to creating great Teams and superior

Dedicate yourself to creating great Teams and superior Programs with the guidance provided here around the Lean discipline of Pull. Your reward will be the poise to gracefully continue to scale, mature, and win with Agile.

Leaning IT: Applying the Principle of “Pull” to Scale Agile Teams

About the Authors

Jean Tabaka is an Agile Fellow with Rally Software Development in Boulder, Colorado. With over 25 years of experience in the software development industry, she has navigated numerous plan-driven methodologies in a variety of contexts (government, IT, consulting) and in a variety of roles (programmer, architect, project manager, methodologist). Her move to Agile software development approaches came in the late 90s as a result of studying DSDM in the UK. Since that time, she has become an Agile devotee, consulting with teams of all sizes worldwide wishing to derive more value faster through the adoption of Agile principles and practices.

She specializes in scaling Agile practices, applying Lean principles and practices, and building continuous planning and testing into organizations. She also creates a strong collaborative approach in how organizations adopt Agile. Ms. Tabaka is a Certified ScrumMaster and Practitioner, a Certified ScrumMaster Trainer, and a Certified Professional Facilitator. She holds a Masters in Computer Science from Johns Hopkins University and is the author of “Collaboration Explained: Facilitation Skills for Software Project Leaders” published in the Addison-Wesley Agile Software Development Series. You can reach her at jean.tabaka@rallydev.com.

Ryan Martens is the founder & Chief Technology Officer of Rally Software and an expert in assisting organizations in transitioning from traditional development processes to more Agile techniques.

Before founding Rally Software Development — his fourth software start-up — Mr. Martens directed the corporate adoption of Internet technologies within Qwest Communications, and then moved on to co-found Avitek, a Boulder-based custom software development firm where he served as Vice President of Marketing & Business Development. Mr. Martens’ successful efforts at Avitek culminated in an acquisition by BEA Systems in 1999. At BEA, Mr. Martens served as Director of Product Management for the eCommerce applications division and he was instrumental in growing that division to more than $50 million in revenue within its first twelve months.