We then got talking about Peter Weir’s 1989 movie, Dead Poets Society, starring Robin Williams and Ethan Hawke. In the movie, Robin Williams plays an English teacher who fosters a love of poetry in his students and encourages them to demonstrate freedom of expression and a willingness to go against expected norms. The movie takes an unexpected turn when one of the students commits suicide. The kid wasn’t free to live his own life but was being forced to live up to his father’s expectations and dreams. The father wanted his son to become a doctor and viewed poetry and drama as frivolous activities keeping his son from the real matter at hand — preparing for a future in medicine at Harvard. The son, in frustration shoots himself with his father’s gun.

So, the question is, whose fault was it — the dads for forcing his expectations on and disregarding his son’s feelings, or the teacher’s for introducing the concept that when faced with conformity, it is your responsibility to stand up for what you believe is right and to not blindly do what others tell you is just.

Recently I ran into Joe, a tech lead on a big Agile project I had coached. Joe is easily one of the best senior developers at the company, is enormously respected by the other developers and by the business stakeholders he interacts with. Joe has also done a stellar job on the Agile project and has been crucial in keeping multiple project teams functioning smoothly.  However, Joe got dinged on his just concluded annual review. IT management expressed dismay at Joe’s “lack of communication” and “poor planning.” What was actually meant was that IT management was not happy with Agile, was not happy with the business being part of the team, and was not happy with their inability to get ahead of any bad news and spin the message to the business — Joe’s superiors considered transparency to be a very very bad thing.

In this company, the C-level folks have utterly failed in convincing their subordinates that they truly believe in what they are espousing and have failed to create an environment that values and rewards openness. Thus far, senior IT managers have only paid lip service to changing the existing assessments, metrics, and reward systems that encourage lying and hiding material information. Employees believe that to be successful in this organization you need to keep a low profile, not stick your neck out, and to lie and shift the blame to someone else anytime something goes wrong. Senior IT managers have also failed to create any new experiences that would cause people to question and challenge their existing beliefs. Senior managers take their cue from C-level managers and try to do what they think their bosses actually want. I don’t blame them for simply going through the motions; after all, past experience has taught them that there is no benefit in doing something counter to what your boss expects (irrespective of what he/she says).

So, once again, the question facing me is: is it right for us to coach teams and get them dreaming about possibilities knowing fully well that they are not going to get real support and encouragement from their bosses, who say one thing to their business counterparts but do the exact opposite and have no interest in changing their modus operandi? Is it ethical for us to show people the great things that are possible and then have them penalized for their good work?

Have you faced a similar situation before? What did you do? What do you think is the right thing to do — call people out on their hypocrisy? Part ways with the client because long-lasting meaningful change is not a possibility at this time? Spend even more time on educating management and executives?

• Leadership is crucial for defining a shared vision and generating buy-in from employees.
• C-level managers are responsible for creating a learning organization that values systems thinking, craftsmanship, and team learning.
• C-level managers must design an organization whose structure, processes, metrics, rewards, and talent align with the organization’s mission.
• Managers are responsible for creating a well-trained, well-organized, well-managed company. If people require constant supervision then management has failed to do its job.

Last year, the new CEO at a client decided to leapfrog existing competitors by creating an innovative product; a product that would attract customers and cause competitors to play catch-up. A team that included the best developers, in the company, was hand-picked; the business was told that cost was not a concern; and the group was secluded from the day-to-day madness and allowed to focus on getting the job done. Despite this the program was a failure and ultimately the task of innovation was “outsourced.” What happened?

A number of major shortcomings inherent in the existing culture doomed the endeavor from the start; these shortcomings were very visible to outsiders but not to long-term employees. Not all organizations face all of these shortcomings — based on my experience, these are more prevalent in larger organizations.

• C-level managers not creating a learning organization
• Lack of a compelling vision
• Lack of prioritization and understanding of what is truly valuable
• Org structures and policies that stifle collaboration and communication of ideas, information, and feelings
• Reward/merit system that punishes innovation and risk taking
• Overly focusing on utilization
• Perception that senior management does not walk their talk

C-level managers not creating a learning organization

