Agile Management

Summary
Business managers often find themselves bamboozled by technologists and their managers. After spending a lot of money on IT or Engineering, they still don’t have what they want. Here are nine ways a business manager can ask questions to improve relations with the technologists.

If you’re a business manager, you are dealing with a wide range of people and problems. Some of those people are technologists. And, no doubt, some of the problems you deal with are related to technology.

Let’s acknowledge right away that a key problem with technology is that it keeps changing. For example, just when you thought you had a grasp of what it takes to implement a computer program to support your sales staff using a centralized computer system, the systems moved out onto the desks of each of the sales people. And just when the PC-based systems seemed to be manageable, the sales people started carrying smartphones around in their pockets and asking for their information to be delivered to these devices.

Add to that the shift to “cloud computing” and “virtualization,” and you find yourself running fast just to keep up with the terminology, let alone the management issues involved in successful IT implementation.

However, if you’re an experienced manager, you know that there are certain principles of management that apply no matter what you’re dealing with. After all, people are people; organizations, even technical ones, are made up of people; and you have a strong grasp of how to listen to, influence, and manage people. But somehow, the technologists seem to be getting more difficult to manage.

Here are some principles and ideas you can use to interact more successfully with technologists – and their managers, whether they are in your organization or outside of it.

1. Have confidence that you are capable of understanding what’s happening in technology. While there are shifts going on that are causing a lot of turmoil in the IT and Engineering worlds, none of the underlying technologies are so sophisticated that you can’t grasp their significance. After all, you have dealt with much complexity simply by being a business manager. People are much more complicated than machines.

2. When a technologist or a technical manager communicates with you, it’s OK to insist that things be explained in terms you can understand. If the person explaining things to you refers to acronyms and terminology you haven’t heard before, ask her to explain what they stand for and what they mean. It does not diminish you to admit that you’re not a specialist in the technology area being described. Keep asking questions until you get an explanation that clarifies things to your satisfaction.

3. Ask questions that clarify the significance of the technology. A technology is significant if it (a) displaces some other technology, (b) makes some existing activity or product a lot cheaper, (c) enables information-gathering or analysis that was previously impossible or too expensive, (d) creates a tool that will vastly improve a person’s efficiency at doing something, or (e) creates a material or process that will lead to a wide range of new products or services. The technologist should be able to explain to you which of these is about to happen, and how it could impinge on the business activities that your organization is engaged in.

4. Ask whether there are competing technologies that could displace the described technology or make it irrelevant.

5. If someone is suggesting that you make a large investment in a new technology, ask whether there are lower-cost alternatives that will suffice for an interim period. Evaluate the risk of being left behind relative to your competitors. Also consider whether you may have more options in the future if you wait before committing to this investment.

6. Expect software development to have a highly variable cost or time to complete, because it is hard for technologists to predict what it will take to develop a piece of software. Software development is not yet a stable engineering discipline the way, for example, building construction is. Every major software development project includes a significant amount of experimentation, because there is not a “reference manual” that tells software people how to make each component. In addition, when you put together a bunch of software pieces, it requires a lot of testing to make sure there are no major malfunctions in it. And even with a lot of testing, there are no guarantees, because there are just too many possibilities to test them all.

7. Get in the habit of asking technology managers to commit to showing you a working prototype of anything you’re asking them to build. Particularly with software, it is normal for your idea to evolve after you see a working model. So it’s best to ask to see the working model often, having the implementation done in small stages. If it’s not going the way you want after, say, 8 demonstrations or 6 months, you can call the whole thing off, or start over in a different direction.

8. Don’t ask Engineering or IT to work overtime for extended periods. You wouldn’t do that with Accounting or Legal without expecting a lot more errors to result. The same is true for development work. And the result of development errors can be disastrous when the product or service you’re developing is delivered to external or internal customers.

9. Develop trust between yourself and your IT or Engineering managers by learning about their challenges and opportunities, and by teaching them about yours. The more you can understand each other, the better your cooperation will be. Invite one of their staff people to sit in on your staff meetings or be resident in your area. Send one of your own staff people to become familiar with their activities. The less mystery there is about their decisions, the more trust there will be.

If you’re not getting what you want from IT or Engineering, consider the possibility that at least half of the problem is on your side. You can take action to develop a good working relationship with the technologists. And while you’re at it, you’ll probably find that they actually want to understand what you’re dealing with as well.

John Levy helps business managers who are frustrated by the lack of results they are getting from IT or Engineering. He specializes in rapidly getting high-tech teams to align with business strategy and to contribute to business success of the enterprise.

John has been consulting for managers in industry for over 20 years. John’s book on management for technology executives, was published in May 2010.

For more information, please visit his website – johnlevyconsulting.com
Email him at: info@johnlevyconsulting.com , or call 415 663-1818

Today’s my birthday, but instead of staying home and celebrating, I’m on a plane destined for a city a couple of thousand miles away from home. The combination of the birthday milestone and the time away from phones and email allow me some reflection on what I’m doing and why. And one of the things I’m doing is advocating adoption of Agile development methods and Lean management principles.

There is a lot of pushback on these principles from consultants and managers who have not lived with them in real projects. And a certain amount of skepticism from business managers who don’t want to embrace a new “method of the decade” fad just because it is becoming more widespread. I don’t blame them. There are some good reasons for skepticism.

