Great video shared by Robin Dymond:
Great video shared by Robin Dymond:
The Real Agility Program is an Enterprise Agile change program to help organizations develop high-performance teams, deliver amazing products, dramatically improve time to market and quality, and create work environments that are awesome for employees.
This article is a written summary of the Executive Briefing presentation available upon request from the Real Agility Program web site. If you obtain the executive briefing, you can follow along with the article below and use it to present Real Agility to your enterprise stakeholders.
At Berteig Consulting we have been working for 10 years to learn how to help organizations transform people, process and culture. The problem is simple to state: there is a huge amount of opportunity waste and process waste in most normal enterprise-scale organizations. If you have more than a couple hundred people in your organization, this almost certainly affects you.
We like to call this problem “the Bureaucratic Beast”. The Bureaucratic Beast is a self-serving monster that seems to grow and grow and grow. As it grows, this Beast makes it progressively more difficult for business leaders to innovate, respond to changes in the market, satisfy existing customers, and retain great employees.
Real Agility, a system to tame the Bureaucratic Beast, comes from our experience working with numerous enterprise Agile adoptions. This experience, in turn, rests on the shoulders of giants like John Kotter (“Leading Change”), Edgar Schein (“The Corporate Culture Survival Guide”), Jim Collins (“Good to Great” and “Built to Last”), Mary Poppendieck (“Lean Software Development”) Jon Katzenbach (“The Wisdom of Teams”) and Frederick Brooks (“The Mythical Man-Month”). Real Agility is designed to tame all the behaviours of the Bureaucratic Beast: inefficiency, dis-engaged staff, poor quality and slow time-to-market.
Studies have proven that Agile methods work in IT. In 2012, the Standish Group observed that 42% of Agile projects succeed vs. just 14% of projects done with traditional “Bureaucratic Beast” methods. Agile and associated techniques aren’t just for IT. There is growing use of these same techniques in non-technoogy environments such as marketing, operations, sales, education, healthcare, and even heavy industry like mining.
Real Agility Basics: Agile + Lean
Real Agility is a combination of Agile and Lean; both systems used harmoniously throughout an enterprise. Real Agility affects delivery processes by taking long-term goals and dividing them into short cycles of work that deliver valuable results rapidly while providing fast feedback on scope, quality and most importantly value. Real Agility affects management processes by finding and eliminating wasteful activities with a system view. And Real Agility affects human resources (people!) by creating “Delivery Teams” which have clear goals, are composed of multi-skilled people who self-organize, and are stable in membership over long periods of time.
There are lots of radical differences between Real Agility and traditional management (that led to the Bureaucratic Beast in the first place). Real Agility prioritizes work by value instead of critical path, encourages self-organizing instead of command-and-control management, a team focus instead of project focus, evolving requirements instead of frozen requirements, skills-based interactions instead of roles-based interaction, continuous learning instead of crisis management, and many others.
Real Agility is built on a rich Agile and Lean ecosystem of values, principles and tools. Examples include the Agile Manifesto, the “Stop the Line” practice, various retrospective techniques, methods and frameworks such as Scrum and OpenAgile, and various thinking tools compatible with the Agile – Lean ecosystem such as those developed by Edward de Bono (“Lateral Thinking”) and Genrich Altshuller (“TRIZ”).
Real Agility acknowledges that there are various approaches to Agile adoption at the enterprise level: Ad Hoc (not usually successful – Nortel tried this), Grassroots (e.g. Yahoo!), Pragmatic (SAFe and DAD fall into this category), Transformative (the best balance of speed of change and risk reduction – this is where the Real Agility Program falls), and Big-Bang (only used in situations of true desperation).
Why Choose Transformative?
One way to think about these five approaches to Agile adoption is to compare the magnitude of actual business results. This is certainly the all-important bottom line. But most businesses also consider risk (or certainty of results). Ad-Hoc approaches to Agile adoption have poor business results and a very high level of risk. Big-Bang approaches (changing a whole enterprise to Agile literally over night) often have truly stunning business results, but are also extremely high risk. Grassroots, where leaders give staff a great deal of choice about how and when to adopt Agile, is a bit better in that the risk is lower, but the business results often take quite a while to manifest themselves. Pragmatic approaches tend to be very low risk because they often accommodate the Bureaucratic Beast, but that also limits their business results to merely “good” and not great. Transformative approaches which systematically address organizational culture are just a bit riskier than Pragmatic approaches, but the business results are generally outstanding.
More specifically, Pragmatic approaches such as SAFe (Scaled Agile Framework) are popular because they are designed to fit in with existing middle management structures (where the Bureaucratic Beast is most often found). As a result, there is slow incremental change that typically has to be driven top-down from leadership. Initial results are good, but modest. And the long term? These techniques haven’t been around long enough to know, but in theory it will take a long time to get to full organizational Agility. Bottom line is that Pragmatic approaches are low risk but the results are modest.
Transformative approaches such as the Real Agility Program (there are others too) are less popular because there is significantly more disruption: the Bureaucratic Beast has to be completely tamed to serve a new master: business leadership! Transformative approaches require top-to-bottom organizational and structural change. They include a change in power relationships to allow for grassroots-driven change that is empowered by servant leaders. Transformative approaches are moderate in some ways: they are systematic and they don’t require all change to be done overnight. Nevertheless, often great business results are obtained relatively quickly. There is a moderate risk that the change won’t deliver the great results, but that moderate risk is usually worth taking.
Regardless of adoption strategy (Transformative or otherwise) there are a few critical success factors. Truthfulness is the foundation because without it, it is impossible to see the whole picture including organizational culture. And love is the strongest driver of change because cultural and behavioural change requires emotional commitment on the part of everyone.
Culture change is often challenging. There are unexpected problems. Two steps forward are often followed by one step back. Some roadblocks to culture change will be surprisingly persistent. Leaders need patience and persistence… and a systematic change program.
The Real Agility Program
The Real Agility Program has four tracks or lines of action (links take you to the Real Agility Program web site):
Structurally an enterprise using Real Agility is organized into Delivery Groups. A Delivery Group is composed of one or more Delivery Teams (up to 150 people) who work together to produce business results. Key roles include a Business leader, a People leader and a Technology leader all of whom become Real Agility Coaches and take the place of traditional functional management. As well, coordination across multiple Delivery Teams within a Delivery Group is done using an organized list of “Value Drivers” maintained by the Business leader and a supporting Business Leadership Group. Cross-team support is handled by a People and Technology Support Group co-led by the People and Technology leaders. Depending on need there may also be a number of communities of practice for Delivery Team members to help spread learning.
At an organizational or enterprise level, the Leadership Team includes top executives from business, finance, technology, HR, operations and any other critical parts of the organization. This Leadership Team communicates the importance of the changes that the Delivery Groups are going through. They lead by example using techniques from Real Agility to execute organizational changes. And, of course, they manage the accountability of the various Delivery Groups throughout the enterprise.
The results of using the Real Agility Program are usually exceptional. Typical results include:
Of course, these results depend on baseline measures and that key risk factors are properly managed by the Leadership Team.
Not every organization needs (or is ready for) the Real Agility Program. Your organization is likely a good candidate if three or more of the following problems are true for your organization:
Consider that list carefully and if you feel like you have enough of the above problems, please contact us at firstname.lastname@example.org. or read more about the Real Agility Program for Enterprise Agility on the website.
We have already written about how Leadership and Delivery Teams operate in a Real Agility Program. It’s time to look at our Recommendations component: getting started on the right path for Real Agility.
Recommendations = Assessment + Playbook
In the assessment portion of the Recommendations component, we gather information about the current situation at an organization. This includes everything from detailed practices, processes and tools, to strategies and organizational culture. This assessment work is designed to help everyone understand the organization’s current gaps, and what strengths it has that will best support it to cross those gaps to Real Agility. The Assessment includes an online portion, an on-site portion and an off-site portion. The assessment work naturally leads to the development of the playbook.
The online assessment requires that each person throughout an organization complete an online survey about corporate culture. It includes three major sections: existing challenges, sense of urgency, and level of teamwork. This cultural survey is the foundation of understanding how to be successful with Real Agility. Managers and leaders are also asked to complete an additional questionnaire about the current environment at the organization. This includes high-level information about the structure of the organization, client and vendor relationships, and staff. Additional surveys may also be administered to understand other aspects of the organization. For example, in an organization that is struggling to use Scrum, we will often use the Scrum Team Assessment.
The onsite portion of the assessment combines in-person interviews and workshops with staff and managers. Interviews explore aspects of the corporate work environment in more depth and include questions about familiarity with Agile methods, and obstacles that people might see to adopting Agile. The workshops gather data around current challenges and strengths, success criteria for projects, situational analysis for teams, and existing metrics (or lack thereof). Typically we need a meeting room committed to our consultants for doing interviews.
The offsite portion of the assessment is used for us to evaluate and analyze the survey, interview and workshop results. We also use some time to review any relevant documentation such as process templates, org charts, governance requirements, etc. We may also use some of this time for follow-up phone calls or emails to clarify aspects of the assessment results. Finally, this offsite work is also where we do the bulk of the development of the recommendations in the playbook.
Several aspects of our assessment are based on the OpenAgile Catalyst Assessment Tools which are open-source and can be found online. We also have a number of proprietary tools.
The playbook maps out a path to a successful Real Agility transformation. It is a road map that helps leaders, managers and team members make good business decisions as they strive for Real Agility. The playbook aids the organization to effectively and appropriately launch Real Agility teams: management teams, project teams, and operational teams. The Real Agility Program playbook includes analysis of the assessment results, recommendations for work that the organization can do on its own and suggests outside assistance that enhances Real Agility results. Two critical questions that are answered in the Playbook include:
We deliver the recommendations in the form of the playbook and an executive summary slide deck in an iterative and incremental fashion so that stakeholders can give us early feedback and so that we can adapt our assessment agenda as we go along. The recommendations include ideas about organizational structure, staffing, governance changes, departmental relationships, tooling, and many other aspects of how an enterprise can best become and Agile enterprise.
Following the Recommendations in the Real Agility Program playbook results in huge time-to-market improvements, 200% (or better) productivity boost for delivery teams, and extremely satisfied customers and staff.
In a recent post, Mishkin outlined the Leadership Team component of the Real Agility Program. While the Leadership Team track focuses on developing leadership capacity for sustained transformation, The Execution track focuses on launching and developing high-performance project, product and operational teams. This track is the one that most of our clients use when they run Agile pilot programs and is a critical component of getting quick wins for the organization.
Groundbreaking works such as The Wisdom of Teams (Katzenbach & Smith), The Five Dysfunctions of a Team (Lencioni) and Drive (Pink) have served well to distill the essential requirements of high-performance teams. Scrum, Kanban, and OpenAgile are proven frameworks that optimize the value of teams and create the necessary working agreements to help teams reach that high-performance state.
The Delivery Team track of the Real Agility Program creates new, cross-functional, multi-skilled, staff-level teams of willing individuals. These teams are responsible for delivering value—business results and quality. Individuals are committed to the performance of the team and the organization. Teams develop the capacity to self-organize and focus on continuous improvement and learning. A team is usually composed of people from various roles at the delivery level. For example, and IT project team might be composed of people whose previous* roles were:
* These roles do not get carried into the new delivery team other than as a set of skills.
The track begins with establishing pre-conditions for success including executive sponsorship, availability of team members and management support. Team launch involves a series of on-the-job team development workshops designed to enable the teams to create their own set of values, working agreements and high-performance goals. Teams are guided in the creation of their initial work backlogs, defining “done”, estimation and planning and self-awareness through the use of a collaborative skills matrix. The teams are also assisted in setting up collocated team rooms and other tools to optimize communication and productivity.
Qualified coaches assist the teams to overcome common issues such as personal commitment, initial discomfort with physical colocation, communication challenges of working with new people in a new way, management interference and disruptions and appropriate allocation of authority. This assistance is delivered on a regular schedule as the team progresses through a series of steps in the Execution track process. Usually, these steps take one or two weeks each, but sometimes they take longer. A team that needs to get to a high-performance state quickly might go through the entire program in 10 or 12 weeks. In an organization where there is not the same urgency, it can take up to a year to get through the steps of the track.
The coaches for this Execution track also help management to resist and overcome the strong urge to manage the problems of the teams for them. In order to develop through the stages of team development, teams need to be effectively guided and encouraged to solve their own problems and chart their own courses towards high-performance.
The goal of the Execution track of the Real Agility Program is to help the team go through the stages of forming-storming-norming and set them up to succeed in becoming a high-performance team. Of course, to do this requires some investment of time. Although the Execution track is meant to be done as on-the-job coaching, there is a 5% to 20% level of overhead related to the Real Agility Program materials themselves.
See also the article on the Recommendations component of the Real Agility Program.
In his book “Crossing the Chasm“, Geoffrey Moore describes the difficulty of creating a popular new product due to a conceptual “chasm” between the first people who adopt a new product and those who come later. He describes five types of people in relation to how they adopt new products:
This product adoption behavior also applies to new ideas in general, and of course, to Agile Transformation [Agile Transformation vs. Agile Adoption] in particular.
Implications of the “Chasm” Model
An organization attempting to do an Agile Transformation [Kotter’s 8-Step Change Model] should understand how to use this model to ensure long-term success. This diagram illustrates the concepts (click on it to see it full size):
First, the organization should start the transformation by finding the innovators and early adopters. These people can then be recruited to run the initial pilot projects. They will be enthusiastic and will typically adapt themselves to the new behaviors and thinking patterns required by Agility. If they are properly supported by managers, they will also be successful – at least within the bounds of a limited pilot environment. Success here will mean that the pilot projects deliver value, use feedback effectively, and the participants (team members and stakeholders) will be happy with the results.
In this stage, it is best to avoid putting people on the teams who are from the early majority, late majority or laggards groups. These people will tend to drag on the results of the pilot projects. This is a common mistake in running a pilot program and leads to discouraging results. One way to help filter between these two groups is simply to ask for volunteers for the pilot projects. Innovators and early adopters will be much more likely to volunteer for a new initiative.
After the pilot projects have shown some good results, the next step is to go the general roll-out. In this step, you are now working with the early and late majority. These people need much more substantial support for a change of this nature. They will require intensive training, and hand-holding in the form of coaching and mentoring. This hand-holding can come partially from your innovators and early adopters. Some of the participants in the pilot projects will have the desire to share their success. From these, you need to carefully select and prepare a few who will act as internal coaches. If you are a small organization or if you wish to do your transformation quickly, you will likely need to hire coaches from outside your organization as well.
The early and late majority require evidence of benefits and reassurance that risks are minimal or can be mitigated. This evidence partially comes from your pilot projects. However, this may not be sufficient. There are two other important sources of evidence for this group: the leadership team and external experts.
The leadership team must be committed to the change to agility and can demonstrate this commitment by doing their own management work as an agile team. The exact details of the agile process do not need to be identical to that of the staff teams, but it should be recognizably similar. As well, this “Agile Transformation Team” must make itself very visible during the general roll-out. This can be done with communication and by taking up visible residence in a central conference room or bullpen. As well, this Agile Transformation Team must work diligently to remove obstacles that are raised by staff teams during the general roll-out.
The second source of evidence comes from external sources. Published case studies are one valuable source. However, there is a huge value in a visible management investment in external support from recognized experts. This can be in the form of training, coaching, consulting as well as informal “lunch-and-learn” meetings, town hall meetings and the like. When engaging experts, it is imperative that the Agile Transformation Team act on their advice otherwise the early and late majority will take that as a sign of hypocrisy.
The final stage of a roll-out is to deal with the laggards. For the most part this is a do-or-die proposition for these people. Either get with the program and engage like a committed employee or leave the organization. If your organization is large enough, you will likely have observed some of these people leaving the organization in the general roll-out.
For some organizations, this transformation process can take many years. An organization with thousands of people should expect to be working on the pilot projects for at least a year, the general roll-out for at least three years. Often it will be longer. Good luck on your agile transformation effort!
Cross-posted from the personal blog of David D. Parker: A Changemaker in the Making
James Shore wrote a great post about the problems he is seeing with agile adoptions that start with Scrum called the Decline and Fall of Agile. Please please please (pretty please) read it before you read what I am about to write here! I agree with what James is saying 100%.
Now, let’s hear the truth:
Scrum is really really hard! Doing Scrum well is like quitting a heavy, long addiction (I think). Don’t ever make the mistake that because Scrum is simple (lack of complexity) that it is somehow therefore easy (lack of effort).
Doing Scrum properly takes:
sacrifice – sacrifice of our ways of thinking, our habits, our comfort
wisdom – wisdom to see the small improvements while struggling with the humongeous ones
and most importantly,
truthfulness – honesty to see and say the truth, integrity to act on the truth, detachment to avoid believing in what you want instead of what is real, courage to continue even when things aren’t perfect or easy
Scrum depends heavily on commitment both at the small scale of an individual committing to a small piece of work, and at the large scale of an organization committing to real deep cultural change. Without that entire spectrum of commitment, it is unlikely that adopting Scrum will be anything but the latest fad imposed by management or done stealthily by staff.
But Scrum isn’t the only “agile” method. As James points out, the engineering practices of Extreme Programming such as pair programming, test driven development, continuous integration, evolutionary design and refactoring are all critical. Do they have to be done and perfected first? No. But eventually, if you are using Scrum to build software (not everyone is), they do have to be done.
As a Certified Scrum Trainer, I have always emphasized how Scrum is hard, and how being a ScrumMaster is very very very hard. This is why my training class is three days instead of two. This is why I don’t encourage anyone to come to it, only people who will be ScrumMasters. This is why after the first day of my course, most students are actually feeling quite discouraged!!! It takes three days minimum for people to understand and process the incredible shift in mental model. And of course, even after three days, it is oh so easy to revert back to our normal thinking habits.
So what should people do? Do Scrum by the book. Yes that means putting a whole team in a single room. Yes it means that you have to really remove obstacles, and fast! Yes that means that your teams actually have to be cross functional (and not just in the weak sense of multi-skilled developers). Yes that means that it – will – take – a – long – time – to – get – it – right!!!!
And please, it is so worth getting help beyond just the training! If you think that I’m just trying to promote my own coaching services, please go check out:
They all have great coaches and I would absolutely way rather see you succeed than believe that I am just trying to promote my own business.
(Parts of this posting were adapted from an email written by my business partner, Dale Kiefling)
We recently had the disconcerting experience of having a client cancel our engagement because they’d felt that we weren’t being agile enough. In hindsight there were a number of reasons why this might have happened but I think the most important one was simply that we did not provide a clear overview of the engagement. This meant that the client was confused about the value of what we were doing. I myself am confused about how the situation arose. I thought we had been very clear but obviously that was not the case.
Pete Behrens has an excellent outline with graphics of a quick overview presentation of agile that can be given to executives. The presentation focuses slightly on agile software development, but a similar presentation could be constructed for Agile Work in general.
A review of Tara J. Fenwick’s â€œLimits of the Learning Organization: A Critical Lookâ€ (article found in Learning for life: Canadian readings in adult education).
This article is a critique of learning organization literature (as presented in the works of Peters, Senge, Watkins, Marsick, Argyris, Schon and others). I chose to do a review of it because learning organization literature can and does inform the work of Agile practitioners. The writer, Tara Fenwick, offers a critique of this literature as an academic and practitioner in the field of adult education. Even though the language and tone of the article is judgmental and at times affronting to the corporate trainer audience, it is never-the-less challenging and valuable because she raises interesting ethical questions that can serve as cautions against potential trends that can distort agile practice. I will summarize her argument in the some of the areas most relevant to Agile practice.
Fenwick’s summary of the model of learning organization found in the literature, is an organization that: â€œcreates continuous learning opportunities, promotes inquiry and dialog, encourages collaboration and team learning, establishes systems to capture and share learning, empowers people toward collective vision and connects the organization to its environment.â€
The following is a summary list of some of Fenwick’s critiques:
Who’s Interests are Served
Although the learning organization literature holds great promise for a more humanitarian and egalitarian workplace, it has the potential to distort learning â€œinto a tool for competitive advantageâ€ and in turn, exploit people as resources in the pursuit of profit. To explore this idea she asks a valuable question: â€œWho’s interests are being served by the concept of learning organization, and what relations of power does it help to secure?â€ She argues that learning organization literature tends to serve the interests of educators working as trainers in organizations and managers interested in their own self preservation.
How Learning is Defined
Learning, in learning organization literature seems to be defined as that which benefits the organization, all other learning falls into the dysfunctional category. This perspective negates other ways that people create meaning and learn and potentially causes a person to become â€œalienated from their own meaning and block flourishing of this learning into something to benefit the community.â€
Assumptions about Learners
The learning organization literature subordinates employees by seeing them as â€œundifferentiated learners-in-deficitâ€. Educators and managers are the architects of the learning organization while employees are busy â€œlearning more, learning better and fasterâ€ trying to correct their knowledge deficit. In the learning organization workers become responsible for the health of the organization without the authority to determine alternative ways to reach that health. The fear of being left behind in a quickly changing market environment is used to create anxiety and fear as motivations for learning. All of these factors serve to put serious limits on the potential of people to learn in the work environment.
Diversity and Privilege Overlooked
Perspectives of race, class and gender -which research has shown affects the way people learn and collaborate- are lacking in the literature. Fenwick challenges the notion of achieving a democratically ideal situation for open dialog -that the learning organization literature calls for- when all people in the work place do not â€œhave equal opportunity to participate, reflect, and refute one anotherâ€ (for example because of the status of ones job, character, gender, class, age etc.)
Fenwick sheds a clear light on where the good philosophies of the learning organization are found wanting. The Agile community can benefit from asking some of the same ethical questions she asks in relation to our work. Her critique is a good challenge for Agile practitioners. It challenges us to:
Reflecting on these issues will go a long way to contributing to the development of agile practice.
The full text of an old version of Fenwick’s article can be found here.
The following is my approach as an educator to my work in community and organizational development. I have come to this understanding mainly through experience, a great deal of mentoring and study.
Please note that when I use the term â€œteacherâ€ in this document I also mean consultant, mentor, coach etc. The term â€œstudentâ€ is also interchangeable with organization or community. The term education is interchangeable with organizational or community development consulting.
Validation: a starting point
Education should start from, affirm and validate the experience, insights and knowledge of the individual. This is a foundation for education that honours and respects the student. Recognizing the nobility of the student allows her an active role in her own learning. The role of the teacher is to facilitate learning by drawing on the experience of the student, to build on that experience through the acquisition of new insights, knowledge and skills.
Learning must be self-directed. The teacher may have a number of wonderful things to teach, but if the student does not believe that they are relevant to her, she will not be engaged. This is especially true for teachers who are working in communities that they are not a part of. The teacher must engage in careful investigation in order to understand the situation of the student, which includes attentive listening, as well as a genuine interest in the needs of the student, before proceeding along any line of instruction. Taking her cue from the students, the teacher must work with the individual / group to create a learning environment in which everyone takes responsibility for their own learning. In this kind of environment the teacher is not an expert and does not do the studentsâ€™ learning for her. The teacher can use questions to assist the student to understand, instead of delivering answers. The teacher should also encourage an environment of learning that recognizes mistakes as part of the learning process. The learning environment should create in the student a hunger for the acquisition of knowledge, insights and skills beyond the direct experience with the teacher.
Encouragement: the key to self-directed learning
Once the experience of the student has been validated and her needs established, education should be challenging but not obtrusive and challenges must be presented with respect and encouragement. Encouragement versus excessive criticism leads to individual initiative instead of paralysis. The natural result of an encouraging and challenging learning environment is self-discipline and self-correction instead of external discipline (control) and constant external correction.
A transformative, holistic approach centred in humility and service
The learning environment should foster humility in both the student and teacher. Most contemporary approaches to education are materialistic; the student pays, studies, receives a degree, becomes an â€œexpertâ€, etc. The whole educational experience, from the teachers to administrators, cultivates in the student a sense of self is that is based solely on the expertise and knowledge gained. The â€œExpertâ€ attitude in the community development environment is often not useful because the work in the field is so complex. Many stakeholders have keys to the process, as a result, the â€œexpertâ€ attitude devalues the knowledge of others and tends to taint the path to solutions with conflict and ego. Another consequence of the expert mentality in the community is dependency; people are divorced from the solution to problems that they all contribute to and to which they all hold the keys. Instead of drawing on the knowledge of the stakeholders, the expert renders her own knowledge most valuable which in turn causes them to discard volition and succumb to a state of perpetual dependency on one expert after the other. Community members or institutions are robbed of the ability to play a central role in their own lives as a direct result of being robbed of opportunities to play central roles in the decision-making process of their community.
With humility at the centre of all learning, the purpose of education becomes transformation. We learn so that we, our communities and our institutions can improve and change for the better. Also as learning is applied to community efforts, individual capacity unfolds and is developed. Learning for its own sake is valuable, but learning for positive social change, makes the acquisition of knowledge, skills and insights relevant and engaging in the face of community development challenges. Learning then becomes intimately connected with action and is corrected and refined through action. This infuses a powerful sense of purpose and meaning in the learning process, especially as successes are realized.
Principle-based approach facilitates ownership
Education should cultivate a sense of personal ownership in the learning process and community life. Fostering a sense of personal ownership comes with educating students to have a mature perspective about their own learning as well as the changes they desire to implement in the community. It involves helping students learn the capability of â€˜becomingâ€™ the change that they want to see, as well as finding positive starting points in desperate situations and building on them. A mature outlook demands that students have a principle-based approach to problem solving versus a rule-based approach. Education then becomes not only a process of acquiring knowledge but centred on capacity building for individuals, institutions and groups. Fostering the development of capacities needed to overcome obstacles also requires a principle-based approach, embodying principles such as perseverance, human rights and dignity, building unity in diversity etc.
Integration and balance of methods essential
Education should be methodical and balanced. It should aim to acknowledge, validate and employ different learning paradigms: those of science, spirituality, culture and the arts. Systems of education that value science above the arts or spirituality are destructive to the individual and community as they create an imbalanced view of the world and rob people of a diversity of perspectives and tools that they need to face complex challenges. An educational program should strive to address the mental, emotional, spiritual and physical needs of students and not focus too much on merely one dimension of life. This is especially important in communities that have experienced extreme marginalization (colonization, oppression) where healing and wellness must play a significant role in the learning process.
A key ingredient to success in transformational education is the example of the educator. As people, naturally we do what we know and what we have experienced. In order to change our patterns of behavior we need to begin having fundamentally different experiences than what we have known. The educator must be able to assist in the creation of such experiences. To do this she must be capable of modelling what is being taught and through constant critical self-reflection strive to exemplify in every action empowering ideals.
Learning and education are indispensable to all community efforts for positive change. The job of an adult educator is to assist individuals, the community and its institutions to adopt a posture of learning. This begins with working with the experience of the student, fostering self-directed learning and follows as the teacher interacts with the student to challenge and assist her to new levels of learning. With humility at the centre of all learning efforts, dependency on â€œexpertsâ€ can be replaced with volition and independent decision-making. The potential of the individual further unfolds as she applies her learning to service to the community. Attention to capacity building and cultivating a sense of personal ownership -in the process of learning and community building- deepens the experience and truly engages the student in taking an active role in the development of her life. Utilizing all systems of learning in the education process ensures balance of methods and helps cultivate the infinite and diverse capabilities of human potential. Ultimately the success of an educator rests on the degree to which she is able to model the change she is fostering.
I’ve been working on developing a Agile Work Seminar to introduce teams to agile work. I’m using some Agile Work practices to develop it.
Iterative Delivery and Adaptive Planning
The seminar is going through drafts. Each draft will actually be delivered to a team. The first time through all the material was done at a small software consulting company five days ago. As a result of feedback from the people who participated, a revision will be made to the seminar… and then it will be delivered again (probably the next time will be in early September). This process allows me to refine the contents and presentation of the material.
Over time, I will be able to use Adaptive Planning to modify the contents and qualities of the seminar as circumstances change.
I have set up criteria for the presentation in the form of an outline and learning objectives. The outline describes the major topics that must be directly covered such as the Agile Axioms or Corporate Culture. I have also set up “soft goals” such as that the seminar must include theory, history, practice and criticism of Agile Work. My first iteration met the outline tests, but did not meet the soft tests explicitly. The next version will.
This is an easy one: the success of this project will be its acceptance in the marketplace by having teams willing to pay the price for this seminar and then recommending it to others.
The Other Practices
Because this is essentially a one-man job, the other practices such as Self-Organizing Team and Maximize Communication are not as applicable.
There is a fantastic article about software productivity: http://www.joelonsoftware.com/articles/HighNotes.html. I love Joel’s writing style, and this article in particular has important lessons for us all, regardless of our profession: find what you can be the best at, and do that. Interestingly enough this is part of the message of the book Good to Great but applied to a whole corporation. It also applies in the context of self-organizing teams: each individual should be able to find/learn in what way they can best contribute and do that more than they do other stuff.
1. Iterative Delivery is a specific way of managing queues of work. As such, rote work is generally better served by other applications of queuing theory.
2. There is one universal condition under which iterative delivery is awkward, if not inadvisable. If one’s horizon of predictability is longer than the size of a work package by some substantial amount (e.g. 2:1 ratio), it can be more natural to use queuing theory and a pull system to flow work through the team. The actual ratio between the horizon of predictability and work package size that is used to switch over to a queue system must be determined empirically in your own circumstances. This empirical analysis can be done using a regular process reflection meeting.