SCRUM · Agile

Is Agile really that good?

Aleksey Malyshev Software Engineer at iTouch Biometrics, LLC

November 27th, 2016

Agile is promoted by many as an advanced and customer-centered way to build software products. However I realized that when I show a partly built product to a customer, who is unfamiliar with software development process, he might go berserk. Like you don't show a partly built apartment block or dirty, undecorated rooms with concrete walls to someone who is going to buy an apartment. If she is not familiar with the construction process, she might be shocked by the scene. What do you think?

Rama Kaldindi Cloud Solutions Architecture Consultancy / Engineering Leadership / Tech. Product Management

November 27th, 2016

Great topic/question and something that I have experienced being contested time/again. Here are my thoughts:
- First and foremost, Agile is much more than a process. A successful Agile practice involves cultural/mindset changes (specially those migrating from more traditional SD processes) across the board i.e.. across all stake holders including customers. Deep down, its about embracing the fact that any reasonably complex software product development involves very many unforeseen (even when you have a very well defined vision). These may be technical, functional, non-functional and more importantly changed requirements/priorities etc. In short change is constant. A good Agile practice allows everyone to deal with such changes in optimal ways while ensuring incremental quality software development. This is just one way of thinking and  I don't claim to be Agile coach here (and besides there is lot of good literature on the subject). But its important to understand this philosophical difference to set the context. To your example of apartment, the first step would not be to take the potential customer to construction site and shock him with unfinished work. Rather, it would be to showcase the vision (e.g architectural designs, virtual walkthrough, model house, prototypes etc.). For products, the analogy would be MVPs, prototypes, etc. Similarly different phases of construction will involve different smaller (and fairly independent ) projects eg. the flooring, the interior designs, the wall colors, windows, doors etc. Note that each such 'components' have their own lifecyle that can be developed/tested independently and incrementally. This is very analogous to a software product development using Agile where each team sprint strives to deliver a completely testable and deliverable component. Now even though the 'apartment' may not be complete, every phase of construction (ie. sprint) allows a customer to see a completed aspect (may be a flooring, maybe the windows etc.) . The idea behind such smaller incremental deliverables is to allow the stake holders to chime-in and provide timely feedback such that if there is any change desired , it can be incorporated without bring the whole building down :).
Just my thoughts!

Nabeel Nawaz

November 27th, 2016

This is a fair point, and I would highly recommend you be aware of the consequences of introducing a new methodology and know why you introduce it before you do. Agile generally fits projects where requirements are 50% known and likely to change, and where there is some technical complexity involved. The customer should know right at the beginning what to expect and how often they will be involved in providing feedback to the process, this is an important stakeholder buy in to achieve at the beginning. Hope this helps.

Akhilesh Choudhary Digital Marketing Manager at Sphinx Solution Pvt. Ltd.

November 28th, 2016

A 2015 study by Standish Group across 50,000 software projects… 
  • Only 29% of projects were successful
  • 52% had major challenges
  • 19% failed completely
And it was the reasons:
  1. The wrong development partner/team
  2. The wrong development model. (Agile vs. Waterfall) 
  3. Poor understanding of Software Development.
  4. Unrealistic/Risky Goals for Development.
  5. Wrong expectations set by Developer.
So the very second reason was using a wrong development model.
Now I am giving you some stats:

1. Revenue

The iterative nature of agile development means features are delivered incrementally, enabling some benefits to be realized early as the product continues to develop.

2. Speed-to-market

Research suggests about 80% of all market leaders were first to market. As well as the higher revenue from incremental delivery, agile development philosophy also supports the notion of early and regular releases, and ‘perpetual beta’.

3. Quality

A key principle of agile development is that testing is integrated throughout the lifecycle, enabling regular inspection of the working product as it develops. This allows the product owner to make adjustments if necessary and gives the product team early sight of any quality issues.

4. Visibility

Agile development principles encourage active ‘user’ involvement throughout the product’s development and a very cooperative collaborative approach. This provides excellent visibility for key stakeholders, both of the project’s progress and of the product itself.

5. Risk Management

Small incremental releases made visible to the product owner and product team through its development help to identify any issues early and make it easier to respond to change. The clear visibility in agile development helps to ensure that any necessary decisions can be taken at the earliest possible opportunity, while there’s still time to make a material difference to the outcome.

6. Flexibility / Agility

In traditional development projects, we write a big spec up-front and then tell business owners how expensive it is to change anything, particularly as the project goes on. In fear of scope creep and a never-ending project, we resist changes and put people through a change control committee to keep them to the essential minimum. Agile development principles are different. In agile development, change is accepted. In fact, it’s expected. Because the one thing that’s certain in life is change. Instead the timescale is fixed and requirements emerge and evolve as the product is developed. Of course for this to work, it’s imperative to have an actively involved stakeholder who understands this concept and makes the necessary trade-off decisions, trading existing scope for new.

7. Cost Control

The above approach of fixed timescales and evolving requirements enables a fixed budget. The scope of the product and its features are variable, rather than the cost.

8. Business Engagement/Customer Satisfaction

The active involvement of a user representative and/or product owner, the high visibility of the product and progress, and the flexibility to change when change is needed, create much better business engagement and customer satisfaction. This is an important benefit that can create much more positive and enduring working relationships.

