Requirements and specifications — your needs or theirs?

I’ve just finished reading a great post from world renowned Information Architect Eric Reiss on website projects and things CEOs should know. Something in particular, though, caught my eye that reminded me of requirements gathering in agile environments:

“Don’t confuse your needs with those of your visitors
You may want … to communicate your company’s values, service offerings, products, or something else entirely. But [users] will have their own agendas … the simple truth is, unless a site fulfills the needs of its visitors, it will never fulfill the needs of the site owner.“

If you’re doing agile, real agile, not just doing iterations or stand-up meetings, you’re focussing on the needs of your users and ranking them in relation to what adds value to them, not to you. This is one of the basic tenets of the Agile Manifesto and, in this way, has a lot in common with lean process practices:

• work from the customer’s perspective
• expenditure of resources for any goal other than the creation of value for the end customer to be wasteful, and thus should be eliminated
• create more value with less work

This requires a different way of working to elicit requirements for some of us. Rather than a focuss on the business, we need instead to shift our thinking to engaging end-users. This is why, specifically the following artefacts are of vital importance in requirements elicitation and documentation:

• Personas — who are your actual end-users? Document their needs, wants, capabilities, expectations and attitudes?
• Storyboards — what is their context of use? Document their thoughts and behaviours in the context of the product or service you’re creating. I generally create both “as-is” and “to-be” storyboards rather than jumping straight into process diagrams. Most importantly, I’ve found that storyboards ultimately have greater appeal as a communications and change management tool than swimlane diagrams and are infinitely easier to create. Their value, therefore, to the project  in relation to “create more value with less work” is far greater than other artefacts you might deliver.
• Epics — how do personas and storyboards fit into the wider picture of the project, particularly system widgets that need building? Multifaceted tools like epic diagrams help to communicate a complete feature set without the need to manually create use cases. It also emphasises that traceability of features through to pain-points and benefits is important to demonstrate in relation, again, to value.

Armed with these simple tools you can begin on the right path to ensure your focus is where it needs to be — on users in order to fulfil the needs of the business.

M

Can approval gateways work within agile?

In a previous project where I was the Roshi, I brought specific milestone deliverables up to the steering committee for approval knowing ahead of time that they would indeed be approved but would take weeks to go through the red tape. This meant I had to protect the team from delays (and sometimes they would ‘get around’ to reading and signing the docs within about 4-6 weeks  … it was really just a tick-and-flick exercise) and just tell them to keep going knowing all the issues and risks involved because, at the end of the day, the biggest risk was not releasing on time. But in some severely risk averse organisations the steering committee mandates a gateway approach.

Approval gateways are synomymous with waterfall project approaches — the idea of producing a single, comprehensive document that is reviewed by the steering committee and then signed-off in order to allow you to proceed to the next part of the process. Some would argue that this gives the project an independant assurance that it is on track, will meet the organisation’s goals and has the permission of the Powers That Be to continue. I certainly agree that these sorts of activities need to occur on some level but how can it work with agile projects without causing major delays?

This is the issue put to me very recently by someone who didn’t want to execute the project in the organisation’s usual linear way (which actually has 6 approval hoops stages to jump through). For his projects he’d usually have a document to sign-off on each stage before being allowed to proceed to the next, but given I’ve been using Kanban to manage the project he’s been very interested in my agile approach to things. So we discussed how to delvier a skinny solution sooner and then deliver pieces of discrete functionality in approximately one month intervals. In essence, my suggestion was this:

• Embed the biggest part of the project — e.g. design, solution, testing and validation as described in ISO13407 — within one of the project phases (typically the design phase)
• Approve the feature sets going into the iteration loop
• Approve solutions for the feature sets going into deployment

While I’ve designed this approach specifically for ZenAgile, you could also use it for Scrum or XP.

Now this approach is by no means perfect, but it will enable the project to go through the actual iterations independant of an approval process. While one feature set is waiting for approval other feature sets can be deployed, iterated or new iterations planned.

I’ll let you know how it all turns out.

M

Turning Storyboards into Agile Requirements

I love to do storyboards. This artefact really enables you to communicate the essence of what an application, process, or policy will have on the business by just telling a story with archetypal users (aka personas) as the protagonists. But once you’ve done this is that all there is? What else can you do, or should you do, with your storyboards.

