The Successful Agile Workflow Practices (According to the Experts)(Episode 2)

The experience shared below was based on the real cases of the experts in project management. Going through the stories can bring you valuable insights and if it helped, leaving comments will make us know how to improve the content!

Gary Gueltig

About the interviewee: Gary is a business system product management consultant with more than 20 years of experience in software solutions industry, and currently a project manager of Fairmont Associates LLC. (Visit Gary’s LinkedIn here).

I’ve worked on other Agile projects, but the one that stands out for a successful workflow was for a Procurement Software vendor (a SaaS product).

To summarize the case, the legacy product had evolved from more of a Financial Transaction focus and the challenge was to rebuild a new release (generation) of the product which was:

• More flexible with financial system integration and
• Included more expected e-commerce features clients were citing as differentiators (we did not have). (plus, a hefty list of other requirements we had collected).

Step by step workflow

1. Scope and Use Cases.

We had the benefit of having the ‘as is’ generation legacy product as our starting point for both the macros scope and micro Use Cases.

From there we expanded existing Use Cases and added additional Use Cases for the features requirements we had collected through a combination of client/prospect feedback, market research (both direct competitors as well as related products in non-completing situations. e.g., e-commerce products in general.

The ‘To Be’ Use Cases were prioritized and assigned difficulty and risk values.

2. UI Prototypes.

We identified the Use Cases which required critical UI design and developed up to 3 alternatives for each one of these.

This exercise was completed using a ‘time-boxed’ method to avoid getting into too much low-level detail too early.

The completed prototypes provided enough information to be able to refine our requirements and map them to Use Cases.

3. Build Plan — Base Product.

Using the Use Case prioritization and UI prototypes we established was we felt was the Minimum Viable Product MVP and divided that into subsets of product areas which could be tackled as independent units.

Using the preliminary database design ‘accumulated’ from the Base Product, 4 distinct sub-projects (sprints) were staffed and executed.

Two of the four components were considered not as proprietary and were ‘farmed’ out to a contractor organization.

The proprietary components remained ‘in house’ to allow our staff to develop firm a understanding and control on the ‘flexibility’ points we knew would be critical later.

4. Exercise and Refine Base Product.

Once the MVP components were complete enough to integrate them, we went back to our Use Cases and measured how well the Use Case was met (for the Use Cases included in the MVP) and the priority and difficulty of other Use Cases which would be addressed beyond MVP (to identify gaps where MVP did not fit well with remaining Use Cases.

5. Build Plan — Full Featured Product.

Using the Use Cases remaining (our backlog) and out UI prototypes was had from earlier, we defined and prioritized over eight ‘sprints’ which would take the MVP forward into our ‘Alpha’ product.

Ali Adib

About the interviewee: Ali has been a project manager for more than 10 years, for organizations such as Building Blocks Inc. and IGWD Co. He is currently a PM and a Consultant with leadership experience. (Visit Ali LinkedIn Here).

A common Agile workflow I have been using in my projects is:

To Do >> In Progress >> In review/test >> Done.

I have used this workflow both for Kanban and Scrum.

An example of where I used this was a project for developing an online resource depository.

The staff needed a way to easily access an extensive set of operational platforms and resources, on which they relied for accomplishing their daily duties. At the time, the relevant resources and links were scattered across different places and were difficult to access and navigate.

To Do

“To do” had a clear definition, of course: Once the team estimated and approved the task to be added to the sprint, it would be assigned a priority and we would start working on it.

In Progress

“In progress” was any tasks from the To-Do section that we had started working on.

Once the project team was happy with where a task is, it was presented to the relevant stakeholders for testing (if necessary), we would mark it as “In Review”.

For example, we would assign creating a prototype for a small section of the new resources page as a to-do task in a sprint. Once the project team created the prototype, it would be sent to select users to test and give feedback.

In Review/Test

Based on the results of the “In Review” phase, we would either mark a task as done or would move it back to the backlog to be included in future sprints.

Occasionally there were In Review tasks that were dealt with within the same sprint, only if the whole team approved the possibility of doing so and it did not get in the way of moving other important tasks in the sprint forward.

Sources such as tips and theories are many out there, but real case samples and insights from learned projects from the managers are drought. We would like to say “thank you” to Gary and Ali, and our other contributors, for the valuable insights provided.

Sharing is learning. “The happiest people are those who are contributing to the society” — Ted Turner.