Tag: agile

Categories
Tips

10 Minute Comprehensive Guide on Modern Software Development with Agile Methods

Modern software development with agile methods

When it comes to custom software development, Agile methodology is preferred because it focuses on the requirement of the customer and fast delivery.  The principles are applied to small software products developed by a single team, as well as big ones developed by programs that consist of more than ten teams.

The goal of any software development company today, as well as the clientele, is producing software at the lowest cost possible, in the shortest time and the best quality. The right planning and management of the development process and the correct methodology are critical to achieve your business goal. The Agile Methodology is a growing trend that’s exponentially growing.

Agile methodologies have helped many business organizations respond to the evolving market conditions fast, boost customer satisfaction, and boost efficiency. Still, so many organizations are facing hardships in comprehending and adopting Agile. For your brand to overcome the challenges, let’s check out an extensive guide explaining everything about modern software development with Agile methods.

Who is this Guide for?

This guide is intended for:

✔ anyone who wants to learn all the ins and outs of the agile methodologies

✔ anyone who seeks out knowledge on what agile is and why it’s monstrously awesome

✔ anyone who’s afraid of adapting the methodologies in their next software project

Your Comprehensive Modern Software Development with Agile

An Overview

Most of you probably already know that Agile has taken the world of software development and testing by storm. The majority of organizations are already practicing the software development methodology in some form. Agile, in simplest terms, is a way of managing projects.

It’s worth noting that although the approach could be used for just about anything, it was nonetheless founded originally in India. Unlike the Waterfall approach in which all the requirements are gathered from the start, and design is all done next, and then development is executed, the Agile method enables designers, developers, analysts, and stakeholders to work together simultaneously.

Traditional Waterfall Approach Limitations

The Waterfall Model was presented first by Winston Royce back in 1970, and it was intended to be used in developing government projects. It was called a waterfall because of its cascading activities with phases, which keep the development process going forward. Because of this nature, the model does not leave room for doing unexpected changes.

Making changes would be difficult and demands a lot of work as well as a waste of money and precious time. Furthermore, it also excludes the client from the project because its focus is mainly on the internal team. Today, clients want to be involved in the development process as much as possible, and since the Waterfall Model pays so little attention to the client involvement, this could mean high change requests in the development later on.

Agile—How it Works

In contrast to the traditional Waterfall Method, Agile Methodologies adhere to the iterative approach. Basically, Agile software development involves several cycles, typically called ‘sprints,’ which are individually designed, developed, and tested. To put it simply, consider every sprint as a miniature project with its own phases of design, backlog, development, testing, and deployment within a predefined work scope.

A possibly deliverable product is shipped at the end of every sprint. Simply, with the completion of each iteration, new features are being added to the main software, resulting in software growth.

Agile Misapprehensions

Even though Agile has been majorly adopted all over the world, still there remain misconceptions about the approach, including the following:

1. It’s very different

Agile could be an entirely new concept to your organization and the entire team. It also demands a bit of rewiring regarding how all stakeholders would remain on the same page during development. Nevertheless, all companies that adopt the methodology know that the new approach runs the entire development cycle smoothly and consistently.

2. It’s unpredictable

It could indeed be unpredictable at times. But it’s the same with other development approaches. Honestly, it’s entirely impossible to determine what the software should be at the start of the development exactly.

Nonetheless, unlike the traditional approach, Agile embraces unpredictability and uses it to its own advantage that leads to producing better outputs.

3. All features are prioritized by developers

There are still some people who believe that with Agile, developers decide what’s relevant, what must be implemented, and when. However, this is far from the truth since, at the start of every sprint, there is always an extensive spring meeting in which all stakeholders get to participate and decide the features that would be developed and delivered.

4. More short-term-focused

It’s hard to understand why, but some still believe that since the Agile approach splits up projects into short sprints or iterations, it doesn’t consider the long-term goals. The Agile methodology, in truth, provides a lot more benefits and provides a better way than the traditional one. Furthermore, earlier testing lets you indirectly make better decisions for your long-term goals.

5. Works only for Software and Developers

Indeed, it started out in the tech industry, but today, as it benefits an organization as a whole, it’s widely accepted even in non-software industries, such as in the field of communication, manufacturing, healthcare, and so on.

The Actual Benefits of the Agile Methodology

Today, a software development company uses the Agile methodology to stay competitive. Majority of clients anywhere in the world demand that their software solutions be developed using the methodology. Why? Because of the many benefits that it brings to the table. Check out these benefits.

1. Business Value Concentration

