Myths about Agile

Myth #1: Agile = Scrum

What’s the first thing you think of when you hear the word agile? For many of us it’s a daily stand up meeting. Or maybe it’s creating a backlog of user stories that get delivered in a two-week sprint. Fact is, these are all elements of Scrum, a popular project management methodology used by many agile teams. Scrum is a framework for developing and managing work, while agile is an umbrella term for approaches like Scrum that share a common set of principles. Scrum is just one of many methodologies that build on agile principles (others include Lean, Kanban, Test-Driven Development and Xtreme Programming). Simply “doing Scrum” doesn’t mean you’re practicing agile management.

Myth #2: Anything can be changed anytime

Adopting Agile does not imply that anything can be changed anytime. It also does not imply that changes can be done without impact analysis or without planning.

Adopting agile only means we accept that fact that changes are part of life. We are open to changes and we are skilled to handle changes in efficient way.  We still need to time the changes , we still need to plan and we still need to do impact analysis.

Myth #3: Agile Doesn’t Believe in Documentation

It’s true that the Agile Manifesto values “working software over comprehensive documentation” However, this doesn’t mean documentation has no place in agile processes.

Documentation is done only when it adds value to the project or business.

Big and lengthy documents are replaced by minimum viable information that needs to be capture. Also there is a big stress on how documents can be prepared in collaborative way, shared easily and can be continually improved.

Myth #4: Agile Development Does not scale

In general, software development itself has scaling issues. This is clearly not a methodology-specific problem.

Large Scope implies greater probability for failure

Greater the team size, the greater the communication risk and complexity.

Agile development simply accepts these realities and recommends smaller projects, shorter delivery time frames and smaller teams.

This does not mean organizations should avoid solving large problems. Agile simply suggests that there is a different approach to solving the same problems. Agile methods promote taking large projects and breaking them down into a coordinated series of smaller projects staffed by smaller, cross-functional teams. The various teams’ work is integrated at least every iteration in order to reduce risk and ensure functional and technical compatibility. There are clearly other processes that need to be instituted in order to facilitate communication, integration, architectural design and standards and decision-making amongst the teams

Myth #5: Agile Doesn’t Need Project Managers

Agile project involves as much planning as any other project and for that project managers are required.

The only difference is that agile project managers won’t be telling people what to do or when to do it. That’s because agile methodologies value self-managing teams—whose success relies on collaboration, localized decision making, regular communication and tools for visualizing and sharing work in process.

Myth #6: Agile Only Works for Developers/Software

Agile is a change in mindset. It about changing the way you thinking. Agile is about breaking down work into smaller steps having independent value. This can be adopted in any domain. This can be adopted as way of life.

Myth #7: Agile Will Fix All Our Problems

A single methodology cannot fix all the problems. It helps in improving your way of working. 

How to write a good User Story

User stories are the most popular technique in Agile to capture requirements.

While writing user stories is easy, ensuring that they are effective and to the point requires diligent effort.

What is a user story

A user story describes how a user is going to use the system. It capture's user prospective.

The format of a typical user story is 

As <persona> ,

I want <what?>

so that <why?>

Example : As a student, I want to purchase parking pass, so that I can drive to school

Epic

Epics are large user stories, typically ones which are too big to implement in a single iteration and therefore they need to be dis aggregated into smaller user stories at some point

Theme

A theme is a collection of related user stories. For example, for a university registration system there might be themes around students, course management, transcript generation, grade administration, financial processing.

Themes are often used to organize stories into releases or to organize them so that various sub teams can work on them.

Elements of a user story

A user story should at minimum have a title. Other good to have elements can be

Description: More detailed description

Acceptance criteria/ Steps to validate   : To ensure the working software meets the requirements of the story
Integration : If the story is about integration with some outside entity
Assumptions : If there were any assumptions made for development of this story
Risks : Are there any risks associated with this story
Design Considerations : What are the design elements to take care of

How to Write It

Step 1 : Identify User Types

A user story describes how a user is going to use the product. So the first step is identify different types of user.

