Agile doesn’t fix anything! So why should I use it? (Part 2)

In part 1 we saw some of the apprehensions that may exist on the ground. Let’s see the other side of the story now. In this article we will take each of the apprehension discussed in part 1 and see if there is another view point.

1.    Person dependency (only some people know certain things) –

a.     In Agile, we highlight teamwork and teams take responsibility for the delivery of value, not individuals. People start to help each other and iteratively and incrementally, by using pairing techniques (such as pair programming, paired reviews, pair testing, swarming, etc.) team will share knowledge / expertise, step by step in a structured and disciplined way.

b.     With each iteration, people should develop new skills that can help minimize the person dependency problem.  

2.    People’s egos and hence politics in the organization –

a.     People will have ego. But since cross functional teams work together each day, the mentality of “everyone is wrong other than me and my team” is eased out with time.

b.     In many cases we need a “war room” at the end to scramble through the project, where people who may not want to see each other, have to come together! How about then starting with a war room itself? Anyways, people have to work together some day, then might as well do it from the beginning, proactively! 

c.     It does require “leadership” support / drive, aligning all to a shared goal, mission, etc.

3.    Ad-hoc / unplanned work –

a.     Weekly iterative trends of unplanned work may help to inspect the details and adapt. While we may try to reduce such consistent flow of ad-hoc work, we also need to factor-in appropriate capacity allocation for it, during the iteration’s planning.

b.     Appropriate capacity distribution based on learning from a few iterations’ trend, adapting iteration plans or going to the root of such inflow of ad-hoc work may help us improve predictability which is essential for increasing trust in our ability to deliver.

c.     Of course, this capacity allocation will not eliminate “waste” because if the unplanned work doesn’t come to the teams, they will deliver more value with that freed capacity.

4.    Poor leadership and management problems –

a.     Transparency, inspection and adaptation are the main pillars of Agile and Scrum.

b.     These allow for empiricism and evidence-based management. When you look at facts, not opinions, it becomes easier to see what needs to be done, changed and what holds us back.

c.     Managers can be encouraged to learn incrementally to focus more on outcomes and empower the teams, decentralize control and delegate decisions to where work is done.

d.     This doesn’t mean we are not going to have bad managers…. but agile’s focus on actual delivery, continuous learning and transparency help managers elevate their managerial skills.

5.    False commitments to customers with fixed deadlines –

a.     Understanding our true velocity trend helps us making realistic commitments. Using the iterative, weekly trends which quantitatively expose the adjustments needed allow us to manage unknowns more efficiently and communicate things early.

b.     There will always be bad news in the system. It can’t magically go away, but the best we can do is to make it visible early so we can avoid bad, late surprises and maximize our chances of successful delivery.

6.    People’s engagement, communication, collaboration across departments / geographies on large programs –

a.     Cross functional teams aligned to a shared goal, working closely all throughout, can help to dissolve these silos and improve working relations across functions.

b.     Leadership creating an environment where we all will aim to learn faster than anyone else, will help to foster this collaboration

7.    Attrition issues where we lose some good people and teams keep changing –

a.     In fact, people’s engagement is one of the central things that agile helps improve. People enjoy much more working in a transparent organization, where what is expected of them is not random but based on reality, and time and space is given to build in quality so that people can be proud of their work.

b.     Iterative weekly trends can help us learn quickly the “sustainable pace” that doesn’t burn people out.

c.     Teams delivering value end to end are not just delivering lines of code, they participate in demos to clients, they are expected to estimate and commit to delivery, and are not simply the “order takers”.

8.    “Accurate estimates, requirements, solutions” on large programs –

a.     The detailed estimates, plans, designs and requirements that we are building up front are anyways changing and turning out to be irrelevant within the same project duration.

b.     So, how about accepting that we just can’t possibly understand or know everything upfront? We have never been able to do this so far!

c.     Product development is like driving at night in a fog. The best we can do is to build incrementally with fast learning cycles (short iterations) and adapting our course accordingly.

d.     The only way to get to a “right estimate” will be to keep adjusting our estimation. Similar to the way applications like “Waze” or “Google Maps” work.

9.    Even if our customers are not interested in seeing something every few weeks, and there is no urgency, still frequent internal delivery and continuous testing has a lot of value

a.     When we “test” a lot of stuff at the end – how can we call it “Quality Assurance”? Isn’t it actually “anxiety assurance”? Because when we find a lot of bugs at the end we simply don’t know what is working.

b.     Receiving feedback early and often, and testing more often, reduces the amount of “noise” we have when we test a large batch, and makes it exponentially easier and faster

c.     Practices like CI, CD, TDD, etc. help us build quality in with small chunks.

 As a student, while studying any course, we will have to face exams to assess the knowledge gained, which will also decide our grade / rank. There can be an assessment at the end of the term, once in six months OR an assessment at end of every week or two where small increments of knowledge / skills can be verified, throughout.

Which assessment approach will help to bring some structure and discipline to my preparation? How about quality of such preparation / studies? Does this approach help to “build quality into” the preparation every week, and all throughout?

One may still think that an exam only once at the very end is better, and then that’s fine  . Please stick with it…choice is yours.

 10.  Most of these problems are known to us already, nothing new that we are uncovering! We can fix these problems on a waterfall approach also (if we want and decide to!)

a.     Absolutely correct! All of it is just common sense. The only difference is that Agile makes us use our common sense in a systematic way.

b.     Isn’t it better to do continuous and small improvements than a delayed “perfection”?

c.     And yes, people start seeing most valuable stuff coming out very soon. Seeing is believing and belief builds trust!

 Incremental and iterative way of working can provide a structure, discipline, which may help us to bring an order to chaos. Problems won’t vanish, we still must face them. Question is, can this approach make it easier to tackle these problems when dealt with incrementally and with the right mindset? What is our goal? Hope to become perfect overnight, or take small steps to become better tomorrow than today?

Will this “Agile approach” magically transform me into a “brilliant developer or tester or leader or whatever”? I am sure not! Do all our problems just disappear? Not really! Transparency, inspection, and adaptation are the pillars of this approach. And can I still make a mess of this approach? Of course, yes! I am a human being :-)

There is a nice thought from Einstein that says “we can’t solve our problems with the same thinking we used when we created them”. So, maybe this other approach is worth a try?