One of the key principles of agile development, and particularly Scrum, is the concept of "One Team".

The Scrum team should include all key roles for the product, wherever they report to, including Product Owner, Product Manager, Test Analyst, Developers, Business Analysts, and any others that might be appropriate such as SEO, Creative, User Research, etc.

This is important for all roles, but especially for Testers, as they need to be aware of the original requirements, and any changes to them, or they can't really do their job effectively. Or certainly not to the level a professional tester expects of themselves, anyway.

For agile to work effectively for professional testers, Test Analysts need to be included in Sprint Planning, or Pre-Planning, wherever the requirements are discussed. And they need to be informed, either at Scrums or as they happen, about any clarifications or changes to the requirements.

Increasingly, with the use of User Stories, test cases will be defined up-front as part of the requirements gathering, and written on the back of the story card. This means that the traditional Tester role is starting to converge with the Analyst role, putting much greater emphasis on the Analyst part of many tester's job titles: Test Analyst.

Using an agile approach, collaboration between team members becomes a key principle. Without a full product specification, agile requirements are barely sufficient and collaboration is key.

It is imperative, therefore, that all Scrum team members - and especially Test Analysts - are included in all key aspects of your regular Scrum process. Irrespective of line management boundaries, which may well be different, it's imperative that the Scrum team is acting as one.

read more

In agile development, it's easy to develop bad habits!

Or to have trouble kicking them.

A blog post from Chris Stirling quotes some good examples...

• Daily stand-ups not every day
• Mini waterfalls in iterations
• Pressing too hard for increased productivity
• Team Leaders taking over team responsibilities

I've certainly seen all of these bad habits in action. In fact I've done them all myself!

In Chris's blog post, "emergent misbehaviour", he outlines some of the reasons people might fall into these habits, and the implications and pitfalls in doing so. Unfortunately he doesn't offer much advice for avoiding them though. I guess it's just a case of understanding why these practices are bad, and having good discipline.

See also:
3 New Year's Resolutions for agile team members

read more

Scrum, and other agile development methodologies, provide a framework for managing software development projects.

But all too often, methodologies focus on a project environment, where the team is focused predominantly on a shared goal. Where the team is largely dedicated to the project.

In reality, this is often not the case.

In reality, development teams are frequently required to develop and support multiple products. Multiple products with multiple product owners. And particularly in 'business as usual' ongoing development.

So how do you share an agile development team?

Operating as a resource pool is often not ideal. Everyone throws their requests over the wall. Those that shout loudest get the team's attention. Or maybe the bigger products get the team's attention, at the expense of smaller products that never get to the top of the list, and never will.

Splitting the team by product sounds great. But sometimes the team's too small for this approach to be practical. Or it leaves too many individal developers, causing problems with cover and you can't exactly collaborate with one developer per product!

So what can you do?

We have a similar situation in lots of our teams. Broadly speaking we are solving it like this:

• There is one Product Owner per product. The Product Owner maintains a separate Product Backlog for each product.
  
• 
  
• The development team acts as one team.
  
• 
  
• The Sprint Budget (number of man-hours available for a Sprint/iteration) is allocated to each product based on our recharges, e.g. 60%-20%-20%. If you don't recharge, you could agree this at a more senior level as a general rule of thumb. Each product has a known % of the budget for each Sprint.
  
• 
  
• Use Cases/User Stories/features are broken down into Tasks and estimated by the development team during Sprint Planning.
  
• 
  
• Each Product Owner can only include Tasks from their Product Backlog up to their allocated % of the Sprint Budget.
  

This approach means the development team can act as one team. There is knowledge sharing and cover when someone is off, because in this case the overall Sprint Budget is reduced but everyone still gets their usual % share of the available hours.

It also means team members don't have to juggle their time between products on a 0.x FTE basis, which is awkward at best and just plain impossible when the fractions are too small or odd numbers.

Instead the Tasks allocated in the Sprint are already appropriate to the Sprint Budget per product, meaning team members can focus on delivering the Tasks in the Sprint, not worrying about how to split their time.

See also:
10 Key Principles of Agile Software Development
10 Good Reasons to do Agile Development
Top 10 Agile Development web sites

read more

Many people find analogies a useful way to characterise new concepts, either to explain them or to remember them. This one's straight from the top drawer! :-)

read more

Agile development relies on close cooperation and collaboration between all team members and stakeholders.

Agile development principles include keeping requirements and documentation lightweight, and acknowledging that change is a normal and acceptable reality in software development.

This makes close collaboration particularly important to clarify requirements just-in-time and to keep all team members (including the product owner) 'on the same page' throughout the development.

You certainly can't do away with a big spec up-front *and* not have close collaboration. You need one of them that's for sure. And for so many situations the latter can be more effective and is so much more rewarding for all involved!

In situations where there is or has been tension between the development team and business people, bringing everyone close in an agile development approach is akin to a boxer keeping close to his opponent, so he can't throw the big punch! :-)

But unlike boxing, the project/product team is working towards a shared goal, creating better teamwork, fostering team spirit, and building stronger, more cooperative relationships.

There are many reasons to consider the adoption of agile development, and in the near future I'm going to outline "10 good reasons to go agile" and explain some of the key business benefits of an agile approach.

If business engagement is an issue for you, that's one good reason to go agile you shouldn't ignore.

See also:
10 Key Principles of Agile Software Development
Active user involvement is imperative
Agile requirements are barely sufficient

For further discussion on this or any other agile development topic, go to the 'all about agile' forum at http://www.groups.google.com/group/allaboutagile

For more agile principles, see below...

read more

In agile development, testing is integrated throughout the lifecycle; testing the software continuously throughout its development.

Agile development does not have a separate test phase as such. Developers are much more heavily engaged in testing, writing automated repeatable unit tests to validate their code.

Apart from being geared towards better quality software, this is also important to support the principle of small, iterative, incremental releases.

With automated repeatable unit tests, testing can be done as part of the build, ensuring that all features are working correctly each time the build is produced. And builds should be regular, at least daily, so integration is done as you go too.

The purpose of these principles is to keep the software in releasable condition throughout the development, so it can be shipped whenever it's appropriate.

The XP (eXtreme Programming) agile methodology goes further still. XP recommends test driven development, writing tests before writing the software.

But testing shouldn't only be done by developers throughout the development. There is still a very important role for professional testers, as we all know "developers can't test for toffee!" :-)

The role of a tester can change considerably in agile development, into a role more akin to quality assurance than purely testing. There are considerable advantages having testers involved from the outset.

This is compounded further by the lightweight approach to requirements in agile development, and the emphasis on conversation and collaboration to clarify requirements more than the traditional approach of specifications and documentation.

Although requirements can be clarified in some detail in agile development (as long as they are done just-in-time and not all up-front), it is quite possible for this to result in some ambiguity and/or some cases where not all team members have the same understanding of the requirements.

So what does this mean for an agile tester? A common concern from testers moving to an agile development approach - particularly from those moving from a much more formal environment - is that they don't know precisely what they're testing for. They don't have a detailed spec to test against, so how can they possibly test it?

Even in a more traditional development environment, I always argued that testers could test that software meets a spec, and yet the product could still be poor quality, maybe because the requirement was poorly specified or because it was clearly written but just not a very good idea in the first place! A spec does not necessarily make the product good!

In agile development, there's a belief that sometimes - maybe even often - these things are only really evident when the software can be seen running. By delivering small incremental releases and by measuring progress only by working software, the acid test is seeing the software and only then can you really judge for sure whether or not it's good quality.

Agile testing therefore calls for more judgement from a tester, the application of more expertise about what's good and what's not, the ability to be more flexible and having the confidence to work more from your own knowledge of what good looks like. It's certainly not just a case of following a test script, making sure the software does what it says in the spec.

And for these reasons, agile testing is not for dummies!


For further discussion on this or other agile topics, go to the 'all about agile' forum at http://groups.google.com/group/allaboutagile.

For further reading about agile development principles, see below...

read more

In the more traditional world of managing software development projects, it is widely acknowledged that developers can’t test for toffee!

Yet Agile Development methods increasingly seem to require or imply that all people in the project team should test, including developers.

So, first of all, why is it that developers can’t test? Are we to believe that these highly intelligent individuals somehow don’t have what it takes to test? Of course not.

The trouble is simply this: Good developers build their code to handle every scenario they can think of. If they’re really good developers, they write automated unit tests to test everything they’ve built. And if they’re really good developers, they even do this up-front so everything is designed and built to pass first time.

But still it’s not enough.

For developers only build (and therefore test) everything they can think of. And testers, partly due to their nature and partly due to the fact they’re not buried in the detail of implementing the code, are able to think up scenarios that the developer didn’t think of. And that’s the problem.

So what do we do in Agile Development, where everyone is expected to test?

My answer is this:

Wherever possible, do include at least one dedicated tester within the Agile Development team. If the tester is not able to test everything personally because there are more developers than the tester can handle, have the tester take a special QA role, including the following activities:

• Identify the test strategy and test scenarios
• 
  
• Ensure the appropriate test environments are in place and controlled
• 
  
• Write the test cases/scripts – ideally up-front but on a just-in-time basis per feature
• 
  
• Review the developers’ automated unit tests, to avoid re-testing the same things later and to QA the scope of the tests
• 
  
• Execute some of the most important test scripts personally, particularly where there is higher complexity or risk, less clarity or where more attention to detail is required
• 
  
• Coordinate the test efforts of others (including developers), so one person knows what scripts have been executed, what areas have been tested, their status at any time, and the issues logged against them
• 
  
• Manage the bug log to ensure issues are logged clearly and prioritised consistently
• 
  
• Liaise with customers and/or business users to organise acceptance testing and advise on approach
• 
  
• Ensure that each developer's code is also tested by someone else, even if it's another developer

In my experience, there is real business value in having tester expertise for this quality management / quality assurance role, even in a situation where there aren’t enough testers to go round. In an Agile Development environment, the emphasis of a tester’s role is more on QA than it is on testing per se.

See also:
Why Agile Testers should be in at the start
10 Key Principles of Agile Development

read more

In my experience, some people implement agile principles within the development team itself, but leave other key roles (for instance business users or testers) out of, or on the fringes, of the agile team.

Earlier in my blog I wrote that active user involvement is imperative in agile development for a wide variety of reasons. It's just as important for the agile team to include all roles required to ensure that each feature is actually complete, that is complete, at the end of each iteration or Sprint.

In particular it's a good idea to include Testers from the outset, and especially in planning, because:

read more

What do you do if someone in your Agile Development team is simply not playing ball? Particularly if their behaviour is counter-productive to the key principles of Agile Development and is affecting the team's performance.

One comment I’ve heard (not at my organisation by the way) was to apply the self-organised nature of Scrum and allow the team to raise the issues with the person directly and use peer pressure to make them feel uncomfortable in the hope they might leave. Admittedly in this case the person’s behaviour sounded particularly bad, but in any event this is not a good approach.

I’ve managed software development teams for many years (in the UK) and am currently responsible for a web development group of about 90 people. I think I’ve experienced every HR/management procedure in the book and keep promising to write a book about some of the more extreme examples (that are entertaining stories in hindsight but certainly weren’t at the time!).

To be honest, I found the idea of the team raising the issues as a group in the hope you wouldn’t need to fire him (presumably meaning he might jump) quite alarming.

Firstly, in UK employment law he’d potentially have a case for constructive dismissal if he knows his rights or gets good advice, and that carries quite a stiff penalty. Secondly there’s the issue of it not being appropriate to bully colleagues into leaving, even if they're a complete pain in the backside!

I recently wrote a short blog post about an amazing statistic I heard; one consultancy firm suggesting you could lose 25% of your developers when moving to Agile Development.

The reality is that not everyone in your team will agree with the philosophies of agile development and some find it practically very difficult to adopt to the very dynamic nature of the process and the lack of clarity and certainty it can bring.

In my experience there’s only one way to deal with someone behaving badly in an Agile Development team (in fact in any team):

• Any discussions must be 1:1 – air dirty laundry in private not in public
• 
  
• Explain that the person appears to be finding the Agile Development approach difficult or appears not to be on board
• 
  
• Outline why you think that’s the case, using constructive examples of how his behaviour is affecting his performance and the performance of the team
• 
  
• Tell him what good looks like; in the above examples, how could he have responded and what might the effect have been then
• 
  
• Try to understand why they’re behaving as they are; do they disagree with the principles, are they uncomfortable with the process, do they find group working difficult for some reason, or is something else bothering them? Remember bad behaviour is a symptom of something else
• 
  
• Adopt a supportive and understanding stance; don’t use personal or aggressive language; use non-emotive words such as “I feel”, “it’s perceived”
• 
  
• See if there is anything you or anyone else can do to help or support them better
• 
  
• If it’s a case of feeling uncomfortable with the principles and process, would training help
• 
  
• If not, perhaps regular 1:1 coaching sessions where you can discuss the day’s events and reflect on the situation outside of the main group
• 
  
• Remember he can’t control his capability but he can control his conduct. In the latter respect, insist that he does
• 
  
• It doesn’t matter how small, and however bad everything else is, catch him doing something right and praise him in public (be careful not to patronise, it must be sincere!)
• 
  
• If none of this works, consider whether there’s an alternative role that might suit him better – remember agile is not for everyone and some excellent people don’t get on with it. Remember the bad behaviours are a symptom not the cause
• 
  
