July 31, 2007
"The Brain that Changes Itself" - Book Review
It has been a long time since I read a book in a single day. Yesterday I started and finished reading "The Brain that Changes Itself" by Norman Doidge, MD. As an educator, father and individual interested in self improvement, I was absolutely astounded by most of what I read. As an agile methods coach, I discovered some important, directly applicable ideas. Read on for a review of this book.
Myths of the Brain
You have probably heard or read somewhere that different parts of the brain control different parts of our body. Wrong.
You have probably heard that after a serious stroke, a person is crippled for life. Wrong.
You have probably heard that mental decline in old age is inevitable. Wrong.
"The Brain that Changes Itself" provides specific compelling evidence to show that these and other beliefs about the brain are dead wrong. Our brains are remarkably flexible, malleable... plastic. This basic point of the book is shown through a multitude of compelling examples. There is the story of the woman born with half a brain who is able to function almost completely normally. There is the story of the surgeon who had a stroke that paralyzed him on one side... only to have total and complete functionality restored to that side. All of these stories are backed up with rigorous scientific investigation and a complete set of notes.
About the Book
The book itself is written in a compelling fashion. The style of writing is light and accessible, the stories are well-told, and the scientific details are present yet unobtrusive. Some of the stories are deeply moving.
On the other hand, some of the material is a bit stretched. There is a chapter on talk therapy which is over-long. There is a chapter describing some deviant behavior which children should not be exposed to and which even sensitive people would probably avoid to their benefit (Chapter 4).
The books is pure text... and it suffers from the lack of pictures or diagrams. There are numerous places where a diagram of the physical structure of the brain, or a photo of a miraculous device would really make for a stronger presentation. For example, there are numerous discussions about how our physical body is "mapped" to areas of the brain. I have seen diagrams of this mapping in other texts and they would help make the idea much more concrete.
The book itself is a good-quality hardcover. It consists of 427 pages including eleven chapters, and two appendices. The table of contents can be found below for your reference.
Agile Brains - Agile Teams
The books is full of stories that bring fresh optimism to my work as an agile coach. Often I encounter individuals or organizations that don't seem to "get agile". This book provides some interesting guidance on how to overcome these mental blocks and has resulted for me in some insights.
The first insight is just practice. Actually doing agile is probably the best way to learn it and "get it". The trick here is to follow an exact and complete set of rules until they are perfected and only after that try variations. By perfecting the rules, we allow our brains to demonstrate that we have truly internalized (or mapped) agile methods.
The second insight is also practice... but related to time and frequency. I have long believed that shorter iterations are a more effective way of learning agile methods. Shorter iterations allow for more repetition of the basic rules and structures of agile methods, which allows for more effective internalizing of agile practices. Under the right conditions, brain maps change quickly (minutes), but in order to "stick", the changes have to be reinforced over the course of months.
The third insight is the importance of coaching itself. In order to change brains, it is necessary to get it right. The most reliable way to get it right is to have a coach who can help a team by demonstrating, guiding and sometimes correcting.
The fourth insight is the importance of practice when I am delivering training (rather than when I am coaching a team). My courses would be much better off if they were simply packed with a mini project that was executed over multiple extremely short iterations.
Recommendation: MUST READ!
Caution: not for children or sensitive types.
Posted by Mishkin Berteig at 11:11 AM | |
January 16, 2007
The Wisdom of Teams - Generalizing Specialists
I've almost finished reading The Wisdom of Teams: Creating the High-Performance Organization
The [Connectors Team] made several decisions that solidified its common team approach and sense of mutual accountability. First, it set some rules. Everyone on the team had to identify two others who could serve as backups during vacation and sick days. To eradicate the attitude of "it's not my job" from the team, it was agreed that whenever anyone needed help, the person asked had to respond even if the activity was not in his or her area of expertise. And the team also agreed on a peer appraisal system that gave everyone the opportunity to evaluate everyone else and, through [their team leader], feed it back to the person being evaluated. Clear-cut rules of behavior like these are an important element of all successful teams.
Second, the team eliminated the two managerial positions that had retarded empowerment. This effectively modified the membership of the team because only one of the two managers whose jobs were eliminated chose to stay. The other believed he could not take a perceived demotion and left. By January 1991, however, the Connectors Team was a dramatically more effective group of people than it had been at its formation a year earlier.
Energy and enthusiasm reached higher levels as the team started pushing itself harder and in more innovative ways. One of the engineers, for example, decided to become completely qualified as a purchaser as well. Instead of being threatened, the purchasers on the team worked hard to teach her the basics of the job. The peer review approach worked so well that the team agreed on the additional - and, for many teams, difficult - step of directly providing each other feedback instead of relyinng on the team leader for this task.
There are several great points in the above story:
Backups: many agile methods do not explicity talk about this, but there is a need to make sure that the Truck Factor increases. A low truck factor can be a real problem and I strongly recommend that the Queue Master (Product Owner, Customer) in particular needs to have backup. As well, this hints at the idea that eventually the roles of Process Facilitator and Queue Master should eventually go away to be taken on by the team as a whole.
Skills: the example of the engineer learning to be a purchaser is a great example of a brave soul really taking to heart the idea of working for the good of the team by becoming a generalizing specialist. In my own coaching work, I have seen purely business-oriented Queue Masters become technical contributors to the team through a process of both deliberate and "accidental" learning. Every human being has an incredible capacity for learning. In a high-performance team, everyone takes that ability very seriously - to the point of it becoming a responsibility.
Rules: one of the simplest, yet most profound, ways that a group of people can start on the process to becoming a high-performance team is by working together to agree on some ground rules about team behavior. One team I worked with, among other rules, decided that no "stinky food" was allowed in the team room. The passage above notes the non-trivial rules. Both "trivial" and non-trivial rules are important to the team for two reasons:
1. Develop a set of expectations that individuals can hold each other to in order to avoid or deal with conflict.
2. Become aware of the team's power to set their own working conditions, independently of management or other "leadership".
Management: regrettably for most managers, in a high-performance team the value of formal, traditional management is much reduced. However, there is now an opportunity for two different types of work: the generalizing specialist work on the team, and the servant leader work of supporting the team. The servant leader is someone who is exceptionally good at problem solving, organizational change, and working through influence rather than authority.
This book is incredible. Every time I read a few pages I think "Oh! I've got to write about that on Agile Advice!" Unfortunately if I did that, I'd be in serious copyright violation. So all I can do is encourage you to read the book.
If you have already read the book, I would love to hear your impressions, particularly if there were things about it that you really didn't like. What didn't you like and why? What are the holes in it's argument?
Posted by Mishkin Berteig at 04:05 PM | |
January 02, 2007
Top Ten Most Popular Entries from 2006
If you are new to Agile Advice, these are not just some of the most popular articles, they are also some of the best! Take a look around; you will find ideas to inspire you, challenge your thinking and maybe that one little thing that will make the difference in applying agile methods in your situation.
1. How Two Hours Can Waste Two Weeks - 25,617 unique views
This little hypothetical story by Dmitri Zimine was very popular on Reddit, and Joel on Software ranted a bit about it.
2. The Case for Context Switching - 2,936 unique views
My rebuttal to Joel's rant. Goes well with Dmitri's article. Emphasizes the idea of building trust in an organization.
3. The Qualities of an Ideal Test - 1,579 unique views
Six qualities that will help make your tests as valuable as can be. Similar to the ACID properties of databases or the INVEST properties of user stories.
4. The Pros and Cons of Short Iterations - 1,555 unique views
A few words that will help you decide how long to make your iteration length. This is an important decision, and most teams and organizations don't know the factors involved.
5. Five Signs of Trouble in an Iteration - 1,489 unique views
A good howto on using burndown charts to discover problems in an iteration.
6. Seventeen Tips for Iteration Planning - 1,427 unique views
A good list of hints and tips that can make the difference between struggling with iteration planning and having it go smoothly and effectively. This is a key part of the Agile Work process, so getting good at it is a high priority for any team new to Agile Work.
7. Change is Natural - "Embrace Change" - 1,397 unique views
A short riff on the universality of change. Also introduces the idea of the "horizon of predictability".
8. The Art of Obstacle Removal - 1,287 unique views
This is a good reference article on types of obstacles and methods for removing them... a critical practice for Process Facilitators.
9. The Seven Core Practices of Agile Work - 1,285 unique views
Agile Work is really quite simple. This is a concise list of the practices that make up this effective methodology.
10. Interview with Alistair Cockburn - Agile and House Renovations - 902 unique views
Applying agile methods to home and garden renovations! Learn a bit about how this luminary of the agile world has taken agile practices out of the software world and into the hardware world.
Posted by Mishkin Berteig at 06:32 PM | |
December 07, 2006
Peformance Goals - The Wisdom of Teams
As I continue my enthralled read through "The Wisdom of Teams: Creating the High-Performance Organization
The Performance Goal
This concept and practice is an essential condition for a team to become a high performance team. The Performance Goal is a specific, measurable, challenging goal that is given to and/or adopted by the team. It is a statement or description of a goal that answers "why?" and "what?" questions, but specifically avoids answering "how?". It is not a description of activities, it is a statement of desired results. The team is left with the full authority to answer "how?" and implement it.
This concept is essential for setting the initial boundaries of self-organization. By defining "what" and "why", the team is left free to be creative about the solution. The Performance Goal is also essential to building team accountability (as opposed to individual or externalized accountability). Every action, plan, mistake and success are oriented around the Performance Goal.
From the book:
The hunger for performance is far more important to team success than team-building exercises, special incentives, or team leaders with ideal profiles. In fact, teams often form around such challenges without any help or support from management. Conversely, potential teams without such challenges usually fail to become teams.
I would also like to point out a great blog entry I found that shows some of the other side of dealing with teams and present some cautionary words about the potential pitfalls of working in teams.
In an Agile Work environment, the starting point for a performance goal is simply the delivery of valuable work at the end of their very first iteration. This is often a substantial challenge to a team and an organization. For some teams that have worked for a long time in a "waterfall" or phase-based project environment, it can be almost unthinkable that valuable results could be delivered in one tenth or one twentieth of the "normal" amount of time.
However, simply delivering value at the end of each iteration is probably not going to sustain the development of a high performance team for very long. Rather, the overall objective or goal of the project has to be important and compelling. Much work these days is _not_ important and compelling. In fact, many people become cynical about work because they are stuck doing a high proportion of work that is bureaucratic or due to chaotic circumstances.
As a reminder, the books "Good to Great
I frequently work with organizations where a team has been formed up, told to use agile methods, and then also told how to do their work. Really great examples of this are things like: "we want you to self-organize, but you have to build this huge system using J2EE." The the problem with this is simply that it may in fact be ten times less expensive to build the system with Ruby. However, someone has decided (possibly for defensible reasons) that J2EE is the technology platform that must be used. In this circumstance, someone external to the team has stepped over the boundary of "why" and "what" and also included some "how" in the team's goals. The team is not even allowed to consider the possibility that something might work just as well and be much less expensive. Not only that, but the stakeholders haven't even really stated "why" the system is being built and so the team can't evaluate technology choices. There is no standard around which to self-organize. I admit that I am using a simplistic example here, but the pattern is something that I have seen over and over again.
Posted by Mishkin Berteig at 11:44 PM | |
October 30, 2006
The Wisdom of Teams
I've read a lot of books lately about agile, organizations, teams, work systems, lean, etc. This one really stands out: "The Wisdom of Teams: Creating the High-Performance Organization
Teams also need to develop a common approach--that is, how they will work together to accomplish their purpose. Indeed, they should invest just as much time and effort crafting their working approach as shaping their purpose. A team's approach must include both an economic and administrative aspect as well as a social aspect. To meet the economic and administrative challenge, every member of a team must do "equivalent" amounts of real work that goes beyond commenting, reviewing and deciding. Team members must agree on who will do particular jobs, how schedules will be set and adhered to, what skills need to be developed, how continuing membership is to be earned, and how the group will make and modify decisions, including when and how to modify its approach to getting the job done. Agreeing on the specifics of work and how it fits together to integrate individual skills and advance team performance lies at the heart of shaping a common approach. It is perhaps self-evident that a working approach that delegates all the real work to a few members (or staff outsiders) and thus relies on review and discussion meetings for the only "work together" aspects of the approach cannot sustain a real team. (p56)
Wow! That's about as clear a description of self-organizing teams as I have ever read! I think that that is even more extreme than an agile approach to self-organization since Agile Work sets up some basic parts of the approach such as the Work Queue, Iterations, Team Status, etc. The Retrospective is the relatively limited explicit place where the team adjusts its approach in Agile Work.
The book goes on for several more pages about the "common approach" aspect of real teams. There are examples and other details which constantly resonated with my specific understanding of self-organization.
Posted by Mishkin Berteig at 02:17 AM | |
June 02, 2006
Cueing Agility - Creating a Supportive Environment for Agile Teams
In Blink : The Power of Thinking Without Thinking
In one experiement, researcher John Bargh designed a scenario to test how sensitive we are to written cues that are structured in a way that we are not consciously aware of being cued. Bargh created two lists, each composed of five words per list item. Of the five words, four were chosen to form a sentance, and the fifth word was selected so that it would not fit with the other four. Then the five words were jumbled.
For example:
rang phone peace the loudly
The people who came as subjects of the experiement were given one of the two lists and told to go through their list as quickly as possible and un-jumble the sentances.
Unbeknownst to the participants in the experiment, each group of five words also contained a word that was selected to suggest a feeling or attitude. In the first list, each group of five words contained one word that would suggest impatience, rudeness and aggressiveness. The second list contained words to suggest patience, politeness and calm.
All the subjects of the experiment were also given additional instructions to come to a particular office once they had completed their lists. At the office they were to receive final instructions. At the office, each participant encountered the experiment administrator deep in conversation with another person. Neither the administrator nor the other person acknowledged the just-arrived subject. Now the real purpose of the experiment was tested: how long would the subjects wait before interrupting the ongoing conversation?
The results were astonishing: those people who were cued with the list containing words suggesting impatience, rudeness and aggressiveness
eventually interrupted - on average after about five minutes. But of the people primed to be polite, the overwhelming majority - 82 percent - never interrupted at all. If the experiment hadn't ended after ten minutes, who knows how long they would have stood in the hallway, a polite and patient smile on their faces? (p 55)
Gladwell gives several more similar examples in his book. I strongly recommend reading this book to see just how powerful this cueing or priming effect can be.
For organizations, teams and even individuals, this effect can be harnessed. The most obvious ways include using posters, screen savers, banners etc. to constantly impress people with positive messages about teamwork, effectiveness, creativity and other values and qualities that might be deemed valuable. This should obviously go hand-in-hand with a conscientious removal of all negative messages.
For agile teams, there are some particular values that should be emphasized: truthfulness, courage, creativity, teamwork, trust, cooperation, hard work, learning, adaptability.
The message can also be communicated in more subtle ways - and this is actually likely to be more effective! Incentives, the power of exemplary behavior, and the physical environment itself all can contribute strongly. In Built to Last : Successful Habits of Visionary Companies
(p 122)
- Fervently held ideology...
- Indoctrination
- Tightness of fit [for employees]
- Elitism
Interestingly, agile methods do tend to require "buy-in". In order to fully feel comfortable in an agile environment, people need to understand and fully accept a small number of very important beliefs:
(These are the generic, non-software version of the Agile Software Manifesto.)
See also: Optimizing a Team Room
Posted by Mishkin Berteig at 11:26 AM | |
May 31, 2006
The Human Touch
If you are given a problem to solve, how much does the presentation of that problem matter to your ability to solve it? Imagine that it's a simple problem... imagine that it is presented in two different ways, both of them simple. It turns out that presentation differences can still make a huge difference. In fact, there is a way to present problems that makes them substantially easiers to solve: make them people problems.
In The Tipping Point: How Little Things Can Make a Big Difference
Consider the following brain teaser. Suppose I give you four cards labeled with the letters A and D and the numberals 3 and 6. The rule of the game is that a card with a vowel on it always has an even number on the other side. Which of the cards would you have to turn over to prove this rule to be true?
Go ahead and take a few moments to figure that out before continuing on to the answer, and keep track of how long you work on it...
The answer is two: the A card and the three card. The overwhelming majority of people given this test, though, don't get it right. They tend to answer just the A card, or the A and the six. It's a hard question. But now let me pose another question. Suppose four people are drinking in a bar. One is drinking Coke. One is sixteen. One is drinking beer and one is twenty-five. Given the rule that no one under twenty -one is allowed to drink beer, which of those people's IDs do we have to check to make sure the law is being observed?
How long does it take you to figure that out?
Now the answer is easy. In fact, I'm sure that almost everyone will get it right: the beer drinker and the sixteen-year-old. But, as the psychologist Leda Cosmides (who dreamt up this example) points out, it is exactly the same puzzle as the A, D, 3, and 6 puzzle. The difference is that it is framed in a way that makes it about people, instead of about numbers, and as human beings we are a lot more sophisticated about each other than we are about the abstract world.
Now unless you had heard about this before, I suspect you were pretty suprised. I know I was! I always considered myself to be a very good abstract thinker/problem solver. In fact, I considered myself to be well above average in that regard for a number of reasons: I was always very good at math without every memorizing a single formula (I always made them up as I went along as long as I remembered the _idea_ of the formula), I was an excellent programmer in a number of different computer languages including assembler, Miranda, Java, Prolog, Pascal, and Objective-C, and finally, I'm always solving problems by moving the problem to a new level of abstraction - solving the meta-problem first.
So what does all this have to do with agile work methods? Quite a few things actually:
1. Obviously, if you can frame a problem as a people problem, it will be easier to solve... and most problems start out this way!
We tend to try to abstract problems, make them more generic or general purpose in the hopes that they can be communicated more precisely and can be solved in a way that will accomodate contingencies we haven't thought of yet. But all the effort we put into abstracting the statement of the problem ends up costing us doubly: in the initial abstraction and in the difficulty of solution that results. So if you have a team that is solving a people problem, make sure to keep it a people problem when you give it to the team!
2. If you have a problem that is given to you in an abstract form, try to convert it to a people problem before trying to solve it.
In all likelihood, the moment you do the conversion, you will quickly see the solution. It may even feel like the process of de-abstraction is a problem-solving process. You may have to make really odd connections to make the problem a people problem but it will likely be worthwhile.
3. Dealing with people rather than abstractions on a day-to-day basis will always result in a more effective interaction.
Sending printed documents, writing emails, manipulating symbols are all interesting ways to communicate, but fundamentally, you are communicating with other people. If you can make that communication as direct as possible - phone, video conference, in-person - then there will be far less effort involved in understanding the communication, and far more effort can be allocated to high-bandwidth communication. This obviously has special relevence for teams: get people in the same room as much of the time as possible.
In the software world, there is one technique that I give teams and that is the use of Personas to assist in solving a software problem. The place I first encountered Personas is in the excellent book The Inmates Are Running the Asylum
The bare essense of the Persona is to create a fictional person who represents a user or actor or stakeholder or customer of whatever it is you are building. This fictional person should have a name and all conversation about the thing being built should be couched in the personal language of these Persona's names. A Persona should also have a short history, a photo and some description of their needs, goals or desires. All of this helps to frame everything about a software project as a people problem... and thus makes it much easier to discuss and solve.
Posted by Mishkin Berteig at 11:12 PM | |
November 28, 2005
Agile Advice Recommended Materials
This page contains a number of links to recommended web sites, books or tools relating to Agile Work. This page will be updated from time-to-time and as this is done, announcements will be posted on the Agile Advice blog. As such, this page will always be "under construction". If you have links to suggest, I will examine them and put them up in my own time. Please feel free to email suggestions to topics@agileadvice.com.
Update 20070115: 1 new reference!
Introductory Material:
Agile Axioms
Agile Manifesto
Agile Work Cheat Sheets and White Papers - Berteig Consulting Inc. [pdf]
Agile Software Focus:
Extreme Programming
Methods and Tools
A Scrum Primer - Report from Yahoo! [PDF]
Control Chaos - Ken Schwaber and The Scrum Methodology
Agile Software Development by Alistair Cockburn
Agile vs. Lean - Thad Scheer
No Silver Bullet by Frederick Brooks
Agile Planet - agile blog aggregator
Buildix - agile software dev tools on a CD
Agile Forums
Implementing Scrum
Project Management:
Project Management Institute
Agile Project Management Yahoo! Group
Burndown and Burnup Charts
Huge List of Software Project Management resources
Scrum Alliance - Agile Project Management and Training
Project Management Resources - by Michael Greer. I don't agree with everything on this site, but if you are looking for traditional PM stuff this is a good place to go.
Lean and Theory of Constraints:
Lean Software Development - Mary and Tom Poppendieck
Evolving Excellence - by Kevin Meyer, Bill Waddell, Dan Markovitz NEW!
Theory of Constraints - Eliyahu Goldratt
Agile Work for Flow Projects - Mishkin Berteig
The Toyota Production System
Practice Without Principles - TPS Without the Toyota Way - Victor Szalvay
Agile Work Uses Lean Thinking - Whitepaper [pdf] by Mishkin Berteig
Management:
Agile Management Yahoo! Group
Slow Leadership - the opposite of Agile?
Adaptive Management - Jeffrey Phillips
Adult Education:
The Self-Educative, Narrative and Metaphorical Faculties of the Soul - Alexei Berteig (pdf)
Infed
Team Building:
The Wisdom of Teams: Creating the High-Performance Organization
Retrospectives
Retrospective Patterns by William Wake
How to Win Friends & Influence People - Dale Carnegie
Community Development:
Corporate Culture:
Catastrophic Organizational Change - Tobias Mayer
The Corporate Culture Survival Guide - Edgar H. Schein
Good to Great (fastcompany article) - Jim Collins
Agile Services:
Berteig Consulting - Agile Work Coaching, Training and Consulting
CC Pace
Digital Focus
Israfil Consulting Services Corporation
Scrum Alliance
Tobias Mayer
David Chilcott
Joe Little
Michael Vizdos
Agile in Other Domains:
Extreme Project Management for Architects
Experiences and Stories of Applying Agile in Other Domains:
Agile Documentary Video Project
Agile Publishing
The following sections of material are based on the Agile Work Cheat Sheet.
We are Creators
Reality is Perceived
An Introduction to General Systems Thinking
Change is Natural
About "Resistance" by Dale H. Emery
Trust is the Foundation
Agile or Not Agile?
Trust and Small Groups
Empower the Team
Launching an Agile Team - A Manager's Howto Guide
Amplify Learning
Abe Lincoln’s Productivity Secret - a nice little bit about being properly prepared (although caution should be taken not to over-prepare!)
Eliminate Waste
Self-Organizing Team
Variations on the Daily Standup - Rachel Davies
Scrum from Hell - William Wake
Team Formation Stages - Forming Storming Norming Performing
Iterative Delivery
Are Iterations Hazardous to Your Project? - Alistair Cockburn
Adaptive Planning
Maximize Communication
Edward Tufte's web site with lots of great info about the visual display of information
Human Tools for effective communication
Eight Barriers to Effective Listening
Facilitation Skills [pdf]
Test-Driven Work
The Qualities of an Ideal Test
Appropriate Metrics
Appropriate Agile Measurement White Paper (pdf)
Removing Obstacles
Intros and Summaries
The Seven Core Practices of Agile Work
Posted by Mishkin Berteig at 02:02 PM
|
|
I heard a story about a situation where someone was refused career advancement because she had made an enemy a long time ago. It made me think. Why do we make enemies? Is it because we don't really know how to make friends? In Agile Work, where communication, collaboration, teamwork and truthfulness are so important, making enemies is the worst thing a person can do. (It might not be such a big problem in mechanistic environments.) The golden rule is a good starting place for learning how to make friends. Esther derby has a great course on teamwork that could help. An of course there's the old classic: How to Win Friends & Influence People which really is very good (if a little dated). If anyone knows some other good books or resources about learning to make friends, please reply in the comments!
Posted by Mishkin Berteig at 03:26 PM
|
|
These six qualities of tests describe how to make a test as effective and as useful as possible. The qualities are similar in style to the INVEST qualities of user stories - but they don't form a nice acronym. Decisive: The test contains all the information required to automatically determine success or failure. Manual inspection of test results is not necessary to determine success or failure. The test is expressed in a way that produces a pass/fail answer rather than a numerical or qualitative result. Decisive tests are often expressed as assertions. Valid: The test produces a result that matches the intention for the work artifact under test. Test failure indicates failure in the artifact under test and test success indicates correct operation or configuration of the artifact under test. Simply put: the result of a test should be true. Complete: The test contains all the information it needs to run correctly with a given test harness and work artifact under test. The test performs all activities and provides all the data necessary. The test does not require any input outside of itself in order to run. Repeatable: The test always gives the same results if the test harness and the artifact under test are the same. The test is created in such a way that the result is deterministic. Even if the system under test is not deterministic, the test should be created to account for that (possibly with statistical analysis) and produce a deterministic result. Isolated: The test result is not affected by other tests run before it nor does a test affect the results of tests run after it. The test and the test harness work together to clean up after every test is run. A collection of tests can be run in any order and always produce the same results. Any test that depends upon the results or side-effects of a previous test is not isolated. Automated: The test requires only a start signal in order to run to completion in a finite amount of time. No manual intervention is required after the test is started. Tests that are automated can be put together into a test suite and run one after another without human intervention. Automation of tests requires the creation of a test harness system. Update 20060106 I've added a little bit more detail to the above qualities. I also wanted to say a few words about my experience with testing: I first started doing test-driven development almost seven years ago after reading the book Refactoring by Martin Fowler. I picked it up in Windsor Ontario while I was driving to San Francisco for my first contract position as an independent. I had to stay the night there due to the immigration office being closed so I read a lot of the book in my motel room that night. By time I got to California four days later, I was totally convinced that I should be using JUnit and refactoring for everything I did. Fortunately my project was ammenable to this approach. Over the next four months I built a Java JMS layer on top of Tibco Rendezvous. In the process I discovered methods for doing unit tests for asynchronous multi-threaded distributed functionality. And my tests satisfied all the above qualities. I delivered code with 100% test coverage and zero defects discovered until more than two years later when a very rare and obscure deadlock issue was found. Suffice it to say, I was convinced from a quality perspective. But there is more. To build tests that follow all the above qualities, you need code that is testable. I have come to believe that testability is the most important architectural attribute of code for most software. The implications of having testable code include code that is easily changed, that is verifiable, and that is easy to understand. Refactoring plays a big role here too. For getting a basic but very practical sense of test driven development, I strongly recomment Test Driven Development: By Example I have also written a couple of articles recently about quality: Quality is Not Negotiable in which I talk about how to handle defects - by always treating them as top priority work items. and Technical Debt in which I expand on this common analogy between lack of testing and debt to show that technical debt is even worse than financial debt.
Posted by Mishkin Berteig at 06:48 PM
|
|
Learning is the result of both encountering new experiences and deliberate experimentation. Learning creates new knowledge, increased volition and improved action. Some of people's best learning comes from “failure”. An essential component of learning is feedback. Learning and feedback can be amplified in several ways. Provide opportunities for learning through books, training courses, coaching, deliberate exposure to diverse work, and deliberate experimentation. Frequently ask the questions “why?” and “how?” and answer the honestly and deeply. Increase the level and quality of communication among the stakeholders and team members. Inspect work in progress frequently or even continuously. Learning accelerates greatly if a culture of learning is created where individuals feel free to experiment and take initiative even on critical aspects of the work. Learning and feedback support all three agile principles. People become more effective creators as they learn. People are better able to adapt to and embrace change as they learn. And a person's span of perception increases as they learn. Any increase in learning or feedback leads to an increase in the manifestation of the principles. Learning and feedback can be amplified rapidly, but an empowered team is necessary to effectively take advantage of this amplification. If a team is not empowered, then rapid learning can lead to frustration. Amplified learning and feedback result in excitement, enthusiasm and playfulness, rapid problem solving, high quality work results and satisfied stakeholders. An excellent analysis of learning at a social or group level is presented in Progress and Its Problems by Larry Laudan. In this very well written book, Laudan takes a look at the history and philosophy of science and develops a model for learning that is applicable to the development of agile methods.
Posted by Mishkin Berteig at 01:12 PM
|
|
Lean Metrics... are Lean Conclusions for Scrum and Agile in General Don't prescribe specific metrics! Agile work is about an empirical process where a team responds to change, learns, and self-regulates. An agile team has the power to choose their own metrics for their own self-inspection. For upper management, the single economic driver that is part of the "Good to Great" process should be sufficient. See also: Appropriate Metrics and A Metric Leading to Success.
Posted by Mishkin Berteig at 07:14 PM
|
|
Here are my rough notes from the May 2005 Scrum Gathering in Boston. Regrettably I was not in the room for most of Mike Cohn's presentation on User Stories... but his book (User Stories Applied : For Agile Software Development) is excellent :-) The notes in this entry include predictions from Ken Schwaber, a presentation from Bob Schatz formerly of Primavera on their enterprise-wide implementation of Scrum, a panel discussion with Tim Bacon, Jeff McKenna, and Diana Larsen, moderated by Esther Derby. In the afternoon we heard from Pete Deemer about Yahoo!'s enterprise adoption of Scrum, Mike Cohn about User Stories, and to close the day we had an energetic presentation from Tim Dorsey of WildCard Systems about their enterprise implementation of Scrum. Scrum Gathering 20050511 Companies using scrum: Microsoft, Sun, Siemens, State Farm, IBM, Federal Reserve Bank, Yahoo Purpose: implement scrum http://www.controlchaos.com/playbook.pdf Predictions by Ken Schwaber: At Wildcard Systems, transition from fixed price to time and materials for clients Bob Schatz – implemented Scrum at Primavera Enterprise Agile – what does it really mean? Implementing agile is a culture changed (Primavera did it all in a big chunk – WHAT SITUATIONS MADE THIS WORK?) Communication No silver bullet Keys to Success at Primavera (100 people in dev org) What to Expect “The Hurricane's” System!! What you will get What can you do? What would you do differently How did you set expectations? Add process/environment/team improvements to the backlog – someone has to pay the price for it. Everything goes on the backlog! Nothing is ever perfected – always changes and improvement. Made mistake – Scrum of Scrums was institutionalized with responsibilities – but this caused power and conflict issues – eliminated this and move to town hall meetings (Scrum of Scrums as a meeting rather than an organizational structure) Times for management feedback Core of stubbornness, courage or stupidity. Tim: Jeff: Deb Hartmann Yes, but depends on how you like to spend your energy. Jeff: Diana: Tim: Jeff: Going from waterfall to scrum – is there a smooth transition? Diana: Jeff: Tim: Ken Schwaber: Diana: Jeff: Tim: Esther: Craig Larman: Diana: Tim: Jeff; Can this be done from a grassroots level? Overallocated people, management confused. Really struggling. Wholesale change is impossible. How? Tim: Jeff: Diana: Tim: Mike (?): Diana: Jeff: Tim: Bottom up implementation – management happy, later ask about working more hours and weekends to get more work done? What about managers that want to squeeze their people? Bob Schatz: Tim: Jeff: Diana: Not necessarily that somethings not working. Question about increase productivity based on hours. Diana: Jeff: Tim: put it on the backlog as a problem: Tim (?): manager may be asking for something realistic .. Brian (?): what about external customer who says we're not doing agile. How do we help our customers to adopt this? E.g. A client that has contracted for work. Jeff: Diana: Jeff: Tim: Ian: how to reward agile teams to get the best out of them? Reward according to influence not control. Tim: Diana: Jeff: ?: Starting from top down? What are the top three pushbacks from dev org? How do you overcome them? Diana: Jeff: Diana: Jeff: ?: Jeff: Ken Schwaber: Tim: ?: Diana: Jeff: ?: Mishkin: Tim: Diana: Jeff: Roger: What about Some Good References for Org Culture and Change? Self-promotion is okay! Tim: Fearless Change: Patterns for Introducing New Ideas ?: more about cultural changes for creating team rules. Jeff: Tim: Jeff: Brent: Esther: one sentence of advice: Jeff: Tim: Diana: Pete Deemer From Yahoo! How did Yahoo! get bamboozled by waterfall? Mike Cohn Filling your Backlog with User Stories Tim Dorsey Wildcard Systems from Florida change is often compared to a step into the dark 2000 – 700 million in transactions Now have 50 clients 12 million cards issued Flexible Solutions – Managed for Client Success Want to do good – but kept tripping over selves System was a catastrophe waiting to happen – growth faster than expected No fallback position because of growth 9 months scrumming last july 27 dev 6 qa 160 dev 60 qa now Client feedback and employee morale – before scrum – not friendly to deal with, products always late, lots of bugs (but still best in business) – 82% of employees said they didn't like coming to work – tonnes of overtime, multiple projects Speaking executive language is very important to going enterprise wide Executive support – let go SVP of Sales cause he couldn't get with the program Scrum: Enterprise -wide implementation of Scrum: Took a baseline Strategic Alignment (setting the course) Organizational Development (preparing the people) Organizational Analysis (looking in the mirror) Implementing for Results (making it happen) Scrum Assessment: Radar Chart Two week sprints all ending on the same day across the organization What happens in two week ramp up after team formation develop backlog, interview clients, interview systems people Stick to strictly normal working hours – teams are allowed to choose to work on the weekend but if it starts being a regular occurance then look at why Metrics:
Posted by Mishkin Berteig at 10:35 AM
|
|
At the Advanced ScrumMaster Training, Ken Schwaber presented a substantial amount of thinking about metrics used with Scrum. The main driver for thinking about metrics has come from implementing Scrum in enterprise situations. Management expects metrics to be used in order to provide visibility into the progress of the Scrum implementation. While this driver has some legitimacy, there are three main concerns to prescribing metrics for use with Scrum. 1. Planned/Engineering Approach - metrics such as "ideal person days" smell like the bad old way of treating people as resources that can be swapped in and out of a project. 2. Normative vs. Empirical - metrics are often used to set a standard for reasons such as prediction, and expectation. Scrum is about discovery and improvement not prediction and planning. 3. Is Something in Scrum not Working? Is adoption being hindered? Are too many Scrum implementations failing? Are metrics a critical success factor? Keep these concerns in mind while considerig the uses of metrics. What are Metrics for? 1. Self-Evaluation over Time - use a metric to track the progress of a group. A measurement is taken at a certain point in time, and then taken repeatedly over intervals. Example: the velocity at which a team completes work can be used to identify problems and opportunities for a team. 2. Control - use a metric to legislate the qualities of some process or attribute of work. A goal or standard is set for a measurement. The size of a queue of projects waiting to be worked upon by a team can be controlled in order to limit the size of work in progress and therefore project inventory. 3. Prediction - use a metric with values collected over time in order to predict future values of that metric. By implication, the metric is used to predict the performance of a system. The number of additional tasks discovered inside an iteration can be tracked and used to determine future expectations on extra tasks discovered. 4. Performance Measurement - use a metric in order to determine rewards and/or punishments and/or adjustments to behavior. An individual on a team may be evaluated based on their productivity as measured by lines of code completed and rewarded or penalized on that basis (not recommended!). 5. Behavior Motivation - use a metric to guide behavior by setting a context for thinking, action and reflection. Focus on an important measure in order to draw attention to improving the attribute with which the metric is associated. Measuring the time elapsed from conception of a project idea to the time it actually delivers valuable results can draw attention to improving speed. The Lesson from Good to Great Good to Great: Why Some Companies Make the Leap... and Others Don't by Jim Collins discusses the attributes and behavior that are common and unique to companies that have gone from a long history of mediocre results to a long run of great results. One identified aspect is referred to as the "Hedgehog Principle". In this principle, three questions are answered: "what can we be the best in the world at?", "what can we be passionate about?", "what is my one economic driver?" The economic driver is a metric. For example, at Walgreens, their driver is profit per customer visit. Other large institutions have other metrics. But all good to great companies have a single economic driver metric that guides all their decision making. See also: A Metric Leading to Success.
Posted by Mishkin Berteig at 05:21 PM
|
|
In her workshop "Advanced Scrum: Collaboration Skills for Scrum Teams", Esther Derby includes a brief discussion on the five parts of a decision. 1. Define the Problem At each step, it is instructive to examine who is "responsible" or involved. In an agile team where team empowerment and self-organization are considered critical success factors, the answer to "who?" fore each step should usually be "the team". There are however, some situations where decisions are outside the realm of a team's empowerment. As well, some decisions are so trivial that it is wasteful to have the whole team involved. In these trivial decisions, usually another person can take responsibility for all the steps of a decision as a service to the team. Over time, a team and the organization in which a team operates can evolve a set of standards that describe who acts in each step of a decision under what circumstances. Many thinking tools described by Edward de Bono in his various books (such as Six Thinking Hats, Lateral Thinking : Creativity Step by Step (Perennial Library), Textbook of Wisdom etc.) can be used at various steps in the decision making process.
Posted by Mishkin Berteig at 11:48 PM
|
|
An information radiator is a large display of critical team information that is continuously updated and located in a spot where the team can see it constantly. The term "information radiator" was introduced extensively with a solid theoretical framework in Agile Software Development by Alistair Cockburn. Information radiators are typically used to display the state of work packages, the condition of tests or the progress of the team. Team members are usually free to update the information radiator. Some information radiators may have rules about how they are updated. Whiteboards, flip charts, poster boards or large electronic displays can all be used as the base media for an information radiator. For teams new to adopting agile work practices the best medium is usually a poster board on the wall with index cards and push pins. The index cards have a small amount of information on each of them and the push pins allow them to be moved around. Information radiators help amplify feedback, empower teams and focus a team on work results. Too many information radiators become confusing to understand and cumbersome to maintain. If an information radiator is not being updated it should be reconsidered and either changed or discarded. Here is an information radiator used to quickly display the status of multiple projects to an agile Project Management Office: As the team used an information radiator, it can adapt the display of information to become more appropriate to the way the team is operating and the information they are really concerned about. For example, on the above IR for a PMO, the group may decide that they wish to put red dots on projects that are in trouble in some way. Some very interesting examples of the effective visual display of information can be found in The Visual Display of Quantitative Information.
Posted by Mishkin Berteig at 06:25 PM
|
|
Kent Beck's book "Extreme Programming Explained : Embrace Change" provides a good introduction to how software development can embrace the constant change that affects our world. Some of the practices he introduces are very software-specific. However, the overall basic message is sound and provides a foundational principle for all agile work. (By the way, the book is excellent.) Change really does occur everywhere. Change is constant. A google search for "embrace change" or "change is constant" will both turn up an incredible variety of articles, papers, discussions, books and viewpoints that all affirm the constant nature of change and the need to embrace it. Nevertheless, it is sometimes difficult to accomodate change when we also have a legitimate and deep desire to know what is coming next. For many teams, the environment in which they work is constantly changing. This change can be caused by competition between organizations, scientific or technological advances, fads and cultural shifts, major events in people's personal lives or even just a change of opinion with a stakeholder. Any change, even small change, can invalidate a planned course of action. However, goals (as distinct from plans) are more stable and often survive even major environmental changes. Therefore, rather than trying to plan the future, an agile team can focus on being able to respond to change while still reaching a goal. Nevertheless, a team needs some sense of what it will do in the near future. A team can work with a “horizon of predictability”. This is the distance into the future which a team can be reasonably certain that plans will be stable. Depending on the environment, this may be as little as a few minutes, or as long as a month. It is rarely longer. The horizon of predictability is not a precise demarcation, rather, expect change with a probability based on the horizon of predictability. Then, plan to respond to change. Be detached from the concrete details of a plan, particularly if they occur outside the horizon of predictability. The terms “agility” or “agile work” refer to this principle of embracing constant change since it is the most visible of the principles. However, the ability to respond to change relies on the establishment of agile work disciplines and practices.
Posted by Mishkin Berteig at 06:57 PM
|
|
I read an article in Wired yesterday that was modified from a book "Freakonomics Doctors have a similar motivation. Statistically, when times are tighter (fewer patients), the article pointed to the proportion of interventions going up (referring here to internists and surgeons). The article isn't crying conspiracy. Rather, it's talking about the natural incentives, and the consequences of the asymmetry of knowledge. The doctor knows more, so if they (consciously or subconsciously) recommend more intervention than is necessary, the patient has no way of knowing in order to assess bias and accomodate. Likewise with Real-estate agents. With alternative practices or new sciences there is an even larger knowledge gap, because even popular wisdom hasn't filtered down to the masses in digestible CNN-sound-bite chunks. Also, there is a lot of "naive money" in new fields, as well as a lot of genuine people who are just trying to help. Unfortunately, this means that there are a lot of wolves among the sheep, and they're wearing the costume of a sheep-dog. I think, in some ways, that was at the basis for Ken Schwaber's concern on the Scrum Developer's list about a scrum practitioner who was not really teaching scrum, but was (in Ken's paraphrased view) bilking the customer and ego-tripping. Scrum will have a similar dynamic as one finds in, say, alternative health and nutrition, or other early-stage professional arenas. There will be idealists and opportunists and then some who try to apply balance. One has to be very careful of both the idealists and the opportunists. Sometimes it is very hard to tell, and this has a high chance of painting the whole Agile community with the same brush. One of my associates had a very very bad experience with Scrum for that reason. An unscrupulous person who used the position of Scrum Master to aggrandize himself.
Posted by Christian Gruber at 01:07 PM
|
|
Pair programming appears to be the most controversial of all the Extreme Programming (XP) practices. It invokes such a violent emotional response in some people that they quickly dismiss all of XP just because of this one practice. Let me start by saying that I've done pair programming on software development teams and it has worked really well for me. I freely admit that it doesn't work for everyone or in every situation however when it does work, it is the most effective form of peer review that I've ever used. Laurie Williams of North Carolina State University has done extensive research into pair programming and has published her findings at PairProgramming.com. She has also written the book Pair Programming Illuminated with Robert Kessler. If you are interested in seeing actual research into this practice then I'd strongly recommend reading Laurie's work. Lets look at why this practice is so controversial. The benefits of pair programming are significant. Overall development time is reduced and quality is higher. Additionally, teams doing pair programming tend to have more fun than teams working individually. People who have done pair programming when it worked well are strong advocates for the practice as they've seen first hand what is possible. The biggest downside to pair programming is that it can push people well outside their comfort zones. I have often heard comments like "if they make me pair, I'll quit". This is an understandable fear reaction to something that is outside our comfort zone. Pair programming cannot be effectively mandated for exactly this reason. If the team is reacting out of fear then you won't get any of the benefits of the pairing. Another downside to pair programming that doesn't get discussed as often is that it is tiring work. After a day of pairing, the team is usually exhausted. I've also seen problems where there is a personality clash between programmers. I coached one team where I had two otherwise excellent programmers who couldn't be paired with each other because of a personality clash. Either one could pair with anyone else on the team but they couldn't be put together. One common myth about pair programming is that it will take twice as long to complete a certain amount of functionality. In my experience (and the research backs this up), a pair will take longer to write the initial code but will spend less time debugging as the code will have significantly fewer defects. When the total developer time is measured, it actually turns out that pairs are more effective than individuals. To be perfectly honest, I didn't believe this claim myself until I actually tried it. Now I've seen the results first hand. One nice side effect of pairing is that you are continually cross training the team. Over time, everyone will learn all parts of the application and therefore the team will be less susceptible to staffing changes. If your team is open to the idea of pair programming then you can get some significant benefits from this practice. Be aware however, that mandating the use of pair programming can be disastrous if the team is not receptive.
Posted by Michael Bowler at 03:28 PM
|
|
| TrackBack
Summary: In this well-written, engaging book, author Jim Collins describes six critical factors that he and his research team found common in companies that transformed themselves from a long period of mediocre or bad results to a long period of great financial results. Although focused on publicly-traded companies in the United States, the results of this research can easily be extended to apply to other types of organizations. Good to Great describes the following six concepts:
May 18, 2005
Making Friends Sure Beats Making Enemies
May 17, 2005
The Qualities of an Ideal Test
May 13, 2005
Amplify Learning
May 12, 2005
Appropriate Metrics - Continued
In the book Lean Software Development by Mary and Tom Poppendieck, there are a small number of references to metrics: process cycle time, process cycle efficiency, business models. Lean practices focus very much on diagnostic metrics that are used to help people find and eliminate waste and improve value and quality. The other aspect of metrics is to measure up for purposes of motivation and performance measurement.Scrum Gathering May 2005 in Boston - Rough Notes
33% of orgs implementing Scrum get most of the benefits – triple the initial productivity
66% will largely fail – software not that important for these orgs
Current software workload will be done by 25% of the staff
Developer will become a umbrella title for software developers – no longer specialized titles
Scrum and XP will be seen as two complimentary approaches that will start merging – may drop these names over five years
Recently left Primavera now at Solstice Software
“Enterprise”
multiple teams, same projects
multiple teams, multiple projects
implementing across an enterprise
building enterprise applications
building systems to support an enterprise
implementing across geography and cultures
Enterprise Agile is all of these and more
culture changes are extremely difficult
transitions are different for everyone
Everyone likes change... as long as it doesn't affect them
Two factors that facilitate faster changes
pain of doing it the old way is greater than pain of chang
new opportunity where the old way simply won't work
Other than that
it takes strong leadership, determination, and TRUST
Learn to crawl before you think about walking
- amount of pain – about to start a new project – very challenging, big technical hurdles – asked about doing it with just one team – what's the point? - whole org new the pain – let's just get this done – didn't want to compare apples to oranges (agile to waterfall) – decided to switch pains – bob had a management team that he spent a lot of time talking with – management team was absolutely on board – failures have come in places where management is working at cross purposes
open communications are critical in agile projects
larger, more complex projects require more communication
across organizational lines
frequent customer communications
Coordination
project managers coordinate the efforts of multiple teams
focus on team building and self-managing teams
progress and obstacles must be visible to everyone
learning and knowledge must be shared across teams
Co-location
individual teams ideally should be co-located in team rooms
the reality is that they can't always be
get creative!
Do the best you can and compensate with technology
enterprise implies complexity
implementing requires leaders, knowledge, skill, and adaptive techniques
one person will not single handedly change a company
a consultant will not change your culture for you
buying a tool will not make you instantly agile
not everyone will read the stack of books you buy them
executive sponsorship and support is needed (DISAGREE? ANYONE HAVE EXPERIENCE WITH THIS NOT BEING REQUIRED?)
sufficient motivation to change (pain)
good coaching from outside
team rooms
town hall project meetings – like daily scrum but from reps for each team
project manager role transition
information radiators
no OT/weekend working – change perspective of managers that OT is good
test driven development
“science fair” sprint reviews
build process
rotating “Scrum Master” responsibilities (after doing scrum for 1.5 years started seeing little hierarchies in teams) – certified ScrumMasters became cross-team coaches
best team performance rewards @ end of each sprint related to performance, scrum compliance, etc.
team-based bonus component (two components focused on scrum plus teamwork)
feature budgeting – work on feature only budgeted time, if over, negotiate with PO (ESTIMATES DON'T WORK regardless of tools)
sprint defect limits (tradeoff in favor of quality)
customer Webex sprint reviews
commitment to learning!
Combination of these things reduced defects by 75% (year 1 1200 to 600 with scrum, year 2 600 to 300 with XP)
resistance – always resistance to change
setbacks
problems
obstacles
damaged egos
unrealistic expectations (kept implementation of Scrum quiet)
difficult personalities
lack of trust
Ken -> Hurricane -> disaster/destruction -> rioting -> calm -> Ken
Ken tells it like it is
people get freaked out
well-respected motivated focused workforce
creative energetic learning environment
everyone focused on achieving goals
ability to meet commitments and be flexible
high value products
a disciplined repeatable approach to building software
cross functional teams that understand technology and business value
involved satisfied “customers”
Academia does not model cross-functional collaborative team work (e.g. No collaboration with business school)
have a vision and sell it
identify pain points and don't be afraid to try something different
openly discuss behaviors and challenges
look for the “real” issues, not just what people talk about
identify champions and leverage their power (people who influence others – make sure they're on board)
educate people outside of development and involve them in the process
brush up on your influence and negotiation skills
use the language and ceremony of agile
reward good behaviors, celebrate success
work the bad attitudes out of the system
don't sweep them under the carpet
be patient, persistent... don't give up!
everyone makes mistakes
communication as a leader could have been better
upper management already had low expectations
middle management was told that there were no expectations for the first few sprints
sprint planning and review
special meetings (maybe triggered by observation in daily scrum)
Esther Derby – Panel Discussion of Agile Change: Building the Self-Organizing Enterprise
Tim Bacon – from UK – ScrumMaster and Coach
Jeff McKenna – Original Builder of Scrum
Diana Larson
transition to XP since 2000
deal with personal and small group level
culture about how people interact – congruence between thoughts and action – values
1991 Scrum
Agile before that
primarily with small teams but up to 80 people
difficulty – getting people engaged – people don't have responsibility for the things they do – power to make changes in working lives – very difficult
Diana:
culture is the stories we tell ourselves about ourselves
changing language
systems level of change - “freedom's just another word for nothing left to lose” J. Joplin
are there places where we shouldn't bother trying to change?
if entire org is saying “no” then listen, but sometimes people say “no” without knowing what they are saying “no” to
as a consultant: there are times when you say “I don't want to do this anymore”
if motivation is there “I want to change” then it is easier
if some say “yes”
“see where the buffalos of change have roamed before and see what kind of a trail they left” - indicators of where things might go in the future
ego involvement – significant influences who have lots of investment in the way things are can prevent change – or need someone who can move them out of the way
How do you make org change stick?
You don't
orgs keep changing – not really a new status quo, just a breather
you can always change starting with yourself
personal integrity and desire to go to work
sometimes need to change other people to keep integrity
find out what people mean by “being agile”
explore what they mean
define “smooth”?
People go through change in different ways – lots of models of change
resistance can be characterized as wanting to hold onto something of value
people need to see new/better value in the destination
may be emotional
the transition in people changing is chaotic and it is hard to do smoothly
some people are not set up psychologically to make a smooth transition
can't completely make transition roughness go away completely
some orgs are easier than others
some orgs have a culture of change
2nd order effect
need some success with change
gain some power to make lives better
rank and file are often pessimistic
uncover the pain that is already there
uncover the good things
a few years ago Martin Fowler: not going to try help unless the org is a train wreck, without hope
now seeing large orgs investigating going agile because of agile's successes
sitting with CEO of corp that want's to go agile
how can I determine if this is even worth doing?
What are some yes/no questions?
what types of change and how did they go?
What is it like when someone needs a change from facilities?
How work with HR when needs to be an adjustment?
How do the support systems support the org?
Is the org capable of making a container?
find out where the pain is? What is agile going to address? How is he/she thinking about it?
V.P. Of large company – 2 hours
6 what if's suggested
kept saying couldn't do it
left (maybe someone else could do it)
litmus test
looking for intellectual curiosity
actively asking questions
seeing possibilities as you provide suggestions, description
what are you willing to do to support this change?
ask CEO what do you know about agile? Pair programming
Customer in Scandinavia
successful scrum project compared to other projects
head of project leaving to go to another company
other PMs didn't know about this successes
How do you sell internal success?
retrospectives at the end of all projects
what are the root causes of success, not just failure
how do we spread the word?
Risk associated with having only one person lead something like Scrum
need to make explicit the job of knowledge and skills transfer to as many people as possible
e.g. Language “pairing” vs. “shadowing”
use newsletters, brown bags, etc.
a big part of all our jobs is to sell what we do
all heard of failures from the inside, but seen as successes from the outside
need to make sure successes are seen as success from the outside
use networks of people
if we don't have the networks, find the “connectors” (The Tipping Point)
secretaries
long-timers
bar, cafeteria
Guerrilla techniques
information radiators
celebrate when work gets done: use a bell
team loves the bell and gets done
other teams ask – what's going on?
yes
Pete from Yahoo! Will talk about this
warning management
team may have self-starting ability
may bring someone in – should start working on management immediately
technical side can improve team very quickly
constraint moves to management and planning
management will stop work if not ready
management can no longer blame dev for failures
can go higher in management hierarchy
start with one team and work from there
team has to manage their boundary between themselves and the rest of the organization
we tend to lack courage when implementing from the bottom up
courage is the most important
“be the change you want to see” - Gandhi
there is a lot of fear about change upsetting the status quo
works outside of development
what are the upside risks? Success can kill you – what happens when you are successful and the org starts to think about institutionalizing Scrum? How do you take this to senior management? Expectation management? Transition and scaling? Lots of cutting of admin work – don't need a lot of middle management to get stuff done.
doing self-org teams for 20 years (*********************)
come up against: managers take two stances:
get worried and mess about
abdicate
BUT
role needs to change
what support do these teams need?
Put on workshops about how leadership shifts in this environment
planning going away
resource management, championing, boundary, facilitating all becomes even more important
requires professional development on part of managers
managers who pay attention know they have to learn and improve
always opportunities for improvement
what goes through the membrane between group and rest of org
sole job to manage membrane – 5 to 10 visitors a day
org context
boundaries change and move
new container forming outside of original group
Keep aware of org context and work with that
Bob Schatz – managers have an identity problem
transition to leadership – have courage to have vision and lead
subtle
invite senior people to see the teams and join them
always work for these people to do in the team
OT/weekends lowers quality – period.
Use that quality price to drive behavior
productivity drops because of quality problems
find these managers and get them to propose this to the team
team that has successfully transitioned will make reasons for not doing this very very clear
team will supply questions to the manager
just ignore them – worked well
manager broke the team up into two pieces
long hours team velocity went down
normal hours team maintained velocity
if question comes up because underlying belief not working enough hours
could be something else going on there – and underlying personal dynamic
could suggest other experiments
recruit someone to be team champion
that sort of question can be directed to champion
medical community research about long hours being bad for productivity
analogy:
mechanistic thinking
people are machines?
Factories don't run machines at 100% utilization
Lean Software movement
Theory of Constraints
people aren't machines
how to increase productivity by 25% without increasing manpower
what do you mean by customer?
Is your business taking an external stance on agile?
Boundary is the organization
can have waterfall relationship to client and work agile inside
may have waterfall embedded in law
are you asking about influencing the culture of an industry?
Invite them in to be involved with the process as much as they can stand
might not be very much at first
someone internal must become a domain expert and act as customer proxy
start by inviting to monthly demos (relatively easy)
invite them to come more frequently
like teaching children
go visit customer
changing relationship to customer is sometimes about asking them to give something up
have to articulate what they have to gain
“Punished by Rewards” - carrots can be just as damaging as sticks
fun work can be its own reward
agile makes work fun again
extrinsic rewards may be an indicator of other problems
frequent small rewards better than large infrequent rewards
large cumulative effect
Esther:
worked with team that received huge financial bonus
bonus was nice BUT
want recognition and notice from managers at a personal level
rewards for goals set by someone else is a problem
e.g. Sales quota had no connection to work in field
manage your own expectations
imposing change is very difficult task
frame it as an invitation
“yet another change”
varies from org to org depending on culture
e.g. “flavor of month – wait it out” passive resistance
keep working the way I always have
working cross functionally is resisted very strongly
want to protect specialization
iterative may seem less efficient locally
Solve: team building, coaching, build on initial successes
First line management team has to buy in
some people will have to move out of the organization
do lots of educational work
find pain points before imposing solution
very uncomfortable
teams for X-functional
lots of releases
management questions about jobs
power prestige
get people to talk about their feelings and facilitate solutions
notice the problem and facilitate talking about problems
fear comes from responsibility for things that were formerly hidden
now get to own solutions
org change
need to paint vision of new organization
resistance comes from what needs to be given up?
Self-image might need to be given up
territorialism
prestige
relationships
paradigm shift – whoop de doo
10-20% of people will not change
some people will have to leave the team
Executives have reposed the question:
how do I facilitate a bottom-up
key driver metric – top down
initial response will be emotional
Fast Company article “change or die”
limbic system seat of emotion
decisions are made by this system not the rational side
allow people to use much more of themselves
inhibitor to change: the old plaster syndrome
things go wrong, put in a solution, solution is institutionalized
have to deal with all the injuries of the past
-
Jeff: Leading Change , The Heart of Change: Real-Life Stories of How People Change Their Organizations
Bob Schatz: Managing Transitions: Making the Most of Change
Diana: Surviving Transition
take over conference rooms
build a relationship with facilities
give team both common area and privacy – gradually spend more time in common
might be about owning tools
keep separate tools for email etc.
dev machines don't even have personal logins
Q&A session to HR people
dealing with emotional level
some who were most concerned went to HR directly
Pay attention, watch observer, get awareness up
be yourself and allow others to be self
be patient, positive and don't give up
History @ yahoo! - founded in 1995
Show up at work and just build stuff
No cubes
Until late 2000
Can't spend anymore
Impose control
Hired consulting firm to impose control
The waterfall for 4 years
Last September – Tobias Mayer – organized brown bag by Jeff Sutherland
Email went out
Pete attended along with 100 engineers
Two hours – blew off meetings
We all have “muscle memory” of small nimble projects that just worked
Pete invited Jeff S. to executive team meeting
The execs often do know what is going on
Potentially revolutionary
Exec team said “ya!” - method to madness that we used to have
December groundswell of engineers and executives – never happened before
Six project teams wanted to start
Esther Derby, Mike Cohn, Paul Hodgets brought in to inform
Four teams left
Deal: support in every way needed in exchange for completed training, coaching, one sprint followed religiously then choose
Scrum pilot program started in early Feb.
Tried bribing Ken, he recommended Paul Hodgets
Paul is light touch, close to teams
Mike Cohn – like a football coach
End of first sprint did survey (anonymous)
Team members and managers
90% response rate
Amazed
First sprint really tough...
but there's something here
How much done, cooperation, quality of work life all had substantial improvement
Didn't want to stop
Quote from manager who was sceptical “I don't know how they did it but what those guys accomplished was remarkable.”
Word spread
More teams wanting to do this
Brought in Gabby Benefield
Head of Scrum practices
Now we have 8 teams + more in the queue
From six months so far -> 15 observations for big companies
1.start with the teams that want to use Scrum – scattered seeds of knowledge widely and watched for the seedlings – everyone on the team must be at least open to it working – skepticism is healthy
2.call it a pilot program – we're not migrating to anything – creates air cover for the messiness – purpose is to learn the lessons – never stop being a pilot – stop when no more teams raising their hands – then examine why – teams that raise their hands have the most pain – Yahoo is classic matrix organization with functional silos – what about interaction between agile and non-agile: non-agile teams become enthusiastic about moving to agile
3.change is scary to many people, Scrum is really scary – resistance is “pre-conscious” - presented as common-sense practices that teams choose to take on – not management forcing it – all of this is about people – people change at different speeds – Scrum is like Indian food: some will love it right away, some will need to try it a few times – some of the biggest skeptics have evolved into biggest supporters – actively managed this – ground the exercise in honesty, openness and realism – gives people room to change their mind – don't create us vs. them
4.Patience is a Virtue – err on the side of rolling out fewer teams and spending time getting it right – every team has had issues – don't risk over-extending and having it collapse – at start many more evangelists for failure and news of failure spreads quickly – over budgeted for working through systemic issues that are made visible in teams – what is us, Us and Scrum
5.Find the middle path philosophically – scrum pragmatists – revolutionaries tend to be the purists – incredible passion – but also they can feel anxiety as transfer from guerrilla warfare against the system to being the system – how to keep the purists involved – revolutions eventually become mundane reality – people are messy, scrum is messy – no utopia where things work perfectly – pragmatists are very effective at carrying this out – but prone to compromise and corner-cutting – creative tension between purists and pragmatists
6.Set a high bar and set low expectations – force teams to take personal cost of training – very hard work, very expensive, may not work for you – people know when they are being sold – lots of pain and work moving a team to scrum
7.Scrum is hard – surfaces lots of nasty stuff – every pilot has had to deal with some big nasty issue – make sure people are prepared – emphasize this pain is scrum working not the opposite – was this problem there before, and will fixing it make things better – never had a team that said Scrum created a problem – be ready to go on a rescue mission – sometimes teams need help, can't always solve things on their own – what kind of help? - more facilitative help but can include direct suggestions – teams need to build their muscles
8.get experienced help – mechanics simple, but still help is useful – but outside perspective can be very positive calm reassurance – fear of looking like an “ass” and being the “Scrum guy” as a leader – spot the small stuff that can be very telling – comes with experience
9.your enemy is your friend – spend the most time with the people who like scrum the least – the detractors can have much more impact in early stages – make them informally part of the team – take their problems and ask them to help fix them – some of them might have some good points – figure it out early – don't let battle lines get drawn
10.be prepared to use guerrilla tactics to get things done – some policy/strategy stuff – but many are just little bumps in the road – e.g. Conference room assigned but had a big conference table so couldn't stand up – tried to get table moved by facilities – got email “thanks for getting table moved out” - table disappeared one weekend – someone came in and tipped over table and moved it out – don't know where it went
11.make good information more accessible than bad information – rumor mill will go into overdrive – email updates, brownbags, top 20 myths, FAQ – continuous flow of good info
12.find your evangelists – build a network of scrum proponents in every group and level of the organization – knowledge of reality both good and bad – able to speak with candor – including bad news – anchor since day one – if scrum is as good as it needs to be, it doesn't really need me to defend it – individuals using it should inform the organization about the reality
1.Senior executives – need to have an advocate but have to be careful with it – with a single statement that person can set the tone – danger in getting exec too excited – can lead to top down imposition
1.Story about “Let's Go” travel guides – every student reporter is fired every year – publisher has no power because temp work – used very scrum-like process
2.Something connected to a prior experience
13.Make the result visible – distributed results of survey to the rest of the team – this is the good, this is the bad – made people feel comfortable to enter the conversation – this is Scrum fixing itself
14.The urge to tinker is great – everyone has a way to improve scrum – some are necessary adaptations – a lot of them aren't – e.g. We're going to split out the eng, design and qa sprints (subtle reversion to waterfall), want SM and PO to be same person, want to use some practices – say “That's fine” but reflect and compare – make very clear what is and what is not Scrum – say “using agile practices” - don't let Scrum's name get sullied by experiments that aren't scrum – but experiments are still okay
15.Scrum will always be messy – Scrum is not about cleanliness, its about reality – people are insensitive and inconsistent – make mistakes and bad choices – Scrum makes the mess visible – if it feels too clean it may not be working – even the final product is messy – there is no utopia we will arrive at
Biggest problem:
first question: what does it stand for? What is the acronym
propose making it an acronym
Mad About You – Society for the Complete Ruination of Universal Mankind
Screwing Customers Royally with Methodology
Accenture as experts in a time of trouble
SVP of performance improvement @ Wildcard
6 sigma and Lean
Brian Stallings from Citibank IT
took four weeks to see results were much better – CEO took whole org to scrum immediately
What is the light at the end of the tunnel? Train? End of tunnel?
You need a leadership that will be the light
Vital stats
founded in 1997
move from cash to electronic payments – whitebox of gift cards
prepaid payment card services
2004 revenues 57mil 40-50% growth per yearsglobal
2004 – 3.45 billion in transactions – 6 second response time
1.process
2.technology
3.scrum teams (operational) everyone using it
4.people
5.org and infrastructure
6.client involvement
7.culture, behavior, morale
8.competitive advantage
1.Strategic Alignment
2.Organizational development – team building
3.Organizational analysis – metrics what is really going on?
4.Implement for Results
1.Symptom -> leap of faith -> solution
vision values and mission
process boundaries and accountability
goals indicators and targets
participation, buy-in and ownership
communications: structure and process
Lessos learned:
+strong executive support and review
+professional coaching and guidance
+consistent scrum practices
-WCS Culture: “get it done no matter what”
-recreate what we just threw out
-good is the enemy of great
team building and dynamics
roster roles and ground rules
expectations and concerns
interpersonal skills and meeting effectiveness
communications: metrics and alignment
Lessons Learned:
+strong review process
+learning organization (releases) – raising the bar means controlled release of the process improvements
+time boxed meetings
+team selection (teams initially had a team lead with 6months, a totally new scrummaster and 4 contractors)
-PO wanted to “own” the team
-lack of shared accountability (lack of collective knowledge of state of tasks)
-we're different, “our client expects...” - clients are exposed to “dirty laundry” through the daily scrum as chickens and they love it
selection criteria & ROI
process and tools
clients, suppliers, products and services
resources and portfolio management
communications: available and consistent – e.g. Mandate on use of Primavera for communication
Lessons Learned:
+Utilized Primavera for Scrum Template
+Staffing Models Reflect Backlogs
+financial benefits – able to move from $150/hr for dev to $60/hr only ask 2 weeks notice to shut team down
+client involvement
- ROI responsibility
-poor forecasting of Start and Due Dates
-valuable early weeks wasted waiting for client decisions
scrum planning and launch (2 weeks)
product backlog and estimates
sprint planning decomposition and review
agile programming tools
communications: daily scrum meetings and burndown charts
Lessons Learned
+introduced launch checklist
+consistent backlog and decomposition format
+application code collisions
+operational bottlenecks exposed
-overall sizing estimates were poor
-didn't require burndown charts immediately
-financial impact of a scrum team
focus on process metricsMay 11, 2005
Appropriate Metrics
May 10, 2005
Steps in Making a Decision
2. Establish Focus and Boundaries
3. Identify Options
4. Choose Among Options
5. ImplementInformation Radiators
May 05, 2005
Change is Natural - "Embrace Change"
Responding to change requires a major mental shift for many people that is difficult and takes time and environmental support. People are often penalized socially or formally for being flexible or adaptable. This quality can appear to be “wishy-washy”, uncertain, indecisive, uncommitted or even rebellious.May 04, 2005
Asymmetry of Knowledge and Abuse of Agile Practice
April 30, 2005
Pair Programming in Software Development
April 18, 2005
Book Review: "Good to Great" by Jim Collins
Some of these concepts are very close to the underlying prinicples of agile work. For example, in the Scrum methodology, the first five principles are all represented. The Scrum Master embodies some of the attributes of level 5 leadership. A self-organizing team gets the right people in the right position. The daily scrum and the sprint planning meetings are designed to help the team confront the brutal facts. The sprint goal embodies at a local level the simplicity of the hedgehog concept. And the practices in general are a manifestation of a culture of discipline.
Who Should Read this Book? Anyone interested in creating a lasting positive transformation in an organization should read this book. In particular, individuals who are coaching teams or organizations should read this book since the concepts also appear to apply at a sub-organizational level.
Posted by Mishkin Berteig at 07:29 PM | |