A belief that there is one right way and one right answer coupled with the allure of doing it right the first time makes it hazardous for employees to experiment, learn from mistakes, and to try novel approaches. Most command-and-control cultures penalize mistakes and those who have the temerity to try something new quickly learn that it is wiser to dutifully follow every rule and guideline — it’s safer to claim that any failure was due to a shortcoming in the process.

Over time, existent unwanted company behaviors, norms, and values supress any creative desire and motivation that employees may harbor about building a culture that encourages inquiry and trust. The job becomes a 9-5 grind and people stop offering ideas for improvement.

Lack of a compelling vision

Executives sometimes think that what ought to be done will get done without them getting personally involved. They tell what they want but fail to explain how to achieve what they want and why the want is even important. People lower in the organization hierachy are left to wonder, “Why should I/we ___?”

A non-existent vision or one that doesn’t align with what employees value and is imposed top-down guarantees lack of buy-in. As Patrick Lencioni so succinctly stated, “Trust and ability to speak freely are the building blocks for eventual results.”

Lack of prioritization and understanding of what is truly valuable

Some companies lose their ability to probe, sense, and respond to market conditions. They inadvertently fail (or purposely ignore) to ask existing and potential customers what they want and what they are willing to actually purchase. Assumptions are made by marketing heads or business owners based on their beliefs, prejudices, and opinions. These unvalidated assumptions often prove to be untrue and result in products being developed that no one wants to buy.

The problem is exacerbated when teams are not provided proper guidance on what is truly important. If everything is deemed a high priority (happens in cultures where IT is unable to say “No” to any business customer) then people end up multitasking, which leads to a loss of focus, more defects, delays, and no time for learning and self-improvement.

Org structures and policies that stifle collaboration and communication of ideas, information, and feelings

A command-and-control culture combined with a fractured (silo) organization causes an “us” versus “them” mentality to take root. Looking good, hiding bad news, shifting blame, and painting an overly rosy picture soon follow. A greater need for written communication (used for CYA) further dampens progress. When silos are present you often hear statements like, “that’s not my job” or ” I don’t care about the rest, I did my part.” Eventually we also lose the concept of teams and end up with a group of individuals working on a project. We also lose any understanding of a system-wide value chain. Incentive systems that reward local optimization worsen the situation by encouraging groups to make locally optimized self-serving decisions that negatively affect the whole. (See the Robbers Cave Experiment for how easy it is for such a mentality to spring up.)

Reward/merit system that punishes innovation and risk taking

When being right, making no mistakes, and doing what you are told is valued, people stop trying new approaches. They stop taking risks when their annual merit increases and bonuses are tied to metrics (often vanity ones) that aren’t aligned with the company’s goals. When meeting project time, scope, and budget constraints is how people are evaluated and compensated then it is not surprising to see them disregarding the concept of providing value; its more common to see fudged reports and gamed metrics. (Also see Jim Highsmith’s article, “Can-do Thinking Makes Risk Management Impossible.”)

Managers who don’t understand the difference between common and special causes only create additional rules and policies that further burden teams. Most managers also don’t understand that artificial targets and incentives don’t help if the process itself has problems. (For additional information search for Dr. Deming’s red bead game on YouTube.)

Overly focusing on utilization

An unhealthy stress on maintaining high utilization leaves no time for learning, thinking, improving. Departments want to show that they are very conscientious in how they spend scarce dollars; pushing employees to book all their time to specific projects helps show that employees are valuable and busy. Batching large chunks of work and getting people to be as efficient as possible at each step defeats the goal of making work flow so as to provide value to customers early and often.

Utilization goals of close to 100% are counter-productive as they encourage multitasking and creation of busy work, cause employee burnout, increase defect rates, slow down throughput, increase focus on activities instead of on outcomes, and leave no time for self-improvement. Without time to learn new technologies and keep with with new trends employees cannot be expected to come up with creative ways of getting things done.

Perception that senior management does not walk their talk

People quickly see through any political maneuvering or chicanery that senior managers might employ in order to look good. They lose faith and respect for managers who are more interested in playing the political game and not in doing what is right for the company or for the team. Such managers lose moral authority and have to resort to organizational power to get anything done. At best they get compliance; not the passion and creativity that an engaged employee brings to the table.

