How do you share your system development progress with others?

At the start of a software delivery project, I often create a document called "Vision and Scope" to get everyone on the same page. Ideally, this should be written in non-technical language, so that it can be shared with team members, stakeholders or potential future app users, alike. It will include elements of the business case/background context, and reasons for the app. Explain the high-level features and the likely user roles of the app. Also, visualise user journeys, process flows and UI mock-ups. Then listing or linking to high-level requirements and maybe touch upon the technical architecture. Outline the project team, approach, timescales etc. It's best to keep this document short and informative, but readable.

At the start, pick one goal and work towards it. Many attempts of system development fail due to overwhelming initial scope which makes it harder to pick a good starting point and adds unnecessary confusion about imagined dependencies and conflicts which don’t actually exist yet. You don’t finish a marathon by jumping from start to finish, you do it one step at the time. Pick a goal, realistic one; move towards it; pick another one only when you reach the last one. Avoid stacking topics to “remove roadblocks”. If you hit a wall this means the original goal was not that realistic as you imagined. Often going back and picking a new, more achievable goal works better - which should be easy and fast because you’re trying to make small steps.

- Modular approach, starting from outside then to inside, starting from the core functionalities and then drilling down to the details in the later stage. - Define a complete user customer journey flow or a closed cycled business logic flow. Split out multiple parallel features if needed. - Discuss, clarify, and synthesize requirements, problems, and solutions in documented communications. - Repeat this ongoing process until a solution design document and a project roadmap timeline can be made. - Strictly allocate enough time for each SDLC phase in each agile iteration. Do not overlook QA and testing. Do not leave room for useless activities outside of SDLC (large requirement scope change, programmer over code reviewing).

Usually Jira is used to track software progress. Keep a record and backup of the software. Work closely with the quality analyst and customers for the software quality. Create SOP for the functioning and maintenance. Try to use software monitoring tools like AppD for health checks.

In my experience, the two most important components are developing the business requirements and creating the system architecture. - Business requirements are the foundation of the project; they define what needs to be achieved and what goal needs to be achieved. - Creating a system architecture, in turn, helps determine how the project will be realized technically. - It is in this interplay of business requirements and system architecture that the foundations of the project are laid. It allows you to create a clear vision, define a strategy and develop an action plan to achieve your goals.

One of the things I find helpful about Scrum is the Sprint Review. By iteratively showing our clients and stakeholders our progress, the easier my team and I were able to pivot in another direction when needed, something that couldn't be easily done with the waterfall model.

I want to second the Sprint Retrospective as a beneficial way to bring the current status to the stakeholders and the team as a whole and provide a forum for questions and comments

- Do not let formality overtake its fundamental purposes. Agile is meant to get the work done, fast, efficiently, high quality, while adapting to ever-evolving complex business software product requirements. - Strictly following Agile methodologies simply means planning, executing, delivering, and then retrospectively reviewing the process to either maintain high quality, and high efficiency or improve. - Requirements need to be 70% complete if not 100% at the time of starting implementation, the remaining 30% is either missing details or decisions can be decided and implemented quickly. - Unexpected out-of-scope discoveries need to be deferred for later iterations. If can't choose a temporary solution, then don't use Agile.

I agree. What’s important to remember is that agile manifesto was a very brief, intentionally vague and accessible piece of text. Focus on practicing manifesto tenants first. Don’t spend too much time on tools, and rituals which (some claim) are supposed to help you be agile. Yes, because you “ARE agile”, not “do agile”. So read the manifesto. And then read it again. And then start every week with reading it again. The “soul” of agile is adaptation to change. Your understanding of the manifesto will change. Your methods and tools used for being agile will change. You will change. After you realize and accept that, read the manifesto again.

Agile, particularly Scrum, I've seen work well on Software delivery projects. I remember being told, years ago, that some companies "Are Agile" but many, just "Do Agile". What this means, in reality, is to implement a version or flavour of Agile that works for your company, even if that means strengthening or relaxing some principles, to get that to work. Keep it simple and agree on something that works to benefit you, rather than hinder you. You can still adapt it as your organisation grows or becomes ready for more. If you get that balance right, it is a methodology that will support you and your team in delivering some quality work, planning ahead, showing progress and, most importantly, knowing when to stop delivering!

