This article is about agile usability considering agile principles in software development environment. We will try help in finding an answer for a question if agile is a right approach for a project. This post in particular is focused on Scrum framework as an agile method.
Before I started work in agile teams, the agile was a buzzword for me. After few months I had worked in Scrum I got better imagination of this term. Proper understanding requires both theoretical knowledge and practice. It is a continuous process. We are getting better understanding and gut feeling when we spend more time with it. Let us start our consideration with Manifesto for Agile Software Development :
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Need an agile methodology or not?
If you are looking for an answer if agile is good for your organization or project then start with the agile basics. Agile manifesto defines principles for agile. Decisions about introducing agile or not should be made after consideration of this manifesto. Successful agile implementation could be expected when you are ready to respect all these principles. Partial and progressive introduction of agile principles could be also sometimes a way toward success with agile. In fact, Manifesto for Agile Software Development is all you need to start investigating your case.
Which agile methodology to use?
Once you decide agile is right for your project then you need to consider available agile methodologies. Please refer to  in order to get overview of those methodologies. Scrum and Kanban are most popular. In order to make this agile consideration even more complicated I have to mention about scaling agile. Sooner or later your organization and project get bigger and then agile on a single team will not be enough. Scaling agile comes then into play. There is an article  which discusses different approaches to scaling agile.
Agile in not about being spontaneous. There are plans and plannings in agile methodologies. In long term, agile requires precision. Estimation provided on sprint planning in Scrum should reflect implementation feasibility. Agile requires continuous inspection and adaptation. It prevents from delivering invalid and obsolete product. The purpose is to maximize product value throughout the whole development process.
Agile produces endless questions. Let us take into account this example:
Does a Business Analyst have a place in Scrum? If so, where -https://www.linkedin.com/grp/post/37631-6051982866898837506?trk=groups-post-b-title
The question is very tricky. Business Analyst is not a Scrum role. You want Scrum, you already have Business Analyst who has a clear role and you wonder how to bring them together. Many questions like this will come into your mind when you start considering Scrum.
What could be an answer for this example?
Scrum defines the following roles: Developer, Scrum Master and Product Owner. Can you see Business Analyst here? No! This could be the immediate and correct answer. However the answer may be misleading too. Let us continue the contemplation. Do scrum teams have testers, technical writers as well? Yes. Does it violate scrum? Not necessarily, they are just considered as developers. Where to put Business Analyst? Business Analyst can be outside of a Scrum Team and collaborate with it. BA can also become development part of a team. These are only some proposals of answers.
Decisions about going with agile are not straightforward. There is required profound research. Scrum is probably the most popular agile methodology. Scrum’s goal is resolving complex issues. It is not for simple and easy to predict things. Agile requires courage and responsibility.