One of the major benefits of Agile is an increased concentration of focus on the delivery of strategic business value through the involvement of business stakeholders in the process. With this, the development team understands what matters most and could deliver the features that provide the most value to the brand.

2. Enhanced Quality

Another of the great benefits of Agile is the improved quality of a product. By dividing projects into manageable units, the team could focus on high-quality software development, high-quality testing, and collaboration. Moreover, by creating frequent builds and doing reviews and testing on every iteration, quality is enhanced by quickly finding and fixing defects, as well as determining mismatches in the expectation early on.

3. Engagement of Stakeholders

Agile provides numerous opportunities for the engagement of the stakeholders and the team before, during, and after every sprint. Through involving various stakeholders each step of the way, there’s a higher collaboration degree between teams. The team will have more opportunities to genuinely understand the vision of a business, early delivery of working software, and boosts stakeholders’ trust often.

4. Predictable and Early Delivery

By using fixed, time-boxed Sprints of 1-4 weeks’ schedule, new features are quickly and frequently delivered, with a high predictability level. Also, this provides a chance to beta test or release software earlier than planned if there’s enough business value.

5. Enables Change

Unlike the Waterfall method, one of the key benefits of Agile is that it enables change. While the team has to remain focused on delivering an agreed-to subset of product features on every iteration, there’s a chance to refine and reprioritize the overall product backlog in a constant manner. Changed or new backlogs could be planned for the next iteration, providing a chance to introduce changes in a few weeks.

6. Transparency

Clients are involved throughout the software development project. This could include prioritizing iteration planning, features, review sessions, or frequent software builds that contain new features. This nonetheless requires the customers to understand that they’re looking at a work in progress in exchange for the added transparency benefit.

7. Predictable Schedule and Costs

Since each Sprint is a fixed duration, the cost is predictable and restricted to the amount of work that could be done by the team in a fixed-schedule time box. Together with the estimates given before every Sprint, the company could easily understand the approximate cost of every feature, which boosts decision making about prioritizing the features, and the need for more iterations.

Popular Agile Methods

Every organization differs, and so the internal and external factors that they face. Therefore, to meet the different organization requirements, let’s check out a couple of the most popular Agile methods. Which methodology works for you best would depend entirely on your internal and external factors.

Scrum

It’s a popular agile management method focusing on defining the major features and its objectives at the start of each sprint. Putting it simply, Scrum was introduced to minimize the overall risk in software development while providing faster value as well. Basically, it begins with the story or requirements, explaining how the particular features should work and should be tested.

Some of the most popular Scrum tools that help in increasing the teams’ productivity level are – Jira, Nutcache, monday.com, and ClickUp.  To manage teams & projects following Scrum methodology, you can choose monday.com. While on the other hand, Jira can also be your best choice for project management and creating customized work reports.

Benefits of Using Scrum Methodology

  • Increase in project visibility
  • Manage different priorities
  • Effective usage of money & time

Kanban

Originally, Kanban was developed by Toyota because of their need to boost factory productivity. It’s a very seamless, Agile methodology that could be defined as a prioritized, big to-do list. The requirements in Kanban, just like Scrum, are monitored by their present status as well, including in development, to-do, in a test, and delivery. 

Kanban tools offer the best services to software developers and project managers. They provide Kanban boards for the development teams. These tools are – Scrumwise, Kanbanery, Volerro, and Planview LeanKit.

Benefits of Using Kanban Methodology

  • Increases efficiency & productivity
  • Reduces work time
  • Continuous delivery approach

Lean Development

The Lean development methodology is created by Toyota and is used for the software development process. It offers conceptual frameworks and principles that enable software developers to apply the Agile development approach to their projects. This methodology’s seven essential principles are – quality development, differing commitments, fast delivery, deleting things that are not important, optimization, and respecting the team. 

Lean development offers some fantastic tools like Kaizen, Value Stream Mapping, 5S, and Focus PDCA. These tools enable the teams to improve efficiency and production levels.

Benefits of Using Lean Development Methodology

  • Strengthens knowledge
  • Optimizes value-stream
  • Eliminates delay in engineering  

Extreme Programming (XP)

Extreme programming is another very popular Agile development framework used by software development companies for various dimensions. This methodology follows the values like – simplicity, courage, respect, feedback, and communication to provide a perfect solution to the customers and satisfy them. The teams following XP methodology for their projects can choose any tool from – Project Planning & Tracking System, ExtremePlanner, and Targetprocess. Besides this, if you are a Java developer, you can select any tool from – JUnit, Maven & AntHill, and Cactus. For the .Net developers, the options are – NUnit and NAnt.

