Someone pointed out that some of the software development methodologies have a suspicious names. Methodone (Method one from Accenture), Crystal METHodology from Alistair.
Perhaps the names reflect the reality distortion effects of software development.
In order to guarantee the success of business value driven software development, I am considering a name change to Profit Centred Process or PCP for short, either that or Angel Dust
Yesterday was my best day at ThoughtWorks so far.
I started the day in the Monmouth Coffee shop with John, our all too cool, HR guy, before another trip to the coffee shop with our MD to discuss stuff.
Then I had lunch and set out to meet up with Dan North, the JBehave guy. Dan was late so I sat in a book shop reading the latest Authority Graphic novel ( A bit of mind popcorn ).
Dan and I did two hours of pairing in a coffee shop. We did a spike on something for JBehave. It was two of the most rewarding hours I have spent so far at TW. I'll tell you more about it when Dan is ready to reveal his work to the world.
Here is a presentation that Rachel Davies gave on User Stories at the Thames Valley Agile Special Interest Group. Worth a look
Found this tutorial on Use Cases by Rebecca Wirfs Brock.
I just read an article on Use Cases on Rebecca Wirfs Brock's website. She has already linked conversations with Use Cases. It was obvious I suppose. I'm not sure if anyone has linked Mock Objects to context though.
It is no surprise I started thinking like this as Joe Walnes is a big fan of Rebecca's work. I have been brain washed or was it another case of legitimate peripheral participation to give me the concrete experience followed by my own modelling. I must test this thinking with Dan tomorrow to complete my Kolb learning circle.
I spent the day in the London ThoughtWorks office.
I was lucky enough to spend most of that day with Joe Walnes and Dan North.
Dan and Joe explained CRC Cards to me as a way of introducing JBehave. Dan then spent a couple of hours working through an example of behaviour driven development. He also showed me how JBehave makes use of Mock Objects. "VERY nice." to quote Joe.
We spent lunch discussing these things. Joe mentioned that Rebecca Wirfs Brock now calls them RRC cards... Role-Responsibility-Collaboration Cards. The role is the same as the view in model-view-controller or my use of metaphor
My interest in JBehave is not from a developer perspective. Rather I am trying to work out how we can apply the technique to recording analysis. I am keen to see an analysis tool that it used to capture the concrete examples that we use to develop our business models. I am also keen to see Eric Evan's Domain Driven Design work linked to the work of the business coach. JBehave also makes it easier to do Rebecca Wirfs Brock's responsibility driven design
I spent my commute thinking about it and I believe that Dan is on to something. For Dan, one of the most important aspects of JBehave is that it encourages you to focus on what the class SHOULD do next. This makes the behaviours more easy to read and meaningful in the domain language. It says what the system should do. What is missing from the should is the context. This is provided by the Mock Objects.
However, rather than the class SHOULDdoSomething, it really should read. SHOULDdoSomethingGivenThisContext. The SHOULD really refers to a conversation. Given this context (Provided by MockObjects), the Class/System/Component should have the following conversation. Use cases try to capture this conversation but they lack the context. The context in BDD is provided by Mock Objects. We need to pull all this together.
Given this context (Initial specified state for the system which is provided by Mock Objects for BDD and will need to be provided by something else for Behaviour Driven Analysis), the system should have the following conversation. The conversation is the Use Case. Even better to use stories and have the Business Coach pair with the developer to specify the conversation. The conversation is the message passed to the system and the system's response.
I definitely see the merging of the Business Analysis and Testing role. I better add Brian Marick to my list of links.
Sorry if this is all a bit jumbled, I am trying to get it all straight in my head.
I think I'm finally getting the object paradigm after eight years. It took me five years to understand the relational paradigm. Perhaps I'm slowing down in my old age.
My eighteen month old son was playing with the computer yesterday. He was tapping away at the keys and generally enjoying himself even though he does not know what a computer is.
I said "He'll grow up to be a geek."
My EX wife was horrified. "Don't call him that."
"Why? Its not an insult."
"Yes it is." she said.
"Well thats what we call ourselves."
"Then its like the "n" word. An insult appropriated by a minority group as a sign of defiance."
"Er, something like that."
So I'm proud to be a geek but it is a label that I'll only accept from other geeks. If I'm lucky it will be a label that my son will proud to adopt but if his mum gets her own way he'll be a ballet dancer instead.
I had a ah ha moment writing the post on waterfall and change control processes.
Most IT project managers are suffering from cognitive dissonance. They are trying to satisfy the needs of their business but they are being rewarded for sticking to a plan. Their IT departments are rewarding the wrong behaviour, delivery according to plan / budget. They should be rewarding project managers based upon delivery of value to the business. Perhaps the business users should set an IT project manager's pay rise and bonus.
Apologies for the pseudy title but I've been dying to use it since ADC. I got it in eventually Solveig ;-)
Andy and I took a long time to write our first two articles. For the negative feedback article, I took a new approach. I got a professional editor to help me. Solveig did a brilliant job of turning my rough ideas into a polished article in double quick time. If like me you starting out on the writing road, try an editor for size. It certainly is money well spent.
One of the great things about the internet age is that you do not need to be close to your editor. I am in London and Solveig is in Denver. IM and e-mail are making the world smaller by the day.
This post is in responce to Kerri Rusnak's comment about my article on negative feedback.
I do think the six positive pressures are a result of traditional waterfall methodologies. On a traditional waterfall project, the IT managers will attempt to control change by getting the business sponsors to sign off on the requirements and then use a change control process. The aim of this is to transfer the risk (and blame) of the requirements change to the business users.
This is particularly important when the development takes place across a contractual boundary. The software vendor will demonstrate great amounts of effort (evidenced through thick and detailed documentation) to ensure the requirements are right before development starts. They will then charge for any deviations from the requirements. I have heard it said that some software developers respond to tenders by putting in a low, loss-lead, bid for satisfying the initial requirements, knowing that they will make the real money from the change control process. The nature of waterfall projects with their change control processes is that they do not care if the requirements are correct because the change control process will pick up any changes.
Change control processes are really change prevention processes. I know from personal experience that you want the business to sign off on the requirements so that development can start. As a project manager you are under pressure from your IT management, who set bonuses and pay levels, to deliver according to the published plan. When the users want to use the change control process, you always give them the choice of having the change or hitting the deadline (like there was any chance of that because your IT management already halved your delivery schedule). From the IT departments perspective, Any delays to the project due to change control are the fault of the business for changing their mind. IT have washed their hands of change by getting the users to sign off the requirements. The business do not see it that way. I remember one instance where I asked the business head to sign off the requirements. He agreed but said that he reserved the right to change his mind at any point.
I was just musing on my article on negative feedback. Something I failed to mention was that the best feedback comes from getting some software into a production environment. Analysis is really about getting information earlier than you would otherwise if you followed a strict Agile process. The article refers to that early information.
In response to Jason Yip'scomment on my business value post.
Organisations should always be alert for disruptive technologies that will take their revenue streams. Investment in disruptive technologies should be considered an investment to protect against revenue loss. An organisation should invest a small amount in a number of potentially disruptive technologies until it is apparent which one will dominate. This real option approach is the one that Microsoft took in the early 1990s when it was unclear which operating system would dominate the PC market. Microsoft famously developed products on UNIX, OS/2 and others as well as its Flagship windows product. That way, if it failed to win the operating system war, it would still have products in the office automation space.
It looks like a revised version of Andy and my article on business value might be published by Cutter.
For me, the most important line of the article is the definition of business value. "An (IT) project creates business value when increases or protects cashflow, profit and return on investment in alignment with the strategy of the organisation.
Lets take the magnifying lens to this statement.
"increases or protects cashflow, profit and return on investment"
Profit is increased/protected by increasing/protecting revenue or reducing costs. Return on investment is increased/protected by increasing profit or reducing investment. What this means is that the project should increase/protect revenue or reduce costs.
"alignment with the strategy of the organisation"
To me this means two views of the strategy. The maturity view and the differentiating/critical view.
The maturity view splits a product / market into three phases. Initially, the market will be in inception. During this phase the focus is revenue and market share. Then during the middle age of the market, the focus is on both revenue and cost. Finally, when the market is mature, the focus is on reducing cost and protecting revenue.
The differentiating/critical view* classifies the businesses within an organisation (or even application) as differentiating or non-differentiating and mission critical or non-mission critical.
If a business is differentiating and mission critical, the organisation should invest and excel. An on-line morganisation's web site should fall into this category.
If a business is non-differentiating and mission critical, the organisation should seek parity with the market. They should do the minimum to comply. General Ledger projects fall into this category.
If a business is differentiating and non-mission critical, the organisation should seek a partner to handle this service or product for them. An example of this would be for an on-line retailer to find a partner to handle foreign exchange transactions for them so that they can offer their products in the local currency of the buyer.
If a business is non-differentiating and non-mission critical, then it should receive the minimum of attention from the organisation. An example of this is the on-line sandwich ordering service offered to staff.
Hopefully this makes things a bit clearer.
*This model was introduced by Niel Nickolaisen of Deseret Books during his presentation at the Agile Development Conference in June 2004
Tim Bacon recommended a great article, "Learning to Lead at Toyota", in the May 2004 edition of the Harvard Business Review.
The article describes the induction process for managers at Toyota. It is an example of Legitimate Peripheral Participation. Effectively, the Toyota manager learns by doing a valid job rather than work in a training environment. He does legitimate work and leans as he does it.
I read "Situated Learning" because it had been recommended by Alistair Cockburn on the C2 site.
It has changed my attitude to how I teach analysis (learning) techniques to other business analysts. It is the way I taught my last two apprentices (Rohit Darji and Sanela Hodzic). In both cases, we worked together on real analysis problems. It seemed an effective way to coach someone. "Situated Learning" told me why it was an effective way of coaching. Both Rohit and Sanela have moved on to bigger and better things. They are far smarter than I who remain a business coach. :-)
I just had lunch with Joe Walnes, Martin Gill and Jeff Santini where we were discussing knowledge, learning and TDD.
I read that software is frozen knowledge. It got me thinking about software development and learning.
Behaviour and Test Driven Development first involve coming up with a behaviour / test results, then modelling software to satisfy the behaviour / test, then running the behaviour / test and finally comparing the actual results to the expected results. This is done repeatedly adding more behaviours / tests. The behaviours / tests provide the context within which the software (model) is valid.
This is analogous to learning (Kolb's model). We start with a concrete experience. We model the experience. We then run our model and test our model results against our concrete experience and then reflect on the results. Over time, we add more experiences that may result in our upgrading our model. Just think flat earth, sun revolves around earth etc.
As we add more tests or experiences, we find that our model of software / reality is no longer valid. Good developers will create a new model (refactor) whereas poor developers will add hacks to the code to make it work. When we test our model we might find that some of our behaviours / tests no longer pass. It might be that they are no longer relevant or that our model does not capture everything. The most valuable aspect of the system is not the model but the sets of behaviours / tests that provide the context within which the system works. Given the context (behaviours / tests), any number of models could be developed that satisfy it.
Now lets look at what happens with Analysis. Traditionally, business analysts will take concrete business experiences and create a model. They will then test this model against the business experience and reflect on whether its output matches. After a few iterations around the learning loop, the model is signed off by the business and passed to the developers. Unfortunately, the most valuable information, the context, is not recorded and is lost as a result. The context allows us to change the model but still satisfy the business requirement. What we need to do is specify our requirements in the form of tests / behaviours as well as models. Unfortunately I am not aware of any software that supports the specification of a system using behaviours / tests. Anyone care to develop an open source version for me? I think something halfway between FIT and JBehave is needed.
Well I've been quiet in Blogland for a few weeks because I have been working on an article. I just submitted it to the Agile Times so fingers crossed that it gets published.
You can read a copy on Andy's web site here. All feedback gratefully received.
Chris Wrote:
Dan
You are the man in the know when it comes to jbehave.
Someone on my blog has asked me why jbehave is so nifty.
My take is that instead of stating what test conditions a piece of functionality should satisfy, you are specifying the behaviour that the functionality should exhibit. This is a subtle difference that makes it easier to get responsibility driven design.
I know I've got this wrong so would appreciate why you think jbahave is nifty.
Regards
Chris
Dan North Wrote:
In the simplest case it is just a vocabulary change, to move away from the vocabulary of "tests" (it isn't a test - you haven't written any code to test yet!), so yes, you are exactly right. Also, the template word "should" encourages you to write proper sentences, so in your CustomerServiceBehaviour class, that accompanies CustomerService, you have methods like: shouldFindCustomerBySurname, shouldFindMultipleCustomers, shouldThrowExceptionIfNoCustomerFound, etc.
That leads on to agiledox-style documentation, so you can genuinely start writing self-documenting systems. Rather than junit TestCases, which have tests like testGetters, or testDatabase, which are just meaningless.
Also, if a responsibility (a "should" method) fails, you immediately know what the system should have been doing, rather than having to drill down into the method itself to find out what it does. Think of it like writing CRC cards in executable code. You define the Responsibility and Collaborations of a class as you go.
I am working on an article with Steve Freeman on using real options to manage IT project risk.
We had an excellent session last week discussing the subject in general. One of the insights that came out of our discussion regarded technical debt. Technical debt is a commonly used term but it is incorrect. Debt is a fixed amount being owed. "Technical Debt" is really selling a call option. For short term gain, you open yourself up to unlimited downside. The cost of the "technical debt" is not fixed as it would be if it were debt but rather unlimited in the case of selling a call option.
I was re-reading Managing the Design Factory. Reinertson says that if you plot the distribution of actual effort on a task versus estimate, you would expect to see a distribution that showed some tasks finishing early and others finishing late. In reality, what you see is a distribution that shows a lot of tasks finishing on time and a distribution of tasks finishing late. His explanation is that when an engineer finishes a task early, they use the remaining time to look for a bettersolution than the one they have developed. They use up the time that they gained looking for better solutions.
This got me thinking about test driven development (and its more elegant off spring Behaviour Driven Development.). The benefit of test driven development is that you know when you are finished with certainty because all of your tests / behaviours go green. You do not need to look for a better solution because the one you have developed is good enough. Also, you have probably been refactoring as you go along so that the technical debt is not too high.
I suspect that test / behaviour driven development will result in tasks finishing early as well as late. This will make the estimates more accurate rather than always being on the low side.
It would be interesting to see if anyone has done some research on the actual versus estimate distributions for normal projects and those developed using test driven development.