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.

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

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.

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

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

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.

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.

Some time ago, I set up a Google group for people to discuss all sorts of things about agile software development and agile project management, regardless of methodology.

To be honest, I never really promoted it much and Google has limited features and allows very little control over how the group works.

So now I've decided to set up a new Agile Forum using a technology called Ning.

Forums are notoriously difficult to get started, so if you don't find what you're looking for here, please go ahead and ask a question on the Agile Forum. Until there is a thriving community, I will answer any questions myself, so for a while you'll get direct access to me and all my experience of agile and other methods, absolutely free of charge.

The new Agile Forum has some other useful features:

• You can set up your own Groups, if perhaps you want to establish a local agile community, or for instance if you want to create a group to discuss particular aspects of agile, eg Scrum, eXtreme Programming, Lean or whatever you like!
  
  
• You can also add photos and videos, and attach files to forum posts if you have files you would like to share with the agile community.
  
  
• Last but not least, you can also add events - maybe training, conferences or meet-ups for example - to make sure the agile community doesn't miss a thing!

Of course I realise there's not a lot there for you to see just yet, but all communities have to start somewhere! Why not sign up to this Agile Forum and maybe ask a question, create a group or add an event?

Kelly.

Photo by altemark

This is a guest blog post from Bruno Sbille...

"During the latest phase of our project, I had to work with a team of 7 people . But none of them were 100% on the project. To describe the situation we had:

• Two team members 80% on project
• Two part-time
• One expert who was 15 days on the project over a period of 3 months
• A person 20% on project
• A person who was involved 5 days on the project, but when he was there … the whole team should be present.

This situation could have turned into a nightmare … how to be sure everyone has the right level of information? How to communicate? How to fix a meeting? If a developer need the webdesigner, how can we sure she will be present?

Well at first I wanted to tell youIi had invented a new tool that combines:

- a very advanced calculation algorithm
- advanced planning techniques
- a module with availability management.

But the truth is far more simple…

Make it V-I-S-U-A-L

In fact these potential issues were solved fairly quickly because we used very powerful and easy-to-set-up follow-up and communication tool called “Visual Calendar”.

Visual Calendar consists of a large sheet of paper on which you draw a one month calendar on which you stick post-it notes.

Here’s how to set up this tool:

1. During the sprint planning, you build the visual calendar for the current month. A good practice is to match your sprint schedule. Example: imagine that your sprint #2 runs from October 19 to November 13. You also know that the sprint planning sprint #3 will take place on November 15 so you can build your Visual Calendar from October 19 to November 15.

2. On the calendar you identify the days-off, or any non-working day for your customer .

3. Place on the calendar all the dates already negotiated with the product owner or customer, e.g. demo, sprint review, sprint planning, go live …

4. You identify each member (Team Member, Scrum Master and Product Owner) with a color.

5. Each team member specify holidays and availabilities on the calendar. Day “ON”, the person is on the project, and days “OFF”, the person is not available on the project.

Then you play with the concepts of days ON and OFF to not overload your schedule and to have maximum visibility.

In our example the full-time staff indicate their days of absence “days off” for the people part – time, they specify their days of prence “days ON.

Example 1: Bob is 80% on the project, he will not be available for 4 days in the sprint, he sticks 4 post-its of his color on the calendar with the words “Bob Off” for the days he is not present on the project.

Example2: Gerard will be 2 days on the project, place 2 post-its of color with the words “Gerard ON” on the calendar.

6. Every “key” event is added during sprint presence of the product owner, meetings, travel outside, unavailabilities etc..

To raise awareness of the team to the importance we give to this tool, each month a different team member builds it (completion time between 5 and 15 minutes). It is also an opportunity for everyone to show some creativity.

Reader: “Okay, okay Bruno you seems to be a nice guy but… you tell us to make it visual and you only use text to explain your concept…strange isn’it ?”

Bruno: “What can i say…you’re totally right ! Here’s the Visual Calendar with a Visual explanation (Click to enlarge) ”

This is it!

With this tool you can immediately answer questions like:

Team Member: “Is Gerard present today ? I need him to complete my module!”

Product Owner: “I will validate some user stories, what is the best day for me to come this week?”

Team Member: “When can we organize our meeting with the client and our technical expert?”

Team member: “When is the product owner coming?”

X: “When is the demo ? I have not received the invitation?”

Scrum Master: “Which day is best to offer the team a Belgian beer ?”

and cherry on the cake … it works even in cases of network failure, viruses or other computer problems!

As always, i suggest you to update your tool according to your team’s feedback (see gallery below)!

