Agile development is often initiated by the development team itself. Whilst they may find some good advantages, the most profound benefits of agile software development will not be realised unless it is driven from the top.

Here's why:

1. Multi-disciplined teams

One of the key concepts of agile development is the idea of multi-disciplined teams - "one team". An agile development team needs all the skills necessary to complete its task from cradle to grave. From initial request to delivery to market, the team should be able to deliver without reference to another team.

Having multi-disciplined teams reduces coordination, creates clear ownership and responsibility, speeds up delivery, and empowers the team. As I said earlier, profound benefits, but benefits only possible to realise often by making changes to the organisational structure, which usually need to be driven from the top.

2. Co-location

Another key concept of agile software development is co-location. Ideally the whole team will all be located in the same place - not just the same office but literally sitting side by side in the same room or space.

Having co-located teams also reduces coordination, speeds up communication, fosters closer working relationships, creates the opportunity for continuous collaboration, enables face-to-face communication, means you can get better visibility of progress etc by putting things on the wall, and strenghtens team spirit.

These factors, over the course of a project, can make or break it. Co-location often requires management intervention, in order to move people around so they can all be together. Sometimes it may be even more fundamental than that - moving people from offices in different cities and physically reorganising the company. So again, it really needs to be driven from the top.

3. Product ownership

A common problem in large organisations is that there are many stakeholders for any given product. It is also common for development teams to be developing and maintaining multiple products. The effect of this is that many people make requests, and to each of the stakeholders, their request is naturally the most important.

With so many requests coming from so many directions, how does a development team prioritise and manage expectations. Usually, it's a case of who shouts loudest! This is not the best approach for the business, as it's sometimes those demanding the most attention that get priority and not those that drive the most business benefit. It also creates an unpleasant working environment, where the default system for getting things done is to moan, shout and escalate. It's not the most motivating way to work, and it's not the most effective.

A development team needs a clear Product Owner, at least for each product if not for the whole team. The Product Owner needs to be the one person who prioritises on behalf of the business, and needs to have real authority to make decisions and stand by them. The team need to know that this is the one person they should listen to the most.

Having clear and empowered Product Owners transforms a teams' performance by enabling them to work on the most important requests, cutting out a lot of noise, creating a more positive working environment, motivating the team, and strengthening business relationships.

The trouble is, in large businesses, there is often not one person who naturally holds this position and has this level of authority. The role of Product Owner needs to be explicitly assigned to someone and communicated clearly to all stakeholders. As this role often spans business units, this usually needs to come from the top.

4. Agile project management/Stakeholder expectations

With agile project management, stakeholder expectations need to change. Where they may be used to seeing a full requirements document and/or specification up-front, they shouldn't expect to see that in agile. Where they may be used to seeing a detailed project plan in the form of a gantt chart, they shouldn't expect to see that in agile. Unless they know that, understand why that is, and really believe in the benefits of agile and why there is a need for change, this will potentially cause you problems.

Since these stakeholders are often senior managers and directors of the organisation, these steps are an important part of selling agile and where the real change management challenge is. This needs to be carefully managed and the message needs to reach all key stakeholders, at all levels of the organisation. In order to secure real buy-in, this usually needs to be driven from the top.

5. Different values

Agile development has different values to traditional project management methodologies. Unless people understand what these values are, how they are different to previous way of working, they will struggle to adopt or embrace some key aspects of agile software development.

People need to understand that whilst they will have less predictability and won't be able to see a clearly defined fixed scope, instead they will get a high-performing team that can deliver software faster and to a higher quality, and that they'll get much more visibility and flexibility that's more likely to meet their changing expectations, and with less bureacracy.

Everyone needs to know that it's okay to lack that perceived clarity from the outset in favour of flexibility and the other benefits that come from adopting agile development. They need to know that agile principles and practices mitigate risk in a different way - not with detailed planning and analysis and strict control, but through visibility, transparency and frequent delivery of working software in small incremental iterations.

People need to know that these values are supported from the top; that it's not only okay to behave in line with these new principles, it's expected.

Summary

Adopting agile development will help with many issues. But without these things being led from the top, you will only be partially successful and you will only see a small fraction of the possible benefits.

Kelly.

Photo by lepiaf.geo

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 a special offer for 1 month only. It's a kind of belated new-year sale I suppose you could say!

Throughout February, you can now get my 55-page eBook - Agile Software Development Made Easy! - for just $10.

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 it, I'll also send you two accompanying PowerPoint presentations that I normally sell for $15 on their own. Not bad for $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.

Pair Programming. It's probably one of the most extreme practices of eXtreme Programming (XP). It's an area of agile software development that polarises opinion.

The concept is simple enough. Two developers work side by side on the same piece of work, sharing a keyboard and screen and working together to produce the code.

The main advantage of pair programming is usually cited as improving quality, which also improves productivity further down the line.

