Unless you are working alone or in a small start-up company, the project manager will have many people to deal with, within an organization, to move the project forward (see Figure 3.1).
Even though Scrum does not have a project manager per se, that does not mean that project management has been abandoned. For those of us who have some deeper experience with Scrum, we know that project management responsibility in Scrum is simply transformed and divided among the product owner, the team, and the ScrumMaster. You can learn more about this in Ken Schwaber’s seminal book, Agile Project Management with Scrum, p.15.
What Ken says in his book is that rather than having one single project manager (or ScrumMaster) taking care of all the interaction with the outside actors like in the old command and control environment, the responsibility of project management is now shared by the development team, the product owner, and the ScrumMaster as shown in Figure 3.2.
We will talk about the specifics of the ScrumMaster’s and the product owner’s responsibility in leading and managing a Scrum project in a later chapter. This chapter is mainly to raise your awareness about what you should do when interacting with the rest of the company, especially if your company is new to Scrum or if it has not chosen to adopt Scrum enterprise-wide on a large-scale.
As we discussed in Chapter 2, you will need to speak to top business or IT management in terms they can understand (the language of finance), because they will have to give the green light before you can do anything else.
When interacting with top business management, such as your CEO, President, CFO, or Senior Vice President of a Business Unit, we recommend that you avoid talking about how much Scrum will help you to build better software faster.
As business executives, they will be polite, but they will ultimately reject you while wondering why someone has ever hired you into the company—who wastes their time talking in general terms, rather than presenting the ideas to them in financial terms that they can more easily understand.
Although building better software or improving programmer productivity is important to executives, they are more interested in the company’s overall market share, large scale savings, or overall profit margin.
So, despite your excitement for Scrum, do not let yourself get carried away talking with top business management about how wonderful your software will be or how fast you will be able to build it if they will only allow you to use Scrum.
Instead, always relate your technical prowess and passion to an executive’s financial concerns in terms of numbers or at least to their overall business strategy.
Whenever you are talking to anyone in the organization, you must consider the point of view of the listener and speak to those concerns.
To help you better interact with top business executives, we have reproduced an example of the balance scorecard (Figure 3.3) for a fictional company, quite similar to one you may encounter in real life situations. The balance scorecard is a well-known concept among business executives.
The balanced scorecard for this fictional company shows what top business management considers to be their main business goals and strategy.
In this example, their goals are to:
Grow revenue
Lower expenses
Drive growth through acquisitions
Generate cash flows
What follows is their strategy in terms of customer value and what they think the company should do in terms of business processes, IT projects, and human resources.
Knowing how IT projects will fit into your business executives’ overall vision and strategy will help you communicate more effectively to them how your project will contribute to the overall strategy of the firm. Always remember that it is important to relate your project’s contribution to the company in terms of finance, which is the language of business. Your executives will thank you for that.
In some companies, the program management office (PMO) is not considered part of top IT management. We have listed it here because it is the Chief Information Officer (CIO)’s main representative in the IT department’s effort to align IT on business strategies and to continuously improve and track IT performance.
As the group responsible for IT performance and alignment with a company’s business needs and strategy, the program management office, or PMO, is the first group that you should try to meet and work with.
If you understand the PMO’s concerns, you should not have any difficulty turning the PMO into an ally, since its mission is to ensure that IT projects bring the most value to the business. This is, after all, what we all have learned the product owner’s mission should be on a Scrum project, right?
Figure 3.4 shows one of the many matrices maintained by the PMO. The upper left quadrant is the most desirable because it has high business value and low cost. Use this matrix to quantify your project in order to gain a realistic view of the true business value and cost associated with your project. If it falls into the upper left quadrant for high business value and lower cost, your project has a good chance of being approved.
The PMO’s other responsibility is IT project governance. Figure 3.5 should give you an idea of the overall process that goes from the time a project is approved until the post-implementation meeting where the project is reconciled with the original targets to ensure the project’s goals were met. So, verify your product owner has solid criteria and goals for you to work with to ensure that you can meet their expectations.
Before we get too deep into the discussion about the functions of middle level or operational management, we should make it clear that these are the people whose job will be most impacted by your project(s) in terms of daily responsibility. It is, therefore, necessary that you obtain their buy-in to successfully get the project to the finish line.
Remember that middle management’s role is not to rock the boat, but to keep it going.
Their concern is to keep issues to a minimum, look like a winning team, and do things at the right time.
Change is always difficult and needs to be properly managed. You, as the person who brings change along with your project, should know the process of how people normally experience change (Figure 3.6). You must know how to communicate with middle management and give them enough reasons to think that these changes will result in something good for them.
When people hear that change is coming, the best you can expect is that they will try to understand the consequences those changes will bring with them. Hopefully, their response will not be outright fear and resistance.
Next, depending on the quality and quantity of communication and information they receive, they will either resist, directly or indirectly, or they will embrace change if they think it will be good for their work or career. So, when communicating, keep the interests of the other party in mind to ensure that your communication produces the result you hope for and provides you the support you need from these people.
You should plan to contact, stay in touch with, and communicate with the people who will be affected by the change your project will bring, and you should communicate in such a way that they can clearly see that this is good for them.
Given the importance and changing nature of testing with Scrum, you will want to build a good relationship with the Quality Assurance team.
Depending on whether your company is already set up for common Scrum practice, mainly in terms of testing infrastructure, you may need to do more or less here. If Scrum is part of the culture, then you may only need to know the procedures and learn to follow and leverage them.
If Scrum isn’t already part of the company’s culture, you might need to explain Scrum to Quality Assurance management, especially to those who are in charge of testing, and ask for their support. You might request that they make someone available from their team to work on your project throughout the life cycle, and/ or help set up the appropriate testing environment for your project, which you will learn more about in Chapter 9, “The Importance of Automated, Regression, and Integration Tests.” This way you can be ready quickly with automated, regression, and continuous integration testing.
Like it or not, you cannot avoid Operations management. They are the people who are in control of all the pre-production and/or production activities. Make sure to pay them a visit to explain to them what you need, so that the code you deliver at the end of every single Sprint will be to the level they expect. First and foremost, remember that the development and operations departments have different, and sometimes opposite, objectives.
The objective for you, as part of the development organization, is to produce a continuous stream of well-perceived value to the business. But in so doing, you bring about change; whereas the objective of operations is to produce a continuous stream of value while making sure that everything stays stable.
By the very nature of Scrum development, there will be more software releases, often in many smaller updates, as opposed to a few larger ones, which the operations team will need to handle.
Operations will not and cannot drop their control procedures for you just because your updates are small. To do so would lead to an increase in interruptions in running business systems. The operations team simply has to remain as strict as ever before applying their pre-production verification tests. The entire change process has to remain intact, even for smaller updates.
So, unless your company is ready for some sort of self-service deployment or more precisely the automation of the self-service deployment process, try to work out some sort of schedule arrangement with operations since that will help them deal with frequent updates. In return, they will help as well as thank you for it.
In time, operations will find that it has more time to complete its other work and will be glad to support change for the development department while, at the same time, retaining all the control over their production environment.
Enterprise Architecture (EA)
If your company has a group called enterprise architecture, try to find out where they fit in or how much clout they have in the IT organization.
Take the time to understand the concerns of this group and work with them to show how your application will fit into their enterprise architecture.
Find out what they need from you but avoid being dragged to many meetings without any tangible results to show.
If the enterprise architecture team is seriously in the process of moving towards a Service-Oriented Architecture (SOA), your company’s EA overall diagram may look like that shown Figure 3.7.
In this case, make sure to explain your needs to the enterprise architecture team in a timely manner and request that they deliver or help deliver the other services, so that you can get all the pieces connected before the end of the iteration or deadline.
If, however, your company is still leveraging a more traditional architectural style, then the EA framework might look like that shown in Figure 3.8.
Every layer of the enterprise architecture framework shown in Figure 3.8 can fill a whole book by itself, but for the purpose of this book, let’s focus only on the last layer, the data architecture layer.
Whether your background is in data architecture or application architecture, there should be no doubt in your mind that data architecture is an important topic within a company. Data architecture is also an often quite messy issue that leads the enterprise data warehouse team to produce reports that cannot be counted on. There are many examples of this, but the most commonly cited one is that the values of the reports often vary from one department to another, even when it comes to the same so-called sales figures.
Based on the illustration in Figure 3.9, there should be no surprise that the reports are often conflicting and the data unreliable.
This situation often frustrates business executives, especially the CFO. As a result, IT usually tries to turn it into something more organized like the diagram in Figure 3.10, by creating a new Master Data Management layer, or MDM for short.
You need to know what your company’s enterprise data architecture currently looks like and what the future enterprise data architecture plan is.
Knowing this will help you make sure that your new application’s data architecture will be designed in such a way that it fits into or contributes to the creation of the future enterprise data architecture.
As you will see in Chapter 6, “The Influence of Architecture Vision on Team Velocity and Software Quality,” and Chapter 7, “From Architecture Vision to Release and Sprints Planning to Parallel Software Development,” the architectural approach we recommend is very much based on core business data elements, and is therefore stable. This is why it can very much help contribute to the creation of the Master Data Management (MDM) layer (Figure 3.11), a key ingredient to better enterprise data or information management.
As known in the industry, the goal of middle management is to keep going and to avoid rocking the boat, so unless you report to the CIO or CEO, make sure that you spend time with your middle manager to ensure that she fully understands Scrum and what it entails.
If your manager doesn’t understand how Scrum works and your project doesn’t go well or lags behind schedule, there is a risk that your direct management will want to revert to the old command and control style very quickly.
You must do what you can to educate your management before you start: about what Scrum is, how Scrum works during the daily execution of the project, and how it works when things go well and how it works when things do not go well.
Besides the obvious need for you to secure agreement from top business management for your project funding, it will be critical for you to gain middle management buy-in, as it is with these same people that you, as part of the Scrum team, interact with most on a day-to-day basis. It is, as the popular saying goes, where the rubber meets the road. These people will either make or break your project.
Unlike the dialogue with business management, which is based mainly on financial numbers, the relationship with middle management requires more finesse. Finances are the concern of executives in your company. Middle managers are more concerned with workload, recognition, and job safety, to name a few.
Before you start your project, and while working on your project, do not just inform middle management of the changes that will take place as you implement Scrum; try also to help them with the new workload or the new changes. This, along with an effective communication strategy, will help you obtain their support, a necessary condition for your project’s success.
For this same reason, remember to work closely with the enterprise architecture group to ensure that your new application architecture fits into the enterprise architecture group’s plan and vision, especially with regard to the data architecture, which is often in a chaotic situation in many companies and a headache for the CFO.