Maverick Software Development Model

(April 1, 2004)

Abstract

The Maverick Development Model is concerned with identifying the best practices for a given situation. A model development process is one that produces the correct development process for the current situation and constraints.

A model of development differs from development methodologies (such as Waterfall, Spiral, or Agile) in that the goal or desired outcome is the driving force, ever present, and never forgotten. Methodologies are approaches to achieving goals, but to often the reason for the steps of the methodology have been forgotten and no one knows the reason things are done except that the method requires it.

There are many good practices that have been accepted over the years and some of them will be presented as well as personal insights and philosophies concerning the software development process and the roles that make it up.

It is time for software developers to become computer scientists. The computer scientist is a role that encompasses all of the responsibilities necessary to complete the tasks of software development.

It is time for managers to become leaders and to forgo the methods of management that do not improve the development process. The process exists to help the workers and not the other way around were the workers are there to satisfy the process. The tail should not wag the dog.

Introduction

Since 1987 I have been participating in software development. I have watched the struggle between the programmers and product marketing, where the later sets the features and the delivery date and then complain about the quality, missed dates, or missing features. This struggle still exists and remains basically unchanged to this day.

I have witnessed the introduction of management to the software development process. This management consisted of processes with the idea of making the software development predictable, traceable, controllable, and manageable.

Several times over my career my various employers have trained me to perform formal reviews and in all of the roles of a review session. At each company, after the training and within a few short weeks, the review process ceased and the programmers went back to their old ways.

I have witnessed the acceptance and use of waterfall methodologies and their many variants. I have watched management follow the methodology with only the rigor that a true manager can attain. The requirements were gathered by product marketing and from that a design was made. This design became a hard and fast contract. However the design seemed to be used more as a defense exhibit (CYA) because every product date was always missed and development dragged on with no apparent end.

I have watched the release dates for the product set by the next occurrence of COMDEX and not by anything that actually pertains to the development of quality software. I have personally asked for requirements to be updated while in the development stage of the life cycle only to have management say that the waterfall method did not allow you to go back and change anything. I was flabbergasted! "The method doesn't allow" is a statement that just doesn't make sense. A method is not alive and does not make choices or demands. Management didn't allow the change because they didn't understand the goals the method was trying to reach. Management didn't allow the change because they can't change the process because they didn't understand the development process in the first place. As hard as I tried to indicate that changes were needed it was like talking to the wall. Where are we today? I feel we have made some evolutionary improvements that place us at a point to achieve revolutionary improvements. The idea is to recognize goals and create custom processes to achieve those goals for the current situation. One shoe does not fit all.

While working for the Department of Energy I struggled with the lack of contact the developers had with the customer. As a developer I felt completely out of touch. I had a written description of what they wanted. The description captured the letter of the law, but I had no feel for the spirit of the law. In 1992 I presented this analogy to my colleagues.

"Once there was a famous painter who was retained by the head of a European State. His time was so valuable that there was an assistant assigned to the artist. This assistant was to go out and find work for the artist and to gather the description of the desired painting. The assistant met with a wealthy merchant and convinced the merchant to commission a painting of his son. The assistant promised the painting finished in three weeks and returned to the artist. The assistant described the merchant's son to the artist and the artist painted a young boy in a silken blue suit holding in his hand a hat with beautiful plumage. The assistant took the painting to the merchant who agreed that the painting was exceptional but in reality it did not look anything like his son and that he wanted his son painted with is brother standing in a lane by a tree outside of their home. Needless to say the artist never delivered exactly what the merchant wanted. Each version became closer to the desired outcome but never just right."

My argument was that computer programming is only one small piece of the training received at the University. I hoped that we could be more than just a programmer; I hoped we could be a computer scientist. I wanted to apply what I had learned in requirements gathering, systems analysis, effort estimation, and design as well as write the code. However, my skills in writing code were expensive to acquire and my employer deemed my time too precious to be spent doing non-programming tasks that could be delegated to less expensive employees.

