Feed aggregator

Multiple Releases In Progress

Walter Bodwell's Blog - Mon, 03/15/2010 - 21:46

A major goal in agile is to stay releasable. Do a little. Get feedback. Do a little more. In fact, a great question to ask is what would prevent you from releasing what you have now? The answer can help you highlight areas where changes might have a significant benefit. Look at each thing, prioritize it relative to the others and then try to change so that each item is handled during each iteration.

read more

How To Be An Agile Leader

All About Agile - Wed, 03/10/2010 - 08:03

Leadership is a mysterious art. Whether you're leading an agile development team or not, some of the important qualities of an inspirational leader are obviously the same.

My latest blog post on the subject is now live on Jurgen Appelo's new site, "Management 3.0". Take a look by clicking on the link below!

How To Be An Agile Leader

Kelly.

Photo by BrianForbes37

3 Days To Go!

All About Agile - Thu, 02/25/2010 - 05:39

There are now only 3 days to go to take advantage of the special offer on my eBook! Click here to find out more...

Kelly.

10 Things I Hate About Agile Development!

All About Agile - Mon, 02/22/2010 - 11:00

Agile development. Love it or hate it, there's no doubt that it's here to stay. I've enjoyed a great deal of success thanks to agile software development and agile project management methods, but here are 10 things I hate about Agile!

1. Saying you're doing Agile just cos you're doing daily stand-ups. You're not doing agile. There is so much more to agile practices than this! Yet I'm surprised how often I've heard that story. It really is remarkable.

2. Worrying about the difference between 'Agile' (big A) and 'agile' (small a). You mean you spell it with a big A, omg you're so not cool! The differentiation is between Agile methods and being 'agile', in the true sense of the word. Most people probably don't get the subtlety. When people split hairs about this it gets on my nerves and makes so-called agilists sound like a bunch of overly-religious nerds.

3. Thinking that agile is a silver bullet and will solve all your problems. That's so naiive, of course it won't! Humans and software are a complex mix with any methodology, let alone with an added dose of organisational complexity. Agile development will probably help with many things, but it still requires a great deal of skill and there is no magic button.

4. Claiming to be Agile when you're clearly not 'agile'. Yes, we're doing all the major agile practices, but we're not flexible and we don't seem to understand the underlying agile principles. Were agile in practice but don't demonstrate the values of openness, attention to quality, collaboration, team spirit, etc.

5. People who are anti-agile but with nothing constructive to say about why. I hate that. I've had a few turn up here and enlighten us all with their intellectual comments, such as 'snake oil' or 'agile is a hoax'. Losers!

6. Blaming agile - "I tried it once and didn't like it". Projects are difficult. Some projects may even fail, even if you are using agile project management methods. As I said earlier, agile is not a silver bullet. It's important not to blame agile when things go wrong, just as it's important not to claim it's the saviour for all of your ills. Don't blame the process. It's a bit like bad workmen blaming their tools. It's not big and it's not clever!

7. Using agile as an excuse - "no we can't do that, cos it's not Agile". "No I'm sorry, we don't do it that way here'. Following the agile process without fail regardless of the circumstances - even if it's contrary to what the situation really requires for the business or for the customer. If the process is the most important thing, above all else, that's not agile!

8. People who think they're smart enough to adapt agile processes before they've really got enough experience to understand how and *why* it works. It's an easy trap to fall into, but one that should be resisted. Otherwise it's so easy to throw the baby out with the bathwater!

