Hi there,

I recently had an interview, and one of the questions was about the Agile method. Since I'm a fresher and haven't worked in a company before, I wasn't familiar with it. I'm interested to understand more about it how the Agile method is used in project development.

To give you an idea of what I'm looking for, let's take an example involving developing a room temperature system using a temperature sensor and ESP32.

Could someone explain how the Agile method would be applied in this context?

Thank you!

 

Hi there,

I recently had an interview, and one of the questions was about the Agile method. Since I'm a fresher and haven't worked in a company before, I wasn't familiar with it. I'm interested to understand more about it how the Agile method is used in project development.

To give you an idea of what I'm looking for, let's take an example involving developing a room temperature system using a temperature sensor and ESP32.

Could someone explain how the Agile method would be applied in this context?

Thank you!

I could talk a lot about this, but I'll try to be succinct.

Agile refers to methodologies that are based on frequent iterations of development work, it focuses on customer feedback, adjusting requirements dynamically, frequent deliveries of beta code and frequent regular progress meetings.

It tries to maintain visible progress with regular customer engagement and leverages unit testing and collaboration more than more traditional approaches.

Many agile practitioners though mistakenly regard earlier forms of project management as outdated and slow, burdened by reams of paperwork and low visibility to progress.

In my experience, Agile aligns well with product development as opposed to project management, Agile is not about project management and is not well suited to traditional projects.

With agile one release frequent builds of a product, users can see, use and evaluate that and send feedback, that cyclic process drives the evolution of the code. This is great when the requirements are minimally defined because they don't need to be concretely expressed, they can be subliminal and emerge iteratively as the cycle progresses.

For project management agile isn't helpful IMHO. You could not build a Jumbo jet using agile, you could never put man on the moon with agile or build some complex software system like an equities trading system and so on.

Also note that some people seem to believe that more conventional project management is a "waterfall" process, it is not, these are different concepts, non-agile project management can in fact be very aggressive and fast paced and handle large teams and complex products, perhaps products that must meet certain industry standards or comply with legislation.

Agile is great for small teams, with relatively fluid requirements where access to users is easy and continuous, for other kinds of projects it is a bad fit, say the word "plan" to an agile team and they will stare at you in silence, mouths agape.

 

build some complex software system like an equities trading system and so on.

I beg to differ, having been involved on several major customer developments using various forms of Agile development. While I agree its most effective for certain user led elements of a system, such as the UI, it is applicable to backend processes across a wide range of environments by making system elements 'actors' in the process. The UK & Europe's leading online rail ticketing system was completely rebuilt and replatformed onto AWS using Agile approaches and development continues to be so today.

You could not build a Jumbo jet using agile

And yet SpaceX have built a very successful business using very similar approaches...

say the word "plan" to an agile team and they will stare at you in silence, mouths agape.

And yet project management is still applicable at a higher level. Agile <> unbounded! Prioritisation and boundaries still apply.

 

I beg to differ, having been involved on several major customer developments using various forms of Agile development. While I agree its most effective for certain user led elements of a system, such as the UI, it is applicable to backend processes across a wide range of environments by making system elements 'actors' in the process. The UK & Europe's leading online rail ticketing system was completely rebuilt and replatformed onto AWS using Agile approaches and development continues to be so today.


And yet SpaceX have built a very successful business using very similar approaches...


And yet project management is still applicable at a higher level. Agile <> unbounded! Prioritisation and boundaries still apply.

I'd suspect that much of what you say is true when there is top shelf management overseeing it. A competent project manager must measure and manage risk, that's a project managers core role, to manage uncertainty. If there is a firm handle on that then I'd expect a good outcome, whatever the daily methodology is.

Agile - in my experience - does not offer much when it comes to scheduling, levelling, estimating deliverable dates, critical path analysis and so on. Most Agile afficionados I've encountered balk at the idea of using MS project (say) or deciding if certain goals are achievable within a given budget and time deadline.

