Waverley Blog

Remember “Management By Wandering Around,” the somewhat old-fashioned notion that no amount of presentations, reports, meetings and conferences can substitute for getting out of your office and walking around (see Tom Peters’ great book: Little Big Things: Excellence).  Great idea, but many experts say it’s impractical when your employees are spread all over the world.  These days teleconferencing, phone conferencing, email, texting and IM substitute for face-to-face discussions.  Unfortunately, good as is, electronic connections cannot replace genuine human relationships.   And business teams who have healthy relationships are more productive.

Managing Waverley software development teams located worldwide, I’ve learned the importance of MBFA – Management By Flying Around.  Software development is complicated, difficult work.  Often there are unexpected problems and setbacks, so openness, honesty and trust among team members is critical to our success. There’s an old adage that says that the three most important keys to retail success are location, location, location.   Well, at Waverley we believe the three keys to outsourcing success are communication, communication, and communication.

I believe that if engineers and customers haven’t been face-to-face in the past six months, our relationship is probably set back to zero.  My visits (alone, with our Silicon Valley Management team, and with our clients) to our software engineers in their home offices creates goodwill. Flying our engineers to our clients builds relationships. Everyone knows that hiding problems creates problems.  As we all listen to each other, air our concerns, share our solutions we create an atmosphere of transparency and accountability.  And, we create better solutions for our clients.

I recently attended a Certified Scrum Master training course and came away from the experience convinced it was worth the time and cost.  I have, of course, been exposed to Agile development over the years, but more from an informal, incidental perspective and from reading books on the subject.  The major concepts of short iterations, fully functional results, and the opportunity to rearrange priorities during project development I knew and understood well.  However, seeing the entire framework described – and used – during the course of the training really tied the entire concept together for me.  I have not only a fuller, more complete picture of what Scrum is and why it works, but also hands-on experience garnered in the rich, guided environment of experienced teachers and other motivated and smart colleagues.

The questions asked by others taking the course really increased the value of the training; their own concerns and past experiences brought out answers and advice that will probably come in very handy in the future but that I would not have thought (or known) to consider myself. Of course our training “exercises” were not nearly the same intensity or complexity as a real-world project, but they provided an excellent combination of getting to “try out” Scrum while having coaches readily available to answer questions and provide guidance.  I am much better prepared to initiate using Scrum with a team after this course than I would be after reading 10 books.

As Waverley’s newest CSM, I recommend that if your company is considering implementing Scrum, formal training is an investment that’s well worth it.

When you are an organization providing services to clients it is important to check in every once in a while to make sure the relationship between the two companies is still as mutually beneficial as possible.

At the beginning of an engagement both parties typically complete at least some amount of due diligence and agree that the business goals are good for both sides. If through the course of time, high-level strategic communication doesn’t take place, then that due diligence becomes stale and potentially worthless. And you may not find that significant disconnects exist until major damage is already done to the relationship through project failure, or even a complete dissolution of the engagement. These risks can be mitigated by having what I’ll call a Customer Review (similar to what’s known as a QBR) on a regular basis, about 3-4 times a year.

Some customers won’t want to spend the time. The Customer Review process is external to what they’re paying you to do and they can sometimes have a hard time seeing the benefit, but it is crucial for the long term success of the relationship. It’s key that you help them understand that finding strategic misalignment early will save them money over the long run and help verify that you are providing the best service you can to your customer.

The Customer Review should be a face-to-face meeting in a conference room with the management of both companies in attendance. Any sponsor executives as well as direct managers of the project should participate and attend from the client’s side. Following are some of the things that should be covered in the meeting as well as items important to you and/or each of your customers.

Presented by you:

• History of the relationship, accomplishments since last Customer Review
• Your company health, growth of the company, new areas of expertise, etc

Presented by the customer:

• Past project success in the marketplace, lessons learned, health of current project, etc
• Future roadmap, business strategy, product plans

Group input during meeting:

• Issues and difficulties currently hindering productivity
• Action items for next Customer Review

If you meet in this brief, semi-formal way with your customers on a regular basis, you will find you understand them better and can anticipate their needs more proactively, which enables you to provide the highest quality of service.

We’ve looked at a variety of software development processes over the years we’ve been creating custom software, including Waterfall, spiral processes (eg, RUP) and of course Agile. I find Agile particularly interesting because it is so heavily focused on value. Here’s how it works. Imagine a factory producing a widget. It’s well understood that as the factory manager, you’d like to keep you inventory down and deliver raw materials just in time. Agile functions in a similar manner in the software world. By promising to deliver frequently, involving stakeholder feedback and constantly reducing risk, it is much easier to use Agile to guide you to delivering something of the highest value as quickly as possible. In effect you are reducing your inventory by keeping your feature list very focused and not implementing things that you really don’t need. This is how the focus on value works.

