Agile Software Development Made Easy!

Agile Software Development Teams Need Managers Too!

2009-11-18T16:00:00.000Z

Mike Cottmeyer recently wrote an interesting article about whether or not managers can lead agile teams?

Organisations do need managers, for a wide variety of reasons. And let's face it, the roles of Product Owner and Scrum Master are management roles.

They may not be management roles in the traditional sense, but management roles they are.

The Product Owner is there to manage stakeholders, manage incoming requests and prioritise work for the team. This is management.

The Scrum Master is there to deal with any issues that are impeding the team's progress, facilitate communication, orchestrate the process, etc. This is also management.

What Scrum has effectively done is to split the traditional management role into two, one with a focus on aligning the team's activities with the goals of the business; the other with a focus on the internal organisation of the team.

The aspects of management these roles don't explicitly address are duties relating to line management, for example:

Reporting up the line
Setting budgets and managing finances
Managing the performance of individuals in the team
Developing people's careers
Ensuring compliance with important company policies or regulations
Setting out a clear vision and strategy for the future
Understanding the wider organisational context and identifying opportunities and constraints
'Selling' the team's achievements and goals within the wider organisation
Raising funds for projects
Signing off and managing holidays, sickness, expenses, invoices, etc - i.e. the administrative side of management
Deciding on the most appropriate organisational structure
Hiring and firing

And I'm sure there are many others!

So I guess one possibility is that the traditional management role was always too big for some people. To fulfil all of these responsibilities, and those of the Scrum Master, and those of the Product Owner, and by the way to be the assigned leader. Management, done right, is a big deal and it's why anyone who has tried it knows it's not easy.

Scrum alleviates this challenge by splitting the management role, spreading the responsibilities and making the challenge of management more achievable.

The Product Owner can worry about what we should be doing. The Scrum Master can worry about the internal process and making sure issues are being addressed. And line managers can worry about all the other stuff!

Having said that, a key principle of agile methods is that agile teams must be empowered.

Agile methods advocate the idea of self-organising teams. In a way that's quite funny, because the responsibilities of the Scrum Master and Product Owner mean that in many ways Scrum teams are far from self-organising!

Nevertheless, the idea is that whilst the process may be somewhat prescribed by Scrum and managed by the Scrum Master, the team will make most decisions about how things should be done for themselves, and will pick their tasks rather than having them allocated by a manager. In any case, self-organisation is not boundaryless!

Regardless of all this, like any other teams, agile teams still need leadership. Leadership sometimes comes from one of these management roles, as managers often end up as managers because they have some level of leadership skills. Sadly, sometimes they don't! Other times leadership comes from within the team, which is equally good and in my opinion should be encouraged.

Leaders can be appointed (e.g. line managers, Scrum Master, Product Owner), or they can be emergent leaders that emerge naturally because of their skills, expertise or personality, rather than because they've been formally assigned a leadership role.

Wherever it comes from, leadership is probably the difference between good teams and great teams! Inspirational leadership can transform a team's energy, and therefore their ability to overcome obstacles, strive for bigger goals, and bond as a team. Here are 20 qualities of an inspirational leader that ideally ought to be present in every team...

Kelly.

Photo by Scarleth White

Agile Software Development Made Easy! Shortlisted in Computer Weekly Blog Awards

2009-11-16T12:03:00.006Z

I'm delighted that Agile Software Development Made Easy! has been shortlisted again in this year's Computer Weekly blog awards.

Computer Weekly is one of the original trade magazines for IT professionals, so it's quite an honour to be highlighted by such an important brand.

There are some other really good blogs in the shortlist too! Click here to see the shortlisted blogs in the Project Management category.

The results will be announced on 25th November, so if you like my blog, vote now!

Kelly.

Photo by eecue

Agile Project Management: Avoiding The Waterfall

2009-11-12T09:03:00.007Z

This is a guest blog post by Richard Revis from The Plan Is...

"Agile project management can be hard to implement successfully because even once you have good practices in place the way projects are run can revert to the old methodology quickly. I would like to share three reasons that I have come across for the reappearance of waterfall project management in an organisation and look at some ways to address this.

The first reason is the sponsor's view of how a project should operate. A client, internal or external, probably has a mental model in his head of how things will happen when commissioning a project.

The project is briefed to the project team.
The project team does the work.
The sponsor checks the work has been done correctly.

