This link has been in my blog backlog for a couple of months, waiting to work its way into a blog post. But I’m fed up waiting so here it is raw.
What Is Software Design? by Jack W. Reeves on Developer Dot Star
Originally published in 1992, before Java, before C#, before Agile, when Lean was just breaking out of Toyota and before the web (almost) this is a classic piece about software design.
Reeves argues that all coding is design. His specifics might refer to C++ but this could be any language.
Just in case you are in any doubt: I completely agree.
Wednesday, May 05, 2010
Tuesday, May 04, 2010
Falling off a Log live!
Bookings are now open for my talk to Software East in Cambridge later this month (20th to be exact.)
There is a £10 charge but you do get buffet, I’m told places are limited and there are quite a few bookings aleady.
The talk is entitled “The Falling off a Log theory and other observations on the software industry”. Think of it as the road-show version of Falling off a Log.
There is a £10 charge but you do get buffet, I’m told places are limited and there are quite a few bookings aleady.
The talk is entitled “The Falling off a Log theory and other observations on the software industry”. Think of it as the road-show version of Falling off a Log.
Saturday, May 01, 2010
Brain dump on team boards
I was helping a team set up their board (white board, Kanban board, Scrum board, call it what you will) for Agile working the other day and it dawned on me I use a whole bunch of heuristics I’ve never seen written down. So here goes:
- I like magnetic white boards best myself but I’ve seen teams use walls, cupboards and flip charts too. The important points are: big, visible things you can stick other-things on it.
- I prefer to use index cards but many teams use Post-It type stickies. If you use index cards you need a means of sticking them to the board which is where the magnets come in.
- You can divide the columns: classically this is To do, In Progress and Done. Of course Kanban teams use many more columns.
- At first I used the same dry market pens to mark the columns as to make notes on the board. The trouble is these lines tend to disappear. This is a particular problem with Kanban teams who have more columns and so more movements to make. So now I use coloured electrical insulation tape to mark the columns. This is much easier to see and lasts a lot longer.
- Leave space on the board to include Team or Project name and the end date of the iteration. You might also find space to keep a burn-down/up or cumulative flow diagram.
- You don’t need a very big board: I normally use 120cm x 90cm, again Kanban teams tend to need bigger boards because they have more columns.
- You can buy a suitable board from most stationary suppliers for less than £100. If your company can’t afford this (or won’t pay) you have problems which Agile isn’t going to fix.
- Remember to buy magnets, dry wipe pens and something to remove the permanent market someone is going to put on there eventually.
- Coloured magnets are fun but so far I’ve not found using the colour of a magnet to convey information hasn’t been worth the extra effort
- Boards are usually mounted on the wall or a stand but, I prefer them to be free standing because you can carry them around. If you have a meeting in another room you just pick the board up and carry it there. And its a team exercise to move it.
- We had an accident with a board once: it was hit from behind at the start of the planning meeting and everything came off. But that turned out to be good, we looked at everything in more detail. Sometimes I now remove everything at the start or during the course of the planning meeting and only replace it if I need to.
- Don’t put designed on your board: there isn’t enough space. By all means have another board for designs.
Saturday, April 24, 2010
Business Analysis Maturity Model
One of the important, but often overlooked, roles in any software development is the “needs” guy. I put it that way to be as general as possible. Its the role which decided what the customer/end-user actually needs (sometimes wants but doesn’t need).
I’ve blogged before (many times, The Product Owner role (August 2009), Requirements: The next challenge for Agile (February 2009), Books for Product Managers (December 2008) among others) about the Product Manager role. However, Product Managers, or to give them their full title, Technical Product Managers, only really exist in genuine software product companies (including software as a service models). In corporate IT departments and software service companies (i.e. ones that write bespoke software for a specific customer) the role doesn’t exist.
In these companies the “needs” role is usually (or should) be filled by a Business Analyst. I blogged about these when I blogged about System Analysts earlier this year.
Both Product Managers and Business Analysts (BA) are concerned with the “what” of the software product, but how they decide this is different. Basically:
However, he BA role is much misunderstood. As a title I think it ranks second only the “Project Manager” in abuse. In some places BAs are really System Analysts, in others they are Project Managers, in others they just gather the requirements. The definition I like best is “Internal Consultant.”
Thats one of the reasons I really like the Business Analysis Maturity Model.
You can view this model as model for individual career development, but I prefer to view it as a model for corporate advancement. At the “low end” BA just rather up everything “users” think they want, at the high-end the BA is responsible for discovering what the business needs to improve.
When you do this the BA role looks a lot more like a Product Manager role: its about deciding what will advance the company and product in both cases.
And its important from an Agile perspective. When the Product Owner/BA role is played as a “requirements gatherer” then there is little scope for the BA to add value and, more importantly, there is little flexibility in what is delivered. The BA becomes just the guy who communicates the need to the people who write the code.
When the BA role is played as an consultant, working with customers/users and the development team to fill a business need then the conversation changes. Rather than discussing which, and in what order, features will be developed from a given shopping list then conversation can centre on how best to satisfy a business need and maximise value.
In short, the BA Maturity Model is a critical, and until now missing, piece in understanding the BA role in Agile teams and Agile development.
I’ve blogged before (many times, The Product Owner role (August 2009), Requirements: The next challenge for Agile (February 2009), Books for Product Managers (December 2008) among others) about the Product Manager role. However, Product Managers, or to give them their full title, Technical Product Managers, only really exist in genuine software product companies (including software as a service models). In corporate IT departments and software service companies (i.e. ones that write bespoke software for a specific customer) the role doesn’t exist.
In these companies the “needs” role is usually (or should) be filled by a Business Analyst. I blogged about these when I blogged about System Analysts earlier this year.
Both Product Managers and Business Analysts (BA) are concerned with the “what” of the software product, but how they decide this is different. Basically:
- Product Managers find the need by looking outside the company, at a market of multiple potential customers
- Business Analysts look inside the company at a single customer, with potentially many stakeholders involved
However, he BA role is much misunderstood. As a title I think it ranks second only the “Project Manager” in abuse. In some places BAs are really System Analysts, in others they are Project Managers, in others they just gather the requirements. The definition I like best is “Internal Consultant.”
Thats one of the reasons I really like the Business Analysis Maturity Model.
You can view this model as model for individual career development, but I prefer to view it as a model for corporate advancement. At the “low end” BA just rather up everything “users” think they want, at the high-end the BA is responsible for discovering what the business needs to improve.
When you do this the BA role looks a lot more like a Product Manager role: its about deciding what will advance the company and product in both cases.
And its important from an Agile perspective. When the Product Owner/BA role is played as a “requirements gatherer” then there is little scope for the BA to add value and, more importantly, there is little flexibility in what is delivered. The BA becomes just the guy who communicates the need to the people who write the code.
When the BA role is played as an consultant, working with customers/users and the development team to fill a business need then the conversation changes. Rather than discussing which, and in what order, features will be developed from a given shopping list then conversation can centre on how best to satisfy a business need and maximise value.
In short, the BA Maturity Model is a critical, and until now missing, piece in understanding the BA role in Agile teams and Agile development.
Tuesday, April 20, 2010
What you need is a ....
Programmer, software engineer, software developer, coder, developer, code-monkey, build engineer, tester, software tester, test automator, test engineer, quality assurance engineer, analyst, business analyst, system analyst, product owner, product manager, requirements manager, subject matter expert, domain expert, project manager, change manager, programme manager, development manager, iteration manager, release manager, deployment manager, scrum master, team leader, technical lead, development lead, architect (system architect, solution architect, software architect), consultant, coach, designer, user interface designer, user experience designer, product designer.
Did I miss any? - There are a lot of roles in software development teams and even more titles. Does your team have a full set? Do you need them all? How do you choose which ones you have, and which you don’t?
And everyone of them offers a solution to your problem. So....
In walks the Programmer (Software engineer, software developer, etc. etc.) and says: “Yes, I understand your problem, what you need is some software writing. Only us programmers can do that so don’t worry about that testing lark, or analysis. Just introduce me to some customers and I’ll work it out.”
The Business Analyst walks in next: “Its all very well writing something, and its all very well making sure it works. But, is it the right thing? How do you know its what you need? Us Business Analysts are trained to understand what you need and give those requirements to the programmers and testers.”
Next in is the Tester. “You see, the problem is that Programmers don’t really know what you want, and when they do they make mistakes. So I’ll test everything and ensure it works, and that it is what you want.”
Very convincing. Next you talk to a Project Manager: “yes, these programmer and testers are very good but have you noticed how long they take? Unless there is someone here to organise them, and dare I say push them, then you’ll never get anything.”
You see, everyone (every role) offers to solve your problem. Maybe by creating a solution, maybe by ensuring its the right solution or maybe by making sure that it all fits together.
And these roles overlap. Programmers can talk to you about what you need, so can Testers. Project Managers like to have a chat too and Business Analysts claim its their right.
As you get more people things get more complicated. They seem to make work for themselves. So you need an overall Development Manager to manage you teams. You hire Architects to ensure the Programmers really do it right.
More people begat more people: Release Managers, Programme Managers and Team Leaders appear to organise people. Designers, Build Engineers, and Consultants appear to specialise in parts of the system.
They all claim to have the answer to your problems but things look worse.
Then someone tells you about Agile. You need a Product Owner, a Scrum Master and a Team. More roles, and the people you already have don’t want to give up their titles so you add some more.
And the holders of all these roles claim they have the solution to your problem.
They can’t all be right.
Thing is: there is only one role you absolutely must have on a software development project. That is the guy who does the coding: Programmer, Software Engineer, Software Developers, call them what you will. If you are not getting code written you aren’t doing software development.
Which of the other roles you have depends on the complexity and nature of the work, the size of the team, the approach you take and your wider organisation.
This doesn’t stop the specialise from telling you they have the solution to your problem. Which makes it all confusing.
I intend to keep with this theme of roles for a few blog entries, so watch this space.
Did I miss any? - There are a lot of roles in software development teams and even more titles. Does your team have a full set? Do you need them all? How do you choose which ones you have, and which you don’t?
And everyone of them offers a solution to your problem. So....
In walks the Programmer (Software engineer, software developer, etc. etc.) and says: “Yes, I understand your problem, what you need is some software writing. Only us programmers can do that so don’t worry about that testing lark, or analysis. Just introduce me to some customers and I’ll work it out.”
The Business Analyst walks in next: “Its all very well writing something, and its all very well making sure it works. But, is it the right thing? How do you know its what you need? Us Business Analysts are trained to understand what you need and give those requirements to the programmers and testers.”
Next in is the Tester. “You see, the problem is that Programmers don’t really know what you want, and when they do they make mistakes. So I’ll test everything and ensure it works, and that it is what you want.”
Very convincing. Next you talk to a Project Manager: “yes, these programmer and testers are very good but have you noticed how long they take? Unless there is someone here to organise them, and dare I say push them, then you’ll never get anything.”
You see, everyone (every role) offers to solve your problem. Maybe by creating a solution, maybe by ensuring its the right solution or maybe by making sure that it all fits together.
And these roles overlap. Programmers can talk to you about what you need, so can Testers. Project Managers like to have a chat too and Business Analysts claim its their right.
As you get more people things get more complicated. They seem to make work for themselves. So you need an overall Development Manager to manage you teams. You hire Architects to ensure the Programmers really do it right.
More people begat more people: Release Managers, Programme Managers and Team Leaders appear to organise people. Designers, Build Engineers, and Consultants appear to specialise in parts of the system.
They all claim to have the answer to your problems but things look worse.
Then someone tells you about Agile. You need a Product Owner, a Scrum Master and a Team. More roles, and the people you already have don’t want to give up their titles so you add some more.
And the holders of all these roles claim they have the solution to your problem.
They can’t all be right.
Thing is: there is only one role you absolutely must have on a software development project. That is the guy who does the coding: Programmer, Software Engineer, Software Developers, call them what you will. If you are not getting code written you aren’t doing software development.
Which of the other roles you have depends on the complexity and nature of the work, the size of the team, the approach you take and your wider organisation.
This doesn’t stop the specialise from telling you they have the solution to your problem. Which makes it all confusing.
I intend to keep with this theme of roles for a few blog entries, so watch this space.
Monday, April 12, 2010
Capers Jones & "How many teams are Agile?"
A while ago I tried to answer the question “How many software teams are using Agile?”. My best efforts put the answer at somewhere between 5% and 15%.
In the search for some other data I’ve recently been look through Capers Jones “Applied Software Measurement” (2008). It is packed full of interesting statistics and I really must buy a copy and read it in more detail. Anyway, Jones gives his hypothesis of project in this table:
(In case that table gets mangled, the first column is the type of development, the second the total Jones looked at and the third the percentage of the total.)
Jones puts the number of Agile projects at 13%, firmly inside the range I give. Of course there are two caveats here. Firstly, the ways Jones has sliced and diced the numbers leaves me wondering how he has counted military work running Agile, and outsourced work running Agile.
Second, how do we know if a piece of work is Agile or not? All the evidence I have tells me that an awful lot of teams are saying they are “Agile” and frankly aren’t. As Kevlin Henney suggested on re-twittered (from somewhere or other) recently a better question to ask is “How are you Agile?”
I’ll get Jones book and read it some more. One other thing he mentioned stood out: getting metric on software projects is hard. He says its like searching through debris, lots of rubbish then occasionally a nugget. Which sums up how I feel about software metrics now. Its quite like I imagine archaeology.
In the search for some other data I’ve recently been look through Capers Jones “Applied Software Measurement” (2008). It is packed full of interesting statistics and I really must buy a copy and read it in more detail. Anyway, Jones gives his hypothesis of project in this table:
| Type of development | Number | % |
| End-user | 2,500 | 2% |
| Agile | 20,000 | 13% |
| Web | 12,500 | 8% |
| Systems | 8,750 | 6% |
| MIS | 70,000 | 45% |
| Commercial | 3,250 | 2% |
| Outsource - US | 17,500 | 11% |
| Outsource - offshore | 15,000 | 10% |
| Military | 7,750 | 5% |
| Total | 157,250 | 100% |
Jones puts the number of Agile projects at 13%, firmly inside the range I give. Of course there are two caveats here. Firstly, the ways Jones has sliced and diced the numbers leaves me wondering how he has counted military work running Agile, and outsourced work running Agile.
Second, how do we know if a piece of work is Agile or not? All the evidence I have tells me that an awful lot of teams are saying they are “Agile” and frankly aren’t. As Kevlin Henney suggested on re-twittered (from somewhere or other) recently a better question to ask is “How are you Agile?”
I’ll get Jones book and read it some more. One other thing he mentioned stood out: getting metric on software projects is hard. He says its like searching through debris, lots of rubbish then occasionally a nugget. Which sums up how I feel about software metrics now. Its quite like I imagine archaeology.
Wednesday, April 07, 2010
Les Hatton's site and the importance of letting failures fail
I recently stumbled across Les Hatton's site. I've owned one of Les' books for probably over decade (Safer C, a classic) but this was the first time I've looked at his website. I highly recommend a perusal of the site and reading some of his papers. Apart from anything else he's an even more interesting guy than I thought he was (and I already though he was interesting!).
One set of his papers looks at the power-law nature of software code. I'll admit I couldn't follow all of the academic speak and advanced maths terms - which might disqualify me from reading some papers but it
more a sign that I didn't take the time to work it out in depth. (Most of his papers are written in a very accessible style.) The key point I took away was that he extends James Noble's work to non-OO systems. Hopefully I’ll find time to go back and read more of these papers in depth and make sense of the bits I skimmed this time.
Another paper which stood out was “How to build successful complex systems: lessons from open source” with his suggestions for how to build the NHS IT system. Until I read this I was unaware that the Welsh
Health Service had taken a different route to the English one, had spent far less money and had actually produced a successful system.
Les, like many others, sings the praises of the Open Source movement. He’s right, there are some very successful Open Source products out there, but, as I’ve pointed out before, most Open Source
projects fail. And when I say MOST I mean tens of thousands fail for every success.
Fortunately Les’ suggestions allows for this; he suggests a Darwinian process with seeds 100+ development efforts and over a series of rounds reduces them to one winner.
Although Les suggests this in an Open Source context what he is actually suggestion is also a Venture Capital model. He proposes to give over 100 teams a little bit of money (seed money in effect) to create an initial system. Year on year winners are selected to continue development, these are given a bit more money. That sounds exactly like Angel funding, VC Round A, VC Round B, etc. etc. funding. OK, Les model is “open” because the winning teams get to pick over the remains of the loosing but even that exists in commercial activity: failing companies get bought by the winners who keep the best bits.
Either way the result is the same: rather than one “too big to fail” NHS IT project we have a number of small projects which compete and can fail. If we remove the ability to fail from the process then we have to
pay for failure.
Whether it be evolution, capitalism, IT projects or even banks, if failures are not removed from the system then change is inhibited because the winners cannot really win.
This is the important thing about failure. Forget that myth about learning from failures, the important thing is that it eliminates something that doesn’t work.
One set of his papers looks at the power-law nature of software code. I'll admit I couldn't follow all of the academic speak and advanced maths terms - which might disqualify me from reading some papers but it
more a sign that I didn't take the time to work it out in depth. (Most of his papers are written in a very accessible style.) The key point I took away was that he extends James Noble's work to non-OO systems. Hopefully I’ll find time to go back and read more of these papers in depth and make sense of the bits I skimmed this time.
Another paper which stood out was “How to build successful complex systems: lessons from open source” with his suggestions for how to build the NHS IT system. Until I read this I was unaware that the Welsh
Health Service had taken a different route to the English one, had spent far less money and had actually produced a successful system.
Les, like many others, sings the praises of the Open Source movement. He’s right, there are some very successful Open Source products out there, but, as I’ve pointed out before, most Open Source
projects fail. And when I say MOST I mean tens of thousands fail for every success.
Fortunately Les’ suggestions allows for this; he suggests a Darwinian process with seeds 100+ development efforts and over a series of rounds reduces them to one winner.
Although Les suggests this in an Open Source context what he is actually suggestion is also a Venture Capital model. He proposes to give over 100 teams a little bit of money (seed money in effect) to create an initial system. Year on year winners are selected to continue development, these are given a bit more money. That sounds exactly like Angel funding, VC Round A, VC Round B, etc. etc. funding. OK, Les model is “open” because the winning teams get to pick over the remains of the loosing but even that exists in commercial activity: failing companies get bought by the winners who keep the best bits.
Either way the result is the same: rather than one “too big to fail” NHS IT project we have a number of small projects which compete and can fail. If we remove the ability to fail from the process then we have to
pay for failure.
Whether it be evolution, capitalism, IT projects or even banks, if failures are not removed from the system then change is inhibited because the winners cannot really win.
This is the important thing about failure. Forget that myth about learning from failures, the important thing is that it eliminates something that doesn’t work.
Thursday, April 01, 2010
PROMS-G slides and other speaking engagements
I presented to the BCS PROMS-G group (Project Management Special Interest Group) last week. This was an expended version of my Jax London talk and formed part of their “Spring School” on Agile. The slides for “The Future of Agile 2010” are now online.
Originally this was going to be a repeat of the BCS Bristol Spring School talk on, The Future of Agile, you might like to compare the two presentations and how my thinking has developed.
Unfortunately I’ve had to pull out of the ACCU Conference this month. I haven’t missed an ACCU conference since 2001 so as much as I regret missing it I think I can skip one. Unfortunately an family matters made it difficult to keep this commitment. The good news for anyone going to the conference is that my place is being taken by Rachel Davies.
So I get April off speaking in public but come May....
I’m speaking to the IIBA Nottingham meeting on 10 May. This will be a repeat of my talk to the IIBA BA conference last year about the BA role in Agile, “More important then ever, the BA role in Agile transition”.
Then I’m speaking to Sottware East in Cambridge on 20 May when I’ll be speaking about The Falling off a log theory and other observations on the software industry.
Unfortunately that means I’ll have to miss the May meeting of ACCU London, which is a shame because Kevlin Henney is the speaker and he is always entertaining.
Originally this was going to be a repeat of the BCS Bristol Spring School talk on, The Future of Agile, you might like to compare the two presentations and how my thinking has developed.
Unfortunately I’ve had to pull out of the ACCU Conference this month. I haven’t missed an ACCU conference since 2001 so as much as I regret missing it I think I can skip one. Unfortunately an family matters made it difficult to keep this commitment. The good news for anyone going to the conference is that my place is being taken by Rachel Davies.
So I get April off speaking in public but come May....
I’m speaking to the IIBA Nottingham meeting on 10 May. This will be a repeat of my talk to the IIBA BA conference last year about the BA role in Agile, “More important then ever, the BA role in Agile transition”.
Then I’m speaking to Sottware East in Cambridge on 20 May when I’ll be speaking about The Falling off a log theory and other observations on the software industry.
Unfortunately that means I’ll have to miss the May meeting of ACCU London, which is a shame because Kevlin Henney is the speaker and he is always entertaining.
PROMS-G slides and other speaking engagements
I presented to the BCS PROMS-G group (Project Management Special Interest Group) last week. This was an expended version of my Jax London talk and formed part of their “Spring School” on Agile. The slides for “The Future of Agile 2010” are now online.
Originally this was going to be a repeat of the BCS Bristol Spring School talk on, The Future of Agile, you might like to compare the two presentations and how my thinking has developed.
Unfortunately I’ve had to pull out of the ACCU Conference this month. I haven’t missed an ACCU conference since 2001 so as much as I regret missing it I think I can skip one. Unfortunately an family matters made it difficult to keep this commitment. The good news for anyone going to the conference is that my place is being taken by Rachel Davies.
So I get April off speaking in public but come May....
I’m speaking to the IIBA Nottingham meeting on 10 May. This will be a repeat of my talk to the IIBA BA conference last year about the BA role in Agile, “More important then ever, the BA role in Agile transition”.
Then I’m speaking to Sottware East in Cambridge on 20 May when I’ll be speaking about The Falling off a log theory and other observations on the software industry.
Unfortunately that means I’ll have to miss the May meeting of ACCU London, which is a shame because Kevlin Henney is the speaker and he is always entertaining.
Originally this was going to be a repeat of the BCS Bristol Spring School talk on, The Future of Agile, you might like to compare the two presentations and how my thinking has developed.
Unfortunately I’ve had to pull out of the ACCU Conference this month. I haven’t missed an ACCU conference since 2001 so as much as I regret missing it I think I can skip one. Unfortunately an family matters made it difficult to keep this commitment. The good news for anyone going to the conference is that my place is being taken by Rachel Davies.
So I get April off speaking in public but come May....
I’m speaking to the IIBA Nottingham meeting on 10 May. This will be a repeat of my talk to the IIBA BA conference last year about the BA role in Agile, “More important then ever, the BA role in Agile transition”.
Then I’m speaking to Sottware East in Cambridge on 20 May when I’ll be speaking about The Falling off a log theory and other observations on the software industry.
Unfortunately that means I’ll have to miss the May meeting of ACCU London, which is a shame because Kevlin Henney is the speaker and he is always entertaining.
Thursday, March 25, 2010
EuroPLoP 2009 proceedings now online
As some of you will recall, I was one of the Chairs for the European Patterns conference in 2008 and 2009. One of my responsibilities for the 2009 conference was to produce the conference proceedings. Well I’ve done it!
2009 represents a change for EuroPLoP. Until now we have published our proceedings in a physical book, a large book I should mention. This cost the conference organisers money (because it sold almost no copies), the money pushed up fees, and the proceedings were almost completely inaccessible unless you actually went to the conference. While some authors (like myself) put their papers online not everybody did.
For 2009 this has all changed, we’ve gone electronic. Thanks to CEUR EuroPLoP 2009 proceedings are available for free to anyone who want them. You can download individual papers or everything as one 30Mb PDF file.
So roll up, roll up, get your EuroPLoP 2009 conference proceedings here!
2009 represents a change for EuroPLoP. Until now we have published our proceedings in a physical book, a large book I should mention. This cost the conference organisers money (because it sold almost no copies), the money pushed up fees, and the proceedings were almost completely inaccessible unless you actually went to the conference. While some authors (like myself) put their papers online not everybody did.
For 2009 this has all changed, we’ve gone electronic. Thanks to CEUR EuroPLoP 2009 proceedings are available for free to anyone who want them. You can download individual papers or everything as one 30Mb PDF file.
So roll up, roll up, get your EuroPLoP 2009 conference proceedings here!
Subscribe to:
Posts (Atom)