Looking back to our post on the 4 dials exercise, Agile really is saying that you don’t have much flexibility with the date due to both cost and competitive factors. The date is a major factor in determining cost. If you’re spending dollars on a big team, then every day is expensive.  By fixing the date and delivering as much quality code as possible by that date, you force yourself to prioritize your huge list of features that you think you really must have but probably do not really need. And that is a good thing.

Recently the CEO of a new client called me to ask why his project with us was at day 85. This was a reasonable question since it had been originally scheduled for 24 person-days!

This client had interviewed us last summer for a position to help them develop some software they viewed as critical to their business strategy. They were very picky about whom to choose and interviewed at least 20 companies. We were honored that we got the nod.

Part of the selection process was to estimate a small project. Our team looked at a simple description, some specs, asked some questions and came back with a 24 person-day estimate. Everyone agreed that this was reasonable.

We started with a single resource, an expert lead developer who specializes in the area our partner was interested in and off he went. So far the project was pretty straightforward.

Day 85

Now we are at day 85. What happened? It’s a common tale, but a cautionary one.

First of all, the client admitted that they changed many requirements (some multiple times), including some API’s  that had to be redone and significant changes to the UI requirements.

On our end, we all knew that the development schedule had run over and that the team had not addressed the delay directly since the relationship with the client was going well.

The client also specifically stated that we had been doing a great job. They were very happy with the quality of the work and the commitment of the developer and client manager. Still, we were at day 85. Not good.

What lesson should we learn?

Is the lesson here that clients shouldn’t change their requirements? This is unlikely, given the dynamic nature of business applications. Or perhaps it is that developers should sound the alarm each time a small delay occurs, even when the client causes the delay and approves the changes? That doesn’t seem very practical either.

Here’s what I took away from the experience. It’s important to have a healthy discussion at the beginning of the project about how the project team should respond to changing requirements. Because with business applications, everyone should assume that requirements will change. It is only be seeing early versions of an application that customers can evolve their understanding of the is really required.

Assume that requirements will change. Make plans about responding to those changes. These steps will go a long way to keeping the balance between the three dimensions of projects: schedule, cost and quality.

I had a regular “client update” call from a customer last week. The project for this customer is nearing completion and so we are starting to think about the transition from development to support. In this case, the concern was whether one person could properly support the work that four developers had been doing on four mobile platforms. Among the questions they asked me was what happens when we go from a team of development resources to a support staff of one?

This is a time when clients are anxious because they want to minimize the costs of managing the risk of potential problems with the application.

Here are the questions we typically hear from clients about the transition and what we advise them.

What should support include?

The main activities that support should cover are minor changes to the custom software application and changes that are caused by updates to the operating system.

What is the payment structure for support services?

Keep the pricing model for support as simple as possible. Our clients prefer a per-hour fee structure because they only have to pay for the support they need.

Which person gets assigned to maintenance and support?

Generally, the best person is one of the members of the development team. Preferably it will be the developer who has the broadest view of the work that was done or who is most knowledgeable about the areas that will need the most support.

But then what happens if we need support in an area outside this person’s experience or expertise?

If you hire the developer to provide support, they will be familiar with the server interfaces and with the software operating environment. They have the process in place to develop and build the code and run it through tests with each change. They can also draw on their team’s capabilities when necessary to answer internal questions about how something works or what to do.

What happens if at some point in the future we need more support than this, or even additional development?

If you need it you can always ask your developer to ramp back up to a multi-person team to provide more depth.

The important point is that your developer show flexibility by meeting all your support needs and by charging you only for the time they work for you.

Effective software development teams have defined communication paths that help guide how projects are run. One important path governs what to do when a customer finds a defect in the software. The bug gets reported, logged, prioritized. The priority of the bug determines when it will be evaluated and fixed.

But what if the rules don’t work? What if a low-priority bug is happening to a high priority person – for example, an executive under pressure to deliver who may unreasonably question the project design and has the political means to damage the overall project? Suddenly it’s time to escalate and go outside the normal rules.

This is exactly the situation that arose this week. I’ll tell you how we handled it, but first some background.

A pilot program under threat

One of our development teams is piloting a recently completed large application. The pilot is going well, at least it was until I got a call from the Program Manager for the client. This Program Manager is as steady as a rock, so if he calls and says he’s concerned, I sit up and pay attention. On this call he’s concerned, and I’m paying attention.

