Virtual Pair Programming

I recently experienced a new (to me) approach to pair programming. Given a set of user stories, my teammate and I were ready to begin coding the core domain library for a project. The problem: we are located about 500 miles apart. Our solution: Jitsi and Git.

With the solution created and the projects defined and waiting for us in the repo, we established a video chat. One of us shared the screen so the other could see the IDE. We talked our way through the appropriate Unit Tests which would ensure the domain entities were coded to match the requirements. As I was writing the tests, my teammate started writing the code to make the tests pass. As soon as a set of unit tests were complete, I’d commit/push my changes to the repo. My teammate pulled the changes into his local and then ran the tests. Tests passed, he committed his changes and pushed them to the repo. In less than three man-hours, we had working code with a great test coverage and a respectable portion of the requirements addressed.

This was the most efficient pair programming and the most gratifying TDD experience that I’ve had. It helps to be working with a competent engineer that understands the benefits of TDD. But it also makes pair programming a little bit easier when you don’t have to literally share a desk.

What is the Enterprise Software Product Management Process

At the base level the process for managing software products in an enterprise is very straightforward. Senior Management identifies a need for a product and a Product Manager works with Business Process Analysts to begin planning the product. Once an initial vision for the product is well understood, BPAs work with Subject Matter Experts to develop the Operational Concept. As the operational concept becomes clearly defined, Architecture and Engineering identifies a solution and begins iterating to build and deploy the software. During this phase, two key sub-processes are concurrently being executed: Manage User Feedback and Manage Change. These two processes feed into the queue for the iterations by way of the processes for managing the operational concept.

Each of these processes will be decomposed into smaller processes and their constituent activities in future posts. Regardless of the tools used, these processes should be followed. The procedures – the “How” of the methodology – defines the tools used, but for continuous improvement purposes, the process should not constrain a team to a given tool set. If the process is failing, focus on improving the process; if the tools are not enabling the team to properly complete the process, then that is a separate problem to be addressed. Sometimes the tools will force a change to the process, and that’s OK as long as the team is cognizant about the impacts of a change to the process and accept that the benefit of using the tool is worth changing the process.

Process work flow

From this perspective, it looks quite simple. And it really is, it just requires discipline to adhere to the process and self inspection to ensure that the process is meeting the needs of the team. Also, the ability to recognize when an aspect of the process is not adding value and willingness to change or even remove it when these aspects are discovered.

RACI

Processes are defined by the activities that must be completed in order to achieve the goal of the process. When talking about process we need to know the parties involved, the “Who” in the “who, what, when, where, why and how”. There are several roles that participate in an Enterprise Software Product Management process. An individual may fulfill the responsibilities of more than one role, but the scope of the duties are defined by the role in which they are acting.

Each process activity has a defined RACI – Responsible, Accountable, Consulted, and Informed – matrix which determines the participating level of each role in the context of the activity.

Responsible

The role(s) actually doing the work required by the process activity. An activity may have more than one role responsible for its completion.

Accountable

The role ensuring that the process activity is being completed in a timely and correct manner. An activity will only have one role that is accountable for its completion.

Consulted

The role(s) most likely to have necessary information in order to complete the process activity. An activity may be able to be completed without the need to consult with another role.

Informed

The role(s) that need to be informed that the process activity is in work/complete. Typically the role(s) accountable and responsible for carrying out a successive activity.

Key Roles

Below are the key roles that I believe are necessary to participate in the process of managing enterprise software products.

Senior Management

This role provides the business case and finances for the product. They control the governance of the development effort and are responsible for defining the product need/vision and for approving the team’s understanding of the Business Objectives that the product is being built to meet. The people that fulfill this role are functional area managers all the way up to the Chief Executive Officer.

Product Manager

The product manager role is the proxy for the end consumer of the product. The product manager has overall product mix responsibility for the requirements. The product manager must insure that the product vision is met through the requirements and the acceptance tests developed to verify/validate the product. The product manager must show that the product aligns with the organization’s strategic planning and fits the market segment(s) intended in the original vision statement. The product manager will insure that the product stays within budget and that the business case is realized.

Subject Matter Expert

A subject matter expert can be anyone who happens to have the knowledge of an area of the business that aligns with the product vision. A subject matter expert is responsible for communicating and transferring their knowledge to other members of the team, such that the appropriate area of the product vision can be realized.

Business Process Analyst

This role acts as the liaison between the roles that identify the business problem and the roles that will produce a solution. The term “analyst” in this role’s title comes from the fact that people in this role spend a lot of time analyzing the actions performed and the information processed by the business. The Business Process Analyst interviews Senior Management and Subject Matter Experts to define the user community and the processes that they must work through in achieving the business objectives that are aligned with the product. As these become defined, the BPA will begin working with the Test and Architect roles to define the features of the product that will be put in place to aid the users with those processes. Future posts will delve deeper into the notion of Business Process Analyst instead of the traditional role of Business Analyst.

Solutions Architect

The Solutions Architect takes responsibility for the continuous improvement and learning in the software engineering team. An architect’s role is to lead and to communicate on behalf of other engineers. A Solutions Architect lends experience and skill and shows leadership by coaching fellow engineers. The Solutions Architect is Accountable for overall system design, code reviews, and iteration tasking. The architect is also responsible for maintaining the architectural integrity of the product and ensure the success of the project by designing the foundations on which all the value can be realized. This includes defining both the organizational structure of the application and the physical structure of its deployment. In these endeavors, the architect’s goal is to reduce complexity, decrease coupling and regression effects, and increase the cohesiveness of components by partitioning the system into parts which can be built and tested independently. The resulting architecture is extremely important because it not only dictates how the system will be built going forward but also establishes whether the system will exhibit the many traits that are essential for a successful product. These include its usability, whether it is reliable and maintainable, whether it meets performance and security standards, and whether it can be evolved easily in the face of changing requirements.

