Archive | Agile RSS feed for this section

Applying Agile principles to requirement analysis

23 May

Background

The Agile methodology originated within the software development industry. Since its inception in 2001 – Agile has expanded beyond an initial developer-centric community – to being embraced by multi-discipline teams working across numerous industries.

The antecedent of Agile within IT was the Waterfall methodology. The Waterfall framework consisted of a series of sequential, discrete phases – with each phase conveniently mapped to a role/responsibly:

Analysis Phase             -> Requirement Analysis (Business Analysts/Product Owners)

Design Phase                -> UX (Designers/Usability Experts)

Development Phase  -> Software Development (Developers)

Testing Phase               -> QA (Manual Testers and Developers in Test)

Delivery Phase             -> Release Management (Project Managers)

Due to the increasing popularity of Agile – requirement analysis has been encouraged to transition from being a stand-alone phase owned by BAs/POs – to become a project facet that can incorporate Agile principles.

In what ways can requirement analysis adopt Agile principles?

Collaborative requirement analysis

Prior to Agile – the practice of the development team being presented with an upfront, non-negotiable, detailed requirements document (BRD/functional specification etc) was common. With the advent of Agile – requirement analysis should no longer be restricted to the interaction between BAs/POs and the business – instead we should embrace collaborative requirement analysis:

A popular collaborative requirement technique is the “3 Amigos”.  This process involves the developer, BA and QA discussing the requirement specification in a workshop. Each Amigo will offer a unique perspective – through discussions the Amigos will identify edge cases, undefined requirements, opportunities and potential reuse. The 3 Amigos technique can also reduce the risk of incomplete features being pushed into development by the product team – requirement specifications must be pulled into development when they have been reviewed and accepted by the 3 Amigos.

Collaborative requirement analysis facilitates a project-wide sense of ownership – and also communicates a common understanding of what features need to be built. Collaborative requirement analysis produces more robust specifications – and reduces the role-based silos that can exist on projects.

Detail as an emergent property

Agile artefacts such as technical spikes and development iterations mean that high-level requirements can be considered sufficient at project initiation. Low fidelity requirement assets (e.g. user stories /”back of the napkin” designs) should be employed on Agile projects:

Just-in-time requirements analysis (JITRA) has a concept that requirements should only be specified at the level of detail required for upcoming development. JITRA states that the further in advance of development requirements are defined – the more probable that requirements will become out of date, leading to rework and wasted effort.

Detail should emerge when it is required – which is typically towards the middle/end of the project lifecycle. Initial requirement analysis should be focussed on business justification and solution scope.

Embrace change

Specifications will evolve throughout the project lifecycle; all team members must acknowledge the benefit of responding to change. Adapting to changes in circumstances/urgency/understanding is crucial – requirement analysis should be considered an iterative rather than exhaustive process:

In terms of systems theory – project teams should be viewed as open systems. As the system will tend towards a steady state – change should be encouraged and communicated at an organisational level. Regular priority sessions, stakeholder workshops and competitor reviews should be used to mitigate resistance to change.

Incorporating feedback is crucial to the success of a project. Requirements are not unchangeable statements – they only reflect the current and expected situation, both of which are liable to change.

Necessary documentation

The adoption of Agile principles does not mean that requirements should not be documented. Requirement documentation is vital for developers, QA and the business stakeholders:

The principle of living documentation should be embraced. This means that all documentation needs to be accessible and up-to date. Business users, developers and QA should be able to request requirement changes. Documentation is most valuable when it is understandable by all team members, available and responsive to change.

Lightweight documentation such as feature files and high level process maps summarise the output of the requirement analysis process. The Agile methodology encourages appropriate documentation – superfluous detail is wasted effort; Agile does not negate documentation.

Continuous process improvement

Requirement processes should not be viewed as immovable obstacles. Instead these processes should evolve and adapt to meet the needs of the project. Where a process or artefact ceases to produce the expected value –it should be reviewed and changed by a self-organising team:

Retrospectives are a popular technique for identifying improvement opportunities. Team members meet to discuss what the team needs start doing, stop doing, and continue doing. Regular (every 2/3 weeks) and actionable retrospectives provide an open forum for continuous process improvement.

Requirement analysis processes (to-be-analysis, process mapping, stakeholder workshops etc) can always be improved. A technique that is effective for one team – may not be effective for another – or at least may require several modifications.

Continuous delivery

The Agile methodology promotes product iterations and regular releases. In order to align with this ethos, requirement analysis must produce a constant output – a steady flow of requirements will avoid the “big bang” requirement delivery that characterised the Waterfall methodology:

