Impact Mapping In Action

The 5 minute presentation on "Impact Mapping" by our Agile Guru Em Campbell-Pretty during our Agile Trains unity day inspired me to put this technique in action. To deep dive in the topic, I did some research and read Gojko Adzic's book "Impact Mapping". The book is short, simple, to the point and you can literally cruise through this book in no time.

An impact map is a visualisation of scope and underlying assumptions and is created collaboratively by the technical and business teams. It is a mind map created by addressing 4 questions - WHY, WHO, HOW, WHAT

We used this technique for the Discovery workshops during the iteration. The typically expected outcome of the workshop is the light weight business case with vision, problem/solution statement, business drivers, features/stories (requirements) with acceptance criteria, solution overview, risks, assumptions, delivery timelines and cost benefit analysis. The impact mapping technique provides the framework and is very useful in capturing the information in structured way. Following framework was used to capture the requirements:

|WHY (Goals-what business outcome needs to be achieved)

|

|------------WHO (Actors/personas who carry out the activities/business process)

|

|------------HOW (All the activities they carry out during the business process  to achieve the goals)

|

|------------WHAT (Features/Stories and deliverables that are required to support the activities)

We also used impact mapping technique for the iteration planning. It helped the team to align their activities with the business objectives and prevented them from getting lost while delivering the projects. Following framework was used for iteration planning:

|WHY (Goals-what business outcome needs to be achieved at the end of the iteration)

|

|------------WHO (Actors- Customer,Team, Technical Governance, Systems Team, Program/Portfolio management, Production Support team....)

|

|------------HOW (DBT cycle, architecture, meetings, engagement, approvals....)

|

|------------WHAT (prioritised stories with acceptance criteria, communication plan, showcase plan)

Impact mapping technique has been of immense use to us and so far we have'nt come across any challenges in using this technique. Iam looking forward to use this technique in other avenues like stakeholder management, development planning, building high performance teams, agile coaching ..............................................

Overview Of Scaled Agile Framework (SAFe)

Scaled Agile Framework harnesses the power of Agile and Lean to address the complexity of software development in large IT enterprises. Using SAFe, many enterprises have experienced increased productivity, significant reduction in defects, faster time to market and happy customers and teams. Following is my presentation pack on Dean Leffingwell's Scaled Agile Framework (SAFe).

http://www.slideshare.net/SandeepYadav94/overview-of-safe

ATDD-Acceptance Test Driven Development

ATDD-Acceptance Test Driven Development is advanced XP practices to baseline software development on testing the user acceptance criteria.

Our Agile Team used ATDD and experienced up to 80% reduction in defects  and  rework time (reduced waste and high productivity).It also helped us to establish better trust and relationship between IT and business stakeholders.

According to Amir Kolsky in Dean Leffingwell's "Agile Software Requirements", the savings can be explained using simple maths.

If T= time to write test, C=time to write code and H= time to hook test

Time to Complete Story if you write test first= T + C + H

And

Time to Complete Story if you don’t= C + T + H + R

Where R is rework time to pass the test once the test is understood and available.

How to make ATDD work:

Customer perspective:

Identify the customers/users. Use mind mapping to understand their influence and network.

Use personas to understand the personalities and accordingly plan your communication strategy.

Maintain ongoing dialogue and engagement with the stakeholders.

Process Perspective:

Plan and schedule the requirements workshops and send notification to right stakeholders well in advance.

Send the reference material, questionaire and convey your expectations/outcome from the session.

When stories are captured in the workshops define the acceptance criteria in detail. Ask for examples and scenarios. This will also help to build the test data.

Translate the acceptance criteria into the test scenarios. The scenarios should cover the system behaviour encountered in actual use from usability and functionality perspective.

Organise another workshop to review the test scenarios in detail. If possible build the prototype so that the customer gets the look and feel of the product well in advance.

Once the scenarios are finalised start writing the automated test suite. The design and build can be done simultaneously if pair test-programming is used.

Book sessions with the customers and demonstrate the functionality progressively as and when the build for test scenario is ready and green in the automated test suite.

Consistently demo the working software and get the feedback. Plan for at least 3 review sessions depending on the number of scenarios.

Organise Acceptance test session and run through all the test scenarios. In most of the cases the UAT runs smooth and signoff can be obtained immediately.

Challenges to take care of:

Requirements/scenarios may change more frequently as you are consistently engaged with the customers.

Black box testing may take back seat as technical tests are not visible to the business users.

The process requires change in team mindset/culture.

The practise is more suited for software applications which interact with the users directly than for the softwares which do not interact with the users directly.