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?

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.

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!



Sam McAfee Building Popup Incubators for Corporate Innovation Programs

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.

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:
Cxds1IqWgAAlKTx.jpg

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.

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

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?

Sam McAfee Building Popup Incubators for Corporate Innovation Programs

December 2nd, 2016

Couple thoughts, all speculation:
  1. The customer did not help to prioritize the features. Login may not be valuable.
  2. The customer didn't think you'd spend time on login was justified, because you didn't tell him how long it would take. Most customers see these utility features as "batteries included".
  3. You didn't start on the core value first. The database features would have been a better way to earn their trust at the outset.
  4. Could you have shown them a sketch first, or collaboratively designed the solution?

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

Aleksey, the good news is you are learning from your new sales experience - likely a lesson you won't soon forget.  Your answer to Sam's questions/comments are quite telling to me (i'm a sales guy with an engineering background).  "how can you identify a user if there is no login"? This makes perfectly logical sense to a developer.  My guess is your customer is not a developer and therefor it is not perfectly logical to them.  At a very high level, you customer is making a decsion based on emotion not purely logical so you need to first understand the 'stuff' behind the emotion. there is a long list of issues to touch on here, but we don't have the time so some of the basics are below.  I don't think the methodology (agile/scrum) is the issue.  Nor is the issue how far from SW dev this person is, although that is an important factor in how you approach him/her.  The issue is if you are going to be successful at selling your services you need to understand a bit about sales.  That starts with understanding the customer and his/her needs and responding accordingly.  Forget the "requirements" for a now, focus on understanding the customer and their needs and the 'specs' will come later. 


1. understand the customer: you and the customer may both think this is a waste of time, but it is still something YOU need to understand. who are they, what is their background (engineer? marketing? artist? sales? accountant? lawyer, CEO?). This will tell you a lot about how they think, what is important to them, how much time they have, do they like details or just high level summaries, etc?  
2. understand the customer's needs:  You need to understand the needs and you need to understand their view of their needs and the language/words they use to describe their needs. not the 'specs' but what they want this 'thing' to do and why.  You need to understand their business too if you have time. Does this person even know what Agile is? What is their understanding of how Agile works? what do they expect in terms of frequency and process?  This is where understanding the customer is important.  If s/he is technical don't assume you are both on the same page, but at least you may speak the same 'language'.  If s/he is an accountant or lawyer or marketer, etc. 'agile' and 'prototype' and 'database', etc. will likely have very different meanings to them. don't assume. 
3. parrot your understanding of his/her needs (product, process, costs, communication, requirements, etc. - everything you can think of) back using words they understand.  the 2 of you need to have an UNDERSTANDING not just speak the same language.  don't assume. The only way to reach an understanding is to feed your understandings back to the customer in terms/words they are comfortable with. use visuals too. If they have used another tool or website or product they like ask them to show you and explain what they like about it. visuals are important. 
4. build disposable mockup: Powerpoint, Prezzi, Lucidcharts, whiteboard, whatever. don't cut any code yet.  visuals are key. A picture is worth 1,000 words. use them a lot.  the whole objective here is to reach an understanding. Customers often have their own vision of what they think something should look like.  You are trying to pull these visuals out of their head so you can both see them. If you are good with mockup tools that product 'clickable' screens that could work too, but you need to be careful of customers' tendencies to get lost in the weeds.  People usually know what Powerpoint is and is not so there's not that tendency to want to get into the weeds and the discussion stays high level. 
5. review the mockup with customer and get feedback. 
6. incorporate feedback into mockup, get more feedback. rinse and repeat until you and customer agree on what rev.1 needs to do and look like. 
7. Only now should the coding process begin. Here's where things get a bit variable:  most customers who are not technical key highly on the visuals first - this is why you built the mockup in Powerpoint not Ruby in the first place (for example). So I would lean toward building some of the key visual components first (use the help of a UI designer if need be) and then build just enough functional layer and backend to give these few key screens some 'life'.  This may be a good place to use a tool that builds clickable screens/widgets.  Iterate on these visuals until you have solid customer buy in, ala agile.
8. Build balance of code knowing that customer will want to 'see' progress so keep the UI side of the dev ahead of everything else as you go thru your sprints. 

there's a few thousand additional details, but that gives you the framework. good luck. 

Rob G

December 2nd, 2016

Aleksey, your reference to showing a partially complete apartment is a good analogy. That is why architects/builders build mockups.  They use cardboard and foam and plastic and clay to build scale models that customers can SEE.  the customer understands that it's not real, but it gives them a visual and a comfort level needed to open their checkbook.  Is it a waste of time for the builder?  It certainly is time they are not spending digging footings and building forms and pouring concrete, but in the overall scheme of things it is a necessary step to setting proper expectations with the customer and avoiding surprises when the customer first walks in the door of their new home.  Selling a customer SW development project is no different.  There's a lot of work that goes into setting proper expectations that takes away from time cutting code, but it's almost always worth it in the end.