« April 2006 | Main | June 2006 »
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 | |
May 30, 2006
Integrated Scrums - Paper by Jeff Sutherland
Jeff Sutherland has announced a paper describing the use of the Scrum methodology in a large distributed project. One of the very interesting unique features of this project is that members of each Scrum team were distributed geographically across several locations., rather than having everyone on a single team all co-located at a location. The paper also talks about lean practices and software engineering practices used on the project.
Posted by Mishkin Berteig at 02:28 PM | |
May 18, 2006
Thoughtful Blog
Once in a while I run across a blog that I really like. This one, BrainScrum, doesn't have frequent postings, but I _really_ like what's there!
Posted by Mishkin Berteig at 01:00 PM | |
May 17, 2006
InfoQ Site "Unlaunched"
Okay, so yet more announcements... a new site called InfoQ has been un-launched. They cover Java, .NET, Ruby, SOA, and Agile topics. This site is important for me because... I've got an article published on it. The article is "What is Agility and Why Should You Care?".
Posted by Mishkin Berteig at 02:28 PM | |
New Cheat Sheet: Agile Work for Process Facilitators
Take a peek at our new cheat sheet for Agile Work process facilitators (large PDF). This cheat sheet features a complete set of basic reference information for process facilitators including a great list of questions to ask oneself. There are also a number of colorful diagrams that quickly convey important tools for the process facilitator including methods of dealing with obstacles. We also have a poster-size version available for sale at the Agile Work shop.
Posted by Mishkin Berteig at 02:09 PM | |
Updated Agile Work Cheat Sheet
The Agile Work Cheat Sheet has been updated. It can be found on the Berteig Consulting Inc. Agile Work Resources page. There are layout and formatting changes designed to make it easier to understand. There is also the addition of the seventh core Agile Work practice "Clear the Path". If you are interested in poster-size color printed copies, please check out the Agile Advice store.
Posted by Mishkin Berteig at 03:26 AM | |
May 16, 2006
Talk on Agile Methods
Sorry for the short notice: Tuesday May 16th I will be giving a short presentation (in Toronto) on the use of Agile methods in non-software environments. For more details see http://www.xptoronto.com/.
Posted by Mishkin Berteig at 12:01 AM | |
May 15, 2006
Dearth of Entries
Due to personal reasons, I have lately been unable to keep up with Agile Advice. I'm looking forward to re-starting in a few days. Some things to look forward to include publication of a Cheat Sheet for process facilitators, and some announcements about two new sites with lots of great agile-related content. I'm also queuing up some interviews that I hope will be interesting to readers.
Posted by Mishkin Berteig at 11:58 PM | |
May 08, 2006
A new Agile-Scrum-Lean Product Management Course
For over 40 years I have been developing, delivering and managing technical training for others. Finally, I've done this one for me. And I expect many others to follow. This course is both intensively conceptual and intensively hands-on workshop. The course is being delivered in Boston on May 18 and 19. See www.jconne.com for details. And read on here for more about this course.
My frame of reference is "trust from truth" which is the heart of what I initially appreciated about Scrum Agile Project Management when I first heard Ken Schwaber speak for the ACM in Boston at MIT.
Why has there been such a poor history of trust between management and development teams? This course explains the cause and offers an alternative.
Here are my First Principles:
Reality always wins in the end,
So get there sooner.
Pretending to know what we don't know gets in the way of learning
(and we can't get caught trying to learn it!)
The world runs on trust.
How do you get and maintain trust?
Go back and read the first two. How does this relate to Agile software development?
Please check out my course and help me spread the word.
Thank you,
Jay
=======================================================
Jay Conne Consulting -- Demystification of Technology
Lean/Agile Coach, Trainer & ScrumMaster-Practicing
http://www.jconne.com/ Jay@jconne.com
M: 617-470-5038 617-776-0339 FAX: 617-776-6206
=======================================================
Posted by Jay Conne at 02:26 AM | |
May 05, 2006
Waterfall vs. Agile
In the Agile Dragon, Scott Sehlhorst, a software guy with a mechanical engineering background, has written a very interesting take on the agile approach vs. an approach called "Interaction Design". While I love many of the ideas and even the results that come from good interaction design (check out The Inmates Are Running the Asylum
He posits that agile's greatest strengths come as a result of being able to accomodate change. He also makes a pseudo-mathematical analysis of the cost of change in an agile method. Finally, he asserts that good requirements as derived and set forth by the interaction design method eliminate a fair amount of the need for change.
Agile's Greatest Strength
Agile method's greatest strength is actually about early delivery of working results. As I said in response to his post:
The end of the first iteration (usually somewhere between one and four weeks) results in a little bit of software that actually works. This has the staggering advantage that the customer/sponsor can take that little bit of usable software… and use it! Even if the client waits for a few iterations before the software has enough functionality, and only then uses it, the advantage is still huge. In any process where all the requirements are gathered up front, regardless of how or what is done with them afterwards, there is a large delay in getting the first bit of usable working software in the client’s hands.This delay _costs_. It costs both money and opportunity. Regardless of how stable or unstable the requirements are, agile methods deliver a return on investment much much sooner than any other approach to building software. As you pointed out:
“Customers know what they want - higher profits, greater market share, etc.”
For both of these desires, the best way to get them is by the reduced cycle time that using an agile method provides.
Cost of Change in Agile
Agile methods acknowledge that a customer/client knows a lot of what they want already... and that they even know what is most important! Therefore, the further along in a project one goes, (barring the kind of unforeseen change to which agile responds well) the more stable the resulting product will be.
This emphasis on the early deliver of highest value requirements gives the customer/client even more options: the project can be cancelled early if the cost of building features is higher than the value delivered by those features. This is impossible in a waterfall approach.
Good Requirements and Interaction Design
I would love to see some more careful analysis of this. I don't know enough about interaction design to say if this is true or not, but I do know that this is a big claim that is contrary to much of the statistical evidence. I'm willing to accept that it is possible, but I'd love to understand better the theoretical underpinnings. Scott?
Posted by Mishkin Berteig at 08:30 AM | |
May 04, 2006
Is There a Difference Between Coaching and Training?
Today I had a very interesting and unique opportunity. I went through my agile project management training materials with a single individual instead of a class. Was it training, or was it coaching?
The materials are from my ScrumMaster certification course. They are meant to be delivered to a group of 5 to 20 people in a training seminar setting. Many of the exercises are pair or small group exercises, including three very critical exercises. They are built as a presentation deck (in OpenOffice.org). So of course, I normally use a projector as I'm conducting the course.
Today however, due to low enrollments in a course I had originally scheduled for today and tomorrow, I made alternative arrangements with the few registered participants. One of those participants has accepted a one-on-one training engagement in lieu of the classroom environment.
When I arrived at the office to deliver this course, and after this individual and I did brief introductions, I made a very substantial disclaimer:
1. I've never delivered these materials to just a single individual so I don't know how well they will work
2. Much of the benefit of the course comes from the exercises and most of them we will not be able to do without more people
3. One possible advantage will be an ability to go in-depth on questions specific to this person's concerns
As it turns out, I needn't have been too worried. The course has been delivered numerous times and refined over the past eight months to the point where it is quite effective. There are very few typos or other errors in the materials. The content is very focused to the target audience: potential agile project managers/ScrumMasters/process facilitators. So, much to my surprise, the course went along with it's normal very good timing. Of course, we spent a little less time on the exercises (although we still reviewed them), and we spent more time than normal on open discussion. But at the end of the day, I was exactly at the end of the first day's materials.
This got me to thinking: what difference is there between coaching and training? My training materials work very well in this one-on-one environment. They are a very compressed way of communicating a great deal of information in a way that ensures good comprehension. In fact, in many ways, the one-on-one format is more effective than a class format since I am able to have a very good feeling for the receptivity, comprehension and needs of my "apprentice"... much more so than I am able in a class setting.
My experience coaching is usually a combination of team coaching and one-on-one coaching with a designated "apprentice". This combination is effective for getting a team going with agile and making sure that early stages of team development go relatively smoothly. However, the majority of my high-impact work with the team is in the initial training and in the few other critical points that occur over the course of 8 to 12 weeks. Much of my coaching time is just being there as a safety net while the team and the process facilitator try out the new practices I've introduce to them. As a result, I've recently decided that I will avoid full-time coaching engagements. Instead, I prefer an approach that gives the team and the process facilitator much more time on their own.
So again, this starts to look a little like training: I do an initial 3 or 4 days of high intensity training to get a team going then do a bit of facilitation and "spot" training on specific topics as the need arises.
Conclusions? Well, first of all, I really enjoy working one-on-one, and I also really enjoy the classroom type training. Both seem to me to be very effective and that makes me feel good :-) The distinction between the two approaches is now very blurred for me and I feel that I can offer my clients a more nuanced approach along a spectrum that I wasn't really aware of before. To me that means being more flexible, more agile :-) and hopefully, more valuable.
P.S. I tried to keep the blatant self-promotion to a minimum, but please be aware that some of the links up there are to my business site where I hope you will find something you would like to have me do for you :-)
Posted by Mishkin Berteig at 10:54 PM | |
May 03, 2006
A Brief History of Agile
I was recently asked: "where does Agile come from?" It's easy to answer this on the surface: from software development. But digging a little deeper, there's a lot more going on. This paper by Craig Larman and Victor Basili details a brief history of Iterative and Incremental Development [pdf] (focused a great deal on US military software history). The Agile Alliance is one of the better sources for articles, papers and other resources relating to the history of agile software development.
Posted by Mishkin Berteig at 09:50 PM | |