I believe that this quote can perfectly relate to the thought that I would like to express in this blog post about estimation in Agile. To some extent I feel that Agile nature also reflects the same behavior that you should be at-least at the edge of right instead of totally wrong, with respect to either decision making or estimation.
Here I would like to focus on Estimation, which is a very crucial part in every project. Agile has changed the concept of estimation. In traditional software development methodology, management used to estimate the project whereas in Agile, team together does the estimation of a project. Agile has introduced simple techniques for estimation – Planning poker and T-shirt sizing.
Planning pokertechnique has made estimations more simpler and less pressurized. Team generally uses
Fibonacci series as story points. Agile promotes standard Fibonacci series like 0 1/2 1 2 3 5 8 13 20… Fibonacci series looks like a progress bar growing from lower to higher range in terms of three factors:
Risk, Effort(not in terms of hours or days- it should be relative comparison of efforts with every user story) and Complexity.
While estimating user stories on the basis of these three factors, team makes sure to consider development, QA, Research and all other dependent tasks. All this estimation activity is done during the backlog refinement meeting.
From the bunch of user stories provided by the product owner (PO) for estimation, team first selects the easiest user story to start with and assign story points to it. Every person in the team show his/her story points for that user story. In case of differing opinions for story points between team members, they come up for discussion and present their view points for selecting that particular story point number. After discussing that user story from all the aspects team re-votes for that user story and keeps repeating the same process until all the team members converge on the same story point number, effectively agreeing on the scope and impact. And this way it becomes the benchmark for other user stories.
After analyzing the easiest user story team starts picking up the user stories from top to bottom
considering they were arranged priority wise by the Product Owner. And team finishes discussion on all those bunch of user stories given by PO. This way team ends up allocating the story points to all the user stories.
Velocity- After the team is done with estimation, during sprint planning the team decides how many story points they can pick during this sprint. Like wise team increases or decreases the story points in further sprints till they come up with the number of story points team is comfortable in picking up for the sprint. And from the experience, team keeps on improving their estimates. After two or three sprints average of story points can be considered as the velocity of the team which can be directly related to the performance of the team.
T-Shirt sizing – This is almost similar to planning poker but the only difference is instead of Fibonacci series team take sizes of t-shirts for estimation like XS, S, M, L,XL. Rest of the method of picking-up the sizes is same as in planning poker.
Team discussion on every user stories and PO presence in backlog refinement tremendously helps the team in understanding the requirements much better. Each individual’s input is important to make the estimation better and help in understanding the requirement correctly.
P.S- You can install the free “Scrum Poker” application from application stores for Android, iOS and windows smart phone which provides virtual story point cards for estimations.
A recent report by Computereconomics found that in the 2018/19 period, the application development process has emerged as the one witnessing maximum outsourcing opportunity – with 56% of the organizations around the world outsourcing their development requirements.
The reason behind this heightened demand for outsourcing the mobile app development needs has been the same as always – Lower cost than what would have to be shelled out if employing own country developers, allowing greater focus on the main business, and better service quality.
However, even with outsourcing taking a central place in the application development industry, we have found that there are some common concerns that the clients show when they plan to outsource their software development project outside their geographical nation.
In this article, we will look into how Appinventiv works with offshore clients using the distributed agile development cycle allowing a more connected working process with aligned risk and remuneration model across all.
But before we get on to the part where we tell how we operate as the distributed team of our clients and work so seamlessly that we become their extended in-house tech team, it is important to know what Distributed Agile Team even means.
What Do We Mean by Distributed Agile Team
A distributed team is a concept used to explain the event where two or more team function across multiple geographical locations instead of one office space or even two office spaces in one city. The distributed agile team relies on digital technologies to interact seamlessly and work together toward the same goal – Timely project delivery.
Why do Businesses Invest in a Mobile App Development Distributed Team?
There are a number of reasons that drive businesses to invest in distributed teams, reasons ranging from:
The scarcity of skilled developers in their nation
The need to test the market before an investment is made towards team buildup
To avail the benefit of the flexible team which can be increased at the time of scaling the app and dissolved when the need ends.
With the definition and the need now attended to, let us now look at how Appinventiv team works as a distributed team of our clients. But before we jump there, let us quickly look at what our typical distributed agile team structure looks like –
Appinventiv Approach to Distributed Agile Development
Many a time we get a project where the requirement entails us to work in close connection with the clients’ FTEs. In such instances, it becomes very important that we don’t let the distance in thousand miles come between work and that we are able to make changes and take action on developmental process in real time.
How we ensure timely delivery without zero scopes of communication lag and misunderstanding is a question whose answer lies in Distributed Agile Methodology.
Fit with both small-scale and large-scale businesses, following distributed agile best practices comes in very handy when we have to work alongside a team that is sitting in some other geographical location with an absolutely different time zone.
Let us look at the Distributed Agile Development Method we apply in our mobile app development process.
After we have introduced all the team members with each other and have collaborated the project management software, the actual work starts.
We formulate the process of daily agile scrum methodology. While in its traditional sense, Scrum requires face to face standup meeting of 15 mins where every participant shares the status of their tasks and informs the team of the tasks they will be taking up next, it is nearly impossible to follow the same process when half of the team is sitting in some other geographical nation in some other time zone.
What we do to keep the essence of face to face interaction alive in the scrum, is we hold a video call on one decided time, which is suited for everyone in the team working on the project. With the help of screen sharing our Agile Scrum Master runs through virtual sprint backlog with the help of tools like Trello or Jira, enabling every team member to give an update on where the project is headed.
What we have experienced is that it is very important to give all the team members an access to a task tracking platform that is easily accessible and updatable. We also emphasize using a communication platform like Skype or Slack for everyone to share updates or ask their doubts between the two scrum time periods.
Another approach that we follow for daily agile and scrum process is that for every different scrum, we appoint one scrum master. So, every individual teamwork as a separate scrum team with a scrum master and product owner – A process which is also known as Scrum of Scrums.
In this, all the scrum representatives provide an answer to the following questions in the scrum –
The work that team has completed since last Scrum of Scrums
The work team is planning to do before the next Scrum of Scrums meeting
The present blocker that the team is facing
The blocker that can lead to another Scrum team.
The method enables all the main individuals working on the project to interact with each other directly, something that always results in dedication from the initiation stage to launch period. This ensures an open, clear, and transparent communication between all the teams, where everyone is given a voice. The process apart from scrum of scrums is the same as what we follow under the typical Agile methodology. But the mere fact that the distance between our team and our clients’ team is miles apart and yet we have to work as seamlessly as possible, has brought a series of learnings that we have driven by the adoption of Distributed Agile. Let us look at what those learnings are –
The Learnings That we Drew by Working on Distributed Agile Development Process
1. Creation of Distributed team is about Building a Culture and Not a Process
What defines the success of a project working under the agile for distributed teams approach is not dependent on how well skilled the team members are, but on how well they are able to work together, the sense of ownership with which they work, and ultimately how closely aligned they are with the goal of the project – something that comes with culture and not a process formation.
2.Only SMART Projects Succeed
When a project has to be completed by a team that is not even in the same country let alone office, it is very important that the goals that you have set for the project follow the SMART – Specific, Measurable, Achievable, Realistic, and Time-framed, concept to the t.
3. There is no Alternate to Online Collaboration Tools
No matter how much it costs you, you will have to rely on online collaboration tools that are real-time and have minimal to zero lags. In terms of finalizing the online project management and communication platforms, you can not in anyway cut slack. You will have to ensure that they are technically capable of handling your requirements.
Now that we have seen the learnings that we have drawn from our extensive working experience as a distributed team, it is time to look at some of the challenges that we came across during the process and how we solved them to become a trusted Distributed Agile App Development Company.
Challenges with Distributed Agile Development Approach and How we Solve Them
1. Difference in Culture
Usually distributed agile software development approach ask for working with teams coming from different cultural backgrounds. This difference causes friction because of different values and figure of speech. Our Solution: We work very closely with the client’s team in the initial few days so that we get accustomed to their between the lines and contexts.
2. A Difference in Time Zones
The crux of distributed agile methodology is teams working out of different geographical nations. In a situation like this, the occurrence of a communication gap emerging because of the time difference is very common. Our Solution: We follow the concept of agile for a distributed team to its core. We fix a time when the teams from all the nations are present and active. To achieve full focus and attention, we ask our teammates to change their office timing on the scrum day, so that they are well slept and attentive.
3. Lack of a Common Idea of ‘Big Picture’
Because of a difference in geographical location, working structure, and policies, there can be a discrepancy in the idea of the Big Picture – the end aim of the mobile app. This difference might cause a lack of interest from some team members and a heightened interest from others. Our Solution: A visioning meeting at the start of the project initiation and a reminder in every scrum, so that everyone is working towards the same goal.
4. An absence of Code Ownership
The absence of collective code ownership means that no one person owns the code, it is owned by the whole team and so when something goes wrong, the blame game starts. Our Solution: We apply a version control system to check who is working on a code and when and the effect of it. This way, there is complete transparency and honesty in the picture.
Two things that define today’s startup ecosystem are innovation and speed to market. If you’ve a unique idea and if you can get to the market fast, before everyone else, chances are your product will be a success. I don’t imply that these are the only two things that matter. But they play an important role in defining product success.
While some may argue that innovation and speed to market don’t go hand in hand, I heartily disagree. Agile project management is one of the ways that allows innovation without compromising on the delivery timelines.
I have been an agile practitioner for nearly a decade now. I’ve worked in different kinds of projects with different SDLC methodologies. Among them, I find Agile to be one of the best methodologies for project development. Especially in managing those projects where new solutions are required to meet rapidly changing customer needs.
Let me share an example. One of our partners, Phritz, began their journey in December 2019. They started building a personal health record chatbot. At that time, they envisioned the chatbot to behave like a personal healthcare assistant that users can chat with anytime. The chatbot would even help users when they change doctors or health insurance.
However, as COVID-19 pandemic started spreading, we began to think of ways in which Phritz could offer extended support. There was a lot of hysteria among people regarding the information available about the virus. We began by thinking of ways to offer a feature in the chatbot where users could add their symptoms and the chatbot would offer answers. For instance, if you have a sore throat, the bot would give advice to take necessary medications. However, if you’ve sore throat, cold, and fever, the bot would suggest you to get a COVID test. If your test comes out to be positive, the bot also offers to inform people whom you’ve met in the past one week.
Another example is from one of my recent projects. Our partners wanted to go for HIPAA compliance and secure all the protected health information (PHI) in the project. Securing PHI is an essential in a healthcare setup, so it’s critical to get this step right. This involved creating non-functional stories for securing PHI requirements, ensuring that it covers what has already been built and what will be built in upcoming features.
Since the stakeholders were in full gear with their marketing strategies and were getting the product familiar with the public, it was important for them to get the product to be HIPAA compliant faster.
With Agile, it was easier to accommodate this new requirement. In the Waterfall way, our stakeholders couldn’t have thought about implementing this until upon reaching the first milestone.
Implementing agile not only helped us in accommodating the PHI requirements but also helped us with process improvements and clear communication with stakeholders.
These examples show that agile development helps in incremental development of the product– one that conforms to the needs of the users and solves their problems.
Agile can be beneficial to implement in healthcare projects under the below scenarios as well–
When you’re not sure about the entire solution
All great products are built on ideas that first appear on a piece of paper. It’s not necessary to flesh out an idea completely before jumping in to develop it. Strategy and execution are important but getting to the market fast is more important.
In such cases, agile development helps in validating the idea. You can start with just a goal in mind. Something that’s specific and measurable. For example: “The claim management software will reduce the claims processing time by 70% and improve efficiency of providers by 90%”
Once you develop a solution to this problem, put it out in the market and get customers to use it. After they start using it, collect feedback from them and improve your solution as per their needs.
When you’re navigating a complex domain
The world of healthcare is constantly shifting and innovating. Therefore, if you’re in the race to build the best product, it would no longer help you win. Instead, you ought to focus on innovating in the services, and improving the customer experience of the product.
One of the best examples is Practo. Before the COVID-19 pandemic, Practo was subliminally known as an online consultation and medicine delivery platform. When the pandemic striked, they quickly pivoted as a telemedicine solution. Within a short span of four weeks, Practo created an ‘Artificial Intelligence’ tool that guided patients after collecting their basic information. The tool leveraged WHO protocols to profile high-risk people by asking them to share their travel and contact history.
This is just one of the many examples. In other healthcare products, you might be dealing with other regulatory guidelines like HIPAA. They make healthcare a complex domain. But with agile development, you can tackle them one at a time.
When there are multiple stakeholders/decision-makers
Healthcare product development might involve many stakeholders and decision makers. Each stakeholder might have a different perspective and goals for the product’s adoption in the market. This might cause a lot of feedback cycles that go in loops and a lot of incremental changes in the product’s features.
Agile teams are equipped to take up new changes, prioritize the needs of all stakeholders, and help you stay on track with rapidly changing requirements.
When you want to improve quality and reduce costs
In healthcare products, there is an unwavering focus on doing things quickly and shipping out features for the world to use and give feedback. Innovation matters the most, along with agility. But funding is limited and you can’t wrap yourself under the garb of innovation. Therefore, features must be rapidly tested. The focus is on failing fast and adapting to the users’ feedback.
In this scenario, agile proves to be the best method. The 2-week/4-week sprint works best in shipping out features that can be tested with the real users.
When product’s scope is variable
In the waterfall approach of product development, the scope of the project is fixed while team members and time can be varied. That is, if you’re halfway through a project when you realize you’re going to miss the timelines, then you either add more team members or extend the timelines. This increases the cost of development and causes delays in reaching the market.
One of the best things about agile development is that here time and people (team members) are fixed whereas the scope can vary as per requirements. It means that once the scope is defined, it’s not the dead-end of discovery.
If after the first sprint’s release you get feedback for adding/removing/improvising features, agile accommodates it. It might impact your final deadlines, but it would still be somewhat near to what you had planned.
Some other advantages of agile teams is that they are more capable of making day-to-day decisions, independently. With a defined and structured process, they can also thrive in different geographical areas.
However, the agile processes are not easy to imbibe. Ceremonies like backlog grooming, sprint planning, need a lot of discipline to execute. I learnt it on the job with the help of my leaders. If you’re a new product manager, I would suggest you to read some good books on agile project management. The Lean Startup by Eric Ries and Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days are two of my favorite books that can help you get married to the idea of agile development.
Mobile device users are rapidly becoming the user’s favored instruments of choice for browsing the Internet. With market leaders centering on providing customers with exceptional user experiences, we are now seeing a rapid rise in consumer expectations, which compels, including the innovation of the mobile experiences you offer. Just implementing a mobile-first approach isn’t sufficient anymore. While your users may make-do with a responsive website in the early period, a shift to mobile apps provides you substantial leverage over your contemporaries. The key to successful mobile applications isn’t just limited to excellent design and continuous development. The development teams need to speed up the delivery of benefits that mobile apps offer to users. Implementation of the agile procedure, adopting a DevOps strategy, and making a move to the microservices model of creating a cloud-based application gives you a unique business advantage. Microservices enable the development teams to own the entire project development cycle. It provides much-needed flexibility in mobile app development services. Teams can work upon the data collected from users to incorporate changes within the app components on a real-time basis resulting in the DevOps procedure becoming more dynamic and the development teams more agile.
Flexible integration and code creation suit rapidly changing, customer-facing apps, which pushes businesses to evaluate microservices for mobile applications. Microservices in mobile application development boost modularization — breaking the architecture apart into independent services and groups of services. With services lined up around business function and still secluded from each other, developers can deliver the quick updates and recent feature releases that mobile users expect. Since microservices communicate via APIs, mobile application developers can opt for the most appropriate technology stack and language for each service or business flow, instead of limiting the entire project to one. However, microservices aren’t the only way to business mobile app development. Low-code platforms also tout a simple procedure to build mobile apps.
What are Microservices?
Microservices architecture is an essential architectural innovation that is a useful alternative for building complicated software applications. It involves the fragmentation of large applications into loosely coupled smaller services. Each microservice focuses on separate business functionality. Every microservice can be independently deployed, tweaked with, and redeployed without compromising the application integrity — the loose combination of microservices lead to the facilitation of rapid deployments. The features build as a result of user feedback, thus quickly reach the users.
How do microservices differ from conventional development practices?
In the conventional monolithic app architecture, designs all the constituents of the code as a single, cohesive unit in which the constituents are independent and interconnected. Any updates the developers require to make results in alterations made to the whole stack. Adopting a new framework or shifting to a new tech stack needs a substantial overhaul and rewriting of the entire code. In contrast, microservices architecture has the system distributed into individual services that can run as autonomous processes and communicate with each other, utilizing APIs. Containerization enables the encapsulation of the services, and operations run in parallel, thereby making the existing infrastructure easy to maintain. Any changes or updates performed on individual services without affecting the entire system.
Benefits of microservices architecture in app development
Improved productivity and agility
Microservices are made, deployed, and tested individually of other components in the system, which results in enhanced team agility and rapid iteration cycles. The developers have the elasticity to use the framework or language most appropriate for the functionality developed; this ramps up productivity by radically reducing the amount of code to be written. It also increases the maintainability of the application. Breaking down complex apps into manageable services improves the performance of agile teams.
Accelerated velocity and scalability
Scaling of various microservices components at runtime takes place individually; this facilitates more productive resource utilization. We can shift the workload of an element to an infrastructure that is best suited for the task. Microservices offer accelerated development speed combined with on-demand scalability. The flexibility of the cloud-native environments can be effortlessly leveraged by the microservices making scaling cost-effective through optimal use of infrastructural resources. Microservices also ensures that the application is more responsive to market requirements. The agile methodology enables you to roll out robust digital capabilities in response to real-time market requirements.
Continuous deployment
In conventional monolithic systems, dedicated teams work on distinct functions. The introduction of microservices leads to cross-functional teams managing the complete application lifecycle in a continuous delivery model. With various team members, including testers, developers, and operations teams working simultaneously on a development testing, single service and debugging takes place in continual iterations. The incremental development results in a constant cycle which writes, tests, and deploys the code consistently while incorporating relevant feedback.
The rise in cross-functional teams
Carrying out software development and deployment could be a tedious job when, while working with extended teams. Microservices result in improved independence for the developer. They can work independently, resulting in faster decision making. The cross-functional teams in microservices architecture consist of empowered individuals who can make faster decisions. Working in smaller groups and close-knit teams result in more freedom to the individual team members and quicker technical decision making.
Flexibility in utilizing technologies and access to a broader talent pool
Since each developed microservice can be written using different technology, the development team is free to opt for the tech stack that would be most suitable for the specific service. Decoupled services written in various programming languages can easily coexist, add new components continuously, and perform scaling at an individual level. The flexibility that microservices offer also enables you access to a broader talent pool.
Summary
While the business profits of shifting to a microservices architecture are huge, the transformation needs to be sensibly monitored and strategically implemented. Implementing a DevOps culture, with robust monitoring is essential for an effective shift to the microservices architecture. The ramp in flexibility and speed has to balance with an associated increase in complexity.
