“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

• Is this satisfying the customer?
• Does the customer always want software continuously delivered?
• Do they want it early?
• Is there such a thing as too early?
• I think the customer would often happily trade off “Early” for “some semblance of finished”.  Early means re-testing.  Early means trying to use something with features you need missing.

“Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

– Is there actually just one customer?

– We should be working out ways to prevent requirements changing, and also to elucidate requirements early on.  

– Often, the requirements are only really apparent after some software has been written.

– But, often the requirements aren’t there because people haven’t sufficiently thought them through.

– There is no reward for coming up with decent requirements early on.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

– The reason for this is not get value delivered early on, per se.  It’s to get feedback loops.

– Also, the reason is that by practicing deployment early, you get good at it.

– But, there are hidden costs to deploying software (even with CI/CD).  People want to check it.  There are often forms to fill in, security reviews to do, and so on.   

– Software with only a few features might not be worth using at all.

Business people and developers must work together daily throughout the project.

– Except this happens never.  If they spent all their time with developers, they wouldn’t be business people.

– This is the single biggest failure of the agile process.  Business people (the people you need to help you) are always too busy to spend much time on the project.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

– Invariably, no project is an island.  Often you have to interact with system B, etc.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

– Developers hate talking to each other.

– People are often working in other countries, in other time zones.

– Face to face conversation is OK, but you need to write things down so that you remember what was said

– Often, everyone disagrees.  You sometimes need sign-offs.

– Lists are really useful.  

– Conversations are lost the moment they are complete.  No one ever remembers conversations the same.  Often, important people are excluded from conversations. 

– I conclude that this is very inefficient and very ineffective. However, it still might be for some use-case the most efficient and effective.  This is a shame.  

– Open source software gets built with almost none of this.  Explain.  

– Groupthink.

– Design By Committee. 

– There are clearly more productive ways to develop ideas. Our brains somehow do it (organising the thoughts of billions of neurons).  This is why art is a one-person-show.  If only we could access these organisational constructs.

– Right now I am in an online meeting.  _We have _a list of actions.  _We are taking _notes.  We are assigning blame.  We are capturing issues in a list.  It’s all kind of ad-hoc.  None of this is face-to-face communication.   There is a continuum here of online, offline, ad-hoc, recorded, signed-off, tracked, untracked communication.  Why?

Working software is the primary measure of progress.

– Which is measured how, exactly?

– What constitutes working? 

– How do we weigh the software we have working?

– Maybe this is counterproductive.  Less software is better than more.

– Bill Gates: “SLOC is like measuring completion of building aircraft by weighing it”.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

– This isn’t even a principle.  It’s just two sentences saying what you hope will be true about the world.

Continuous attention to technical excellence and good design enhances agility.

– I think this is another way of saying, get rid of technical debt.  

Simplicity–the art of maximizing the amount of work not done–is essential.

– I think this is another way of saying, get rid of technical debt.  

The best architectures, requirements, and designs emerge from self-organizing teams.

– If this is true, why do we need agile to tell us how to organise things then?

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

– This is really just the Lean/Deming/ISO9000 thing all over again.  Is this even true anymore?  Why do teams only concern themselves with their own processes?  Can’t teams learn from each other?  Why does each team have to re-invent the wheel.  

– Isn’t software supposed to be some unique thing?  Shouldn’t things change as they go along?