IT organizations are in particular need of good governance. They face a unique degree of resource sharing across the enterprise. IT leaders are brokers of limited project and infrastructure money in the organization. There are many competing demands for a limited pool of resources. An IT leader can either charge for all the services or create a governance model for allocating the shared resources. Non-IT leaders who need information systems resources want a voice in the decision process.
Many organizations tend to have a mixture of chargeback and shared free resources. To prevent the tragedy of the commons around free services, organizations adopt some form of a governance model. Governance sets the criteria for the organization's IT priorities. Then they use these criteria to prioritize resources and projects. Prioritization helps determine what decisions need to be made and who makes them.
I've read some wonderful books, white papers, and internal manifestos on how to launch governance models for IT organizations. They explain the committees, the scope of responsibilities, the nature of the decisions, the criteria for creating priorities, and the individuals involved. With all this wonderful documentation, how could they possibly fail?
Usually governance fails because the meetings are boring. After the initial excitement of the governance launch fades, members of the governance process start to lose interest. Attendance wanes. Within months, people wonder what happened. Discussions are theoretical and abstract. Real influence in the future of IT is not happening at the governance table.
So what do you do? How do you keep the flame of interest alive on a regular basis? There are three secrets to great governance. The first secret is make sure everyone realizes the governance process is the only way resources from IT are going to be allocated. No back doors, no secret deals. Everything is on the table at the governance meeting. That means there is money on the table at every meeting.
If all projects go through the governance model for approval, this process allocates all IT investment money. We all know there is never enough money to implement every idea and project. So the money and resources approved for one project means some other project will not be done. This means the sponsors and stakeholder representatives of initiatives with competing demands must justify their requests at the governance table. IT becomes the facilitator of the debate, not the decision maker.
Governance meetings become interesting because they shape future investment. The winners of the IT allocation discussions are the winners of investment in the future of the organization. That makes the governance meetings particularly fascinating.
The second secret is to make sure the meetings are entertaining. It may sound silly, but no one wants to attend yet another boring and dull meeting. Give your committee members something to look forward to by teaching them, in an entertaining way, about the issues before asking for a decision. Educate attendees on the issues facing IT and engage the IT staff in the teaching process. The organization will learn about the key IT issues and the IT staff will learn about the broader organization's issues.
To keep the education process entertaining, use the IT staff who are closest to the issue to explain it. Make sure their talks are brief, focused, non-technical, and avoid jargon. Using IT staff to explain the issue exposes more people to the governance process. The exposure to new ideas and people from the IT organization helps everyone grow.
The third secret is to open the kimono to what really goes on in the IT organization. Report on progress honestly. Expose your performance metrics and open them up for discussion. If something is working well, tell your governance committees. If something is failing, tell them why and what you are doing to fix it. Listen to their suggestions. Members of governance committees want to have an impact. Make sure you listen and implement the good suggestions.
When IT acts on the good suggestions, your governance stakeholders feel they are being listened to. They feel like they are having an impact and making a difference. There is nothing more engaging than realizing your voice is being heard and valued.
In summary, there are three ingredients to keep your governance process alive and engaging. First, give your governance committees real influence on IT investments. Next, educate them on the issues before asking for decisions. Finally, open the doors to the IT organization and make sure there are no secrets. These three ingredients make the secret sauce of good governance.
~
Monday, 24 October 2011
Sunday, 23 October 2011
Optimism: the Ultimate Motivator
Pollyanna was a fictional character from a book of the same name written in 1913. The plot is a about a young girl who always finds something to be glad about in every situation. She has an overwhelmingly and infectiously positive attitude. Her bright personality combined with infinite optimism changes other peoples' lives for the better. As a manager, does the plot seem silly and old-fashioned to you?
Modern management cynics typically view Pollyanna and people like her as naive and ineffectual. Today's managers are supposed to be tough, heads-down misanthropes. But Colin Powell, former leader of the most powerful army in the world, was a Pollyanna. His most famous quote is "Optimism is a force multiplier." He fought in Vietnam in some of the most difficult military operations of the war and he learned the value of optimism under rather grueling circumstances.
Managers often overlook the value of optimism. For example, what employee would prefer to work for Scrooge instead of Pollyanna? Optimism paints a positive picture of the future - it gives staff something to believe in. Optimism creates energy and enthusiasm. Misanthrope managers claim they never have enough staff to get the work done. Optimistic managers may have the same workload and same headcount, but they're looking forward to continuously greater accomplishments with staff who relish the opportunity.
How do you create optimism? As a manager do you just put on a sunny disposition and act happy all the time? Should you hope your clients and staff simply believe there is a silver lining in every cloud because you tell them so? Optimism without substance is hollow and destructive. Successful optimism has two feet firmly planted in reality. The first foot is in rooted in today's immediate success. The second is in tomorrow's long term success. Create faith in the ability to succeed today. Then build faith that today's success will continue. Confidence in today's success builds unshakeable faith in the future.
Start with small successes. Complete small high profile projects that not only exceed your clients' expectations, but your staff's own expectations too. Build confidence that the team can win against local competition before going on the road to play in the big leagues. When you have created self-confidence in the team you can create deep-seated optimism through bigger changes.
The bigger successes take time, but have a lasting impact on your culture. For example, I ran a large organization where we genuinely hired from within. Every director and manager who worked for me was promoted internally. Over time this approach created a sense of opportunity and confidence that personal growth within the organization is possible. When staff see management positions being filled internally they see hope for their own future in the organization. Doing this consistently creates trust in management. Trust + opportunity = optimism.
Once your team has unshakeable optimism, they can accomplish anything.
~
Modern management cynics typically view Pollyanna and people like her as naive and ineffectual. Today's managers are supposed to be tough, heads-down misanthropes. But Colin Powell, former leader of the most powerful army in the world, was a Pollyanna. His most famous quote is "Optimism is a force multiplier." He fought in Vietnam in some of the most difficult military operations of the war and he learned the value of optimism under rather grueling circumstances.
Managers often overlook the value of optimism. For example, what employee would prefer to work for Scrooge instead of Pollyanna? Optimism paints a positive picture of the future - it gives staff something to believe in. Optimism creates energy and enthusiasm. Misanthrope managers claim they never have enough staff to get the work done. Optimistic managers may have the same workload and same headcount, but they're looking forward to continuously greater accomplishments with staff who relish the opportunity.
How do you create optimism? As a manager do you just put on a sunny disposition and act happy all the time? Should you hope your clients and staff simply believe there is a silver lining in every cloud because you tell them so? Optimism without substance is hollow and destructive. Successful optimism has two feet firmly planted in reality. The first foot is in rooted in today's immediate success. The second is in tomorrow's long term success. Create faith in the ability to succeed today. Then build faith that today's success will continue. Confidence in today's success builds unshakeable faith in the future.
Start with small successes. Complete small high profile projects that not only exceed your clients' expectations, but your staff's own expectations too. Build confidence that the team can win against local competition before going on the road to play in the big leagues. When you have created self-confidence in the team you can create deep-seated optimism through bigger changes.
The bigger successes take time, but have a lasting impact on your culture. For example, I ran a large organization where we genuinely hired from within. Every director and manager who worked for me was promoted internally. Over time this approach created a sense of opportunity and confidence that personal growth within the organization is possible. When staff see management positions being filled internally they see hope for their own future in the organization. Doing this consistently creates trust in management. Trust + opportunity = optimism.
Once your team has unshakeable optimism, they can accomplish anything.
~
Thursday, 20 October 2011
Complexity is easy, simplicity is hard
In management, complexity is an excuse for not really understanding the problem. I find a lot of managers rush into decisions without taking time to clarify the real issue in their own mind. As a manager you need to make the effort to simplify your thinking about a problem. Imagine this approach: to really understand a problem, you need to be able to explain it to your grandmother. Once you have that kind of clarity, you are ready to take rational action to solve the problem.
Clarity of thinking is a rare commodity in all walks of life. For example, the battle of Waterloo was a turning point in European history. Did Wellington win it with a series of complex strategies? Did he outfox one of history's greatest generals through sheer intellectual power? Nope. There are several reasons for the victory, but ultimately Wellington just picked a good place to fight. He picked the right ground and built his battle plan around a defensible ridge. Not complicated. But he decisively changed the course of history.
Hemingway, renowned for his economy of words, was once asked to write the shortest story possible. He used six words: "Baby shoes. For sale. Never used." An emotionally powerful message conveyed with remarkable brevity. Can you have the same effect as a manager? Creating a clear message starts with simplifying the problem. Simplification builds clarity. That is hard work. It is easy to assume a problem is complicated.
What does this mean to a manager facing challenges this morning?
Think about your strategic plan. Is that 100 page strategic plan full of spreadsheets and complicated charts ever going to be read? What if the plan was only 10 pages with lots of easy to read graphics? In any strategy there are probably only 5 or 6 strategic changes you really need. Boil it down to the core principles of needed change. Then explain how you want to get there in clear language.
On a smaller scale, think about that business case for a new project. Do you think you can sell the idea in a 25 page detailed memorandum? I doubt it. No one has the patience to read the whole thing. If your audience isn't paying attention, how can they approve its funding? Keep it short and to the point. Make your case and move on.
Applying lessons to management from writing fiction and fighting wars may seem like a stretch. But these are all human endeavours requiring similar problem solving skills. I think Wellington would have made a great corporate president and Hemingway could have been a brilliant software entrepreneur. What about you?
~
Clarity of thinking is a rare commodity in all walks of life. For example, the battle of Waterloo was a turning point in European history. Did Wellington win it with a series of complex strategies? Did he outfox one of history's greatest generals through sheer intellectual power? Nope. There are several reasons for the victory, but ultimately Wellington just picked a good place to fight. He picked the right ground and built his battle plan around a defensible ridge. Not complicated. But he decisively changed the course of history.
Hemingway, renowned for his economy of words, was once asked to write the shortest story possible. He used six words: "Baby shoes. For sale. Never used." An emotionally powerful message conveyed with remarkable brevity. Can you have the same effect as a manager? Creating a clear message starts with simplifying the problem. Simplification builds clarity. That is hard work. It is easy to assume a problem is complicated.
What does this mean to a manager facing challenges this morning?
Think about your strategic plan. Is that 100 page strategic plan full of spreadsheets and complicated charts ever going to be read? What if the plan was only 10 pages with lots of easy to read graphics? In any strategy there are probably only 5 or 6 strategic changes you really need. Boil it down to the core principles of needed change. Then explain how you want to get there in clear language.
On a smaller scale, think about that business case for a new project. Do you think you can sell the idea in a 25 page detailed memorandum? I doubt it. No one has the patience to read the whole thing. If your audience isn't paying attention, how can they approve its funding? Keep it short and to the point. Make your case and move on.
Applying lessons to management from writing fiction and fighting wars may seem like a stretch. But these are all human endeavours requiring similar problem solving skills. I think Wellington would have made a great corporate president and Hemingway could have been a brilliant software entrepreneur. What about you?
~
Wednesday, 19 October 2011
When You Stop Having Fun
As a teenager I played lead guitar in a band. We weren't very good, but we had fun. Over time the rest of the players in the band started to get serious about playing professionally. They wanted to play other people's songs and get the sound perfect. Slowly but surely the fun disappeared for me, as everyone else got serious about the group. As the fun died, so did my interest in the group. Eventually the inevitable happened and my best friend from childhood had to ask me to leave the band. So instead of becoming a rock star I went to university, got a computer science degree and I've been having fun with computers ever since. The band found a new lead guitarist who fitted in and they played professionally for several years.
Hiring and firing decisions are never easy. Whether you're in a band or a large corporation, the decision cannot be taken lightly. In my experience, you have to ask yourself two questions. First, is this termination the right decision for the organization? Second, is it the right decision for the individual being terminated? As a manager, the first question is usually easier to answer than the second. But in my band example, the band did the right thing for the group and the right thing for me. I went on to a career I loved and they got to play the music they loved.
Management requires a healthy balance of understanding of others and self-awareness of your own needs. Balance your thinking before you act. Be aware of the toll on the organization while taking the time to assess the employee. Think carefully about your own biases when making the decision. Empathy is about understanding as much about others as you understand about yourself.
When you have a people problem and you lose sight of both sides' needs you can make several mistakes. The simplest reaction is to ignore a minor staffing issue. It's easy to worry about bigger issues and hope the little ones go away. But when an employee no longer fits in, the problem will fester and grow into a show-stopper that damages both the organization and the individual. Time is lost and both sides suffer.
Be careful in rushing into the decision. Some managers make difficult decisions too quickly. Shooting from the hip and terminating an employee without thinking through the consequences is mindlessly naive. In these situations the manager recognizes the situation is failing the company and simply pulls the trigger. Without understanding the employee's potential value you may have made a mistake. That's why it is worth taking time to understand if the decision is right for the employee too. A good termination is one where both parties benefit from the decision.
Some managers are afraid to make difficult decisions. They continue to support the individual after the person is a lost cause. Investments are made in counseling, the employee is sent on self-improvement courses, and sometimes the whole team is dragged to an off-site team-building session. As a professional manager, you need to know when to stop. Resolving issues around the cultural adaptability of one person is simple: once you are sure the situation isn't working for the company and the individual, take action immediately.
In my band example, what I did wrong was stay too long. I remained in the band long after I was enjoying it. As soon as I stopped having fun, I should have made it easier for everybody and left. I should have left the band before they had to ask me to leave. Managers don't always have the luxury of having self-aware employees. So they have to make some very difficult decisions and have some very tough conversations.
But that is why you are a manager.
~
Hiring and firing decisions are never easy. Whether you're in a band or a large corporation, the decision cannot be taken lightly. In my experience, you have to ask yourself two questions. First, is this termination the right decision for the organization? Second, is it the right decision for the individual being terminated? As a manager, the first question is usually easier to answer than the second. But in my band example, the band did the right thing for the group and the right thing for me. I went on to a career I loved and they got to play the music they loved.
Management requires a healthy balance of understanding of others and self-awareness of your own needs. Balance your thinking before you act. Be aware of the toll on the organization while taking the time to assess the employee. Think carefully about your own biases when making the decision. Empathy is about understanding as much about others as you understand about yourself.
When you have a people problem and you lose sight of both sides' needs you can make several mistakes. The simplest reaction is to ignore a minor staffing issue. It's easy to worry about bigger issues and hope the little ones go away. But when an employee no longer fits in, the problem will fester and grow into a show-stopper that damages both the organization and the individual. Time is lost and both sides suffer.
Be careful in rushing into the decision. Some managers make difficult decisions too quickly. Shooting from the hip and terminating an employee without thinking through the consequences is mindlessly naive. In these situations the manager recognizes the situation is failing the company and simply pulls the trigger. Without understanding the employee's potential value you may have made a mistake. That's why it is worth taking time to understand if the decision is right for the employee too. A good termination is one where both parties benefit from the decision.
Some managers are afraid to make difficult decisions. They continue to support the individual after the person is a lost cause. Investments are made in counseling, the employee is sent on self-improvement courses, and sometimes the whole team is dragged to an off-site team-building session. As a professional manager, you need to know when to stop. Resolving issues around the cultural adaptability of one person is simple: once you are sure the situation isn't working for the company and the individual, take action immediately.
In my band example, what I did wrong was stay too long. I remained in the band long after I was enjoying it. As soon as I stopped having fun, I should have made it easier for everybody and left. I should have left the band before they had to ask me to leave. Managers don't always have the luxury of having self-aware employees. So they have to make some very difficult decisions and have some very tough conversations.
But that is why you are a manager.
~
Tuesday, 18 October 2011
Outsource this!
In theory, organizations should focus on their core competencies and outsource everything else. The problem with that theory is the difficulty in deciding what is a core competency and what isn't. If I run a business making concrete, I want to focus on making concrete and selling concrete. Those are my core competencies and everything else should be outsourced. Typically accounting and IT can be done by specialty organizations. Let a company whose core competency is accounting or IT do my it for me.
Generally speaking, concrete is a classic commodity business. Nothing fancy or complicated. Like any commodity business, the product and its manufacturing process have not changed in decades. Unlike the music industry where iTunes revolutionized the distribution channel, concrete is not likely to see technology radically change its physical shipping methods.
In this type of business (and arguably any type of business) accounting techniques are legally required to be identical in every organization. There is no point in making it a core competency. In the concrete business the final product is so similar among manufacturers that there is no competitive advantage in accounting. Accounting is the classic outsourcing target.
But is accounting just like IT? They both may not look like core competencies, but IT warrants further scrutiny. First of all, it is not legally required to operate the same way across every organization. That gives IT some room for creativity and innovation. Second, IT can have a multiplier effect in global economies and within corporate cultures. The multiplier effect of technology means the right IT investments can have disproportionately large impact on profits.
How does innovation occur in your organization? In a culture that respects new ideas, innovation can take hold. Even in the example of a commodity business like concrete, there is always room for new process ideas and creativity. Maybe the final product is boring and simple concrete. But there is an unlimited amount of room for improving internal methods.
Any organization can create sustainable competitive advantage by continuously, rigorously, and ruthlessly examining their internal processes. All process improvements are driven by information changes and new knowledge. Inevitably, new information systems technologies are demanded to support and often drive these changes. An internal IT organization that understands the intimate details of the business model is infinitely better suited to drive such innovation than any outsourced IT organization. That makes IT a core competency.
What you outsource should never be cast in stone ... or concrete.
~
Generally speaking, concrete is a classic commodity business. Nothing fancy or complicated. Like any commodity business, the product and its manufacturing process have not changed in decades. Unlike the music industry where iTunes revolutionized the distribution channel, concrete is not likely to see technology radically change its physical shipping methods.
In this type of business (and arguably any type of business) accounting techniques are legally required to be identical in every organization. There is no point in making it a core competency. In the concrete business the final product is so similar among manufacturers that there is no competitive advantage in accounting. Accounting is the classic outsourcing target.
But is accounting just like IT? They both may not look like core competencies, but IT warrants further scrutiny. First of all, it is not legally required to operate the same way across every organization. That gives IT some room for creativity and innovation. Second, IT can have a multiplier effect in global economies and within corporate cultures. The multiplier effect of technology means the right IT investments can have disproportionately large impact on profits.
How does innovation occur in your organization? In a culture that respects new ideas, innovation can take hold. Even in the example of a commodity business like concrete, there is always room for new process ideas and creativity. Maybe the final product is boring and simple concrete. But there is an unlimited amount of room for improving internal methods.
Any organization can create sustainable competitive advantage by continuously, rigorously, and ruthlessly examining their internal processes. All process improvements are driven by information changes and new knowledge. Inevitably, new information systems technologies are demanded to support and often drive these changes. An internal IT organization that understands the intimate details of the business model is infinitely better suited to drive such innovation than any outsourced IT organization. That makes IT a core competency.
What you outsource should never be cast in stone ... or concrete.
~
Sunday, 16 October 2011
Never trust the word trust
Perhaps the most abused word in management is trust. "I trust you to get this done" is simply an interesting way to ask someone to get some work done. "I don't trust our competitors" is pretty normal. But managers fail when they use trust to distinguish, assess, and evaluate staff. The notion of "I trust you, but I don't trust you" might make the manager feel like they have drawn the line between good and bad.
But trust is an abstract noun. Any abstract noun's definition is so vague, that it is essentially meaningless. Vague language is a crutch. Bad managers cling to such vague language in performance appraisals and team assessments. An abstract statement such as "I trust you" really means "I don't have anything constructive to say about you." Saying "I don't trust you" simply means "I don't want to tell you what I really don't like about you."
Maybe the managers who abuse the word trust should be forced to use the word in only one context: "I trust you had a good lunch."
~
But trust is an abstract noun. Any abstract noun's definition is so vague, that it is essentially meaningless. Vague language is a crutch. Bad managers cling to such vague language in performance appraisals and team assessments. An abstract statement such as "I trust you" really means "I don't have anything constructive to say about you." Saying "I don't trust you" simply means "I don't want to tell you what I really don't like about you."
Maybe the managers who abuse the word trust should be forced to use the word in only one context: "I trust you had a good lunch."
~
Friday, 19 August 2011
Don’t Separate Design from Implementation
In fact, I couldn’t imagine how one could look at a piece of paper – words – and decipher what to program. I felt that if the work to be done could be adequately written down in a detailed enough manner that code could be written from it, well, it pretty much had to be pseudocode. And if someone was going to write pseudocode, why not just write the code? It would be equally difficult, less error-prone, and much more efficient.
Software Without Stories
So if I didn’t use detailed requirements – how did I know what to code? Actually, everything had requirements, it’s just that they were high level goals and constraints, not low level directives. For example, when I was developing process control systems, the requirements were clear: the system had to control whatever process equipment the guys two floors up were designing, the product made by the process had to be consistently high quality, the operator had to find the control system convenient to use, and the plant engineer had to be able to maintain it. In addition, there was a deadline to meet and it would be career-threatening to be late. Of course there was a rough budget based on history, but when a control system was going to be used for some decades, one was never penny wise and pound foolish. With these high level goals and constraints, a small team of us proceeded to design, develop, install, and start up a sophisticated control system, with guidance from senior engineers who had been doing this kind of work for decades.
One day, after I had some experience myself, an engineering manager from upstairs came to ask me for help. He had decided to have an outside firm develop and install a process monitoring system for a plant. There was a sophisticated software system involved – the kind I could have written, except that it was too large a job for the limited number of engineers who were experienced programmers. He had chosen to contract with the outside firm on a time-and-materials basis even though his boss thought time-and-materials was a mistake. The engineering manager didn’t believe that it was possible to pre-specify the details of what was needed, but if a working system wasn’t delivered on time and on budget, he would be in deep trouble. So he gave me this job: “Keep me out of trouble by making sure that the system is delivered on time and on budget, and make sure that it does what Harold Stressman wants it to do.”
Harold was a very senior plant product engineer who wanted to capture real time process information in a database. He already had quality results in a database, and he wanted to do statistical analysis to determine which process settings gave the best results. Harold didn’t really care how the system would work, he just wanted the data. My job was to keep the engineering manager out of trouble by making sure that the firm delivered the system Harold envisioned within strict cost and schedule constraints.
The engineering manager suggested that I visit the vendor every few weeks to monitor their work. So every month for eighteen months I flew to Salt Lake City with a small group of people. Sometimes Harold came, sometimes the engineers responsible for the sensors joined us, sometimes the plant programmers were there. We did not deliver “requirements;” we were there to review the vendor’s design and implementation. Every visit I spent the first evening pouring over the current listings to be sure I believed that the code would do what the vendor claimed it would do. During the next day and a half we covered two topics: 1) What could the system actually do today (and was this a reasonable step toward getting the data Harold needed)? and 2) Exactly how did the vendor plan to get the system done on time (and was the plan believable)?
This story has a happy ending: I kept the engineering manager out of trouble, the system paid for half of its cost in the first month, and Harold was so pleased with the system that he convinced to plant manager to hire me as IT manager.
At the plant, just about everything we did was aimed at improving plant capacity, quality, or throughput, and since we were keepers of those numbers, we could see the impact of changes immediately. The programmers in my department lived in the same small town as their customers in the warehouse and on the manufacturing floor. They played softball together at night, met in town stores and at church, had kids in the same scout troop. Believe me, we didn’t need a customer proxy to design a system. If we ever got even a small detail of any system wrong, the programmers heard about it overnight and fixed it the next day.
Bad Amateur Design
The theme running through all of my experience is that the long list of things we have come to call requirements – and the large backlog of things we have come to call stories – are actually the design of the system. Even a list of features and functions is design. And in my experience, design is the responsibility of the technical team developing the system. For example, even though I was perfectly capable of designing and developing Harold’s process monitoring system myself, I never presumed to tell the vendor’s team what features and functions the system should have. Designing the system was their job; my job was to review their designs to be sure they would solve Harold’s problem and be delivered on time.
If detailed requirements are actually design, if features and functions are design, if stories are design, then perhaps we should re-think who is responsible for this design. In most software development processes I have encountered, a business analyst or product owner has been assigned the job of writing the requirements or stories or use cases which constitute the design of the system. Quite frankly, people in these roles often lack the training and experience to do good system design, to propose alternative designs and weigh their trade-offs, to examine implementation details and modify the design as the system is being developed. All too often, detailed requirements lists and backlogs of stories are actually bad system design done by amateurs.
I suggest we might get better results if we skip writing lists of requirements and building backlogs of stories. Instead, expect the experienced designers, architects, and engineers on the development team to design the system against a set of high-level goals and constraints – with input from and review by business analysts and product managers, as well as users, maintainers, and other stakeholders.
A couple of my “old school” colleagues agree with me on this point. Fred Brooks, author of the software engineering classic “The Mythical Man Month” wrote in his recent book “The Design of Design” [1]:
“One of the most striking 20th century developments in the design disciplines is the progressive divorce of the designer from both the implementer and the user. … [As a result] instances of disastrous, costly, or embarrassing miscommunication abound.”Tom Gilb, author of the very popular books “Principles of Software Engineering Management” and “Competitive Engineering” recently wrote [2]:
“The worst scenario I can imagine is when we allow real customers, users, and our own salespeople to dictate ‘functions and features’ to the developers, carefully disguised as ‘customer requirements’. Maybe conveyed by our product owners. If you go slightly below the surface of these false ‘requirements’ (‘means’, not ‘ends’), you will immediately find that they are not really requirements. They are really bad amateur design for the ‘real’ requirements….
"Let developers engineer technical solutions to meet the quantified requirements. This gets the right job (design) done by the right people (developers) towards the right requirements (higher level views of the qualities of the application).”Separating design from implementation amounts to outsourcing the responsibility for the suitability of the resulting system to people outside the development team. The team members are then in a position of simply doing what they are told to do, rather than being full partners collaborating to create great solutions to problems that they care about.
_________________________________
Footnotes:
[1] “The Design of Design” by Fred Brooks, pp 176-77. Pearson Education, 2010
[2] "Value-Driven Development Principles and Values;" by Tom Gilb, July 2010 Issue 3, Agile Record 2010 (www.AgileRecord.com)
Subscribe to:
Posts (Atom)