Software Engineer

The software engineer is responsible for the bulk of the work coding the product. The software engineer should suffer a minimum of communication overhead allowing for a maximum effort on construction of code. In addition, during the early stages of a product, engineers may be expected to help specify product requirements not included in the system requirements and to work on analysis and architecture activities as part of a multi-disciplinary team. Enterprise software should be written with a suite of unit tests. In my opinion, using Test Driven Design is the most efficient way to achieve a clean code base. In order to write effective unit tests, the software engineer must be intimately familiar with the context for the requirements which means that interacting with the BPA heavily in the first few days of an iteration are essential to a positive outcome.

Build Engineer

A build engineer is a specialist role who performs the function of facilitating the build or integration of the source code. The build engineer will run the build, develop scripts for automation of the build and automated reporting mechanisms such as the build report. As the requirements for an iteration are solidified, the Solutions Architect will create the necessary folder structure within the source code repository to represent the required components of the system (in .NET terms, the solution and project files). It is the Build Engineer’s responsibility to ensure that for each iteration, any new components are added to the build and deployment scripts.

Test Manager

The Test Manager must understand the context for the project and help others to make informed decisions based on this context. The Test Manager works very closely with the Business Analyst in order to gain this understanding.The Test Manager is responsible for conducting test case reviews to ensure that the test cases will exercise the system sufficiently. The Test Manager also coaches fellow testers as a mentor.

Tester

The tester is responsible for writing the test cases for the requirements. A key goal for the tester is to find and report the significant bugs in the product by testing the product. Once a bug is found, it is also the tester’s job to accurately communicate its impact and describe any workaround solutions that could lessen its impact. The tester writes bug descriptions and steps for recreating the bugs easy to understand and follow. The tester participates with the entire team in setting the quality standards for the product. The purpose of testing is to prove that known features work correctly.

Quality Assurance

This role is responsible for assessing the quality in the product as measured by quality control and the quality assurance measured as conformance against process definition. QA reports variance from specification, variance from plan, and variance from process definition. QA reports can be used to assess the likely quality of the product and whether or not the organization exhibits control in its operations. With proper tooling, this role can be almost entirely automated.

Systems Administrator

The Systems Administrator is responsible for the upkeep, configuration, and reliable operation of computer systems; especially multi-user computers, such as servers. The system administrator seeks to ensure that the uptime, performance, resources, and security of the computers required to host the product, without exceeding the budget. To meet these needs, a system administrator may acquire, install, or upgrade computer components and software; automate routine tasks; write computer programs; troubleshoot; train and/or supervise staff; and provide technical support.The Systems Administrator works closely with the Solutions Architect and the Build Engineer to ensure that systems conform to the requirements as well as to provide physical constraints of available systems that may impact architectural decisions.

Why Is Process Important?

For enterprise software management, process is important because having a documented way of doing things enables adding new team members more efficiently and provides a mechanism for improvement. Process is important to the business as well as to the engineering team.

What is “Process”?

Process describes what needs to be done, not how it is done. Process allows an organization to see the information that needs to move from one state to another without prescribing how to make this transition. In this way, a process describes the nature of the business without constraining it to a particular toolset.

For an example, the process of writing a research paper hasn’t changed. You look for information in authoritative sources, then copy important quotes with their attribution. You outline what you want to say about your discoveries and then you expand on those thoughts. We used to do this with a lot of notebook paper and books, magazines and journals at the library. Now we do this with word processing software and search engines. The process – the what – hasn’t changed, but the procedure – the how – has.

In developing and implementing a process for enterprise software development, I believe the principles that should be the guiding force are: Balanced Priorities, Collaborative Understanding, Architectural Planning and Continuous Improvement. These four principles correlate nicely with the Core Principles of the Eclipse Foundation‘s Open Unified Process.

Core Principles

Balance competing priorities to maximize stakeholder value

For a software product to be successful, stakeholders and team members must converge on a clear consensus of the following factors:
  1. Constraints placed on the development team (cost, schedule, resources, regulations, etc.)
  2. Constraints placed on the solution
The challenge for all involved is creating a solution that maximizes the value delivered to the stakeholders subject to those constraints. Balance is about making the critical, cost-benefit trade-offs between desired features and the subsequent design decisions that define the architecture of the system.

Collaborate to align interests and share understanding

For a software product to be managed and built successfully, those involved must overcome the fact that there is a diverse range of interests and skills that are brought together by the common goal of bringing the product to fruition. An Enterprise Software Product Management Process should enable a team to live up to the principle of healthy collaboration by

Focus on the architecture early to minimize risks and organize development

Without an architectural foundation, a system will evolve in an inefficient and haphazard way. Such a system often proves difficult to extend, reuse, or integrate without substantial rework. Architecture is the description of the organization of the components of a system and the interfaces by which these components interact. Ways to adhere to this principle typically include:
  • Leveraging the architecture as a collaborative tool
  • Cope with complexity by raising the level of abstraction
  • Organize the architecture into loosely coupled, highly cohesive components
  • Reuse of existing assets
  • Simplifying processes and optimize on strategic systems

Evolve to continuously obtain feedback and improve

Knowing all of the stakeholders’ needs at the inception of a product is impossible and even if it were, those needs are likely to change over time. The intention behind this principle is to continuously get feedback in order to improve both the product and this process. A team can adhere to this principle by:
  • Developing in iterations
  • Focusing iterations on defined management milestones
  • Embracing and managing change
  • Establishing objective measures of progress
  • Continuous improvement through iteration retrospectives