When we discuss about the project management. we have four model of project management Agile, Incremental, Iterative, and Predictive. Here’s the explanation of Agile, Incremental, Iterative, and Predictive processes in project management according to PMI
Agile
Process: Agile adopts an adaptive approach, combining iterative and incremental methods. Projects are divided into short iterations (typically 1–4 weeks), each delivering a usable product increment. Every iteration involves intensive collaboration between the team and stakeholders to ensure the product meets requirements.
Focus: Rapid response to changes, collaboration, and delivering value quickly.
Example Implementation: Developing a mobile application with features that evolve based on user feedback.
Good Case: Creating product in startup and deploy to the marketplace
Incremental
Process: The product is developed in small increments, where each increment delivers specific functional value. Each increment can be independently released and immediately provide value to users.
Focus: Delivering results in stages.
Example Implementation: Developing software where features like search functionality, recommendations, and playlists are developed separately.
Good case: creating inhouse system information that will be used right away
Iterative
Process: Development is conducted through repeated iterations to enhance the product's quality. Each iteration delivers a better version of the product based on feedback and testing.
Focus: Continuous improvement.
Example Implementation: Developing an AI algorithm that is refined iteratively to increase its accuracy.
Good case: creating multiplayer video game with more than season of play.
Predictive
Process: This approach involves full planning at the beginning of the project. All phases of the project—from planning to implementation—are designed in detail before the work begins.
Focus: Stability and control.
Example Implementation: Developing an ERP system with a clear and stable scope and requirements.
Good case: creating standardized software like ERP, E-commerce and the other
These approaches are used depending on the project characteristics. PMI emphasizes selecting the most suitable approach to achieve optimal results. Let me know if you'd like to explore any of these in more depth! 😊
Let's say you're developing a Web Application that utilizes AI for livestock disease detection. Here's how you can apply Lean in your Agile process:
Identify Value: Prioritize features that enhance disease detection accuracy and provide timely alerts to farmers. For example, notification is primary feature that should be prioritize.
Eliminate Waste: Remove any unnecessary steps in the development process that don't directly contribute to these features. For example, since the process is quite straightforward, we don't need to create business process diagram
Create Flow: Streamline the integration of IoT devices and data analytics to ensure seamless operation. We use CI/CD to automate the build process and also use the flow.
Implement Pull Systems: Use Kanban boards to manage tasks related to device integration, data collection, and alert systems.
Empower Teams: Allow your team to make quick decisions regarding device configurations and data processing techniques. For example, technical teams invite vendor to discuss and to compare device configuration.
Build Quality In: Use automated tests to ensure the accuracy and reliability of disease detection algorithms. For example, we use NUnit to test the system.
Measure and Optimize: Track metrics like detection accuracy, response time, and farmer satisfaction to continuously improve the solution. we can use App Insight to measure the application perform and use Azure Open AI studio to validate it!
The Product Owner is not just a passive participant in the change process; they are active change leaders. They must embrace change, using it as an opportunity to innovate and improve the product. By fostering a culture of adaptability and continuous learning, the PO ensures that the team can navigate change successfully.
There are seven things that we need to execute:
Defining user value. On this step the PO should understand is the changes is major OR minor. A lot of minor changes can be majored
Managing backlog. PO should document meeting notes and versioning
Stakeholder negotiation. PO should arrange meeting with the customer to discuss the trade off and additional information
Prioritizing changes. PO should communicate with stakeholder to discuss the impact of the software development
Release planning. PO should understand the effect and technical review and adjustment
Risk management. PO should discuss the risk management because the changes
Acceptance criteria. PO should create structured to review the changes result
You can see the detail in this picture
As a software developer, establishing a productive daily routine is crucial for success, especially when working within the Scrum framework and utilizing tools like Azure DevOps Boards and Visual Studio. Here are some best practices to help you optimize your workflow and enhance your development process.
Start your days with the plan
Developer can use planner and Microsoft to Do to plan their daily activities for today. Here are the tips.
Check your DevOps Board task, see what you need to do today
Update your planner with your Board task, you can read the DevOps boards task to Planner by using Power Automate.
Sync your Planner with Microsoft To Do
Collaborate with Your Teams
Do stand up meeting (daily scrum) and do strategic planning session for the next 24 hours. Engage actively, share your progress, and discuss any impediments you're facing. This is the time to synchronize with your team and adjust your sprint backlog if necessary.
Prioritize Your Days
Begin each day with a clear understanding of your goals. Review your sprint goals and the tasks assigned to you in Azure DevOps Boards. This will help you prioritize your work and focus on what needs to be accomplished for the day.
Coding and Commenting
Visual Studio is a powerful integrated development environment (IDE) that offers a plethora of features to streamline your coding tasks. Familiarize yourself with its debugging tools, code navigation features, and extensions that can enhance your productivity.
use Copilot Chat to learn the latest features and optimize your codes
use comment to document your thoughts and codes.
refactoring or optimize when the codes is working.
Code Review with your pairs
Code reviews are an integral part of the development process. Allocate time in your daily routine to review your peers' code and collaborate on solutions. This practice not only improves code quality but also fosters knowledge sharing within the team.
End Your Day with Reflection
At the end of your workday, take a moment to reflect on what you've accomplished and what could be improved. Update your tasks in Azure DevOps Boards and Planner for the next Daily Scrum. This reflection will help you stay organized and ready for the following day.
Don't forget to learn
Join applied skills, Microsoft Learn challenge, read a book or join MOOC to keep you continuous learning happen.
After product owner creates product backlog based on the customer voices. The next agenda is to select the product backlog to a sprint. If you are wondering how to create an user story format in product backlog you can see this video. On this video, we will discuss what you need to do in Sprint Planning. There are five steps in sprint planning namely:
Creating a sprint length and release.
Redefining product backlog
Put a backlog into a sprint and reorder it as sprint backlog
Adding the details of Sprint Backlog with Tasks.
The definition of done in a sprint
Creating a sprint length and release
After you have a draft of product backlogs, you can try to create a release.
A release should be discussed with the client. Some of client said a release as a commissioning list of a project. A release is your commitment to deliver values to the customers.
Your customers will approve the timeline for a release. It can be a date namely deadline. For example, your customer said that the system should be released on 19 January 2022. If today is 19 November 2022, you will have two months before the release date. Imagine if your team works for 5 days / week. It means you will have 40 days to catchup.
You can get sprint numbers by dividing a release length with your sprint length. In this example, we have 40 days of works. If your team decide to choose sprint length for 20 days. You will have two sprints.
Sprint length is defined by the development team and product owner.
You might ask why we choose 20 days, why not five days or ten days. Basically, there is no rule of thumbs of the sprint length. However please consider these when you choose the sprint length.
Try to convert the user story points into the duration. You can do that by using your team velocity based on project historical analysis.
Warm boot. Your team has previous experience. You can capture the velocity. For example, they finished 50 user story points for 25 days. It means the velocity is 2 user story points / day. Therefore, if you have the longest product backlog Is 40 points. You can get the sprint length 20 days
Cold boot. Your team has no previous experience. On this case you can ask the development team to convert the points into days.
You can find the sprint length by trying to put related product backlog into a single sprint. For example, you have a related story such as login, registration, and profile. And you can finish in 10 days. It means you can choose 10 days as your sprint length. Try to find the longest related product backlog in your project. And choose that as your sprint length.
The shortest the sprint length the worst in efficiency. For example, you have 5 days of sprint length. It means you will have 4 days of sprint review and sprint retrospective for a month. If you have 10 days of sprint length, you will only have 2 days of sprint review and sprint retrospective. However, if the sprint length is too long, you will face inefficiency when the product backlog changes in term of requirements.
Redefining product backlog
In a sprint planning, you should detail the product backlog. It means you should complete the
Business rules
Stored Data
Usage Scenario
The acceptance criteria
The business values
You can read this post Estimating Product Backlog in Azure DevOps (ridilabs.net) for further information
Reordering Sprint Backlog
After you complete the product backlog, you can put the backlog into a sprint. In Azure Boards, you can navigate to the Sprint menu and do these following:
Reorder the product backlog. You can put the highest priority product backlog in a top
Put the product backlog in a sprint. You can drag and drop your product backlog in a sprint
Adding the details of The Sprint as Task
Task is technical activity that will be done by the development team. You can add the task by visiting the Sprints menu and click the + sign in the left of your backlog. Ask your team to add their personal task such as creating table, setup the middleware server, or even build user interface,
The definition of done (DOD).
DOD is the heart of a sprint closing. For example, you can say the sprint is closed when:
The entire task in a sprint is finished AND,
The backlog is tested and passed the test AND,
The backlog is approved and demonstrated to the customer and they accept it.
You can define your own DOD to close the sprint by doing sprint review and sprint retrospective. In the next post, I will discuss what you will do in Sprint Review and Sprint Retrospective. Put a comment, if you have a question!
One of the most critical activities by the development team in Scrum is ordering the product backlog into sprint backlog. As you know, the product backlog is a user story that developed by the product owner based on the interaction between the product owner and the customer. When product backlog is agreed between customer and the product owner. The product backlog will be stored in a 'place' where the development team can take it and put it on a sprint. A product backlog should be estimated, prioritized, and refined first before putting into a sprint. You can read the estimating method on this post Estimating Product Backlog in Azure DevOps (ridilabs.net). Estimating product backlog gives the information about the size of the product backlog. However, it doesn't give any information about the order of the product backlog. To do that, we need to do several steps such as:
Estimating the product backlog effort size. For example, "as a admin I can set role the employee so that each employee will align with the department and job description". After the discussion, we conclude the 13 points.
Converting the points into a duration. This approach will convert the points into the duration of each point. We name it as velocity. Velocity unit is hours/point. Therefore, the duration will be effort size (points) x velocity (hours/points). The velocity can be obtained from the
Machine learning / prediction of the length. The idea is grabbing a lot of project data and find the similarity between product backlogs and project types. This can be used for anyone who want to get prediction of the duration
Historical analysis. The idea is using the history of the team based on similar project. This can be done of you already have similar project.
Finding the relation of the product backlog. There are two types of relation
Depend on. Profile page depends on the registration page.
Is a dependent of. Registration page is a dependent of profile
After that you can short the product backlog based on dependency for example. You can create matrix of dependency
The higher depend on means you should consider build the product backlog later
The higher dependent of means you should consider build the product sooner
After the ordering you can combine the ordering with the priority. The highest priority should be developed first. If many of the product backlog has many similar priorities try to pick the easiest one.
Now you can split the product backlog into sprint backlog. The idea is to deliver value. So, you can combine two product backlogs into one sprint in order to deliver a value. For example. One sprint length is defined as three product backlogs that have equal in 25 points. The three product backlogs have same value for example: registration, profile, and activation. It has 25 points. If each point equals with 8 hours. It means the sprint length will be 25 points x 8 hours / point. Or 200 hours. You can convert into days when you need to.
Some Research agenda
How to define the velocity in cold start
How to define the sprint length
How to order the product backlog in a sprint
Building custom solution for a customer is challenging. The most challenging part in building custom solution is change requirements. We already know, there is no stable requirements. Every requirement that customer said can be replaced, changed, or added. In requirements engineering, a way to make requirements stable is by doing requirements managements. In this article, we will discuss what requirements management is and how to make sure it can be worked in the requirements that we already developed.
Requirements Management
Requirement management is part of requirement engineering. As we know, requirement management consists of two components. The first one is requirement development as a technique to obtain requirements. The second one is requirement management a way to make sure the requirements can fulfill expectation without sacrificing the development teams. The detail of requirement management can be read here What is Requirements Management | IBM
Although the principle is similar, requirement management can be different in Agile environment. In Agile environment, the requirement management is not structured as in the formal one. The product owner or product manager should handle the requirements management in daily basis. There are several principles that will be adopted in Agile environment.
medianet_width = "600";
medianet_height = "250";
medianet_crid = "858385152";
medianet_versionId = "3111299";
There is always 'version zero'. The user story should have version zero. Initial version that will be modified and changes. The team should discuss with the customer for the initial version of user story.
There should be regular meeting with the customer on each iteration. The regular meeting should be happened at least weekly.
There should be a proof of concept (POC). The POC can be viewed by the customer to validate the requirements. Ideally the POC should be sent after a week of regular meeting. The customer can say go or not go based on the POC.
There should be acceptance test that can be tested based the tester or customer to validate the requirements.
There should be unit test for the user story that 'complex' enough to validate and can be done automatically.
There should be a versioning of the user story. This is to make sure changes is documented and logged.
Requirements Changes does not mean it should change!
In agile environment, it is said that the requirements will be changed, and you should manage it. I recommend you to read Agile Requirements Change Management (agilemodeling.com). And here are the quick tips.
When changes happen, do a discussion with the team. What the impact of the changes.
When there is an impact, there will be additional work of solution. On this stage, choose which solution that can be done by the team with two considerations.
Perfection of offered solution.
Least of work solution
The development team chooses which offer that will be given to the customer.
The product owner / product manager will tell the customer about the changes and the 'additional' work and budget.
If the customer agrees, the product owner will add the changes of the user story into the next iteration / sprint.
Â
medianet_width = "600";
medianet_height = "250";
medianet_crid = "858385152";
medianet_versionId = "3111299";
Agile is a current software process that is believed to be a solution to build a software. On this article, we discuss how to build a software that implemented Agile and DevOps. For the real example, we will use azure DevOps and eXtreme Programming (XP). Let us get started:
#1 Creating a DevOps project
After the project is agreed and the contract is raised, the team can start to create a DevOps project. They should do:
Choose the process template (in this case we choose Agile). You can learn step by step here Create a project - Azure DevOps | Microsoft Docs
Invite your development teams, product owner, and others stakeholder.
Set the iteration path. You can learn step by step here Define iteration paths and configure team iterations - Azure Boards | Microsoft Docs
Preparing the development environment. You can deploy the development infrastructure in Azure and connecting to your DevOps. You can connect by using service hooks.
You use Azure Service Manager if you connect with Azure Subscription that SAME
with your Active Directory.
You use Azure Classic if you connect with Azure Subscription that different with your Azure Active Directory.
You can use Terraform If you want to publish your solution to Amazon AWS.
Creating initial project with Visual Studio and push it into GitHub or Azure DevOps.
medianet_width = "600";
medianet_height = "250";
medianet_crid = "858385152";
medianet_versionId = "3111299";
#2 Composing the user stories.
This step is a casual XP based requirement engineering technique.
Creating features,
Defining the actor or persona
Creating user stories, https://youtu.be/2Qj3x1RnqHA
Creating iteration plan with user stories deliverables
Discussing the features, user story, and iteration plan with the customer
#3 Designing the Solution.
You start this step by creating a mockup for your design. You can start with.
Creating information architecture (IA). You can create the IA with Mindmap software such as MindManager or XMind.
Create low fidelity prototype. You cab create with your pencil & paper or user wireframe tool like PowerPoint or Balsamiq.
Discussing the low fidelity and IA with the customer
Creating high fidelity with Visual Studio or Visual Studio Codes.
Uploading and presenting the High-fidelity prototype to customer
#4 Developing the Solution.
This step can be the longest step in the project. This is because the solution is developed through one or more of iteration. Of course, this step is executed iteratively.
Since we are using XP, the development team (tester) should create a test suite, test plan, and test case. You can see the video here https://youtu.be/0GKPguP4qLU
The developer should create unit test in Visual Studio.
The developer should create the codes to fulfill the user story.
The developer will commit and check-in daily to the repositories.
The CI/CD process will deliver the nightly build.
The iteration review will be happened in two stages.
Internal play testing – with the development team.
Customer play testing – with the costumer
Revising and getting feedback from the customer or from the defect.
Iteration retrospective with the development team and others. It discusses how to improve the next iteration of the development such as:
How we communicate with the customer
What we need to change in the next iteration
How the development progress so far
Deploying the solution for the iteration.
Continuing to the other iteration
#5 Implementing the solution.
After the entire iteration is finished, it is a good time to implement and to finish the solution.
Confirming the customer that the solution is appropriate to be deployed.
After the confirmation, the development team can create documentation such as:
User manual
Developer manual (optional)
Doing several workshops to socialize the system.
Gathering the feedback for continuous improvement.
Ready for the next improvement and for the next project.
medianet_width = "600";
medianet_height = "250";
medianet_crid = "858385152";
medianet_versionId = "3111299";
So our business analyst ready to kick off a project. the real question is what should we do in release planning session. A session where we start the project for the first time. On this article, we will discuss the main activity in release planning. the activities follow the eXtreme Programming method. Let's get started
Writing Story
The business analyst should write user story as comprehensive as possible. the business analyst will create
set features. i.e. Registration Feature
user story i.e. as a member i can register through social media account so that i dont need to fill basic information
acceptance criteria i.e. member should have at least first name, last name, organization, and email
Estimate the Story
The business analyst should elaborate with the customer to do several things
Validating the user story with the customer
Detailing the user story and acceptance criteria with the customer
Estimating the story point with the development team
Creating the release plan
The business analyst will do several activity to make the plan is solid
Discussing the story depedency with the developer
Discussing the story priority with the customer
Creating iteration plan that contain user story
Stabilzing the release plan
The business analyst should understand that the story will be changed. Therefore, the business analyst should stabilising the plan by doing several activities
iteration review with the customer / weekly progress with the customer
documenting feedback based on the review
reviewieng the changes into updated story
discussing the detail of the story with the task with software development team
medianet_width = "600";
medianet_height = "250";
medianet_crid = "858385152";
medianet_versionId = "3111299";
Programming is a challenging task. You need to focus, to solve a problem, and to create a solution for problem. There are so many ways to do programming. In Agile environment, programming can be done through three ways. Solo programming, Pair Programming, and Mob Programming. This article will discuss when you choose one compare to the others.
Solo (all in one)
This is just like a song from Katty Perry featuring Clean Bandit. Solo! Solo means you do by yourself. You did plan, do, codes, and test activities. The solo great when
Project is simple and less complexity.
Less external dependencies and stakeholders.
Limited user experience
Benefits of solo programming are:
Faster in development
Codes are understandable.
Easy to manage.
Challenge in solo programming is:
Limited design principles applied during the development process.
Exhausted and bored
Undocumented codes
You can learn more here The Personal Software Process (PSP) (cmu.edu)
medianet_width = "600";
medianet_height = "250";
medianet_crid = "858385152";
medianet_versionId = "3111299";
Pair (~2 developers in same role)
Pair is a couple way to do programming activity. Pair programming is great when.
Pair is available with different skills and knowledge.
Pair is great when face-to-face communication.
Pair is great when we have same role in a team.
Benefits of pair programming are:
Well-design product two head is better than one.
Transfer knowledge happens.
Shared ownership of the codes. The pair knows the codes.
Challenge in pair programming is:
Slow down the productivity.
Hard to implement in distributed environments (e.g., different time zones)
Suitability of pair person.
You can learn more about pair programming here On Pair Programming (martinfowler.com)
Mob (> 2 members in different role)
Mob is more than two peoples work together. Mob is great when.
Having members with different skillset
Having a good workspace to work together.
Having a jell team with good communication model.
Benefits of mob programming
Project understandability is the highest among the team members.
Validation and verification happen between members.
Near real time feedback model to shape the well-designed project
Challenge in mob programming
Specific infrastructure is needed.
The communication between members should be fluid between team members.
Limited productivity when the others work while the others only see the process.
You can learn mob programming here Mob Programming Basics – Mob Programming
So which one you prefer as your programming style? Put a comment please.
Â
Â
medianet_width = "600";
medianet_height = "250";
medianet_crid = "858385152";
medianet_versionId = "3111299";