First of all, any movement that has passionate followers and promoters tends to acquire a fringe element that pushes everyone to follow the trend, to get on board. And we all know that not 100% of projects, environments or companies a suitable candidates for an Agile conversion. Why? Sometimes they have extensive requirements-definition phases imposed on them from a contractor (such as the Federal government or the military). Sometimes they simply do not have the support of top management to revamp their operations in a way that requires changes in management style or procedures.

Second, some operations have far-flung operations including offshore units, making effective implementation of Agile methods much more difficult. Rather than going through the motions of Agile or Scrum teams with vast timezone differences and incompatible local management style, they are better off using traditional project management tools and methods.

Finally, it is threatening for some technical managers, project managers, or business managers to have to change their management activities and open them up for inspection by self-directed development teams. For example, one IT Director I worked with at a client company was known by his colleagues as “The Hammer” because of his management style. He was not a candidate for participatory decision-making in a team.

And yet, Agile and Lean transformations are worthwhile endeavors. How do I know? I’ve seen development teams move from ordinary results into higher productivity; business managers move from fear of the new into embracing Agile because of the greater confidence they had in getting results on a predictable schedule; and companies move from asking what the heck is Agile to committing tens of millions in development money to Agile projects.

I also recommend Agile transformations because of my own frustration with the failure of software development on the whole to improve significantly over the past 30 years. Sometimes, you have to make your own predictions about what is going to work, what is going to make things change for the better. I predict that ten years from now, we won’t be discussing whether to go Agile or Lean, because everyone will be practicing them to some extent, and no one will have any doubts about the payoff.

_______________________________________________________________________

John Levy helps business managers who are frustrated by the lack of results they are getting from IT or Engineering. He specializes in rapidly getting high-tech teams to align with business strategy and to contribute to business success of the enterprise.

John has been consulting for managers in industry for over 20 years. John’s book on management for technology executives, Get Out of the Way, was published in May 2010.

For more information, please visit his website at https://johnlevyconsulting.com ,

Email him at info@johnlevyconsulting.com, or call 415 663-1818.

There’s a lot of talk these days about Agile methods. They may be called Scrum or XP or a number of other names. And a lot of companies and institutions are trying to make a transition to Agile methods. You may be wondering what the big fuss is over Agile Software Development, which is where the Agile movement began. Let’s review a couple of key things about Agile:

1. It’s not a new technology that came down from an academic institution or from a commercial enterprise. Agile is a set of principles and practices that were codified in 2001 by a group of practicing software professionals with a lot of experience making software products. This alone makes Agile unique, because it is what I call a “grass-roots” movement, coming from the people to whom the methods apply.

I like to say that they got together and said to themselves, “we’ve been so badly managed for so long, surely we can do better ourselves.” Of course they didn’t say that, but I believe they were motivated by the desire to have more productive and happier development teams. And from the business point of view, we can’t deny that software development has a poor track record – most large-scale projects do not deliver working software within the time, budget or quality constraints that were set out at the beginning.

2. To do Agile properly, the development team has to include someone who is in the role of customer or user. By “include,” I mean that a person in that role must be accessible to the software developers all the time – or at least every day for most of the day. The reason for this is to be able to have conversations about what is meant by certain requirements or functions or uses of the software. And conversations are key to the whole process, because we have learned over the years that written specifications and requirements never (NEVER) fully explain the actual requirement for the product. Why? Because often the customer herself doesn’t know what is needed until a working prototype is demonstrated.

3. Working prototypes are also key to the Agile processes. If the team cannot demonstrate a working prototype of the software at least every 3 weeks, then it is not doing Agile. And when the prototype is shown (to the customer on the team), the customer gets to say whether it meets the “story” or specification that was given to the team a few weeks ago. The customer also gets to participate in setting the priorities for the next 3-week development session.

What does Agile development mean for a business person who is contracting for or paying for software development? It means all of the following:

a. You are responsible for designating an authoritative & knowledgeable “customer” to the development team, and making that person responsive to the team on a daily basis. You also have to be willing to accept that person’s decisions on what goes into the product and what is left out.

b. You may set the budget and the time line (deadline for delivery) for the product, and you can make a list of the features or functions you want, in priority order, but you must not insist that all features on your list be included for any one deadline (at the price). Or you can set the features required and the budget, but then you can’t set a deadline for their completion. Why? Because making software – real working software – requires experimentation and trial and error. And that makes the job of predicting the complexity of a particular feature very uncertain. So as the process goes along, you can’t tell how long it will take to make any one feature. In compensation, you get to re-prioritize the features to be built next every 3 weeks or so.

c. Your project managers will probably have to learn that their roles will change with Agile development. They must accept the two new views (a and b) and learn to monitor the development progress without having the control they are used to with traditional project management. Why? Because software development is not like constructing a car or a building. The steps are known, but the “trial and error” part is still needed to find a satisfactory solution to the complex problems posed by software.

I recommend that you accept this, and learn to live with Agile processes. Because the satisfaction that comes from having real working software demonstrated to you every few weeks, along with the higher success rate for overall projects will amply compensate you for learning this new method of working with developers.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

John Levy helps business managers who are frustrated by the lack of results they are getting from IT or Engineering. He specializes in rapidly getting high-tech teams to align with business strategy and to contribute to business success of the enterprise.

John has been consulting for managers in industry for over 20 years. John’s book on management for technology executives, Get Out of the Way, was published in May 2010.

For more information, please visit his website at https://johnlevyconsulting.com ,

Email him at info@johnlevyconsulting.com , or call 415 663-1818.