I will be at the Agile Development Conference this week. Ask for me at the ThoughtWorks booth if you are going as well.
The business users have a language that is poorly defined with multiple meanings for the same word and multiple words for the same meaning. One of the aims of the business coach is to establish context between the development team and the business users. This often requires the business coach to clearly define the business language used by both. This is normally done using a business model (simplified object / entity relationship model ). Sometimes this involves the business coach helping the business user to unlearn their imprecise vocabulary and then learn a new precise one.
We all have different meanings for words. The meaning is only valid when considered with the words and experiences that the word is related to. Those relations will be different from person to person. The business coach needs to understand that all people have different meaning for the same word. This gives them the starting point for the common vocabulary that they will produce. i.e. A mess of words with little or no common shared understanding.
Sounds fun. It certainly is.
I am currently reading Introducing NLP by Joseph O'Connor. It is the first NLP book I've read that actually explains to me what NLP is and how to apply it. It is a book full of ideas. I will be rereading it straight away so that I can more fully understand it.
In the chapter on Loops and systems, it presents a model that has current state and desired state. Then there are tests to compare the current state with the desired state. If the test indicates a difference between the two, then resources are applied to chage the current state. This chapter then moves onto discuss learning loops..... Does this sound similar to anyone? It sounds, looks and feels like Test Driven Development to me. We have a set of tests that specify the desired state. We then change the code (from nothing to begin with) until the tests show no difference between the code and the desired state. It supports my theory that "Agile is a Learning Pattern"
I have started to put my reading list on Book Shelved
I have not written any reviews yet though.
O.K. Dave ;-)
Another difference between the UK and Germany was the approach to security. Like America, the German security insisted that travellers put their shoes through the X-Ray machine. UK security did not. Perhaps the UK Security think it is too improper to suggest such a thing or perhaps they are a bit more relaxed about security.
As an aside, humans are incredibly ingenious and can turn many things into dangerous weapons. For example, a bottle can be smashed and turned into a nasty weapon. Bottles are still sold in airports past security.
The only way to remove the security risk is to prevent everyone from travelling.
It is a misguided policy to attempt to increase security to "fight" terrorism. The only way to remove terrorism is to remove the conditions of injustice that cause terrorism.
XP 2004 was held in Garmish which was a train ride away from Munich Airport. Something that I noticed was that a lot of people take their shoes off on the train. This is something that I have rarely seen in the UK. The Germans put comfort ahead of appearance. Good for them.
At XP2004, Someone (Goldfish attack!) mentioned that only 5% of people can think in terms of abstract models. This is probably why we get such poor feedback from the business when we present them with models.
I explained our approach to the requirements on my current project. The business users have specified a list of representative trades. The business analysts are preparing the trades for sessions where the business users are specifying how they want the system to react for each trade. In effect, they are specifying their requirements in the form of user acceptance tests.
Henry C.T. Andrew suggested that the business coach should present the users with the abstract model and then the concrete results. e.g. 2 + 2 = 4. This way the users would not need to think in terms of abstract models. They could express their requirements in concrete terms that they are more comfortable with.
I said that it would be better to present the abstract model and then 2 + 2 = ?
and et the business user to specify "?". There would be useful learning from the exercise of discussing the answer. The discussion might be "Its four", "No, its four point zero zero to two decimal places", "No, it does not really matter, four is close to five so lets round it up to ten."
At the XP 2004 Customer Panel, Angela Martin said that in most projects she had interviewed, the XP Customer was massively overworked. Sometimes they were working 80 hours a week.
A couple of strategies for overworked Customers:
1. This is a demanding full time job. Do not try to do it on top of another job.
2. Focus on coaching rather than writing documentation. It is a much more effectively and efficient means of transferring knowledge.
3. Get a business coach to help out. The business coach can help with structure and get the most out of the Customer's precious time.
4. Pair on the learning (analysis). If this requires writing up. Get the other person to do it.
5. Appreciate that anyone who understands the question can answer it. Get someone else, ideally a member of the development team, to resolve the issues that arise out of the learning sessions.
Tammo Freese sent me the link to this excellent article on XP and Real Options.
Real Options are going to be increasingly popular in software development.
There are so many interesting Blogs but it is difficult to keep up with them. Do you think it would be a good idea to start a wiki that lists all the Agile Bloggers.
The Blogs could be listed by Category. Developers, Coaches, Testers, Project Managers, Lean, Theory of Constraints.
Perhaps we should host the list on book shelved. People could then write reviews about the Blogs.
Thoughts?
I am sitting in Garmish train station waiting for the train to take me back to Munich. It is a beautiful morning in a beautiful town. The sun is warming my back and the view in front of me is of the mountains.
Even though it has been a bit rushed, it has been a wonderful experience. XP2004 has been a success for me on many levels. I had some fun on the XP Customer panel and I drank some beers with old friends and new. It was such a good night that I cannot remember most of what was discussed. I met a number of fellow Bloggers such as Laurent Bossavit and Mike Feathers who I have only known by name until yesterday. It adds so much more meaning to the work when you know the person. We had a brief chat about Blogging and Mike Hill said that he prefered Wikis to Blogs because the Blog just shows your most recent thought whereas a Wiki allows you to structure your thoughts. I think he might be right. I intend to restructure my Blog and bring all my thoughts together on a couple of Blogs that link all my earlier posts together.
The most striking thing for me is that XP and Agile are a community. It is an inclusive group of people who welcome anyone to join. David Putnam from exoftware and I joined a group of about six sitting outside a bar which included Mike Hill, Mike Feathers and Diana Larson. The late afternoon sun was shining down on us as we sat under the trees. By the time we left for the Irish Bar, there was a crowd of about 20 to 30 people chatting and enjoying each others company. I got to renew my acquiantance with Diana and Martin Fowler as well as chat for the first time with David. As always, exoftware, an Agile Coaching consultancy, were well represented. I chatted with Brian and Sean, the two brothers who own the company, and agreed to put an advert on this Blog if they bought me beers all night. (They kept their part of the bargain, check out the site to see I kept my part.)
One of the messages I wanted to get out is that we are a community. We agilists are not competing against each other. I think everyone agreed. We would rather work with each other than work with “Waterfallists”. In any event, we will all be working for IBM/Microsoft/McDonalds (when they diversify into “feeding” the mind as well as the body) in ten years anyway when Agile is the accepted way of doing software development.
As always, the real heart of the conference lay in the conversations between the sessions. The sessions just provided some context to get the conversation flowing. So many ideas my head is spinning.
I was heartened by how many people are talking about business value. The meme for this year’s ADC is “Business Coach”.
I met so many interesting people. Unfortunately I have the memory of a gold fish and cannot remember most of their names.
I’m now on the train headed for Munich. As I reflect on my mad dash (14 hours travelling) from London to Garmish and back again for the one and one half hour XP Customer Panel, I’m just glad I made the effort.
The panel consisted of (from Left to Right) Linda Rising, David Hussman, Angela Martin, Mary Poppendieck and myself. Joshua Kerievsky did a fantastic job of moderating the session. I was terrified and Angela confided in my afterward that so was she but to see my hands shaking at the start had given her courage. We were only allowed to speak when we were holding onto a fluffy kiwi bird toy. The toy was soon criss-crossing the room from the panel to the audience. Only one person in the audience was a customer, most people were developers. More than XP Day 3.
I had planned my opening comments on the train to Garmish. I’m glad I did because nerves meant that my mind went blank the moment the session started. I just read out my planned statement. Once the questions started I got into the flow of things and started to enjoy myself. I had planned my first iteration but after that responded to change over following the plan
Key points that I remember
Angela pointed out that on most of the projects she has interviewed, the customer was overloaded and suffering from overwork (80 hour weeks!!!) whereas the development team were working a relaxed 40 hour week.
There seemed to be agreement that XP is lacking a role. It’s the role that I call a business coach, Mary calls a product manager and others call Proxy Customer or Proxy Developer.
We agreed that there is benefit to be gained from having someone, the business coach, who can help the users decompose their requirements and help build the relationships between the development team and the business user community.
No one objected when I said that there was a place for structured analysis tools as learning tools for the business coach.
Tom Poppendieck defined Use Cases as a user defined unit of business value and XP stories as a developer estimated piece of development. He said that use cases were implemented through a number of XP stories. Joshua Kerievsky pushed back on this saying that there were high level business stories as well as low level developer stories. I like Tom’s distinction. Tom runs an Agile Customer training course which sounds really interesting from its name alone.
Initially Mary and the others pushed back on my “Zero Documentation” approach to analysis. They agreed with the idea when I explained it further that you do create documents, but only when they are “pulled” by the development team or users, rather than as planned deliverables.
Someone (Goldfish attack) asked what we should do to get the business users to attend XP 2005. We tended to agree that the business users would not be interested in attending an XP conference. They would only be interested in their own domain specific conferences. We did agree that there should be more business-focused sessions for the developers at XP 2005. These sessions would be to help developers understand the business more.
We all agreed that an important role for the business coach is to help build trust and respect between the development team and the business. No one disagreed when I suggested that an on-site customer isn’t essential as long as the business respond immediately when they are asked a question. Linda said that trust and respect was one of her patterns.
I drew my classic Know/Don’t Know diagram and explained how the overworked customers could free up time by focusing on knowledge transfer rather than documentation. No one objected when I said that the business coach should focus on finding the questions and leaving the the task of getting the answers to the development team. I got some great feedback on the diagram from Martin Fowler and as a result I will refactored it.
Mary said we should stop thinking in terms of projects and adopt a more disciplined product approach to software. I agree.
There was a discussion on fixed price / fixed scope projects with a general agreement that they a bad way of doing business. (Mary is working on Agile contracts for software)
We discussed the barriers to the adoption of Agile. We agreed that the developers love it and the business love it but the real opposition comes from project managers and middle managers. Angela pointed out that in the successful projects she has interviewed, the project managers support was one of the key reasons for success. I said that I think the reason project managers resist Agile is because they feel threatened and no one has redefined their role. (Check out Sanjiv’s Book on this very subject). I suggested that a way XP could address this was to welcome the business analyst (coach) community and they would then engage the business. The developers and business users could then launch a pincer attack on the project managers with tanks, planes and guns. Someone pointed out that project managers want the best for the business as well, they just need someone to help them understand how they add value.
I pointed out that Agile is a disruptive methodology just like “lean thinking”. I pointed out that the established consultancy’s, like Accenture and KPMG, business models do not support Agile. Of course there was someone from Accenture in the audience :-0 They took it well J
David Hussman and I got together briefly to compare notes. David thinks he is business coach but didn’t have a name for it before. Like me, he is interested in Agile Philosophy and Culture. I look forward to some interesting exchanges. I might suggest we do them on Brian Marick’s new Customer Yahoo Group
The others seemed to have much better ideas than I did. It was a great learning experience with participation from the whole room, not just the panel.
I had the last word at the session by coming up with the pattern ”Have Fun!”
My one regret about the session is that I did not shut up enough to hear more of what the other panellists had to say. I wish I had listened harder to what other people were saying. Its hard though when you are thinking of your own answer to a question from the audience. I need better listening skills.
Tom P took the photos. I will post a link to the photos when he publishes them.
I briefly joined the session on Assessing a project for Agility.
I was a bit disheartened that they wanted to assess Agility based upon the ability of the project to deliver function points rather than business value. The argument was that business value was the responsibility of the business and besides it was hard. I continued the discussion with Dr Peter Lappo and Henry C.T. Andrew, the moderators, at the Garden Reception. We ended up in violent agreement. I promise to draw up the business benefits curve they drew. It really explained Agile well. I agreed to follow up with Henry to develop a business value approach for government and charity developments. They would be based on the three “E’s”. Efficiency, goldfish and goldfish.
The session also asked how we sell Agility to management. I said that aside from the better value from a net present value and real option to quit/change perspective, the real value is the reduced risk and transparency due to production quality code being delivered earlier in the process. Later on at the garden reception I was talking to someone Tammo Freese who had attended a session at XP 2001 session on real Options by John Favaro. Apparently Kent Beck used Real Options to value XP for the “White Book”back then. It looks like I wasn’t the first to see the Real Options in Agile.
I have just invested in Feed Demon. This means I can keep track of all the Blogs I follow.
I realised that my Blogs seem a bit incoherent if read in the order they are presented. They run top to bottom whereas my thought processes run bottom to top.
Perhaps Blog aggregators should give the option to start at the bottom instead of with the most recent entry.
I'm off to XP 2004 tomorrow.
I did a bit of planning in advance of the conference. I have a flight booked, a hotel reservation, a taxi booked to the airport and the train times to get me from Munich to Garmish. My train gets in at 2:30 and I'm on the XP Customer panel at 4:30.
The details though I will let happen to me. I haven't decided what I will say. I will be guided by the Agile Business Coach principles.
How will I determine whether it is a success. Very simple. If I have fun, it will have been a success. Acceptance test driven conference attendance ;-)
I just drove to a friends and back. Whilst driving, I was musing over the principle "Responding to Change over Following a Plan".
I had a plan. To drive to my friend's house and back. I had a route in my head that was pretty well mapped out as well. I had not developed the plan at a micro level. That is, I had not decided to turn left, drive for 100 yards, turn right etc. You get the idea. If I run into an obstruction such as road works, I can chose another route.
I think a high level plan is good. We want to invest about $1 million to develop the application. However my problem is with detailed plan. We will drive the project forward, turn left, on for 100 yards.....
The details of the plan can be left until just before we implement a particular detail.
I suppose thats why I like the word OVER. It doesn't say we should not have a plan at all. Its just that we want to be able to respond to change. The trick is to get the balance right in terms of how detailed the plan is.
I say paint the plan with a broad brush, the broadest you can find.
The advantage of a business value driven approach to software development is that the development project focuses on the features that generate the most value for the business. Take the situation where there are two features "A" and "B". Both features are about the same in size and will take the same amount of effort to develop. However, feature "A" generates 90% of the value whereas feature "B" only generates 10% of the value. It is obvious that the focus of effort should be to develop "A" and not "B".
Without a break down off the business value between the requirements, the requirement looks like both "A" and "B" are equally weighted.
A fairly convincing argument I hope for applying a business value driven approach. See here for our Article on business value.
Writing a functional specification divides the project between the consumers (The business) and the producers (The Development Team). The developers say they will only develop that which is written in the spec and the users want the app to work even though it might not be specifically written in the spec. This causes a tension between the business users and the development team. This tension is normally "managed" using a change control process. From experience, users will cram as much as they can into the specification because they know changing it at a later date will be so painful. The result is "scope bloat" - A whole load of requirements that the business do not really want. Unfortunately, decisions about the project will be significantly influenced by the scope bloat features even to the detriment of the core requirements. This is one of the advantages of a business value driven approach, that it focuses the effort on the important features.
Agile takes an alternative approach. The developers say "We will deliver good stuff. You just tell us what you want for the next iteration." We will decide what to deliver in the following iteration just before we start it. It means that there is no need for a change control process. Hence more harmony within the extended project team.
After all, the users are learning about the business problem just in the same way that the developers are. So of course it is naturally that they will change their minds as they get to understand more about the problem.
Allan Kelly rightly points out that the learning does stop at the end of the analysis phase. In fact the emphasis shifts from the business coaches learning to the development teams learning, when the coach shifts into coach role (They should be coaching all along rather than build up a batch of learning). The development team and business will continue to learn about the problem as they develop the solution. I recommend checking out Allan's article on Software Engineering and Organisational Learning.
Allan Kelly rightly points out that the learning does stop at the end of the analysis phase. In fact the emphasis shift from the business coaches learning to the development teams learning, when the coach shifts into coach role (They should be coaching all along rather than build up a batch of learning). The development team and business will continue to learn about the problem as they develop the solution. I recommend checking out Allan's article on Software Engineering and Organisational Learning.
As you will know from my earlier Blogs, I regard structured analysis tools as learning tools.
The question is "When should analysis (learning) stop?"
Learning should stop when the risk of something significant being missed has been reduced to a level that is acceptable to the project sponsor. Note that the risk preference of the sponsor may be different to that of other project members such as the project manager. It is however the sponsor that is most important. The risk preference of the sponsor will be affected by their trust in the business coach. If the sponsor trusts the business coach it is likely that the business coach can simply tell the sponsor that enough work has been done. Otherwise the business coach may have to do more work in proving to the sponsor that they understand the problem/domain well enough to proceed. This does not mean more documentation but rather more time spent with the sponsor to demonstrate your knowledge about the problem.
From the business coach's perspective. Enough learning means that there are no really bad smells associated with the business domain. i.e. The business coach doesn't have any bad feelings about the gaps in their knowledge. There are no questions that are nagging at the back of the mind.
There will be gaps in their knowledge. After all it is best if the development team resolves the issues rather than the business coach as it helps to build the relationship between the development team and the business. It is more a matter that the business coach does not feel there are anymore significant questions they have missed rather than questions they have not answered.
The first by Allan Kelly who I met at XTC last week. I The second by Seely Brown. It was in the reading list for the first It is interesting to note that the Seely Brown Article is on the PARC site even though he left a couple of years ago.
I just found this page for all you Seely Brown fans
One of the most important things to establish with a document is "Who is it for?"
The Agile Business Coach suggests a zero documentation approach to analysis. The aim should be to have zero documentation as deliverables but rather build the domain knowledge of the team so that they can interact with the business.
I have discussed this approach with a few business analysts. A couple of them suggested that the act of writing the document was a way of them structuring their thoughts to make sure they did not miss anything big and obvious. The document then becomes a persistent store of their knowledge in case they get assked something they cannot remember.
So if your aim is to write the document for yourself to be used as a persistent store, then it might serve a purpose. Do not aim to write them for someone else though or you will end up in a review cycle nightmare.
Its the endless number of revisions to get it just right.
From my experience it is not the writing of the document that takes the time but rather the review process and endless corrections in an attempt to get it one hundred percent right. That is why it is best not to have the document in the first place.
It is better to deliver 80% of the business value for 20% of the effort than to attempt to deliver 100% of the business value for 100% of the effort.
It is sad but true that most Business Analysts justify their existance on a project by generating lots of documentation. And the more the better.
When someone asks what a business analyst does. Normally the answer is "Writes the functional Spec." Even though this revered document is normally never read by anyone apart from the "Project Analyst" working for the business who demands several rewrites to justify their own existence. Check out NerdHerding for a fairly accurate description of what happens on an IT project.
The business coach focuses on developing the domain knowledge of the project team. When someone asks what a Business Coach does, the answer should be "I don't know but they did something pretty cool because the developers can understand what the business are talking about."
Do not justify your existence by writing pointless documents. Do something worthwhile and develop the team instead.
Does anyone else feel really motivated when their work has some meaning. When you can see the value of the work you are doing, you just fly through it.
The opposite is true. If the work you are doing has no value, then your motivation just disappears out the door, down the street, and into the nearest pub.
Seeing as the work I'm doing at the moment is off the muda scale, my motivation just caused a surge at the brewery.
I wondered whether I should call this entry. "We value process over people."
I have a new manager on my current project. We spent the last few weeks before he joined validating a model of the business with all the business users. The business users are all comfortable with the model. The model consists of a single diagram with about twenty functions on it, a document containing a one or two line description for each function, an object model showing objects only and a CRUD matrix. This had taken very little time to prepare. This is for a programme of work that will cost north of $20million.
My new manager thinks there is too much detail and wants a summary diagram and CRUD. The conversation went along the lines...
Me: "Who is this for. If we show it to the users they will be annoyed that we have taken a step back?"
Manager: "Well there are a group of people who will need this for their understanding."
Me: "Who are they?"
Manager: "Me and my fellow architects"
Me: "So we agree that it is for you, and for your understanding?"
Manager: "Er, yes. We need to show that we are following a rigorous process. We can use your work when we get to the individual projects."
Me (Thinking to myself): Sounds like Muda to me but if the client (my manager) wants it, I might as well get it done and out of the way as soon as possible."
Before I put them into Bookshelved which may take a while, here are my Top Ten books. (You will notice that I can't count).
The Timeless Way of Building : Christopher Alexander
The Accelerated Learning Handbook : David Meier
Lean Software Development : Tom and Mary
The Innovator's Dillema : Clayton Christenson
Agile Software Development : Alistair Cockburn
Managing the Design Factory : Reinertsen
Lean Thinking : Womack & Jones
The Goal : Goldratt
Options, Futures... : John Hull
Slack (My Way of Life) : Tom DeMarco
Practice What You Preach : David Maister
Social Life of Information : John Seely Brown
Steve Freeman pointed out the
Napkin Look and Feel java plug in. The idea is to use the rough look and feel in prototypes to convey the idea that the application is incomplete. It should also encourage feedback from the users. This supports the Fuzzy Versus Hard approach I suggested for encouraging negative feedback.
Just in case you thought Iraq came about as a result of 9/11.
Rumsfeld and chums have been planning it for a lot longer.
Check out this
Does anyone else seem to find that they hear about something for the first time and then all of a sudden it is everywhere.
Take Seth Godin as an example. I first heard about him a couple of weeks ago by following a link from a link from a link. Then
* An hour later I read about him on Clarke Ching's blog .
* Today Alan Francis asks for Purple Cow back as part of a book Amnesty.
* Today I was sent a summary of one his books by Bizsum ( They have a one month free subscription )
Take Dee Hock as another example. Never heard of him until a few weeks ago. read his book "Birth of the Chaordic Age". Then the next book I read, Synchonicity, has a review on the back by Dee Hock.
Is this weird or just another example of a scale free network.
Just finished reading Synchronicity. I'm left with the feeling that I missed something in the book. The ideas are presented in the form of a journal so I perhaps focused too much on the story and not enough on the ideas. There are a couple of interesting ideas.
Leaders as Servants
Just go with the flow and it will take you where you need to go.
I have just created a page on bookshelved. I will add my booklist over the coming weeks and months ( O.K. Dave ;-) )
I had another great evening at the eXtreme Tuesday club. I met Allan Kelly who is interested in Organisational Learning. Something that I am going to have to find out more about.
There was also a discussion about naked objects. Perhaps these are a business coach prototyping tool of the future. Sam at TW is working on a nicer gui for these called Fig Leaf.
As an aside. I found this great post by Benjamin who describes our meeting a few weeks ago. I wish I could write as clearly.
When we first started our thinking on the role of the Agile Business Coach, Andy and I asked ourselves the question "Lets assume that there is a development team working alongside the business users who are writing stories and assigning priority to them. What value would a business analyst add in that setting." Our thinking lead to the Business Coach Role. Someone who coaches the development team in the business domain and problem, and coaches the business in how to interact with the development team - writing stories and specifying tests.
I sat with a group of project managers and asked a similar question. "If we have a self organising team who allocate work amongst themselves. What value does the project manager add?" I received a lot of criticism for asking the unthinkable question and was labelled a trouble maker. This is because a lot of project managers are uncomfortable with the question and the possible answer. There is a role for project managers but it is not the command and control role that many enjoy today. They add value by creating a gelled team that delivers business value. At ADC last year, the title suggested for a project manager was "A Behavioural Coach". I like this title. They are the person responsible for encouraging positive behaviours and discouraging negative behaviours. The project manager also ensures that the business value is delivered into production and clears the way for the team to get the job done. Certainly not the current role.
If it upsets people when I ask "What value do project managers add?". Perhaps there is a reason for the unease is the same feeling the dinosaurs had.