Other managers talk a great game but fall short on execution. Ultimately, actions speak louder than words and when there is a disconnect between what is said and what is done, people begin to disregard the spoken word. If managers and executives really believe in something, they should take every opportunity to demonstrate its importance. When employees don’t see the passion and don’t hear the message communicated over-and-over again they rightly assume that the new thing is just another passing fad. It isn’t the emloyees’ fault that they don’t belive; it is management’s responsibility to create new experiences that permit employees to question their existing beliefs and to try new actions in the hope of getting better results.

In conclusion

So, why did this company fail to innovate? The group had shortlisted 8 possible things they could work on but they dithered for months about which of these to work on first. They failed to quickly validate their assumptions on whether the market really wanted any of the things being proposed. The group continued to rely on tried-and-true methods and constantly referred to what had worked in the past; they failed to realize that new approaches to development were called for. They lacked managers unfraid of making decisions that were not guaranteed to succeed. They lacked executives who could provide the group with a clear direction or a challenging vision. A political struggle between the CEO and CFO worsened the situation and neither wanted to compromise on his agenda.

This company had over the years deemphasized systems thinking, personal mastery, shared vision, and team learning. Was it then any surprise that their ability to innovate had withered and disappeared? Losing the innovative edge makes it harder to keep up with faster nimbler competitors who aren’t resting on their laurels and are actively looking for ways to leave you in the dust. Ultimately, being nimble and agile is not a choice — it’s a necessity for survival and growth.

There were two reasons for the request:

1. I recently critiqued a 2-day “Introduction to Agile” class by a coach-in-training. Everything that I expected was covered in the class but I felt the lack of an underlying theme; the content didn’t seem to fit well together.
2. I wanted to understand whether Agile meant the same thing to different people and whether they emphasized the same points in their class/presentation.

Here is a sampling of the responses I received.

• “Deliver value frequently at a sustainable pace while adapting to business needs.” — Brad Swanson
• “Be one with the customer.” — Steve Johnson
• “Sense & respond quickly to changes that have measurable value.” — Skip Angel
• “Do the right things sooner.” — Jonathon Golden
• “Agile is about knowing what NOT to do.” — Mike Dwyer
• “Continuously adjust our actual process to reflect our improved understanding.” — John Ryan
• “Utilizing continuous prioritization and feedback, collaboratively develop incremental business value.” — Jim Elvidge
• “Continually improve value delivery via experimentation, feedback, and retrospection.” — Alex Singh
• “Do Something, Self-Organize, Inspect & Adapt” — Scott Dunn (stolen from Aaron Sanders)

Not surprisingly, people emphasized different aspects in their distillation. I assume that these are the same things they emphasize when coaching teams and organizations as well. It is important to note that everyone is right and no one definition is better than another; people with different backgrounds emphasize different things and have a different worldview.

What do you think is the intrinsic nature or character of Agile that makes it what it is? How would you define the most important aspects of Agile in no more than 10 words?

In software development, however, the technique has some shortcomings:

• Problems and their causes are not always linear and you cannot always trace a symptom directly to a root cause by asking the 5 Whys.
• Sometimes causes are separated, in a significant manner, by time and space from the effect; this makes identification of the relationship difficult.
• Practitioners at times aim for the single root cause, but each question could elicit many possible root causes.
• The 5 Whys technique works well in simple and complicated environments; not so well in complex and chaotic conditions (see the Cynefin framework for definitions). Multi-causality, contributing factors, and not-so-obvious variables if ignored can lead the questioner to the wrong conclusions.
• Results are highly dependent on the questioner’s ability — stop too soon (at the symptom level) and you don’t reach the lower level root causes; stop searching after the first right sounding answer and you miss out on other plausible causes; treat a long-lived and unchallenged statement as fact and you limit avenues of investigation.
• The questioner’s level of knowledge is a limiting factor — ignorance can cause people to overlook causes they don’t already know about.
• Results aren’t repeatable and different people can identify different causes for the same problem.

It’s important to realize that we have more than the 5 Whys method in our toolkit. We can flow chart the process, use the Current Reality Tree (CRT) thinking process, or use Gerry Weinberg’s Diagram of Effects (my favorite). Which techniques do you use?

1. What did I work on yesterday?
2. What am I going to work on today?
3. What are my obstacles/issues

Please realize that the questions are just a mechanism for ensuring that everyone understands:

• What’s blocked?
• What’s being worked on?
• Who is working on X?
• When will X be done?
• What am I doing/supposed to be doing?
• What are everyone’s top 3 priorities?
• What will be done today?
• What’s ready to test?
• What issues need to be discussed?
• What is critical?

ScrumMasters, your facilitation skills won’t amount to a hill of beans if everyone attending cannot satisfactorily answer (for themselves) these question after the daily stand-up. Don’t get hung up on the procedural nitty-gritty (the rituals); aim for understanding instead.

I found that a large information radiator for displaying project risks and issues has been well received by clients. The version I use is a simple 2×2 matrix. The two columns are used to classify items as Business or Technology related; the two rows to show whether the items are Execution or Coordination related — teams that aren’t smitten by the categories are free to change the headings to whatever makes sense in their context. Concentric rectangles denote when the effect of a risk will be felt.

Sample Risk Radar Chart

Items in the inner-most rectangle (or square or circle) identify current issues (risks that have come to fruition) or risks that will become issues within the next two sprints if not handled. The next outer rectangle shows risks that the team foresees materializing within the next 4 sprints. Longer timeframe risk items go outside the 4 sprint rectangle.

Color coding helps denote the severity/impact of the risk. Reds and Oranges affect the project more negatively than the Yellows and Greens. The Sunburst item in this case was a showstopper that was going to bring the project to a complete halt. The areas on the extreme right were for items that weren’t deemed worthy of being tracked on the risk-radar board just yet or for risks that had been taken care of.

For teams the goal was to handle risks before they became issues. Ideally, the innermost rectangle should be empty — teams should be proactively mitigating risks and taking care of them before they get into the innermost “Next 2 Sprint” rectangle.

We used large foam boards and masking tape for creating these risk-radar charts. The chart was prominently displayed in the team room and could be referred to during meetings.  The light weight foamboards made it easy for one person to carry the chart from one room to another if a meeting was being held elsewhere. Pictures taken with a digital camera were emailed to off-site participants.

Once a week, the Product Owner and ScrumMaster would meet with the development and QA managers and with business and IT stakeholders to review progress and roadblocks. During this hour long session, the group would discuss the issues and risks starting from the innermost rectangle.

This meeting served four purposes: (1) as a risk escalation mechanism, (2) as a mechanism for managers and stakeholders to remove impediments that were too big for a team to resolve on it’s own, and (3) as a mechanism for moving away from the existing one-way status reporting culture — managers and stakeholders were expected to report on progress (or lack thereof) on items they had publicly taken ownership of during the previous meeting, and (4) as a way for keeping managers from harassing the teams to “go faster”.

The reason this chart worked surprisingly well was: (1) it was always in everyone’s face and was hard to ignore, (2) managers had insight into risks and impediments and could proactively smoothen the way for the teams, (3) managers realized that teams could not go faster until the issues were taken care of.

Try it out on your next project and let me know what you think. Ideas for improvement will be highly appreciated.

2400 years ago, Xenophon took the initiative to lead 10,000 stranded Greek mercenaries out of western Persia (modern day Turkey and Iraq). The Greeks were 1,100 miles from home and had to retreat through inhospitable deserts and snow-filled mountain passes to the security of the closest Greek cities on the Black Sea. Throughout the journey, they were blocked and constantly attacked by the numerically superior Persian army.

During their retreat, when some mercenaries were disheartened because the Greeks had no cavalry, Xenophon reminded them that: “Wars may be fought with weapons, but they are won by men.” He also said: “Ten thousand cavalry only amount to 10,000 men. No one has ever died in battle by being bitten or kicked by a horse; it is men who do whatever gets done in battle.”

This is true of any human undertaking — it is men and women who get the job done. This is true for software development too — it is people, not horses (tools), that win struggles. Resources count, but they are not the deciding factor — people are.

So if you are ever faced with a situation that is not going well, ask yourself if you (the leader):

• Have the right people and more importantly if you are providing them the right leadership
• Give team members what they need to get their work done and provide them opportunities to develop their skills.
• Get out in front and set the example
• Help and teach others whenever they need your help and are ready to accept it
• Treat others with respect and give recognition for good work
• Take care of your team members and put the project before self
• Get your team thinking about the positive actions that they can take to succeed