Also I have dealt with another extreme where managers that thought the developers where "prima donnas" that did not work hard, that waited until the project was well beyond the point of no return and then asked for raises and stock options and held the company hostage. Also the managers thought the engineers padded their dates so they could take it easy. There where managers that said they were sick of the attitudes of the developers and that if they were not happy then they should just leave because they are easy to replace.

If it wasn't enough to have managers without any real understanding of how to develop software I have watched developers dup management into believing heroics are required to develop software. Duped into believing that there is only a few that can develop the product and the rest of the developers are to take supportive roles. I have watched these clever developers build empires to protect themselves and become the very prima donnas that management complained about.

I have seen excellent developers black balled by these empire builders because the empire builders realized that this person was skilled enough to replace them. I have watched these empire builders wait for a power vacuum to occur and rush in and fill the gap. I have seen them target other developer's features that are late and secretly criticize the developer. Then, while the developer's reputation is in doubt, the hero works many late hours and rewrites the feature and presents it to management who in turn praises their effort and commitment to the company. The other developer is then regulated to a subservient position and is basically layoff fodder for the next round.

I have watched managers closely and found that very few managers excel at their task. Why? Leadership was the original goal, and management somehow was adopted. If a manager does not write code then what does he bring to the development effort? I have noticed that most managers consider their job to be reporting state in meetings. Therefore, they are only working when they are generating reports that capture the state of development and when they are in meetings presenting their reports. Managers are rewarded on their reporting skills and thus the amount of reporting grows beyond their ability to control. Then they assign the developers to help by making intermediate reports that will be used as sections in their master reports. Soon developers are spending one or two hours a day generating reports of the current state of the development effort. That state of the project has changed before the report is finished and the report captures only a ghostly representation.

In 1997 a friend gave me a copy of "Maverick: The success story behind the world's most unusual workplace. Ricardo Semler. Warner Books. 1993." I never read books on other people's success stories because I always figured that the revenue from their book was their success story. I reluctantly began to read the book and soon found a kindred spirit in Mr. Semler. Everything he said made sense to me, even though his business was in manufacturing. I could see benefits for software development. Eagerly I summarized his book and presented it to management. They laughed at the idea of publicly known salaries. When designing a new workspace for development I suggested that they give the developers a budget and let them pick their desk and chair. They responded that the furniture was an asset of the company and that the developers would pick a hodge podge arrangement that would look terrible. Wow, it was almost word for word from Semler's book when they were trying to select uniforms for their workers. I name my development model after his book, the Maverick Development Model. Mr. Semler has never met me, and the name does not mean to suggest he has supported this effort or endorses it in any way. It is my way of giving credit to one that has inspired and reinforced my ideas.

After being formally mocked for presenting the Maverick concept I went about my work trying to inject those ideas into the environment whenever the possibility presented itself. Needless to say, I was more often labeled radical, a loose cannon, and someone that had no idea of how real business works. After several years of frustration I decided it is easier to be quite and draw my paycheck. I lost all love for the software development process and kept my head low to avoid the laser-targeting sights of the layoff assassins.

Since I was unhappy with anything to do with the process I focused solely on object-oriented development and how to model systems in a way that the code was easy to maintain and be bug free. Before agile methodologies required unit test I had a personal policy of testing each piece of my code before introducing it in the system. My rationale was, if you don't have any confidence in you own code then how can you determine where a bug lies when you integrate your code with someone else's? I felt each piece of code had to be solid so that you can build upon it. You had to have confidence in some piece of the system; otherwise you will never know if you fixed a bug in the right place. For example, if the compiler is suspect, the third party libraries are suspect, the code from the rest of the team is suspect, and your code does not have some proven level of quality, then when the system fails where do you look for the problem? I have heard "compiler bug" cried probably a hundred times. In all of those, I have seen it to be the case only twice. Why do I share this? Because the evolutionary path that has led us to Agile process and Test Driven Development has be trodden by many of us.