For example an online ticket booking site can have following types of user:

1 An administrator to manage users

2 An administrator to upload to data against which booking can be made

3 A customer of site who would like to book the ticket

4 An sales executing who would like to see reports as to how customers are using the site and what the revenue areas are

5 A Customer care executive to track that customers using the system are not facing any problems.

Step 2: Define Personas

Based on user types identified in step 1 , user personas should be defined. These are distinct roles for which product would be build. All the user stories would cater to requirements of at least one of these personas.

Step 3: Write one liner titles for all use cases you could come up with

Step 4 : Write additional information about user stories like description, validation steps etc.

Step 5 : Repeat the process to identify any missing stories.

How to make sure that it’s effective

Implement INVEST to write good user stories.  INVEST is an acronym which encompasses the following concepts which make up a good user story:

· Independent

· Negotiable

· Valuable

· Estimable

· Small

· Testable

Let’s look at details of each of these items: 

Independent:  Stories should be as independent as possible.   In other words, stories can be worked on in any order.  

Why is this important?  It allows for true prioritization of each and every story.  When dependencies come into play it may not be possible to implement a valuable story without implementing other much less valuable stories.

Negotiable:  A story is not a contract.  A story IS an invitation to a conversation.  The story captures the essence of what is desired.  The actual result needs to be the result of collaborative negotiation between the customer, developer and tester (at a minimum).  The goal is to meet customer needs.

Valuable:  If a story does not add any value to the system, it should not be done. User stories are prioritized in the backlog according to business value. Business value encompasses more than just customer or user facing value.  It includes internal value which is useful for things which are normally called “non-functional requirements” or something similar.  

Estimable:  A story has to be able to be estimated or sized so it can be properly prioritized.  A value with high value but extremely lengthy development time may not be the highest priority item because of the length of time to develop it.  What happens if a story can’t be estimated?  If that is the case we should consider splitting the story to gain more clarity. Sometimes even splitting a story doesn’t help. If this situation occurs it may be necessary to do some research about the story first.  

Small:  Stories are small chunks of work, but how small should they be?  The answer depends on the team and the methodology being used. Ideally a user stories should not be on average more than 3-4 days of work – TOTAL!  This includes all work to get the story to a “done” state.  

Testable:  Every story needs to be testable in order to be “done”.  Acceptance criteria should be written with user stories in order to define done state.   

Agile for Fixed Scope Projects

Today  majority of product development organizations have adopted Agile based development approach . It helps them develop products incrementally. This in turn helps in  prioritizing as the business model develops and adaptability to change. The scope is also incrementally updated in such cases. This is really helpful in cases where development needs to adapt to the changing business priorities.

I recently came across cases where budget is fixed and there is a need to complete the development within the defined scope. How can agile development help in those cases ? Should such projects follow normal waterfall approach or will there be benefit in still adopting agile model.

Here are some agile practices that can be adopted

• Incremental development where outcome of each iteration should be complete and verifiable
• Daily Stand up call within the team members to discuss task for today and obstacle that the team is facing
• Regular interaction between project team and business representative 
• There are some Engineering practices which can be beneficial as well
• Continues Build and Deployment
• Automation Testing
• Pair programming
• Test First Approach

These practices can benefit the client, the team and the management equally .

Benefits for Clients/ Business Stakeholders :

• This model gives a clear visibility about the progress and a chance to review outcome iterativly
• It provides reassurance in form of conformance to deadlines and also gives ability for course correction

Benefits for Team:

• Team gets regular feedback which helps in identifying gaps in requirement understanding
• Regular deliverable adds to the satisfaction level of the team because of feeling  of achievement
• Interaction between team members creates healthy work environment and enhances communication

Benefits for Management:

• Deliverable produced after the end of each iteration acts as  milestones for the project and enable clear tracking
• Ability to showcase the output gives greater chances of building good reputation with the client
• Happier and satisfied team results in low attrition rate
• Enhanced communication in the team helps in reducing confusions and hence lesser wastage of time