If you don’t do any of these, it is doubtful if the team will trust or follow you; if you do, the team will always come through for you.

You can read the whole story about the Greek retreat in Xenophon’s “Anabasis” at http://ebooks.adelaide.edu.au/x/xenophon/x5an/ or on Project Gutenberg at http://www.gutenberg.org/catalog/world/readfile?fk_files=862407.

Abraham Lincoln used to ask a riddle: “If you call a tail a leg, how many legs does a dog have?”

Answer: Four, because calling it a leg doesn’t make it a leg.

As a change consultant you have the difficult task of unmasking and presenting reality as it really is. This may involve the removal of blinders that people have over their eyes. This also means that people have to be taught that simply wishing for things or saying things doesn’t make it so.

Telling people how things really are can land you into hot waters a few times. There’s something to be said about being tactful and pragmatic, but there are times when you have to say it as it is and lay it all on the line. The question to ask yourself is: “Am I here to just collect a pay check or to make a real difference?” If it is the former, there is not much chance that you’ll expose faulty thinking or organizational dysfunctions, stir up the pot, or stick your neck out. You’ll also not make much of a difference. Change agents who want to make a difference may end up getting their head chopped-off once in a while but in the long run the successes will far outweigh the failures.

I’ve had a few instances where I’ve had to say “A is A” — a thing is what it is — to senior management. I’ve had my head handed to me on a platter only once; the other times the clients actually appreciated the forthrightness and the rewards (satisfaction in causing big changes, bigger contracts) far outweighed the risks. My sense is that most people want to do the right thing; sometimes, they just need to be jolted out of their current mode of thinking.

In the software development field, the thing I really like about Agile is that it reveals problems and dysfunctions and forces you to either acknowledge the problem and fix it or to cover your eyes and hope it goes away. People’s responses to these difficult situations (exposing the naked truth) help you quickly distinguish those who talk a great game from those who actually walk the talk. These situations also help you determine if you are really going to make a lasting change in the organization or if you are simply wasting your time and postponing the inevitable. Some might say that, “A dead ScrumMaster is a useless ScrumMaster”. To that all I have to say is that sometimes you just have to realize that even though you may not be technically dead, you are pretty useless anyway.

There were a few problems that the teams faced when attempting to discover the stories:

1. There was minimal user interface and it wasn’t readily apparent who the users were for these back-office applications.
2. The team was at a loss on how to define the stories. Most of the stories by themselves provided no benefit — determining business value was difficult.

Let’s tackle these two separately.

Determining Actors

A number of people think of users solely as people. The problem with equating users with people is that the resulting stories are often too big to fit in an iteration and are better classified as epics. The problem of decomposing epics into smaller stories that are defined from a user’s (person) perspective and that provide business value frequently gets teams wrapped around the axle.

The trick is to realize that it is OK to have users who are not people. We can use the RUP concept of an actor to our advantage here.

An “actor” is anything with behavior, including the System Under Discussion (SuD) when it calls upon the services of other systems. Actors are roles played not only by people, but by organizations, software, and machines. — Craig Larman

Craig differentiates between three types of actors:

1. Primary actor: has user goals fulfilled via the SuD’s services
2. Secondary actor: provides a service to the SuD, e.g., external credit card authorization service
3. Supporting actor: has an interest in the behavior of the use case (or epic) but is neither primary nor secondary, e.g., government tax agencies.

Actors can be identified by asking questions like:

• Who uses the system (SuD)?
• Who starts and stops the system?
• Who does system administration?
• Who does user and security management?
• Is there a monitoring process that restarts the system on failure?
• Who evaluates system activity and performance?
• Who evaluates system logs? Are these remotely retrieved?
• Who gets paged on errors or failures?
• Do other systems call on the SuD to do their work?
• Does the system do something in response to a time event? If so, then Time is an actor.

Identifying the actors and determining their goals allows us to better decompose the stories.

Defining Stories

The loan servicing system involved the creation, transformation, and transfer of a number of file types. These file types had multiple record types within them. The data was exchanged between schools, loan providers, loan guarantors, loan servicers, endorsers, and employers not to mention the students and their parents. These files were often batched for processing, though the desire was to move to “real-time” processing sometime in the future.

The team initially created stories for each step of the loan origination process, like so:

