Posts Tagged ‘Agile’
One of the first decisions you need to make before starting a project implementation is: which development methodology should I use? There are different approaches to the software development process. Two of the most popular methods are Waterfall and Agile.
What is Waterfall?
Waterfall is a linear approach to software development. That means that project stages are executed sequentially, and no stage can begin before the previous one is finished. You receive your completed project, fully developed and tested, at the very end of the process.
Pros of Waterfall methodology:
- Simple and easy to understand and use
- Easy to manage due to the rigidity of the model
- Phases are processed and completed one at a time
- Works well for smaller projects where requirements are very well understood
Cons of Waterfall methodology:
- You cannot go back a step; if the design phase has gone wrong, things can get very complicated in the implementation phase
- High amounts of risk and uncertainty
- Not a good model for complex and object-oriented projects
- Poor model for long and on-going projects
- Not suitable for the projects where requirements are at a moderate to high risk of changing
What is Agile?
Agile development, as opposed to waterfall, focuses on building software iteratively. The project is divided into small modules and delivered in weekly or monthly sprints. During each sprint, a certain functional set of features is developed, tested, and delivered to you for evaluation. This approach emphasizes rapid delivery.
Pros of Agile methodology:
- Value is added every sprint
- Easier to add features that are up-to-date with the latest industry developments
- Project priorities are set before every sprint and evaluated after each sprint
- Customer feedback is allowed and will contribute to the final end product
- High level of customer involvement (strong sense of ownership)
- Short time to market: quickly produce a basic version of working software
- Transparency is high
Cons of Agile methodology:
- Projects can run longer than anticipated
- Requires high level commitment of time and energy from developers
What can we conclude from all this? Both methodologies have their own strengths and weaknesses. The choice of methodology really depends on the goals you want to achieve. The key to deciding which is right for you comes down to the context of the project. Is it going to be changing rapidly? If so, choose Agile. Do you know exactly what you need? Good. Then maybe Waterfall is the better option. Or better yet? Consider taking aspects of both methodologies and combining them in order to make the best possible software development process for your project.
Do you use the Waterfall or Agile methodology? Why? Have you ever tried combining the two? How did that work out? Please, tell us below.
For some years, Agile methodologies have been widely adopted within the information technology software world to bring new products and services to market quickly and efficiently, increasingly taking over from more traditional approaches such as ‘waterfall’. While it may have promised much, Agile has not been without its critics, who say that it does not live up to expectations, that users can become too bogged down in the processes and lose sight of the end goal. They also fear Agile projects become siloed into teams, rather than being visible to the organisation as a whole.
However, as an increasing number of companies are finding, Agile CAN deliver on expectations, if some simple principles are followed: what might be called “pragmatic agile”. Supporting tools also have a role, such as SCM (software configuration management). SCM can help ensure that a project remains visible to all the key stakeholders, while supporting Agile-related tactics such as Scrum.
So exactly what is Agile? First introduced in the late 90s, Agile methods are well established in the software development world as tools to accelerate time-to-market. They aim to emphasise the items on the left below, while still appreciating the value of the items on the right:
– Individuals and interaction – over processes and tools
– Working software (or product) – over comprehensive documentation
– Customer collaboration – over contract negotiation
– Responding to change – over following a plan
Taking these elements individually, let’s look at what they mean in practice.
Individuals and interactions – over processes and tools
This does not mean that there is not a place for processes and tools – of course, there has to be – but Agile is very much about people communicating with each other, ideally verbally and not just via email. A common communications element of Agile methods are daily meetings, or “stand-ups,” to review the current status of a project and to iron out issues before they escalate. In Scrum processes (see later), planning meetings provide an environment in which to understand requirements of the backlog and how to address them with collective support on the effort required. This approach helps to engender more creative thinking, because people have an environment within which they can safely suggest ideas.
So given this environment, how might tools provide support? As an example, a strong SCM system is invaluable in two ways. First, it provides visibility into how all the work fits together to deliver a working product. Second, it allows features to be developed in parallel across Scrum teams, or to move changes between sprints if work has not been completed as expected.
Working software (or product) – over comprehensive documentation
Whatever the project – whether in mainstream IT, games development or embedded software design – all too often, projects can become unwieldy, with the temptation to ‘over engineer’ and lose sight of the original goal and deadlines. Agile encourages teams to maintain focus on the outcome. This can mean delivering a working version of the software that may not have 100 percent of the features originally planned, but the product still has usable functionality. A central tenet of Agile is to take an iterative approach: it is more effective to deliver a product early and then continue to improve, rather than delay time to market.
One common Agile method is Scrum. Scrum is an iterative and incremental Agile software development framework for managing software projects and product or application development. Here’s a quick overview of the Scrum framework from the Scrum Alliance:
A Product Owner creates a prioritised wish list called a product backlog. The Product Owner is a proxy for the customer when determining features and priorities.
During sprint planning, the team pulls a small chunk from the top of that wish list, a sprint backlog, and decides how to implement those pieces.
The team has a certain amount of time, a sprint, to complete its work – usually two to four weeks – but meets each day to assess its progress (daily scrum).
Along the way, the Scrum Master keeps the team focused on its goal.
At the end of the sprint, the work should be potentially shippable, as in ready to hand to a customer, put on a store shelf, or show to a stakeholder.
The sprint ends with a sprint review and retrospective.
As the next sprint begins, the team chooses another chunk of the product backlog and begins working again
Customer collaboration over contract negotiation
In this context, customers can be internal colleagues, not just external. In any design process, there is always a danger that once a brief is agreed, the team then goes away and develops the prototype, only to find that it no longer meets the requirements of the ‘customer’. An Agile approach includes regular communication with the customer, to get his or her ‘buy-in’, so that once the product is developed, they know what to expect and have been involved throughout the development process. This can mean working with non-technical colleagues, perhaps in the product marketing department, on a level not experienced before.
Responding to change – over following a plan
Of course, solid planning is usually essential, however within that framework, Agile prescribes that it is important to be able to respond to change and be flexible. After all, when a project can take months or years to deliver, it is not surprising when market or customer requirements change.
Some deadlines, like manufacturing lead times, are hard stops in the schedule. Does that mean the project can’t respond to changing requirements? Quite the opposite. It means that, until the project hits that deadline, the team has to be as Agile as possible, embracing continuous delivery principles.
Agile – how SCM helps get it right
So far so good, but Agile can – and does – go wrong. Here are three pain points that organisations typically face and how version management (or software configuration management) system can help:
Latency – while the intention may be there, in practice it is easier said than done to prevent delays. One of the biggest bottlenecks can be retrieving source files from a repository or opening in dynamic views. Continuous integration (CI) can help address this, by ensuring that the software works at all times, not just as it is being released.
Far-flung teams – this is one that Agile didn’t see coming, at least at first. The movement emphasised co-location and collaborative programming, with daily-stand up meetings and shared workspaces. However, thanks to outsourcing, the need for differently skilled teams, particularly when building hardware and software products, and high-speed connectivity, vastly distributed development is now commonplace. Again, SCM can help support this, enabling distributed teams to keep track of what has happened and what is happening, collaborate with colleagues, but carry on working on their own projects.
Varied workflows – during the development process, multiple teams will be involved working on different elements and each team may have its own workflows. For example, the process used by the software development team is likely to be different to that used by the documentation team and the hardware design team. These teams will also be working on very different asset types – source code text files, large binary files for hardware designs or documentation PDFs. The best SCM systems should be able to handle all the different content types and workflows such that all teams work the way they want to and have visibility in all parts of the project.
Agile lessons from the games industry
The game development industry hit a number of the same roadblocks, yet many have been very successful with Agile methods, not least Perforce customers. Game developers are successful with Perforce because the tool actually increases collaboration and communication: a key Agile principle. SCM – or version management – lets the entire team, no matter the discipline, store and work with their data in a common repository.
Hardware engineers can manage their huge design files, while firmware engineers can work with their driver code, and the software developers can of course participate fully. Each team can work semi-independently, yet still make their work visible and useful to the rest of the shop early on. For example, a firmware engineer can always load the latest approved hardware simulator designs for testing.
Given that the cross-functional teams may not be at the same location and may use very different schedules and workflow, it is important to build communication into the tools and processes. The SCM system should lend itself to modern task management techniques, like task branching and pull requests. These processes improve quality and build communication into the way the organisation works.
Time to market has never been a more critical element of product development than it is today. Ensuring that products fit customer demand is what makes products profitable. Agile methods, particularly Scrum, offer a chance to address both challenges. A strong SCM tool is required to enable distributed, multi-skilled teams to fully exploit the promise of Agile methods.
There is no doubt that 2012 will be another big year for BI and information management. In the article we`ve tried to gather what we suppose are the top BI trends for near future
Big Data → Need for Speed
The rise in volume (amount of data), velocity (speed of data) and variety (range of data) gives way to new architectures that no longer only collect and store but actually use data: on-demand or real-time BI architectures will replaces traditional datawarehouses. Successful business intelligence projects will need to consider Big Data as part of their data landscape for the value that it delivers. More and more organizations will look toward statistics and data mining to set strategic direction and gain greater insights to stay ahead of the pack.At the same time the BI user is expecting faster answers from their BI environment disregarding the fact that the size of data is increasing.
Shift from analytical BI to operational BI
Increased adoption of cloud and mobile BI encourage individuals to access their KPI dashboards (key performance indicators), more often. An operational dashboard works much like a car’s dashboard. As you drive, you monitor metrics that indicate the current performance of your vehicle and make adjustments accordingly. When the speed-limit changes, you check your speedometer and slow down, or when you see you are out of gas you pull over and fill-up. Likewise, an operational dashboard allows you to make tactical decisions based on current performance, whether it is chasing a red-hot lead or ordering an out-of-stock product.
Latest surveys showed that only 25% of employees in businesses that adopted BI had access to that tool. And that is not because they didn`t want to or didn`t need information, but because traditional BI tools have been too bulky and technical for that other 75% of employees to use.
As now organizations more and more are adopting cloud and mobile BI dashboards, this situation is likely to change. Business intelligence is heading towards simpler, more straightforward methods and tools..
An Agile approach can be used to incrementally remove operational costs and if deployed correctly, can return great benefits to any organization. Agile provides a streamlined framework for building business intelligence/data warehousing (BIDW) applications that regularly delivers faster results using just a quarter of the developer hours of a traditional waterfall approach.
It allows you to start a project after doing 20 per cent of the requirements and design that deliver 80 per cent of the project’s value. The remaining details are filled in once development is underway and everyone has a good look at what the challenges actually are.
BI going mobile
In a survey conducted by Gartner, it was found that by 2013 one-third of all BI usage will be on a mobile device, such as a smart-phone or tablet. BI users want to access their data anytime and anywhere. This puts a demand on both the backend of any BI solution (like datawarehouse appliances) but also on the frontend where information access and visualization must be possible.
BI going up to the Cloud
As Cloud computing continues to dominate the whole IT landscape, so BI also dominates in the Cloud . Throughout next few years adoption of cloud BI tools will be driven by a number of important factors. First, cloud-based solutions offer the advantage of being relatively simple and convenient to deploy. Second, cloud tools are more easily scalable to provide access to key performance indicators (KPIs) to everyone in your organization, no matter where they are or what device they are using. Lastly, continually improving security measures will put to rest any reservations businesses have with storing their sensitive data in the cloud.
We believe these above enumerated areas will grow over the next few years. Organizations will embrace the Agile approach, utilizing new tools and technologies to decrease delivery times and demonstrate substantial business value. As we put more data into the Cloud, big data will become standard. Data itself will be delivered to satisfy the desires of users, so access from mobile devices will dominate desk-based consumption. The businesses that embrace these new business intelligence trends, and take steps to change and adapt the way data is hosted, analyzed, utilized and delivered, will be the ones that grow and prosper in the near future.
And what are your predictions for the big business intelligence trends in the next few years? Do you agree/disagree with our predictions?
Let’s find out how good can get agile development methodologies, using cloud-based resources
Agile, the great enabler
Agile is a style of software development that places new capabilities right there in the hands of users, as and when they need them, and usually almost just about as rapidly as they need them. It does this by stripping the project requirements down into achievable component parts and then focusing on each part individually, single-mindedly, full of intent, energy and drive. As each part is developed so it becomes‘iteration’; a release of useable software that can be made available to users instantly. And while they start using it then the development team moves onto the next step, the subsequent iteration. At every step of the way there is an overt emphasis on collaboration between developers and users. Nobody goes off behind screens or departmental smokescreens or politics or excuses; everything is transparent to the client and the users. And one of the most magical aspects of all is that no functionality is built in which users are not going to use.
Put Agile together with Cloud and it’s a case of ‘now you don’t see it, now you do’.
Cloud computing, the great provider
Cloud and Agile are suddenly almost synonymous, in IT-speak. Perhaps the best way of summing up the benefits of Agile development methodologies is to refer you to the actual word itself, or the broad definition thereof: able to move quickly, with skill, and control. The Cloud can catalyze the development process. It’s just like the weather, in fact; it’s everywhere. This means that new applications can be made available to users instantly, the very second a development team has completed them. There is no need for drawn out distribution procedures, the risks of down-time thus entailed, patches and reinstallations. Users can jump straight in and start using. Integration issues are overcome, change management is minimized and risks are minimized.
Putting Agile together with Cloud accelerates an organization’s pace of improvement. Bear in mind also that the working style of Agile is very much tied up with user involvement, drawing users’ right into the heart of the development process. Functionality is developed as they want it, how they want it. As developments move along in cumulative steps (iterations) the features and benefits can be rationalized and reprioritized as each project unfolds. No waste, either of time, or money. And just as soon as everybody agrees that the application is where it needs to be, off it goes into the cloud and everyone can start using it.
The prospects for the organization, in any sector, are breathtakingly exciting; Agile, working via the Cloud, now gives greater control over process innovation and more strength to the competitive edge than has ever been the case before.
This is hard to answer without knowing company’s current process. You cannot go agile alone. The whole process shall go agile. Process means a business with roles, different types of activities, corresponding work results and sometime some associated projects.
There are many different ways for going agile. The main criteria that matter includes are:
– How much risk are you prepared to take?
– How keen / desperate are you to become agile?
– What ‘good things’ do you want ‘agile’ to give you?
– What aspects of the context you work in would get in the way of becoming agile?
– What does your team already know?
Key questions about the context for transformation to agile are:
– Is the context more focused on Enterprise or Project?
– Do regulations and the need for compliance with them form a significant constraint on the project?
– Does the way the work is governed apply constraints that impact our ability to be agile?
– Does the mind-set of the people involved constrain what we can do?
– Does the inherent complexity of the application constrain how agile we can be?
– Is the team small enough to be able to use the common agile practices effectively?
– Is the work split across teams or representatives from more than one organization?
– Does the team all sit together with the customer in the same room? If not, what degree of geographical separation do you really need to live with?
Unless you work in the ‘right’ context with respect to all of these questions, you either need to change your context or select carefully which set of practices suit your context – applying the standard set won’t work well.
Also one of the first steps in the transformation is to make sure you have executive sponsorship for your agile project.
In recent years agile software development has emerged as one of the most popular methodologies used in software projects.
Agile development, in its simplest form, offers a lightweight framework for helping teams, given a constantly evolving functional and technical landscape, maintain a focus on the rapid delivery of business value. As a result of this focus and its associated benefits, organizations are capable of significantly reducing the overall risk associated with software development.
In particular, agile development accelerates the delivery of initial business value, and through a process of continuous planning and feedback, is able to ensure that value is continuing to be maximized throughout the development process. As a result of this iterative planning and feedback loop, teams are able to continuously align the delivered software with desired business needs, easily adapting to changing requirements throughout the process. By measuring and evaluating status based on the undeniable truth of working, testing software, much more accurate visibility into the actual progress of projects is available. And finally, as a result of following an agile process, at the conclusion of a project is a software system that much better addresses the business and customer needs.
Agile development has its own set of drawbacks and may not be suitable for any type and size of software project, but can be successfully used for reasonably sized projects with a maximum team size of around 100 developers. However, agile development should be taken up by any organization in steps and can be started with a small project that can fall in line with the agile methods.
The advantages and risks of Agile Development are currently discussed very hotly. However, with all its pros and cons, agile development is gaining immense popularity amongst organizations across the globe that believe in simplicity in designing and developing software with great and effective collaboration between the project stakeholders.
I wonder what you personally think on this topic. We would be happy to have your comments on if it really makes sense to go agile.