Another advantage is spreading knowledge, as at least two people will know each area of the system. And it can also help with skills development - a kind of coaching and mentoring technique with one of the pair more experienced than the other.

It's also possible to benefit from the theory that two brains are better than one. A simple way of explaining this is that two people have very different experiences. One may see a solution that the other doesn't. It's possible that two minds might lead to solutions that are quicker to implement and simpler to maintain.

Even without pair programming, it's quite common for two developers to work together when they hit a particularly thorny problem. It's usually a little while before someone declares they are stuck and asks for help. With pair programming, this situation doesn't really arise, so time is not lost with single developers perservering on their own.

The other area it can help with is motivation and retaining focus. Someone is much less inclined to become distracted and spend time on facebook, for instance, when they are working with a colleague.

The motivation advantage reminds me of DIY in my case. I hate DIY! I will put it off for as long as possible. I'm simply not interested enough, so it doesn't get done. My solution to this? Invite my father-in-law round! Once he's in, he's so keen to get started, and I have to get it done because that's why he came over. He gets me started and keeps me focused. Hopefully you don't have wide-spread motivation problems in your team, or you have deeper problems to worry about! But we all go through short periods like this, and pair programming keeps them to a minimum.

On the other hand, pair programming also has some disadvantages.

In the short-term, there is a loss of productivity, or at least perceived productivity. You have to have sufficient budget to put two developers on each piece of work. If your team needs specialist skills, you have to have a team where there are at least two people with each major skillset. And when you need to hire another person, you ideally need to hire in pairs.

I think it's also important that the team members have the right chemistry. That they spark off each other. And can work closely together without differing opinions causing endless frustration. There's a loss of autonomy, having to explain everything and constantly build concensus. Sometimes you'll be constrained by your partner; other times they may be going too fast for you.

This reminds me of back-seat drivers. It's so annoying when someone sitting beside you keeps interfering and just won't let you drive how you want to! It's tiring and frustrating.

These are important soft-factors that can make or break pair programming in practice.

In the end then, like many agile development practices, you have to look at the unique circumstances of your team, and understanding these factors, decide for yourself when and if to adopt pair programming.

There is currently a discussion on pair programming on my new Agile Community. If you have something to add, why not go and join in?

Kelly.

Photo by kurtthomashunt

Hi everyone! This blog just seems to keep on growing! It's a bit belated, but I just had a look back at last year's stats...

2009 brought over 750,000 page views from 200,000 people! That's astonishing to me - it's so good to think that this blog might have helped so many people.

Thank you all for visiting!

Kelly.

Photo by Sreejith K

Back in September, I renamed this blog from 'All About Agile' to Agile Software Development Made Easy!

If you are one of the many people kind enough to link to my blog on your home page, but you're still listing me under the old name, please would you update the link text to Agile Software Development Made Easy!

That would help me with Google and obviously it's better to use the new name. Much appreciated!

Kelly.

I recently came across this agile estimating experiment by Lance Walton. The article is quite old now but I still found it very interesting...

In recent years, I've had quite a fascination with the concept of velocity and estimating in points.

To be honest, it took me quite a while to really get this concept! But once I understood the statistical nature of it - once the penny finally dropped - I have loved it ever since!

In my experience, it really is the secret to delivering on time - the holy grail of software development projects for decades. And better still, it's so easy to do. Well, fairly!

The biggest obstacle of all seems to be explaining it to people without sounding completely mad. It really does sound quite whacky. Some weird development technique practiced only by people with long beards and sandals! :-)

But it's worth doing. Because it works!

Lance's experiement is interesting because he is using statistics to show evidence that estimating user stories in points was just as accurate as estimating tasks in hours. And in his case at least, it was.

I can remember trying to convince some teams to try estimating in points. With so little information, they were convinced that estimating user stories in points wouldn't be accurate. The truth is they were probably right. Estimating in points isn't accurate. My argument for using points was somewhat counter-intuitive. I remember saying that points will be just as inaccurate as any other method, but would take less time to do and then they'd have more time to get on with the job!

What is interesting, though, is that when you estimate with relativity using points, and plan future iterations based on past velocity, it's remarkable how predictable you can be. Even with very little information at the point of estimating.

If you're interested in this topic, you can read more from me here: agile estimating

Kelly.

Photo by Haria Varlan

Finally I've managed to convert my two most popular blog series' - 10 Key Principles of Agile Software Development, and How To Implement Scrum in 10 Easy Steps - into a book!

It's a fairly short book. 108 pages to be precise! A lot of books about agile are quite big, with small text, and are quite heavy-going I think. What I've tried to do with my book is to create something simple - a bit like the popular One Minute Manager series - something that's not too academic and can be read quickly by people who just want to get started with agile as soon as possible!