• Create Stafford Loan from CL4 App/Send
• Create Stafford Loan from CL5 App/Send
• Create Stafford Loan from CRC
• Validate Loan information for Stafford Loan
• Validate Enrollment information for Stafford Loan
• Validate Borrower information for Stafford Loan
• Search for Loan
• Search for Disbursement(s)
• Search for School

The way the team approached the work caused a number of issues:

• Most of the stories were not independent; the team discovered for example that updating a loan from one type of record was very similar to updating it from another. So which story gets the bulk of the work?
• The team also noticed that if one type of creation story was overestimated, all the creation stories were likely overestimated. After a few iterations, the team really couldn’t say how much work actually remained.
• The team started working on the creation stories and after a half-dozen iterations realized that they had produced nothing of value; there wasn’t anything complete end-to-end. They had started working layer-by-layer instead of trying to build threads through the system.

A better approach would have been to decompose the epics in a manner that ensured that the resulting stories would adhere to the INVEST criteria (Independent, Negotiable, Valuable, Estimable, Sized appropriately, Testable).

Split by File Type

For example, an epic like “As a loan originator, I want to receive a correctly formatted Stafford Loan application so that I can process the loan request.” could be decomposed by the types of files that contain the loan information:

• Create Stafford Loan from CL4 App/Send files
• Create Stafford Loan from CL5 App/Send files
• Create Stafford Loan from CRC files
• Create Stafford Loan from CAM files

The backlog would have similar stories for creating other types of Loans: Federal Parent Loan for Undergraduate Student (PLUS loans), GRAD-PLUS loans, etc.

Split by Type of Information within the File

The stories mentioned above are too big to process in an iteration and need to be split further. An option is to do this by the type of formatting of the records in the file.

• As a loan servicer, I want to generate a CL4 file with the correct header information so that I can route the file correctly.
• As a loan originator, I want to receive a CL4 file with the correct header information so that I can process the file correctly.
• As a loan originator, I want to receive a CL4 file with correctly formatted Borrower Detail records (CL4 @1-02) so that I can process those correctly.
• As a loan originator, I want to receive a CL4 file with correctly formatted Loan entry records (CL4 @1-07) so that I can process them correctly.
• As a loan originator, I want to receive a CL4 file with correctly formatted Sub/Unsub Reallocation Loan Decrease records (CL4 @1-13) so that I can process them.
• As a loan originator, I want to receive a CL4 file with correctly formatted Post-Withdrawal Return/Refund records (CL4 @1-28) so that I can refund funds.
• And so on and so forth

The backlog would have similar stories for creating Stafford Loans from other file types: CL5, CRC, CAM.

Split by Data Filters

Different Actors have different expectations of what data (transactions) is in the file. Some want data for the past week, some for the past 24 hours, some from specific sources, etc. To account for this, we can split based on time periods selected.

• As Aggieland Credit Union (a loan originator), I want to receive a CL4 file with only the last week of data.
• As Education Finance Partners of New Mexico (a loan originator), I want to receive a CL4 file twice a month.
• As First National Bank of Central Texas (a loan originator), I want to receive a CL4 file with only updates made in the last 5 business days.

Split by Scheduling

Stories can be created based on schedules. For example, real-time processing versus end-of-day processing.

• As Aggieland Credit Union, I want to receive a CL4 file between 8:00 p.m. CST and 8:30 p.m. CST.

“Post-Office” stories that deal with routing and file transfers could be another batch of stories.

Order of Stories

Even with this splitting-up of stories it is critical that the team select stories wisely. Remember that you want to: deliver quick increments of value and exercise the system end-to-end as soon as possible.

Stories selected should attempt to build threads through the system; don’t tackle all the file generation stories, then all the validation stories, then all the dissemination stories. Instead, choose a file type and record type and try to build that one through. Don’t worry about alternatives initially; just get the happy-path done quickly. Implement the alternate paths next to make the functionality robust.

What Not to Do

Do not split along process lines.

1. Design the thing
2. Code it
3. Write unit tests
4. Write acceptance tests
5. Document the design and implementation details

This doesn’t work very well as none of the five items produces value by themselves.

Don’t split across architectural lines either.

1. Design
2. Code the UI
3. Implement the business logic
4. Implement the data layer
5. Write acceptance tests
6. Document the design and implementation details

