Smart Agile: Choose Your Approach Wisely
All companies have different approaches when trying to adopt Agile, but the common recommended steps are to conduct a pilot project to test feasibility, or to invite a project coach that will help them during the transition from a traditional to agile development.
There are situations where the higher management insists that the company needs its teams to be Agile, not realizing the impact of the agility for the company as a whole. This situation may lead the management process in a wrong direction since they’re pushing ahead Agile practices, instead of the real agility.
Dynamic Agile
The adoption of Agile methodology in some organizations can be difficult in some cases. There are many available development and project management practices on the market, but the agile approach promises a fast and efficient way to product delivery with less obstructions and impediments. Project teams usually concentrate on agile artifacts (user stories, iterations, meetings, backlog), and on regular testing of each developed item (component).
By doing so the teams expect to maximize the development output. However, they get in a rush and apply ideas that are not mature and lose the clients’ viewpoint.
A Scrum Master is responsible for ensuring that the project is carried out according to the values and processes of Scrum; he controls the schedule, and assigns tasks to all team members. The Scrum Master cooperates with the project team, the client and managers.
Product owners are on a constant rush to complete stories for the next sprint, and have very little time or energy for other actions like analyzing market and client’s needs.
UX designers also have a lot of stress during sprints (iterations), trying to create all required details and having no time to search for different ways to accomplish things.
Agile is a dynamic process, and its purpose is to make you effective. Your team will try to deliver constant releases (the increments will be deliverable items, maybe with minor changes required), but the entire process may slow down the team over a longer period.
A product manager of one of the major telecom companies told us his story about their experience in adopting Agile in their corporation. They had to develop a mobile app with components built by different teams, and the app had been dependent on new features in the operating system. The teams had tried to follow all Agile practices, but the complex management of various teams had become a big problem. When one of the main teams asked for a dependent component, all other teams went crazy.
The teams had already planned out the user stories and sprints, and they had found that the progress was slow and they had to choose features to drop out in order to keep the app stable.
Of course, all teams felt frustrated. The product teams was frustrated because the demands had changed over time, while the tech teams was frustrated that they had to rewrite a large portion of the code because of the changed dependencies, or not having final specification at the start of the project.
Theoretical Agile
The same product manager also analyzed several companies and their Agile implementation experience. Many of them faced similar problems, and there were several companies that had decided that they would accept Agile just as a theory, not as a dynamic process.
In such a case, the teams should agree at the beginning what items will be best developed using Agile. The teams may find that some important components will require a lot of time and iterations. So, they may decide to first build the basic functions for other components and simulate outputs for them. When they have more time the developers may try different ways of building the basic components.
There are also different approaches to sprints and the ways to increase the effectiveness: some organizations accept a 3-week sprint for iteration, since they may find 2 weeks is too limiting. Others will continue to work only in 2-week sprints.
Another important issue is time requirements for different team members. Managers (scrum masters) should sit down and discus the best ways to maximize the work of UX designers. If they make very detailed specs for every sprint, they will not have time to test the important ideas.
The teams could agree to lock down deliverables for the next two sprints, and make time for the designer and architect to create main prototypes for them in advance. This will solve a lot of questions when it comes to implementation.
Product owners should ensure that all team members are familiar with the items in the Product backlog. They are responsible for managing of the Product backlog. During the realization of the project, they allocate these items from the backlog into the sprint.
Conclusion
First, try to apply Agile as a concept. It will give your team more ownership in the development process, and as time goes by, you will be able to make the most of it in your context.
