As we stated in the first part about Waterfall, we are going to investigate the most popular project management methodologies with the aim to identify potential risks, share our experience from the real life and provide insights on what to keep an eye on.
Methodology 2: Agile
The Agile Manifesto originated as a response to shortcomings of the Waterfall model. The need was to address the linear sequential process in order to keep up with the ever more dynamic markets and customer demands.
Especially in industries like software development where one product release cycle in the classical Waterfall model could take around a year. The customer demands change dramatically in a year.
How is it possible to shake a status quo and suddenly out of nowhere solve the issues of the Waterfall model?
Of course not everybody can use Agile. Agile is mostly suited for cases when you are able to deliver partial improvements to the product. This is mostly software.
However, some large product installations like elevators can undergo partial improvements over time. Car makers have new models, face lifts etc. Of course you do not go to the car owner and rebuild their car over a night. You rather release new model, model 5, 6, 7, X… Clearly even a hardware can use Agile (e.g. mobile phones).
Isn’t Scrum Agile as well? Mathematically speaking not. Scrum adopts all Agile values and principles and adds its own. From the other point of view, Agile does not have all the attributes of Scrum. While Scrum implements Agile, Agile is not Scrum neither implements nor adopts it.
Six key deliverables and the workflow
Agile is based on six key deliverables:
- Product vision statement: A summary that articulates the goals of the product.
- Product roadmap: The high-level view of the requirements needed to achieve the product vision. What are the Epics (customer cases) to be met?
- Product backlog: a full list of all user stories (features) to be implemented in order to create the product as required, ideally ordered by priority.
- Release plan: An action plan (tasks in a timetable) for the release of a working product.
- Iteration (e.g. sprint) backlog: The user stories (requirements), goals, and tasks linked to the current iteration.
- Increment: The working product functionality that is presented to the stakeholders at the end of the iteration and could potentially be given to the customer.
When teams dive deep into product increment creation, there is a risk of forgetting the big picture. It is an intrinsic part of the product manager’s role to remind the big picture to the team. Especially because when solving individual tasks and their challenges, people might easily slip to solving problems that are absolutely not needed to be solved for the product and customer.
Another important aspect is making sure that all completed tasks make sense when combined together. In other words, to make sure that the accomplished work can be combined to fully implement a feature, a customer use case or a bigger piece of the product backlog. Often, when this is forgotten, teams end up with many great partial solution that unfortunately cannot fulfil customer needs.
Agile places large emphasis on collaboration, flexibility, continuous improvement, and high quality results. What does that mean? It means that we mostly need a highly skilled team with multi-disciplinary experience. Especially in case of Scrum.
Conclusion – Who should use Agile?
Who should use Agile? Teams working on projects requiring flexibility, having a high level of complexity or uncertainty. Also, have a look at the following two flavors of Agile – Scrum and Kanban.
All projects magaed in an Agile way can be easily tracked in an online tool so that all team members have instant access to up-to-date information and project state whenever they need.
In the next part, we’ll discuss the most popular Agile implementation – Scrum.
In many systems, time is either just a piece of text or, in the better case, something that you can enter via a calendar popup dialog. The system itself then barely understands the meaning.
On the other hand, we people understand time pretty well. We know that a certain date is associated with a day of week. We know that we typically do not work during the weekend. We know that Christmas are in the fourth quarter.
We would like our systems to naturally understand this as well. And guess what, Lumeer does exactly that.
The easiest way to proceed is to tell Lumeer what format of date and time we have or expect. Lumeer tries to guess that for you, however, it might be difficult to recognize month and day when the numbers do not exceed 12 for instance.
Let’s have a look at our example with data about calls made by our sales department. In the table with calls statistics, we right-click on the Call Time column header, select Attribute type and switch it to Date.
Next, we select a Custom format and enter a sort of a magic formula (see below) that reflects our format. We can see in the example that the format matches.
In the following table, we can see what is the meaning of individual codes in the date time format formula:
|YYYY, YY||Years 2021, 21|
|MM, M||Months 01-12, 1-12|
|DD, D||Days 00-31, 0-31|
|HH, H||Hours 00-23, 0-23|
|hh, h||Hours 00-12, 0-12|
|mm, m||Minutes 00-59, 0-59|
|ss, s||Seconds 00-59, 0-59|
|S, SS, SSS||Milliseconds 0-999|
|a, A||am/pm, AM/PM|
|DDD, DDDD||Day of year 1-365|
|ddd, dddd||Day of week Mon, Monday|
|e, E||Day of week 0-6, 1-7|
|WW, W||Week of year 01-53, 1-53|
|x, X||Timestamp 1410715640579, 1410715640.579|
|Z, ZZ||Offset from UTC +12:00|
The advantage of Lumeer understanding the format is that we can create a Pivot table that counts total and unique calls per day of week and hour of the day.