Why smart people defend bad ideas by Scott Berkun looks at a fascinating, and fairly common, problem. Interestingly, this problem of smart people doing dumb things / defending bad ideas, is often related to perception. Agile principles and practices are about aligning perception among all the stakeholders, and in particular, between an execution team and the rest of the stakeholders. By aligning perception, the best environment is created for doing the right thing. In the case of a business, your project teams are the experts in “how” to do stuff, and your business teams are the experts in “why” to do stuff. This combination of “how” and “why” is done as efficiently as possible using agile work methods.
Our effectiveness as creators depends greatly on our knowledge and our skills. Less obviously, our effectiveness as creators also depends on our emotional and mental state, and even what some would call our spiritual state. Finally, our ability to create can be greatly magnified or greatly reduced by our environment, particularly the other people who are around us. Which is interesting, because our creative nature affects our environment.
Our senses and the devices we create to extend our senses, are filters through which we perceive reality. We don’t get to sense all of reality. Then, our minds take in the streams of information from our senses, and filter them further. Our attention or focus, our preconceptions, our mood, all determine the way we filter information from our senses. If we are feeling guilty, we may be more likely to hear other peoples’ conversation as criticism. If we are feeling proud, we may be more likely to hear those same conversations as praise.
If our perceptions are wrong then no amount of logical excellence will give the right answer. So it is a pity that almost the whole of our traditional intellectual effort has been directed at logic and so little at perception.
Experienced, smart individuals who work together effectively will always perform better than junior untalented people thrown together at random. The experienced effective group will build its own tools and create its own processes. The random junior group will be unable to effectively utilize tools given to them, nor will they be able to effectively follow a process.
When a team needs improvement, don’t impose a process or throw tools at them. Instead, concentrate on improving the team and the individuals within it. Technical, personal and team training and coaching will always be time and money well-spent. Spending money on processes and tools before an excellent team is in place can be very risky and wasteful.
Individualism and competition have no place in an agile work environment. Instead, the agile environment supports and fosters teamwork, collaboration and consultation. In turn, teamwork, collaboration and consultation depend on trust and truthfulness. “Truthfulness is the foundation of all human virtues.”
Nevertheless, processes and tools still have some importance. Great people with a great flexible process and great flexible tools will be hyper-productive. A junior group may need training on tools that will help them be more productive. Just be sure to never let processes and tools get in the way of the team.
In many ways, improving people is a sufficient practice for agile work. All the other principles, disciplines and practices would eventually arise out of this one practice. However, the depth of individual and group improvement needed for this practice to stand on its own is very great. Therefore we make the other principles, disciplines and practices explicit.
As the change team works on the ideal state and the present state [of the corporate culture], it probably has to periodically redefine the change problem in terms of the gap or gaps identified. In other words, though the process is a set of steps undertaken in sequence, there are many feedback loops that force going back to earlier steps to guarantee clear thinking. . . .
As various gaps are identified in concrete form, it becomes apparent where cultural assumptions aid or hinder the change agenda. For example, having sales teams work together on big accounts may sound simple until it is discovered that the organization’s individualistic culture prevents changing the incentive system to a group-based compensation program. The change program then has to shift to examining how to change some of the individualistic assumptions; this might entail an entirely new change program not previously thought about at all.
In other words, expect and embrace changes in understanding brought about by learning from work performed. Deliver corporate culture change work iteratively. Plan corporate change adaptively.
People are creators: we willfully change our environment, we imagine new things and through our actions, manifest those things in the world. All people do this. Human beings enjoy having an effect on their environment and seeing the results of that effect. We all have this ability. We all derive satisfaction from the exercise of this ability. And we can all learn to improve this ability.
In any endeavor we take on, we are attempting to create something new. A new system, a new object, a new pattern of behavior, or a new way of thinking. We are attempting to create change. This is one of three fundamental axioms of Agile Work.
Waste can be of several different types. Independent of what the types of wastes are, they can also come from different sources. When attempting agile work, it is essential to identify the underlying causes or sources of waste. Once these sources are identified, efforts can be made to change them so that they cause less waste.
In an agile environment, all work done needs to be directly related to the needs of stakeholders. Stakeholders request or “pull” work from the team, and they do this by defining prioritized work packages. The team needs some way to know when they have completed a work package, so both work packages and iteration tasks need to have testable acceptance or success criteria. The team collaborates with the stakeholders to determine what needs to be done to successfully complete a work package.
I heard a story about a situation where someone was refused career advancement because she had made an enemy a long time ago.
Can be found here. It is very bare-bones and will eventually be fleshed out. Presents the outline of the basic axioms, disciplines and practices of working agile. Please feel free to contribute.
Work can often be divided up so that the smaller pieces are valuable on their own. By dividing work this way, a team can deliver value incrementally. The team can choose a short period of time called an iteration and select a small amount of work to complete in that time. This work should be valuable on its own. For example, if a team is building something, then at the end of each iteration whatever is built is usable as it is. This means that each iteration includes all the planning and design as well as construction or creation necessary to deliver a final product or result.
For example, a volunteer group may desire to attract new members. A non-agile approach would have the group plan their membership campaign completely before actually executing on it. An agile approach using iterative delivery would have the group plan a small piece of work that will attract some small number of new members, execute it, and then start a new iteration. One iteration may cover the creation of and delivery of a door-to-door flyer in a neighborhood. Another iteration may cover the design, creation and publishing of a small advertisement in a local newspaper. Each iteration includes all the steps necessary to produce a furthering of the group’s goal of attracting new members.
In a business environment, iterative delivery allows for a much faster return on investment. The following diagram compares delivering value iteratively with a non-agile project delivery where results are delivered only at the end of the project:
One can see clearly from the diagrams that the non-agile delivery of value at the end of a project is also extremely risk prone and suseptible to change. If the project is cancelled just before it delivers, then a fairly substantial amount of effort is wasted. In the agile iterative delivery situation, an endeavor can be cancelled at almost any time and it is likely that substantial value has already been delivered.
Even if the work cannot actually be delivered incrementally, it almost always can be divided in a way so that it can be inspected in stages. Either method of dividing work allows us to do the work in iterations.
Iterations are fixed and consistent units of time during which work is performed and between which planning, inspection and adjustment is done. The empowered team will decide on the length of iterations for their work. As a rule of thumb iterations should be shorter than the horizon of predictability. Generally, iterations should never be longer than one month, no matter what the endeavor.
At the end of each iteration, a demonstration of the work completed is given to the stakeholders in order to amplify learning and feedback. Between iterations, the stakeholders collaborate with the team to prioritize the remaining work and choose what will be worked on during the next iteration. During the iteration, the stakeholders need to be accessible for questions and clarifications.
Iterative and incremental delivery is used to allow for the early discovery and correction of mistakes and the incorporation of learning and feedback while at the same time delivering value early.
Truck Factor (definition): “The number of people on your team who have to be hit with a truck before the project is in serious trouble”
In a previous entry about constant change, the idea of a horizon of predictability was introduced. This concept, along with the agile discipline of amplifying learning, suggest a strategy for addressing problems in a project.
Just a link to the Self Organizing System FAQ – glanced through it, it looks amazing.