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?

Sam McAfee Building better technology leaders and teams

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.

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!

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.

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.

Sebastian Pereyro

December 5th, 2016

There is difference between wanting an honest answer to your question: is agile that good vs wanting to validate your mental idea of why the experiment with your clients or potential partners failed so far. Agile and it's benefits, no need to talk about, but blaming agile for not communicating effectively to clients is a little twisted. There is a lot of communication needed in a software development process, and the amount of communication needed depends on many factors, as a software solution provider we must learn about them so we can not only identify right clients but also continuously set and deliver expectations. Maybe you are right, these people had no idea about agile, or maybe they want you to work more than what you are paid for, who knows. At the end of the day the methodology does not eliminate the human interaction, agreements, and contracts. From my own experience, agile yes is that good, does it mean if a client gets mad, the methodology failed to realize the project, no.

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.

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.

Aleksey Malyshev Software Engineer at iTouch Biometrics, LLC

December 2nd, 2016

I know about scum and it's advantages because I worked as a Software Developer using scrum methodology for a few years. I also attended a scrum certification course. But when I wanted to use scrum with my would be customer, I had a very strange experience. Some person I knew contacted me and said that he needed a web site that would keep a database, where customers could enter certain data. We discussed the basic features and I started writing the web application. I created a login and registration parts where customers could register, enter their profile information and this would be stored in a database. They also received a confirmation e-mail about this registration. I was very proud of myself and demoed this to my "customer". I expected a positive feedback, but instead he started screaming, waving his hands and saying that "I just need a database, I do not need all this". He used to work with Excel sheets and used to see the lines of data before him. I was trying to explain that he cannot have a database without people registering first and this is a different screen that was not yet ready. But he only went more angry. I never communicated to real customers before - only as a part of a Software Developers' team and I still don't understand - what could have triggered such reaction?