Disciplined Agile

On April 19 Disciplined Agile Consortium ran a webinar entitled Disciplined Agile Offshoring: Making it Work for Both the Customer and the Service Provider (follow the link for the recording and other stuff).  During the webinar we received a lot of very good questions, most of which we were able to answer.  We’ve decided to write up the answers to these questions here.   We’ve organized the answers into the following topics:

1. Product Owners
2. Testing
3. Measurement
4. Common Pitfalls
5. Miscellaneous

Product Owners

Ideally, what will be the Product Owner and Team Leader’s location in outsourced agile team? Can a Delivery Manager role be infused?  The Team Lead and Product Owner (or a proxy) should be on site with the development team. Many times, however, the PO is located with key stakeholders who are rarely at the same location as the development team. In this case there will be a need for a proxy, either a business analyst or better yet a (Junior) Product Owner at the site with the team who interacts with the (Chief) Product Owner regularly. You will likely need to apply the Ambassador strategy and have people fly between locations regularly.

Do most successful outsource agile projects have a product owner (junior or otherwise) and team lead role at all sites?  I would suggest that. The team needs someone who can answer questions regularly. The (Chief) PO needs to interact with stakeholders regularly.

Testing

What is included in the scope of the Outsourced Work? Should it include system testing and QA testing?  This depends on what the contract calls for. It is possible to outsource most of the testing effort if you choose to.

What cannot be outsourced apart from UAT/Integration Testing?  Actually, you could probably outsource a lot of your integration testing effort if you choose to do so. User Acceptance Testing (UAT) needs to be done by stakeholders and those people work for the customer organization, not the service provider.

When you’re working for outsourcer, I think it is better to do manual test, to see all bugs before than spend time on automating tests. Is automated test writing always better than manual testing? I think we lose the time on automation.  Automation of yours tests, or I guess more accurately your checks, is absolutely critical to your success. You can’t afford to not automate as much of your testing as possible. Yes, some testing will be manual at first, but once you understand how to run the test manually you should be able to automate it in most instances.

Measurement

What the metrics to evaluate the outsourced agile delivery?  This depends on what your priorities are. Are you trying to improve time to market? Quality? Return on investment (ROI)?   What you measure will be driven by what you’re trying to achieve. We’re a firm believer in an agile approach to GQM.

How to measure the performance of team during outsourced agile delivery?  Once again, it depends. A very good strategy is to include code analysis tools in your continuous integration (CI) strategy that provide the customer with real-time insight into the quality being delivered by the service provider.

Are Development Intelligence (DI) dashboards and code analysis tools something the consumer should expect the Service Provider to have and be using, or is this something that the Consumer needs to acquire and then share with the Service Providers?  It would be incredibly foolish not to use such tools. There are many very good ones available free of charge via open source, as well as some very good commercial tools.

Common Pitfalls

Apart from sending ambassadors, can you suggest any other approaches to eliminate cultural differences and we-they attitude?  The only way to reduce cultural differences is to work closely together.  If you’re not willing to spend at least some money on travel then I would seriously question why you’re doing offshoring at all.

What kind of indicators stand out for failing offshoring activities?  The primary cause of failure of an offshoring effort is an inappropriate procurement process by the customer itself. Other failure factors include an inflexible approach to changing requirements, inadequate monitoring/governance of the project, unwillingness to pay for travel, and unrealistic expectations by the customer.

Miscellaneous

Do you recommend doing development in one place and testing in another?  No. Organizing teams by function injects a lot of overhead, cost, time and risk into your software development efforts. A much better approach is to have a whole team at each location with the skills and resources required to get the job done. Some testing may still need to occur on the customer site of course, but that should be a small part of the overall testing effort.

How can we possibly be called agile when the offshore team is developing while the onshore teams sleep, and vise versa? We fix this with 20 min standups, and heavy process, and using process over comms is by definition, not agile. Should we be happy with water-agile in this case?  You can strive to be as agile as possible in the situation that you find yourself in. As you learned in the webinar there are many strategies that you can apply to become more agile. You might also find our article on Agile GDD to be of interest.

How do you encourage a move away from sign-offs?  There isn’t an easy answer to this one. It is quite common for us to work with organizations to help them to evolve their IT governance strategy to be more agile in nature. We often coach and mentor IT governance people to help them to move away from signing off on artifacts to a more light-weight, risk driven approach. My suggestion is to contact us for help.

Can you share any successful case study in more details?  You can find some fairly easily via a quick web search.

A common question that we get all the time is how do you take a disciplined agile approach to metrics.  This is a fairly straightforward question, but it has a potentially complex answer.  At a very high level the answer is to keep your metrics strategy as light weight and focused as possible.  One way to do this is to adopt an agile version of the Goal Question Metric (GQM) strategy. The fundamental idea behind GQM is that you first identify a goal that you would like to achieve, a set of questions whose answers are pertinent to determining how well you’re achieving that goal, and then the metric(s) that could help you to answer each question.

An Example

Consider the goal of improving time to market (reducing overall cycle time in lean parlance).  The following table summarizes potential questions, and their supporting metrics, that we could ask to help us to determine how well we’re addressing that goal.

