5 Signs You Are Doing bAgile (instead of Agile)
Have little time and would watch a video instead? Click on the video link below!
I don’t think I can say that I have been bred and brought up in the waterfall style of things. Hence I will probably not appreciate what the waterfall vs Agile difference feels like. But, I have seen a LOT of what I like to call bAgile. bAgile is a hurried portmanteau of bad and Agile. Some have christened it as frAgile or even wAgile. But, what I have seen are Agile practices which are actually re-purposed waterfall concepts and distorted scrum practices- all window-dressed as Agile.
Let me make something clear. Waterfall is not bad. I can’t remember who said this, but well done waterfall is much better than badly done Agile. Why? Because, you know what you are signing up for. In fact, there are also projects that go from Waterfall to wAgile to pure Agile. It is great when that transition is deliberate. What hurts me is when we think and act like we are Agile, but without the inclusion of some key concepts central to it. Without the key concepts, the bad creeps in.
Here are some signs that you, or someone you know, are doing bAgile instead of Agile:
1) The business analyst or product owner speaks to the customers and writes the user stories which are then picked up for development (maybe even after some brief discussions)
I have been as guilty of this as anyone else and it still shocks me that proudly Agile organisations follow this. A quick look up to any definition of a user story tells us that it is about card, conversation and confirmation (Taken from Mike Cohn’s description of user stories: https://youtu.be/6q5-cVeNjCE). If we are writing stories in a dark room, isolated from the dev world without the second C, then, we are simply writing the previously dreaded SRS in the form of many smaller SRSs.
2) One person writes the acceptance criteria and presents them for getting agreement
This one’s a bit similar to the one above but it addresses the third C in the user stories- confirmation. I have seen a lot of BAs, QAs writing acceptance criteria which are then presented to the customers and developers for agreement. Here is a trick- if you show people something and ask them whether they agree to it or not, chances are that you will never get them to think about disagreements. It is a lot easier and lazier to just agree and get an activity done. We, then, miss out on ideas and insights that come when you come with a blank paper instead and a few pointers and say, “Let’s discuss the acceptance criteria”.
3) The customer signs up for a fixed scope and fixed cost. Fixed scope here means the signing off on requirements detailed to the lowest level of granularity.
Project planning is hard. Everyone wants to play as safe as they can. But paradoxically, you, as a customer, sign up for much greater a risk when you sign up for fixed scope and fixed cost. Why? Because of software intangibility, the actual realisation of what you truly want comes in when some working software starts to take shape. So, the scope always goes through changes (small and big) as you course the project timeline. The better and Agile-centric idea is to sign off on a high-level feature list and a certain number of iterations. I have seen some RFP writers finding this hard to swallow, but fixing one of those parameters and not both, really helps the project management to go smoothly as well. Unfixed scope also helps your product to learn and improve from user feedback, which is one of the key drivers in Agile.
(That does not mean the scope itself loses all shape and definition — something that some project managers fear for. More on this coming very soon..)
4) User feedback via show-and-tell drives the backlog
Sprint demos are a celebrated ceremony in Scrum. The customer sees that things are on the right track and hence, we have confidence to plow through. In the previous days, many waterfall teams also produced demo-able software periodically. But, that, unfortunately, did not do much to prevent scope-creep and scope-burst later on. That won’t change with Agile unless users use the software instead of just seeing it. Remember about how developers would mostly agree to the acceptance criteria but on the other hand, provide ideas and opinions when encouraged to discuss without a biasing list? Well, users would also say things like, “This looks fantastic/lovely/beautiful (insert your choice of adjective)” but using them would expose the true insights for the team to consider into the backlog refinement.
5) There is no reference story for the minimum story points
This one is a bit pedantic, but in my opinion, very crucial to actually use story points properly. I have seen new devs, old devs, not-so-old devs being asked “What points is this story?” That’s it. There is no base story stated. This is where someone says 5 and another says 3 and they debate. However, the base of the estimate is not well established in many projects. Without that, devs are simply trying to express the number of person hours in a different language. That’s not story pointing. That’s even worse than absolute estimations. If your project does not have a base story, which every dev must know before getting to estimate anything else, then you may be bAgiling.
In conclusion-
Are you engaged in any of the above activities? If yes, then I have some good news. The recognition of it has already solved some part of the problem. You know now what needs work :) I wish I didn’t do these things for so many years myself, but then, I would have never really grown to appreciate what being on the other side feels like. Happy Agiling!