Benefits of Using XP Methodology

  • Increases product quality
  • Early product delivery
  • Empowers the team

Crystal

Crystal is a methodology that comes with different variations like Crystal Red, Crystal Orange, Crystal Yellow, and Crystal Clear. These variations specify the number of team members working on a project. It has a different range from 8 to 1000 (Clear to Red). Crystal methodology works on principles like – skills, community, talent, communication, and interactions. 

Benefits of Using Crystal Methodology

  • Flexible
  • Fewer team members required
  • Fixed-rate contract

Conclusion

Evidence reveals that the Agile methodology is very effective in modern software development these days. For most business organizations, the business and people’s results make the methodology well worth the effort.

Categories
Tools

An Agile Software World

agile software

Since the emergence of the first agile software development methods more than 20 years ago, development teams around the world have undergone a significant cultural shift. The traditional waterfall approach to running software projects sequentially has been gradually replaced by iterative project management styles. This has enabled organisations of all sizes to scale successfully by remaining resilient in a business environment full of uncertainties. Agile methodology appears to be transforming companies across sectors, but is it really the dominant trend in the software industry nowadays? And if it is, which particular implementations of agile are the most widely used by developers?

 

To gain more insight into the above questions, we asked 11,700+ developers in our latest Developer Economics survey about the project management methodologies they follow in software development. The data we collected provides clear evidence that agile is indeed the most commonly adopted practice in the software industry.

Agile project management

Agile is an umbrella term used for processes like Scrum and Kanban that emphasise short release cycles, rapid response to changing requirements and continuous improvement through regular customer feedback, as described in the Agile manifesto of 2001. According to our survey data, more than half (58%) of developers say they follow a project management methodology that can be classified as agile.

By comparison, the once ruling waterfall methodology is currently used by only 15% of developers. Waterfall’s biggest advantage, i.e. its sequential approach, is also its greatest limitation: in projects where the goals are not clear from the beginning and requirements change continuously, waterfall fails to adapt and deliver results quickly.

 

SCRUM IS LEADING THE AGILE REVOLUTION

Scrum was conceived in the mid 1990s as a response to the shortcomings of waterfall and is now the most popular project management methodology, followed by 37% of developers. As a framework that puts the core principles of agile into practice, Scrum enables teams to break down large, complex projects into a series of smaller iterations (or sprints) and ship high quality products faster and more frequently.

Kanban is another prominent agile project management framework, although its popularity is significantly lower – nearly half of Scrum’s (20% vs 37%). The two methodologies share some of the same core values but have very different implementations. Most notably, Kanban is lighter on structure as it’s not constrained by fixed-length iterations, but instead it prioritises continuous delivery of work to customers (even multiple times per day) as long as the capacity of the team permits it.

Only 6% of developers blend the concepts of Scrum and Kanban into Scrumban, indicating that agile hybrids are not common. Agile-waterfall hybrids, in contrast, are the second most popular choice for developers (21%). This is most likely a sign that many organisations remain skeptical towards agile development and prefer a slower transition to it by mixing some of the less controversial agile techniques with the traditional waterfall method.

Other well-established frameworks such as Feature-driven development (FDS), Extreme programming (XP) and Lean are used by about 10% of developers, whereas Adaptive software development (ASD) and Dynamic systems development method (DSDM) – both outgrowths of the early Rapid application development method – appeal to more niche audiences. Interestingly 23% of developers don’t use any specific methodology in their projects, although – as one may expect – it’s mostly amateurs who do so (40%) and to a much lesser extent professionals (17%). Another 19% of developers (18% of professionals) do not follow any specific project management process for some of their side projects, which in most cases are hobby endeavours.

Our data reveals that developers tend to follow multiple methodologies across their projects (2.7 on average), with Scrum being the most frequently co-used framework along with other methodologies. This implies that Scrum often acts as a “touch point” for development teams landing on the world of agile or as a starting choice before transitioning to less structured agile processes. For example, 66% of developers using Kanban and 57% using XP also use Scrum, as opposed to only 36% and 13% of Scrum followers also using Kanban and XP, respectively. Among developers following the waterfall model, more than 40% also use either Scrum or an agile-waterfall hybrid (like Scrummerfall) while the adoption of any other framework is below 25%. It seems that Scrum’s simplicity, clearly defined roles and timeboxed nature attract development teams who want a smoother transition from traditional waterfall to more flexible approaches.