I turn my storyboards into epic requirements on an A3 page and display the logic of the storyboard along with:

• The feature as detailed on the storycard
• The user-experience (UX) to show the basic flow of choices and actions
• The business process at a high-level — just enough for someone to understand what the business rules are
• The system components that support the UX and and business process
• The personas used, their requirements, and the business requirements

 

What I end up with is a discrete piece of the solution described in just enough terms so that everyone has a sense of how all the pieces of that solution go together. Some people like to call this approach ’skinny documentation’. I like to call it ‘zen documentation’ — simple, elegant, minimalist yet comprehensive and uncomplicated.

The template is available under a Creative Commons Licence from one of our other posts on ‘requirements on a page‘.

M

Tips for presenting Agile deliverables

In the past my presentation of business level requirements has involved walking the business through the 80 pages of UML use cases and watching them glaze over after 10 minutes. I was wanting them to understand what they were signing off on but this was not the right way to present the material to that audience. I was finishing up a project recently and was asked to present our teams’ findings, requirements specification and design to the Director group.

My project was to develop a consolidated reporting tool that would bring together 6 different program data sets. So I took a user centred design approach and incorporated a lot of the Agile artefacts that I had developed on projects over the least three years and used the IA tools I had learnt from Matt, my IA mentor.

I started with face-to-face consultations and workshoped the needs and wants of the service user who were required to supply reports. I also talked to internal users who would analyse and summarise the reports for the Branch’s policy decision makers.   We decided to use Personas, want maps and process maps to present our findings about what the users really wanted and then used the site map and a prototype to show how the system would look and feel.

The presentation went extremely well as the Directors were taken through the process and had the visual clues to show them what the user experience would be. So why was this presentation approach successful? I think it was because my Agile documentation tends to be very visual as I find that my audience like to see how the design and the system will work and need to be brought along the journey. In my recent presentation I told the story through the eyes of the users and found this was a very effective way to present my deliverables.

Here are my top 5 tips for presenting Agile deliverables:

1. Establish and Communicate the Purpose: On my project, the service users clearly wanted a system that would help them manage and plan their day-to-day service business, not just a tool to use for reporting back to the funding Branch. I presented our findings from the stakeholder consultations and then presented the 6 Personas to demonstrated our understanding of these 6 key user groups. I told their story by presenting scenarios and explained why they wanted what they wanted from the system. My key message was that the system users wanted a management tool, not a reporting tool. By clearly presenting this purpose and demonstrating through personas and user stores, the Directors understood that this change would mean a win/win at implementation time as the burden of data entry for services would be lessened if there was something in it for them – namely useful management reports.

2. Use Visual Artefacts to Display Requirements and Design: The Personas were a very powerful tool to show what the archetypal users of the system wanted and how the groups differed in what they required. We displayed the primary, secondary and tertiary user needs in a want map and this helped to show the key difference and commonalities of wants across the varied stakeholders.The process maps showed how the different groups would interact with the system and how we would help them through the process and streamlining the process and reduce duplication of information. the Prototype helped to show how automation and integration of data would decrease data entry burden and also capture information that could be used to aid their management and planning.

By presenting deliverables as user scenarios and showing the findings through use of personas and want maps, the Directors were able to see the value in responding to the needs of the services as this would in the long run gain acceptance and quick wins for the system implementation. Walking this audience through Use Case after Use Case, would have missed the mark with this group as it would have been too detailed and technical and would not have given them the same feel for the concept of what the users wanted.

3. Understand your Audience: My presentation was aimed at the business users so I needed them to understand their needs so i could tailor my presentation to meet their needs. I needed to understand who were the key players? Who were the Influencers and Decision makers? What did they want from this system? What was the relationships between the different stakeholders? This was difficult as it was a short project (only 10 weeks) and I had little direct contact with some of the key players. therefore i walked closely with my business product owner to ensure he saw the deliverables in progress and has a chance to comment prior to them being presented to the Directors and Executives. I sought his guidance on how to handle the meeting, the dynamics of the stakeholders involved and walked him through the key messages. This preparation meant that I could frame the deliverables in a way that would hit the mark for this audience.