This rationale of building on a solid foundation came from a few years of porting code. I have seen the memory manager rewritten too many times. You remember the guys that said, "You can't use alloc, it is inefficient. I read somewhere that you have to write your own to get any kind of performance from dynamic memory allocation." Always the reason was to improve performance. This piece of code then became a roadblock in the porting effort. Also, the code required the complete attention of a developer. I would say, "We are not in the operating system services business. We shouldn't be rewriting what the OS should provide. If the OS is not working, then develop to a better platform and quit supporting this garbage." They dismissed my comments as to hard-line. But I learned that we did not have a solid foundation because of all of the in-house developed services. The core service of memory management was now always a suspect. Many bugs were found in the memory manager. When something didn't work, were did you look for the problem? You had to go to the lowest layers and verify that the memory manager was not the source of the problem. Ironically the memory manager became the bane of the main platform as well. The system was taken to Intel to profile the product and suggest improvements. They pointed out that one of the trouble spots was the proprietary memory manager. It did not perform as well as the standard memory manager provided by the current version of the OS on the current hardware. The reason was that the OS people continued to develop and improve their services and to optimize their services for new hardware. The proprietary version, once debugged, was left "as is" and in a few short years become obsolete for the advances in hardware and operating systems. I relate this story because it is necessary to recognize the facets and subtle interplay in software development that the development process must recognize and support. If the memory manager would have had regression tests then it would not have been a suspect with every bug. If the developers would have delivered on the core business instead of optimizations of OS functionality they would have been better off in the long run. Agile has concisely described this as building the functionality that delivers value first, do it with the simpliest implemenation that meets the requirements, and use a test first design technique.

Since those times of which I described there have been some events that have occurred and set the stage for Maverick Development. One is the development of Java. The other is the acceptance of what is now termed Agile Methods.

Java has helped by reinforcing my idea that you shouldn't develop services that the OS should provide. This may be termed "don't reinvent the wheel" but it is much more than that. It is about letting others have their core business and trusting that they might be just as smart as you. It is amazing that the developers that were so concerned about performance and writing their own memory manager would ever accept Java.

Java was slow compared to anything we had seen for years. So, why did the same engineers that wrote their own memory manager embrace Java? Because, it was time to rewrite the system again or they wouldn't have a job! They had to sell management on another version of the product. They dropped the old buzzwords of web services, n-tier, peer-to-peer, and all the others. Regardless of the reasons the acceptance of Java has opened the door for me to try again to change the way software is developed. I have been quite for too many years. I love software development and it is time to present ideas and hopefully start meaningful discussions that lead to a revolutionary change in software development.

Agile methods have really helped in motivating me to gather my ideas and write this document. Honestly I am really shocked that agile methods have been accepted. The agile methods are addressing the same issues I have been concerned with for years. One of which is that of "the process doesn't allow us to go back and change the requirements." Finally in the name of agility you can go back and fix things that are wrong and work in a reasonable manner. But alas, as soon as you specify your ideas as a methodology, and there is some missing step for a specific situation, some manager that only knows the letter of the law will still say, "you can't do that, the process/methodology doesn't allow it." I have been doing research on XP for large teams and XP with Integration Testing. I have found many statements like, "XP doesn't do that" or "XP only does unit testing and Integration testing has to be added in a Waterfall fashion." Why do these managers "lock" XP down? I feel they lock it down because they do not understand the real problems and the appropriate solutions.

It reminds me of a 300 level fine arts class I had in college. Being a CS major and having artistic skills are not common and the application of logic to art is probably not something the Art Department was accustomed to. I remember learning of the masters, the great artists that had created a new style and had altered a norm and had become famous for their unique perspective and talent. Then in art class the instructor teaches you how to hold the brush in your hand, how to make the strokes, how to portray depth, how to do each and everything and then grade you on your conformance. If I painted just like Picasso then I would never be famous. I would be another painter that painted like Picasso. I had been taught what made a great artist and then told not to do the very things that made them great. I had been exposed to the model but taught to follow the method.

Why do I go into these past experiences? They form the foundation of my reasoning. I have always said, "It takes a village to make a village idiot." Without the foundation of understanding then methods are followed for the wrong reasons. I heard this story once.