Agile_Software_World

You can read the latest full State of the Developer Nation report here, and help shape the trends by taking the 18th Developer Economics survey here

 

Categories
Business

How We Learned to Built Hardware, the Agile way

I ‘m part of a hardware research group at Telefónica Digital called “Physical Internet Lab”. Three years ago we started a small group under the Emerging Technologies area of the company focusing on the Internet of Things. The commitment of the group was (and is), in ambitious terms, “to democratize the Internet of Things” opening it to as many makers, developers and users as possible. Our goal has been not entirely altruistic: Telefónica as a network operator has a lot of value to add in the Internet of Things economy.

On day to day basis we build prototypes and products, usually connected objects or components like the Thinking Things building blocks.

Setting up the lab three years ago was no easy task. We wanted to work at the crossroads of the Internet, the Things and the People. But our development skills were almost 100% software related. In the process we built a team skilled on all three sides. And we figured out how to do agile hardware.

agile-hardware

Of Agility and Hardware

We ‘ve come full circle. Telefónica I+D (the Telefonica Digital development branch) was created 25 years ago to produce hardware innovations such as X.25 and ATM switches. We did that in the classical engineering fashion: writing long and rigid lists of requirements, splitting the work across solution providers, integrating and then testing following a waterfall schema.

Over time Telefónica I+D adapted quickly to the technology changes and by the mid-nineties we were developing mostly software. First we followed the same engineering process; then we moved towards more iterative methods. In the last 10 years we have adapted fully to agile methodologies.

As we were building the laboratory we found ourselves getting back to hardware. But the company now could not understand a slow-moving unit. The lab had to be agile. So we had to bring agile methodologies to hardware development.

The first difficulties came with the corporate facilities. Hardware work demands physical proximity and we could not afford to have a distributed team depending on collaboration tools on the Internet. At the same time, soldering fumes or drilling noises were not welcome in our modern, bright, open spaces. So the team had to move to a closed office in an old building in Madrid city center.

Moving to the city center was a boon: in minutes we could reach many shops and services, buying anything from hammers to plastic boxes. Visitors now found it easier to visit us in a centric garage-like office. This was great for our open approach as we wanted to help and interact with other companies and organizations.

Purchasing tools was another problem. The corporate procedures were tuned for large-scale purchases such as server farms or external services. Buying a handful of resistors for 10 euros could take several weeks, creating bottlenecks to our work. Fortunately the purchasing department showed a great deal of sensibility. We worked together to redesign the process. Now we buy any component or tool in a single day while still working by the book.

Putting together the Agile team

Hardware work implies multiple teams across several companies with extremely specialized profiles. When setting up the lab we opted for a small and autonomous team, able to build a hardware prototype with no external dependencies.

A small team allows us to work closely integrated, in the same location, continuously coordinating our work. A small team also means that budgets are smaller and is well suited to experimenting, failing, learning and adapting.

Basic agile methodologies such as Scrum expect some degree of overlap between the specializations of team members, so that different people can execute the same tasks naturally balancing the work load. But hardware work is different. It demands a lot of specialization. In our case most of the tasks can be executed only by one team member. As a result, the Scrum methods and tools have to be modified to reflect this reality.

Our internal workflow follows many steps. The first step is the Industrial Designer, a role which is somewhat of a novelty in the Telefonica Digital payroll. Carlos (that’s his name) starts his work in the CAD station designing the physical product: plastic pieces, metal straps, cloth, magnets. Then he builds the design using the currently available 3D prototyping tools such as the laser cutter, the CNC tool (i.e. a computer controlled drill) and a variety of 3D printers. These tools give much flavor to the lab.

In some cases we start from an existing object that we hack so that we can explain a new concept. Carlos at the same time designs and builds, which is a bit out of his job profile. Software developers are multi-taskers, too – they design and type, while software architects can also code. In the hardware industry this is somewhat unusual and typical engineers expect someone else to physically build what they have created. In the lab we follow the software philosophy. It is leaner, and gives the designer a real feel of the piece or circuit construction. This approach demands some tolerance and patience from engineers who have to get their hands dirty.

The same philosophy applies to the next step in the workflow: the electronics engineering part. The electronics engineer first designs new circuits, then prototypes them. We even design and build the PCBs to check that everything fits in place.

The agile doctrine underlines the importance of early user testing. Early use provides rapid feedback focusing the most important characteristics of the product and showing what isn’t relevant for customers. To shorten the time-to-test we use 3D printing and prototyping technologies.