9. Right Product

Above all other points, the ability for agile development requirements to emerge and evolve, and the ability to embrace change (with the appropriate trade-offs), the team build the right product. It’s all too common in more traditional projects to deliver a “successful” project in IT terms and find that the product is not what was expected, needed or hoped for. In agile development, the emphasis is absolutely on building the right product.

10. More Enjoyable!

The active involvement, cooperation and collaboration make agile development teams a much more enjoyable place for most people. Instead of big specs, we discuss requirements in workshops. Instead of lengthy status reports, we collaborate around a task-board discussing progress. Instead of long project plans and change management committees, we discuss what’s right for the product and project and the team is empowered to make decisions. In my experience this makes it a much more rewarding approach for everyone. In turn this helps to create highly motivated, high performance teams that are highly cooperative.

Now its upto you how you want to see your project running.

Please note: There are implications And there’s no magic bullet for software development.

Sam McAfee Business model innovation and digital transformation

November 28th, 2016

My first reaction was "you're kidding, right?!" Ha ha.

Seriously, though, 17 years into software development, and having practiced agile from about 2003 on, with hundreds of projects under my belt, I have not yet found a project that was worth the trouble and overhead of Waterfall.

Even when the "requirements" are quite known, and the solution is pretty clear (which only happens if you're replacing an existing system), you would still want to build in smallish pieces, tracking your work with a kanban or sprints, and ship finished chunks to a staging server as they are completed. There is no downside I can think of to working this way, and that's the essence of Agile.

Plus, the technical practices of Agile (TDD, continuous integration, etc.) almost make the whole thing worth it on their own. Working this way just produces better code. I have never found a waterfall project that was also doing XP style development, though I suppose it's possible. The forcing function of iteration puts pressure on iterative styles of coding, so they kind of go together.

And I have never met a client or customer who didn't want to have transparency into the building process, who wasn't curious about how the magic happens. They have nearly all been open to seeing partially completed work because they understood (after I explained, sometimes) that they get to give early feedback and, optionally, change our direction based on what we show them. It's extremely valuable to see the product before it's completed.

Rob G

December 4th, 2016

Aleksey, i suspect your business is a bit different than Apple. 

Aleksey Malyshev Software Engineer at iTouch Biometrics, LLC

December 2nd, 2016

Rob, Thanks for your contribution. What you are saying about comparing S/W to construction is different. You are talking about models, some design documents maybe, visuals. When a customer sees an apartment model on the pictures, on VR maybe these days, it looks beautiful. Have you ever been on a construction site or saw an undecorated apartment? Probably not, because I remember the kind of shock I experienced when I saw my undecorated apartment for which I paid tons of money. In a construction business you better show her a complete picture, because otherwise you may ruin the impression. Even if it's not perfect it can be fixed.

Aleksey Malyshev Software Engineer at iTouch Biometrics, LLC

December 2nd, 2016

1) Maybe I am missing something. How can you identify a user if there is no login?

3) Database was done before. But that's just a schema and a sequence of SQL statements. Someone who is not familiar with the database design would probably get even less from it.

4) Obviously we had a sketch and discussed all steps.

I just think there are people who are so far from Software Development processes that they do not understand basic things and demoing an incomplete product will not help. Hence was the question. I think sometimes there is "I don't care how you do, I need the result" attitude exists. Some people see participation in every step of the process, which scrum suggests, as a waste of their time.

Rob G

December 2nd, 2016

yes, i've been on plenty of construction sites - worked my way through engineering school as a construction grunt.  That 'shock' you experienced when you saw your unfinished apartment is likely similar to what your customer experienced, only it sounds like you were perhaps still 'pouring concrete' when s/he started yelling.  It's still about setting expectations.  You know when you have spent days or weeks designing the data model and building and testing the backend and business logic what effort it took and what challenges you faced and overcame.  You know that your algorithms are elegant and efficient.  Your customer has no clue.  just like the builder knows that he had to drive pilings 30 feet into the muck in the rain and move a lot of dirt and tie a lot of steel and those super straight forms he built and the time he took to accurately level and square all his forms will make life easier for the framer and the roofing contractor and the window guy, but the customer has no clue.  The customer could care less and likely have no concept of what went on under ground unless they were a carpenter in a former life, in which case you should know that up front.  All they care about is how it looks and if it's quiet and the furnace works when they turn the thermostat up.  selling SW is the same.  It's about setting proper expectations. 

Aleksey Malyshev Software Engineer at iTouch Biometrics, LLC

December 4th, 2016

Rob, yes. I have to admit, I am more of wantrepreneur. BTW, I called these guys "customers", actually they were my potential business partners. I tried to work with them, but realized I cannot work with people who do not appreciate my work.

Aleksey Malyshev Software Engineer at iTouch Biometrics, LLC

December 6th, 2016

Sebastian, I wanted to facilitate a discussion about limitations of Agile, not a Q & A session. This IS a discussion section, right? I presented an example there in my opinion it did not work. You say - it's my fault. Well, maybe. I presented another example - consumer products, like Apple. Imagine if Apple would show a prototype to the public and ask - "is it good"? How do you like? Then next spring and so on. I received a response that it is none of my business. That's obviously true. But can't we discuss this? Or is it NOT a discussion forum? Then, I am sorry for misunderstanding.