A woman was cooking a ham. Her daughter-in-law notices that she cuts the ends off of the ham before baking it. She asks why. "Because it makes it taste better." Does it really make it taste better? After some investigation it was learned that the reason why she cut the ends off of the ham is because her mother did the same. The reason her mother did it was because she had seen it done by her mother. The reason the grandmother did it was because her baking pan was too small to hold the ham unless she cut off the ends.

Why do software development methodologies have the steps that they do? In the beginning the reason for the method was known. The key is that reason must not be lost and must be understood.

As computer scientists, instead of just developers, we have been trained to act in all the roles of software development. If your software process falls short in some area, we can fix it. We can have emergent processes if managers will get out of the way and if developers can wake up and become computer scientists and if we will work towards a goal and take whichever road gets us there. Life may be a journey and the road taken important, but software development is a destination. We have to lay down the pride, we have to give up the heroics, and work as a team. I guess this means we have to understand what work is. We have to understand why methods exist and what goals they are trying to achieve. We have to wake up and be thinking individuals that question everything and that do not want fame for anything.

Maverick Development is about goals and understanding. It is about accomplishing the goal the best way possible at that time. It is about changing anything and everything including the way you work, the way you think, and the way you interact with others. It is about removing dead end jobs. It is about real rewards. It is about trust and selflessness.

Work

Work is something that we all know when we are doing it and we also know when we are not. However, to give a firm explanation of one's work is difficult. Work is physically described as a force applied through a distance. In creative processes there is no physical object to be moved. That is why effort is used to describe creative work. Distance is also a non-physical attribute of creative work. Progress is used to describe this aspect. So, with effort and progress we work.

In a methodology, work is anything that progresses from the current step to the next. In a model, work is anything that finishes some attribute or artifact of the goal. Thus said, work on a method is very different than work performed on a model.

Traditionally one of the tasks of management is to measure work. The measurement of work is an intrusive inspection that interferes with the work that is being measured. The benefits of measurement should out way the costs of acquiring the measurement. If measurement activities are not worth the effort to perform then why continue to measure in the same way? Think and change it. Make it worth the effort. I often wonder at what point thinking was disallowed. It sure seems like it has been disallowed.

Developers are smart and once they learn the rules of a game they try to win. When developers are monitored and their performance measured, they learn to perform by what is measured. If lines of code are measured, you will get lines of code. If number of bugs found is the measurement, they will find bugs. The problem is we have forgotten why methods measure these things. Management wanted to measure quality and then they created a process. Somewhere down the road we ran amuck.

The measurement process uses terms like defect discovery rate and whether or not it is decreasing. It was anticipated that if the defect discovery rate is decreasing then the quality of the product was increasing. There are a lot of assumptions here, especially that all bugs are created equal. If one thousand bugs where found and eliminated and the product ships with just one bug and that bug manifests itself you have a problem, especially if that one bug happens to loose and corrupt data.

Even algile processes are not perfect. Agile and iterative processes have the expectation of seeing the additions of new code into the product to be rather constant over the iteration. Instead we see that the last three days of the iteration the number of new or modified files in the system increase dramatically. Why? It could mean many things. Managers readily accept conclusions from journals and well-known experts instead learning the current reason behind the problem for themselves. Without the understanding of reasons the ability to correctly apply the lessons of these experts rarely happens. Simply said, "You can't rely on books, papers, and publications to solve your problems. You have to get in there and figure things out for your specific situation and this requires understanding of the process and how work gets done."

In reality the check-in rate could be the symptom of any number of problems. Maybe the iteration is to long or the build process is too painful. Maybe integration is too painful. It could be that the Use Cases where unclear and too much time was needed to design the code. Maybe it was dependencies on other modules such that coupling became a bottleneck. This list could go on and on. Most likely the reason is not simple, but is complex and there are many reasons that differ from each team and each person. There is no simple fix and there might not be a complex fix. It might be the fact that this is the way it is.

My point is that it takes more than methods and management to understand the development process and to identify when progress is being made and when work has been done.