Of course, this would only be one of several goals that you likely have for a given team.  I would hope that you have goals around improving quality, stakeholder satisfaction, and staff morale to say the least.

It’s important to note that a single metric can help to answer multiple questions.  For example, a ranged release burndown/up chart can potentially help to answer two of the questions in the table above.

Keeping GQM Agile

Unfortunately GQM has gotten a bit of a bad name for itself in the past, often because organizations took a far too heavy approach to applying it.  The technique can in fact be applied in an agile manner if you so choose.  There are several things that you need to do to keep GQM agile:

1. Keep it lightweight.  The value of improved decision making provided by metrics must exceed the cost of gathering those metrics.  The easiest way to do that is to prefer automatically generated metrics over manually captured ones wherever possible.
2. Evolve as you learn.  As you fulfill your existing goals your priorities will evolve and sometimes new goals will emerge.  You may also discover that you have new data available to you, perhaps due to the introduction of new tools or processes, that provide insight into one or more questions.  You may also find that some metrics can be dropped, either in favour of newer ones or because they simply don’t provide the insight you had hoped for.
3. Take an open approach.  Make the metrics as available to as wide an audience as you possibly can (so as to increase transparency).  Furthermore,  make it clear what you’re using the metrics for and then only use them for your stated purpose.
4. Collaborate.  Metrics can provide insight into what is going on but it is far better to have conversations with others to determine what is actually going on.  Don’t try to manage or govern by the numbers, instead work closely with, and more importantly help, the teams that you’re responsible for.

Adopting an agile approach to GQM, or something similar, is only one aspect of your overall agile measurement program, and measurement is an important part of your overall governance strategy.  More on both of these important topics in future blog postings.

Traditional IT governance typically focuses on a command-and-control, documentation-based approach. Teams are expected to adopt and then follow corporate standards and guidelines, to produce (reasonably) consistent artifacts, and to have those artifacts reviewed and accepted through a “quality gate” process. The following diagram overviews such a process for an IT delivery team – in practice we’ve seen several traditional governance lifecycles that were more complex than this and a few that had less quality gates.

Traditional governance strategies often prove to be both onerous and ineffective in practice due to the focus on artifact generation and review. For example, delivery teams will often produce required artifacts, such as requirements documents or architecture documents, solely to pass through the quality gate. The implication is that these artifacts often reflect what the team believes the governing body wants to see, and that may not be what the team is actually doing. The result is a governance façade that often injects risk, cost, and time into the team efforts: the exact opposite of what good governance should be about.

Lean IT governance, on the other hand, is a lightweight approach to IT governance that is based on motivating and enabling IT professionals to do what is best for your organization. Lean IT governance strives to find lightweight, collaborative strategies to address governance areas. It does this by focusing on risk mitigation, not on artifact generation, by leading people not by commanding them, and by enabling people by making the “right things to do” the “easy things to do”.

The following table compares and contrasts traditional and lean approaches to IT governance. The table also indicates where each governance area is addressed by the Disciplined Agile (DA) toolkit.

Related Reading:

• What is Lean IT Governance?
• Why Lean IT Governance?
• What is Agile Delivery Governance?
• Strategies that Enable Agile Governance
• Supporting Agile Delivery Team Governance

Lean IT governance is the leadership, organizational structures and streamlined processes to enable IT to work as a partner in sustaining and extending your organization’s ability to produce meaningful value for your customers. There are several reasons why this is important for your success. Lean IT governance strives to ensure that:

