Someone recently said to me that I should offer individual coaching assistance to people based on Agile Work. This would be completely non-technical life/profession style coaching. It’s an interesting idea. I don’t think I’m quite ready for it, but here are a few links to coaching, life improvement, and related things.
Given the huge interest in the article by Dmitri Zimine about context switching, and despite a couple of good articles about how to determine iteration length, there has been no empirical method described, only reasoning processes. This article describes a simple method to quickly determine iteration length by experimental means.
Recently, Dimitri Zimine wrote an excellent little story about context switching. Joel Spolsky writes in “From the ‘You Call this Agile’ Department“:
Dmitri is only looking at one side of the cost/benefit equation. He’s laid out a very convincing argument why Sarah should not interrupt her carefully planned two week iteration, but he hasn’t even mentioned arguments for the other side: the important sale that will be lost.
Okay… I’ll bite.
I have now trained over one hundred people in my Agile Project Managmenet / ScrumMaster Certification course. I’m starting to see and hear some of the results of this training. There are a couple specific “smells” that I have become aware of.
Starting off on the right foot is just as important as it ever was. However, with Agile Work, this takes on a significantly different meaning than it does in other methods as the emphasis of what is “right” is also significantly different. This is a short guide on how to successfully launch a team using Agile Work.
Today I had a very interesting and unique opportunity. I went through my agile project management training materials with a single individual instead of a class. Was it training, or was it coaching?
On the Retrospectives Yahoo Group, Michael Webb posted a link to his article Eight Barriers to Effective Listening. This article provides practical advice on how to improve communication. Since one of the basic practices of Agile Work is to maximize communication, this article is essential reading!
Sometimes an agile team is innundated (or maybe just slightly distracted) by requests for individuals on the team to do work for people or groups outside the team’s official stakeholders. This can happen, for example, in a corporate culture that promotes the exchange of favors. This past weekend at our Agile Coach’s gathering, Deborah Hartmann shared her method of detecting, exposing and discouraging this unofficial work.
The coach’s gathering last weekend also got me thinking about the ethics of Agile Work and coaching. Is it okay to use agile methods for destructive purposes?
In Jean Tabaka’s new book, “Collaboration Explained : Facilitation Skills for Software Project Leaders
There are a few times that I have been involved with implementing agile pratices without management knowledge or direct support. In these cases it has usually been necessary to gradually introduce the practices. An unsupportive or apathetic environment cannot be changed instantly and big-bang introduction of agile tends to bring too much negative attention too quickly.
In reflecting on those experiences, as well as “normal” agile implementations, I have felt that there are some specific practices that can stand alone.
Self-Organizing Teams
The practice of a self-organizing team consists of frequent regular status meetings, face-to-face, reporting to the other team members accomplishments, work commitments and obstacles. Scrum has a very strict method of doing this on a daily basis but I have found it valuable to do more or less frequently depending on the team and its environment (generally any less than every second day is not enough). The team, or some assistant of some sort, tracks the barriers and works to resolve them quickly. Management, if it exists, must be contacted through trusted channels to assist with the removal of barriers. And stakeholders must be able to attend the status meetings or receive reports immediately after the meetings.
This single practice tends to have the ability to bootstrap the others. The identification and clearing of barriers provides a way for the team to practice all three Agile Work Disciplines (Empower the Team, Amplify Learning, Eliminate Waste). Reporting accomplishments to the other team members Amplifies Learning. Committing to work is empowering.
Some teams have done only this single agile practice and seen great improvements in productivity, morale, and stakeholder satisfaction. However, there are some pitfalls that must be acknowledged and dealt with.
Pitfall: Speculative Work
The team can tend towards speculative work if there is no strong representative of the stakeholders. This does not always happen since most people are sincere in their desire to “make a difference”. However, if as a team you adopt only this practice and find yourselves doing lots of “what-if?” or “wouldn’t it be neet if…” or “what exactly is our purpose?” discussions, then you need to find some external stakeholder support for your effort.
Pitfall: Failing to Deliver
In many organizations, failure to deliver is an endemic problem and a self-organizing team will break through and start delivering. However, failure to deliver can also become a cultural mindset for an organization or group. A self-organizing team must maintain a goal (not a plan) for itself, and that goal must include delivering something valuable. Again, finding an external stakeholder to support the team’s efforts can help to avoid this pitfall.
Pitfall: No Barriers
Sometimes a team will get into a habit where no new barriers are being exposed. This can often happen when the progress in the work becomes steady and is recognizably better than it was before. The team falls into a “local optimum”. In this case, the team needs a fresh way to view their work. This can happen in a number of ways: a crisis, an external observer, or a change in environment among others.
…
Do you have experience with successful but incomplete agile implementations? I would love to hear of other experiences and opinions about this.
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.
Given the Agile Axioms and Disciplines then an agile coach or mentor should have some really specific experience and capabilities. This list constitutes a first attempt at a job description.
I’ve worked as an agile coach on three infrastructure/maintenance projects in a row. One was a software/hardware upgrade, one was implementing agile for a defects/enhancements team, and my most recent was a data warehouse decommissioning project. In all cases, the interesting part for me was taking the basic principles of agile and applying them in a way that works when not doing new product development. Here are some lessons I’ve learned:
1. Figure out what is going to deliver value (usually cost savings). In the case of infrastructure projects, one is usually focused on cost savings. Find a way to tie your work items directly to cost savings. You need a good financial model to do this. Mary and Tom Poppendieck talk about this a little in their Lean Software Development book. In the decommissioning program, there was a very explicit dollar cost associated with disk space and cpu utilization. Every user/MB decommissioned saved a measurable amount of money. As well, it allowed us to easily prioritize our backlog.
2. Focus project/program organization more on Lean principles than agile. A good understanding of queuing theory will go a long way to helping with throughput. In a team doing defects/enhancements work, the small pieces lend themselves well to certain types of streaming through the team. Iterations are not necessary to chunck work. Instead, iterations become checkpoints solely for process reflection.
3. Technical infrastructure projects can benefit greatly from automation. Test automation including test generation can sometimes be possible. Automating parts of a regularly repeated process that is used for every work item can be extremely beneficial for increasing speed. In the case of the decommissioning effort where every database table needs to be considered separately and where they all go through the same process for decommisioning, there are many opportunities for automation. The project/program/team can invest in doing this automation to great benefit to NPV.
4. The basic axioms (We are Creators, Reality is Perceived, Change is Natural) and disciplines (Empower the Team, Amplify Learning, Eliminate Waste) still apply. Even though it is not “new” product development, the creativity of people is essential for problem solving, and finding ways to do the work faster. Stakeholders still need to have their perception of reality acknowledged, and the teams still has to do constant checking to make sure they are on track with that perception. And of course, things are always changing including priorities, our understanding of the work, resource availability etc. Having an empowered team makes short work of many obstacles, but that wouldn’t happen without an explicit acknowledgement that we have to constantly be learning and eliminating waste. Teams get better and better at these disciplines over time.
I would be very interested to hear other peoples experiences with infractructural/operational projects.
Which approach is most valuable in training that fosters collaborative work for the purpose of optimizing the performance of an organization: a tools / methodologies approach or an inner capabilities approach? The typical orientation that most organizations take is often external and rule-based. This consists of creating methodologies, rules, boundaries, systems and processes to enhance collaboration.
These external approaches ultimately fail to have a lasting effect on people and the culture of the organization because they don’t address change at the level of habits of mind. People then work in the new structure with the same patterns of behaviour. Behind this kind of surface approach to change are assumptions about human nature. At worst this consists of a belief that people are base (greedy, selfish etc.) by nature. At best that people are fundamentally good but cannot improve except through external measures. It is true that we need external systems and structures to give expression to our inner capabilities, to test, foster and develop them in action. However all the investment that companies make in tools, systems, methodologies are obviously not enough. We need both external and internal approaches to training people in collaborative processes. Systems and tools provide only a framework that then need to be filled in with character. At the core of Agile there are disciplines (such as Empower the Team, Amplifly Learning) without which the methodologies would have no life. The practice of the disciplines fostered by the development of inner capabilities infuses life into the Agile methods and at the same time the methods act on and reinforce the inner practice of the disciplines.
As Agile champions (coaches, facilitators, practitioners) we must invest energy on fostering -through modelling and coaching- the development of inner capabilities. The Agile community will benefit from an identification of core capabilities required and a deep exploration of how to foster their development in individuals, teams and organizations.
Although it is our nature to organize in groups and we may have much experience with collaboration, we nevertheless live in a culture of contest and individualism. Out of this culture comes a set of belief systems which are so deeply rooted in our lives that we are not fully conscious of them and their affect on us. These belief systems cannot change easily through the introduction of external structures alone.