In Maverick Development work is defined to be any task that moves things forward to the ultimate goal. Most processes do not measure time spent helping other team members. Traditionally if help has been given to a team member it is not unusual to label the person that needed help as a weak link. Being labeled a weak link is like putting strawberry jam in your pockets because in the next layoff you are toast. So, people will not ask for help. Is that what management wanted? I doubt it. This is what they get and often they cannot recognize the environment they have created. In Maverick Development helping another developer get work done is work. Helping the team move forward is work. It does not affect the person's task list in a negative way. If the person does not finish their tasks for the iteration yet they worked hard on unforeseen tasks then the person is still successful and considered a great worker.

When helping others is not rewarded you will see symptoms of it. You will hear developers say things like, "I didn't get anything done today because of interruptions" or the person that needs help will passively say "I hate to bother you right now for some help but I am stuck" or they will only ask for help through non-intrusive manners such as e-mail.

Work together and be concerned for others success. If managers are counting and measuring, then developers will only work on what is being counted. If there is no metric on how many others you helped to be successful today, then no one will help others. Maverick Development demands less measurement OR it demands management to truly measure work, which would be a very difficult task that most managers are not up to. Maverick development raises the bar on management.


Computer Scientist

The developer has to be more than just a code writer. The bar is raised on the developer. For lack of a better term I say the developer must become a computer scientist. I chose the term computer scientist because during my formal education as a computer science student I learned all the aspects of developing software. I learned about programming languages, algorithms, requirements gathering, quality assurance, effort estimation, software cost, motivating programmers, ...

The computer scientist is a leader in the area of software development. The computer scientist understands that heroic efforts can destroy teams and skew business perspectives into believing heroics are necessary. The computer scientist understands when to use multiple inheritance. A computer scientist understands runtime behavior as compared to static behavior. A computer scientist understands the costs of coupling and poor cohesion. The computer scientist understands activities that improve productivity and activities that slow things down.

Management

First I need to define the type of manager to which I will refer. Historically developers have been promoted to team lead, then manager, then director, and on up the ladder. I have also noted there are two paths to manager. The other path comes from the business side of the company instead of the technical side. In the organizations I have experienced often the manager has a technical role. The manager reviews and approves designs and architectures. Also the manager choses the development methodology, the amount of reporting, the format for meetings and documents, coding styles, and other things that directly relate to the development process. In addition to these responsibilities these managers also perform reviews, do budgets, and report status. The manager often uses the position to inject their desire in one situation and delegate when they have no opinion. This inconsistent use of position is not helpful.

Management has to come to its own in the Maverick Development Model. What does this mean? They have to have clear understanding of all of the aspects of development. First they have to understand each individual. Why, because they are managing people, they are not managing skill sets and resources. Everyone communicates in different ways. Everyone expresses concern in different ways. Everyone is motivated in their own way. I would imagine that a good manager , like a good poker player, can read a person as well as listen to a person.

Managers have to understand why different methods and practices are available and know which practice to apply to a situation. Managers are too often like the ship's captain that knows nothing about sailing. As long as the wind blows the ship along the right course everything is fine. However, as soon as there is a problem that requires knowing how to control a ship the so-called captain is in trouble.

The skill set of a manager has to be greater than the average developer on the team. A manager in Maverick Development must become a leader. A leader is much more than a manager.

Patton was a military leader. He did not care if politicians were pleased with him. He did not care if people did not like him. The Vietnam conflict was managed. It was not lead. The difference is clear. The "feeling" about the situation is almost tangible. Vietnam was managed and the methods were political and had nothing to do with winning a war or fighting for values. The managers of the Vietnam War talked in statistics. How many shots fired. How many casualties. How many sorties. How much money had been spent and are we within our budget.

From Mr. Semler's book I paraphrase and quote a section concerning management.

"...Fernando was convinced that the Hobart plant lacked organization, ambition, and the necessary controls. He would arrive at 7:30 a.m., to find himself alone in the office until about 9:00 a.m. At 5:30 p.m. people would leave for home and Fernando would stay until 9, 10, and sometimes 11 p.m. This didn't please him and everyone knew it.

Many others worked long hours too, and their families were beginning to complain. They were convinced that the hours were temporary, until the company had digested its acquisitions. 'It took us almost a decade to learn that our stress was internally generated, the result of an immature organization and infantile goals.'

