The Agile framework or method you choose to implement is where practicality meets the philosophy.
Agile is a set of principles, but it comes from many different groups of practices finding common ground. Principles alone aren't enough, though - you still have to do development and to do this you'll want to use some management and engineering "practices" to improve agility and increase quality. So in order for a project, or even a whole organization to be truly agile, you need to follow some engineering management practices, without which you cannot be Agile enough, but if you aren't Agile enough, it is not solving the entire problem. What are the best practices required for an Agile project to be truly Agile?
Agile Planning: Regardless of the size of an organization developing a road map is important. How much time we spend understanding the low-level details of that roadmap is what is different in Agile. There is plenty of planning in most agile systems, keeping well in mind that Agile is a philosophy and expressed through a set of values and principles - the framework you choose to implement is where practicality meets the philosophy. Assuming you're using Scrum, there is more than enough room for program, project, and release planning, as well as Sprint planning. Those all have different goals and work at different levels, but work together.
Agile Management: The biggest change organizationally that you must address is management. Agile frameworks and methodologies are not easy nor are they magic. They are much more simple than massively administrative waterfall systems, but that catches many people out. Simple does not equal easy or magical. Getting it right requires knowing what you're doing and how it needs to be done in real, concrete terms. Management is used to having projects approved and then get updates along the way and don't know until the very end that the project is off the rails and they will only get some pieces of the project, often the parts that were easiest to deliver and ones that keep the project running. In Agile management, it is now engaged every step of the way, they get to decide what is most important today and have teams work on that. What they aren't used to is being engaged in this manner, it's harder for them, they aren't experienced in making decisions from a scope perspective in the here and now. They own the scope of the project in a much more integrated manner.
Agile Delivery - In large scale organizations with specific major release dates, teams need to organize their roadmaps around these delivery dates. You will want your teams to come together for a formal Release Planning event that will allow everyone to review all of the planned work across all teams. This is ideally done together and all of the work is on the wall and very visible. Dependencies and such are identified and addressed here. The hard part to get right is delivering the most valuable work first. There is also a great deal of cognitive bias to work through, especially in "we've always done it this way" organizations, organizations new to agile, etc. Getting that right and knowing how to both break down and prioritize the work, are real challenges. Although it is true that estimates turn to be fuzzier, the further out you get, it does not mean you don't have estimates, requirements, or timelines. Especially when there are clear timelines for deliverables, the team needs to develop a plan which can help the business meet the need, or inform of impediments, trade-offs, etc., when it cannot.
One of the important Agile principles is to focus on value. The idea is to always do the most valuable thing first. That way, when you reach some arbitrary date, you will have developed the most valuable software that you could have developed in the available time. You can't expect a development team to fully understand what's valuable. However, that's why business people and developers must work together daily throughout the project. There is a different level of planning and delivery. The "macro" level is a technology roadmap that ties together key technologies with the strategic capabilities/outcomes/products you need as an organization. It evolves slowly. The "Meso" level is "release cycle," where you balance out will drive the most value in the next 6 months. This is usually a balance between "epics" and smaller features, as well as a balance between "strategic epics" and "feature epics." To what extent you need detailed meso and macro planning depends on context. The key is to develop a level of comfort in quick delivery and realization of value, and then in plans for value realization in the distant future.
Basically, Agile success depends on management, leadership, culture or in another word: PEOPLE; not just processes or frameworks, where those are the means and tools to help you get there. The key should be selecting the right tool at the right time and situation to try to take the best decisions, without blaming Agile or Waterfall for one’s own mistakes.
0 comments:
Post a Comment