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/asingh/determining-actors-and-defining-back-end-stories/feed/ 1 http://www.bigvisible.com/asingh/hiring-the-right-people/ http://www.bigvisible.com/asingh/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.

• Schedule the end of iteration demonstrations for the next 6-12 months – highly visible deadlines prevent teams from over-engineering solutions.
• Hold team members collectively accountable for team performance and for fulfilling job responsibilities. When things do not get delivered it is the team that has failed – freeloaders or those who are completely unsuited for the job will usually not be tolerated by high performing teams for long.
• A team’s performance is limited by the least invested individual. Such people dampen everyone’s morale and it is essential to quickly counteract people who habitually over-promise, make excuses, reject responsibility, complain, and lack commitment. While some skepticism up-front is healthy, perpetual grousing is not. To counter this, it is essential to clearly define and communicate behavioral expectations up-front and the consequences of not changing (if any).
• Clearly define and communicate expectations for decision-making including span of control and scope. This is to ensure that the team is not waiting around to be told what to do next.
• Require teams to develop corrective action plans for performance that is not meeting goals.
• Set a good example by promptly responding to questions, concerns, and escalated problems. Clearly communicate time frames for follow-up and consistently follow-up within these time frames.
• Help team members separate facts from emotional baggage.
• Recognize individuals and teams that respond with urgency.
• Discuss Chris Avery’s Responsibility Process Model or Roger Conners’ Oz Principle early in the transition process and refer to either at appropriate junctures.

In the past two years, this client has moved from a crappy Agile implementation to doing Agile the right way to implementing a lean software development system. They have taken the concept of smaller batches, removal of waste, and continuous flow of value to heart.

A common problem in many organizations is that business often pushes projects into an IT organization faster than IT can complete projects. Some of those projects simply accumulate within the organization, become work in process, and slow down the system. To counter this problem, the business at this client ensures that they do not overfill the hopper and clog the system (IT).

It is all well and good to make sure that wasteful activities are being removed from the development process; it is another to make sure that the right projects are being worked on.

As part of the initial engagement, the Product Owners and I go through the complete wish list to determine the cost and benefit of each of the projects or enhancement requests. As an example, there were 55 line items in their 2008 Value Stream Analysis spreadsheet; most will never see the light of day as their relative ROI is poor compared to the others on the list.

Funding is asked for and approved based on the work done in this joint session. Only projects that meet a certain ROI threshold are approved. Project funding is denied if there are questions surrounding the ability to meet the targeted ROI. The benefits are evaluated 6-12 months after a project is delivered; shortfalls are analyzed in an effort to learn and to not repeat the same mistake.

The modus operandi is unlike that in most agile implementations that you see elsewhere. There are no iterations; instead, requirements in the form of stories are pulled by the team as they complete the stories that they have been working on. The Product Owners and I make sure that the backlog is always kept prioritized and that the top of the list is well thought out and defined.

The team is not collocated with the Product Owners — instead, most communication occurs via Skype and GoToMeeting. This actually works remarkably well for explaining the stories, clarifying issues, and demonstrating completed work.

Iteration planning is replaced by Skype and GoToMeeting sessions between the team and the Product Owners just prior to the start of that story. The team picks up a story or two from the top of the prioritized backlog and calls the Product Owners to discuss and ask for clarifications. The teams break up a larger story into smaller stories if necessary and begins test driven development.

Informal demos happen as the story is being worked on (and an interesting portion has been implemented) and when it is finished. There is no formal end-of-iteration demonstration. Feedback is incorporated immediately and the story re-demonstrated. Once the Product Owners are satisfied with the story, it is ready to be moved into the QA environment; promotions to Production happen every week.

The teams working for this client are significantly more productive than other comparable teams following the standard Agile way of developing in 2-week iterations. I think this increased productivity is due to the increased focus on a story or two at a time, quicker feedback and turnaround, minimization of in-iteration overhead, and continuous effort for removal of wasteful activities.

While this level of fluidity is more than what most new Agile teams can handle, they can still attempt to implement some of the practices that lead to a continuous flow of value. Story boards can provide a quick indication of and help regulate the amount of work in progress. Frequent demonstrations can speed up delivery and make the end-of-iteration demonstrations a breeze.

The Product Owners produced stories that followed the: “As an [actor], I have to do [action] to cause [effect] in order to achieve [business goal]” format. But this did little good for the team as they are not collocated and had a difficult time getting clarifications and details from the Product Owners. The result was significant in-iteration thrashing and a velocity that was close to negligible.

A “Come to Jesus” meeting, where being brutally honest about the observed behavior and its impact on the teams and on project progress, helped change the dynamics. Of course, losing the clients was a very real possibility but it was worthwhile taking the risk — we weren’t making any headway the way we were operating.

To reduce requirements churn, we decided that before the start of an iteration, candidate stories must meet the following criteria if they were to be scheduled for the upcoming iteration:

1. Stories defined in the Agile project management tool
2. Acceptance criteria specified
3. Fitnesse tests / executable requirements specified
4. UI design/storyboards completed
5. Applicable business rules listed and referenced or defined
6. Non-functional requirements specified
7. Assumptions and constraints specified
8. In/out of scope delineated
9. Test data / sample files provided

This level of upfront definition for a story before the start of an iteration is definitely an overkill in most situations. But Agile is all about “the art of the possible” to get the job done; it just made sense to go counter to an important Agile principle (customer collaboration and face-to-face conversations) to get things back on track.

What ultimately matters is a pragmatic outlook — sometimes you have to bend the rules or even break them to move forward. A good coach can guide you during these rare but crucial moments.

I work with a number of people who come from a RUP background and who claim that RUP is Agile because RUP calls for iterative development. While a cursory reading of RUP literature may show that the RUP framework doesn’t really mandate anything — it is a framework not a process — and leaves things up to the team and organization, it’s spirit couldn’t be further from Agile. I just have a hard time reconciling some of  the ideas behind RUP to Agile values and principles

Consider the following:

RUP is predictive and calls for component based architecture, use of use cases for specifying requirements, and UML as the language for specifying design.

While RUP proponents may claim that official RUP literature doesn’t really mandate that use cases are the only way to specifying requirements, every explanation, presentation, or book always depicts RUP as use case driven. They also contain diagrams that mention the percentage of the use case model that should be completed by the end of each phase of the RUP. Moreover, the official documentation cleary states that “The Rational Unified Process is a use-case-driven approach” and the entire set of documentation refers to use cases and the use case model — use cases play a major role in several of the critical process workflows.

RUP calls for iterative development within a waterfall process. It does not aim for frequent releases at the end of each iteration; releases are done at the end of a transition phase after cycling through the Inception, Elaboration, Construction, and Transition phases, each of which is composed of multiple iterations. It basis reeks of Waterfall development — gather requirements, design, implement, and transition to production.

RUP encourages granular division of labor where specialists hand off documents to one another at specific points in the process. Their roles depend on the quality of documentation to guide their work. Agile teams look for generalizing specialists and makes no distinction between roles. All team members are accountable for the product! RUP roles are accountable only for their portion of the process.

Agile teams are assigned to one project at a time and everyone is busy during an iteration. During RUP phases, what is one group of roles doing in the other phases? Are people multitasking and working on different projects at the same time?

XP requires TDD and Scrum encourages adherance to good engineering practices like those followed by XP; RUP doesn’t and is instead a mini waterfall.

Agile methods call for aggressive refactoring and the discovery of a final design; RUP calls for an initial candidate architecture, UML to elaborate use cases and other design artifacts that become the basis for construction.

RUP prioritizes based on risk; agile on business value, which is a function of scope, quality, cost, and time. Too often projects in companies that adopt RUP seem to have an architecture/IT focus; business value is rarely if ever mentioned. This is also evident from how the use cases are written; they have an IT slant to them and are rarely written from a user’s perspective.

RUP is silent on the active removal of roadblocks; agile is chiefly concerned with identifying and removing roadblocks whether created by the team, management, or the organization.

Companies that adopt RUP often have a number of related heavy-weight Rational/IBM tools. It seems like a discussion of tools is often a major topic for RUP speakers these days. Agile teams on the other hand like to travel light and use the simplest tools possible — whiteboards, sticky notes, index cards, agile models, etc.

So can we learn anything from RUP?

This is not to say that we cannot learn anything from RUP. An initial focus on architecture and risk identification and mitigation is a good strategy especially when the project involves a degree of novelty (new technologies, new domains) or when the team is not composed of Journeymen or higher (“The Seven Stages of Expertise in Software Engineering” by Meilir Page-Jones ). Far too often, I have seen Agile teams struggle with the implemented architecture iteration-after-iteration; a short initial focus on specifying a candidate architecture would have been beneficial in most situations. Most probably, if the team was composed of superstars I wouldn’t have seen this problem. But there aren’t too many teams of that nature that I have come across.

Use cases though maligned by some, and bastardized by others, have their place. There has been a recent trend by Agile teams and Product Owners to write smaller-and-smaller stories to fit into shorter-and-shorter iterations. The result has been over-fragmentation and a loss of unity and cohesion; it becomes difficult to quickly see how the pieces fit together and how the process flows together. Use cases (if written properly) help us see the forest for the trees (see Alistair Cockburn’s writings and Craig Larman’s POS example in “Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development” for good examples and principles to follow).

Considering risk and developing strategies for tackling them early is a smart idea. Spiking and implementing risky portions of the infrastructure and architure helps drive out risk early and prevents surprises later.