Fernando was firing people and changing things constantly.

'At the Hobart plant, and all over the new Semco, we could track with great precision virtually every aspect of our business, from sales quotes to.welding machines. We could generate all sorts of reports almost instantly with dazzling charts and graphs.. (I)t took us a while to realize that all those numbers weren't doing us much good. We thought we were more organized, more professional, more disciplined, more efficient. So,.how come our deliveries were constantly late.'

Work hard or get fired was the new motto. Everyone was being pushed forward instead of being self-propelled.

'During this time I often thought of a business parable. Three stone cutters were asked about their jobs. The first said he was paid to cut stones. The second replied that he used special techniques to shape stones in an exceptional way, and proceeded to demonstrate his skills. The third stone cutter just smiled and said: "I build cathedrals.'"

Leadership

Maverick Development is based on leadership. Leadership is something above management. All leaders have management skills. The converse is not true. The bar has to be raised on managers. They have to be leaders.

Agile methodologies depend upon emergent processes. Managers cannot control this type of process because of its very nature. Maverick Development goes where ever is necessary to get the work done. When an unexpected situation arises we do not plod along the same path just because the directions say to go that way. Instead, in Maverick, we say, "Hmm, an unforeseen problem. What should we do? Go on? Go back? Go around? ... "

Leadership cannot be taught. Quoting Dr. Huge Nibley,

"At the present time, Captain Grace Hoper, that grand old lady of the Navy, is calling our attention to the contrasting and conflicting natures of management and leadership. No one, she says, ever managed men into battle, and she wants more emphasis on teaching leadership. But leadership can no more be taught than creativity or how to be a genius. The Generalstab tried desperately for a hundred years to train up a generation of leaders for the German army, but it never worked, because the men who delighted their superiors (the managers) got the high commands, while the men who delighted the lower ranks (the leaders) got reprimands. Leaders are movers and shakers, original, inventive, unpredictable, imaginative, full of surprises that discomfit the enemy in war and the main office in peace. Managers, on the other hand, are safe, conservative, predictable, conforming organizational men and team players, dedicated to the establishment.

The leader, for example, has a passion for equality. We think of great generals from David and Alexander on down, sharing their beans or maza with their men, calling them by their first names, marching along with them in the heat, sleeping on the ground and being first over the wall. A famous ode by a long-suffering Greek soldier named Archilochus, reminds us that the men in the ranks are not fooled for an instant by the executive type who thinks he is a leader.

For the manager, on the other hand, the idea of equality is repugnant and indeed counterproductive. Where promotion, perks, privilege and power are the name of the game, awe and reverence for rank is everything and becomes the inspiration and motivation of all good men. Where would management be without the inflexible paper processing, dress standards, attention to proper social, political and religious affiliation, vigilant watch over habits and attitudes, etc., that gratify the stockholders and satisfy security? ... Managers do not promote individuals whose competence might threaten their own position, and so as the power of management spreads ever wider, the quality deteriorates, if that is possible. In short, while management shuns equality, if feeds on mediocrity... For the qualities of leadership are the same in all fields, the leader being simply the one who sets the highest example; and to do that and open the way to greater light and knowledge, the leader must break the mold. " A ship in port is safe," says Captain Hopper, speaking of management, 'but that is not what ships were built for," she adds, calling for leadership... True leaders are inspiring because they are inspired, caught up in a higher purpose, devoid of personal ambition, idealistic and incorruptible... So vast is the discrepancy between management and leadership that only a blind man would get them backwards... "

It is a common known practice when hiring and retaining software engineers to retain what is referred to as the 10x performers. Maverick Development requires the same from its Leadership. Managers that are leaders will be 10x performers.

Trust is the key and here is what Mr. Semler had to say,

"We simply do not believe our employees have an interest in coming in late, leaving early, and doing as little as possible for as much money as their union can wheedle out of us. After all, these are the same people that raise children, join the PTA, elect mayors, governors, senators, and presidents. They are adults. At Semco, we treat them like adults. We trust them. We don't make our employees ask permission to go to the bathroom, nor have security guards search them as they leave for the day. We get out of their way and let them do their jobs."


