Episode 2: Thoughts on Agile / SCRUM – The benefits and drawbacks

It’s quite obvious that the current popularity of being Agile has a tremendous impact on how companies want to do business, and who could blame them? The problem is that many companies want to start doing projects in Scrum right away, without rethinking their work culture, without verifying if they are ready to do it properly and most importantly without giving it time to become ready. I’ve had the opportunity to work as an IT analyst on a Scrum driven project; already during the kick-off it turned out that:

• the product owner would be available 30-50% of the time, because he had other projects to manage

• the sprints would be 4-month iterations consisting of a design, implementation and testing stages (sounds familiar?)

• the daily scrum would be a once-a-week hourly status.

The funny thing is, this example of how NOT to implement Scrum got me interested in how to do it properly.

So where to begin? First of all, Agile and Scrum are not for everyone! In many cases, when implemented improperly, it can do more harm than good. So, before you give in to the trend, ask yourself a couple of questions:

• How flexible is your product scope? Do you see a possibility of launching a minimal working version of it and working on making it better with every iteration?

• Do you have the support and trust from your management, your peers and all the necessary stakeholders?

• Do you have room to make mistakes and learn from them? Is your working environment open to change and seeking better ways of working?

Managing scope and deadlines is one of the fundamental challenges, when starting a project using Scrum. Ideally, a product backlog would be constructed in a way which consists of an MVP part at its very top, followed by remaining stories and epics. The Minimum Viable Product is the least possible scope of a product that would be valuable to a product owner and releasable. The idea is to get the product out as soon as possible, to gather feedback and improve on the next iterations. This often requires changes to the product backlog but helps us to avoid implementing features that are obsolete. The problem is that many stakeholders have an “all or nothing” or “the whole product is our MVP” approach to building products. Agile would not be for them because they would lose one of the key values that agile brings, which is the possibility to quickly react to change and flexibility. The product owner gains the possibility to launch a product in an expected time period to benefit from an identified business opportunity, instead of continuously shifting the launch date and potentially losing the sense behind launching that product at all. Timing is everything!

Building an agile culture, which nourishes trust, gives freedom and fosters creativity is another aspect. A working environment, where people are resilient to change is a challenge and that concerns both the teams and the management. Starting from the management: that’s the biggest change. The management needs to give space to the teams, needs to trust the teams and give them the benefit of the doubt. This will allow the teams to grow, learn from their mistakes without being judged and become more self-organized. This is a combination which should allow the teams to elaborate a mean to deliver the expected result in the best way they know. No micromanagement would be necessary and the teams would become more appreciable at the same time! Less frequently the issue concerns the team or the team members. The reason for this is usually different, because the management’s resistance to change is associated with losing control, whereas certain team members are opposed to doing Scrum (for example) because “the current process is working fine so why change?”. Yes, so why change? Continuous improvement is a big part of Scrum and Agile. We should always seek ways not only to improve the product but the process behind it. Talking with team members and asking a lot of “why’s” is the best way to address such issues, since it allows to understand the root cause behind their resistance; furthermore the root cause can often be lack of understating of agile and what changes it brings, and that’s when workshops / trainings come in handy.

What everyone should understand is that being Agile does not mean the organization will save a lot of money. So if you’re not ready to invest, then it’s not for you. Implementing Scrum requires a lot of discipline and time, during which that discipline will grow but it doesn’t mean that it is a cheaper approach to product delivery… However, it does mean that products will be delivered more efficiently. Eliminating waste, which is a big part of Lean, can also be observed when following 2 of the Scrum principles: Inspect & Adapt. Thanks to those 2 principles, Scrum will allow you to notice what is important in your product, as well as learn better ways of fulfilling your product vision; meaning you will not waste time and resources on useless stuff.

Once properly implemented Scrum is very rewarding, both to the product owner, the management and to the teams. All of the product owners I’ve worked with were extremely appreciative of the benefits, such as flexibility and reaction time to market needs. The teams on the other hand, were happy with the possibility to be creative and fully responsible for the value that they deliver and observe with every iteration. The management and the stakeholders were meeting their goals more consistently. The only question that was left afterwards was, how do we scale this…