An Agilist Needs More Than Training To Succeed
After his return from Rome, Will couldn’t find his luggage in the airport baggage area. He went to the lost luggage office and told the woman there that his bags hadn’t shown up on the carousel. She smiled and told him not to worry because they were trained professionals and he was in good hands. Then she asked Will, “Has your plane arrived yet?”
The most essential part of Agile transformation besides the Org. change champion, is proper training and in this post the intent is not to undermine the importance of training. Agile based training or certifications provide you with knowledge but not necessarily the wisdom needed to apply it successfully. Implementing Agile in any Organization requires more than just knowing the terms or ceremonies. It requires changing the mindset of people and working on making changes to the legacy processes and tools.
In my experience, most of the training does not cover what exactly Agile Manifesto meant by uncovering better ways of developing software. So here is my attempt of dissecting what is included in the Manifesto.
- Individuals and interactions over processes and tools – You need to develop a self-performing team that owns collective responsibility but then for them to be successful, communication has to be transparent. You cannot be a ‘self-performing’ team without bringing in the transparency using processes and tools. Scrum ceremonies (Sprint planning, Daily Scrum, Sprint Review & Sprint Retrospection) provides you the discipline to be transparent but we need to ensure that the transparency in communication & collective responsibility is flowing across the Organization. In my earlier post Trust your Team But Make Sure to Verify, I had shared that trusting your self performing team is important but its essential to verify that team is performing to its optimal level as a unit and not showing just individual brilliance, which can be counter productive for the end results.
- Working software over comprehensive documentation – In order to develop a ‘working software’, project team and stakeholders should have a shared understanding of the project objectives or goals. We do not need to spend a lot of effort to create an accurate or comprehensive project charter but what we need is a good understanding of the vision, which is shared. Agile based SDLC of building potentially shippable products incrementally in short periods of time is one of the most tangible changes and benefits, which an Agile process provides. But again, its important to remain focused on the shared vision. Have enough documentation to serve the architecture, design, delivery, user acceptance and deployment of a working product in short iterative/incremental cycles.
- Customer collaboration over contract negotiation – In my earlier post Minimum Marketable Features: An Agile Essential, I had shared that Organizations no longer compete on product or service but they compete on experience of faster to market with quality results. It is an organization’s ability to learn and translate that learning into action rapidly, which gives it the ultimate competitive advantage. Traditionally, the negotiations with customer were happening upfront at the start of a project with more energy spent on trying to be safe in terms of scope of work, cost & schedule. With a practical Agile approach, a trusting collaboration can be fostered between the customer and project team in which discovery, questioning, learning and adjusting with shorter feedback loops during the course of the project will have a better chance of delivering a product, which provides the customer with a competitive advantage than a contract that is signed early in the lifecycle and is difficult to change.
- Responding to change over following a plan – Planning is important because if you don’t know where you are heading, any road would take you there. But having said that, experience has taught us well that creating elaborate project plans does not guarantee success of a project. Also we understand that in this disruptive era, its not pragmatic to freeze product requirements, priorities and timelines. Change is the only constant factor in a SDLC and we should plan enough to be receptive to change. Agile creates an opportunity for increased customer satisfaction and return on investment by handling change effectively with more robust feedback loops, which accommodates changing requirements to generate higher-value products. Bottom line is to plan continually rather than plan once and follow it to the core.
To summarize, getting trained in Agile does not necessarily mean that we have started thinking ‘Agile’. After training, work in your Org towards bringing in changes including predictable delivery by taking small steps in developing an environment, which fosters a collaboration culture with a shared vision across the Org.
If you want something talked about, ask a theorist and if you want something done, ask a practitioner!
Previous posts you might be interested in: