6 Reasons Why You Should Adopt Agile in Your Organization…!!!
All you need to know about agile development and agile project management using agile software development methods such as Scrum, Extreme Programming etc. Here, we can discuss about following points:
- Reasons for Agile Adoption
- Is Agile feasible for you?
- Groundwork for successful Agile journey
- Cultivating Agile in your organization
While the agile manifesto and principles look tremendously interesting and practical on paper, it starts appearing equally ineffectual to produce a balance among project’s scope, time, cost, quality and risks.
Enough has been said and written for praising agile. It has been criticized equally. If we just go through the formal research studies related to the pros and cons of agile, every other scholar on the planet seems to be working on the same.
Now is the time, I believe, to make it work.
Remember that development process is one of the tools to run an organization just like other tools. We cannot allow one tool to dictate and others to follow. Rather, we have to make them compatible and complement each other
The two extremes of Agile adoption approach are:
1) Either philosophize the concept to an extent that makes it impossible for the process engineers to materialize the concept objectively.
2) To ritualize it enough to focus on the process more than the end goal.
We will be discussing the approaches that lie between these two extremes and as much in the middle-of-the-road as possible.
Why should you go for Agile?
Here are the six top benefits I’ve experienced after implementing Scrum and Agile methodologies for some of our customers:
1. Smaller, Faster Failures
Have you heard the saying, “Fail forward fast”? I know every project begins with successful intentions, but the reality is that it doesn’t always work out that way. Perhaps it’s not even the project, but an idea or feature that you’re working on implementing and it’s just not adding the value you thought it would.
“Fail forward fast” infers that this failure happens quickly and you can learn from it and move on. In Agile frameworks there are not gigantic up-front analysis efforts; you learn as you go and change as you need to. Companies no longer need to spend $20 million and wait 18 months for a new application to launch. Agile can produce the application incrementally and businesses can experience return almost immediately. The application starts producing Return on Investment (ROI) quickly and with a small investment.
2. Faster Time to Market
Agile frameworks emphasize the Minimum Viable Product (MVP) and the Minimal Marketable Product (MMP). These are two Lean concepts that allow for a small, safe investment that can be delivered quickly.
An MVP tests an idea and provides a learning mechanism. You essentially release a very early version of software to see how the market responds to it. It’s often missing or contains ‘placebo’ functionality, but the full intent is to determine if the concept is worth pursuing. It is a vehicle for testing your assumptions.
An MMP is a fully functioning piece of software. It contains the bare minimum feature set that a user needs. It gives a business the ability to get to the market faster and be empirical about adding future features. Rather than spending months until you ship a product with all the bells and whistles we think a user wants, we deliver what we know they want right now.
Remember: In general, the Agile framework emphasizes working in short iterations (one to four weeks with the most common being two weeks). Each iteration ends in a potentially shippable product increment, which affords a business the ability to incrementally release.
3. Stakeholder Satisfaction
Stakeholders are users, customers, or anyone that has a vested interest in the software. In Agile approaches, stakeholders are heavily engaged in the process and their feedback is constantly solicited. To ensure that we’re adding value every step of the way, we ask the stakeholders their opinions during iterations.
Stakeholders feel engaged and part of the process. They know that we’re working for them and are concerned with their needs. The bonus of this is that we’re building the right thing and can test our assumptions in ‘real time’.
4. Greater Employee Satisfaction
During the Agile process, employees are heavily engaged in the process and decision making. They have buy-in and get to directly work with stakeholders who can answer vital questions. An emphasis is put on conversation rather than exhaustive documentation.
The team atmosphere with these methodologies is brilliant. Teams commit to complete work as a unit, which lowers workplace vulnerability and heightens team member knowledge. They collectively work towards a common goal and succeed or fail as a unit. It’s a fun environment that leads to lower attrition rates.
Lastly, the iterations provide them with a channel of work that is not constantly interrupted with the latest fire. They can focus entirely on a feature and the task at hand without having to worry about being diverted by management’s latest idea. Micromanagement cannot exist.
5. Organizational Transparency
Agile is a total, holistic process that creates organizational transparency and camaraderie. People are honest and work towards a common goal and achieve what they have set out to achieve. The political landscape is lowered. The open office environments that are encouraged flatten the organizational hierarchy and create a greater sense of community.
6. Save Money
By lowering risk, embracing change, having faster time to market, and involving stakeholders—businesses save money by building the right product rather than basing development on assumptions. The team is highly productive and they feel completely engaged in the process. The costs are lower because the emphasis is on building precisely what is needed, not designing bells and whistles that will never be used.
So the question isn’t “why go Agile”….the question is, “why not?”
V & V Projects Outcome:
Waterfall Projects Outcomes:
I have broadly classified the most commonly found reasons among different software organizations which adopted Agile successfully as a need rather than a fashion. When I say “Fashion”, it’s because the percentage of Agile companies have increased from 34% to 75%.
6 Most Common Reasons You Should Adopt Agile in Your Organization:
#1. Excellence require right process
“Excellence is not an act. It’s a habit”, said Aristotle. In any discipline, consistency is the key to success. Odd superhuman performances do not place you anywhere. That’s why there is no appraisal for CMMI level 1 because it requires individual heroic efforts for occasional achievements.
Every startup relies on the individual heroics initially but to reinforce the same performance and attain the excellence, you need a right process. This is the single major argument for emphasizing on adopting the “right” process. Unfortunately, there is no “one size fits all” process available that can be universally applied in any organization for any project. But fortunately, you can develop one for yourself.
The dedicated resources and time required to develop a highly structured and complex process definition and continuously improving it forever is not feasible for many companies. So, they are compelled to overlook an important dimension of production business i.e. process and relying on Adhoc practices. On average, large IT projects run 45% over budget and 7% over time, while delivering 56% less value than predicted.
This leaves Adhocism as the direct competitor to Agility for such organizations. With respect to simplicity, flexibility and inexpensiveness, it’s probably the next best thing to adhocism and certainly far more efficient. Agile keeps its principles abstract enough to be materialized in a form that best suits the needs of an organization as simply as possible. You can just take an inspiration from other organizations or projects following Agile and pragmatically evaluate what works in your specific setting.
#2. Bureaucracy kills productivity and creativity
We were jubilant when we were appraised for CMMI level 2 in 2006. Among more than thousand software companies in the country, we were among the only ten to acquire the status. We looked proud to share the achievement with our clients and prospects as if we had come across a prominent marketing tool.
It seemed all good before we realized that there’s something killing the organizational productivity as well as creativity considering its potential. We were turning into a dogmatic organization like armed forces. There was an unnecessary red-tapism in the flow of information and completion of tasks just because the focus was more on the designated roles than the tasks. People were not willing to go beyond their roles and were religiously following the organizational structure.
I am indecisive about whether the disciplined processes were causing the bureaucratic culture or vice versa but the two are meant to be as I talked to the other organizations aiming for highly structured and established processes. Bureaucracy doesn’t give you much room for experimentation, risk taking and rectifying your errors.
————For creative software development, you need a right balance between discipline and flexibility. The approach has to be more democratic than bureaucratic. As they say “Bureaucracy is a giant mechanism operated by pygmies”, high stature software developers do not like it at all. They were becoming rebellious with the defined practices which were becoming more formal with our notion of continuous process improvement and were shifting to adhocism.
It was finally decided that Agile is the only way to save them from bureaucratic processes, other than going entirely Adhoc. PMI ranks increased productivity as fourth top reason for adopting Agile.
#3. Software Development follows Darwinism
Almost all the software process models have transformed themselves to incorporate the change management as they realized that inevitability of changes and scope creeping in the software. But this is where the problem starts. All the traditional models introduce change management when the change becomes inescapable. But originally, they try to resist and escape the changes. The change management procedures are invoked as a last resort.
Agile with its manifesto “Responding to change over following a plan” introduced a philosophy that answered the problem of changes with using it as a primary tool to develop software rather than treating it as a constraint. It believes that software development is naturally evolutionary and there is no better way to build a software than to continuously respond to changes without trying to evade them. Software is meant to resolve a specific problem of masses or for a particular community.
There are often multiple solutions for the problem and it is not humanly possible to jump to the best solution unless there is an off-the-shelf solution available and your target is just to imitate. Here, the Darwin’s concept of “survival of the fittest” comes in and the best attempted solution prevails. PMI ranks change management as second top reason for adopting Agile.
#4. Dynamic products need Early ROI
One of the distinct characteristics of software products is its dynamism and volatility. There’s a continuous stream of innovative ideas in the market with previous ideas and solutions becoming obsolete at a similar pace. So, we cannot wait forever to build the right product before taking it to the market.
The phase that transformed our whole process was when our traditional process was not able to get along with the frequent market demands. Every other week, we had to ship the products with changes. Planning and execution within the defined process had become unmanageable. Gradually, we had to forego our practices one after the other because of the market pressures. Top management was not willing to compromise on the client deliverables just for the sake of following a particular process. This created a vacuum that had to be filled in by another process that ensures the shorter time to market and ultimately the early returns. Therefore, you have to deliver it when market needs it.
If you don’t reach the market early enough, you cannot convince them to buy your product just because you built it using ultra-sophisticated processes. Agile encourages you to build “Minimum viable product” for market delivery. And it has been very successful with 73% of the Agile adopters have verified that the process reduced their time-to-market significantly.
#5. Customer cannot be kept out of the loop
A significant dilemma of the software companies following traditional processes is that they never know before the completion of the project that they are building a “right” product. At max, you can know at the end of the iteration if iterative model is being used. The reason being that it is only the customer who can validate the product. This is why I was in favour of the Prototype model the most before Agile made its way. We used to build a simulation of our proposed solution for the client to validate the product before building it. We used to call our prototype as “proof of concept”.
But, it proved to be the over-simplified solution of an extremely complex problem of a gap between customer’s expectations and our offering. It was not just about the challenge of creating a representative prototype but also the customer’s own indecisions and fuzziness about his actual requirements at the start of the project. Then, if it is a product for mass usage rather than a customized project, situation gets more complex.
The only way to cope up with this is to engage the customer(s) throughout the development process in order to collaboratively build the final solution. Agile manifesto is very clear about the focus on customer collaboration more than following a contract. PMI ranks better alignment of business and software development as third top reason for adopting Agile.
#6. Team morale has to be consistently high
Project plan, Gantt charts, Project management reports, test plans and the release plans were my favourite artifacts in the younger days. It was based on a traditional belief that well planned is half done. My belief is still intact. However, my definition of “well planned” has evolved over time. The project manager used to decide who will do what and when, based on the input and estimations from the stakeholders. Once the plan was put in place, team members had to consider it as a bible.
While it was meant for the accountability of team members, it was found that they use it as a tool to run away from the responsibility of product’s success or failure. All the team had to do was to follow the plan. They did not own the product.
It was somehow obligatory for us to shift the ownership of the product towards the team to make them accountable as well as to raise their morale. Agile holds the teams accountable for the collective goals rather than encouraging people to work in silos. It encourages the cross-functional tasks by mutual assistance. The team members with limited or different level of skill set do not feel left out and are equally determined to contribute towards the team goals. I suggest replacing the individuals’ happiness index with team morale which is a major factor in high performance reinforcement among Agile teams.
The sample representation of team morale is below:
Although I have used my personal experiences with the traditional processes that pushed us towards Agile, but the purpose was not to get a praise at all for thinking smartly. Rather, I validated all the issues from the Agile practitioners and the process engineer of other organizations.
I have used my organization’s experiences just as a case study. Some of the issues were specific to our organization which have not been discussed in this article. But the motives I have discussed for Agile adoption are very generic in nature. If you have been using traditional approaches only, there is every chance you are facing these issues.
I would suggest to take a final decision only after discovering that you are coming across these glitches in some form. That would help you to set your direction and assess the success of specific Agile practices in your organization. Else, you can be caught in two minds at any stage of Agile adoption process whether Agile is better than your previous process or not.
- Posted by admin
- On April 14, 2015
- 0 Comments