4. Understand the Business Context: Presenting to an audience when you don’t understand their business does not end well for the presenter. In conveying understanding of requirements for Business and Users, I believe it is important to know the business context. I did my research and preparation before the meeting and asked myself:

• What are the key drivers for this change?
• What processes are involved?
• What are the internal or external environmental constraints or opportunities out there for this group?

Once you know the context, demonstrate that you understand  the business needs and vision, them demonstrate how your solution will meet that need.

5. No Surprises: In the past I have been reluctant to show my work in progress as I wanted it near complete before i would share it (as the virgo perfectionist in me wanted to make sure it was right). In Agile, I have embraced this skinny solution concept and am now comfortable with starting with a skinny version, and fleshing it out as the work progresses. As I would finish a piece of thinking about users, processes or design, I would share these artefacts with the core project team, the key business product owner and then refine. This iterative approach helped my target audience to get a feel for what the deliverable would look like and meant that  when it was being presented, it was not a new concept, just a more refined and validated version of what they had seen earlier. Remember that you are presenting your requirements design solution, not telling a joke, so sending material out beforehand as pre reading will not “spoil the punch line”. If you feel people may miss the point of your deliverable without you there to narrate, then allow for their questions at the end rather than take questions throughout the presentation.

Top 10 for starting an agile project

A friend of mine is just starting an agile project and is having discussions with her organisation’s top PM about how he believes he needs to begin to address the project’s needs, particularly in relation to staffing.

The approach he was dictating will be rather familiar to a lot of you:

1. A PM will lead and manage the project
2. A BA is needed to undertake analysis and design of the solution, perhaps coupled with an enterprise architect or a solutions architect.
3. A Developer (or three) is needed to produce the software solution. He’ll also work out how long the project will take based during the initiation phase on assessment of the number of use-cases in the requirements documentation
4. A Test Manager is required to do the User Acceptance Testing (UAT) and ensure the solution doesn’t break when introduced to the big wide world.
5. You might need an IA or user-experience engineer to help with UAT at the end of the project, or if you’re really advanced in your thinking, they might be involved up front to help clarify the project solution and identify the sets of users’ needs from information classification to navigation paradigms.
6. … add 4 weeks for requirements and 2 weeks up-front for project initiation, 4 weeks for testing (UAT) at the end, and voila! you’ve got your project plan, n’est pas? (… hmmm … maybe not?)

Given her project is expected to last about 12 months, as soon as you put a PM and a BA on the books, even if its only the equivalent of 1 FTE, you’re already looking at $0.25 million or so before you actually deliver something. So, I put the question to her as to whether you start with roles or whether aspects of what users say they require need to be assessed, prioritised, and then look at the skills needed with people who have those skills to then follow.

Some people think it’s a chicken and egg thing. How do you know where to start if a PM doesn’t sit down and plan out the schedule and a BA assess what’s required? Do you need to do this before you establish that you need a PM to manage the project and a BA to do the analysis?

In essence, preparing for an agile project is just a different way of thinking. Gone are the days where I personally just automatically assign a PM and a BA because I just can’t afford the overhead of having someone to intermittently gauge project risks, update gantt charts (note: I now use Kanban instead) and dictate to the team the tasks they should be doing just because the schedule says to do so.

Here’s my top 10 on how I now begin my agile projects:

1. I write-up a basic project requirement — after all, you’ve got to start with a list of basic user needs and what that might mean in relation to a solution. I know some organisations who will spend about $10K and two weeks doing initial requirements gathering, interviewing users and/or conducting workshops, and producing something simple to communicate what the project needs.

   Me? I like to start with a collection of user stories, a few personas, create storyboards for them in a workshop environment with post-its and pens, and discuss what those user stories might mean in relation to features and sets of features. This typically takes me (and some SMEs like an enterprise architect and an experienced senior BA) a few days.

2. I then group the requirements into logical feature sets and prioritise them based on an initial assessment of value to the end-user. Card sorting with users is a good way to involve users in ascertaining priority.
3. I then draw a line in the sand that describes the most simple, skinny solution — one that essentially has to be delivered in about 8 weeks.
4. I ascertain what documentation might be required or activities that need to be undertaken
   
