Enterprise vs Agile !!
Amit Mahajan
Technical Product Owner | Associate Product Manager | SAFe Scrum Master | Business System Analyst | Solution Design & Implementation | System Integration | Solution Architect | SAFe POPM? | PSM1 | AWS Solution Architect
Agile software development has proven to be a major benefit to various teams,but it can affect businesses differently depending on their size and how they integrate the methodology into their operations
It's no wonder Enterprises are struggling with when they are adopting agile as it is far from a silver bullet. Simply adopting an Agile methodology without understanding what means to be Agile, won’t lead your organization to a successful transformation. In addition, such change has its challenges and issues, which, if not addressed correctly, will inevitably lead to another failed transformation.
1) Insufficient Agile experience
You need a team of people who can drive and enable an entirely new way of operating. If your existing staff lack Agile experience, it will be difficult if not impossible to successfully adopt Agile on your own.
People find it very easy to retain their old methods and processes except in the case when they are vividly presented with solid “whys” they need to embrace the transition to Agile.
Tip: Be Agile in Hiring as needed.
It seems simple, but it means changing the way HR operates—the way they resource, interview, assess skills and more.Also, while coaching can help address insufficient Agile experience, to fully enable Agile, you also need to embed seasoned Agile practitioners within the development process to ensure that the Agile adoption sticks.If you know someone who has a credible perspective on Agile, get their take on your Agile adoption
2) Attempting enterprise-wide Agile adoption without project-level Agile success
Agile requires “support from above” for a “bottom-up” approach to get things done. Trying to adopt Agile on all development teams at the same time is simply too much change at once.Some of the Agility Attributes such as Customer Focus , Adaptability ,Effective Leadership & Continuous improvement needs to be conveyed by management to address desired result from this change.
Tip : Get executive support for an Agile development starting One project.
Successful Agile adoptions start small. They budget for achieving a defined, initial functionality on one or two teams and just get started. Support comes from above to specific Agile teams in terms of Adaptability ,Effective Leadership & Continuous improvement .Executive-level sponsorship is critical to driving the culture change that Agile requires. While a lot of the Agile adoption process is “bottom-up”, support from the “top-down” enables it. Without executive level support, an Agile adoption is at risk.
3) Micromanagement and Agile
In non-Agile environments, there is a tendency to micromanage the development process. In Agile, development teams should be left to run the whole process using disciplined engineering practices and adaptive, collaborative control processes.Agile Teams would be given the freedom to analyze and figure out how to come up with solutions by themselves whenever they encounter issues, instead of wasting valuable time waiting for approval after approval just for something to be done.
Tip : Enable decision making.
Let the team—managers, developers, quality assurance—work together and make decisions. In particular, business and domain experts assigned to a team must be enabled to make decisions on the project, such as prioritizing stories. They shouldn’t have to check with their boss every time a decision is needed. Keep in mind this principle behind the Agile manifesto: “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”
4)Unrealistic planning expectations
It is unrealistic to expect absolute certainty over project scope and budget before the project starts. Software development never actually worked that way; and now, with rapid innovations in technology and frequent changes in customer wants and needs, it’s impossible to envision the entirety of any substantial software project up front. As stated in the Agile manifesto, it’s about “responding to change over following a plan”.
We can only forecast future based on what is currently known to us and Agile gives you all the required artifacts to inspect and adapt that plan .
Tip: Avoid comparing software development planning to other forms of planning.
Software Development lies in Complex zone . The development of software is often compared to the construction of a building—a completely inappropriate analogy.A building is tangible. A significant change to the design of a building during the course of construction will be expensive and likely impossible. In contrast, software is intangible. Making changes in the course of development may or may not be difficult or expensive. For example, everyone has an intuition based on their experience of the physical world that it should be relatively cheap to change the colour of tile in a building foyer, but no one would ask to move an entire building “only” two feet to the left after the tenth storey has been added. But the same intuition does not apply to software: maybe “moving” the application from one server to another is cheap. Maybe it isn’t. No one would expect this to be impossible.
5)Underestimating the amount of planning in Agile
Plans for Agile projects, by their very nature, are flexible; stories can be pulled in or out of the plan as business requirements change. In Agile development, planning is an ongoing process that requires discipline to execute well.
Tip: Work the plan, not work to the plan.
In Agile development, planning occurs throughout the development cycle and involves the entire team. This avoids the situation where overly detailed plans made at the start of a project become out of sync with the technical and business needs as the project progresses. With Agile, you work the plan, not work to the plan. The result is a constant focus on business value, which demands ongoing planning.
6) Adopting Agile delivery process practices without adopting technical practices and just adopting Agile Tools
This is challenge is all too familiar: adopting the non-technical elements of Agile while ignoring the technical elements. The benefits of Agile can not be fully realized without the adoption of the technical elements of Agile.
“I’m using an Agile tool. Therefore, I’m Agile” seems to be the logic of some companies adopting Agile. While these Agile tools can certainly help, without an understanding of and support for the cultural change that needs to happen within the organization, relying on tools alone can be risky.
Tip: Adopt Agile technical practices and get started without a tool
In fact, it’s stated right in the Agile manifesto: “Individuals and interactions over processes and tools”. Start with the basics of what it means to be Agile, and then use tools to support the initiative.Agile means having the tools, skill sets, technology and engineering practices to support the overall concept. It goes beyond the ability to change what you’re building next week without jeopardizing what you’ve already accomplished.Necessary capabilities include continuous integration practices and automated builds and tests. Adopt the practices of refactoring and evolving architecture. Agile technical practices are a critical yet often missed component of Agile adoptions.
7) Impatience
Agile is not supposed to be some magic stick which will fix all your problems . It will helps you to raise and discover problems in Software Development process which needs to be inspected and adapted continuously .
For some teams , it takes months and for some it take years to understand what works best for them . Large enterprises need to be patient and learn to expect that Agile is not a quick fix but instead a long-term investment.
Tip : Note where Agile is in the Hype Cycle
In Gartner’s latest Hype Cycle for Application Development (2014), Enterprise-Class Agile Development is at the peak of inflated expectations while Project-Oriented Agile Development Methodology is climbing the slope (of enlightenment). That means project-level Agile is nearly mainstream whereas enterprise-level Agile is still relatively nascent. Act accordingly.
Understand implementing Agile is continuous journey which involves frequent feedbacks and retrospectives .