Agile is a great emergent methodology, however, there is such trend that industry has been a way to be preoccupied with asking all the ‘HOW’ questions and focusing on methodologies and everything that come with that. In other words, when have you been so preoccupied with details that you fail to see the big picture? What are the circumstances in which you can’t see the forest for the trees?
Lack of Agile mindset: Agile is a mindset: Instantiated in the Agile Manifesto, supported by stated principles, each of that encompasses the whole – including business change and ecosystem dynamic, and those professionals inside the business who are responsible for both receiving and delivering people, process and software change. Those who properly apply agile ways of being known that you never take a methodology as a given, but you adapt it to the people and problem domain, the environment in which the change is taking place. Those who don't, and use methodologies as a cookbook find they don't have all the right ideal goals to put a great big smile on the customer’s face.
Methodology ‘rules’: Methodologies and strategies are important, but they should be there to support and not govern. The true and genuine way of achieving customer satisfaction is putting a smile on their faces. However, there are constraints (many of which are imposed by the customer) including cost, time, expectations for oversight, etc. How often have you heard “we could have delivered a much better solution if only”? It takes the courage to suggest working outside the constraints if that could bring a better outcome. Also, Scrum deliberately increases the isolation, using SM and PO as gatekeepers. This is useful when the team *need* to be protected from an organization that is less than agile. However, you need to recognize that the isolation is not a good thing, people should be working closely together, that there is no ready way to distinguish between business, business change and software development people; they're all part of the same team focused on the change, both in the how, what, and why. Customers' expectations and, critically, their own know-how around technology and what it can achieve have increased exponentially in recent years. It is critical that software delivery professionals recognize that and respond, harnessing and engaging with this growing customer awareness.
Business micro-management: The agile model has customer representation on the team and further feedback is obtained when the customer gets his/her hands on running software at the end of each cycle. This has been a move towards increasing the role of the customer in the process because you need the customer to steer and get the requirements right. However, business users are increasingly micro managing the requirements and often IT teams don't care to correct the business requirement. The goal of IT teams often remained "How" to deliver those requirements. Within that boundary, Agile is serving great. But very few are looking beyond the delivery. Whether the features developed are actually used by intended users is not considered by IT team, and business is not willing to admit that what they developed is a failure. Result is a big amount of waste.
Isolation issues: Business users have learned basics of software and hardware. Does IT teams learned basics of business they are serving? And if they did, does business team is inviting IT team at strategy planning meetings? Collaboration not just means business owner be a part of IT team as a product owner, but it also means IT become a part of business teams. The business team shall invite IT team for business planning meetings if IT team will be able to provide end to end customer experience, and not just restrict its role to delivering the requirement in perfect shape in any specific methodology or framework. Isolation from business is, in fact of people, but not the functional sort of. Everyone needs to bring something to the table in regards to ensuring that what is needed is actually delivered. Processes and methods continue to evolve as the team identifies better ways to actually deliver what is needed. Ideally, business and IT are working so close together that there is no ready way to distinguish between Business, Business Change, and Software Development people; they're all part of the same team focused on the business objectives.
Success criteria & failure identification: It is difficult to define success criteria for not just Agile but any project. There must be some responsibility of each one involved to make sure that money invested in the entire program does return the intended outcome. Return on investment can't be judged without taking into account production possibility frontier. The development team is just one piece of this interconnected puzzle and everyone has an interest in the project. How broad should you cast the net to define the WE who should be involved in the project? Is it inherently un-agile to have a very rigid target? If the target evolves during a project, can a completed agile project be evaluated to determine if it succeeded or failed? You need a way to identify failures so you know what needs correcting when looking for ways to improve agile.
Agile is the right mindset, methodology, or approach to enforcing interactive communication, and continuous improvement, one should not only see the tree but get lost in the forest and can’t see the big picture, there must be committed and continual engagement from the customer/ client/business. They must be part of the WE. To deliver products/services exactly what customers need, with outstanding quality, usability, and experience.
No comments:
Post a Comment