5. I assess what skills are required to complete the activities. If in doubt, check what you needed last time to produce a certain widget, document, or feature set. Document and baseline it often enough and this task becomes a breeze. Record how long it took and suddenly you’ll be able to have a better guess as to how long you’ll need to complete the task.
6. I then source the people with the right skills and note during the iteration of what feature set when they are required. I don’t care if they call themselves a PM, a BA, or an IA. If they have the right skills for the right job then I want them.
7. To mitigate against loss of knowledge because different people are involved at different times I use virtual teams to baseline and benchmark specific project elements, like the UI, interaction design, systems architecture, etc. In practice, this means gathering together, for example, all the analysts to have their own stand-up meetings about twice a week and have the most experienced among them take a Sensei role. These Sensei’s have their own stand-up meetings with the Roshi to communicate issues with the baseline.
8. If I’ve got multiple feature sets to produce in the skinny solution I group the feature sets into logical bundles and assign each bundle to a team. Of course this can cause fragmentation of the solution, particularly with respect to the UI and interaction design. Leveraging the Sensei in the virtual teams however mitigates the likelihood of this occurring.
9. Each team then needs someone to champion user needs and mentor people to make them more capable to deliver what the project needs (now and in the future) — the team’s Sensei. I simply choose the person that has the most experience and willingness to mentor. Some agile practitioners call this the Product Owner, Product Owner Proxy, the Product Manager or even just the Team Lead (I’m quite partial to Japanese terms and titles though, particularly given they don’t carry a lot of role ‘baggage’ with them).
10. I then choose the most experienced Sensei amongst all the groups to be the Roshi — the person who will champion the project, teach and mentor the team members, be involved in producing aspects of the project, hold morning standups and communicate issues and risks to the Steering Committee. Some call this the Scrum Master, the Project Lead, the Project Director, or the Project Manager. I don’t care about the title overall, I just want them to:
    1. lead
    2. communicate
    3. champion the project,
    4. not be an ‘extra’ or an ‘overhead’. I want them to be part of the solution and intimately familiar with it.

    When I suggested this to a group of PMs in a government department recently someone asked me whether this essentially meant that PMs needed to go out and learn new skills. I simply responded by saying that this was an opportunity for PMs to adapt and learn in order to add greater value to a project.

Working this way to sort out how to begin your agile project isn’t hard. Importantly, it emphasises that from the outset of the project that adding value to users is important and your roles are subservient to that cause.

M

The Way of ZenAgile

1. Identify your users’ stories

As I studied users’ thoughts, I found patterns in what my project was really designed to do, above and beyond what the project brief said. I listened to what my mind was drawn to listen to. These were the users’ stories — what was most important in their working lives.

There are no right or wrong answers in listening. Be honest with your users that you’re there to add value to the way they work and their stories – needs, expectations, attitudes and capabilities – will become clear.

2. Embrace your users’ needs

Once I am aware of users’ needs, it is far easier to design according to them. When faced with a decision, I can compare it to their values by documentation as personas, and see it will bring me closer to a solution that is fit for them, rather than what is easiest for the project team to produce.

3. Accept expanding feature sets

A ZenAgile mind does not struggle. It accepts users’ needs as they truly are. A rock is a rock. It will remain that way no matter how much you worry, wish, or pressure it into changing. Worrying about requirements and ever expanding user wants are the same way. I accept requirements for what they are, do not waste time or energy fretting over it, and group them into feature sets for delivery in such a way that, as a whole, they add value to users’ work.

4. Energise for change

A ZenAgile mind can give you extra energy for change as you are not wasting energy fighting against the inevitable. As above, there is a large rock in your way. You have three options:

• run into the rock repeatedly
• agonize about the rock being in the way, or
• find a way around the rock.

Before ZenAgile, I chose the first two options. With ZenAgile, I now accept the rock for what it is: an obstacle. I accept that you cannot go through it. I do not panic, and waste time and energy worrying about the obstacle. Instead I make my own path around the obstacle, either over the rock, around the rock, or under the rock.

This is Seijaku (静寂) — the energised calm.

5. Enhance knowledge of yourself

As I practice ZenAgile, I spend a fair amount of time in conversation with others and thereby understanding myself and how I come to terms with change: change in the project context, changes in requirements, and changes that need to occur to the solution.