As always, I am not asking you to believe me … Just give it a try! Go test this tool, customize it your way, invent your own rules … and give me feedback on your experience

Cheers,

Bruno.

Gallery:
Iteration 1
Iteration 2 - more visual
Iteration 3 - we add colours!
An event
Use colours

About Bruno: I've been in IT and Business consultancy for more than 10 years. In addition to my project management experience, these last four years I had the opportunity to discover a lot of new "things" to put in my "toolbox": Scrum, Agile but also NLP, coaching, people management, creativity techniques... I'm passionate about "making things happen". I blog regularly in English and French about Scrum, Agile and Management on http://brunosbille.com (Scrum and Agile in Belgium)."

I was asked recently to answer 5 questions about agile project management for a feature on PM Boulevard. I thought you might appreciate seeing them here too...

1. How has the Agile practice evolved over the last two years?

I don’t personally think that agile practices have particularly changed in the last two years, however there is clearly a stronger emphasis on some elements more than others now.

Scrum certainly seems to have crossed into the mainstream since I started my blog. Even though it was less than 3 years ago, Scrum still felt quite new and innovative in the UK at that time. I work in the web development sector and now every company I meet seems to be doing Scrum.

Another change is the interest in agile from the project management community. This seems significant as people start to think more about how best to apply agile on larger projects. Looking at Google Trends, which shows search volumes over time, the graph below shows that search demand for ‘agile project management’ started relatively late in terms of agile adoption, and interest is still growing strongly now.

The other thing that seems to be a clear trend during 2009 is a much stronger emphasis on Lean software development from the agile community. It seems to have really gathered pace in the last year or so.

2. What would you tell someone who thinks Agile is just another fad?

I don’t think agile can be called a fad now! Admittedly it may not be for everyone, but it’s certainly not a small minority any more. Again using Google Trends to gauge search demand and therefore people’s interest in a topic, 'agile software development' has been in high demand on Google as far back as 2005 (although it’s obviously been around a lot longer than that), and has remained high ever since. I don’t think something can be called a fad when the buzz has been going for over 5 years already and is continuing to grow strongly. For anyone that hates the idea of agile and is secretly hoping it might just go away, you’d better get used to it because I think it’s here to stay!

3. What are some tools that you use?

I know this might sound like it isn’t much help to others, but we don’t actually use any project management tools or any specific agile tools. Those who read my blog will know I’m a big fan of Excel and the whiteboard, although clearly agile project management tools would be a useful addition in some circumstances, particularly where teams or stakeholders are distributed across multiple locations or projects are particularly large.

In my experience, I’ve had several development teams practicing agile web development using Scrum, and they have been able to operate Scrum on a team-by-team basis without the need for any specialist tools to help manage. Instead we have placed a much stronger emphasis on face-to-face communication and collaboration, using Excel to manage product backlogs, user stories to convey requirements, and whiteboards to provide visibility.

4. Do you think that Agile and the PMBOK can coexist?

I definitely think agile and PMBOK can coexist, although some elements of PMBOK would be irrelevant to apply on an agile project. However there are plenty of elements of PMBOK that are not addressed at all within agile methodologies, for instance project initiation, cost management, risk management and various other aspects too.

I think the problem here is that a project manager must know PMBOK-style project management methods like PRINCE2 and agile methods such as Scrum very well to be able to choose the right techniques for the right situation. This obviously demands a lot of skill and experience from the project manager and is potentially very difficult for anyone new to either method. This is where experienced project managers that have successfully transitioned to agile have a really strong advantage over others who have only really managed projects with one approach or the other. It gives them the ability to blend the methods based on the unique characteristics of their particular situation, which along with leadership skills might be the thing that differentiates a good project manager from a great one.

I have blogged about this topic before here: Agile Project Management Is Not Enough!

5. Can you recommend a book, blog, podcast, Web site, or other information source to our readers that you find interesting or intriguing right now?

First and foremost, I would obviously recommend you read each and every page of my blog! :) (Agile Software Development Made Easy!). As if that’s not enough, I can also recommend various others, which you’ll find in my blogroll in the sidebar. My personal favourites at the moment are Leading Agile by Mike Cottmeyer, Succeeding with Agile by Mike Cohn, and Agile Techniques on InfoQ. In terms of books, you’ll also find some books I can recommend on my blog; they’re on an Amazon affiliate widget in the middle of each page. Agile Project Management with Scrum by Ken Schwaber and Agile Estimating and Planning by Mike Cohn are particularly recommended.

Kelly.

Photo by Marco Bellucci