April 30, 2005
Pair Programming in Software Development
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
April 28, 2005
Plan Methods Oppose Agile Work Axioms
Plan driven methodologies which attempt to mechanize the process of doing work are in opposition to the three Agile Work Principles.
We are Creators
A plan methodology attempts to define intermediate and end work products independently of the input and effort of those who perform the work of creating the work products. This disenfranchises people from their work and leads to low morale. It also establishes a heirarchy of value for the people working on an effort where those who create the plans are perceived as more important or valuable than those who execute on the plans.
Change is Natural
This principle is usually acknowledged, but is usually described as a "problem" to be dealt with rather than as a basic principle to be fully embraced. A plan methodology has "change control" or "change management" and "risk management" and puts the whole notion of change in a negative light. This approach also disenfranchises people because they are constantly placed in opposition to reality.
Reality is Perceived
Plans attempt to legislate reality. "Thus and so must the project go" results in a constant struggle between the plan and peoples' perception of reality. Plans marginalize the importance of perception on the belief that reality can be objectively understood. If reality can be objectively understood, then it can be mechanistically manipulated. Thus results can be pre-determined without regard for the perception of those results.
Posted by Mishkin Berteig at 10:54 PM | |
April 27, 2005
Eliminate Waste
Waste is the result of activities or environmental conditions that prevent a team from reaching its goal. The opposite of waste is something that adds value (more, faster or higher quality) to the desired result.
The whole notion of eliminating waste comes from lean manufacturing. More recently, Mary and Tom Poppendieck applied this idea to software in their book "Lean Software Development: An Agile Toolkit for Software Development Managers". In this (excellent) book, the authors list the wastes of manufacturing and the wastes of software. Here I have summarized and generalized these types of wastes so that they apply in any situation:
| The Seven Wastes |
| 1. waiting caused by delays, unreadiness, or simple procrastination |
| 2. partially done work or inventory caused by sub-optimal workflow |
| 3. extra processing or processes caused by poor organization or bureaucracy |
| 4. defects and rework caused by insufficient skill, tools, inspection or filtering |
| 5. movement of people or work caused by physical separation |
| 6. overproduction or extra features caused by working towards speculative goals |
| 7. task switching caused by multiple commitments |
As wastes are eliminated or reduced, a team will function faster and with higher quality. However, not all waste can be eliminated. Sometimes waste is legislated, sometimes waste is an unavoidable byproduct of work, sometimes mistakes are made, and sometimes it takes a great deal of effort to eliminate a waste.
In order to eliminate waste, first waste has to be detected and identified, then the underlying causes of the waste have to be identified, and finally changes to the work environment need to be made to both eliminate the cause of the waste and the waste itself. Many agile work practices help with this process.
Value stream mapping is one particular tool that can be used by a team or organization to identify wasteful activities. The team describes the amount of time that work takes to go through each activity in their overall work process. Next, the team determines if each activity adds value or does not add value to the end goal. All activities are subject to speed improvements, and activities that do not add value are subject to elimination.
In order to determine the causes of waste, special attention should be paid to incentives and motivations. Wasteful behavior often exists because there is some incentive for people to do it. Sometimes these incentives are explicit, but sometimes they are the side-effects of other things going on in the team's environment. Changing the incentives can be an effective way of reducing waste.
By eliminating waste, the team will find it has reduced frustrations, and enabled greater productivity and creativity. The team will also increase its speed and delivery of value, and at the same time reduce defects.
Posted by Mishkin Berteig at 07:40 PM | |
April 26, 2005
Truthfulness and the Three Agile Axioms
A few more words are in order about how Truthfulness is the foundation upon which the three Agile Axioms rest. Taking them one at a time:
1. We are Creators
Truthfulness operates at a very deep level for this agile principle. People typically are not aware of their own need to shape reality, to create things. Developing truthfulness helps a person to uncover this fundamental capacity and bring it to fruition. Truthfulness also helps a person reflect on the results of their creative work. This is essential for learning how to become a more effective creator. In an agile team, truthfulness is also essential in developing the interpersonal trust necessary to know when the process of creation is going aright or awry.
2. Reality is Perceived
This principle is the most obvious domain where Truthfulness plays a role. In this instance, being able to express one's perceptions and share them with others in a truthful manner allows others to develop empathy and formulate an honest response. If Truthfulness is missing, then perception will be based on something other than reality (well,... technically it will be based on the reality of an untruth). In an agile environment, where the value of communication and collaboration is extremely high, truthfulness helps to develop a shared perception for a team.
3. Change is Natural
Here the role of Truthfulness is simple: an agile team cannot function if it is not Truthful about change. Recognizing and communicating change so that a team can embrace it and adapt to it depends completely on people being forthright and truthful about change.
Much of my thinking about Truthfulness comes from the study of a passage from the Sacred Scriptures of the Baha'i Faith: "Truthfulness is the foundation of all human virtues." I have also had substantial discussions with other agile coaches about the importance of truthfulness and its key role in developing trust.
Posted by Mishkin Berteig at 11:51 PM | |
Mishkin Berteig attains Scrum Master Practicing Certification
Mishkin Berteig, the founder of Berteig Consulting Inc. and the Agile Advice blog has been listed on the Control Chaos web site as a Certified Scrum Master Practicing. This certification represents acknowledgement of Mishkin's real-world experience as a Scrum Master. Scrum is a collection of management patterns used to implement agile principles and practices for new product development.
Posted by Mishkin Berteig at 12:25 AM | |
April 24, 2005
Agile HR - Sort Of
An article called Are You Ready for the Agile Future presents a brief discussion about the role of HR in an agile organization. There are several very good ideas. The basic idea is that the HR function must adapt to the nature of agility. This in turn means, for example, hiring people that are agile, nimble, adaptable etc.
There are however some mis-steps in the article.
One is an ommission: the HR organization must itself become agile. In one organization that I worked, it took at a minimum 4 weeks and typically 12 weeks to get a contractor onto a project. Three months lead time!!! Now admittedly, it is not easy to bring an individual on-board quickly. However, it is possible. Some organizations I have worked at have lead times for getting new people into the organization that are on the order of 2 weeks including search, selection, administration and orientation. In these organizations, the HR organization maintains an attitude to their own work as service to the larger organzation... and the faster the service (without sacrificing quality), the better.
The article also misses the mark on employee performance. Employees should be measured on their sphere of influence, not their sphere of responsibility. In other words, if a person is a member of a team, their own performance should be judged by the performance of the team as a whole. This mitigates people's competitive habits and positively reinforces collaboration. People should not be measured against their role discription.
One of the recommendations in the article is to "Create selection, testing and hiring criteria that identify diverse, resilient, nimble people." Unfortunately, there is no guidance on how to do this. Here are some ideas: look for people who have moved between projects, roles, employers and even locations frequently, look for people whose resumes contain lots of work that doesn't fit their job titles, look for people who have hobbies and interests that are outside their field of specialization, look for people who have diverse volunteer experience, look for people who ask lots of questions.
(Thanks to Deb Hartmann for the link.)
Posted by Mishkin Berteig at 09:48 PM | |
April 20, 2005
Scrum Scorecards - Measurements to See Progress of Agile Adoption
Two interesting visual presentations of the progress of adoption of Scrum practices. These are marginally software-specific but could very easily be adapted to non-software agile work situations.
http://wiki.scrums.org/index.cgi?ScrumScoreboard
Posted by Mishkin Berteig at 04:31 PM | |
April 19, 2005
Considering the Agile Manifesto and the Axioms of Agile Work
The Agile Manifesto, aimed squarely at software development, is inaccurate when considered against the more general target of Agile Work. The Agile Software Manifesto reads in part:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Having studied Scrum, and attempted to apply agile practices on non-software projects in non-corporate, non-new-product-development efforts, I am painfully aware that the Agile Software Manifesto needs some re-jigging to become the Agile Work Manifesto. My first cut at doing this was to remove the software implications from the above four statements of value. This resulted in the following three statements of value:
Individuals and Interactions are preferred over Processes and Tools
Moving Towards a Valued Goal is preferred over Producing Ephemera
Responding to Change is preferred over Following a Plan
I removed the part about customer collaboration because I felt that it was strongly implied by "Individuals and Interactions" and "Moving Towards a Valued Goal" and because not all efforts have identifiable customers in the sense that a business effort usually does.
Once I got to this point, I started to feel like the statements of value were not really getting to the fundamental assumptions or principles or axioms of Agile Work. I thought quite a bit about each value and what it was really saying at a very basic level. For example, "Individuals and Interactions over Processes and Tools" is partly about the value and power of human beings. What is that power? "Moving Towards a Valued Goal over Producing Ephemera" begs the questions of what is a valued goal? and can ephemera be valued? and for that matter, what exactly constitutes ephemera and its opposite? Finally, "Responding to Change over Following a Plan" is really saying that plans don't tend to work. And why is that? So in order to answer those questsions, I have come up with the following three Agile Work Axioms:
People are Creators
Perception Mediates Reality
Change is Constant
People are creators and that's why its so important for us to improve ourselves and our interactions with others. Perception mediates reality and that's why we must produce results that are perceived as valuable to those who care about our results. Change is constant and that's why following a plan never works... unless you "embrace change" (Beck). But there is still something missing. There is a foundation necessary to make these principles work together in real human environments.
Truthfulness is the Foundation of Agile Work
Posted by Mishkin Berteig at 10:32 PM | |
April 18, 2005
Book Review: "Good to Great" by Jim Collins
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:
- Level 5 Leadership: personal humilty and professional discipline in an organization's leader are the starting point for the transformation.
- First Who... Then What: don't worry about what to do until the right people are in the right positions in an organization.
- Confront the Brutal Facts (Yet Never Lose Faith): careful and honest examination of an organization's current situation is the foundation for finding a path forward.
- The Hedgehog Concept (Simplicity within the Three Circles): discover a simple business concept that people can be passionate about, that works with a single key economic driver and that the organization can be the best in the world.
- A Culture of Discipline: disciplined people removes the need for heirarchy, disciplined thought removes the need for bureaucracy and disciplined action removes the need for excessive controls.
- Technology Accelerators: pioneer the application of carefully selected technologies without relying on technology for transformation.
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 | |
April 14, 2005
Stealth Methodology Adoption
This link was seen on a scrum-toronto list, referring to an e-book called Stealth Methodology Adoption. The title is brilliant, and reflects, in my view, a significant means of adoption of Agile technologies at this point in the maturity of this market.
More projects than not, a small straw poll of friends and family in the business indicated, where Agile was used, used it under the radar screen. Often artifacts were translated into the artifacts of more traditional PMOs, and not a word was said. However, this is a dangerous approach, however necessary at times. The partial implementation of an Agile method, without buy-in in certain quarters can lead to a failure to realize the benefits of the method. If the practices that were used can be blamed, they will. People love to find scapegoats, and there are costs to agile that can be pinned. For example, if the project fails, but TDD was used in isolation, or used badly, it can be held to account as having taken more time than just writing code. If Pair Programming is used in an otherwise traditional project that fails, it can be identified as a halving of productivity. If daily scrums and backlog are used (again, by themselves, or without experience), they can be seen as a failure to gather sufficient requirements and manage to those requirements.
It take subtlety and wisdom to know how much agile to put into an organization, how much visibility, and which particular practices will garner the most benefit in a particular area. Most agile methods have a combination of practices that encourage emergent behaviour. But in many cases, the practices themselves are emergent. The interaction of daily scrums with a scrum master that's working the group to a sprint backlog, and working with a product owner to refine the product backlog for the next sprint - without interrupting the sprint - these have powerful effects on productivity when put together. But, for example, all you have to do is interrupt the sprint and start messing with sprint backlog, or have a product owner / scrum master that doesn't do the work of refining a good product backlog and you end up with developers who don't know which way to turn at a given moment.
Similarly, TDD - if you are writing tests first, but you're not actually defining "done" properly, (ie. sufficiently covering the desired behaviour and edge and negative cases) then you can end up having someone write a lot of tests that are practically meaningless to the code in question. This means that you don't get the benefits of the testing, plus you incur the costs not only of the tests, but also of the wasted time sifting through test code that was not written against the requirements of the interface.
In a lot of these situations, it is judgement that comes from experience that is the real solution. There are few formulae that can practically resolve these questions. The benefits of NOT implementing Agile in stealth-mode, therefore, include the ability to bring in experienced mentors who can provide this kind of judgement to an organization new to agile approaches. Most "stealth agile" projects don't have budget for such. But books like the afore-linked can help communicate some of this wisdom and judgement.
Posted by Christian Gruber at 07:08 AM | |
April 13, 2005
Backlogs in an Organization - Levels of Queues
Queues of work form at three types of levels in an agile organization.
At the largest level is the project portfolio. The queue for this level contains all the projects that are not yet being actively worked upon by project teams.
At the intermediate level is the backlog of project functionality. The queue for this level contains packages of business function or infrastructure components necessary to implement business function. These packages are selected by a project team to fit into a single iteration.
The packages in turn are also elements in a queue. This smallest level of queue contains individual tasks required to implement all the business function and infrastructure that make up a selected package of work. The team members select tasks off this queue based on priority and dependencies.
In many agile methods, the queue management approach is fairly explicit at the intermediate and small levels. However, very little is said about the largest level. Some organizations have solved this by limiting the size of projects:
To be successful, high-tech CIOs recommend biting off projects in small chunks.... Gregoire notes that Dell is growing so fast that at the end of an 18-month project, the company would be significantly different from when it began. "A project has to take less than six months [to complete]. That's the only way we can make sure [it stays] with the business," he says. (http://www.cio.com/archive/120198/tech.html)
Posted by Mishkin Berteig at 06:19 PM | |
April 12, 2005
Agile Household Management
Four weeks ago my wife, Melanie, reviewed a paper I was writing about Agile Work. When I talked to her about it, she asked me why we aren't using these practices for managing our household.
So, we decided to try it. First we developed a starting Work Queue. It includes stuff like "eye appointment for Mishkin" and "build boxes for vegetable garden" and "set up expenditures spreadsheet". It covers any activity that is non-repeating, non-business. Things we need to do with the kids, renovations, travel plans, personal finances, community work, social events.
Once we developed our Work Queue, we agreed that Melanie would be the Queue Master, responsible for managing the work and prioritizing it. So, with a small amount of coaching, she prioritized our rather long list of Work Queue items.
We then jointly decided how much to accomplish over the next week. Our iteration length is one week because we already have a natural rhythm of that length due to my travel schedule for work. We took on about 15 items from the queue, and committed to getting them done.
We have now been doing this for a little more than three weeks. Having this process in place has been helpful in a number of ways. First of all, because it is in priority order, our level of stress about what we need to do is decreasing rapidly. Secondly, we are starting to develop a sense of how much work we can accomplish in a one-week period. By being focused, I am finding that we can get more done than I would otherwise expect. Thirdly, by working in weekly iterations, we can quickly adjust to things that come up. Finally, we have a clear set of expectations about what we will accomplish and this reduces feelings of tension around household work.
There are some things that I would like to add to our approach. We have three young children and I would like them to become involved with the process. The eldest is nearly seven, reads at least three years ahead of his age, and is certainly capable of understanding the text-based format of our planning. I would also like to see how we can incorporate acceptance test-driven work into the mix. Because we are such a small team this may be overkill, but at this point we are not explicitly checking our work at all or setting any sort of acceptance criteria. I can see that jumping up to bite us in the future.
I would be interested in hearing from anyone else who has tried applying agile techniques and practices in their own households.
Posted by Mishkin Berteig at 05:15 PM | |
April 09, 2005
Article on CIO Insight
The online CIO Insight has a great article/interview about a forthcoming book: "The World Is Flat: A Brief History of the Twenty-First Century". Choice quote:
What I am trying to do is say that something important really is happening. The value-creation model is moving away from a vertical silo model to an increasingly collaborative horizontal model, from command and control to collaborate and connect, and that's going to change everything.
This comment alone is a fairly close hit at the essense of Agile Work. The rest of the article is very interesting and touches on many topics of interest relating to globalization, business, information technology, outsourcing and politics.
There is an interesting article at The Economist also about this book. It is very critical.
Posted by Mishkin Berteig at 11:49 PM | |
April 05, 2005
Announcing Agile Advice
At this time, the word “agile” is often associated with software development. Many web sites and resources about agility have this focus (see www.agilealliance.org). However, the concepts and practices that are focused on software (see www.agilemanifesto.org, www.extremeprogramming.org, www.controlchaos.com), are also in use to various degrees under various names in other fields: Lean Manufacturing, Just-in-Time Logistics, The Scientific Method, Creative Problems Solving, and Organizational Learning, among others. Agile Advice and it's sister web site (AgileMasters.com) aim to bring the notion of agility to all types of work: Agile Work.
The Agile Advice blog is meant to be an attractive resource for people exploring the use of agile principles and practices in all aspects of work, community and personal life. Agile coaches, consultants, practitioners, trainers, novices and any other interested people are all invited to participate by submitting suggestions for topics to topics@agileadvice.com.
Agile Advice aims to be practical, useful, and relevant on one hand, and exploratory, thought-provoking, and ground-breaking on the other hand. With that in mind, entries in the Agile Advice blog will fall under five categories: Agile Work Practice, Agile Work Theory, Agile Work Stories, Interesting Stuff, and Announcements. We will also be open to any suggestions, criticisms, or questions about the work we do here. Please feel free to contact us at comments@agileadvice.com.
Posted by Mishkin Berteig at 02:22 AM | |