In time, I’ve learned to quiet my mind. I’ve listened to the same fears for projects repeating themselves which inspired me to change what was causing those fears. I’ve realised, for example, that lack of a user-centred approach was a large source of anxiety, and so it was time for a change. Without time to think and meditate on the conversations in a project, we tend to ignore what our mind is telling us, and remain locked into our old patterns of doing things.

6. Gain confidence in the agile way

As you reflect on your inner self, you become conscious of who you really are, your role, and the skills you bring to aspects of the agile project. You learn what makes you happy, what is beneficial to your project, and where you fit into the multidisciplinary team. You bypass the fears and anxieties of your mind, what role you play — Business Analyst, Project Manager, Information Architecture, User Experience Designer, Change Manager — and focus on doing what needs to be done. Boldly and passionately complete the iteration. The opinions of traditional organisations like PMI, IIBA, ABAA, etc, do not matter, because you know you are doing what is right.

7. Appreciate the iterative project lifecycle

I accept the project as it truly is – evolutionary in nature, rather than revolutionary. You will always uncover new aspects of users’ needs. You will always uncover the unknown as you proceed boldly through the project. Some will be surprises like a starry evening, a stroll by the river, or a night of solitude. Each will have their own unique characteristics to be appreciated. Mundane user needs also hold their own charm. Observing the quiet details of the project lends value to the less appealing aspects, and brings peace and joy in commonplace tasks.

8. Increase consideration for others

Each person on the project is interconnected. We are all searching for the solution, requirements, and a meaningful project to work on. It is much harder to be angry at the user who argues with you about scope when you realise they are on the same path, just at a different point in their journey.

9. Simplify your project and your documentation

Conversation not documentation helps you differentiate between needs and wants. To document things completely today is to suggest that it will fix users and their workplace in time until the project has been completed. By focussing, instead, on a minimalist, simple project solution delivered in a short period of time, with just enough documentation to describe the decisions made, you are able to deliver value to people now and then build upon that solution to meet their future needs.

This is Kanso (簡素) — simplicity and elimination of clutter from the project

10. Cultivate a giving spirit by mentoring others in the team

When you are doing your role in the best way you can, your heart fills with joy. You are doing what you were put on this earth to do, and doing it to the best of your ability. Your life is simple, you are living your values, and you have a clear mind. You can then give to others, mentoring and teaching with a loving spirit, to help them along their path.

This is the True Way of ZenAgile

M

The Way of ZenAgile

The Oshö says:

“Any intelligent fool can make things bigger and more complex. It takes a touch of genius – and a lot of courage – to move in the opposite direction.”

What BA skills are of value in an Agile world?

I recently created a post on a BA’s role on agile projects. The essential message was, simply, that there is no BA role. There’s also no PM role either. However, both disciplines have an immense number of skills that are incredibly valuable in agile projects.

Sprint Zero

• Identifying users: Understanding who to talk to and who the prioritised feature sets and requirements represents if the first skill needed on an agile project. A BAs skills in stakeholder segmentation is the perfect starting point as is documenting them as personas.
• Collecting user needs described on story cards: BAs have a great number of skills in eliciting requirements. In Sprint Zero all that is required is documentation as a story card:”As a [role] I need to [activity] in order to [outcome]“This gives you great traceability throughout the project because everything as to tie into enabling the user to undertake the activity and give them the outcome they seek.

Articulating the skinny solution

• Prioritisation of requirements: What requirements are more important than others?  BAs have skills in negotiation, liaison, workshop organisation and execution. Pair a BA with an Information Architect (IA) or user-experience designer (UXD) and you get a good idea of the prioritisation of their needs and how they need to be articulated during the iteration phases as complete feature sets. Remember it’s not about having mandatory, desirable, etc. Instead, agile requirements are listed in priority order with a minimum set — the things we can’t do without — forming the skinny solution.This is where the BAs skills are essentially lacking because it’s more in the province of cognitive and behavioural psychology. The skinny system reflects users’ hygiene factors.Pair a BA with an IA, however, and the way to elicit the hygiene factors will become clear.

Planning an iteration

