As I said earlier, Agile has been the biggest influence in how I think about software and my profession in general. Over the years I have witnessed Agile’s growth and various ways people/organizations/teams have adopted it; There were early adopters who started doing Agile not long after it was first, for the lake of a right word, invented. These people took Agile as an experiment and their learning has greatly contributed to the growth of this methodology.
Then there were mid-time adopters who took up Agile when the success stories had just begun to come out. These people were tired of running things the Waterfall-way and took Agile up for the promises it showed for increased communication, flexibility and change adaptability. These were the kind of cool-kids of Agile in that they were able to understand the context best suited to apply Agile. They had the right kind of organizational commitment to implement Agile and today Agile culture is inherent to the way they work and think about their product development.
And now I come to the last wave of Agile adapters (The very reason I am writing this particular blog post)They were probably sleeping when the Agile-sun came up on the horizon. They were content with the status quo while trying everything in their power to defy changing customer needs, constantly reacting to crisis situations while barely making the delivery months and months after requirements were first gathered. Now they are looking around, amazed at the pace at which the world is changing and unable to hold their customers any longer.
So one fine day they just pull up their socks and decide- enough in enough..we cant work this way anymore..we need to go Agile! They read a couple of blogs, maybe send some mid-level managers for an Agile training and BOOM! Their Agile bandwagon is ready to move. But does it really work that way?
In my experience, successful Agile implementation requires many different things coming together at the same time. Many teams just started with the implementation and success came much later and at times it even did not. There are teams who have been working in Agile, reaping great benefits but there are also some teams who tried Agile, went wrong and burnt their fingers quite badly. A lot of times, success and failure of Agile implementation depends upon the reason behind -Why you really want to go Agile? And trust me, their are wrong..really wrong answers to this question.
In my opinion, if you start with the wrong reason, you are almost certain to end up doing ‘Bad Agile’. What is it you ask? Here are some of the most telling signs I have observed while working with different teams:
- You are partially Agile- This typically happens when your stakeholders don’t care about Agile or your management doesn’t care or about Agile or both. So you are implementing agile at your team level without much stakeholder involvement (Cuz you dont have their buy-in) and you are constantly fighting organizational red tape because they don’t care for you being agile. There is a Youtube video about a guy wanting to run an Agile project in a traditional organization. Just watch it and you’d know what I mean. In this case your delivery commitments do not match with your team churn nor does your team effort reflected in customer contracts. So basically you are trying Agile, halfheartedly, in an environment that doesn’t support it. Its like trying to grow a lotus pond in Sub-Saharan Africa. It is doomed right from the thought state.
- You have a Project Manager constantly asking ‘what are you working on? How long it would take?’ – By philosophy, Agile teams don’t have a Project Manger. Even if you do, asking of these questions show that one, there is not enough awareness in terms of who is doing what, which means there is not proper planning and two, you are clearly not estimating as a team.
- There is no self-inspection- Not having pre-schedule retrospectives on your calender is not necessarily a bad thing. Agile talks about inspect and adapt- how you do it is totally up to you- as long as you do it at regular intervals. But if you are just going on, without taking a pause to simply ask ‘how are we doing?’ you are not likely to be very successful as a team
- There is no planning as a team- Plans are nothing; planning is everything. This quote can be used probably most effectively in support of Agile planning. If the design and scoping decisions are still being made in closed door Manager-TechLead meetings and team is informed after the fact, if at all, then you are just using Agile as a way to impose changes upon your dev team while completely omitting their involvement and thus their input. A perfect way to set yourself up for failure
- Your sprints are mini-waterfalls- This is a classic Bad-Agile scenario. You decide you will deliver something in N number of iterations and every iterations starts with getting a formal sign-off on requirement document, design, coding, code freeze 2-3 days before sprint end and testing and bug fixes. Not only this is not Agile, this could actually prove to be counter productive. You are not leveraging concepts like emerging design and how are you ever going to find opportunity for managing change in scope?
- Your engineering practices are primal- Your team does not have time to write Unit tests. Your integration tests wont be written until the final code review at the end of the project and your team needs to spend considerable time getting all kinds of approvals to deploy on various environments. This is not in the spirit of team empowerment. If you are expecting your team to meet sprint timelines without leveraging automation, they will either be completely exhausted or deliver poor code or both. Won’t work for too long..
- Your team culture is of blaming and Heros who save the day- In my experience people who suffer most from Bad Agile, or any bad way of software development are developers. Your developers are not involved in planning or preparing. They still work in silos and avoid talking to each other. Your team system is built upon meritocracy there is always that one person who can code 18 hours straight and get your project out of any possible bad situation. He is the only one with visibility and recognition. Others just fill the space while constantly being undervalued and under-challenged. The skills and motivation of each team member is a huge deciding factor for your software quality. A poor team will hardly ever come up with a great product.
- Agile is a way for you to get more work done of your team- You are an Agile PM or a Scrum Master constantly influencing your team’s estimates, using your seniority or years of industry experience to influence them to over commit and you translate story points into man hours (A 3 pointer story means it’d take 3 hours to build – No it doesn’t!) Basically you are an Agile bully. You are using hierarchy and agile to pressure your developers. This may work in short term but is certainly not good for team morale and definitely not sustainable. Agile thrives when teams stay together for longer duration (A couple of years or more) but that would happen only with self- empowering, nurturing environments that you can’t provide.
- You are doing Agile when you really shouldn’t- This is something only you can decide upon. There is no set guideline to tell when is Agile suitable for a project and when it isn’t. I believe at the most basic level, you can ask yourself- would your project benefit from iterative,adaptive development? Is there even scope for you to be iterative and adaptive? There could be projects so critical that there is no opportunity to fail and learn and experiment. Or there could be projects where documentation is must or there could be projects where the customer is crystal clear about what they want and doesn’t want to be involved frequently. As a professional you need to be able to assess your situation and decide the best suited way. Don’t do Agile if you dont need to. I find this phrase very important – Good waterfall is much better than bad Agile. Also, Agile and waterfall are not the only ways to develop software. There is always an opportunity to pick and choose what works best for your project and do exactly that
- You are trying to implement Agile without being agile- This is a tough one. Probably the toughest of all. There is a difference in implementing Agile and Being agile. You have setup a daily standup meeting, draw up a project burndown chart and calling yourself Agile. You ask your team to estimate without engaging them in planning and commitments. You are still sending project reports to 5 different people and you have no idea what is the product roadmap. True agile implementation is not simply about setting up some ceremonies. Agile is a cultural shift, its a huge change and change is always hard. Agile concepts are not to be memorized and mindlessly plugged into your development. Its a series of experiments, adaptive learning and building a team culture that is able to easily respond to change. Most importantly, it works best when their is a buy-in from the stakeholders. If you are not ready for this kind of shift, your agile implementation is never truly Agile