I thought I would begin with an agile foreword:

1. Buy this book.

2. Read it.

3. Follow the advice in it.

4. Recommend it to your colleagues.

5. Repeat steps 2 through 4 as appropriate.

6. If it’s a print copy, store it on your shelf to show to everyone how smart you must be.

And now for a more traditional foreword .

Analysis is so important for agile teams that we do it every single day. Every. Single. Day. The implication is that we need one or more people on the team who has analysis skills; the more people the better in my opinion. Agile analysis skills are critical in the agile world.

But do agile teams need people who are just analysts? Sometimes yes, but very often no. In most situations, agile teams need people who are generalising specialists, people with strengths in one or more specialities (such as agile analysis); a broad understanding of the software process and the domain they’re working in; and the willingness to learn new skills and share their own with others. This is a different staffing strategy from that which is typical of organisations still taking a traditional approach to IT.

This begs the question of when do we need people who are specialised in agile analysis? The answer is ‘at scale’. When a team faces a complex domain, it is common to see one or more people who focus on exploring, understanding and then communicating the inherent complexities to the rest of the team. In other words, an agile analyst. Similarly, when a team has geographically distributed stakeholders, then having analysts at the various locations makes a lot of sense. When a large agile team, or agile programme, is organised into a collection of smaller subteams it is common to put analysts on the team who work closely with the programme’s product owner to communicate the requirements to their subteams. These analysts working on geographically distributed and/or large teams are referred to as ‘junior product owners’ in some organisations or business analysts in others. The point, contrary to what you may have heard, is that some teams need agile analysts.

I’m the guy behind the agile modeling (AM) method (see AgileModeling.com), which was the first serious look at how modelling and documentation activities fit in on agile teams. I led a group of people, several hundred from around the world, to develop the initial version of AM in the 2001/2002 time frame. It’s evolved since then of course, capturing collaborative lightweight strategies for analysis, architecture, design and even documentation activities for agile teams. Needless to say I’m excited that this book has been written.

What should you hope to gain from reading this book? Here are my suggestions for what you want to learn:

1. Discover the agile mindset: whenever you think, ‘that won’t work for me because I’m in a different situation’, the best thing to do is to assume that you’re completely and utterly wrong about that (you very likely will be) and therefore need to work things through. Being agile, having the mindset to collaboratively work in an agile manner, can take a long time to truly learn.

2. Keep analysis light yet sufficient: when it comes to ‘doing agile’ the biggest change is often the focus on keeping your work and the artefacts that you create as light as possible. In agile modelling, we promote strategies such as working with the audience of an artefact to learn what they really need, preferring direct communication with others as opposed to documentation hand-offs, and capturing requirements in the form of executable tests.

3. Focus on working collaboratively with others: modelling is something you should do with others, ideally using inclusive tools such as whiteboards and sticky notes. Many heads are better than one.

4. Embrace an evolutionary approach to analysis: as I said earlier, analysis is so important that we do it every single day on an agile team. This is because of the agile philosophy of embracing change – we accept the fact that our stakeholders' requirements will evolve over time, necessitating an ongoing and evolutionary approach to analysis (and architecture, and design and all other aspects of solution delivery).

5. Seek active stakeholder participation: one of the more radical ideas in agile modelling, one that we adopted from usage-centred design, is that the people who are best suited to perform requirements-oriented modelling are your stakeholders. If we can find ways to get our stakeholders actively involved in our modelling efforts, something that inclusive tools (whiteboards, paper) and inclusive techniques (such as the simple model types described in this book) enable, then we are much more likely to find out what our stakeholders actually need.

6. Continuously improve: part of the agile mindset is to regularly reflect on what is working well, and what isn’t working so well, so that we can potentially learn from and address the challenges we face. Similarly, the Lean mindset tells us to experiment with potential improvements, study their effectiveness, and then adopt new ways of working accordingly. We can always get better.

7. Constantly expand your intellectual toolkit: there are some great modelling techniques described in this book, including many common ones such as user stories, epics and personas. These techniques are of course the tip of the iceberg – there are hundreds of strategies out there that you should experiment with and learn when (and when not) to apply them in practice. The more techniques you have in your intellectual toolkit, the greater the chance you’ll choose the right one for the situation you face.

8. Be enterprise aware: one of the hallmarks of working in a disciplined agile manner is to recognise that your team is only one of many within your organisation. You need to work with other teams to accomplish your goals; few agile teams are rarely whole, regardless of the rhetoric you may have heard, and that’s OK. Furthermore, your team should strive to do what’s right for your organisation, not just what is convenient for you. All teams should work towards a common vision, should follow common conventions and should strive to work together effectively.

I believe that this book captures critical ideas and skills for anyone wanting to improve their agile analysis skills. This is critical for all agile team members, but is particularly important for anyone in the role of product owner or agile analyst. Your investment in reading this book will be time well spent. Enjoy!

Scott Ambler

Author of Agile modeling

Co-author of Disciplined Agile delivery

November 2016