Agile Development

Have you ever felt that something is not working in the process? for example, when gaps reoccur or when we do not advance towards our goals. Sometimes we feel that the process itself is inefficient but is being managed this way for years and no one seems to have the guts to change it, especially not now.

Actually, this is quite the common situation at many workplaces. We implement orderly work methods. The same methods do not always produce sufficient results and are not necessarily the most appropriate approach to the changing times and needs. Therefore, we must work outside the box and consider creative courses to the desired result.

I too faced a similar situation as a global product manager. The product is essentially a designed "website template" which includes different types of pages (lobbies, articles, etc.), a navigation tool-bar, a component footer, features and content. The content can be edited and add/remove components using the CMS (Content Management System).  This system is a back-end array on which the template is based. The template is implemented in approximately 50 of the company's websites, and it is my  job to ensure product development and refinement.

The development process is comprised of two main stages:

Requirements for new developments. This is what I handle, editing the requests’ details: defining the essence of the development in my own words- the need and its rots as well as the development that will serve as a solution. I will then on elaborate on how we implement the development in a CMS, what  is the expected behavior from said development (dos and don'ts) and possible scenarios. I then conclude with sending the requirements to the development team at the IT department.

Development stage- the development team works on developing the requirements. Once this stage is concluded (and quality control has been assured), we launch the website's new version  which includes the new developments. This might sound like a simple, orderly process yet my teammates and myself began to notice gaps between what we expected to receive and what we actually received:

 

Miscommunication between business teams to development teams when implementing the requirements: the teams had not communicated from the of submitting the requirements to the launch of the new version complete with the new developments. This led to questions that came up during the development regarding implementation methods or conflicts not being shared or solved internally. They should have been addressed in accordance with the developers' opinion (which are not always compatible with that of the business teams).

Development standards not being met in light of the gaps discovered following the launch, we had to 'fix' them using another development (which then led to more hours of development and effort on behalf of all parties). This situation had us stuck with unusable developments while unable to move on to new ones.

A multitude of bugs and malfunctions: despite the pre-launch quality control check, we experienced an abnormal number of malfunctions.

Where did we go wrong? Were our requirements unclear? Was the development team not sufficiently experienced? Did we invest enough resources? And most importantly, how can we improve the process?

We looked into the matter and discovered that this problem had been tackled before-in the field of programming, actually. To meet it, a new approach to software development was developed: AGILE.

In software development, agile (sometimes written Agile) practices involve discovering requirements and developing solutions through the collaborative effort of self-organizing and cross-functional teams and their customer(s)/end user(s). It advocates adaptive planning, evolutionary development, early delivery, and continual improvement, and it encourages flexible responses to change.

Development according to the Agile model includes interactions throughout each stage between the client and the development team. The client provides feedback and can change the software's original requirements (for example, according to market requirements or alternative solutions). Feedback is essential as it enables development optimally adapted to the client, unlike the traditional process of orderly analysis on which a solution is then based- despite the market or client's requirements changing in the process.

In accordance with the model, we implemented tools and methodologies which assisted us in coping with our difficulties:

Sprint- a accelerated development session, focused on clear objectives for a limited amount of time.  We allocated six weeks for the process, each session involving the following actions followed by the launch:

  • Requirement editing
  • Requirement prioritizing
  • Sprint conclusion
  • Development
  • UAT (User Acceptance Testing) & QA
  • Launch+ sanity check

Development teams and business teams should work together on a daily basis throughout the project. We hold meetings before submitting the requirements. During these meetings we discuss the essence of these requirements and the expected and unexpected behaviors.  We then decide on the best way to implement these requirements as developments and bridge the gaps.


What were the results? We reduced knowledge gaps between the teams, received quality developments and attained a more in-depth understanding of the process and its implementation.

UAT & QA- these are pre-launch tests. They used to be performed by whoever was available. Once we moved to an Agile approach, we appointed one reviewer from the business team and a team of AQ personnel to review on behalf of the development team.

What were the results? We reduced knowledge gaps.

Sanity tests, a series of tests performed on websites following their launch to ensure they meet quality standards. Every reviewer used to document their reviews on a word document. This, in turn, made the process slower. The bugs detected were only later documented by whoever reviewed the files and occasionally needed to return to the reviewer for clarification then return to the document process. However, once we adapted an Agile approach we began using the Jira software to document bugs immediately (online) and collectively- all reviewers are exposed to all malfunctions and can share their findings with each other.

What were the results? Knowledge sharing, work resources conservation, and higher quality, more thorough sanity tests.

 

Obviously, we sense the change in perspective and see positive results. From the moment we began implementing the Agile approach, we never stopped searching for ways to work more efficiently and maximize the method's potential. We used to perceive reality as a given. We have realized nowadays that all problems can be solved, or at least a better way to be handled.

 

 

 
  Contact