So I suspect in the case of the large project you mentioned there was more than "agile" involved, but I could be wrong. I have no idea how an agile project manager can show that some deadline is or is not achievable, agile itself doesn't cover this.

If I'm asked (as I have been, as a PM when I worked in London) "Can we get phase one functionality operational, delivered within ten months?" then I know exactly how to determine the answer, but agile is useless here I think.

 

I'd suspect that much of what you say is true when there is top shelf management overseeing it. A competent project manager must measure and manage risk, that's a project managers core role, to manage uncertainty. If there is a firm handle on that then I'd expect a good outcome, whatever the daily methodology is.

Agile - in my experience - does not offer much when it comes to scheduling, levelling, estimating deliverable dates, critical path analysis and so on. Most Agile afficionados I've encountered balk at the idea of using MS project (say) or deciding if certain goals are achievable within a given budget and time deadline.

So I suspect in the case of the large project you mentioned there was more than "agile" involved, but I could be wrong...

Of course, no project of any reasonable complexity got delivered without effective project management. But PM in an Agile environment involves some different techniques and to say Agile has no planning is incorrect - the process of breaking tasks into user stories, estimating and prioritising them is a form of planning. Measuring the quality of that process - how accurate was the estimate, how effectively was the story delivered, etc are valid management stories - ie PM goes Agile too. As teams get more experienced and user stories get better defined estimates get more accurate to the point you don't estimate any more, you compare story complexity to a database of previous stories and pull out an estimate from that. Projects of several hundred or even thousands of 'user' stories can and hav been envisoned and delivered. PM tools still apply - stories have ancestors and dependents - things still have to be done in certain sequences... checkpoints where a specific set of stories must be delivered together in a (weekly/monthly/etc) 'release' still exist.

 

It would greatly appreciate if you could provide an example of a project while discussing the Agile method. This approach would be more helpful for me to understand the method, as the current discussion is going over my head.

 

Of course, no project of any reasonable complexity got delivered without effective project management. But PM in an Agile environment involves some different techniques and to say Agile has no planning is incorrect - the process of breaking tasks into user stories, estimating and prioritising them is a form of planning. Measuring the quality of that process - how accurate was the estimate, how effectively was the story delivered, etc are valid management stories - ie PM goes Agile too. As teams get more experienced and user stories get better defined estimates get more accurate to the point you don't estimate any more, you compare story complexity to a database of previous stories and pull out an estimate from that. Projects of several hundred or even thousands of 'user' stories can and hav been envisoned and delivered. PM tools still apply - stories have ancestors and dependents - things still have to be done in certain sequences... checkpoints where a specific set of stories must be delivered together in a (weekly/monthly/etc) 'release' still exist.

I'm sure there's much validity in what you say here Irving. I'm speaking of situations like can we deliver and have some system operational in time for some immovable deadline? I worked on two such projects back in London, one was the well know Y2K deadline and the other was the introduction of the Euro in Jan 1 1999 both of these were immovable, non negotiable deadlines.

I'm not convinced that the typical agile techniques and tools can confidently answer these kinds of achievability questions, that's my main gripe I suppose. A tool like project can answer these kinds of questions because it represents not only individual task estimates but task inter-dependencies, estimated efforts are simply insufficient to tell a team if they can or cannot reach some target.

Thankfully I don't work as a PM any more, but I recall several times telling executive management that some project cannot be delivered by some date, when they asked me why, how was I so sure, I'd show them the MS Project plan printed out on US "Ledger" sized paper. I'd make them look at it and I'd ask them, "which of these tasks do you not want to do, because unless we remove some we can't hit the deadline as you can see".

This was always understood by them, it was a great way to prove deliverability rather than just base it on feelings and optimism.

 

To give you an idea of what I'm looking for, let's take an example involving developing a room temperature system using a temperature sensor and ESP32.

Could someone explain how the Agile method would be applied in this context?

Its almost too simple a project, but here's a stab at it...

