With Agile has been adopted by more organizations, there’re
also more debates upon weather it causes software quality issues. "Blaming
Agile" is the mentality to resist changes, or make it broader, it's still
the culture issue, the collective programming of mind for group of people to
think and react. Agile isn’t the answer
to all things either but it surely isn’t the problem. The point is that
unlike a physical product that may not be functioning correctly and therefore
breaks down and fails, a process or methodology like agile is people dependent.
Agility is all about people and change! Here are 7 principles
- Adapt to Changes: Agile way was
brought in because there was a long gap between the thinking and the doing
and the implementing in case of Waterfall. Simply put, Waterfall projects
tend to fail because of constant changes , and dogmatic adherence to
documentation and processes!
- Agile has three characteristics: Incrementalism, Iteration, Improvement.
As Agile is more about the mindset shift upon keeping iterative
communication, cross-functional communication, customer satisfaction and
faster delivery. Agile is
- Agile can be humbling -- everyone is essentially selling their services to someone -- developers, testers, requirements people, scrum masters, and yes, architects. There's a concept agilists embrace called "the tyranny of the best idea."
- Aim, fire, and adjust. Agile makes the issues that you normally face at the end of the project more relevant upfront. The primary goal of software development is demonstrably working software with few defects. Regardless of complexity, customers NEED to see working software so they can tell you whether you're on the right track or not
- Breakdown Large Project to Small ‘Work”: Agile doesn't attempt to control all the variability, but rather chunks up the project into small "work" then "measure" phases. Conduct early reviews, provide releases and gather early feedback (iterative, responsive, handle change)
- Show traceability (plan, execute, review): Smart agilists don't want architecture and risk management to be rubber stamps or millstones. They definitely want the value they provide -- but it needs to be provided in a consumable way, The project should deliver value that the customer expects, and it takes rounds of improvements to actually know what the customer should or like to see in the end
- Agile Human Factors:
1) You need people with attitude to openness;
2). People need to take full responsibility for their activities and goals;
3). They need to be willing to present their results as well as failures;
4). Their motivation must be spurred by radical change and the aim for break through innovation;
5). Finally, you need an audience and organization with a focus on people and results, which celebrates small successful steps but keep the focus on long term objective
Change is the only constant in the IT world of delivering
solutions to customers, and we cannot challenge that. Though Agile may cause
some confusion, hit a few roadblocks and get set back quite a bit, it’s still a evolutionary methodology in managing
projects, ensuring full team participation, and customer satisfaction. Also
Agile is not only an engineer team's next practice, it's really about a culture
of innovation which encourages cross-functional communication, adapts to changes
and enchants customers.
1 comments:
The problem I have found with agile is that we haven’t learned from nature. The whole point of being agile is for us to adapt. What we then might want to do is look how nature conforms to adapt and this can be found in physics, particularly concepts of quantum; we learn that everything is connected. When we try to establish an agile process we tend to start with a boundary which in itself restricts our abilities to look at certain options. But if we establish these boundaries based on an enterprise or network framework rather than an independent solution set; we can stop some of the duplication and start reusing functionality as we find it available within our network. We need to build the IT to fit this framework and that requires loose coupling but with the purpose of being able to couple when needed to complete a process. This is a different IT design than what has been built in the past.
Some of the newer ideas in SOA; and Cloud are beginning to evolve into this but right now composability of the components is over the horizon and standards to produce it haven’t been defined. And, if standards aren’t being developed in this same network framework fashion; then we have a mismatch with design. Standards are for a purpose; to enable interoperability. But if standards are also bound and limited to specific areas of technology without the thought of how these relate to the wider whole; we run into the same problem with agile.
I have worked on a composability project and know it can work but the political risk of implementation is huge as we know that it is a new way of doing business and the comfort zones of leadership are not ready for this change until they are forced into it or until it becomes well accepted within the IT industry. There is much resistance to it in the IT industry as well because it changes the IT industry from developing specific solutions to developing the tools for the users to develop their own solutions. Granted this could open up a whole new type of IT industry; it goes against traditional business plans of IT companies.
Post a Comment