Loading...

Agile Estimation Techniques and Innovative Approaches to Software Process Improvement.

Innovative Agile Development and Estimation Techniques, Process and Productivity Improvement in Agile Software Development with Process Libraries.

Agile practices have rapidly taken hold in software development organizations. But little has been said about how these same practices can be applied to IT operations. an IT team who is struggling to keep up with the rapidly changing demands of their day to day work and learn how the simple application of a few Agile techniques can help them get back on top of their workload as well as function better as a team.

One concern for creating a process description is that software developers do not usually follow the process to search and create knowledge required to develop and improve their activities. There are two types of knowledge leading the software development process: knowledge acquired through experience (known as tacit knowledge), and the technical knowledge stored in documents (known as explicit knowledge).

Currently, agile methods are replacing traditional process-based methods in the software industry. However, process-based software development still matters because of its degree of reusability in new projects. Some problems arise when Knowledge Management (KM) is not correctly aligned with processes, such as lack of productivity and process improvement.

Our research was identified as action research, hence, our research goals were defined and focused on improvement and productivity. Moreover, our implementation process was based on the suggested spiral case study process. The spiral process represents the actors who perform their corresponding activity, such as: setting scope and goals, data collection, data analysis and results, and corrective actions taken. Our collaboration scheme for data collection and filtering can be seen in below. Researchers can interchange ideas, suggestions and instructions with the technical leader and, in turn, the technical leader with the development team and the QA leader for project coaching, and with the customer to meet their expectations of user stories. Finally, researchers and the technical leader can save the project data in a Annanta Source, LLC repository.


Collaboration scheme for data collection

Customizing Your Team Workflow with the Best of Kanban and Scrum

Let's start with the team. A team size and its structure can be an important factor in making your decision about methodology to be used. Kanban does not prescribe any roles but you can establish them if you want. Kanban is well suited for a great range of team sizes. For example, if you have a team of three people Kanban is a good choice. As well as being good for micro-sized teams, Kanban can be used for large development teams. In Kanban it is not necessary for a team to be cross-functional; specialists are allowed as well. A Scrum team consists of three roles: product owner, Scrum master, and development team. The optimal team size that is prescribed in Scrum is 7 plus, minus 2; that is between five and nine. The product owner and Scrum master roles are not included in this count unless they also execute the work of the sprint backlog. Development teams in Scrum should be cross-functional, which means that team member need to possess all the skills necessary to successfully complete all the stories from the backlog.

When we say a project type I actually have two types on my mind: new software development and software maintenance. In case of maintenance, we have four categories: corrective, adaptive, perfective, and preventive maintenance. Corrective maintenance can be seen as reactive modification of a software product performed after delivery to correct discovered problems. By adaptive maintenance we mean modification of a software product performed after delivery to keep a software product usable in a changed or changing environment. Perfective maintenance is modification of a software product after delivery to improve performance or maintain ability. And preventive maintenance means modification of a software product after delivery to detect and correct latent faults in the software product before they become effective faults. There is a widely-spread belief that Kanban is only good for maintenance and support. It is true that Kanban shows that best results if you have to maintain software, meaning that Kanban works great for support teams. Still, Kanban can be successfully used for implementation of new features as well. Scrum is best suited for developing new software. Using Scrum in support teams is not impossible, but from our experience it can be extremely challenging. In some cases, it can happen that most of the time you do corrective maintenance. It can mean that you need to fix bugs as they arrive. Usually there is no release date but as soon as the bugs are fixed, the fix is pushed into production.


Daily Meetings

Depending on whether you have a team distributed in different countries and different time zones and depending on whether you want to focus on what each team member did or you are more interested to hear what the status of particular tasks is, you can choose to organize meetings in a Scrum way or more in a Kanban way. Scrum daily standups are used to inspect progress toward the sprint goal. Scrum daily meetings are prescribed to be held every day at the same time. They are time boxed to 15 minutes and only development team members can participate. Every team member needs to give an answer to the following three questions: What did I do yesterday that helped the development team meet the sprint goal? What will I do today to help the development team meet the sprint goal? Do I see any impediment that prevents me or the development team from meeting the sprint goal? A Scrum master is responsible for moderating these meetings, to keep them 15 minutes’ time boxed, and to make sure that follow-up meetings are organized, if necessary.

At Annanta Source, LLC online tools, Admin member identifies that he or she is being blocked, there should be a follow-up meeting where only the relevant team members should participate and where the particular problem will be addressed. Scrum master is also responsible for removing any obstacles. As you can see, Scrum meetings are person-oriented. In Kanban, there is no rule for mandatory daily meetings. On the other had there is also no rule that forbids you to organize them. In Kanban you can organize sure meetings whenever you want, and they can last as long as it is necessary or needed. There is no strict rule that time boxes meetings to 15 minutes. Contrary to Scrum, Kanban daily standups should be board- or cards-oriented. This means that the team members don't have to report one-by-one, answering the three mentioned questions, but the team should discuss cards instead. The best practice is that a team gathers in front of Kanban board to discuss the cards that are ongoing and planned. Also, the teams should check if there are any blocked cards and if they can do anything in order to remove the impediments. The blocked cards should be marked, and if the team can't unblock them immediately, then a team leader or a manager should make sure to remove the obstacles as soon as possible.


Iterations

Having an iterative development enables rapidly-developed working software, which is an increment. This approach allows early and continuous inspection of the increment and the process. In Scrum, iterations are time boxed. Usually they are one to four week sprints, although two weeks is typical. In practice, sprints that are less than one week or more than four weeks long should be avoided as your overall product overcome can suffer. The general idea is to keep the same length of iteration over a period of time. Each iteration in Scrum starts with sprint planning meeting and ends with sprint retrospective, where the progress and lessons learned are reviewed. Scrum team commits to the sprint goals that should be achieved in each iteration. It is not allowed to change stories in an ongoing sprint if that change will endanger a sprint goal in any way.


Metrics and Reporting

Burn-down, burn-up, and cumulative flow diagram are graphical representations that can be used to predict when the work will be completed. Many tools today already have a built-in capability for these three types of charts, diagrams. Burn-down chart tracks work remaining. You can use the X axis to represent your iterations and the Y axis to display story points, task, or story count, or time estimates. Be aware that the time that is used for the chart is not effort spent but effort left. Burn-down charts are preferred for an iteration because of the shorter time and fixed scope. When you analyze a burn-down chart you can see the following situations: Entire work is done before the end of a sprint. This can be an indicator that the team overestimated tasks or that it was a lucky sprint where the team was not interrupted, as usual, which gave them an opportunity to finish all the stories before the deadline.

scrum benefits
  • Delighted Customers

  • Improved returns on Investment

  • Reduced Costs

  • Fast Results

  • confidence to succeed in a complex world

  • more joy

Using the Data to Estimate More Precisely, the concept of the estimation problem and how it is difficult to perform estimates in not just software projects but in everything else. Then we looked at the concept of agile estimation with our introduction to agile estimation learning how it's important to then perform an estimate at the end of every estimation. We dove deep into the mechanics and looked at things like user stories and story points and planning poker, product backlogs and team velocity. Then we started looking at going beyond that and collecting data and using metrics to provide for better estimates.

Our organizations are repeatedly delighting their customers by giving them what they really want, not just the features they might have specified on the first day when they knew the least about their true needs. They are also seeing an improved return on investment by delivering smaller, more frequent releases. And, by relentlessly exposing organizational dysfunction and waste, these organizations are able to reduce costs.