• Work estimation and benchmarking: What is the team going to produce? What skills are required? What activities will be done in this iteration? How long will elicitation and validation tasks take? These are all questions that BAs because of their ongoing involvement in projects are readily able to answer.I like to ensure that I’ve got a wiki handy to note the aspects of the estimation so that I can change the estimation into a benchmark once the work has been completed. Over time, this becomes a valuable knowledge tool because I can simply say “when we last did it, it took [this long]“
• Risk analysis: While doing work it’s the job of all team members to understand issues and risks as they arise and communicate them to the team’s leader, Sensei or Product Owner. The ability, therefore, to analyse on the fly is vital to the team and a skill that BAs have in spades.I find that differentiating between a fear and a risk is the hardest thing for peope to grasp. People often fear that something will eventuate, but when you start to boil things down into hard facts abouta) the impact the issue will have, and

  b) the actual likelihood of occurence (based on research) then fears can rapidly vanish when also paired with constant communication from standup meetings.

  In this way, the BAs skills are best applied in the Roshi, Scrum Master or Project Lead roles.

Understanding the context

• Elicitation and observation: Analysing how people work, why, and the outcomes achieved is an important part of a BAs skill set.  Whether done through interviews, focus groups or a contextual inquiry (my own favourite), understanding the context of use and communicating it is a BAs core strength in agile environments
• Communication: How do you relate to the rest of your multidisciplinary team that you know the context of use — both from a user and systems perspective? BAs have a variety of tools they use regularly coupled with a talent for customisation of communication mediums and messages so that information is passed on to others with maximum efficiency.So what are some of these tools?
  • Storyboards (which I love to draw!)
  • Plans on a page (epic stories)
  • User pathways
  • Behavioural and process flow diagrams
  • Context diagram
  • Logical data model

  Notice that these are all light-weight, can be done in a short period of time, are easily changed, and are, essentially, placholders for a conversation.

Understanding the human, strategic and system requirements

• Custodianship of requirements: Understanding context is one thing, but then drawing the relationships between context and the needs of different people, and then taking into consideration the constraints, is a BA’s bread and butter. Where other disciplines, particularly UXD, tend to have greater strength in understanding and documenting context, the BAs strength has always been in elicitation, translation and communication of requirements, and then the management of these requiremens through to solution design, validation and implementation.For people like me, who tend to like to work at the ‘big picture’, having a BA who is detail oriented is a must.

Solution design

• Translation, communication and business representation: This is my favourite part of the iteration. While other team members might be responsible for the organisation of information of a system, its interaction design, and its systems architectural design, the BAs skills best served during the design phase is in representation of business and end-users. This is largely because their role as custodian of requirements makes them the most familiar with what is required and what the outcomes need to be when putting everything together.

Validation of the solution

• Diplomacy, negotiation, and whole-of-project representation: While programmers use automated testing in agile environments one aspect that can’t be automatically tested is whether or not the system behaves in the way that matches the way users need and want to use the product. Here the BAs diplomacy is his most valuable asset to bring to the agile project. He has to balance the needs of everyone, as well as their expectations, to help negotiate an agreement that the solution works, or whether additional things need to be incorporated in order for the solution to be acceptable to those who will use it.Of course, the outcome also needs to be communicated to The Powers That Be. With their strong skills in diplomacy and negotiation, a BA is able to represent the team and project as its Roshi, Scrum Master, or Project Lead.Then there’s letting the team know they’ve not suceeded in producing a valid solution. Lots of people get very attached to what they think is the right way to proceed and having users tell you that it’s not what they want can be incredibly frustrating. It means that the BAs skills of diplomacy are not only valued as an outward facing ability but also as an inward facing one as well

Implementation

• Diplomacy and sign-off: Having completed the ISO13407 cycle final implementation the feature set needs to be signed-off. Someone has to remind users and the business of how the iteration has been conducted and the points of agreement throughout. This can be a delicate matter particularly given many users and sponsors want a big thick document to read at their leisure and then sign.I usually print and package all of the smaller deliverables and put them into a folder. The first page lists the milestones and activities, agreement dates and who was present/represented, and when agreement was reached. The bottom of the page has the dotted line on which to sign.
• Setting expectations: I’ve found other sponsors don’t care so much about being this formal, particularly given the BA has been in constant communication with them and set expectations along the entire feature set iteration.