The items by themselves don’t provide value and like waterfall projects, integration is pushed to the end instead of attempting it earlier.

Helpful Tools and Additional Information

Irrespective of how the stories were created, the teams in this case very quickly realized that use of a tool like Fitnesse was crucial. It allowed the teams to mock up files and records that they could develop against and use for automated functional testing.

• Unlike requirements captured in large formal documents, Fitnesse based requirements are executable.
• Execution results are concrete — tests either pass or fail, thereby providing a true indicator of feature and project status.
• Tests can be used as a starting discussion point for iteration planning — tests are demonstrable.
• Fitnesse provided independence from a database
• Database state changes can make testing difficult — testers must revert to the initial state of the database after changes.
• Testing hard to find situations (in real-time databases) becomes easier as data is manually setup.
• Executing hundreds and thousands of tests can become slow if accessing data from a database. This makes quick feedback, which is highly desirable, impossible.
• Processes can be tested via workflow tests

Good places to get additional information are Craig Larman’s, “Applying UML and Patterns” for a discussion on actors and their goals and Mike Cohn’s, “User Stories Applied” for guidance on writing good user stories. Fitnesse related information can be obtained from Rick Mugridge and Ward Cunningham’s “Fit for Developing Software: Framework for Integrated Tests” and from http://www.fitnesse.org/ and http://fitnesse.info/start.

]]> http://www.bigvisible.com/2008/04/determining-actors-and-defining-back-end-stories/feed/ 1 http://www.bigvisible.com/2008/04/hiring-the-right-people/ http://www.bigvisible.com/2008/04/hiring-the-right-people/#comments Thu, 10 Apr 2008 16:13:22 +0000 Alex Singh http://www.bigvisible.com/asingh/hiring-the-right-people/ General Colin Powell in his Leadership Primer says that:

“Organization doesn’t really accomplish anything. Plans don’t accomplish anything, either. Theories of management don’t much matter. Endeavors succeed or fail because of the people involved. Only by attracting the best people will you accomplish great deeds.”

So, how do you attract and choose the best people to work in your organization? What are the qualities that you look for when hiring people – is it the length of their resume, their past positions, their degrees or where they obtained them? Is it their familiarity and expertise with the specific technology or domain that the company needs at the moment?

While I consider their ability to do the work required to be important, I weight factors other than technical knowledge far higher. Technical knowledge and ability to learn new related skills is a threshold trait that just gets them the interview.

What I am really looking for in a candidate are qualities like enthusiasm, drive, and motivation – remember the adage that the team is only as strong the least motivated individual. I look for people who accept responsibility to get things done and don’t waste their time bitching and moaning about others and the circumstances they were in. Ultimately, a person’s talent is immaterial if he doesn’t have the desire to get things done. Equally important is the person’s ability to execute and not just talk a great game; don’t assume that if someone can think and plan and sell their idea that they can also execute and deliver.

A willingness to do new things is critical – generalizing specialists are more versatile than specialists and can contribute in more areas. How often have you had to deal with people who think of themselves as one specific role (for example, I am an Architect and that’s what I do)? That sort of thinking is really counter to the Agile way. It reduces flexibility in scheduling projects, exacerbates the functional silo mentality, and encourages department managers to optimize their function often to the detriment of the whole. Keep in mind that a team members job is to get the product out the door not to do just development, or just testing, or just requirement gathering.
You also want to hire people who can organize and plan their work and then execute it properly. If you don’t pay attention to this you end up hiring people that require constant baby-sitting and you end up doing most of their work anyway. If they demonstrate good judgment and an ability to anticipate problems so much the better.
Last but not least, look for people who are able to collaborate and work closely with others. I don’t want “team players” who just go along with everyone; I like people who are willing to express their opinions and disagreements but who also have an open mind to take in new information and reconsider their position if need be.

People with the right attitude are far more productive and easier to work with than prima donnas who just excel in one narrow activity. People with the right attitude can pick up additional skills fairly easily; training someone without these skills is far harder.
Ask the candidate to describe the accomplishment that they are most proud about. Then ask probing questions and listen for clues to the above in their responses. Also, ask what they would do once they got the job; their responses will let you know whether they have thought out a plan and how they would execute once on the job.