In electronics engineering we massively use Open Hardware. Open Hardware gives us access to lots of ready-to-use designs that we can employ in product testing. In a sense, Open Hardware behaves now like Linux and Open Software in the mid-nineties. It allows us to focus on the real technical or design challenge rather than reinventing the wheel for every test.

Electronics and physical design teams work side by side, so they can verify in real time how components fit in the same object. Our objects become more than simple plastic boxes, as they are tightly coupled with the internal electronics.

Electronics engineers work also with the firmware developers. The firmware developers write the code for the embedded microprocessors. They also have to deal with connectivity issues and power management.

In our Physical Internet Lab, electronics and firmware engineers work side by side. In most situations knowing what will firmware do simplifies hardware design. Similarly, software developers can ask for fine changes in the hardware designs nearly in real time.

On the other side of firmware sits backend development. In our typical systems architecture, distributed devices communicate with a backend service in the cloud. We push as much intelligence as possible to the backend service, so our designs can evolve without touching the deployed hardware or executing firmware updates. We like to think that the back-end gives every object nearly infinite computing power and knowledge, as it can interact with any other Internet service.

Again back-end and firmware developers work side by side. This tight collaboration resolves any integration problems before they appear, and encourages electronics and firmware developers to take issues to the more powerful (and more agile) back-end platforms.

The final technical step is the front-end development, usually based on web and native apps. Again we do a lot of work locally in the lab, well integrated across the team.
The frontend is also tested in complete end-to-end scenarios. Automatic testing tools execute scripts that run against the firmware and the frontend.

And of course, there is a Quality Assurance side. We are extending continuous integration, test driven development and automatic testing to the embedded firmware. At the same time we have to handle more hardware specific tasks such as sensor calibration, assuring robustness and strength.

Physical Interaction Design

The web/application interface and physical design are the two endpoints of the “development chain” of our group. They form the two interfaces exposed to the final user. At the final part of our workflow, the physical interaction designer, works with both web / app and physical design.

The physical interaction designer is responsible for the design of the connected object as a whole. He takes care of building a single object with a coherent interaction model in the physical world and in the Internet.

Without the physical interaction designer we would have to separately design the physical object and the application or web interface. The result would be a split-personality product, usually an amalgamation of data stuck on top of a square box. The physical interaction designer combines the capabilities of the physical object and the Internet interface in a coherent manner.

Physical interaction design, bringing together the Internet and physical objects is a completely new field. There are a handful of specialized schools in the world, and we are working too with UX designers with strong industrial design background.

Everyday physical objects have usually long stories and designs optimized through centuries of use. We still have a lot to learn on how to take the Internet beyond of the smartphone/tablet/PC onto this physical object world. Customers will not adopt Internet of Things devices if they are a step behind of the design standards they have become accustomed in software interfaces.

Agility plays a role here, once again. Developing and prototyping quickly we can try interaction designs with users, test our assumptions and build a sizeable bunch of knowledge around user interaction with connected objects.

External providers

Of course we have to work with external providers, especially when dealing with complex technologies or industrialization. For development we often use online services for as PCB manufacturing or 3D printing. They are extremely easy to use, robust, fast, and offer a direct web interface instead of long negotiations with a salesperson.

For the final manufacturing we interact with real, serious manufacturers. Agile, as a software development doctrine has no solutions to this task. But Agile can be seen as a spin-off of Lean philosophy, which was created to deal specifically with manufacturing issues.

One of the main lessons from the Lean methods is that service providers have to be tightly integrated in the business process. We have found this is very important also for us. The lab has spent considerable efforts building trust relationships with service providers and manufacturers, integrating their teams with the lab. Schedules and plans are shared under an openness philosophy. We have established even real time communication so their teams get continuous feedback from the engineers in the lab.

The future of agile hardware

We have yet a long way to create a truly Agile Hardware lab. Physical work is sometimes slower than software development. Some other times (especially when prototyping on Open Hardware designs) they are blindingly fast and have to pause and wait for software components. Speed differences keep the group working on different “user stories” at the same time.

External dependences are many, and the lab will never be, in that sense, completely autonomous. But we can find yet faster service providers and build leaner and more integrated workflows with them.

Regarding Quality Assurance we have to handle correctly the physical device characterization and fit the expensive and slow certifications in the product workflow.
The bright side is that Agile methodologies provide and require continuous improvement. Every sprint or work cycle forces us to learn and adapt our methodology and organization, looking for a better process. Perhaps in a couple of years we’ll have a completely different process in a completely different lab, and it will be all right.