One of the things I really like about this blog is the comments. Firstly I get comments, secondly they are usually complementary and often provide additional information and understanding.
I moderate the comments but on the whole I publish everything I get. Once or twice I’ve published comments I find personally hurtful or miss the point. I’m not promising to keep this up but I will try to publishes everything.
However, what I will not publish is “spam” comments, I’e just rejected another one. Over the last few months I’ve got comments which say something like “Good blog” or “Nice blog entry” - i.e. they are short and not specific to my blog or any particular blog entry. Nothing wrong there except, usually the poster has included a link to their own website (or someone elses) and I have no other links for the poster.
I published the first one or two of these then realised they were not really commenting on my blog, they were placing a link to their own site.
I don’t mind people linking to a site in a comment provided its relevant, tells me more about the subject or the person who posted.
While comments of the form “Keep up the good work - you might like www.cheap-tickets.xyz” may support my ego they don’t add anything to the blog.
Secondly. As a general rule I don’t reply to comments, and I don’t promise to answer questions posted in comments. Sometimes I do but to reply to everything would be making too much work for myself.
Tuesday, May 26, 2009
Saturday, May 23, 2009
Thoughts after Jeff Sutherland at ACCU London
Jeff Sutherland was back in London last week and was good enough to give a talk to ACCU London. As one of the organisers of the ACCU London events I feel I’m justified in giving myself (and my co-organiser James Slaughter) a well deserved pat on the back. This was something of a coup for us.
Over 80 people registered for the event - in fact there was a waiting list of people we couldn’t fit in - and I counted at least 70 people in attendance.
As this event was somewhat bigger than our usual events we had to find a bigger room. Fortunately JP Morgan came to the rescue with a room at the top of their London tower. So not only did we have Jeff but we had a great view of London. Thanks JP Morgan!
Jeff is a good presenter and had some interesting things to say. Although I know most of the Scrum-stuff I still picked up some good information. A few points I thought writing down:
• When Scrum was introduced at Palm it was found that 1 hour of postponed testing resulted in 23 hours of testing later.
• The Chaos reports from the Standish group find that 76% of requirements change after a project has started.
• Data from Yahoo shows that teams adopting Scrum on their own show a 35% productivity improvement. Teams which are coached through Scrum adoption shows a 300-400% improvement. Good news for those of us like me who make a living as an Agile Coach, usually with Scrum. (For those who want it the original source of this statistic is "Rolling Out Agile at a Large Enterprise" by Gabrielle Benefield at the Hawaii International Conference on Software System, 2008.)
• Not only does Jeff endorse the addition of XP technical practices (TDD, refactoring, pair-programming, etc.) to Scrum he believes these are what allow Scrum to scale up. This is important as it fits in with Bob Martin’s comments at the ACCU conference last month.
At the end of the session there was a very good Q&A session - so good we ran out of time and had to cut it short.
In response to one question Jeff mentioned a paper he wrote a couple of years ago called The Future of Scrum. What is interesting here is, Jeff foresees changes in the way Scrum is practices. This contradicts with Ken Schwaber’s statement that “There is only on Scrum.”
I don’t want to get into fighting about whether there is one Scrum, or a future Scrum or what ever. What I think is interesting here is that there are different views on the subject.
While the Agile community as a whole sometimes seems unable to agree on “what is Agile” the Scrum community seems steel like in their understanding of what Scrum is. The truth, for both groups, is somewhere between the two extremes.
Over 80 people registered for the event - in fact there was a waiting list of people we couldn’t fit in - and I counted at least 70 people in attendance.
As this event was somewhat bigger than our usual events we had to find a bigger room. Fortunately JP Morgan came to the rescue with a room at the top of their London tower. So not only did we have Jeff but we had a great view of London. Thanks JP Morgan!
Jeff is a good presenter and had some interesting things to say. Although I know most of the Scrum-stuff I still picked up some good information. A few points I thought writing down:
• When Scrum was introduced at Palm it was found that 1 hour of postponed testing resulted in 23 hours of testing later.
• The Chaos reports from the Standish group find that 76% of requirements change after a project has started.
• Data from Yahoo shows that teams adopting Scrum on their own show a 35% productivity improvement. Teams which are coached through Scrum adoption shows a 300-400% improvement. Good news for those of us like me who make a living as an Agile Coach, usually with Scrum. (For those who want it the original source of this statistic is "Rolling Out Agile at a Large Enterprise" by Gabrielle Benefield at the Hawaii International Conference on Software System, 2008.)
• Not only does Jeff endorse the addition of XP technical practices (TDD, refactoring, pair-programming, etc.) to Scrum he believes these are what allow Scrum to scale up. This is important as it fits in with Bob Martin’s comments at the ACCU conference last month.
At the end of the session there was a very good Q&A session - so good we ran out of time and had to cut it short.
In response to one question Jeff mentioned a paper he wrote a couple of years ago called The Future of Scrum. What is interesting here is, Jeff foresees changes in the way Scrum is practices. This contradicts with Ken Schwaber’s statement that “There is only on Scrum.”
I don’t want to get into fighting about whether there is one Scrum, or a future Scrum or what ever. What I think is interesting here is that there are different views on the subject.
While the Agile community as a whole sometimes seems unable to agree on “what is Agile” the Scrum community seems steel like in their understanding of what Scrum is. The truth, for both groups, is somewhere between the two extremes.
Monday, May 18, 2009
The BCS Kingston & Croydon session
In March this year Kevin Rutherford and myself ran an interactive session for Kingston & Croydon BCS at Kingston University.
Immo Hueneke who organised the evening has now done a write up of the evening with photographs. The session demonstrated and discussed the Theory of Constraints, Lean and a little on the Kanban development method.
Immo Hueneke who organised the evening has now done a write up of the evening with photographs. The session demonstrated and discussed the Theory of Constraints, Lean and a little on the Kanban development method.
Saturday, May 16, 2009
What architects do
I stumbled across a programme called English Heritage on BBC 2 last night (Friday 15 May). Enjoyable for three reasons: first it was an insight into the work of English Heritage, second it was about renovation of Kings Cross station but while both of these were interesting the what I found fascinating was; third - the work of architects.
That’s physical, building, architects. Not the software engineering type.
Like many others in the software engineering community I’ve been guilty in the past of throwing the architectural metaphor around without really understanding what building architects do. Sure I know a little but much of what I think they do is guesswork.
So this programme grabbed my interest because it showed real architects at work. Here are some points that stood out to me:
• Work had begun on the project and the architecture plans were far from complete. Design was continuing and evolving as work continued.
• There was a budget and work had to be within the budget. It looked like the budget (and I suspect time) was set and design and construction occurred within that budget. I saw no sign of a up front master plan which had been broken down item by item, then estimated for time and cost and the sum total agreed.
• In some cases demolition had occurred and it wasn’t clear what would be build in place.
• Building areas where being found and possible work suggested.
• Most of the work was on the old Kings Cross station, some was redesign, some was addition, some was removal and some was simple refactoring.
• We never saw the architects at their drawing boards; we did see them walking around the site, investigating ongoing work; arguing, discussing and negotiating with clients and authorities.
• We saw architects having to change their designs because of business constraints (not enough money to renovate one area) and regulating authorities (English Heritage restricting what the architects could do and how they did it).
• We saw one set of architects disagreeing with another set (Network Rail’s architects wanted to do things want way and English Heritage’s architects thought it should be done another way.)
All in all I found it a fascinating insight into what architects do. As I long suspected, the practice of architecting buildings is not what a lot of software people assume it to be.
That’s physical, building, architects. Not the software engineering type.
Like many others in the software engineering community I’ve been guilty in the past of throwing the architectural metaphor around without really understanding what building architects do. Sure I know a little but much of what I think they do is guesswork.
So this programme grabbed my interest because it showed real architects at work. Here are some points that stood out to me:
• Work had begun on the project and the architecture plans were far from complete. Design was continuing and evolving as work continued.
• There was a budget and work had to be within the budget. It looked like the budget (and I suspect time) was set and design and construction occurred within that budget. I saw no sign of a up front master plan which had been broken down item by item, then estimated for time and cost and the sum total agreed.
• In some cases demolition had occurred and it wasn’t clear what would be build in place.
• Building areas where being found and possible work suggested.
• Most of the work was on the old Kings Cross station, some was redesign, some was addition, some was removal and some was simple refactoring.
• We never saw the architects at their drawing boards; we did see them walking around the site, investigating ongoing work; arguing, discussing and negotiating with clients and authorities.
• We saw architects having to change their designs because of business constraints (not enough money to renovate one area) and regulating authorities (English Heritage restricting what the architects could do and how they did it).
• We saw one set of architects disagreeing with another set (Network Rail’s architects wanted to do things want way and English Heritage’s architects thought it should be done another way.)
All in all I found it a fascinating insight into what architects do. As I long suspected, the practice of architecting buildings is not what a lot of software people assume it to be.
Tuesday, May 12, 2009
How many people are doing Agile?
The BIG question came up the other week during my presentation to HP: “How many organizations are doing Agile?”
As I said at the time: Thats the $64,000 question - or perhaps in todays money, $64,000,000,000.
Of course, it depends a lot on how you even define “Agile”. Sure if your following everything Kent Beck says in the XP books your probably Agile. But in most places adoption is patchy, a bit of TDD here, some iterations there - stand up meetings seem to be very common now but one practice does not an Agile team make.
Within organizations Agile exists in some places and not in others. There is a large Swiss bank in London which has one of the best Agile teams in the country - well, at least it contains many of the best Agile people in the country.
As I said, Its a LARGE bank. I met someone from elsewhere in the bank at a BBQ last week. The very mention of Agile upset him. His team claimed to be doing Scrum but it didn’t sound anything like the Scrum I know - requirements changed everyday.
“What is Agile” is big question in its own right, maybe we’ll come back to it another day. Back to the original question.
When Jeff Sutherland spoke in London last month he mentioned that there are 83 certified Scrum Master trainers. Bob Martin at the ACCU conference mentioned that there are now 50,000 certified Scrum Masters.
Of course we don’t know how many of those Scrum Masters are practicing, how many work with multiple teams and how many unofficial Scrum Masters there.
Neither do we know how many other teams there are so knowing how many Scrum Masters there are doesn’t help.
In late 2006 Gartner issued a report (“Agile Development: Fact or Fiction”) which estimated less than 5% of development groups were doing Agile. If think its reasonable to assume more teams are doing it now.
I heard from a developer who was looking for a new job in Moscow recently that about 1 in 10 companies claimed to be Agile. That would make it 10% of companies, or 10% of teams.
To get an idea of the UK market I did a series of searches on two job boards: JobServe.com and Monster.co.uk. I searchied for all jobs asking for Java, C# and C++ then I repeated the searches for the same languages with Agile.
Monster.co.uk
Jobs
% of Agile
Java
501
Java and Agile
68
13.5%
C#
411
C# and Agile
67
16.3%
C++
1686
C++ and Agile
19
1.1%
I was quite surprised by the results for C++ here, but if you want to work Agile you are going to have to look hard for an Agile C++ shop. Another surprise, especially for C++, is that different jobs boards might be better for different languages (I’ll leave that thought for someone else to follow up.)
JobServe.com
Jobs
% of Agile
Java
1077
Java and Agile
135
12.5%
C#
960
C# and Agile
127
13.2%
C++
705
C++ and Agile
51
7.2%
Interesting while there are fewer C# jobs than Java jobs the percentage of jobs asking for Agile is similar. So bang goes the theory that there is more Agile Java than Agile C#.
These are very crude counts, I made no attempt to adjust for duplicates (which certainly exist), location anything else. I don’t even know if the searches included JavaScript in the Java searches. (I suspect not because the number of Java jobs is not so far ahead of C# jobs.)
It is worth pointing out that, in general, only those jobs which are difficult to fill get listed so these stats are not representative of the job market as a whole.
Crudely, there seems to be a cluster around 13%. If we ignore the highest and lowest results the answer is between 7.2% and 13.5%. Which isn’t far from that Moscow report.
Certainly there will be teams who are asking for Agile but don’t do Agile. For some teams they may be looking for Agile developers in the hope that they bring Agile into the organization.
For me one of the tests of Agile is: Is it working?
If your development is not effective then I don’t think you are Agile. You might be following a process called Scrum, XP, DSDM or something else but if your team is not effective then you are not filling the business need and you aren’t Agile. How can you be Agile if you are failing?
To be Agile you must be effective.
(That is a little sneaky of me because I am equating Agile with success. It also means the questions “How many people are doing Scrum?” is different to “How many people are doing Agile?” but lets leave that to one side.)
Back to my favourite study from Bain Consulting (The Alignment Trap) which estimated that only about 15% of organizations had effective IT. Now not all these IT groups are doing software development and some will be effective without Agile.
But, if we put those two statements together we get 15% as the upper bound of adoption. That is: at most 15% of oranizations are effective, therefore at most 15% of organizations are Agile. (If they are not effective they cannot be Agile.)
None of this data is conclusive, or definative, but I think it does give us a range:
Between 5% and 15% of all software development is done using Agile software development.
It its worth pointing out that both a high number and a low number is good.
The more companies adopt Agile the safer it is to adopt. The more companies adopt it the more mainstream it is and the more reason to adopt it.
But, while only a few companies are working Agile there is a real competitive advantage in companies adopting it. If your company can produce software in a fraction of the time, or with a fraction of the people of your rivals then your onto a good thing.
It is a risk reward ratio. If you wait until its adopted by 80% of the industry there won’t be an advantage. You’ll be playing catch up.
Given that, the 5-15% range is probably good news. Its common enough to be safe but rear enough to be advantagous.
As I said at the time: Thats the $64,000 question - or perhaps in todays money, $64,000,000,000.
Of course, it depends a lot on how you even define “Agile”. Sure if your following everything Kent Beck says in the XP books your probably Agile. But in most places adoption is patchy, a bit of TDD here, some iterations there - stand up meetings seem to be very common now but one practice does not an Agile team make.
Within organizations Agile exists in some places and not in others. There is a large Swiss bank in London which has one of the best Agile teams in the country - well, at least it contains many of the best Agile people in the country.
As I said, Its a LARGE bank. I met someone from elsewhere in the bank at a BBQ last week. The very mention of Agile upset him. His team claimed to be doing Scrum but it didn’t sound anything like the Scrum I know - requirements changed everyday.
“What is Agile” is big question in its own right, maybe we’ll come back to it another day. Back to the original question.
When Jeff Sutherland spoke in London last month he mentioned that there are 83 certified Scrum Master trainers. Bob Martin at the ACCU conference mentioned that there are now 50,000 certified Scrum Masters.
Of course we don’t know how many of those Scrum Masters are practicing, how many work with multiple teams and how many unofficial Scrum Masters there.
Neither do we know how many other teams there are so knowing how many Scrum Masters there are doesn’t help.
In late 2006 Gartner issued a report (“Agile Development: Fact or Fiction”) which estimated less than 5% of development groups were doing Agile. If think its reasonable to assume more teams are doing it now.
I heard from a developer who was looking for a new job in Moscow recently that about 1 in 10 companies claimed to be Agile. That would make it 10% of companies, or 10% of teams.
To get an idea of the UK market I did a series of searches on two job boards: JobServe.com and Monster.co.uk. I searchied for all jobs asking for Java, C# and C++ then I repeated the searches for the same languages with Agile.
Monster.co.uk
Jobs
% of Agile
Java
501
Java and Agile
68
13.5%
C#
411
C# and Agile
67
16.3%
C++
1686
C++ and Agile
19
1.1%
I was quite surprised by the results for C++ here, but if you want to work Agile you are going to have to look hard for an Agile C++ shop. Another surprise, especially for C++, is that different jobs boards might be better for different languages (I’ll leave that thought for someone else to follow up.)
JobServe.com
Jobs
% of Agile
Java
1077
Java and Agile
135
12.5%
C#
960
C# and Agile
127
13.2%
C++
705
C++ and Agile
51
7.2%
Interesting while there are fewer C# jobs than Java jobs the percentage of jobs asking for Agile is similar. So bang goes the theory that there is more Agile Java than Agile C#.
These are very crude counts, I made no attempt to adjust for duplicates (which certainly exist), location anything else. I don’t even know if the searches included JavaScript in the Java searches. (I suspect not because the number of Java jobs is not so far ahead of C# jobs.)
It is worth pointing out that, in general, only those jobs which are difficult to fill get listed so these stats are not representative of the job market as a whole.
Crudely, there seems to be a cluster around 13%. If we ignore the highest and lowest results the answer is between 7.2% and 13.5%. Which isn’t far from that Moscow report.
Certainly there will be teams who are asking for Agile but don’t do Agile. For some teams they may be looking for Agile developers in the hope that they bring Agile into the organization.
For me one of the tests of Agile is: Is it working?
If your development is not effective then I don’t think you are Agile. You might be following a process called Scrum, XP, DSDM or something else but if your team is not effective then you are not filling the business need and you aren’t Agile. How can you be Agile if you are failing?
To be Agile you must be effective.
(That is a little sneaky of me because I am equating Agile with success. It also means the questions “How many people are doing Scrum?” is different to “How many people are doing Agile?” but lets leave that to one side.)
Back to my favourite study from Bain Consulting (The Alignment Trap) which estimated that only about 15% of organizations had effective IT. Now not all these IT groups are doing software development and some will be effective without Agile.
But, if we put those two statements together we get 15% as the upper bound of adoption. That is: at most 15% of oranizations are effective, therefore at most 15% of organizations are Agile. (If they are not effective they cannot be Agile.)
None of this data is conclusive, or definative, but I think it does give us a range:
Between 5% and 15% of all software development is done using Agile software development.
It its worth pointing out that both a high number and a low number is good.
The more companies adopt Agile the safer it is to adopt. The more companies adopt it the more mainstream it is and the more reason to adopt it.
But, while only a few companies are working Agile there is a real competitive advantage in companies adopting it. If your company can produce software in a fraction of the time, or with a fraction of the people of your rivals then your onto a good thing.
It is a risk reward ratio. If you wait until its adopted by 80% of the industry there won’t be an advantage. You’ll be playing catch up.
Given that, the 5-15% range is probably good news. Its common enough to be safe but rear enough to be advantagous.
Wednesday, May 06, 2009
Intermission
On the whole I don’t use this blog to push myself – maybe I should. As I finished that last blog entry it dawned on me: Why not? Maybe I could help your company?
Broadly my activities fall under the heading: Agile Coach, Interim Manager, Consultant and Training.
Here are some examples of how I have recently helped software development teams improve:
• Agile & Scrum training, more details on the Software Strategy website.
• Coaching for teams adopting and running Agile - broadly equivalent to Scrum Master
• Interim Development and Project Management: whether to adopt Agile or to rescue a project; I get involved for several weeks or month, fix things and hand it over
• Project and Team turn around
• Advice on transition to Agile development practices
• Development review
The common theme here is: helping software development team perform better to benefit their business customers.
If you think I may be able to help you please get in touch, allan@allankelly.net
Broadly my activities fall under the heading: Agile Coach, Interim Manager, Consultant and Training.
Here are some examples of how I have recently helped software development teams improve:
• Agile & Scrum training, more details on the Software Strategy website.
• Coaching for teams adopting and running Agile - broadly equivalent to Scrum Master
• Interim Development and Project Management: whether to adopt Agile or to rescue a project; I get involved for several weeks or month, fix things and hand it over
• Project and Team turn around
• Advice on transition to Agile development practices
• Development review
The common theme here is: helping software development team perform better to benefit their business customers.
If you think I may be able to help you please get in touch, allan@allankelly.net
What does an Agile coach do?
I often describe myself as an Agile Coach. In fact coaching teams in Agile development is only part of what I do but its the only bit that fits in two words. For some people the title Agile Coach is self-descriptive but for others it leaves the questioner none the wise.
With, Clark Ching’s recent blog about bread as a prompt, here is what I do as an Agile Coach.
The Coach helps teams adopt and improve Agile methods and practice. A Coach helps people rethink and change the way they go about development.
The Coach role is part Consultant and part embedded Trainer. My task is to help individuals understand how to apply Agile ideas in practice. Part of this involves painting a picture of how the Agile world works by telling stories. It involves explaining how to tackle specific problems, in a specific environment.
I tend to work from the process and management side, so I spend most of my time with team leaders, managers, business analysts and product managers. I attend their regular meetings and hold one-on-one sessions to help them try new approaches to the problems they face. That could be project planning, talking to the business, talking to the development team, or about ongoing problems.
Some Agile Coaches get involved with the technical side. They will pair program with developers and help them write tests for TDD. I don’t normally get involved with the actual coding any more but I do spend time with developers. Sometimes these are one-on-one conversations to address specific issues raised by managers, and sometimes they are conversations initiated by developers themselves. They have a question, they come to me and together we find an answer.
I also work with the entire team – managers, developers, testers, etc. – to help improve the team performance. This typically starts with a discussion about Agile, or a process mapping exercise. When a team is first starting out with Agile I like to run what I call “future-spectives”, or “reverse retrospectives”, in which the team choose the practices they would like to adopt.
Initially I run planning meetings, stand-up Scrum meetings in the mornings, reviews and retrospectives. Over time I like to hand these meetings over to team members to run themselves.
As the team improves I introduce new practices and new exercises. Gradually the team starts to look like a true Agile team. I think you need about six weeks to lay the foundations - hence my Scrum Foundation Programme.
I also help remove block and impediments when I can. It can also be as simple as buying books, or (as on a recent engagement) persuading the company to spend money on more technical training for the teams.
There are hundreds, even thousands, of small decisions made everyday during software development. These decisions are based on people’s mental models of how development works – or how it doesn’t work. Part of the Coach’s role is to help people unlearn many of these models and relearn models based on Agile values.
I’m often heard to say that it is in these thousands of small decisions that success or failure hides - “God is in the detail” or “The Devil is in the detail” if you prefer. By definition big decisions aren’t made that often and you usually know they are being made but small ones are made without thinking. Its no use switching to Agile if you keep making the small decisions based on some other model.
Its these small decisions that you can’t see in advance that can derail work. That’s part of the reason I prefer working as a Coach with a team rather than as a Trainer. Yes I deliver training but when I’m gone do people use it? When I’m there as a Coach I walk people through the changes, and I can provide any training as we go.
Each team is different so the approach has to be different every time. It also means that while I describe myself as an Agile Coach I sometimes work in a more interventionist manor. On occasions I will take over the management of the team – as a Development Manager or Project Manager – and help the team change that way.
Working this way is actually harder. Working as an external Coach you are looking into the team and you can see what is happening more clearly. When you are inside the team its often more difficult to see what needs doing. That said, once you have decided on action it is usually easier to make it happen.
On other occasions I’m more of a hit-and-run Consultant. I arrive, I talk to people, I make recommendations – perhaps write a report – and move on.
Finally, working as a Coach isn’t, and shouldn’t be, a full time job. I’m always conscious that the team shouldn’t become overly dependent on me. I prefer to spend only couple of days a week with a team – although when a company has several teams I may end up switching between them during a full week.
So that – briefly - is what this Agile Coach does for teams. And if you think some of this would help you please give me a call - 0845 310 8366 (UK), allan@allankelly.net. (Yes, that last paragraph is self serving but this is my blog!)
With, Clark Ching’s recent blog about bread as a prompt, here is what I do as an Agile Coach.
The Coach helps teams adopt and improve Agile methods and practice. A Coach helps people rethink and change the way they go about development.
The Coach role is part Consultant and part embedded Trainer. My task is to help individuals understand how to apply Agile ideas in practice. Part of this involves painting a picture of how the Agile world works by telling stories. It involves explaining how to tackle specific problems, in a specific environment.
I tend to work from the process and management side, so I spend most of my time with team leaders, managers, business analysts and product managers. I attend their regular meetings and hold one-on-one sessions to help them try new approaches to the problems they face. That could be project planning, talking to the business, talking to the development team, or about ongoing problems.
Some Agile Coaches get involved with the technical side. They will pair program with developers and help them write tests for TDD. I don’t normally get involved with the actual coding any more but I do spend time with developers. Sometimes these are one-on-one conversations to address specific issues raised by managers, and sometimes they are conversations initiated by developers themselves. They have a question, they come to me and together we find an answer.
I also work with the entire team – managers, developers, testers, etc. – to help improve the team performance. This typically starts with a discussion about Agile, or a process mapping exercise. When a team is first starting out with Agile I like to run what I call “future-spectives”, or “reverse retrospectives”, in which the team choose the practices they would like to adopt.
Initially I run planning meetings, stand-up Scrum meetings in the mornings, reviews and retrospectives. Over time I like to hand these meetings over to team members to run themselves.
As the team improves I introduce new practices and new exercises. Gradually the team starts to look like a true Agile team. I think you need about six weeks to lay the foundations - hence my Scrum Foundation Programme.
I also help remove block and impediments when I can. It can also be as simple as buying books, or (as on a recent engagement) persuading the company to spend money on more technical training for the teams.
There are hundreds, even thousands, of small decisions made everyday during software development. These decisions are based on people’s mental models of how development works – or how it doesn’t work. Part of the Coach’s role is to help people unlearn many of these models and relearn models based on Agile values.
I’m often heard to say that it is in these thousands of small decisions that success or failure hides - “God is in the detail” or “The Devil is in the detail” if you prefer. By definition big decisions aren’t made that often and you usually know they are being made but small ones are made without thinking. Its no use switching to Agile if you keep making the small decisions based on some other model.
Its these small decisions that you can’t see in advance that can derail work. That’s part of the reason I prefer working as a Coach with a team rather than as a Trainer. Yes I deliver training but when I’m gone do people use it? When I’m there as a Coach I walk people through the changes, and I can provide any training as we go.
Each team is different so the approach has to be different every time. It also means that while I describe myself as an Agile Coach I sometimes work in a more interventionist manor. On occasions I will take over the management of the team – as a Development Manager or Project Manager – and help the team change that way.
Working this way is actually harder. Working as an external Coach you are looking into the team and you can see what is happening more clearly. When you are inside the team its often more difficult to see what needs doing. That said, once you have decided on action it is usually easier to make it happen.
On other occasions I’m more of a hit-and-run Consultant. I arrive, I talk to people, I make recommendations – perhaps write a report – and move on.
Finally, working as a Coach isn’t, and shouldn’t be, a full time job. I’m always conscious that the team shouldn’t become overly dependent on me. I prefer to spend only couple of days a week with a team – although when a company has several teams I may end up switching between them during a full week.
So that – briefly - is what this Agile Coach does for teams. And if you think some of this would help you please give me a call - 0845 310 8366 (UK), allan@allankelly.net. (Yes, that last paragraph is self serving but this is my blog!)
Monday, May 04, 2009
The F progamming Language
My suggestion that C++ should split in two prompted an e-mail from Robin Williams. It seems there have been similar thoughts in the Fortran community about extensions to that language. The result is the F programming language.
Its not clear whether F is an active language or whether it is a moribund experiment. As Robin pointed out, one could consider Fortran 77 as the simpler version of Fortran.
I suppose a similar thing could happen with C++, people don’t have to use the new standard, they could just stick with C++ 1998. Hopefully some compiler vendors will offer a switch to switch off the C++ 200x features.
Or of course, we could just stick with C.
I was contact by a company a few weeks ago looking for some Agile and Test Driven Development training. At first my heart sank when they said they still had a lot of code in Pascal, or rather Object Pascal (Borland 7). But in the last couple of weeks I’ve been wondering if that’s a good thing.
I used to program in Borland (Object) Pascal 7 and it was a nice language. Sure we didn’t have meta-templates or reflection but it could do most of what I wanted without half the complications of modern C++, Java or C#.
Its not clear whether F is an active language or whether it is a moribund experiment. As Robin pointed out, one could consider Fortran 77 as the simpler version of Fortran.
I suppose a similar thing could happen with C++, people don’t have to use the new standard, they could just stick with C++ 1998. Hopefully some compiler vendors will offer a switch to switch off the C++ 200x features.
Or of course, we could just stick with C.
I was contact by a company a few weeks ago looking for some Agile and Test Driven Development training. At first my heart sank when they said they still had a lot of code in Pascal, or rather Object Pascal (Borland 7). But in the last couple of weeks I’ve been wondering if that’s a good thing.
I used to program in Borland (Object) Pascal 7 and it was a nice language. Sure we didn’t have meta-templates or reflection but it could do most of what I wanted without half the complications of modern C++, Java or C#.
Subscribe to:
Posts (Atom)