Minimum Viable Product (MVP) provides the scope of requirement analysis. The MVP will be delivered in multiple iterations – requirement analysis must be constantly baselined against the MVP and ensure that there is a sufficient specification available for each delivery.

Shorter delivery timescales encourages more frequent requirement analysis output. Specifications should be aligned to the MVP – features need to be deliverable and contribute to the MVP vision.

Conclusion

Iterative, collaborative Agile development has replaced the sequential Waterfall development methodology. Prior to Agile – the product team could hand over a list of detailed requirements – which would then be used by developers to build the product. In order to align requirement analysis with Agile development practices – the following principles need to be applied: requirement collaboration, iterative specifications, embracing change, necessary documentation, continuous improvement and continuous delivery. By adopting these principles requirement analysis will transition into the Agile world, produce better specifications and ultimately lead to greater quality products.

Gamification

22 May

GAMIFICATION is the application of gaming constructs to non-game contexts.

Gaming constructs:

• Immediate rewards/feedback (e.g. badges, points, likes etc)
• Measurable progress path
• Task/challenge based
• Problem solving
• Fun factor
• Player centric

Non-game contexts:

• Personal finance (https://www.mint.com/)
• Location-based social networking (https://foursquare.com/)
• Technical forums (http://stackoverflow.com/)
• Test driven development (http://www.happyprog.com/tdgotchi/ – requires Eclipse)
• Software development tutorials (http://www.codecademy.com/)

Is Gamification effective?

The aim of Gamification is to apply the mechanics of gaming in order to reward user engagement and encourage a sense of achievement.

As a buzzword – Gamification is trending (http://www.google.com/trends/explore#q=gamification) and there is evidence that Gamification can produce some benefits:

gamification_google_trend

However – there have been MANY criticisms of Gamficiation. These range from:
• Gamification relying on extrinsic rewards rather than intrinsic motivation. This produces a failure to offer long-term, sustainable value. As with Foursquare – the appeal offered by Gamification is typically one of novelty
• Overreach. It’s been adopted too far beyond its intended remit – “Gartner Says by 2014, 80 Percent of Current Gamified Applications Will Fail to Meet Business Objectives” (http://www.gartner.com/newsroom/id/2251015)
• My favourite criticism is here: http://gamedeveloper.texterity.com/gamedeveloper/201105?pg=58#pg58

Summary

Aspects of Gamification are appealing,  when applied correctly there is evidence that Gamification can increase initial engagement. However as an approach to generate meaningful, long term changes – the jury is out.

If you’ve read this far – congratulations you’ve won a “Gamification badge” 🙂

Image

Brian the Business Analyst – part 3 – young Brian visits a career counsellor

29 Apr

brian_career_counsellor

How to measure Agile maturity on your project

28 Apr

What is “Agile”?

The concept of “Agile” was popularised in 2001 with the publication of the Agile Manifesto (http://agilemanifesto.org/). The manifesto set out a number of principles which – when successfully applied – would improve the process of software development.

Over time these Agile principles – valuing individuals and interactions over processes, responding to change, collaboration etc – were applied to projects in various industries. “Agile” made the transition from IT to general management practice in a similar manner to lean/six sigma’s evolution from its manufacturing origins.

With its increasing popularity – Project Managers were widely encouraged to implement Agile principles in order to successfully deliver projects (http://pmdoi.org/).

Why measure Agile maturity?

1) Let’s imagine the following scenario:

You’ve heard that Agile is popular with other PMs – but you’re not sure about it. You decide to try Agile on your project. You invest £10,000 on staff training and purchasing Agile artefacts (an online dashboard, Sprint boards etc). One year later – you want to find out whether your investment was worthwhile. You measure the team’s current delivery (time/cost/quality metrics) and compare this against an earlier benchmark. You notice very little improvement.

As a PM – do you attribute this to the team’s failure to implement Agile principles (i.e. due to a low level of adoption)? Or was Agile the incorrect methodology for this team (i.e. due to the nature of the product would a more structured approach have had greater efficacy)?

Without a measure of Agile maturity – how can you answer these questions?

2) In another scenario:

You’re a PM who is completely sold on “Agile”. You believe in it passionately – the more Agile a team is the better. You have a total of 7 teams across the business using Agile.

How can you identify the Agile improvement areas for each of the 7 teams? How can you provide feedback on their Agile performance?

3) Last scenario:

You dislike Agile intensely. It’s a methodology that has being extended to fit every size/structure of team. You use Waterfall – and want to convey that this approach works for your team.

Imagine that you could measure your team’s success using the standard metrics – and also show that this success has been possible without being “Agile”. Perhaps then there would be less pressure from management to adopt Agile principles.

Broadly speaking therefore – the pragmatist (scenario 1), Agile evangelist (scenario 2) and Agile sceptic (scenario 3) would each benefit from the ability to quantify Agile adoption. So what types of Agile assessments are available?

How to measure Agile maturity?

There are 4 widely available, self-administrable, free assessments that can provide teams with a detailed breakdown of performance across key Agile areas:

1) Mike Cohn & Kenny Rubin (http://comparativeagility.com/): This assessment measures a team’s performance across 7 dimensions: teamwork, requirements, planning, technical practices, quality, culture and knowledge creation. With approximately 100 questions – this is one of the most detailed assessments available online.

2) Thoughtworks (http://www.agileassessments.com/online-assessments/agile-self-evaluation): Consisting of 20 questions – and providing a detailed summary report – this assessment was developed by a leading consultancy. The assessment is best administered as a group exercise- as this encourages dialogue and leads to a more balanced viewpoint.

3) The Nokia Test (http://jeffsutherland.com/nokiatest.pdf): This is one of the oldest assessments available – and was produced by Jeff Sutherland (a key figure in the Agile community). The Nokia Test focuses on the iterative nature of Agile and the adoption of the Scrum framework.

4) Agile Karlskrona test (http://www.piratson.se/archive/Agile_Karlskrona_Test.html or http://www.mayberg.se/archive/Agile_Karlskrona_Test.pdf): an incredibly simple self-assessment that provides a team with a basic snapshot of their performance.

Limitations

The 4 assessments mentioned above provide valuable feedback: improvement areas are flagged and successes are recognised. They also encourage dialogue throughout the team in terms of best practices.

It is worth adding however that “Agile” is based on a descriptive manifesto (e.g. you should value customer collaboration) – rather than a prescriptive manifesto (e.g. you should produce a customer collaboration tracker which should be reviewed biweekly with the PMO team). The origins of Agile (in terms of a descriptive manifesto), and the lack of a definitive maturity model, mean that although measuring Agile maturity is worthwhile – it is an imprecise science.

Low Fidelity vs High Fidelity

9 Mar

Low fidelity assets are frequently employed on Agile projects. An example of a low fidelity asset is the production of basic wireframes/”back of the napkin” designs:

Screen Shot 2013-03-09 at 22.21.34

The advantage low fidelity designs is that they encourage feedback and corresponding design iterations – without the waste/overhead involved in high fidelity assets.

In terms of the Business Analyst role on Agile projects – low fidelity assets may include:

  • User stories
  • High level requirements (basic specification)
  • High level acceptance criteria (basic user acceptance conditions)

What are the advantages of the Business Analyst employing the above mentioned low fidelity assets:

  • They encourage a focus on the essential behavior of the system (MOSCOW must haves). This ensures the Minimum Viable Product (MVP) is documented early in the project lifecycle.
  • Facilitates communication across a project. Low fidelity assets encourage feedback – they are much easier to present and convey than a 30 page BRD.
  • Mitigates the risk of mistakes entering into detailed requirement specifications – assumptions can be identified earlier on.
  • Descriptive vs prescriptive. The focus is on the high level functionality – this means that the technical solution is less constrained by non-essential elements of the product specification.
  • Easily produced and maintainable – changes can be made quickly and with minimum effort. This sits well in the Agile world.
  • Stand-alone pieces of work (features) can be identified – this enables backlog prioritization.
  • Fidelity (i.e. detail) is added through participative iterations – documentation evolves through collaboration into a steady state.

Product Owners vs Business Analysts – MOSTly different roles?

14 Feb

The MOST acronym (Mission, Objectives, Strategy, Tactics) can be used to describe the main differences between the Product Owner and Business Analyst roles on a project.

Mission

  • This is the vision statement for the product. It should be concise and value driven.
  • This will provide answers to the following questions: What is the intention and long term direction of the product? Who is the user-base/target market? What is the business benefit?
  • Example: “We want to deliver the most popular Sports app in the World – with unparalleled journalist content”
  • Responsibility of the Product Owner.

Objectives

  • These are derived from the product mission. These are targets that will translate the product mission into reality.
  • These will provide answers to the following questions: What goals will lead us to achieve our mission? What will need to be created? What will need to be changed? What will need to be acquired?
  • Example: “We need to deliver live video streaming in the iOS app
  • Responsibility of the Business Analyst.

Strategy

  • This is a description of how success will be achieved. This should describe the features and their prioritisation.
  • This will provide answers to the following questions: How will the product scope be delivered across iterations? What is the Minimum Viable Product for release 1.0/launch? Which features are nice-to-haves?
  • Example: “Pundit analysis, live video & match statistics are required for the first release – personalisation will be delivered in the second release of the app” 
  • Responsibility of the Product Owner.

Tactics

  • These are derived from the product strategy. These are the deliverables that will be provided by the development team.
  • These will provide answers to the following questions: How can we achieve tangible benefits in the next Sprints? What tasks need to be completed? How can work be grouped together logically & in terms of delivery?
  • Example: “Provide live streaming of our CMS videos using Media Player”
  • Responsibility of the Business Analyst.

Summary

Within MOST there are 2 definition activities (Mission and Objectives) and 2 planning activities (Strategy and Tactics).

  • The Mission (high level product definition) is done by the Product Owner.
  • The Objectives (detailed product definition) is done by the Business Analyst.
  • The Strategy (high level product planning) is done by the Product Owner.
  • The Tactics (detailed product planning) is done by the Business Analyst.

User stories – WHO wants them, WHAT are they, WHY use them?

9 Feb

WHO wants user stories?

  • Project stakeholders: these individuals want an easy method to pin ideas to the product backlog. With user stories ideas don’t need to be defined in detail – the user story will provide a “placeholder for a conversation”.
  • The end user: teams that are able to elicit requirements directly from end users can use this technique to facilitate the discussion and documentation of feature requests. What does the user want to do? Why?
  • Project Manager/Product Owner: when grooming the product backlog – user stories are much easier to prioritise than detailed requirement specifications. User stories provide a non-technical, concise summary for the product team to decide the primacy of a feature.

WHAT are user stories?

  • Definition: User stories describe the desired interaction/dialogue between a user and the system. User stories provide the user’s rationale for a feature.
  • Typical format:
    • AS A [actor/user role] – this can be referred to as the WHO section. Who wants this feature? The user could be a generic actor (e.g. AS A user of the website), or a specific user role (e.g. AS A frequent business traveller), or even another system (AS A BACS payment system). Actors can be identified by internal discussions within the project team – identifying user roles may require more sophisticated analysis (e.g. profiling activities by the marketing department, transaction analysis, industry segmentations etc).
    • I WANT [feature/action] – this can be referred to as the WHAT section. What does the user want? The user will typically want the system to perform a new behaviour e.g. I WANT  the ability to track an order, I WANT to pay for orders using an AMEX card, I WANT to cancel an order without any hassle.
    • SO THAT [benefit] – this can be referred to as the WHY section. Why does a user want this functionality? This section provides the justification/benefit of the feature.
    • Characteristics of good user stories: the INVEST acronym is frequently used to describe attributes of a good user story:
      • Independent
      • Negotiable
      • Valuable / Vertical
      • Estimable
      • Sized Appropriately / Small
      • Testable

WHY use user stories?

  • Requirements as an emergent property: user stories provide the Business Analyst with a springboard for analysis. A single user story (e.g. AS A price sensitive user, I WANT to be able to cancel my order, SO THAT I do not get charged by the bank for exceeding their overdraft limit) can lead to multiple scenarios for the BA. What is the happy path of this user story? What are the edge cases (e.g. what if some of the items are in the sale)? What are the business rules (e.g. full refunds are only provided up to 3 days from when the transaction was processed)? Requirements should emerge from user stories  (not vice versa) – all requirements should have a user justification.
  • Maintenance of the backlog: the detail of a feature is abstracted a level below user stories. In addition – user stories should have few/no dependencies (refer to the INVEST acronym) – this means that user stories are lightweight additions to the product backlog and are therefore easy to maintain.
  • Available for discussion: user stories should be understandable by business users/end users/developers/all team members. User stories facilitate cross-role discussions and encourage open communication between various project sillos.
  • Trees and forests: Working at a detailed level can occasionally mean that some requirements are not identified. User stories provide a way to mitigate the probability that user journeys are missed by the team.

BANALysis – a new word for the BA lexicon

7 Feb

BANALysis

BA*NAL*y*sis

Noun

A combination of the words banal and analysis. Refers to situations where analysis is requested but not required.

Usage

“I’ve got to do BANALysis of a pagination component – UX have given all the different variants anyway!!”

“Can you do some BANALysis of this page of static links?”

“Can you do some BANALysis to MOSCOW these requirements with the senior stakeholders (who really want them all anyway)?”

Synonyms

unnecessary, tedious, obvious

The 3 Amigos – BA, QA and Developer

7 Feb

The 3 Amigos (sometimes referred to as a “Specification Workshop”) is a meeting where the Business Analyst presents requirements and test scenarios (collectively called a “feature”) for review by a member of the development team and a member of the quality assurance team. The overall aims are to ensure:

i)              COLLABORATIVE REQUIREMENTS: a common understanding of what needs to be built, business justification is conveyed for a feature, a project-wide sense of ownership.

ii)             COLLABORATIVE TESTS: all teams members contribute to testing the quality of a feature, business & technical edge cases are identifed, testing restrictions are conveyed, test duplication within the team is reduced.

iii)           READY FOR DEV CONSENSUS: Pull vs Push approach – features are pulled into a Sprint when they have been reviewed and accepted by the 3 Amigos. Features cannot be pushed into a Sprint – this reduces the risk of the team incorrectly assuming that a feature is ready for dev.

The general format of the 3 Amigo process is:

  •  A time boxed meeting (30 mins – 1 hrs max) is setup 1-2 Sprints before a feature is expected to go into development.
  • 1 Developer + 1 QA are identified and invited to the meeting. These are expected to be the individuals who will develop and test that feature.
  • The Business Analyst begins the meeting by introducing the feature to the Amigos. Why is the feature needed, is it like anything they’ve done before, what should it look like on the site?
  • The Business Analyst presents the requirements (prepared prior to the 3 Amigos) – these are reviewed by the Amigos who provide feedback. The requirements should be updated in the session until the requirements are deemed “Ready for Dev”.
  • The Business Analyst will then present the test scenarios (prepared before the meeting) – these are also reviewed by the Amigos. Feedback is incorporated until it is agreed that the test scenarios cover the feature’s expected behavior – this ensures good test coverage.
  • The feature/specification is now “Ready for Dev” – it has been accepted by the developer and QA.
  • Developer – asked to identify any tasks that need to be done pre-development e.g. do they need access to an endpoint, do they need to see variants of the visual design? These tasks are assigned and put on the current Sprint board.
  • QA – asked to identify any tasks that need to be done pre-feature testing e.g. do they require access to a system, do they need mock data? These tasks are assigned and put on the current Sprint board.
  • Estimate: the Amigos should have a common understanding of the requirements and the test scenarios (the “feature”). This is a good opportunity for the developer and QA to provide estimates.

Lessons we have learnt:

  • The developer and QA involved in the 3 Amigo meeting should be the individuals who will develop and test the feature. We have explored the idea of “any developer/QA can be involved in the 3 Amigos and any developer/QA can then pickup the feature” – however we have learnt that maximum benefit comes from the Amigos being involved in a feature until its completion.
  • The requirements and test scenarios should be maintained in a place where everyone has access. This gives individuals/stakeholders (even non-Amigos) VISIBILITY of the requirements and tests.
  • What language should be used for requirements and test scenarios? Technical? Business? Plain English? We have found that DOMAIN language is the most useful … if you work in banking than all 3 Amigos should know what a derivative is – but not everyone is expected to know what a cron job is. If in doubt – maintain a glossary of terms.

Challenges:

  • For the BA: although the BA still tacitly “owns” the requirements – part of the collaborative 3 Amigo process is a shared level of ownership. This can be difficult for a BA – as requirements are one of the main BA deliverables.
  • For the Developer: there may be some resistance to reviewing requirements/test scenarios as these are “non–development activities”. In our experience the 3 Amigos process enables the developer to have greater visibility of the requirements, provide technical feedback and convey challenges/blockers.
  • For the QA: similar to the BA – they may need time to adjust to the test scenarios being under common ownership.
  • For the Product Owner: the Product Owner isn’t an Amigo. The process assumes that the BA represents the Product Owner/stakeholders. Once the requirements and test scenarios have been through the 3 Amigo process– it can be worth re-confirming them with stakeholders.
  • For the PM: the 3 Amigo process limits what a PM can put into a Sprint – features are pulled into a Sprint by the team and not pushed by the PM. The BA can begin to take on some traditional PM duties: task breakdown (tasks are identified in the 3 Amigos), estimations (developer + QA estimates are provided in the 3 Amigos), limited Sprint planning etc.
  • For the Agile enthusiast: to be a fully iterative process there may be “pre amigo” meetings – and complex features may require several sessions.