Ultimately, while there is no actual BA role, a BAs skill sets are of incredible importance throughout an agile project. This is a breath of fresh air for those of us who are only invited by the PM to elicit requirements during the first stage of the a waterfall project only then to be brought back onto the scene to help with users acceptance testing. This, ultimately, is why as BAs, we should all be championing agile. And if you’re not, then you should be!

So where are your strengths? What skills do you use most often as a BA in agile environments?

M

What is a business analyst’s role in an agile world?

The last ABAA meeting for the year is nearly upon us — 8 Dec 2009. The topic of conversation will be ‘what is a business analyst’s role in an agile world’?

At first I thought this would be a very interesting conversation but the more I thought about it the more I thought it was a little naive to be asking the question in this way. Is there an actual role? … see for yourself . . .

Kanban

• Prescribes no formal roles

ZenAgile

• Samurai – the defender of the project
• Roshi – the project lead, teacher and mentor
• Sensei – the team’s mentor, leader and users’ champion
• Team – multi-disciplinary where its members are chosen based on need

Scrum

• Scrum Master – protector and champion of the team from The Powers That Be
• Product Owner – customer representative and stack prioritiser
• Team – multi-disciplinary based on need

Extreme Programming (XP)

• Tracker - measures and communicates the team’s progress
• Coach – like the Sensei in ZenAgile this is a supporting role that helps a team stay on process and help the team learn
• Tester – helps the customer define and write acceptance tests for user stories in the same way a Product Owner might do in Scrum
• Customer - defines what is the right product to build, determines the order in which features will be built, and makes sure the product actually work
• Programmer - implements the code to support the user stories
• Programmer administrator - manages the programmer environment

DSDM [1]

• Executive Sponsor – commits appropriate funds and resources
• Visionary – initialises the project by ensuring that essential requirements are found early on. The Visionary has the most accurate perception of the business objectives of the system and the project. Another task is to supervise and keep the development process in the right track.
• Ambassador User – the knowledge of user community into the project, ensures that the developers receive enough amount of user’s feedback during the development process.
• Advisor User – the one who represents important users’ viewpoints
• Project Manager – manages the project in general
• Technical Coordinator – designs the system architecture and controls the technical quality in the project
• Team Leader – ensures that the team works effectively as a whole.
• Developer – interprets the system requirements and model it including developing the deliverable code and build the prototypes
• Tester - checks the correctness in a technical extents by performing some testings. Tester will have to give some comments and documentation.
• Scribe – gathers and records the requirements, agreements, and decisions made in every workshop
• Facilitator – manages the workshops progress, acts as a motor for preparation and communication.

RUP

• Well, it has over 30 roles … so let’s not go there

If the essence of agile is simplicity then there’s certainly something wrong with some of these ways of working. The most striking thing in all of these is the lack of an actual, dedicated, business analysis role. There are certainly elements of a standard BA in DSDM’s Scribe and Facilitator roles. The Tester and Tracker roles in XP could also be done by someone with a BA background. Craig Brown of Better Projects has even suggested that a BA could undertake the role of the Product Owner in Scrum. But Scrum, ZenAgile and Kanban essentially take the most appropriate people with the most appropriate skills in order to acomplish a specific task or activity. In these, there is obvious room for a BA role to lead or follow, but no defined role for a BA to play as it’s task dependent.

So what is a business analyst’s role in an agile world? Just like there is no PM role in agile there is also no actual BA role either. In some areas that focus more on software engineering there aren’t even any standard analyst roles but moreover a focus on eliciting customer needs directly. It means that in some agile projects there may not be a perceived need to involve an analyst at all.

In reality, though, someone needs to assist with the following:

• Understanding users’ needs, wants, expectations, capabilities and attitudes
• Communicating and documenting those needs
• Translating those needs to those who will implement the project
• Ensuring that the output meets the needs of users and the strategic goals of the project and, moreover, the organisation as a whole

This reinforces that skills in business analysis are important for everyone in the project and not just a single role as is prevalent in traditional waterfall projects. It suggests that everyone, from the project lead, samurai or scrum master, should have these skills.