I don't expect readers of my blog to buy it, as the content of the book is all free here. But for those that haven't discovered my blog, or for those that prefer books, it's now available on Amazon.com.

If you like the idea of the book, but would prefer a version you can share with your colleagues, there's always the ebook, which you can buy here!

Kelly.

Back in September 2009, I ran a poll on what agile project management software people would recommend. I was amazed at the response - so far (Jan 2010), about 2,000 people have voted!

For those that haven't been back to the poll to see the results, here they are:


Lots of other agile project management software got a handful of votes under the 'other' category. I removed these from the poll simply because it was getting too long and unwieldy. Some of these apps may well be excellent, but just don't have a big enough following to get lots of votes yet. Here is the list of other applications people recommended, just to make sure their votes are not disregarded:

AgileZen
Trac
TargetProcess
RedMine
Scrum'd
ScrumWorks
Bright Green Projects
IceScrum
BananaScrum
iMeta Agility
AxoSoft
Pivot
ProjectCards
ExtremePlanner
ProWorkflow
Rational Team Concert
Unfuddle
Skinnyboard

Finally, if you haven't seen it already, there's a discussion going on about Agile Project Management Software over on my Agile Community...

Kelly.

Hi everyone. I'm delighted with the progress of my new Agile Community. It's only been live for a week and already we have over 200 members, who are actively contributing to discussions on the agile forum on all sorts of topics from agile project management software, feedback mechanisms, team members who don't want agile, Scrum on large projects, metrics, and more!

As well as connecting with other members of the agile community and participating in these discussions - or simply getting your questions answered - there's also an events section where you can post events for the community. Here you can access free webinars, training courses, workshops and agile conferences.

It's also possible to write your own blog posts, add videos and photos, and keep up with all the latest tweets on Twitter that mention agile.

Finally, the news section lets you post links to interesting articles for the community, vote on them, and keep track of what the agile community thinks is important. This section already has some really interesting links.

The number of people signing up and contributing has exceeded my expectations so far, but obviously the success of this community relies on people's continued participation. Sign up now to be part of this new Agile Community and get involved!

Kelly.

Happy new year!

I've been on holiday for a few weeks, so apart from setting up my new Agile Community, I haven't blogged for a little while.

I thought I'd start the new year with a round-up of some of the things in my RSS reader that I found interesting when I got back from my holiday.

Here they are:

Personal Retrospectives
Quality assurance; consistency in testing
Scaling agile: Get your focus story together
Build trust between teams with Ambassadors
Specialists should become more
Pragmatic Personas: Putting the user back into user stories
Free Scrum webinars
Agile requirements at scale
ScrumMaster as impediment
Kanban and Scrum: making the most of both
Stabilisation sprints: necessary evil or waste?
Five benefits of feature teams
Agile project management insights
Mary Poppendieck on the "tyranny of the plan"
Scrum tools
Agile Design: Intentional yet emergent

Hope you enjoy my selection!

Kelly.

P.S. Don't forget to sign up to my new Agile Community to be part of this community!

As a blogger myself, I know how hard it can be to get links to your blog, and to attract visitors to your site. Promoting your blog posts in some ways is as hard as writing them! The new Agile Community I have just set up has a News section designed for sharing links with the community.

In this section, you can post links to your blog posts and share them with this growing community. Apart from highlighting your blog post to the community, this will also allow you to create links to your site, which of course will ultimately help you with your Google ranking.

Go ahead and post your links. As long as you don't post them in the discussions area, and as long as they are about some aspect of agile development, it will not be seen as spam and should be a useful way for you to promote your content and for the community to find interesting points of view to help inform their thinking.

Kelly.

In setting up this new Agile Forum, I've added some cool features that mean it's already so much more than the forum I originally intended. So I've changed the name to Agile Community.

The features now include:

• Forum - have discussions with your peers and get answers from the community
  
• News - share links and vote for the ones you like (ala Digg)
• Groups - set up your own groups, for instance local or topic based groups
  
• Events - list agile events and see who's attending
• Blogs - enter your own blog posts and share your thoughts with the community
• Twitter - keep track of tweets about agile
  
• Videos - share yours or other people's videos from YouTube
• Photos - share photos of your team or events
• Members - find and communicate with other members of the community

Hopefully we will manage to get this Agile Community going; I'm hoping it can offer so much more than a straightforward forum!

We have 80 members already, which I think is pretty good considering it's only been live for a few days and we're still in the new year holidays. But its success will obviously depend entirely on your participation, so please go ahead and sign up, start a discussion, list an event, share news, write a blog post, or whatever captures your imagination! One action from everyone and it should be a lively and interesting place for us all to help others and learn from each other.

Finally, if you've already signed up and haven't already added your photo, please go ahead and do so. If this is going to be a real community - a community of real people helping others with similar interests - it's so much better to put a face to a name...

Happy new year!

Kelly.