To-Do Or Not To-Do In Agile
Nowadays it becomes clear that teams and managers are starting to think more dynamically and they want to be more flexible and adaptable. They realized that Waterfall lacks those capabilities, besides that they clearly see how the customer started to be uncomfortable with the outputs and the results of the projects. Starting from spending a lot of time analyzing, planning, setting the milestones, discussing the budgets, and preparing the different communication channels, to the long and expensive process of implementation. After that comes the delivery., and at that critical point, the customer says “It is not what I wanted?!”.
Here comes the time to find a way to be more productive and proactive by moving to a methodology like Agile. Starting to prepare the app as usable doses, dealing with the customer as a part of the team, and showing more flexibility to changes and new needs.
Many best practices and experiences about agile management have been built over the years it came from trying and failing and success stories. So let’s explore the do and the don’ts and understand how we can lead this process.
I am going to do a projection of these points on the life cycle of the agile management stages:
Concept: Projects are envisioned and prioritized
Do: There are 5 levels of agile planning, you should make sure that all planning levels align with each other’s and all are serving the main vision and goals of the company. Even the daily meetings and actions should be aligned with your goals. analyzing the projects’ feasibility and ROI is an important factor to decide the order of the projects.
Don’t: Be aware of the environment of the organization and the existing working style that taking place in everyday work, is the vision clear on the top management do they share it with all the units, do we have awareness of where are we going. Besides that, don’t waste your time on building intensive plans, there are so many estimation tools and techniques that will help you to like MoSCoW and Kano.
Inception: Team members are identified, funding is put in place, and initial environments and requirements are discussed
Do: The main resources (hard and soft) should be clearly identified and aligned with the timeline of the project. After that you have a clear image of the amount of the needed fund and when you will need it. You should be aware that “fail to plan is a plan to fail”, and agile does not mean there is no need to plan because we are ready to change always!. It is easy to lose control of the boundaries of your project, so even if you are using agile it is so important to create the scope chart and scope statement of your project and always keep an eye on scope creep.
Don’t: The main difference between waterfall and agile is that in the waterfall you will prepare an extensive analysis on the other hand in agile you will make a minimum analysis to get a general image of what to do without making a bottom-up analysis that contains all the details instead of that you will use gross-level estimation technique to build your time frame. You should be careful not to ignore the role of the team in the estimation because they are the force who will execute the project, creating a plane and putting it in front of them to follow is a bad idea, and creating a plan without the minimum level of information and details is even worse.
Iteration/Construction: The development team works to deliver working software based on iteration requirements and feedback
Requirements: Define the requirements for the iteration based on the product backlog, sprint backlog, customer and stakeholder feedback
Do: Make sure that the backlog contains all the stories that you will need to complete the project, the functional and non-functional requirements are important, and the most important the definition of done without it you will never understand when and how the story will finish
Don’t: Defining the stockholders is so important and defining the product owner role that will contact them to read their needs and transfer them to the team is so important. The PO role should be defined as early as possible, so he will get used to the system and be involved in the early stages of the planning and even creating the vision of the project.
Development: Design and develop software based on defined requirements
Do: Always verify that your requirements didn’t change and if this happened it should happen under the control of change and risk management. Recalculation of the budget and the time is important, also controlling the quality by using some methods, for example, the XP tools like pair programming and TDD are so useful and will save you a lot of time in the future.
Don’t: There is a general norm that in agile we should start coding as soon as possible and starts showing a working product. Don’t be in hurry! Sequence, activity, and class diagrams will help you to find the mistaken or missed points in your application, so don’t underestimate the power of these tools while you are designing the system.
Testing: QA (Quality Assurance) testing, internal and external training, documentation development
Do: Testing is so important and as much as you make it automated you will save time for testing and retesting after every change. There should be a responsibility for controlling the quality of the code, UX.UI and the process as a whole to make it is following the generally defined standards of the project. And as much as you create clearly contained user manuals and support videos and sites to show the tricks and tips of your system this will show the power of your system and save your time for required training sessions.
Don’t: As we follow agile we create the minimum documentation but it does not mean that you will never create it because you are in hurry and there is not enough time. Using tools to manage agile projects like Jira for example and creating clear and will define stories also break those stories into logically and clear tasks that contain full details, notes, comments, and uploaded documents is a big part of your documentation.
Delivery: Integrate and deliver the working iteration into production
Do: Using CI/CD tools and systems in different development environments is so handy cause after building your scripts and agents for building and deployment you can concentrate more on the development process and create nonstop deployment services. Especially in iteration-type development like agile which contains a change requirement and produces worked outcomes every sprint.
Don’t: Deployment in an old lazy fashion like using copy-paste will waste a lot of your time and you can’t track what had been deployed to which machine and when happened and what errors immerged and who queued that process. Don’t also waste time trying to build your own tools for deploying there are so many open source and cheap tools that you can use.
Feedback: Accept customer and stakeholder feedback and work it into the requirements of the next iteration
Do: No matter how you are trying to build a system according to the customer needs there would need to change something remove and add another thing, after all, it is the main idea of being agile. As soon as you get this feedback early and in a clear way and add it to the system to be done in the next iterations, the customer will feel that you are creating exactly what he needs and will trust you more when he sees what he wanted in a clear way in the system.
Don’t: Don’t lose your customers’ trust by letting them wait too much to get what they wanted, and differently don’t lie, then you will lose everything. To begin agile is to make the customer part of the team and partner to work with showing him what are you trying, it is normal to fail sometimes, don’t hide it, be clear and ask him to help you, you are both in the same team.
Release: QA (Quality Assurance) testing, internal and external training, documentation development, and final release of the iteration into production
Do: Same as in the delivery of the sprints, be in good control of the system in all of the stages of the release process. Create separate environments for development, testing, pre-production, and production.
Don’t: after you created separate documentation and user manuals for all the sprints, don’t forget to put the final touch to classify them to create a final workbook. Don’t try to test the whole application manually, use TDD to be ready to test deeply any part anytime you want.
Production: Ongoing support of the software
DO: Tracking of the running system and getting all the notes of the performance of the system, the needed enhancements, errors, and problems in systematic ways and move them to a tracking system like Kanban board then starting prioritizing them and handling them is so important and shows the maturity level of your business.
Don’t: The lifecycle of the system does not end here, at this point a new system is coming to life and another chapter of the story is starting here, when you are going to production make sure that the whole team are sharing this step, developers, testers, analyst and else. It is not a step for developers only, everyone should support them, cause the core idea of agile is to be a team.
Retirement: the system could come to the of his life for many reasons like it is not cost-effective anymore or it needs so many updates and fixes or a new version will be used.
Do: Get the best practices and lessons learned from the old system document it and share it with the organization to be a guide for future applications, keep the code in the archive and make sure that the old system is closed in the most proper way.
Don’t: There is much effort spent to build the old system and at a period of time in the past, it was working, be careful that you didn’t leave any sensitive data or information there, beside that moving to the new system could be dangerous, no matter how you tested the new system, there could be a need to rollback to the old system if a killing fatal problem happened in the new system even after weeks from going online, always create a backup plan to rollback.
After all, there is something that should be clear to you, there are no fixed rules about what to do and what not to do, there are general best practices to follow. Every company has its’ different conditions, and under these conditions, every organization should create its’ own checklist and always review and control it and even update it. By the time everything changes and we should be flexible and ready to adapt.