The issue was that two of the pilot users were having a problem with the application and were making their frustration known to a lot of people, including the CIO. Although the problem had been logged with the development team, it did not get a high priority based on its description. The development team was focused on completing an iteration and so this problem was on the list of bugs and would be considered when prioritizing the backlog for a future iteration. Standard development methodology here.

The symptom that the two users were experiencing was this: a request to the application that should normally take less than two seconds was taking 45 seconds. As you can imagine, they found this troublesome.

Redirecting the team

After I got off the phone with the Program Manager, I immediately contacted the manager of the development team in Romania and explained the situation. We agreed that we needed to immediately focus the development team and the QA team on fixing this bug.

Of course, when the developers tried to replicate the problem at their lab, they couldn’t. The application performed perfectly.

It wasn’t until they could actually gain remote access to the user’s computer that they could see the problem. What did it turn out to be? The local database for the application wasn’t indexing properly and so some queries to the database were taking much longer than they should. The developers were able to quickly fix the problem by running a simple script once they identified its source. The script was included in a future patch to be sure this problem would not resurface and we reviewed our release procedures and patch creation process to look for anything we could improve in a future release. Finally, we checked back with the two pilot users to make sure they were satisfied with the software.

What’s the takeaway?

Once the developers fixed the problem and restored the user’s application to its normal state, their job was done. As for me, I still had plenty of work to do to reassure the Program Manager, our Sponsor, and the CIO that the problem was an isolated one, that it was a simple problem and that it did not reflect any fundamental underlying issues with the application.

What does this experience tell me? I don’t think it’s that we should change our procedure for fixing bugs. My takeaway is that even if a development team has a good set of procedures and communication policy in place, some situations will arise that require escalation. In these cases, the Client Manager has to change the team’s priorities and put all its energy into fixing the immediate problem. It also points out the importance of an effective escalation path so that the client always has someone to go to when the conditions are extraordinary.

In the scheme of the whole project, this kind of escalation is unproductive. The problem the two pilot users were experiencing would have been resolved in due course. Escalating an entire QA team for 36 hours prevented other issues from being worked on, so there was likely a small schedule hit as a result of the team being quickly redirected, then redirected again when the bug is resolved. But sometimes, despite the productivity hit, it’s necessary to parachute in the swat team so that the client can manage internal expectations and politics. We understand this is the reality for our client, and we work to support them as best we can. But for everyone’s sanity and for the continuity of the project, we try to keep these fire drills to a minimum.

Picture these situations:

Three engineers from different groups talking at lunch about a difficult bug that one of them had spend most of the night fixing. Nothing wrong with that, right? Just some colleagues talking informally about their work.

The Product Manager meets with the User Interface Design Group to decide about priorities for the next release. Once again, perfectly appropriate. Part of the job of the Product Manager is to establish release priorities. Meeting with each engineering group is one of the ways this gets done.

A Sales Account Manager asks an Engineer to make a change in the next release that a customer has asked for. Oops. We just crossed a line here. We would expect the Account Manager to advocate on behalf of a customer, but going straight to the Engineer is the wrong way to do it.

The Client Project Manager calls an Engineer at a vendor firm to ask how a particular feature in the application works. The line just got crossed again. The Project Manager for the client should have a primary person, probably a Client Manager, who can field these calls for the client. It’s not that the client can’t get these questions answered, it’s just that they should be answered in the most productive way possible.

These examples point clearly to the need for defining communication paths for project teams. But how can you define them in a way that encourages helpful informal communication and that also ensures necessary formal communication?

At one extreme you could view a project team as a network with potential connections from each member of the team to every other member of the team. But if everyone talked to everyone else, life would be chaotic and the team would never reach its goals.

At the other end of the spectrum you could have tightly controlled communication that defines exactly who can speak to whom. This approach allows for no flexibility in the system and is overly restrictive.

Finding the middle

The answer of course lies somewhere in the middle. What is that middle?

Before I answer the question, let’s look at the difference between formal and informal communication. At Waverley we think of formal communication as any communication that causes a person to change work priorities, goals, or that affects productivity. Everything else is informal.

So according to this definition, formal communication includes obvious events like team meetings, client email, design reviews. It also includes any nonessential and lengthy calls to engineers by the client.

The way to find the middle is to define communication paths – not to the degree that they limit informal communication – but so that formal communication can proceed in a predictable and productive way.

The communication paths in distributed teams are controllable, even across remote locations, if everyone on the team understands and plays by the basic rules.

Early definition of communication paths will help avoid problems. As the project evolves, communication paths can evolve with them.

So how does a team go about defining communication paths? It starts by defining roles, then by looking at groups of roles, and finally at paths between groups.

That’s what I’ll be examining in my next two posts.