1. Your organization’s IT investment is spent wisely. Organizations invest in IT to enable them to run and extend their business. From a financial point of view, your goals should be to regularly and consistently create real business value and to provide appropriate return on investment (ROI). To do this you must determine how you will execute your strategy by selecting and prioritizing the most valuable initiatives to undertake. You must also monitor these initiatives to ensure that they fulfill their promise, and if not then remediate them appropriately.
2. Your IT strategy supports your organization’s needs. Your IT efforts should deliver consumable solutions in a timely and relevant manner AND operate and support those solutions once in production. Part of your IT governance efforts will be to ensure that this is actually happening in practice.
3. Your IT teams are empowered to carry out their work. An important aspect of IT governance is to ensure that people and teams have the authority to fulfill their responsibilities. Many agile transformations run into trouble when the roles and responsibilities of people are not agreed upon, or when they are they are not properly supported by senior management. Another important strategy is to empower teams to own their process, to self determine how they will work together, enabling them to tailor their approach to meet the needs of the situation that they face.
4. People are motivated to work together effectively. There are several aspects to this. First, IT teams need to work effectively with their stakeholders. For this to happen in practice IT professionals need to understand the fundamentals of the business domain that they are working in and business stakeholders to understand the fundamentals of IT. Second, IT teams also need to work effectively with their IT colleagues. To do this you must adopt processes and organizational structures that encourage people to collaborate together and to learn from one another. Third, stakeholders need to work together effectively when it comes to IT. Your organization has limited resources to invest in IT, so it behooves your IT department to work with stakeholders to invest those resources wisely. Doing so are important aspects of your Portfolio Management, Product Management, and of course your solution delivery efforts.
5. Risks are monitored and mitigated at appropriate organizational levels. Although team-level risk mitigation is a good start it isn’t sufficient from an organizational point of view. Many small risks that are acceptable individually can add up to a very large risk for your organization. For example, one team using a new technology platform is an experiment. Fifty teams adopting that new platform at the same time is a significant risk if the platform proves to be problematic. Someone must be looking at risks from a portfolio perspective and guide teams accordingly.
6. Your IT infrastructure is sound. Your IT department must be able to operate and support solutions that are in production over both the short and long term. Your IT governance effort should guide and monitor your teams to ensure that they leverage and evolve your IT infrastructure effectively.
7. IT works in an open and collaborative manner. There are several ways that the DA toolkit promotes this. First, IT solution delivery is performed in an agile manner that is inherently open and collaborative. Second, all IT teams should present accurate and timely information to stakeholders, not just solution delivery teams. For example enterprise architects can make their work available to everyone, as can your portfolio management team, your data management team, and so on. Third, stakeholders can and should be educated in the fundamentals of IT so that they better understand how to work with IT teams. Fourth, IT professionals should be educated in the business domain and fundamental business concepts so that they can interact more effectively with stakeholders and understand how to serve them better.
8. All of these things will continue to be true now and in the future. Lean IT governance balances your short-term and long-term needs. Too many organizations have allowed technical debt to grow in recent years, for the skills of their IT staff to stagnate, and to continue to tolerate traditional IT process strategies from yesteryear. This is because they allowed short-term priorities to trump long-term health. We must do better.

There are two fundamentals reasons why IT practitioners should be interested in lean IT governance:

1. It’s happening, like it or not. Regardless of the size or your organization, the length of time it’s been in operation, or the sector(s) in which you work, someone is keeping an eye on and guiding your IT efforts.
2. You deserve to be governed effectively. Sadly, as we’ll explore in the next posting in this series, most IT governance strategies prove to be ineffective in practice due to application of traditional strategies and ways of thinking.

Lean IT governance is a critical aspect of the Disciplined Agile (DA) toolkit. Delivery governance activities were originally built into Disciplined Agile Delivery (DAD) v1.x. The recent release of Disciplined Agile 2.x extended this thinking in two ways. First, each of the new process blades includes a process factor focused on governing that activity. Second, there is a specific IT Governance process blade that coordinates all IT governance activities across your IT process.

Related Reading:

• What is Lean IT Governance?
• What is Agile Delivery Governance?
• Strategies that Enable Agile Governance
• Supporting Agile Delivery Team Governance

As with most things in IT, there is no standard definition of what IT governance is. For example, the IT Governance Institute provides this definition:

“IT Governance is the leadership, organizational structures and processes to ensure that the organization’s IT sustains and extends the organization’s strategies and objectives.”

Gartner, on the other hand, offers this definition:

“IT governance (ITG) is defined as the processes that ensure the effective and efficient use of IT in enabling an organization to achieve its goals. IT demand governance (ITDG) is the process by which organizations ensure the effective evaluation, selection, prioritization, and funding of competing IT investments; oversee their implementation; and extract (measurable) business benefits. ITDG is a business investment decision-making and oversight process, and it is a business management responsibility. IT supply-side governance (ITSG) is concerned with ensuring that the IT organization operates in an effective, efficient and compliant fashion, and it is primarily a CIO responsibility.”

In Disciplined Agile, we promote the following definition:

“Lean IT Governance is the leadership, organizational structures and streamlined processes to enable IT to work as a partner in sustaining and extending the organization’s ability to produce meaningful value for its customers.”

As you can see in the following diagram, IT governance is part of your organization’s overall corporate governance strategy. IT governance encompasses several more narrow forms of governance, including but not limited to the governance of IT delivery/development, data/information, IT security, IT investment, enterprise architecture, and IT operations activities.

IT governance typically addresses areas such as:

• The effective and timely investment in IT to sustain and extend the organization over the long term
• The evolution and support of roles and responsibilities to streamline how people work together
• Definition of decision rights and decision making processes to streamline interactions between people
• The evolution and support of common procedures and guidelines to ensure appropriate commonality of activities and artifacts
• The evolution and support common roadmaps to guide the efforts of IT teams
• The monitoring of activities to provide insight into their effectiveness
• Formation of a governing body that is responsible for guiding governance activities
• Definition of exceptions and escalation processes to streamline critical interactions
• Creation of a knowledge sharing strategy to grow individuals, teams, and the organization as a whole
• The support and monitoring of risk mitigation strategies to promote appropriate and holistic adoption of IT solutions
• Adoption of a reward and compensation structure to support the attraction and retention of excellent staff
• Status reporting to share information throughout the organization

In future blog postings we will explore why IT governance is important, the differences between traditional and lean approaches to IT governance, and the activities addressed by IT governance.

Related Reading:

• What is Agile Delivery Governance?
• Strategies that Enable Agile Governance
• Supporting Agile Delivery Team Governance