One thing we can notice about this progression is that it looks suspiciously like the key steps from the waterfall process:

Requirements
Design and implementation
Verification

If this is how your sponsor views the world there will be a strong tendency for it to creep into the way the project is managed.

Secondly the business environment can add to the pressure to do single iterations. Most projects occur in an environment with severe constraints. A typical project starts now and ends when the money, or attention, or time runs out. I have worked on several projects where this end date was defined by the last day we could deliver something to avoid being sued.

This kind of time constraint will lead your project sponsor even more towards thinking about their project in a waterfall style as the important requirement (don't get sued) is very clear. The consequence of such a precise requirement is the belief that it must be possible to work out how to achieve that result and then do it right the first time.

Finally, interaction with the rest of the programme can contribute. Generally your project sponsor will be thinking about more than one strand of work at a time. The part which is handed over to you will be going on in parallel with the work that is being done in marketing or operations or by another team. This naturally will reinforce the tendency to plan in a waterfall style, where each strand is completed and then brought together for iteration.

So how can a project team address this kind of imbalance between the process they wish to operate and the natural inclination of their sponsor or client?

The fact that there will be an underlying waterfall project plan, at least in the mind of your project sponsor, doesn't mean that you have to throw away your agile practices.

You probably can't get rid of the waterfall thinking entirely. The constraints and thinking I have mentioned will generally already be set by the time you get involved. However by moving the plan they have in mind up to a high enough level it is still possible for you to implement agile practices underneath.

For the element of the larger project you are working within you can try to pulling your stakeholder in early, delivering small iterations, and changing the specification to closer match the real requirements as you go along.

You will still be aiming to deliver what they want, within the time scales they ask for, just organising it in a slightly different way than they probably expected.

However in order to get this flexibility it is necessary to ensure that project milestones in your sponsors plan are high level and flexible. For example good milestones I have seen are achieve 80% rating on customer feedback, deliver £5,000/day revenue and launch a good product.

Milestones like this offer enough flexibility that another process can iterate underneath working out what the actual definition of 'a good product' is and how to best build it.

In summary, if you identify the hidden waterfall project that is going on and work out how to influence it appropriately it won't necessarily harm your project. In fact knowing about these implicit constraints and deadlines can help you deliver a better result."

About the Author:
Richard Revis has run technology development projects involving everything from iPhones up to front line fighter jets. He is currently Project Director at The Plan Is where he is developing web applications that make it easier to plan fixed duration projects. He writes regularly on project management and start ups at theplanis.com/blog.

eBook - Agile Software Development Made Easy!

2009-10-30T13:00:00.002Z

Many thanks to everyone who has bought my ebook - Agile Software Development Made Easy! so far.

It's gone fairly well and that gives me all the extra encouragement I need to finish my paper book! It probably won't be ready until next year some time, but my intention is to produce a product that allows you to take away all the best content from this blog and read at your convenience.

Thanks again to all those who've bought the ebook in the meantime. That really is much appreciated!

Kelly.

Lean and Scrum - Chicken and Egg

2009-10-29T16:00:00.001Z

Here is a really interesting post from John Scumniotales, one of the inventors of Scrum. Here he sets the record straight about whether or not Scrum was based on the concepts of Lean manufacturing, as pioneered by the likes of Toyota and Honda...

Lean and Scrum - Chicken and Egg

Whilst this is clearly admirable for the inventors of Scrum, they clearly share some similar principles and philosophies.

But in some ways I was disappointed to hear this. The idea that Scrum was based on the widely celebrated principles of Lean manufacturing really added some credibility to Scrum and other agile/lean methodologies.

To think that John and others stumbled across it whilst working in their cubicle is a bit disappointing really! I would have liked to think it was based on years of research :-)

Kelly.

Photo by Mikyl Roventine

Which Agile Methodology: Scrum, XP, Either, Both or Neither?

2009-10-28T16:00:00.001Z

Here is an interesting article on InfoQ about the debate over agile methodologies, and which is best: Scrum, XP, either, both or neither?

Personally I think they are entirely complimentary as they cover different aspects of software development. I find it useful to think of Scrum as an agile management methodology, whilst eXtreme Programming (XP) focuses more on agile engineering.

In an earlier post, I explain my views on this in a bit more detail; see here...
eXtreme Programming versus Scrum.

What do *you* think?

Kelly.

Photo by Mike Cogh

Agile Software Development Made Easy!

2009-10-27T20:38:00.002Z

Hi all. I'm very grateful that so many blogs and web sites link to this blog. Many, of course, still link with the old name, 'All About Agile', as the link text. If that's you, would you mind updating the link text to 'Agile Software Development Made Easy!' so it reflects the new name?

Many thanks in advance!

Kelly.

Certified Scrum Master Exam

2009-10-26T16:00:00.003Z

I've blogged before about Certified Scrum Master (CSM) status, and how I think Scrum Master Certification isn't worth the paper it's written on!

I'm not against CSM training. In fact I'd heartily recommend it to anyone. The Certified Scrum Trainer process is pretty rigourous, ensuring the quality of the trainers.

It's the terms 'Certified' and 'Master' I have a problem with, when all that's required to be labelled as a Certified Scrum Master is attendance on a 2 day course.

However, I'm really pleased to say that the Scrum Alliance has taken the first step towards putting that problem right, with the announcement of a Certified Scrum Master exam being introduced from 1st October 2009.

Credit to Scrum Alliance for listening and acting on feedback from the agile community. It's definitely a step in the right direction...

Kelly.

Photo by superia85

Agile Self-Assessment Tool

2009-10-19T16:00:00.002Z

Quite a while ago now, I published this 42-point questionnaire to help you assess how agile you are.

Now even ThoughtWorks are at it...

ThoughtWorks Studios is a global leader in agile tools and training. Today they announced the launch of a new web-based tool for gauging the status of a software development team’s agile adoption and potential roadblocks to the successful delivery of business-aligned programmes.

The complimentary self-assessment tool consists of 20 questions that cover both management and engineering practices, and provides a customized report with high-level analysis and potential areas for improvement.

Why not give it a try? www.AgileAssessments.com

Kelly.

Photo by okimi

Agile Methodology

2009-10-12T16:00:00.007Z

I recently ran a poll on which agile project management software you would recommend. It got a terrific response and the results are really interesting!

While you're in the mood for polls, I thought I'd run another one.

This time I'm asking which agile methodology do you use?

Which Agile Methodology Do You Use?(online surveys)

Thanks in advance for your response!

Kelly.

Photo by brianemitchell

Agile Scrum

2009-10-06T08:51:00.007Z

Over the last couple of years, I've written quite a lot about Scrum.

It's certainly my agile methodology of choice.

I love the fact it's so easy to apply, straight over the top of whatever technical or engineering practices you already use.

Here's a quick round-up of some of my most popular posts about Scrum...

How To Implement Scrum in 10 Easy Steps!
Video Introduction to Scrum
Why General Agile Is Not Enough - Why Scrum Wins
Scrum Hell
ScrumMaster Can Be A Blocker
Certified ScrumMaster Isn't Worth The Paper It's Written On!
eXtreme Programming Versus Scrum
Scrumaholics Anonymous
Example Product Backlog and Sprint Backlog
Using Scrum on Larger Projects: "Scrum of Scrums"
Implementing Scrum - PowerPoint Presentation

I hope you like my selection...

Kelly.

Photo by MartyDev

The Problem With Planning

2009-10-05T16:00:00.001Z

I think I've been pretty successful in my career. But if I was better at planning, I wouldn't have achieved half the things I've achieved in my career! In fact, I wouldn't even have started some of them...

In reality, there are some things you can plan, and some things you can't. The trouble is, in most organisations we've come to expect a plan. And to meet it whatever happens. And that's just not realistic.

Doing detailed planning pre-supposes you know where you want to go and aren't going to be influenced too much by what happens in the meantime - or at least not without a substantial amount of re-planning. This, at least in my experience, has a tendency to give project managers tunnel vision at times.

Now don't get me wrong - I'm not suggesting for one moment you embark on a project that doesn't have a clear and robust vision. And I'm not suggesting for a moment you embark on a project where you have no idea how to achieve it and whether it's a reasonable (although hopefully challenging) goal with the available resources. And forming that into an outline plan to provide some markers to aim for is certainly a good idea, but ideally it's a high level roadmap rather than a detailed plan.

Coming from a traditional software development environment, I realise this sounds slightly mad. And I must admit it takes a certain amount of maturity and experience to recognise that you can't really plan in detail up-front if you want to retain any flexibility, as the real requirements, risks, issues, priorities and opportunities all tend to emerge when you start to build and see the software in action.

Most organisations are not ready to accept such a radical idea - the idea of acknowledging you don't really know what you want - certainly not for sure - and you don't really know what you're going to get for your money, or when. So, as a minimum, a clear vision and outline plan are essential, but be careful to keep them to a high level.

Rather than a detailed plan, I prefer to see a strong vision, a strategy, goals, and a roadmap (high level outline plan). The tactics to achieve this, for example the precise features and all the tasks to deliver them, can vary along the way and are best not articulated up-front. This enables the team to discover the details when they are in a better position to do so, and allows them to change direction rapidly in response to changing circumstances.

This, when you think of it, is the very meaning of agile...

Kelly.

Photo by tanakawho
First published on agilesoftwaredevelopment.com

Recommended Agile Project Management Software

2009-09-29T08:26:00.011Z

I'm curious. I haven't used specialised agile project management software before. I've always relied simply on Excel and as you may know I'm a big fan of the whiteboard!

Nevertheless, I was wondering what is the most popular, or most recommended, agile project management software and thought it would be interesting to run a poll to find out!

Vote for your recommended agile project management software now using the poll below...

I've added a few tools to start off with. If the agile project management tool you'd like to recommend isn't listed, enter it in the 'Other' box. I'll keep an eye on votes for Other and add other tools into the poll as they arise.

Calling all agile bloggers and providers of agile tools! Please promote this poll. It would be great to get a comprehensive poll of the marketplace and see what tools people recommend. Make sure your software gets the votes it deserves!

Kelly.

Which Agile Project Management Software do you recommend?(survey)

Photo by Lee Creighton

Lean Software Development: Less is the New More!

2009-09-21T12:00:00.001Z

There is no doubt that 'Lean' is the new buzzword of the software development industry; certainly within the agile community anyway.

But how does it fit in with agile, and more specifically, how does it fit in with agile methods like Scrum and eXtreme Programming (XP)?

Lean software development shares many, if not all, of the key principles of agile software development.

As a result, in can potentially be seen as an instance of agile, much like Scrum is another instance and eXtreme Programming is another.

Whilst Scrum focuses on agile management practices, and eXtreme Programming focuses on agile engineering practices, Lean software development is an extension of the underlying principles and has a sharp focus on eliminating waste.

It can also be seen the other way around, that agile is an instance of Lean thinking.

It's certainly true that agile principles and methods eliminate a lot of waste, especially in comparison with previous project management methods and traditional waterfall projects. That's for sure.

And it's also true that agile - starting with the original agile manifesto - has its roots in Lean manufacturing, as pioneered by Toyota and Honda.

But Lean thinking can actually be applied to any methodology, whether it's waterfall, Scrum, eXtreme Programming, or whatever.

For example, in Scrum, is Sprint Planning waste? It's certainly very time-consuming, although I would argue it's not generally waste. There can potentially be enormous value in aligning the whole team, unifying the team on common goals, establishing a common understanding of what needs to be done, and committing as a team. On the other hand, in some circumstances, when the work is nigh-on impossible to plan and Sprints are routinely disrupted, Sprint Planning can potentially be a big waste of time.

As another example, in eXtreme Programming, is Pair Programming waste? There are some circumstances where Pair Programming is extremely valuable, for instance, when one person is learning from another, to spread knowledge about areas of the code, and to increase quality. On the other hand, if these are not particularly issues for your team, and if the tasks are relatively straightforward, it could certainly be argued that Pair Programming is waste.

It's no wonder people find this all a bit confusing! So what are you meant to make of all this?

My personal suggestion is this...

For those that like and support the underlying key principles of agile, they still apply in Lean. In fact, agile is very Lean compared to traditional waterfall projects. In this respect, Lean thinking is an extension of agile and not a replacement.

For those adopting agile development principles, it can certainly be valuable to adopt some common practices, such as Scrum or eXtreme Programming to bring some structure and process to the principles and help the team to put the principles into practice.

Increasingly it seems to be common practice to use elements of both Scrum and XP, in order to address both the management and engineering aspects of agile. Personally I like this; the two methods are very complementary as they share the same principles and address different issues.

But in adopting these practices, or any other practices for that matter, you could also benefit from Lean thinking. Think hard about your particular circumstances, and whether any of these practices are really waste in your particular situation? If they are, regardless of methodology, you should really try to eliminate them.

One word of caution though. Be sure you really understand the intrinsic value of any process before you eliminate it. Sometimes the benefits are soft and not immediately obvious. Until you really understand the principles, and have practical experience of why they work, you're in no place to adapt them... Agile Practices Are Meant To Be Adaptive, But Only When You're Ready.

Kelly.

Photo by WillShoot

55 Page eBook - Agile Software Development Made Easy!

2009-09-14T16:00:00.007Z

Over the last couple of years, I've had quite a few requests to turn this blog into a book. Finally I've made the commitment to do it, and hopefully you'll see it for sale on Amazon in a few months time...

In the meantime, I've decided to release the first couple of sections as a 55 page eBook called '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 vs Waterfall vs Iterative vs Lean Software Development - In Pictures!

2009-09-10T06:45:00.009Z

Tara Whitaker has produced an excellent diagram to depict the key difference between Waterfall, Iterative, Agile/Scrum, and Lean software development, in pictures!

Take a closer look at it and read the explanation over on her blog, agile101.net...

Kelly.

All About Agile Is No More!

2009-09-06T11:27:00.007Z

After 2.5 years of blogging about agile software development, 'All About Agile' is no more!

Today I have taken the difficult decision to rename it, to 'Agile Software Development Made Easy!'.

Who knows, this could potentially be one of the worst decisions I've ever made! And I'm sure I've made some bad ones :-) It doesn't exactly roll off the tongue! But I really feel it's an important change to help people find this site in search engines, and it's the strapline I've been using for All About Agile for quite some time now...

Note the address has not changed. But if you have a link to this site on your site or blogroll, perhaps you'd be kind enough to update the link text to show my new name.

If you don't have a link to All About Agile in your blogroll, why not add one to Agile Software Development Made Easy!

Kelly.

Agile Estimating: The Secret To Delivering On Time

2009-09-02T16:45:00.004Z

For decades, delivering on time has been the holy grail of software development.

I've been doing agile software development for quite a few years now. I've seen many benefits, but one of the most remarkable things of all, is how so many teams can quickly get good at delivering on time.

It's the art - and/or science - of predicting what can be delivered in a given timeframe, even if the same team was hopeless at estimating before!

This, for me, is one of the most compelling reasons to do agile development. Here is the secret:

Estimate features, rather than tasks.
Keep your estimates high-level intuitive guesses (don't analyse the details).
Estimate in points to indicate the relative size of each feature.
Consider estimating using a number sequence like Fibonacci. Fibonacci numbers get less precise as they get bigger, which builds a natural distribution curve into your estimates.
Estimate as a team. Consider playing Planning Poker to facilitate this.
At the end of your Sprint (or iteration), score the points for all features you managed to deliver. Only score points for features 100% complete, tested and potentially shippable. This is your Velocity. Count zero for incomplete features.
Track your Velocity over time on a graph. You can also track your Reliability, i.e. the number of points delivered as a percentage of the number of points committed to at the start of the Sprint.
At the start of each Sprint, look back at your Velocity for recent Sprints to decide how much to commit to for the coming Sprint.
Don't try to reconcile points with hours or days.
Commit as a team.

Like most great things in life, it's actually very simple. That's really the beauty of it. It seems a bit abstract, so many people might be retiscent to give it a try. I would urge you to try it.

You'll need to give it several Sprints before you pass judgement on it. You will find your Velocity bounces all over the place for the first 3-4 Sprints. But then it will settle down, as your team discovers its norm.

Trust me, it works. I have seen it work in many different teams, time and time again. It's a statistical approach to estimating. And statistically, if you estimate with relativity, everything is average in the end.

Kelly.

Originally published on agilesoftwaredevelopment.com

Agile Testing versus Waterfall Test Phases

2009-08-25T19:52:00.013Z

I have recently been asked by a tester how agile testing compares to the various test phases in more traditional, waterfall development projects.

For instance, after the code has been unit tested, are there several testing phases, such as system, integration and regression testing?

Although these layers of testing do exist in agile projects, agile testing is integrated throughout the lifecycle, with each feature being fully tested as it's developed, rather than doing most testing at the end of all the development.

Here's how traditional test phases typically fit in with an agile testing approach:

Unit testing is still completed by developers as usual, but ideally there's a much stronger emphasis on automated testing at the code/unit level.
In eXtreme Programming (XP), there is also a strong emphasis on test driven development, which is the practice of writing tests before writing code. This can start simply with tests (or 'confirmations') being identified when a 'user story' is written, and can go as far as actually writing automated unit tests before writing any code.
System testing and integration testing are rolled together. As there is at least a daily build, and ideally continuous integration, features can be tested as they are developed, in an integrated environment. As per waterfall, this stage of testing is ideally carried out by professional testers, as we all know developers can't test for toffee! Importantly, though, each feature is tested as it's developed, not at the end of the Sprint or iteration, and certainly not at the end of the project.
Towards the end of each sprint, when all features for the iteration have been completed (i.e. developed and tested in an integrated environment), there needs to be time for a short regression test before releasing the software. Regression testing should be short because automated, test driven development, with features tested continuously in an integrated environment, should not result in many surprises. Hopefully it should be more like a 'road test'.
Finally, on a very large project, where a release must practically span multiple sprints to be of any value, a 'stabilisation' sprint may be worthwhile to make sure everything is okay before release. This should, however, be a short duration and the need for a stabilisation sprint should be avoided if at all possible, by trying to deliver releasable quality in each and every sprint along the way. If it is required, this sprint should be all about reducing any defects prior to launch, and the scope of development should at that time be frozen.

That's a very quick summary of how traditional test phases fit in with an agile testing approach. In many ways it's common sense, although it's not always easy!

Kelly.

Photo by BaylorBear78

Advantages of Agile Software Development for Testers

2009-08-19T07:59:00.020Z

This is a guest blog post from Ray Claridge, who writes a really interesting blog about agile testing caled Tester Troubles.

Over to Ray...

Moving into agile software development can be a daunting experience for any tester, and crawling the Internet for crumbs of comfort does little to ease the anxiety.

I remember how I felt on my first day, going into a mammoth planning meeting and participating in a sizing session with what appeared to be poker cards. When asked why I'd held up a 5, I really didn't know what to say. Talk about a fish out of water!

Like most testers, I gained experience and qualifications over many years whilst practicing the V-Model approach to development. I'm not saying it was easy, but it was pretty straight-forward. Give me a spec, I'll review it, create a test plan, devise tests against it and months later finally test against it. Whereas in agile, there's no big spec, the software functionality evolves during development and testing is required before it's finished!

However, once I got my head around the changes I soon realised the advantages of working in an agile environment:

• Agile re-ignited my passion for testing.
• I spent less time complaining about being the last to know when there's a requirement change.
• For the first time I felt like a valued member of the team.
• Developers looked upon me as one of their own, instead of the nasty tester in the corner.
• I was being engaged and used for my creativity, skill and critical thinking.
• Tried and tested test techniques still applied.
• User stories are just like bite size specifications, only easier to digest.
• The business were more engaged with the process.
• I was more engaged with the business.
• The business was happier with the process.
• The business were ending up with software that meets their needs at that moment in time, not the software they thought they wanted 6 months ago.
• I was helping to shape the requirements.
• I lost a huge amount of negativity and became more positive, motivated and accommodating tester.
• I spent far less time sitting around waiting for code to be delivered.
• I no longer waited days, sometimes weeks for defects to be fixed.
• I felt I was adding real value.

Now I know there are some testers and managers out there who will disagree with agile and will never accept it as a development process. Some have even considered a career change to avoid it. I'm not saying agile is perfect and like all methodologies it's not without it's faults, but for me it's been a breath of fresh air.

My advice to any tester about to embark into the world of agile would be: keep an open mind, be flexible, accept the tester's role IS changing and remember, agile is here to stay. Don't fight it, embrace it!

Ray.

Ray Claridge is an experienced tester with ISEB qualifications and experience in both agile and waterfall environments, and author of the popular blog, Tester Troubles.

photo by Duncan Rawlinson
thelastminuteblog

Agile Project Management: Risk Management

2009-08-12T18:14:00.014Z

This is a guest blog post from Tara Whitaker. Tara has recently launched a new agile blog called Agile 101.

It really is amazing how much content Tara has already published on agile project management and agile programme management.

Here's a taster...

A Risk is an uncertain event that will impact your chosen path should it be realised. Risks are events that are not currently affecting you - they haven't happened yet. Once a risk is realised, it has the potential to become an Issue(s).

The following activities are more traditionally carried out by a Project Manager. In Agile working environments, the responsibility for risk management is shared by all involved.

Identify a risk

Assess a risk

Respond to a risk

Reviewing risks

The old saying 'a problem shared is a problem halved' comes to mind. In Agile Software Development environments, we accept that projects are ridden with complexity and uncertainty.

By promoting communication, distributing the responsibility of risk identification/mitigation and enabling ourselves to respond quickly to change, we are fundamentally better equipt to dealing with Risk than more traditional environments.

With that said, there don't seem to be any official guidelines on how to manage risks within an Agile environment, so I'll combine my personal views with notes and ideas I've found scattered around the web.

The articles below provide an overview of Risk Management within an Agile context and take you through the four key stages of the Agile Risk Management Lifecycle:

Agile Risk Management – Risk Identification (Step 1 of 4)

Agile Risk Management – Assessing Risks (Step 2 of 4)

Agile Risk Management – Risk Response (Step 3 of 4)

Agile Risk Management – Risk Review (Step 4 of 4)

Agile Risk Management – The difference between Risks and Issues

12 Principles of Risk Management (PMBOK - with an Agile slant)

Enjoy!

Tara.

Scum Certified Agile Master (SCAM) Training

2009-08-11T19:06:00.009Z

I've just stumbled across this genius piece of work from Scott Ambler, who recently posted here on All About Agile about agile project management and the challenges of agile project initiation.

Those who've followed my blog for a while will already know that I think Certified Scrum Master training isn't worth the paper it's written on!

Don't get me wrong. I'm a really big fan of Scrum. And I'd heartily recommend going on a Certified Scrum training course. It's just the combination of terms 'Certified' and 'Master' for attending a two day course that I don't like.

Anyway, this was an April fool's joke, so PLEASE don't take it too seriously. As I say, I love Scrum and yet I still thought it was a really witty view of the shortcomings of the certification process. Read it here - sense of humour permitting!

SCUM Certified Agile Master (SCAM)

No offense intended :-)

Kelly.

Photo by Amanda D80

Agile Project Management: Project Initiation

2009-08-10T08:12:00.010Z

I'm delighted to introduce another guest blogger on All About Agile. Scott Ambler has agreed to blog here from time to time. Scott is Chief Methodologist at IBM Rational and (co)author of 19 books!

His first post is a call for action. Scott runs various surveys in order to get feedback on key issues in agile software development. The latest is about project initiation. I know many people do not like to fill out surveys, but I encourage you to complete this one as it's important for the ongoing development of the agile 'body of knowledge'.

Over to Scott...

I’m often asked fundamental questions by people new to agile regarding how people go about getting an agile project started. What strategies do people use for estimating? What approaches to project funding do people typically use? What did you have to do to justify the project? How much modeling occurs and to what extent? How long does this typically take? Without decent answers to many of these questions some people are still reticent to experiment with agile approaches to software development.

So, to get answers to these sorts of questions Mike Vizdos and I have put together the Agile Project Initiation Survey. There are 17 questions in this survey, although you may not be asked all of them, and it should take you at most 5 minutes to complete. Thank you very much for investing your valuable time to fill it out.

To entice you to fill out the survey we'll be drawing for 10 copies of "Agile Project Management: Creating Innovative Products, 2nd Edition" by Jim Highsmith, published in July 2009 by Addison Wesley.

The results of this survey will be summarized in my "Agile by the Numbers" presentation at Agile 2009 in Chicago on August 27th. Furthermore, this is an open survey, so the source data (without identifying information to protect your privacy), a summary slide deck, and the original source questions will be posted at my IT Surveys page so that others may analyze the data for their own purposes. Data from previous surveys have been used by university students and professors for their research papers, and hopefully the same will be true of the data from this survey. The results from several other surveys are already posted there, so please feel free to take advantage of this resource.

For anyone who is reticent about filling out a survey, or who doesn’t see the value in them, you might want to read 'Surveying the Agile Community' for some arguments as to why you should consider investing your valuable time to help us out. Thanks in advance!

Click here to take the agile project initiation survey now.

- Scott.

