Skip to content

Agile: common sense, simplicity, execution – Planning

Each project is different although the approach is the same: common sense, simplicity and capacity of a team to execute a high level plan i.e. deliver working software. This is a model that can fit some types of projects where governance is important to an organization, where project management is being used and where UX work is key to the launch of a product.

I would highlight again “simplicity”: agile is about making improvement and a good way to identify improvements is to ask yourself: “Can this cost less energy? Can this be reused? Can this be replaced by something that already exist if I change it?”

This picture shows 3 levels of planning, a gated process with review of business cases (yearly budgeting and quarterly funding) as well as quality criteria such as INVEST, DEEP for the product backlog, DoD etc

 

Big picture

Image

Agile definition

Everybody is talking about “agile” but hardly nobody agrees on the meaning? What is “agile”? I have tried to see what makes you agile and thought…

Common sense is key to success: without common sense, you get mindless chaos (Steve McConnel) and smart people will not stay round for long.

Common sense drives simplicity: you cannot solves issues you do not understand; you cannot make progress if your people don’t understand what directions you are taking etc

Simplicity drives values: you clarify the key values; what is really important and people is “something” you value more than processes and documentation

Values drive principles: once your values are clear, you set out principles to follow

From your principles, you establish and improve a framework driven by common sense and simplicity and that support your values and principles.

 

 

Agile Definition

Enterprise Agile Project Management: where does “Agile” fit?

Although it may look similar at first sight, Agile project management has a far bigger part to play in the Enterprise. The key difference is first in the values and the desire to apply common sense in the Enterprise.

High Level

Then, going deeper, into more details:

Medium Level

Finally:

Low Level

The paragraph from Ken Schawber that everybody should read again…

Extract from Ken Schawber, Project Management with scrum, 2004:

“Common sense is a combination of experience, training, humility, wit, and intelligence. People employing Scrum apply common sense every time they find the work is veering off the path leading to the desired results. Yet most of us are so used to using prescriptive processes—those that say “do this, then do that, and then do this”—that we have learned to disregard our common sense and instead await instructions.”

If you renamed agile, applying common sense, you would get…

Agile does not scale -> Applying common sense does not scale

Agile does not work for fixed cost projects -> Applying common sense does not work for fixed cost projects

Agile is not for complex projects -> Applying common sense is not for complex projects

Agile is not for junior members -> Applying common sense is not for junior members

Agile is prescriptive -> Applying common sense is prescriptive

Agile does not apply to all projects -> Applying common sense does not apply to all projects

I’ll bring some more… Just a start…

Simple ways to speed up manual regression testing

Sometimes, not everything can be automated. So how can you optimise your manual regression testing so the test suite can be run quickly and is easy to maintain? I have used the tips below and it is turning out to be very effective!

- Make your tests UI independant:

Exemple: instead of *click on the button “Save” to save your data*, write *Save your data*. This is a minute difference with a big impact: if you change the title of the button or change from a button to a drop down list, the second test is still valid, the first one is invalid.

Testing requires common sense and intelligence: having your tests UI independant means you need to get your brain work a bit more on the first time you run the test, the second time it gets faster and the third time, you just know what to do.

Also, tests are simpler to read and far easier to maintain!

- Make your tests business focused:

Because of the history in your company, tests might be written with lots of details such as “The pop-up should open” but this is pointless as the pop-up exists because there is business workfow behind so by writing tests that represent business workflows, the test will fail if the pop-up does not open even if you don’t check explicitly this is the case.

- Combine tests that are similar and find the path that tests most cases:

Let’s say you have 2 tests testing these 4 cases:

  • A -> B -> C
  • B-> C ->D
  • Can’t you have a test that does A->B->C->D?
  • And if you write a new test: B->D->E then why not having only A->B->C->D->E?

- Use consistent way of writting tests:

One way is to use the Given/When/Then pattern:

  • (Given) some context
  • (When) some action is carried out
  • (Then) a particular set of observable consequences should obtain

- Add as many verfications as possible with the tests:

The purpose of the tests is to find defects if any so add as many verification as possible including verifying impact on data and other screens.

Conclusion: I have used the tips above, based on BDD principals for most, and this has been very effective: we can run more tests, validate more cases and still have not that many tests to run that are easy to maintain. Indirectly, your tests could be now automated quite easily!

Agile SDLC (ALM), Cone of uncertainty and stage gate process

The picture below aims at summarising an agile SDLC combined with a stage gate process and, using the cone of uncertainty, why having regular gates based on the velocity of the team and the business case updated (ROI and risks):

Cone of uncertainty and stage gate process 2

Follow

Get every new post delivered to your Inbox.