We’ve written  about the disadvantage of fixed-price contracts for agile programming projects before – why fixed-price makes sense for business process outsourcing with its predictable outcomes, but not so much for agile development.

Our main argument was that avoiding fixed-price gives you more flexibility to define your business requirements. You don’t have to know all your requirements at the beginning of an agile project.

Artem Marchenko recently expanded on this argument with two additional sources of flexibility. One is technical obstacles that may be impossible to predict at the outset of the project.

And the second is changing market conditions. The source of this change could be at the micro level (e.g. a competitor enters the market) or a changing macro-economy.

As Artem puts it, “Agile methods acknowledge the market and project uncertainties and try to adapt by building software in small and completely done increments.”

He also points to some additional articles on the subject of agile development and fixed-bid contracts, both pro and con.

How does a company manage financial risk if the project cost isn’t fixed? A company can always set an internal cost goal and end iterations when it’s reached – that would help them manage their content iteration by iteration. The beauty of agile is that there’s something ready to go out after every iteration.

The four constraints of project management

Every project has four dimensions to manage: scope, cost, schedule and quality.

• Scope: For software projects, scope is the project requirements list. Typically, this includes performance requirements and a set of features. To increase the scope, add features or make existing features on the list; to decrease the scope, remove or simplify features or reduce performance requirements.
• Cost: For software projects, cost is primarily contained in resources needed for the project.
• Schedule: The schedule for software projects is typically prioritized using the desired release date. If interim dates (alpha, beta, feature freeze, code freeze, etc.) are determining factors, these dates may be prioritized separately.
• Quality: Many models prioritize based on the previous three dimensions only. Unfortunately, what usually drops is the quality of the product or at least the testing time. It is important to realize that the quality of a software product is directly influenced by the other project dimensions. Occasionally the product quality is of lesser importance than other dimensions – for example to meet the deadline for a demonstration or marketing event.

Not only do you have to establish the goals within each of these categories, you have to prioritize the four dimensions. These priorities establish the constraints on the project.

Setting priorities

Working on a big software project involves managing risk, handling unexpected tasks and absorbing competing priorities from external influences. These influences include investors, management, and customers.

Successfully navigating such a complex task requires that you understand and steadfastly follow your most important priorities. Even more important, your team needs to be as resolute about these priorities as you are.

Here’s what often happens. The project sponsor makes the priorities clear at the onset of the project. It might be schedule and cost, or quality and scope, or some other pair of project dimensions.

The members of the team nod in agreement about these priorities and the project begins. Then, at some point, it becomes clear that different members of the team have a different understanding of the priorities. Although there was a lot of head-nodding at the beginning, the team hadn’t fully internalized the constraints on the project.

How can the project sponsor and project manager help the team to follow critical project priorities?

The Four Dials Exercise

Here’s an exercise that we use at Waverley to make sure the entire team understands and stays focused on the top priorities that will determine the project’s success.

In a team meeting, explain the four project dimensions to participants and discuss the purpose of setting the guiding criteria for the project. Then ask each team member to vote on the two dimensions that he or she believes are most important.

Record the votes for each person’s top two dimensions and tally the votes. For the exercise, treat every vote equally.

As a sponsor or program manager, you probably have already decided the outcome you or your management feel is necessary to guide the project. If your expectations disagree with the voting results, discuss these differences. This discussion provides an opportunity for the project sponsor or the project manager to walk through the reasoning that was used to set the priorities. It also is an opportunity for team members who understood the priorities differently to voice their views and for the group to reconcile these views.

Because the project hasn’t started yet, it’s safe for people to have different views and for these views to be discussed. The goal is to make clear to everyone what dimensions are most important to the project sponsor, for alternative views to get an airing, and to reconcile differences.

All other decisions made during the course of the project relate back to the constraints that are established at the beginning of the project. The Four Dials Exercise increases the probability that the entire team will internalize the priorities and make decisions that support them.

Fighting overconfidence

Why does this exercise work? Chip and Dan Heath, in their book  Made To Stick, explain that one of the ways to make an idea stick in a person’s mind is to introduce an idea that is unexpected, if the answer surprises us. One of the best ways to create surprise is with a mystery, a gap between what we know and what we don’t know. People generally want to solve a mystery and so it’s easier to keep their attention.

But often people are overconfident about how much they know. If, at the beginning of the project we told the team to remember the top priorities of the project and then reminded them of the priorities, the tendency would be for team members to be overconfident, to say to themselves “I already know this”, and to tune out.

By taking a vote at the beginning of the meeting, we are asking everyone to commit to their answer. The Heaths explain that this simple act of committing causes everyone to be “more engaged and more curious about the outcome.”