• When you’ve exhausted all other possibilities and if the conduct issues persist, if you really are 100% committed to the agile approach, you may in the end have to resort to disciplinary action potentially leading to dismissal
• 
  
• If you have to take this path, make sure you consult your HR department and follow the appropriate process for your company and location

Finally, and just to reiterate, personally I love the agile development philosophy, but it’s not for everyone and not everyone can adapt easily to the change. Your first goal must be to change people's behaviour through education and training, followed by some open 1:1 discussions with those reacting badly to the change or finding it difficult. First and foremost, try positive support and encouragement, even when it feels like it's going against the grain.

10 Key Principles of Agile Development

read more

In my experience, most developers are over-optimistic and tend to under-estimate. However it's not uncommon for some teams to estimate on the cautious side. If you find yourself in this situation and finishing the Sprint (or timebox) early, include a couple of nice-to-have "stretch tasks" (or features/stories) in future Sprints.

read more

An Agile Development project team must include all the necessary team members to make decisions, and make them on a timely basis.

Active user involvement is one of the key principles to enable this, so the user or user representative from the business must be closely involved on a daily basis.

The project team must be empowered to make decisions in order to ensure that it is their responsibility to deliver the product and that they have complete ownership. Any interference with the project team is disruptive and reduces their motivation to deliver.

The team must establish and clarify the requirements together, prioritise them together, agree to the tasks required to deliver them together, and estimate the effort involved together.

It may seem expedient to skip this level of team involvement at the beginning. It’s tempting to get a subset of the team to do this (maybe just the product owner and analyst), because it’s much more efficient. Somehow we’ve all been trained over the years that we must be 100% efficient (or more!) and having the whole team involved in these kick-off steps seems a very expensive way to do things.

However this is a key principle for me. It ensures the buy-in and commitment from the entire project team from the outset; something that later pays dividends. When challenges arise throughout the project, the team feels a real sense of ownership. And then it's doesn't seem so expensive.

See also:
10 Key Principles of Agile Development

read more

In my book, active user involvement is the first principle of Agile Development.

It's not always possible to have users directly involved in development projects, particularly if the Agile Development project is to build a product where the real end users will be external customers or consumers.

In this event it is imperative to have a senior and experienced user representative involved throughout.

Not convinced? Here's 16 reasons why!

• Requirements are clearly communicated and understood (at a high level) at the outset
• 
  
• Requirements are prioritised appropriately based on the needs of the user and market
• 
  
• Requirements can be clarified on a daily basis with the entire project team, rather than resorting to lengthy documents that aren't read or are misunderstood
• 
  
• Emerging requirements can be factored into the development schedule as appropriate with the impact and trade-off decisions clearly understood
• 
  
• The right product is delivered
• 
  
• As iterations of the product are delivered, that the product meets user expectations
• 
  
• The product is more intuitive and easy to use
• 
  
• The user/business is seen to be interested in the development on a daily basis
  
• The user/business sees the commitment of the team
• 
  
• Developers are accountable, sharing progress openly with the user/business every day
• 
  
• There is complete transparency as there is nothing to hide
• 
  
• The user/business shares responsibility for issues arising in development; it’s not a customer-supplier relationship but a joint team effort
• 
  
• Timely decisions can be made, about features, priorities, issues, and when the product is ready
• 
  
• Responsibility is shared; the team is responsible together for delivery of the product
• 
  
• Individuals are accountable, reporting for themselves in daily updates that involve the user/business
• 
  
• When the going gets tough, the whole team - business and technical - work together!

See also:
10 Key Principles of Agile Development

read more

I attended a very interesting web meeting today about SOA (Service Oriented Architecture) and Agile Development with the Burton Group - a consultancy specialising in Enterprise Architecture.

They explained all the advantages of SOA and Agile Development and why they are such cool things to be doing. I asked what the main pitfalls were in their experience and I heard a very interesting comment.

They said that changing Developers' mindset for Agile Development was one of the hardest things to do and a challenge that is often under-estimated. I've certainly seen this challenge first hand, but was very surprised to hear their view.

In their experience, they say you can expect to lose anything up to 25% of your Developers in moving to Agile Development; as it's just not an approach that suits everyone.

I must admit my experience is rather different. Whilst I have found educating Developers and Team Leaders (and Business people) to adapt to a different mindset takes time, actually most seem to embrace the concepts and are excited by the approach.

By contrast, I have found most tension comes with Project Managers, as it's fundamentally different to the methodology they're used to (invariably based on PRINCE2/Waterfall), and even more so Testers who like to have a lot more clarity about what they're testing than Agile Development usually provides.

10 Key Principles of Agile Development

read more