Seth Godin is one of the most famous bloggers around and has authored numerous books on the subject of marketing.
I just ran into this old post of his, 'Ads are the new tip jar'. It's an interesting, but controversial concept.
At first the idea certainly appealed.
Bloggers, like myself, spend a lot of time writing unique content and promoting it, usually for little financial reward but because bloggers are sharers; people who get genuine pleasure from sharing knowledge and opinion, and helping others.
Advertisers are fighting for attention. The attention deficit, in this age of information overload, is a real problem for producers of content and advertisers alike.
Google say you mustn't ask people to click on your ads. It's strictly against their policy. But what if you ask, "Please click on my ads, but only if they're potentially of interest and relevant to you"? Isn't that what advertisers want?
In a follow-up post, "Beating the status quo", Seth apologises, but defends his original post which came under quite a bit of criticism.
Even in the world I work in, large media companies have similar problems with the monetisation of online content. Rupert Murdoch of News Corp (the world's second largest media conglomerate) is tackling the problem head-on (see 'Murdoch on Leading the Charging Charge').
At 79 years old, and with a net worth of about $6bn, I think it's amazing that he still has the energy to fight this battle for his companies. His views on the subject of paying for content have been well publicised and we are just about to see whether or not people are willing to pay, at least for news, as he puts up his pay wall on The Times web site.
The world's media companies, and perhaps even bloggers, are watching with baited breath to see what happens. If he's successful, it could change the economy of the internet forever. Or will people simply go elsewhere?
Kelly.

I'm delighted to announce that IPC Media - the company I work for as Web Technology Director - has agreed to sponsor the first ever Agile Awards in the UK.
We're sponsoring the award for Best Agile Team - something that's close to my heart because teamwork is such an important part of agile software development. Regardless of any particular agile methodology, people are the most important aspect of any project, without a doubt.
I'm so pleased that IPC has been able to support this event. Regular readers of my blog will obviously know I'm a keen advocate of agile methods, and IPC has benefited significantly from the implementation of agile.
As per my recent blog post, I'm also speaking at the Agile Business Conference about IPC's experiences with agile. I hope it will be an interesting insight into one company's approach to agile, and how it's transformed our digital division into a really great place to work!
If you're not familiar with IPC Media, we produce over 85 iconic brands, with our magazines alone reaching almost 27 million UK adults while our online brands collectively reach 20 million users every month. Just a few of our top web sites include: goodtoknow.co.uk, marieclaire.co.uk, look.co.uk, instyle.co.uk, housetohome.co.uk, nowmagazine.co.uk, trustedreviews.com, nme.com, mousebreaker.com, ybw.com, whatsontv.co.uk, wallpaper.com, womanandhome.com, horseandhound.co.uk, countrylife.co.uk, cyclingweekly.co.uk, decanter.com, whatdigitalcamera.co.uk, nuts.co.uk, loaded.co.uk and many more!
Why not show your support for the awards too, either by booking a table at the dinner, and/or sponsoring an award!
Kelly.

The Agile Business Conference is sponsoring the Agile Awards 2010 – the inaugural Awards for the UK Agile Community.

There will be 10 Awards recognising the People, Projects and Products that have contributed to Agile in the UK.

Nominations for each Award are invited from all members of the UK Agile Community. Winners will be announced and Awards presented at the Agile Awards Dinner alongside the Agile Business Conference in London on 5th October.

Full details of the Awards Categories, Nominations and Sponsorship opportunities can be found at the Agile Awards Website: Agile Awards 2010

The Agile Awards 2010 is a not-for-profit event organised by Connections Agile Services in association with the Agile Business Conference. Any profits will be donated to the charities Shikamana School for Orphans in Kenya and the Macmillans Cancer Support.

ABC Super Early Bird rates available until 30 June and Early Bird until end July:
Book Your Place Here!

The next Agile Business Conference in London is being held on 5-6th October at the Inmarsat Conference Centre.
The theme of the conference this year is 'The Naked Truth'. As agile development has been adopted by many organisations and as it begins to mature, this year's conference aims to explore the realities of agile at both an organisational and project level, in an attempt to really get behind the skin of what it takes to make agile work.
In keeping with this theme, I'm delighted to announce that I will be doing one of the keynote presentations, entitled 'IPC Media - The Naked Truth'.
In case you haven't heard of IPC, it's one of the UK’s largest publishers of consumer magazines and websites, including many iconic brands such as NME, Nuts, Loaded, MouseBreaker, Good To Know, Now, Look, Marie Claire, In Style, Ideal Home, Living Etc, Trusted Reviews, Country Life and many more!
I am currently Web Technology Director at IPC, responsible for web technology across all brands.
IPC is a large organisation, with a lot of business stakeholders and a lot of web sites. Before implementing agile methods, this presented some really big challenges for the centralised digital division, trying to manage requests from many different business units, all with their own priorities!

The introduction of agile methods across all of IPC’s development teams has transformed the way the digital division works, aligning development teams with business units, managing priorities and expectations, speeding up delivery and building a reputation for delivering on its commitments, driving growth, and perhaps above all resulting in much stronger relationships between business and technology teams. Agile methods have really helped IPC Media to transform its digital operation.
Of course there is always room for improvement and a lot of lessons have been learned along the way! My keynote presentation will take a close look behind the scenes, revealing what life was like before and after agile, how the transformation was achieved, and highlighting some of the difficulties that had to be overcome to succeed.

There are also lots of other presentation tracks at the conference, ensuring that there's something of interest for everyone!
In one of these tracks, I'm also going to be presenting 10 Key Principles of Agile Software Development. This session aims to be a useful introduction for people relatively new to agile or wanting to cement their understanding of the key principles underlying all agile methodologies.
Why not come along? If my bit doesn't suit you, there should be lots of interesting people to learn from...
Kelly.

Scrum is the form of agile software development that has helped me the most.
It has helped me to transform the performance of the web development groups that I've led at both my current company and at my last one.
But, sometimes, I do wonder if Scrum is really agile enough?
There are quite a few regular meetings in Scrum. For short Sprints, this can be quite a big overhead. For me, that's where I can see why the Lean methodology appeals, especially to developers.
But there is also value in these meetings. So I thought I'd take a look at each Scrum meeting in turn, and assess whether or not their value really outweighs the effort?
First, there is Sprint Planning.
Sprint Planning happens before every Sprint. In our case, that's generally every two or three weeks. In Scrum, this meeting is split into two parts...
The first part is to discuss the requirements for all the User Stories intended for the Sprint as a team and give everyone on the team the chance to understand what is required. Questions are asked, and hopefully answered, that give people useful insight into how each User Story will be designed. Ambiguity is reduced and the team, hopefully, gains a common understanding of the User Stories and the requirements for the next Sprint. The collective experience of the team means that everyone gets the chance to input and the quality and appropriateness of the solution is potentially improved as a result. For a 2 week Sprint, this part of Sprint Planning generally takes about 2 hours, maybe less if the requirements for the relevant User Stories are well understood or well prepared beforehand.
Without this meeting, this discussion can still happen ad-hoc as and when someone picks up a User Story to develop. However, the chances are that the discussion will then occur with just the Product Owner, or perhaps one or two user representatives. It will be less onerous than having the whole team involved, that's for sure, but it won't benefit from the wisdom of crowds that you get from the group approach to Sprint Planning. The other thing about this ad-hoc approach is that it's more onerous for the Product Owner. They would need to be available most of every day and at the beck and call of the development team. If your Product Owner is not full-time and sitting with the development team, Sprint Planning is a useful way to ensure sufficient access to their time, and it's a useful way to pre-plan this regular event in everyone's diaries.
Weighing all of this up, I personally believe Sprint Planning is costly (in terms of time) but really worthwhile.
The second part of Sprint Planning can happen immediately after the first part, although some teams leave a day or so's gap between the two meetings, in order to clarify any outstanding questions before going to the next stage. The purpose of this second part of Sprint Planning is to plan the Sprint in detail.
The idea is that the team works together to break down all the User Stories into tasks, and estimate each task in hours. The team then plans their capacity for the next Sprint and decides collectively how much to commit to in the Sprint.
Personally I think it is useful to think about the tasks for larger User Stories, but unnecessary to do this for the smaller or simpler ones. Although Scrum suggests estimating all of the tasks in hours and going through this detailed planning process, personally I think this has some negative effects...
Obviously it can potentially take quite a long time, and with the whole team involved, that makes it an expensive meeting. But I also think - ironically - it can really hinder a team's ability to deliver on time. There are two reasons for this. Firstly, the team only estimates the tasks it can identify. They don't estimate the tasks they haven't identified. Inevitably there are some. Secondly, we all know by now that most developers are hopeless at estimating. Inevitably it their estimates will be wrong.
If you're on a large project, you may have already estimated all the User Stories on the Product Backlog in Points, in order to get an idea of how big the overall project is. If so, I personally think it's much more accurate for the team to commit to how many points they think they can deliver in the Sprint, and stick with that instead of estimating tasks in hours and trying to plan them in detail. In my experience, once a team's Velocity (the number of points delivered in a Sprint) has stabilised, this is a much more accurate way to gauge what a team can deliver in a Sprint, and it takes less time to do. For more information on this, see my post The Secret To Delivering On Time.
If the User Stories being discussed in the first part of Sprint Planning have not yet been estimated in points, I would suggest the team voting on the size of each User Story once its requirements have been discussed. Planning Poker is a great technique for doing this.
So, in summary, my personal view of Sprint Planning is this: It is worthwhile to discuss the requirements for the intended User Stories for the next Sprint as a team. It is worthwhile to estimate the User Stories in points, either when they go onto the backlog, or using Planning Poker to estimate them as a team in Sprint Planning. It is worthwhile for the team to make a collective decision about the amount of points they are able to commit to for the next Sprint, based on their experience of their past Velocity. Whereas breaking every single story into tasks, aiming to identify every task, estimating each task in hours, working out the precise capacity of the team for the next Sprint, and committing based on that, is not necessarily worthwhile. It takes a long time and can lead to less predictability about what can be delivered, meaning the team doesn't deliver on its commitments and people are disappointed.
During the Sprint, the only regular meeting in Scrum is the Daily Scrum itself.
This is where the whole team meets every day to answer three basic questions:

1. What did you do yesterday?
2. What are you going to do today?
3. Is there anything blocking your progress?

This meeting should take between 5 and 15 minutes. No longer.
There is no doubt in my mind that the Daily Scrum is extremely worthwhile.
It keeps the whole team joined up and provides the Product Owner with clear visibility of progress and any issues affecting the team. This is one of the key ways that Scrum helps to ensure that development teams can keep stakeholder's expectations in line with their emerging reality. This is critically important. The definition of a successful project, at least in my mind, is one that meets or exceeds expectations. Therefore I would never personally suggest that a team does not have their Daily Scrum. It's a way to manage expectations on a very granular level, ensuring expectations and reality don't diverge along the way.
At the end of the Sprint, there are two more meetings: the Sprint Review and Sprint Retrospective. These are useful meetings, but because they're at the end of the Sprint, they coincide with the Sprint Planning meeting which is at the start of the next Sprint. Sometimes this can make it seem like meeting overload for about 1 day of the Sprint, which to be honest can be a bit wearing.
The purpose of the Sprint Review meeting is to invite all interested people to come and see what the team has achieved in the last Sprint. If this is kept brief and informal, I think it's really nice for the team to show what they've done. It's also really nice for people interested in the project that can't be involved all the time to see what's going on and have the chance to provide regular feedback. This is another important mechanism to manage expectations in small, bite-sized pieces, which I've already mentioned I think is critically important to the success of any project. It's also a useful motivator for the team to achieve good results in each Sprint, as there will be a Review meeting afterwards so it tends to keep the team more focused on delivery.
And last but not least, the Sprint Retrospective. The purpose of the Retrospective is to build continuous improvement into the regular Sprint cycles. Again, there are three key questions to be discussed by the team in the Sprint Retrospective after each and every Sprint:

1. What went well?
2. What didn't?
3. What will the team do differently in the next Sprint?

Doing these Retrospectives so regularly throughout a project means that the learnings actually help to improve the team's Velocity throughout the project (and beyond). If it's kept simple, the things the team want to do differently in the next Sprint should be actionable and should actually make a difference to the efficiency and wellbeing of the team and the project. There's no question this is a meeting you can't afford to give up. There's just too much value in it.
However, because it coincides with so many other meetings at the start and end of each Sprint, it's important to keep it brief. For a 2 week Sprint, half an hour should be plenty of time to quickly brainstorm these three questions and action any changes in the next Sprint.
So, in summary - whilst on the face of it all these meetings don't seem very agile, I do believe the Scrum meetings do help the team to be agile throughout each Sprint. They help the team to gain a common understanding of what's required, improving the quality of the solution. They help the team to have a common understanding of progress and issues, improving the level of teamwork and visibility for the wider team. They help the team to see what's been achieved, improving the level of satisfaction and helping to manage expectations. And they help the team to learn from past issues and improve on them in the very near future.
My conclusion? Talking takes time. But it also adds value.
Kelly.
For more information on Scrum, see my series: How to implement Scrum in 10 easy steps!
Photo by incase

Hi everyone! I've been really pleased with how well my eBook has beeen selling. I normally sell it for $25, but I've decided to do another special offer.
You can now get my 55-page eBook - Agile Software Development Made Easy! - for just $10.
In the eBook, I've updated all my posts in the series '10 Key Principles of Agile Software Development' and 'How To Implement Scrum in 10 Easy Steps'. I've brought the text up-to-date with my current thinking, and in a few cases I've expanded on the points on my blog.
I've also reformatted them into PDF format, so it's convenient for you to take away from your computer, share with colleagues, read on the train or wherever is most convenient for you.

And that's not all! When you buy my eBook, I'll also send you two accompanying PowerPoint presentations that I normally sell for $15 on their own. That's my 55-page eBook and 2 PowerPoint presentations, all for just $10!

The only conditions of purchase are that you do not publish it (in print or on the web) and please do not circulate it outside of your organisation. Many thanks in advance for your cooperation with these conditions.

I sincerely hope you find it useful. I think you'll find it's pretty useful and for just $10 you can't really go wrong!

Click the button below to buy it now...











Many thanks!

Kelly.

In my series of posts "How to Implement Scrum in 10 Easy Steps", I refer to two stages of estimating:
Step 2 is how to estimate your Product Backlog.
Step 4 is estimating tasks in Sprint Planning.
Someone recently asked me a very good question - why estimate twice? I thought it would be worth addressing this question here...
The idea is that the first estimate, in points, is a high level estimate of everything on the Product Backlog.
At the time of estimating in points, the team has very little detail on what the requirements really are or what the feature has to do. They may be estimating from a simple heading or description.
This high level estimate helps with medium term planning (Release Planning) and helps the Product Owner to prioritise everything with some sense of how big the features are relative to each other.
Later, these points are used to calculate Velocity, which means the team get statistically better at predicting what they can achieve from very quick high-level estimates, which is is obviously very useful.
The second estimate is meant to be a detailed estimate for only those things that are included in the next Sprint.
Here, the team has the opportunity to potentially see some prior analysis of the requirements, to discuss the feature with the product owner and any other stakeholders, and to discuss the technical implications with the team.
At this stage, the team is in a much better position to break the feature down into tasks and estimate in hours.
At this stage, it is also possible to take account of the team's actual capacity at that time - i.e. how many team members available for the sprint, any other commitments, holidays, etc. With this information, the team should be able to plan the next Sprint reasonably accurately.
I have found that some teams like the second Sprint Planning estimates, and other teams can do without them.
The teams that do without still have the Sprint Planning meeting, which they still use it to discuss the requirements and technical design of the features in the next sprint, but they don't bother trying to break the features into tasks and estimate them in hours because they found invariably they were wrong anyway so it was a waste of everyone's time. Teams that are more accurate at estimating may be the ones that find it most useful for planning.
The teams that drop the hours estimates rely entirely on their historic Velocity (in points) to decide how much to commit to in each sprint, so they let the statistics take care of it.
If they have a lot of absence, or a team member missing, for any one Sprint, they simply commit to a slightly lower Velocity.
Personally I favour this approach. It's nice and simple and in my experience the statistical approach to estimating is just as accurate as the analytical approach, if not more so. The trouble with estimating analytically is that you only estimate what you can think of, and inevitably you can't really think of everything. Even if you think you can.
One thing I can say for sure, though, is that the Sprint Planning meeting is still exceptionally useful for the team to discuss the next Sprint together, whether you break down the tasks and estimate them or not.
In case you haven't discovered it, I've written quite a lot about agile estimating on my blog. You can see all of my posts on the topic here - Agile Estimating.
Kelly.
Photo by jronaldlee

Ahem. Actually that's a bit of an exaggeration. I have to be honest with you. Agile software development probably doesn't really save lives. There, you heard it from me first. I just felt like being melodramatic...

Someone once joked with me that "agile is great, but you wouldn't use it
on an air traffic control system!"

Actually, I would.

In fact, I wouldn't dare use anything else.

But agile is just a concept - a set of values and principles. What specific agile practices would be most appropriate in a life or death situation like this?

Those who read my blog will know I'm a big fan of Scrum. I have used Scrum on its own, without any other agile practices, and with a great deal of success. I would probably still use Scrum as the management approach to an air traffic control system, but I certainly wouldn't use it on its own.

For a project like this, where quality is absolutely critical and lives depend on it, I would put a strong emphasis on XP (Extreme Programming).

Personally I would describe Scrum as an agile management method, whereas XP is more about agile engineering and XP has some important practices to assure quality.

One is Pair Programming. If we're going to write code that people's lives depend on, there's no way I would want a single line of code written by any one person. I would want every line scrutinised, every assumption challenged, and every line sanity-checked with a second pair of eyes. With Pair Programming, this level of continuous peer review obviously comes as standard.

Another QA aspect of XP is automated unit testing and Test Driven Development (TDD). On a project like this, I would want 100% test coverage. I would want to know that every scenario had repeatable tests, so we could be completely sure that nothing ever regressed after passing the initial tests without us knowing about it. Anything less would simply be inadequate.

There are many specific practices in Scrum and XP that would help to mitigate risk and assure quality on a project as critical as an air traffic control system. But these two practices in particular - Pair Programming and Test Driven Development - if followed religiously, I am sure would deliver higher quality code than any other approach to development and testing.

In commercial situations, this level of rigour isn't always appropriate or affordable. But when quality is paramount, these engineering practices make complete sense. For an air traffic control system, the overhead of doing them 100% of the time is completely justified by the lives they could save.

In a situation like this, I wouldn't have it any other way.

Kelly.

Photo by Akinori YAMADA