Lets assume you have a temperature sensor, an MCU, a touch-sensitive display and a fan heater. You might start by defining an actor 'user' and a user story "As a user I want to see the current room temperature on the display". This would be broken down into sub-stories with a new actor 'MCU' eg "As a MCU I want to get the current temperature from the sensor" and "As an MCU I want to show the current temperature on the display". These are deemed small enough to estimate and result in two subroutines getTemperature() and showTemperature(), and the loop { float t = getTemperature(); showTemperature(t); }

Other user stories would refine how the temperature display was formatted, building on these basic ones.

Another set of stories would look at how the system allows the user to make adjustments to temperature resulting eg in <up><down><set><cancel> on-screen touch buttons.

A further set of stories would link the difference between current and set temperatures to control the fan heater, again initially as simply on & off and then adding more control aspects, proportionality, derivative, etc to manage the control loop.

Hope that helps...

 

I'm not convinced that the typical agile techniques and tools can confidently answer these kinds of achievability questions, that's my main gripe I suppose. A tool like project can answer these kinds of questions because it represents not only individual task estimates but task inter-dependencies, estimated efforts are simply insufficient to tell a team if they can or cannot reach some target.

As I said above, Agile doesn't preclude dependency-management, that still exists and needs addressing. In my mind, a high-level Agile approach can be a better way of identifying the minimum that needs to be done to meet the deadline. I've worked on large 'waterfall' projects that missed out so much (and questionably by accident or design) that their estimates had little basis for validity. Its true that applying Agile to some legacy projects is hard, but then its often hard because of lack of knowledge of the legacy system.

BTW very few deadlines are 'hard'. My experience of Y2K projects was that few met the deadline and there was plenty of mitigation and workarounds in place if problems arose. Now a truly hard deadline I worked to, and we went down to the wire on, was the ESA Giotto project in 1985 - miss the launch window on that and its a 76y wait to try again...

 

I beg to differ, having been involved on several major customer developments using various forms of Agile development. While I agree its most effective for certain user led elements of a system, such as the UI, it is applicable to backend processes across a wide range of environments by making system elements 'actors' in the process. The UK & Europe's leading online rail ticketing system was completely rebuilt and replatformed onto AWS using Agile approaches and development continues to be so today.


And yet SpaceX have built a very successful business using very similar approaches...


And yet project management is still applicable at a higher level. Agile <> unbounded! Prioritisation and boundaries still apply.

I think success with Agile is heavily dependent on staying within the process so there aren’t any “leaks” that can require knowing “secrets” in order to avoid strange and unexplainable system level behaviors; and to properly identify the customer and stakeholders from the start and having a product owner that understands their rôle as liaison between these parties and the developers.

Agile should allow for short meetings, quick agreement on solutions, and solid tracking of the dev team’s output to the agreed feature set and budget. It doesn’t on its own prevent feature creep or scope creep but if it is adhered to as a framework, it can do this.

It is the job of the customer to specify the functionality, and the stakeholders to set priorities and boundaries—including time and money budgets, and deadlines. It is the job of the product owner to understand these things, as well as the constraints the developers are working under, and communicate these things in both directions.

If these things are done, it will necessarily include elements of project planning and its tools—a competent product owner working a project where, say, Microsoft Project, is being used by the stakeholders will also be using it as the interface to them even if the developers never see a Project screen or document.

It has been my experience that there are many potentially effective methodologies for large project development but all share one thing: the need to actually use them. This always requires the up front effort to define all relevant terms, document all rôles and responsibilities, and get explicit sign off on the resulting scope, requirment, and timeline documentation.

In traditional project management, a good project manager is an activist concerning project progress, and this is good, but it can make the project schedule the primary focus, reducing the quality of the delivered product—or even creating an on-time failure.

To me, it seems the value of agile is the addition of the product owner rôle which allows a customer-focused methodology on one side and a developer-focused methodology on the other. It allows those writing code to be agile and only applies the stagnating effect of more traditional project management to the deliverables, where that rate-limiting change management is a good thing.