Performance Reviews

Maverick Development changes the traditional performance review process. The goal is to truly review the performance of the team and the individual. Each person's performance is reviewed by each member of the team and this includes the team leader. There is no protection because of hierarchy, title, or rank.

For more information read Maverick Reviews.

Compensation

In Maverick Development, compensation is public knowledge within the company. Mr. Semler points out executives with high salaries should be proud of their salary and confident that they are worth it. If they are not confident they are worth their salary then they will be inclined to hide it.

For more information on compensation please read the section entitled "Compensation" in Maverick Hiring.

Meetings

In Maverick Development all meetings are to have an agenda that is known before hand by all attendees. The agenda should be concise and if the meeting is to be one of discovery then state that fact.

I have attended to many meetings where some important and complex idea is briefly presented and management unexpectedly asks for opinions and if there aren't any they will move to the next topic. This unfair tactic does not produce the proposed desire of gathering more information. Prior to the presentation, management has taken as much time as they saw fit to discuss the matter and formulate their solution. Then they come to a meeting and blind side the entire team with a topic that is usually nontrivial. Do they really expect valid input? It is like they are saying, "Okay you have five minutes, be creative starting now!" Or is it a paternalistic approach and they are satisfied with the stupid looks and blank stares? This approach does not meet any goal and is not part of Maverick Development. Present a decision as just that, a decision. Present a proposal as that and give people time to prepare for suggestions.

In Maverick Development there is never a lunch meeting. Lunch meetings are rarely necessary. Downtime is essential, and if you want to have a lively mind for the afternoon then you may want to take a break at lunch. Do you ever feel that lunch meetings are used to squeeze and extra hour out of the day? How often have you attended a lunch meeting and then afterward you still take a lunch break? Any manager that calls a lunch meeting is to be gibbeted in an iron cage outside of the conference room for all to see just like what happened to Captain Kid.

The 15-minute standup from XP is sufficient to relay the current state of development. Details are not necessary. If there is a problem, then the details will be addressed by all those who can provide a solution to the problem. If things are on track, no one cares to hear about each item and how "on track" it is. State is the key, not details.

It seems that some managers only produce two things that are their work products. One is meetings, the other documentation. Maybe three things, the third being carbon dioxide. The documentation becomes the information presented in the meetings. These items include endless spreadsheets and huge step-by-step procedures on how the process is to be maintained. (Remember in the abstract the comment of the tail wagging the dog!) When a manager is in a meeting he is working. A developer is considered to be working when he is writing code. If a developer is in a meeting he is not working. If a developer is filling out some status report for management, he is not working. When they are doing these tasks, they are doing management's work.

The goal for a status meeting should be to determine the state of the project. Not to pour over minute details. The XPM methodology states:

"...meetings with the Product Manager and the Steering persons should be context not content. Have the success expectations changed? Is there any change to the scope/objectives? Have there been any changes in the stakeholders/related projects? Are the benefits and cost assumptions still relevant? Are benefits-realization plans still relevant? Has quality been changed? Are there changes to project risk or risk management issues? In other words, is the project still FOCUSED on the right business outcomes?"

This is a method of achieving the goal of reporting the state of the project. Since Maverick Development is goal oriented, and any method that achieves the goal is fine, then this or any other way to discover the state is within the Maverick model.

If there is not a goal, and there is not an agenda, then there is no meeting.

In Maverick Development meetings that deal with details instead of status are called by those who can do something with those details. Developers call meetings on details to discuss problems in detail with peers and individuals that can create a solution, not with people that conduct meetings. When managers attend these meetings they try to do the tricks of their trade such as injecting comments to stimulate thought and regulating the conversation to facilitate communication. Stimulate, regulate, and facilitate, and managers hate developers that can't produce tangibles. Go figure.

Managers interrogate to find the details of the state of the process. Leaders investigate and recognize on their own. Interrogation is intrusive. It takes to much time. It removes people from their real work.

Documentation

