Manifesto for Agile Corporate Finance

Suppose that in 2001, seventeen corporate finance professionals came together at a ski lodge, and wrote a document called "Manifesto for Agile Corporate Finance", and one of the values promoted is "Cash on hand over receivables" (analogous to 'working software over comprehensive documentation).

How bizarre would it be if the values espoused in their manifesto then gets used as bedrock foundations for: the right way to build software, run projects, and a host of other activities unrelated to corporate finance?  

I also wonder if everyone would be calling it the "Agile Manifesto" for short, omitting the "for Corporate Finance", thus obscuring its intended domain.

It's "Manifesto for Agile Software Development"

Whenever someone refers to the "principles of Agile" and claims these principles are found in the Agile Manifesto, always remember the manifesto is called "Manifesto for Agile Software Development".

It's not "Manifesto for Agile Anything".  It's not "Manifesto for Agile Marketing".  It's not "Manifesto for Business Agility". It's not "Manifesto for Agile Project Management"

It's a manifesto for agile software development. 

The manifesto was written by software developers to promote better, faster, more enjoyable, higher quality software and software development experience.

Agile vs Waterfall

Often heard: "What you experienced was not true Agile."

Never heard:"What you experienced was not true Waterfall."

Recommended New User Story Format, Because New

There's a playful way of explaining the reason why one does something. The argument ends with the rationale "because <noun or adjective>."

We can recommended this as new format for user stories, because it's aligned with how people speak these days.

AS A phone user, I WANT TO upload photos in one click, BECAUSE one-click!

AS A bank customer, I WANT TO see my balance on my phone, BECAUSE money!

***

No Such Thing as ‘The Four Agile Values’

Everyone should just stop referring to ‘The Four Agile Values’ or ‘The Four Values of the Agile Manifesto” 

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.

Why? Because this so-called 'The 4 Agile Values' does not exist.

Consider the following:

1. There Are 8 Values Listed in the Manifesto

If by ‘4 Values’ is meant the following: 

1. ‘Individuals and interactions’, 
2. ‘Working software’, 
3. ‘Customer collaboration’, and 
4. ‘Responding to change’

Then please note we have eight values listed (not four): 4 values on the left plus 4 values on the right, making a total of eight values.

The manifesto affirms: 'there is value' to the four items on the right. So if you regard the items on the left as values, you need to regard the items on the right as values too. We value family over careers. Does that mean we don’t value careers?

The authors did not put worthless items on the right: 'Customer collaboration over cheating the customer'

They also did not say 'Individuals and interactions, etc' trump everything (see point number 3 below).

2. The 'Values' Are Merely Trade-off Preferences

If you consider the 4 values to be the 4 listed earlier, then please note that these are simply statements of relative value, not of highest value.  Hence, they do not merit the definite article 'The'.

Read them as saying, “between responding to change and following a plan, we regard the former more important”. (How much more important is not indicated).

The signatories shared interesting trade-offs they have ‘come to value’, trade-offs that upend (what they consider) the normative trade-offs in software development. No suggestion is made that these are the only trade-offs they value, nor even the most important ones, but merely the tradeoffs that make their approach different. 

3. The Principles List Even More, Even More Important Agile Values

The Twelve Principles call out other ideas important to the signatories (and by extension to Agile development): customer satisfaction, continuous delivery, frequent delivery, motivated individuals, support, trust, face-to-face conversation, measure of progress, working software, sustainable development, technical excellence, good design, simplicity, best architecture, best requirements, best designs, team effectiveness. Some of these arguably carry equal, arguably even more, weight to the ‘4 Agile Values’.

The first sentence of the manifesto also mentions two ideas valued by the signatories: 'doing it' and 'helping others do it'

4 The Manifesto Never Talks About 'Values'

The manifesto never uses the word 'value' as used in the phrase 'The 4 Agile Values'. In that phrase, 'Value' is a noun that means 'something intrinsically desirable'. These refer to ideas like 'emotional intelligence', or 'integrity'.

The manifesto says that the signatories have come to ‘value’ A over B. The word ‘value’ here is not the same word as the noun. This verb means ‘to consider highly’, as used in 'we value efficiency'. Valuing something does not necessarily turn that thing into a 'value': I have come to value good quality leather shoes over cheap shoes, but good quality leather shoes isn't one of my values.

The manifesto uses 'value' as a noun when it speaks of "there is value..." but this noun carries the different meaning of 'having worth' (the opposite of the word 'worthless'), like gold has value to a jeweler, but dirt does not.

In short, the manifesto never talks of 'values'.

5. Surely There Are Now More Than Four!

The verb tenses in “we are uncovering…” and “we have come to value” indicate that the list is preliminary, and describes a point-in-time state of affairs that is hoped will continue onward. It would be surprising (shocking) if they meant for it to be the final uncovered preferences for all time (or even for a few years).

Referring to 'The 4 Agile Values' after so many years is a serious indictment of the movement, for it means no new Agile-specific value trade-off have been ‘uncovered’ since 2001. (Calling them ‘The Original 4 Agile Values’ would still be wrong -- see points 1 and 2).

Fnally, referring to 'The 4 Agile Values' surrounds them with an aura of being untouchable and unchange-able.

So please stop talking about 'The 4 Agile Values', because doing so promotes misunderstanding and inhibits uncovering of new 'better ways of developing software'

 

Milestone Sprint

 Idea: a sprint that when it delivers its increment, the overall delivered product has reached an important milestone.  It could be that it has reached an MVP stage and can be delivered (though would not be commercially successful), or can be deployed and actually deliver new capability.  

Sprints are all meant to ‘deliver’ business value, but realistically most of them just showcase the increment.  The increment often remains unusable.

Agile Uber Alles

How did words from a 2-day meeting at a ski lodge, on principles for a new approach to building software become such gospel that they are now being used as principles to run whole corporations engaged in activities nothing to do with software?   The Agile Manifesto principles are not even the best choice for all types software development.

This is a fascinating phenomenon worthy of study.  At the very least it can confirm theories about diffusion of untested practices and fads. A generation from now, indiscriminate and inappropriate applications of the Agile Manifesto will be seen as something of a Tulip Mania. Or a YAF.  Yet Another Fad.

Agile Diversity Manifesto

To accommodate the (irrational) demands for diversity that is proportional to the wider population, should the Agile Manifesto be rewritten by a new group more diverse than the original set of: 

1. White 
2. Middle-aged
3. Men
4. Software Developers

Scrum Fundamentals – Iteration, Sprints, and Feedback

I said in the previous post that one of the biggest problems brought about by a waterfall approach is the lack of feedback.  The future users of the software get to see the software only when it is finished, when the opportunity to provide valuable corrections and suggestions are practically over.

Not only is it too  late (or too expensive) to modify the program, the software is often actually unusable.  Scrum directly addresses these problems by mandating that software must be developed iteratively, in iterations, and the at the end of each iteration, the software must be demonstrated to the stakeholders to get their feedback. 

Scrum calls its iterations Sprints.  Scrum recommends that Sprints be between 2 to 4 weeks.  Whatever duration you choose, all the Sprint must be always the same duration.  If you go for 2 weeks, then all the Sprints must each be 2 weeks. 

This is in the ideal case of course, in practice a Scrum team that is just beginning to learn the ropes can choose a tentative duration to try out (say 2 weeks).  If the team finds that 2 weeks is too short, they are free to adjust it (and all future Sprints).  If they find that it suits them, they stick to it.

The key thing is to establish Sprints as a regular occurrence, like a heartbeat.  Sprints of different lengths are like arrhythmia, with all the unpleasantness it brings.

The completion of each Sprint produces a finished subset of the product.  The ideal is to deliver a working subset, preferably something that can be shipped.  In practice this is not so easy to achieve, for some functions rely on other functions which may not fit in the current Sprint. 

For example, an online store may include such functions as allowing the customer to search for products, order products, apply discounts, and have them shipped to an address of their choosing.   Very often all of these functions cannot be built within a single Sprint. So which ones to build in order to product a shippable subset?

The Scrum team (together with the Product Owner) decides which functions to build in order to deliver working software.  One such option could be to simply include only the search for products function.  So at the end of the Sprint you end up with software that searches for products, and does nothing else.  That is an acceptable choice.

It is far better than deciding to build all the user interfaces for all the above functions, but not have them work.  If you do this, what you get at the end of the Sprint is not working software, rather, you end up with a glorified series of screenshots.

Back to feedback.  At the end of each Sprint is a Demo of what was built.  The Scrum teams demonstrates the current product so that the Product Owner (and other stakeholders) can review it and give their feedback.   Is this what was envisioned?   If it was, was it what you wanted?  Very often, once we see the the incarnation of what we said we wanted, we come to the realisation that that is not really what we wanted.

The purpose of the Demo is NOT to show the Product Owner that the Scrum Team is working hard.  No.  The purpose is only feedback regarding the product.  (There is a time when evaluation of the Scrum Team occurs, but this is not that time, and I will talk about it later).

If there is one thing that feedback causes, it is change.  You can be sure that the feedback will result in changes, changes to what the software will do, and changes to what it is currently doing.

So what do we do with the changes?  I’ll talk about that in the next post.

Scrum Fundamentals – Iterations, Sprints, and Feedback

I said in the previous post that one of the biggest problems brought about by a waterfall approach is the lack of feedback.  The future users of the software get to see the software only when it is finished, when the opportunity to provide valuable corrections and suggestions are practically over.

Not only is it too  late (or too expensive) to modify the program by then, the resulting software is sometimes not only bad, but even unusable. 

Scrum directly addresses these problems by mandating that software must be developed iteratively, in iterations, and the at the end of each iteration, the software must be demonstrated to the stakeholders to get their feedback. 

Scrum calls its iterations Sprints.  Scrum recommends that Sprints be between 2 to 4 weeks.  Whatever duration you choose, all the Sprint must be always the same duration.  If you go for 2 weeks, then all the Sprints must each be 2 weeks. 

This is in the ideal case of course. In practice a Scrum team that is just beginning to learn the ropes can choose a tentative duration to try out (say 2 weeks).  If the team finds that 2 weeks is too short, they are free to adjust it (and all future Sprints).  If they find that it suits them, they stick to it.

The key thing is to establish Sprints as a regular occurrence, like a heartbeat.  Sprints of different lengths are like arrhythmia, with all the unpleasantness it brings.

The completion of each Sprint produces a finished subset of the product.  The ideal is to deliver a working subset, preferably something that can be shipped.  In practice this is not so easy to achieve, for some functions rely on other functions which may not fit in the current Sprint. 

For example, an online store may include such functions as allowing the customer to search for products, order products, apply discounts, and have them shipped to an address of their choosing.   Very often all of these functions cannot be built within a single Sprint. So which ones to build in order to product a shippable subset?

The Scrum team (together with the Product Owner) decides which functions to build in order to deliver working software.  One such option could be to simply include only the search for products function.  So at the end of the Sprint you end up with software that searches for products, and does nothing else.  That is an acceptable choice.

It is far better than deciding to build all the user interfaces for all the above functions, but not have them work.  If you do this, what you get at the end of the Sprint is not working software, rather, you end up with a glorified series of screenshots.

Back to feedback.  At the end of each Sprint is a Demo of what was built.  The Scrum teams demonstrates the current product so that the Product Owner (and other stakeholders) can review it and give their feedback.   Is this what was envisioned?   If it was, was it what you wanted?  Very often, once we see the the incarnation of what we said we wanted, we come to the realisation that that is not really what we wanted.

The purpose of the Demo is absolutely NOT to show the Product Owner that the Scrum Team is working hard.  No.  The purpose is only feedback regarding the product.  (There is a time when evaluation of the Scrum Team occurs, but this is not that time, and I will talk about it later).

If there is one thing that feedback causes, it is change.  You can be sure that the feedback will result in changes, changes to what the software will do, and changes to what it is currently doing.

So what do we do with the changes?  I’ll talk about that in the next post.

Scrum Fundamentals

Stripped to its essence, Scrum is an approach to delivering software.  Nothing more, nothing less.

There are many approaches to developing software.   At one end, you can have a very formal ‘waterfall’ style approach where the development lifecycle consists of major phases that follow one another.  These phases include the Requirements Phase, where the project analyses and documents what the stakeholders need.  The next phase would be the design phase, where designers design the system to be built, which once built will deliver the requirements identified in the Requirements Phase.

After the Design Phase comes the Build Phase.  This is where the actual product get built, based on the specifications produced from the Design Phase.  Once built, the product gets tested in the Test Phase, in order to ensure the quality of the built product.

The phases in the waterfall approach are very logically  structured.  Each phase produces exactly what the next phase requires.  From arguments based on reason alone, it seems to be the perfect approach. 

In reality, however, the above approach is riddled with inefficiencies and problems, not due to the phases themselves, but because they are performed by fallible human beings, using fallible communication methods.  

Perhaps the most commonly cited problem is that very often, the product that comes out at the end meets the specifications, which in turn meets the requirements, but somehow ends up not being what the end users wanted or expected.

The lack of feedback between the stakeholders and the product being built – as it’s being built – contributes in no small part, to the problem.

Agile, and in particular, Scrum, proposes to fix the above problem by increasing the visibility of the product being built, while it’s being built.

We can illustrate Scrum at a very high level in the IDEF0 format as shown.

The output of a Scrum process is working software.  The inputs are a vision of the product, and of course time and money.

The process is executed by the Scrum Team, who relies heavily on the Product Owner, who represents the business stakeholders and from whom comes the Vision of the product.

Scrum comes with a set of techniques and procedures, and guided by the principles espoused in the Agile Manifesto.  You execute Scrum using these techniques.  In theory, you get working software, and the software that is guaranteed to be what the customer wants.

How does Scrum do that?  We’ll start exploring beginning with the next post on this topic.

The Essence of Agile

How much of Agile practices can you remove before it becomes no longer Agile?

I was having a discussion that other day with another project manager, and this fellow was saying that he didn’t think you could do Agile without having a card wall.  Now, I’ve done Agile development before using just an Excel spread sheet instead of a card wall to track the progress, so I know for a fact that you could do Agile without the card wall. 

So I said I disagreed and we left it at that.

A little while later, I thought about the matter a bit more and decided that I haven’t changed my mind.  It is not the card wall that determines if you are doing Agile or not.

Let me give an analogy.  The other week my 6-year old son and I were playing basketball.  We weren’t in any basketball uniform.  I was in jeans, and he was in his civvies. We were still playing basketball, weren’t we?

We also were not following basketball rules: each time he makes a shot, it’s worth 50 points. Each time I make a shot, it’s worth 1 point. We were still playing basketball, weren’t we?

Also, he didn’t have to dribble: he could run with the ball as much as he likes. We were still playing basketball, weren’t we?

Lastly, we were not even using a basketball ball. We were using a soccer ball (our basketball ball was too heavy for him). We were still playing basketball, weren’t we?  I believe so.

My point is that there is a core in Agile that represents the essence. The card wall is not an essential part of it.

The idea of the card wall originated from the concept of ‘kanban’, a Just-in-Time (JIT) system developed at Toyota many years ago (as far back as the 1930s would you believe it?).  I’ll write about what kanban is in another post, and explain the big difference between it and how the card wall is used in Agile development. 

The important thing is that in Agile, the card wall is simply a reporting tool.  It give you a synoptic (‘at a glance’) view of where things are.  It is not part of the essence of Agile.

The essence of Agile is constant feedback and constant adjustment. 

The card wall, the daily stand-ups, even the sprints, are merely communication and administrative techniques.  You can replace each one of these with completely new techniques (potentially better) and still be doing Agile!

The Product Owner in Scrum

What is the role of the Product Owner in Scrum? 

The product owner’s responsibility is to ensure that the product is developed and delivered in a manner that maximises the paying owner’s return on investment.  In Scrum, what this means is that the product owner must identify for the Team those product features that deliver the highest business value for money amongs the outstanding product features not yet delirvered.

There is the assumption that there will never be enough money to build every desired feature.  Therefore, the features need to be prioritised.

The Product Owner does not dictate to the Team the specific set of features they need to build in a Sprint.  

Specifically, the Product Owner does not tell the Team how many features they ought to build during a certain Sprint – that decision belongs to the Team alone.  The Product Owner’s main role is to inform the Team of the priorities, so that they don’t proceed to deliver lower value features over high value ones.  There can be exceptions - for example a lower value feature may be included in the Sprint over a higher value one because the higher value one is too big to be added to the current Sprint, while the lower values one is small enough to be added.

It is possible that the product owner is the customer, but he or she must never be the Scrum Master.