If you’ve been following the Get Out of the Way! blog for a while, you know that I talk about a lot of things besides product development. My new focus is on delivering successful IT projects for business. With the new focus is a new website, which I hope you’ll visit at http://johnlevyconsulting.com.
In addition, the blog is changing. It is called Agile Management now, and you can find it at http://johnlevyconsulting.com/blog/. I hope you’ll join me in the journey. Your comments are welcome.
I grew up in a family of engineers. My father studied electrical engineering in college, but never practiced it because he graduated from college during the Great Depression. Two of my uncles are engineers, and my older brother preceded me in going to Cornell as an engineering student.
I have always felt that engineering is not only an honorable profession, it also leads to a practical lifestyle that values inquiry, problem-solving and efficient solutions to the challenges in life. So you may not be surprised to learn that I am a fully qualified lifelong nerd. I love examining things to discover how they work. And the more complex the mechanisms, the more interesting they are.
This is where it gets to be a problem. When I invent something new, like a part of a computer, I revel in the complexity of the thing I’m building. As long as the complexity serves a purpose, such as actually making the thing do what it’s supposed to do, my brain is tweaked in pleasurable ways when I contemplate the complexity.
If you’ve been reading any of the recent pieces about Steve Jobs, you’ll have understood that part of his brilliance was being able to conceive of simple and easy-to-use products that “just work.” I worked with Steve in the early days of Apple, and I can verify that it was a challenge being an engineer in a place where the visionary boss kept revising the product based on his latest concept of simple. Yet even engineers have a principle they repeat to each other to counterbalance their tendency towards complexity – the KISS principle: “Keep it simple, stupid”.
A quote attributed to Einstein says “Make it as simple as possible, but no simpler.” This teaching admonishes us to simplify our theories, but not so far that they no longer apply to the real world. Jobs’ vision was to make products that contained complex technology but worked well and intuitively for the common person. And from that basis, he led the creation of products that have changed the way the world works.
So does this mean that I’m giving up on complex ideas and mechanisms? Not at all. The mental contortions I need to undertake to understand complicated things still give me pleasure. And I believe they keep my mind alive in important ways. The key to living with such an engineering mind is to keep it from running my life. I still listen to J.S. Bach’s music with satisfaction at the complexity of the counterpoint and harmonies. But I also meditate on emptiness to keep the logical brain in check.
The next time you hold a complicated piece of consumer electronics in your hand – such as your mobile phone – take a moment to reflect on its complexity and its simplicity. Encapsulating one of these in the other is an art. And to accomplish that encapsulation, you need both engineers and artists. Long may the engineers and artists work together.
John Levy works with Finance and Operations executives who are sponsors for new IT-based business capabilities. He helps them to succeed with their projects and to transform their relationship with IT.
Getting business value from every dollar spent in IT is not easy. You need a guide who is knowledgeable about technology and also speaks the language of business. John specializes in rapidly getting IT to align with business strategy and to contribute efficiently to the success of the enterprise.
John has been consulting in industry for over 20 years. His book on management for technology executives, Get Out of the Way, was published in May 2010. http://bit.ly/9pX1wS
For more information, please visit http://johnlevyconsulting.com , email him at info@johnlevyconsulting.com , or call 415 663-1818.
Because of Hewlett-Packard’s recent announcement suggesting that they will abandon the PC business, I think you might enjoy reading this piece I wrote – 12 years ago, in 1999 – about the impending demise of the PC business as a high-growth market.
The era of the Personal Computer is over.
Not because PCs are about to disappear, but because PC software and hardware will not define the direction of high-growth technology markets in the 21st century.
For those who remember the 1970s and 1980s, the arrival of PCs in 1979-1981 pushed aside the Minicomputer as the defining force for high-growth markets from then on. The minicomputer market did not disappear. It simply became a stable, 15%-per-year growth industry. As a result, the most creative programmers, engineers and business school graduates started going into PC-related businesses.
What has pushed aside the PC? The answer is the World Wide Web – sometimes known as the Internet. But this is a flawed answer if you conceive of the Web as something accessed through a PC.
There are two reasons PCs are already obsolete as Web-access devices.
One reason is that only half of U.S. homes have a PC. And the people who do have home PCs are not satisfied with the type of service they receive or the kind of interaction they must do to successfully access and navigate the Web.
Windows unreliability: Microsoft’s flagship operating system has extremely wide acceptance, but everyone expects to have to re-boot their system at least once per day if they are using Windows on their PCs. [ref: Walter Mossberg, Wall Street Journal, 1999]
Complexity of Windows and Macintosh OS: A general-purpose operating system, such as Windows or MacOS, is designed to allow the computer user to run any application program on the computer. This general-purpose design requires the OS to be complex, have many settings and controls, and the allow for recovery from a wide variety of errors that may occur both in the applications programs and in the OS itself. The average person does not need or want this generality.
An OS is inherently unstable: In the academic halls of Computer Science, I used to joke that Operating Systems “consist of those functions that we don’t understand well enough to commit to hardware.” In other words, we may need to change the functions and interfaces as we learn more about the application software environments, the file and database systems, the communications channels, and so on. If we really understood the requirements well, we would have put the programs in a ROM, rather than loading them at “boot” time.
The second reason is that miniaturization of electronics – and the continued increase in compute power per chip – have enabled portable, personal devices, such as the cellular telephone and the personal digital assistant typified by the 3Com Palm III and successor devices.
Both of these devices have wide acceptance among people who are not regular PC users. Why? Because they do one thing well (telephone), or do a small number of things well (Palm III). The computer industry calls these devices dedicated application computers. The software is loaded in once and runs many, many times without being modified. The person using them does not see a desktop and “launch” an application program. A single button causes a function to work. And it works well.
You didn’t know your cell phone was a computer? But it is! And so is your thermostat, your pool control, your home security system, your automobile engine carburetor controller, and so on.
Who are the people who will use the Web but not PCs? Here are a few clues:
• They watch movies at home and in theaters.
• They talk on the telephone.
• They buy things in stores, and also from catalogs.
• They buy music recordings and listen to them at home, in their cars and while walking or running.
• They read magazines and newspapers and watch broadcast television.
• They participate in community activities, attend meetings, go to schools and churches, and raise children.
• They are interested in who their neighbors are and what stores are in their neighborhoods.
• The do not program their VCRs.
In other words, they are people like you and me, living their lives in North America at the beginning of the 21st century.
draft 11/29/99 John V. Levy, Ph.D Copyright (c) 1999
415 663-1818 john@johnlevyconsulting.com http://johnlevyconsulting.com
I spent many years managing engineering projects. It was satisfying work, because the people doing it are very dedicated, they have a culture of finding the best solution, and they get satisfaction from seeing their creations go into the world and be useful (and profitable).
When I began to consult for managers who were counting on IT to provide functions and capabilities to enhance the business, I was shocked to find that IT was regarded as an alien land (full of technologists who speak a different language), and as an untrustworthy department (because of many late or failed projects).
I began to visualize development of IT-based capabilities as being a water pipe, with a Niagara Falls of effort on the input side (IT doing development), and just a trickle of useful results coming out on the business side. So I set out to discover what was blocking the pipe – or diverting the flow to somewhere else.
While consulting for an insurance company client, found some answers. Here are some ways the flow of IT is diverted or blocked, and some ways of correcting them:
1. Emergencies pre-empt everything. The same people are responsible for creating new capabilities and for dealing with crises. So whenever there is a crisis, all work on the new capabilities stops.
Key projects must have committed resources. While it’s good to make IT developers responsible for problems in their programs, it is crazy to pull the best people off of all projects to address urgent problems. Instead, there should be a stable of top trouble-shooters available on short notice. These people should not be committed to development projects.
2. The project is delivered, but it’s the wrong thing. When Business and IT don’t speak the same language and don’t plan strategy together, projects can be chartered and completed without knowing what is actually needed for the business. The result is often a functioning program that doesn’t do what the business needs.
Business and IT must collaborate in strategy and planning. While they are planning, it helps to have someone who speaks both languages present. Business and IT also benefit from learning about the other side’s interests and measures of success.
3. Both IT and Operations collude to treat IT development as if it were the same as call-center operations, for example. But software development is Engineering, not Operations. So the best software designers leave the organization, and IT projects are implemented by second-tier people who are neither as efficient or as capable as the top-level people.
Software engineering should be recognized as professional work needing the best people you can hire. Then the physical and management environment needs to be maintained for this professional work. If you can’t provide such an environment in IT, then the work should be outsourced. It’s better, however, to have it close to the home office.
With the rapid evolution of IT, it’s easy to get caught up in the rush of new technologies and not pay attention to the core management issues that are wasting a lot of IT effort. But by correctly managing IT projects and the business-IT interface, you can have more resources available to pursue the latest needs.
If you find these ideas useful, you may be interested to read an article I’ve written, titled, Nine Mistakes That Get in the Way of IT-based Business Excellence. To receive a complimentary copy and to sign up for a twice-monthly e-zine on this topic, please go to http://www.johnlevyconsulting.com/signup.php
John Levy works with Finance and Operations executives who are sponsors for new IT-based business capabilities. He helps them to succeed with their projects and to transform their relationship with IT.
Getting business value from every dollar spent in IT is not easy. You need a guide who is knowledgeable about technology and also speaks the language of business. John specializes in rapidly getting IT to align with business strategy and to contribute efficiently to the success of the enterprise.
John has been consulting in industry for over 20 years. His book on management for technology executives, Get Out of the Way, was published in May 2010. http://bit.ly/9pX1wS
For more information, please visit http://johnlevyconsulting.com ,
email him at info@johnlevyconsulting.com , or call 415 663-1818.
I’ve spent many years managing development projects in high-tech industries. My experience teaches me that people doing development are extremely aware that their time and effort is frequently wasted, for a lot of different reasons. The key point for you as a business leader is that wasted effort is the same as wasted dollars.
It’s actually worse than that. Because you depend on deploying new systems, software or business processes on schedule, any delay – or a complete failure to deliver the result – costs you further in savings you expected to have after the system, the product or the service begins. And if it’s a product from your company, you also lose market share to competitors and therefore never realize the life-of-product revenue you were expecting.
One of the key indicators of waste is finding that your managers decide to kill projects because they are not progressing fast enough, or because they are not meeting functional or performance targets. Or they are choosing to live with deficient systems or products because there are not alternatives.
Here are a couple of causes of slow or deficient development projects:
The first cause may happen due to insufficient information being available to your business managers, so they can’t make informed decisions about either the requirements or the development process itself. The second cause is very common in large organizations or large projects, because they are modeled on construction projects, which are very different from IT or product development in high-tech fields.
To counteract these causes, you may have to change the culture of project definition in your organization. Your business managers need to commit to involvement in the development process. And your project managers need to investigate modern methods of doing development, particularly the “agile” or iterative development methodologies. The main point is to define incremental development milestones that can be visibly demonstrated on a time scale that is short (less than a month, typically), and coupled with immediate feedback and counsel from business managers who are responsible for delivering results.
If you don’t have such processes working in your organization now, it’s time to get going on them. Before you see another big project cancelled for lack of progress.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
John Levy helps executives get business value from every dollar they spend on development. He specializes in rapidly getting development teams in IT and Engineering 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. http://bit.ly/9pX1wS
For more information, please visit his website at http://johnlevyconsulting.com
When you’re responsible for a project, one of the first things you’re supposed to do is determine the requirements for the project. In other words, what exactly do the people who asked for it want? This is much more complicated than it sounds, and much has been written about eliciting requirements and getting them written down in a coherent manner.
In many years of managing projects and teams of developers, I have learned to ask some questions that you might not think of while you’re gathering requirements. You may consider these questions as “tricks of the trade” that could help you keep out of trouble.
Here are the questions:
1. Who has veto power over this project?
One of the most startling outcomes for a young project manager is to have the project cancelled abruptly after pouring a lot of energy into directing and supporting the project and the team performing on it. To head off such an outcome, you should ask this question early in the project definition phase. The answer, which could include the CEO, the Chairman of the Board, or one of the Founders, gives you an idea of who should be included in your regular status updates.
You also can discreetly inquire as to whether those people with veto power have any feedback for you and for the project team, even if they don’t show up on your organization chart (at least not anywhere near your project team). This is the art of politics, and you may as well get good at it.
2. How many of the project team have in the past been interrupted with high priority, preemptive requests from outside their project?
No matter how carefully you estimate manpower and workload, your estimates will be way off the mark if people outside your project can and do take away your team members’ time with non-project work. It is best for you to gauge this “distraction level” as a percentage of the team’s effort, so ask this question early in your project estimation phase.
There are two aspects of this kind of distraction. One is pure non-project work requests that take away team time when they do things like fix a problem with the CEO’s PowerPoint slides, or respond to a key customer’s emergency. The other is when project team members are assigned to more than one project, so that they are switching between the project you manage and a project (or two or three) that are managed by someone else.
When this is the case, you must not only divide the projected available team time by the number of concurrent projects, but also further degrade the time by the “context-switch” factor, which I estimate at 10% per context-switch. In other words, if a team member is working on two projects at once, each project may get 45% of a full-time member at best. For three projects, it’s .8/3 or 27% of full time. Of course, if the context switch happens during a single day, the percentage loss is much worse than 10%. You should make your estimates accordingly.
3. What is the available budget for tools and other capital equipment? Whose approval is needed to actually spend this money?
You want to know how much you can spend on tools before you start, because having the right tools is often crucial to making a team productive. If the development work is in software, this is particularly crucial to your planning – having the wrong tools can not only make productivity low, it can get in the way of your ability to hire the best people for the team.
Having determined how much money is “available,” you also need to find out what it takes to spend the money. Often, in larger organizations, the path to making capital outlays is long and arduous. If it only takes a written justification from you and approval from your immediate boss, then you’re in a relatively normal situation. If a committee has to meet in order to approve your purchase, then you had better find out who is on the committee, how often they meet, and what kinds of purchases they have approved (and disapproved) in the past.
These three questions may all be part of politics. But then knowing what it will take to succeed may influence which project management jobs you take on. Be forewarned and proceed with your eyes open and questions ready.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––
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. http://bit.ly/9pX1wS
For more information, please visit his website at http://johnlevyconsulting.com ,
Email him at info@johnlevyconsulting.com , or call 415 663-1818.
Summary
Architecture is about design at the top level, including interfaces and protocols. Architecture of complex systems requires knowledge of the technology in all of the components. In software, there are few constraints on how the components are put together, so it requires discipline to keep things simple and consistent. Bring in an architect when you are trying to integrate many existing subsystems.
Architecture is the high-level design of functional components of a complex system. A functional component can be anything from an arithmetic unit in a computer processor to a database system in a software environment. What an architect does is to define the functioning of the unit (without specifying exactly how the function is to be implemented) and the protocol for interfacing to the unit – that is, how to invoke the function and how to transfer data to and from the unit.
Interface and protocols are the stuff an architect works with. Whether the interface is a bus or an object instantiation in an object-oriented software system, the key objective of the architect is to make the system as simple and as consistent as possible, viewed from the functional block level. Why? Because simple, consistent interfaces and protocols are more robust, are easier to understand and are easier to modify when needed. In other words, more agile.
I worked for a number of years at Quantum, a maker of hard disk drives. Quantum developed their own ASICs (application-specific integrated circuits) for inclusion in their hard disk drives. They also wrote firmware (embedded software) that controlled the whole disk drive, from servo (motion control on the read/write head assembly) to buffering (managing the flow of data into and out of the disk drive). As time went on, the complexity of the firmware and the ASICs went up by orders of magnitude, allowing nearly all of the functions of the disk to be managed by a single chip containing a microprocessor, RAM memory and the ASIC logic.
My dream was one day to have designers of the ASIC logic and the firmware logic use a single integrated tool that would allow the design to be completed before a commitment was made for partitioning the functions between hardware and software. Even though firmware runs for the most part as a sequential process, and ASICs for the most part run as parallel pieces of hardware logic, their functional blocks have a lot in common. Even more important, the definition of an interface between the functional blocks are almost exactly the same for firmware and ASICs.
Since hardware and software can frequently be traded off – complex hardware can be simulated by large software programs running on simple hardware, for example – why not defer the decision as to which parts will be committed to hardware until after all of the design is done? I visualized a designer completing the design of hard disk control logic on an automated design system, then trying out several different variations on partitioning the logic between hardware and software before committing the design to a chip and firmware, each of which would then be automatically generated by the design program.
Alas, the design automation software never converged to a degree that allowed such a tool to be built. ASIC designers still have to ply their trade using design tools that understood logic gates and clocks, sequences of inputs and outputs on signal lines, and parallel processing of signals (and testing for race conditions). Firmware designers, on the other hand, have to write their code as sequences of instructions that execute on a computer processor, access memory, and perform input and output operations using registers (many of them embedded in the accompanying ASIC).
The architect of a disk drive thus must understand both worlds – logic and software – as well as several others, including read/write, servo and mechanical technology. Fortunately, the boundaries between these areas have evolved only slowly. However, in the software arena, boundaries between functional blocks of a system are much more volatile, because there are very low barriers to invention of new ways to interface between blocks or to perform protocols.
Therefore, the software architect’s job is even more critical, because simple and consistent interfaces and protocols will not occur naturally. There are two reasons for this. First, software designers tend to delight in inventing new ways to interface between modules – because they can. And second, legacy systems always demonstrate limitations that must be overcome as systems evolve.
To maintain agility within software designs, an architect must balance the need for evolving functions with the conceptual integrity and simplicity of an initial design. This is why the best architects are constantly struggling to reduce complexity while integrating more and more functions into an evolving system.
If you thought that the work of an architect is only needed at the beginning of a project, consider what will happen if you let existing interfaces and protocols persist forever as you integrate diverse systems into a working whole. The battle for robustness and maintainability will not be won by letting every subsystem persist unchanged. Instead, you need a constant reevaluation of all of the interfaces and protocols. When your designers are facing such problems, bring in an architect.
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 – johnlevyconsulting.com
Email him at: info@johnlevyconsulting.com , or call 415 663-1818
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, Get Out of the Way, 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. http://bit.ly/9pX1wS
For more information, please visit his website at http://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. http://bit.ly/9pX1wS
For more information, please visit his website at http://johnlevyconsulting.com ,
Email him at info@johnlevyconsulting.com , or call 415 663-1818.
