For the last 3 years, implementing scrum or just being agile, I have had lots of concerns reg. test strategies issued by test managers for my projects: I felt they did not take into account the specifics of the product and they turned into copy/paste test plans of previous projects.
Since we are talking about delivering working software, as a project manager/scrum master, I started writing the test strategies, approaches and test plans with support of the scrum teams for my projects. I got slightly lucky because before that I had read some books about testing inc. “Agile Testing” by Lisa Crispin and one about ISQTB so about testing and certification and some articles, especially Mike Cohn’s Forgotten Layer of the Test Automation Pyramid. Testing is now a interesting discipline thanks to numerous clever tools and techniques like BDD.
My whole goal was to make sure the test strategy and its implementation were tailored to the project and was fit-for-purpose for the project. There is a learning curve for the team to come up with the test strategy: writing a good test strategy requires thinking, lots of discussions and an understanding of what the product is as well as a knowledge of different tools and techniques.
A test strategy, like design, is “intentional yet emergent” to quote Mike Cohn: you may have to adapt it based on the lessons learned in the first sprints.
So , testing with all activities emcompassed under this name, should be part of the remit of responsibilities of the scrum teams! You build it, you test it and you run it!
- Rename “agile” to “common sense”
- What matters is the quality of the team…
- Go for simplicity, make it a habit
- Get trained but not by anybody
- Not everybody can be agile in the timeframe of your project
- Do completeness from the first user story
- Software test strategy: make it the responsibility of the team
- Rename “Scrum Master” to “Scrum facilitator”
- Think big, start very small
- Use ideas and concepts that provide a holistic approach
- Mono-tasking: art of getting things done
- Learn, learn and learn
1. Rename “agile” to “common sense”
•“Agile cannot apply to all projects!” becomes: “Common sense does not apply to all projects”… “Could you repeat that?”
•“Agile is just a fad” becomes “Common sense is just a fad!”… “Oups! Is it?”
“Agile” may not be the right word, so use a more meaningful word ?
2. “What really matter is the quality of the team
•… The rest is just an optimisation”
•Having worked for a great team using waterfall, we just became agile because:
–They were Highly Skilled engineers
–They were Quality-focused
–They had Common sense
Fundamentally, this is all about the quality of team
3. Go for simplicity, make it a habit
•People like the abstract world, mainly because it feels better: “Wow, you are doing complicated stuff!”
–Use examples, models, rewrite and rethink until you have captured the essence of business needs
•Good user stories are more than “As a … I want … so that…” but they are a still a good conversation!
–If you don’t understand something, this “something” might be your problem soon
–Dare aim for simplicity and be very concrete (use examples)
Simplicity is an art
4. Get trained but not by anybody
•Agile is about not compromising on Quality so get the right trainers i.e. aim for the best!
•Mike Cohn and Ken Rubin are very good
Quality in each and every aspect!
5. Not everybody can be agile in the timeframe of your project
•“Common sense is anything but common”: you have to acknowledge some people will be obstacles so if this is your project, better out of your way that in your way!
Agile is not for everybody, be tough!
6. Do completeness from the first user story
•Your Definition of Done is the key success of your project
•So make sure that even for the first user story, you have tackled your non-functional requirements
–Add tests to measure performance, data quality, load testing etc
Is your first story really, really shippable if you had to ship it?
7. Software test strategy: make it the responsibility of the team
Mainly because of historical reasons, software design and software development are the responsibility of the dev team and software testing of the test team headed by a test manager who is the person to come up with the test strategy, although test engineers are now part of the scrum team.
With new techniques and tools are appearing (e.g. BDD), new ideas or ideas are evolving (see testing quadrants by Lisa Crispin or the Forgotten Layer of the Test Automation Pyramid by Mike Cohn, “test engineering” requires a tailored approach to your project including a good understanding of the product, the requirements (user stories) and the design (taking testing into consideration when designing your product helps get a better design): and who is most capable to provide that approach? Yes, the team! As design is emergent, testing is too.
Tailor your test strategy: make it the responsibility of the team, they will provide the right one!
8. Rename “Scrum Master” to “Scrum team facilitator”
•I understand scrum master is the master of the scrum process/framework but some people really only hear “Master”
•The scrum master is a team facilitator: find the people who have facilitating skills to be your scrum masters!
Look for facilitators to help your teams!
9. Thing big, start very small
•Always keep the big picture in mind and implement small user stories first
•Engineers always under estimate the effort so ask them to do the simplest thing that can work and help them do it well
Really, don’t hesitate to do less and do it well
10. Use ideas and concepts that provide a holistic approach
•User stories, BDD et DDD have lots in common:
–Based on conversation
–Reflect business inputs
–Supplement each other
•All together provides a cohesive approach
Holistic approach = coherent people
11. Mono-tasking: art of getting things done
•Too often, engineers get involved in doing too many things at once
•Limit work in progress (WIP) in your « in progress » column of tasks
Mono-tasking is great discipline
12. Learn, learn, learn
•New concepts are coming along, BDD, DDD, FDD etc: don’t be afraid: behind these concepts, there are simple ideas
•Learning new things and once you have passed the learning curve will motivate you!
Nobody was born an agile coach…
In a nutshell , Apply common sense and use simplification to drive change!
User stories express (business) needs through a conversation and a confirmation, stored on a card
The conversation allows to the team to understand what the (business) domain is, naturally defining a common language: this helps provide a software design that reflects the business domain: DDD, Domain Design Driven.
The confirmation could include (lots of) examples that validate business needs. These acceptance criteria will be needed by the PO for approval and for building a customer test suite (UAT): BDD, Behaviour Driven Development.
In a nutshell, when we discuss user stories (requirements), we build a language and contexts. Instead of reinventing the wheel, we match our design of the solution and the tests to this language and contexts – simple!
This picture below aims to summarise “interaction” between User stories, DDD and BBD.
The point of this blog is to demonstrate that making things simple helps becoming agile (i.e. helps bring back common sense to what you do). Slight glitch: making things simple is a different kettle of fish than taking the easy option. Simple is not Easy!
Project Noise Level: iterations to make it simple:
Looking at what Mike Cohn and Ken Schwaber’s project noise level (from http://www.mountaingoatsoftware.com/scrum/a-reusable-scrum-presentation)
It took me a while to understand this slide (ok, did not pay attention to it first).
I am interpreting it that way: if you can make things simple around you, then you can be agile: you have to reach simplicty to know what you are doing – we are not as good as we think to handle complexity.
Scrum is made of short sprints forcing a team to break down requirements and technology simple enough to deliver a product increment.
As De Vinci said “Simplicity is the ultimate form of sophistication”
So Simplicity could be a path to agility, not an easy path!
A Real life example that saves time, lots of it:
Just about 2 years ago, we set up a 3-day workshop to capture user stories with our customers. Our supplier did attend this workshop. For each story we created, we added a few (1 to many) acceptance criteria using specification by example (Given/When/Then/And/But model). It did work great because even for the user stories that initially looked obvious, adding an example showed that there were still misunderstanding between participants about what the stories were about.
An example was (along the line):
As a driver, I want to get directions to a city in another country so I can travel to that city
GIVEN I am in France AND my system is in French
WHEN I say “go to Brussels, 123 main street”
THEN the system says “I did not recognise that – please try again”
The reason the system does not recognize an address abroad: this is a technical limitation that the supplier of the system raised. The customer had forgotten this limitation.
That “specification by example” does is making the story simple to understand. Even a story well written may not be concrete enough hence having an example makes obvious what we want to achieve (and also generate discussions).
We also know what that agile architecture principles like to “keep it simple stupid”.
So if you make things simple (and this is hard), then can you become agile?
Last but not leat, these are De Bono principles to simplicity:
- You need to put a high value on simplicity
To get simplicity you have to want to get it. To want to get simplicity you have to put a high value on simplicity.
- You must be determined to seek simplicity
People quite like simplicity if it does not cost anything but are usually unwilling to invest resources in making something more simple.
- You need to understand the matter very well
If you do not seek to understand a situation or process, your efforts will be ‘simplistic’ rather than simple. Simplicity before understanding is worthless.
- You need to design alternatives
It is not a matter of designing the ‘one right way’. It is more a matter of designing alternatives and possibilities, and then selecting one of them.
- You need to challenge and discard existing elements
Everything needs to justify its continued existence. If you wish to retain something for the sake of tradition let that be a conscious decision.
- You need to be prepared to start over again
In the search for Simplicity, modify if you can – start afresh if you cannot.
- You need to use concepts
Concepts are the human mind’s way of simplifying the world around. Warning: If you do not use concepts, then you are working with detail.
- You may need to break things down into smaller units
The organisation of a smaller unit is obviously simpler than the organisation of a large unit. The smaller units are themselves organised to serve the larger purpose.
- You need to be prepared to trade off other values for simplicity
A system that seeks to be totally comprehensive may be very complex. You may need to trade off that comprehensiveness for simplicity.
- You need to know for whose sake the simplicity is being designed
A shift of complexity may mean that a system is made easier for the customer but much more complicated for the operator.
When talking about agile, lots of aspects need to be taken into account and implement at some points:
- Which agile framework? Scrum, XP, DSDM…
- What control and governance around the project? Prince2/DSDM, A-PMI, …
- How do we scale? Agile Release Train, Spotify startup product mindset,…
- How is portfolio management affected? Yearly budgeting and quaterly funding
- Agile Transformation: how we deal with HR? With Legal? With PMO? How do we make the organisation more agile?
Here below is a picture that represents the aspects to think of:
User stories have, in a way, bridged the gap between technical teams and the Business: we understand what you want and why; we speak the same language!
On the architecture/design side, this can be still be a black box for the Business or even for the scrum master and product owner: yes we get the idea but cannot really comment…
Looking at Domain Driven Design (Domain Model Principles), the tech team is going to model their “architecture” while interacting with the customers/users (PO) and use the same words used by the “business” to model their design.
Concretely, as the customers describe their business flows in front of the tech team, the tech team map out the flows to a model so the customers can understand how the system will handle these flows and spot any issues, missing constraints and requirements.
One great benefit from an agile point of view is that this is another “tool” to use to increase interactions between tech teams and the business to implement the right solution.
The use of ubiquitous language is key as “Ubiquitous Language is the term Eric Evans uses in Domain Driven Design for the practice of building up a common, rigorous language between developers and users. This language should be based on the Domain Model used in the software – hence the need for it to be rigorous, since software doesn’t cope well with ambiguity.” (see http://martinfowler.com/bliki/UbiquitousLanguage.html).
http://skillsmatter.com/podcast/design-architecture/talk-from-udi-dahan (quite good, some very good examples to see who it works)
http://www.infoq.com/presentations/model-to-work-evans (From Eric Evans – DDD: “putting the model to work” – a good example!)
http://www.youtube.com/watch?v=2fVTNsQ8POI (very theoretical at the beginning)