So…you have a product that is core to the success of your organization, and you’ve just realized that, though the titles of your team say Software ENGINEER or DEVELOPER, it should really be ARTIST. Add to that the challenge of software itself, a product that is often indistinguishable from magic, and you have a dilemma. How do you maintain the level of creativity you need to be cutting edge and still deliver on time?
Let’s talk about the planning process. Consider, for a moment, Microsoft Project. I know, I know…a fearsome thought. So many people have an antibody reaction to using Project; I’ve worked at companies who have refused to use it, relying instead on Excel spreadsheets and lots and lots of manual updates to manage complex development programs. Microsoft Project isn’t perfect, no question about it, but it’s not really that bad. Its biggest problem is that it isn’t flexible enough to track the work of artist developers. It’s an artifact of the waterfall methodology, symbolized by the horizontal Gantt charts with their slick interdependencies that adapt every time a date is changed. It assumes that the project is one monolithic whole with interconnected moving parts. You start with A and move to B and then to C, and before long, you intersect with D. Waterfall methodologies focus on maintaining these relationships to keep the project on track. For some applications, it works wonderfully – IT infrastructure projects, vendor evaluation, customer betas and product launches, to name but a few -- but waterfall, and therefore Project, isn’t the best tool to support the more fluid vision of the software developer.
In reaction to the restrictions posed by waterfall, we now have “Agile” programming, with its various manifestations…the one I’m most familiar with is Scrum. Agile is pretty much exactly what its name indicates. It’s a way of approaching software development that allows us to bob and weave, to take advantage of discovery, to place enough rigor around the process to know what is going on, but to keep options open. Agile says that the best results arise from small, iterative development chunks. You come together as a group, you meet every day, and you chart your progress with tools that can be easily adjusted as you discover more and more about what your product really needs. And within a short time, you have a usable, working piece of functionality. It changes the game.
But Agile programming seldom takes place in a vacuum. Inevitably, there are customers and deliverables, and we need to sell product to make money. So elements of waterfall creep in under the cover of darkness. How can we support the creativity of our software developers and still march to the corporate drumbeat of deadlines, release schedules and launches?
Eventually, common sense trumps methodology, and a hybrid scheme emerges…not as crisp and apparently predictable as waterfall, and not quite as free and creative as Agile. This is a compromise with which no one is completely happy, but which honors both the need for flexibility and the need for predictability. However, it isn’t easy. Knowing when to let the creative energy flow and when to rein it in is a dance that doesn’t come naturally to most of us. We are called to come out of our comfort zone and live in two worlds at once. And this management challenge has a tendency to change emphasis depending on the breadth of our responsibility to the organization. The closer we are to the development process itself, the more comfortable we will be with an Agile approach. The closer we are to the Boardroom, the more we will want things to be certain.
But to be successful in this volatile, ever-changing world of software, we have to listen to the development process as if it could talk, and let it tell us what it needs. When we consider it as a living organism, the combined DNA of marketing and engineering creativity, the offspring of a company that depends on it for survival, we can see more easily where the touch points are, where we can apply structure, when it’s time to let the ideas flow, when to say, “That feature won’t make the release” and when to say, “This feature is worth waiting for.” It may mean letting go of some old assumptions about how things work, but the final result will be the best of both worlds.
____________________
Courtney Behm holds a B.A. and an M.A. in Performing Arts and Communication, and an M.B.A. from the Harvard Graduate School of Business. In her corporate career, she has worked for wildly successful companies, and those struggling to stay afloat in the ocean of change. Through her consulting company, Viewpoint Solutions (www.ViewpointSolutions.com), she has helped a diverse client base, including Sun Microsystems, Adobe Systems, Wyeth Pharmaceuticals and the San Jose/Silicon Valley Chamber of Commerce, find creative solutions to classic business problems. An accomplished speaker, Courtney uses a combination of language, humor, insight and front-line experience to offer a fresh perspective on life in the fast lane. In 2006, she returned to the corporate world, and is currently Senior Project Manager at i365, A Seagate Company. She is writing a book on how to lead effectively in a time of constant change, and collaborating on a book on Personal Career Management.
Let’s talk about the planning process. Consider, for a moment, Microsoft Project. I know, I know…a fearsome thought. So many people have an antibody reaction to using Project; I’ve worked at companies who have refused to use it, relying instead on Excel spreadsheets and lots and lots of manual updates to manage complex development programs. Microsoft Project isn’t perfect, no question about it, but it’s not really that bad. Its biggest problem is that it isn’t flexible enough to track the work of artist developers. It’s an artifact of the waterfall methodology, symbolized by the horizontal Gantt charts with their slick interdependencies that adapt every time a date is changed. It assumes that the project is one monolithic whole with interconnected moving parts. You start with A and move to B and then to C, and before long, you intersect with D. Waterfall methodologies focus on maintaining these relationships to keep the project on track. For some applications, it works wonderfully – IT infrastructure projects, vendor evaluation, customer betas and product launches, to name but a few -- but waterfall, and therefore Project, isn’t the best tool to support the more fluid vision of the software developer.
In reaction to the restrictions posed by waterfall, we now have “Agile” programming, with its various manifestations…the one I’m most familiar with is Scrum. Agile is pretty much exactly what its name indicates. It’s a way of approaching software development that allows us to bob and weave, to take advantage of discovery, to place enough rigor around the process to know what is going on, but to keep options open. Agile says that the best results arise from small, iterative development chunks. You come together as a group, you meet every day, and you chart your progress with tools that can be easily adjusted as you discover more and more about what your product really needs. And within a short time, you have a usable, working piece of functionality. It changes the game.
But Agile programming seldom takes place in a vacuum. Inevitably, there are customers and deliverables, and we need to sell product to make money. So elements of waterfall creep in under the cover of darkness. How can we support the creativity of our software developers and still march to the corporate drumbeat of deadlines, release schedules and launches?
Eventually, common sense trumps methodology, and a hybrid scheme emerges…not as crisp and apparently predictable as waterfall, and not quite as free and creative as Agile. This is a compromise with which no one is completely happy, but which honors both the need for flexibility and the need for predictability. However, it isn’t easy. Knowing when to let the creative energy flow and when to rein it in is a dance that doesn’t come naturally to most of us. We are called to come out of our comfort zone and live in two worlds at once. And this management challenge has a tendency to change emphasis depending on the breadth of our responsibility to the organization. The closer we are to the development process itself, the more comfortable we will be with an Agile approach. The closer we are to the Boardroom, the more we will want things to be certain.
But to be successful in this volatile, ever-changing world of software, we have to listen to the development process as if it could talk, and let it tell us what it needs. When we consider it as a living organism, the combined DNA of marketing and engineering creativity, the offspring of a company that depends on it for survival, we can see more easily where the touch points are, where we can apply structure, when it’s time to let the ideas flow, when to say, “That feature won’t make the release” and when to say, “This feature is worth waiting for.” It may mean letting go of some old assumptions about how things work, but the final result will be the best of both worlds.
____________________
Courtney Behm holds a B.A. and an M.A. in Performing Arts and Communication, and an M.B.A. from the Harvard Graduate School of Business. In her corporate career, she has worked for wildly successful companies, and those struggling to stay afloat in the ocean of change. Through her consulting company, Viewpoint Solutions (www.ViewpointSolutions.com), she has helped a diverse client base, including Sun Microsystems, Adobe Systems, Wyeth Pharmaceuticals and the San Jose/Silicon Valley Chamber of Commerce, find creative solutions to classic business problems. An accomplished speaker, Courtney uses a combination of language, humor, insight and front-line experience to offer a fresh perspective on life in the fast lane. In 2006, she returned to the corporate world, and is currently Senior Project Manager at i365, A Seagate Company. She is writing a book on how to lead effectively in a time of constant change, and collaborating on a book on Personal Career Management.
No comments:
Post a Comment