Documentation should never be required to read. It should be accessible and helpful when it is needed. This means it needs to be up to date, well structured and organized, tailored in the context of whatever it is documenting. Different audiences will need documentation for different things so you will need different kinds of documentation. You can keep documentation in multiple separate, independent parts, as long as they are kept in sync and reference each other in respect to their area of concern. As important as documenting “how” and “what”, is documenting “why”. Often answering “why”, might make explaining “how” or “what” unnecessary.

- If trying to do a good job building and delivering high-quality software systems, then document everything, requirement documents, solution design documents, architectural design and diagrams, tricky implementation documentation, and user manual documentation. Good documentation makes the systems look and feel like the original developer never existed. - If it's a large crap system with nothing, then don't bother, rebuild it.

I think on any development project, it's always better to write and collate documentation, as you go and when it is still fresh in the mind. Leaving this to the end of a project often leads to gaps in knowledge, things forgotten or not recorded quite as accurately as they would have been earlier. Not to mention, the additional load and effort this creates, when you are trying to launch your new application, support it, or encourage user adoption. Having documentation written as-you-go, also helps onboard new team members who join, mid-project. There are many tools available to do this. I've always found Confluence to meet my needs in this area and it is collaborative and accessible enough, such that the whole team can contribute.

When I work on a task I provide updates when anything changes. I document what I did and what my plans are going forward, including timelines. If something happens to me, the next in line will know exactly where I left off. If something is wrong with my work, someone will know exactly what I did. Documenting work is meant to allow managers and others the opportunity to evaluate the progress of the work and help out when necessary. I can't tell you how many times I've seen an update on a task come through my inbox and have been able to provide support to another developer. Likewise, I've had tasks where my manager or another developer has stepped in with helpful insight.

There are several great products out there, each equally good in this area, including Trello, Slack, Monday etc. Jira has worked well for me in recording everything from User Stories and Acceptance Criteria, to linking stories to mock-ups in Invision or Figma. Prioritisation and estimation of work, release and sprint planning and ultimately, allocation work and recording/visualising progress. It integrates well with other platforms you may be using, too. In terms of meeting and presenting, MS Teams, Zoom, PowerPoint, all work great. Nothing beats the team all being in the same room, at the start of or during a project, though.

Contar com um bom plano para o desenvolvimento da equipe é essencial. Muitos desenvolvedores precisam de treinamentos para desenvolver melhor seus conhecimentos e implantar melhores soluções.

For me, three good areas in these circumstances are, as follows. Firstly, stakeholder showcases or demos at the end of sprints are invaluable for showing progress, getting feedback and understanding any minor course corrections that may be needed. Secondly, never forget the observations and inputs of your amazing QA analysts. Their input will be invaluable and any bugs or UX issues which they record, perhaps needing re-work, will help identify current progress and status, in real terms. Lastly, consider Sprint Retrospectives with the delivery and development team members. The 4Ls format, I've found to be fabulous. Liked, Learned, Lacked and Longed For. The team's observations and suggestions should never be underestimated.

I set a cross-functional Scrum team with defined roles and responsibilities, to create a prioritized Product Backlog with features, user stories, and tasks, and making sure my team conducts sprint planning meetings, hold daily stand-up meetings for progress updates and obstacle discussions, execute the sprint with the development team | QA etc.. and facilitate obstacle removal. We conduct sprint review meetings to showcase done work to stakeholders while collecting feedback and making necessary adjustments to the Product Backlog. We conduct a retrospective meeting to discuss improvements and action items. At last i would suggest to keep stakeholders informed through regular driven communication channels such as slack, teams etc.

Sharing system development progress can be done through regular status updates, detailed project documentation, and collaborative tools like program/product management software. I also use Notion. I love the user experience. Providing clear milestones, roadmaps, and holding regular meetings can also keep stakeholders informed.