Scott Ambler is Chief Methodologist/Agile&SOA with IBM Rational. He is the (co)-author of 19 books on software development topics ranging from very traditional to very agile approaches. In recent years his focus has been on techniques to scale agile software development, in particular how modeling, documentation, and database issues can be addressed agilely. He works with customers around the world to improve their software processes in a manner which reflects their unique situation. He is a senior contributing editor with Information Week and a keynote speaker at software conferences internationally. He also writes a blog on the IBM web site, about strategies for scaling agile software development - Agility@Scale.

photo by Metal Chris

The Million Dollar Question

2009-08-04T09:51:00.013Z

I'm delighted to introduce my first ever guest blogger on All About Agile...

Mike Cottmeyer is a product consultant and agile evangelist for Version One, and regularly blogs about various aspects of agile software development.

Here he writes about teamwork, and the importance of agile teams pulling together...

People have lots of reasons for not working together like a team. In many organizations... it is pretty common for developers and testers to only interact through the defect management system. For a long time developers and testers weren't even encouraged to talk to each other... let alone collaborate. Sometimes developers don't even get talk to a product manager... let alone a real customer. All their requirements come by way of a great big requirements document... and if they have any questions... or need any clarification... they can go talk to the BA.

Sometimes I'll meet a new agile team... one that just recently came out of this way old of working... and they are bringing many of those low bandwidth communication habits along with them. When we talk about people interacting on a daily basis... when we talk about developers and testers and customers talking to each other... when we talk about collaborating and having shared accountability... these are pretty foreign concepts. These folks come up with all kinds of reasons that a defect HAS to be written up during the sprint or that requirement change just HAS to be documented and passed through change management. It's the only way they know how to work together... and they want to know they can be individually successful... successful independent of everyone else on the team.

When I meet a team like this, I like to ask them to do a little thought exercise with me. What if I offered everyone on the team one million dollars to plan a set of features that could be delivered in two weeks. The team would work with the customer directly to understand the requirements... the team would make a shared committment... the team would deliver the work. Once the work was delivered... they'd all get one million dollars... each. No one sets the goal... they set it for themselves. But... and here is the kicker... everyone gets the million or no one gets the million.

We are all dependent on each other for a successful outcome.

Would this kind of reward change your notion of planning? Would it change your notion of working together? Would you allow process and red tape and defect management and change control stand in the way of delivery? Most people start telling me how they would generate as little documentation as possible... how QA testers would work with developers to make sure the code was right... how they would review progress with their customers frequently to get feedback. They start telling me about how much they'd talk to each other to make sure they were getting things right.

So... if we can create that sense of urgency to inflate our own personal bank accounts... what stops is from breaking down all those organziational barriers for the sake of our companies... for the sake of our recurring paycheck? At the end of the day... that's what's really at stake... our companies... and our continued employment... are depending on it.

Mike Cottmeyer is a product consultant and agile evangelist for VersionOne. Prior to joining VersionOne, Mike was a senior project manager for CheckFree Corporation where he led a portfolio of projects for their online banking and bill payment business unit. Mike has 20 years of experience leading IT initiatives using a combination of traditional, agile, and lean project management best practices.

Mike is a certified PMP Project Manager and a certified ScrumMaster. He co-created the DSDM Agile Project Leader certification and holds Foundation, Practitioner, and Examiner level certificates. Mike is an honorary member of the DSDM Consortium and a founder of the Lean Software and Systems Consortium.

Mike speaks internationally on the topic of Agile Project Management and writes for several blogs including Leading Agile and VersionOne Agile Chronicles and occasionally for AgileSoftwareDevelopment.com.

If you like my blog, please link to it

2009-07-29T06:43:00.006Z

Hi all. I've spent over 2 years now, and countless hours, blogging all about agile software development and agile project management, highlighting interesting things about agile all over the web and writing original content explaining some of the key agile principles, how to implement Scrum, user stories and lots more!

One thing I haven't really done very well, though, is promoting my blog. I promoted it quite heavily in my first couple of months of blogging, but since then I've relied heavily on word of mouth.

I've really enjoyed the feeling of helping people to understand agile and as a result have taken great satisfaction from the many 'thank you' emails and positive comments I receive, and for that reason I really want my blog to reach the widest possible audience.

I have enjoyed some great success with agile development methods - particularly Scrum - and I guess I just want to share what I've learnt so other people can benefit from agile in the same way and be successful too.

In order to expand my reach, I really need more people to link to my blog. If you like my blog, or you've found it useful in your adoption of agile, the best way to show your appreciation is to link to it :-)

Many thanks!

Kelly.