Modeling is a useful exercise if it doesn’t become an end to itself. Instead of UML, team members can gain much more insight by drawing simple, informal models on whiteboards (see Scott Ambler’s Agile Modeling Web site at http://www.agilemodeling.com/ for creating effective and light-weight models).

Employees were mandated to enter all tickets (work requests, enhancements, and bug fixes) into a requirement-tracking tool. All tickets were to track through each of the following phases.

• New: All new work requests (tickets) should be entered into the requirement-tracking tool by the business analysts or by the development teams. Tickets must be entered at least 91 days before a scheduled monthly release.
• Acknowledged: A service level agreement (SLA) mandated that the business must acknowledge tickets within 7 days of receipt of the ticket – 84 days prior to release. This 7-day period was used to triage the tickets to remove duplicates, close tickets if no action was going to be undertaken, and to prioritize the items.
• Accepted: The IS department is tasked by the business to analyze and estimate the tickets — target 63 days prior to release.
• Business Requirements: The business analysts were required to complete the business requirements 42 days prior to release.
• Committed: IS would commit to the tickets, 28 days prior to release, that it thought it could complete — create functional specifications, construct, unit test, and build within the release dates.
• IN/OUT List: Final date to decide whether tickets are going to be included in this release or not.
• Constructed: IS completes coding, unit testing, and delivering final build 14 days prior to release.
• Resolved: Business analysts complete all testing 7 days prior to release.
• Closed: Code merged into the production environment (“going live”) on implementation day; Business signs-off on the release within 5 days of implementation.

The goal of any development system is to deliver customer-defined value, effectively, and with a minimum of waste. Systems that deliver value more efficiently are preferable to those that deliver value in a relatively expensive manner. One of the greatest contributors to inefficiency, poor quality, and high costs is waste (activities that do not add value to the end user).

While the “glide plane” concept sounds good in theory, it suffers from a few major drawbacks:

1. The glide plane does little to eliminate wasteful activities that do not add value to the end user. At Freesurance, over the 96 day (2304 hour) glide plane cycle, value is added during only 10 business days (80 business hours) during construction. This evaluates to a best case scenario of approximately 3.5% of the available time being used for value add activities. In actuality, overall productivity is further degraded by excessive rework and multi-tasking. Ouch!
2. The glide plane ultimately leads to excess work in progress — too many requirements are being investigated, sized, designed, and implemented at the same time. Time is wasted on investigating requirements that are not committed to being delivered and on backing out, at the last possible moment, implemented requirements which no longer hold true (scrap and rework).
3. The overlapping nature of the glide plane deliverables ensures that team members are not working solely on the current iteration; their focus is diluted by having to wrap up the previous release and to begin actively planning for the next release.
4. Multiple streams of work means that any single stream disruption can disrupt all streams. Critical bugs introduced in an implemented release have to be fixed, tested, and redeployed into production, therby, cutting the time available to work on the current iteration.

1. Executive and Senior Management support and commitment
2. Team makeup
3. Front-line staff commitment
4. Degree of change being introduced

1. Executive and Senior Management SupportAt the start of an engagement, the most important determinant is the level of executive buy-in. Forming a judgment of their behavior, feelings, and real motives is easier said than done. All too often, the real motives and underlying political issues remain unstated; it is up to the change agent to quickly determine who is for and against the initiative and why. Some managers may be for the initiative but for the wrong reasons — a CIO at a previous client was interested in the change not to improve the division, but to earn brownie points with a key internal customer.Often times, an organization introduces change (Agile methodologies in this example) but does not change the way it evaluates and rewards performance. The cliche, “you get what you measure” is absolutely true. For example, all Agile methods depend to a large degree on teamwork; this can be easily undermined if the senior managers cherry-pick and reward their favorites during the annual evaluation cycle or if management decisions are made not with the ultimate product but with the functional roles in mind.

A leading provider of strategic HR, payroll, and talent management solutions, in Florida, has successfully done away with individual rewards —- teams are rewarded based on their performance.

The goodness of Agile methods is that they quickly spotlight major problems in the way the organization is structured and managed. Executives and senior managers then have the option of either fixing the underlying problem or ignoring the problem — switching off the spotlight — and hoping it will go away. Their actions when faced with such situations speak louder than their words.

“The influence of wabi sabi on creativity begins with a simple premise: Do only what is necessary to convey what is essential. In bonsai and in haiku, you prune and trim what is nonessential in an attempt to shorten the distance between the observer and the observed. You carefully eliminate elements that distract from the essential whole, elements that obstruct and obscure….Clutter, bulk, and erudition confuse perception and stifle comprehension, whereas simplicity allows clear and direct attention.”

This is harder than it sounds — people frequently confuse the concepts of complicated and complex (Glouberman and Zimmerman). Instead of trying to clarify the complex (by using pictures, stories, anectodes, graphs, etc.) they try to simplify it and, in the process, often lose the inherent nuances and interdynamics. They oversimplify and their end product/explanation barely does justice to the original complex system. This same problem exists in the realm of Agile coaching and transformation. Companies often start an Agile transformation effort based on a simplified explanation and then are usually surprised when things don’t pan out.

Complicated problems contain subsets of simple problems but are not merely reducible to them. Their complicated nature is often related not only to the scale of a problem like open heart surgery, but also to issues of coordination or specialised expertise. Complicated problems, although their solutions are generalizable, are not simply an assembly of simple components.