9. People who use agile as an excuse for having no process or producing no documentation. If documents are required or useful, there's no reason why an agile development team shouldn't produce them. Just not all up-front; do it as required to support each feature or iteration. JFDI (Just F'ing Do It) is not agile!

10. People who know more about agile development than me. They're so smug ;-)

Ah, that's better! I feel much better now I've got that off my chest.

Thank you for listening!

Kelly.

P.S. - one more thing! I hate people who rant about agile development on agile blogs. That's just silly.

Picture by beneneuman

One Big Team

Walter Bodwell's Blog - Sat, 02/20/2010 - 14:52

There's a notable difference between working for a start up and working for a large company. One major distinction is focus. Start ups that aren't focused don't tend to last long. Large companies can afford to go many directions at once. But they often do so at a cost. By fighting against themselves with cross purposes they lose some of the leverage that their size could provide.

read more

10 Days To Go!

All About Agile - Thu, 02/18/2010 - 03:34

There are now only 10 days to go to take advantage of the special offer on my eBook! Click here to find out more...

Kelly.

Agile Business Conference 2010 in London

All About Agile - Mon, 02/15/2010 - 11:00

I've recently received an email from the organisers of the Agile Business Conference 2010 in London. For those that aren't on their mailing list, I've copied their message below for you.

They're asking for suggestions for the topics of the various breakout sessions. If you're planning to go, I strongly encourage you to put your ideas forward!

I've been asked if I might like to speak at the conference this year. I don't think I'm going to do that; that's not really my thing! Although I'm flattered and tempted. I might run one of the breakout sessions though. If you think I should, then please let me know in the comments of this post what you think I should do it on?

Kelly.
London, 5th- 6th October 2010
The Naked Truth

The Agile Business Conference 2010 will be held in London on 5th and 6th October. The purpose of this Newsletter is to provide an update on our plans for ABC 2010.

We have taken note of the trends from sponsors’ and attendees’ feedback from past ABC events, and we have included these and taken action so that the Agile Business Conference 2010 will have a new and refreshing format:

• We want to move away from the standard “three streams” within the Conference and to provide a broader, relevant, interactive event so that attendees can navigate their own way through a variety of sessions.
• To ensure a broad, vibrant and interactive agenda; instead of the usual Call for Papers and Presentations we are inviting you to contact us if you would like to run a session or even if you just have an idea of a topic you would like to see covered by a session. As the “people in the front line” we are sure that your everyday experiences will create an agenda that is pertinent, interesting and interactive.
• We are seeking sessions of 40 minutes that address a broad spectrum of Agile topics. Rather than just having presentations, we are looking for a mixture of sessions that cover a wide variety of Agile topics and include interactive sessions, workshops and open space gatherings alongside some more formal experiential presentations.
• We will have some of the best keynotes from the world of Agile – with presentations based on their practical, real-world experience – and we will be extending the programme to incorporate a wider selection of sessions for delegates.

Our theme for 2010 is centred on the detail and the practicalities of evaluating, enabling and making Agile work for you and your organisation - regardless of your sector, start point or history.
For example:

• A CxO may want the opportunity to build confidence that a move towards an investment in Agile is valid, beneficial and practical.
• A Project Manager may be interested in managing risk, driving predictability of project outcomes and understanding how progress towards the agreed goal can be observed and reported.
• A Resource Manager may be interested in understanding how Agile practices can impact and improve on how resources are managed and how the capabilities of their resources need to be built and assessed.
• A Quality Manager may want to understand the impact an Agile approach will have on an existing Quality Management System and how to deal with that.
• A Software Developer may be interested in how a combination of technical Agile practices genuinely leads to significant improvements in software quality.

The potential list of topics is endless - the actual list will be up to you.

Agile has now matured and become well established in many organisations.

• What are these organisations doing differently today?
• What have they learnt along the journey?
• What would they do differently if they could turn back the clock?

We would like to explore The Naked Truth about Agile evaluation, enablement and adoption, and to discover and discuss the realities at both organisational and project level.
So, if you have a story to tell in which you can unwrap Agile and allow a clear insight into your experience, or you have some real expertise in some aspect of Agile, or you have an idea for a session that you would like to run or simply just participate in, please take a look at the outline for the ABC 2010 event below and contact me at mary@agileconference.org
Again, based on feedback from previous events we are planning 6 tracks running in parallel this year:

• Education: An introduction to Scrum, XP, DSDM Atern, Lean, Kanban, AUP etc.
• Corporate Strength Agile: These sessions will have an emphasis on the ‘how to…..’ make Agile work in large or complex organisations or environments.
• Public Sector: Experiences of how Agile has been introduced, the benefits, how is it different for the Public Sector.
• Technical: Sessions that concentrate on quality, testing and delivery.
• Business and Organisational Change: What does Agile have to offer? What are the routes to take and the pitfalls to avoid when introducing and implementing change?
• Troubleshooting Agile: Free format, flexible sessions.

All submissions will go through two reviewing processes; a double-blind and Conference Committee (non-blind).

If you are interested in running a session, or want simply to suggest a session that you would like to participate in, please download and complete the form attached here and submit it to mary@agileconference.org by 15 March 2010.

A win-win for everybody would be to match real answers from real experts to real questions from real delegates.

Successful proposals will be notified by 23 April.

***

Photo by liz noise

5 Reasons Why Agile Development Must Be Driven from the Top

All About Agile - Mon, 02/08/2010 - 11:00

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

Special Offer! Get My Agile eBook And Presentations For Just $10 For 1 Month Only

All About Agile - Tue, 02/02/2010 - 04:31

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 - An Extremely Agile Practice

All About Agile - Sun, 01/31/2010 - 07:17

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

Agile Visitors in 2009

All About Agile - Sat, 01/30/2010 - 04:44

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

'All About Agile' is no more!

All About Agile - Tue, 01/26/2010 - 07:34

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.

Agile Software Development Estimating Experiment

All About Agile - Mon, 01/25/2010 - 13:08

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

55 Page eBook - Agile Software Development Made Easy!

All About Agile - Tue, 01/19/2010 - 03:12

Here is my 55 page eBook, 'Agile Software Development Made Easy!'.

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 the content away from your computer, share with colleagues, read on the train or wherever it's most convenient for you!

I'm selling this 55 page eBook for just $25. And when you buy it, I'll also send you two accompanying PowerPoint presentations that I normally sell for $15 on their own.

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. Your feedback is very welcome as always - please let me know what you think via comments on this post.

Click the button below to buy now...











Many thanks!

Kelly.

Agile Software Development Made Easy! - The Book

All About Agile - Tue, 01/19/2010 - 03:10

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.

Agile Project Management Software

All About Agile - Tue, 01/12/2010 - 11:00

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.

Agile Community has over 200 members in first week

All About Agile - Sun, 01/10/2010 - 05:54

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.

Managing Tasks

Walter Bodwell's Blog - Sat, 01/09/2010 - 20:31

Stories represent business value. If you accomplish them, it will help the business. Tasks, on the other hand, are a means to track what must be done to accomplish those stories. They can be really helpful in communicating what work remains and coordinating on who does it.

read more

New Year Round-up!

All About Agile - Tue, 01/05/2010 - 11:18

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!

Calling All Agile Bloggers: Post Your Links Here!

All About Agile - Mon, 01/04/2010 - 07:34

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.