One reason documentation exists is because someone was trying to meet the goal of communication. Documents are created so that things do not have to be said over and over. Documents state things that are fixed, wrote down, and locked in state, thus the term statement.

When documentation does not meet the goal of communication then the document should not exist. If the document is not read then it clearly has not communicated anything and it should not exist. How many of you have ever put some comment in your weekly report to see if anyone was actually reading them? I have and many times I have not received any response from my manager. Clearly that report was not necessary. When my manager is busy doing what he really thinks is important he is not reading fifty status reports. Since in Maverick Development reviews are not done solely from the top down it cannot be said that status reports are required for the review process.

One approach that achieves the goal of conveying weekly status is just these three statements: on target, concerned, in trouble.

If the state is anything but on target, managers will then ask the obvious question, "Are you taking the appropriate action to rectify the situation?" How many times have managers pointed out the obvious?

In Maverick development there is one place to report status. There is not a team dashboard, and a textual weekly report, and a management spreadsheet. There is only one of these items, or some other single reporting method. If someone wants to generate a new report including other items, then they are responsible for the format and media difficulties, they cannot make this an assignment to others. The tail can't be allowed to wag the dog.

For more information on documentation please read Maverick Documenation.

Release Dates

Release dates in Maverick Development are based on real goals and supported by development.

In Maverick Development there is no "release date by trade show". How many times have you had a release date for a product set by product marketing to be for the next trade show? Where is the basis on that choice? They will tell you that if you miss that date we will miss our window of opportunity. The ability to market and display a product at a trade show is advantageous. However it is not sufficient to require the release of a product based on date alone. If the original time estimation for the set of features places the release date beyond the trade show then the feature set must be changed to correspond with the shorter development time.

Release dates are based on budget, features, quality, and timing. Product management will always try to set the date for release, the number of features in the release and the quality for that release. Well, everyone knows they can only choose two of the three. The third is always a variable.

Maverick development says that there are only two choices that are variable and that third, quality, is fixed. You can pick the features or the release date, but not both. Quality is always set at high. That never changes. No one will accept low quality. If you relax quality then you have opened the door for your competition to take your market share by merely reproducing the same functionality with improved quality. You have to have high quality so that the purchase decision is based on such things as features and solutions.

In Maverick development a goal can be set to reach a certain point in the production by a certain date. Since Maverick is based on real work, and doing work right, then it really doesn't matter if the date is not met. Work has really occurred and real progress was made. Goals are essential for a target. If the goal is to far out there, it is hard to hit. Should we get down on ourselves if we miss it? No. Why not? Because Maverick Development produces real work every day. In reality software is done when it is done. The scope can be reduced and thus you can be done sooner. Maverick Development supports these simple facts. Motivating development to work hard every day is the responsibility of the leaders of the development team.

Conclusion

Since Maverick Development is goal driven, the goals for the development process are essential. If a goal for development is to respond quickly to changing requirements then an agile development methodology could meet this goal. If you were trying to get awarded a government contract then a process based on SW-CMM could be the means to the end. Now, one would say, Maverick development is really nothing. It doesn't tell me how to do anything. The point is, you should be a computer scientist and you should already know how to do something or have the ability to learn how to do something for your current situation.

Maverick development opens the door for leadership and for understanding why methods exist and the real issues the method addresses. I am currently working on a Maverick Development Methodology for Agile Development. Maverick Development Model means there is a goal to be reached. If the method is not the right one you are not stuck. If you are not progressing, or if there is something missing, or whatever the problem is, Maverick says you must do something about it. You must apply your skills as a computer scientist. You must apply your leadership capabilities. Maverick Development Model addresses the issue of people that live by the letter of the law and not the spirit. It is out of the box thinking, but it shows that you have to have skills, knowledge, and understanding to survive out of the box.

Maverick Development demands that people are worth their salt. Reviews are going to happen and you had better be ready. Managers are not protected and leadership is the goal. Managers cannot promote mediocrity in Maverick Development. Managers cannot protect themselves from the movers and shakers. They cannot create empires. They cannot reward those whom please them and remove those whom do not.