So what is a business analyst’s role in an agile world? There is no BA role. But everyone should definitely have a business analysts skills.

M

- – - -

1. http://www.businesspme.com/uk/articles/rh/49/Roles-of-DSDM.html

Managing agile projects with kanban

I’ve been listening with great interest to the tweets on #agile over the last few months. It’s been a great way to understand what people currently think about agile projects and where the thinking is headed in relation to its use. Recently I’ve noticed a growing number of tweets on #kanban mixed in with #agile and so I finally asked the twitterati what kanban was really all about. Fortunately, I was pointed in the direction of Jim Benson of Personal Kanban.

Personal Kanban is a great website for starting your own kanban journey. In essence, Personal Kanban relates that you should:

1. Visualise your work
2. Limit your work-in-progress

There was also an image that really helped me understand what that meant in practice on the InfoQ website that I found through doing a Google images search.

So this past week I set about making a kanban board for my own project. We’re a small team of four: me leading the project, a business analyst and Holocentric modeller, an operational concept SME and the client’s project manager. We’ve just completed the project’s initiation phase and are now headed into its planning and execution.

Of course, like any of my projects, this is done using our ZenAgile philosophy. We’ve chopped up the pieces of the project into small parts and prioritised this scope in relation to the client’s needs and the time constraints of the project. I then did a high-level view of all our activities over the next 3 months, highlighting to the client when we were likely to need to start engaging with stakeholders, primarily as a communication so we could start to book interviews and workshops. I then got out our company’s project management plan template and noted one section that essentially said ’stick in gantt chart here’. After reading an article on why gantt charts are horrible and posting some commentary to PMs myself on the issue, I decided to do my own kanban board instead.

Here’s how I put it together:

• Multi-coloured post-its: So I can immediately differentiate between tasks (green), people (pink) and categories of task completion (blue)
• Individual rows for each team member: To identify who is doing what and what stage their work is up to
• Priority tasks: These are on the LHS waiting to go onto the board when someone has completed a task
• Stakeholder post-its: Because we have to consult with some key stakeholders I felt they needed their own cards. It means at any time we can look at the board and know what stakeholders are being involved in which activity
• Parking zone: The very top row is for parking. It’s when something immediately comes up that requires our attention, or when we’ve got to wait for someone outside the team to action something before the activity can move forward. This allows us to immediately start on something else and yet remind everyone that there’s something that’s stalled.
• Timestamping: If something gets approved, signed-off, or there’s an issue we just write it onto the post-it noting the details, e.g. whether it was an email, who approved it, and when.
• String: The essential bit that marks rows and columns and so we could hang different things off the lines if needed with little alligator clips.
• Alligator clips: These became a necessity because the post-its didn’t stick very well to the felt on the board but we quickly realised it would enable us to clip items of value to each task, like reminders, links to our BaseCamp collaboration site, doodles of ideas on paper, etc.

Already, it’s helping the team and our client’s project manager to see what’s going on. In fact, he commented (jokingly) as he walked past our work area that ‘nothing had moved in hours’! What we also noticed was where the process bottlenecks within the team were occurring. You’ll see already that the guy with the bottom row already has two items currently being worked on. That’s our client’s project manager. He’s so busy with his day job that he’s falling behind on the things he has to do. We’ll deal with that next week

I’m already seeing how useful kanban is with other elements of our project. I had to do my status report on Friday — part of my company’s Quality Assurance process. So I looked at the board, wrote down what we’d accomplished this last week, wrote down what was in flow as well as what tasks were waiting to be started that I could conceive we’d likely start next week.

So would I use this technique on another project? Of course! Here’s why:

• Visualisation: Everyone can see where the project is up to, from the team to stakeholders,  just by walking past
• It’s easy to setup: The team help me set it up in about 30 mins. The hardest bit was actually that the pin board was so firm that it was almost impossible to stick pins into it *LOL*
• It’s easy to change something: Unlike a gantt chart, I can just move a post-it somewhere else or make a few notes on it with my sharpie
• It’s intuitive: What could be harder to understand than post-its on a board and limiting work-in-flow?
• It goes perfectly with ZenAgile: Zen philosophy and agile are a way of life for me. Kanban just fits in with this philosophy perfectly

M