PROFES 2018, Wolfsburg: Talk by Tilman Seifert (Principal IT Consultant at QAware) === Please download slides if blurred! === Abstract: Processes cannot just be judged as ``good'' or ``efficient''---they must be appropriate for the type of project. As the type of a project changes over time, the processes must adjust in order to stay efficient and appropriate. We accompanied the transformation of a large and fast-growing project, using agile development methods and cloud-native technologies, from the very first steps of a prototype to the development of a customer-ready product. This experience report shows patterns we found on the way. It argues that systematic process evolution can be done without documentation overhead or relying on questionable process KPIs. We only used information which is available anyway; this includes our archive of sprint retro boards which allows to create a clear picture of the project's evolution, regarding both the process and the product quality.

1. Experience Report
Tilman Seifert
Process Evolution and
Product Maturity:
From Prototype to Product
Wolfsburg, 29. November 2018

2. Tilman Seifert
Principal IT Consultant @ QAware GmbH
Developer and Architect
20+ years experience
Industry, research, community
Email me: tilman.seifert@qaware.de
Meet me: meetup.com/cloud-native-muc
QAware 2

3. 1. Situation and Challenges
2. Approach
3. Appropriate Processes in a Changing Environment
4. Conclusion

4. Situation and
Challenges

5. QAware 5
Context
Building a novel entertainment system: Cloud-Native, Micro Services, Integration of 3rd Party services
Started as a prototype: Is it possible? What can we get off the shelf, what do we have to build?
2 years later: 170+ people involved: developers, designers, etc.
Evolution
Do you use the same processes
for a 5-person team vs a 170-person team?
for a prototype vs a customer-facing product?
Change is introduced step by step, and sometimes (to be honest), on a trial-and-error basis:
Great (= ) or wrong (= don’t work)
Too small (= ineffective) or too large (= too complicated)
 Do we change the right things? Is it effective? Is it appropriate?
 How are Process Evolution and Product Maturity related?
When teams grow and the constraints change,
process change is inevitable.

6. Approach

7. QAware 7
We analyzed data from the retro archive.
Retro archive: Glad | Sad | Mad
(2) Analyze Sprint Retros:
Systematic collection,
categorized and condensed.
Use data that already exists.
(3) Think
(1) Consider process areas to focus on.
Write down hypotheses.
 Create columns in spreadsheet.

8. QAware 8
Systematic?
No: It’s not repeatable. Maybe comments are missing because other issues are more pressing etc.
However, the retro is a well-known standard process, and routinely well-reflected observations are voiced.
Authentic?
Yes: The team is not known for being shy.
Pragmatic?
Yes: no additional documentation effort.
Possible conclusions:
On a qualitative basis: probably ok.
Be careful to extrapolate.
Is this a sound approach? What results can we expect?

9. Appropriate Processes in a
Changing Environment

10. QAware 10
Hypotheses: We expect to find major changes over time in these process areas:
Communication
Planning
Quality
Requirements and Change
Leading questions:
What makes a process appropriate?
How did we find processes which are inappropriate? How did we find measures against it?
Disclaimer: Both the selection of the process areas and their descriptions are highly opinionated.
But all observations are backed by data from the retro archive.
We analyzed selected process areas.

11. QAware 11
Data shows:
The team is sensitive about how its time is being used.
While developers don't fancy writing documentation, they much prefer it to being interrupted by phone,
email, or chat for the ever-same questions.
Lesson: Finding the right channels for communication leads to different answers over time.
Communication Structures and Tools:
Teams need to share information.
Large teamSmall team
“Go and ask”
Many changes. Documentation
tends to grow old
1 / 4
Need more written docs.
Knowledge-transfer needs structure;
concepts need to be well-thought
and proven
Scaling
Structure

12. QAware 12
Example 1: Demos to senior management
Important to keep sponsors’ support.
“Don’t break anything – rather stop the world” blocks work. Especially if unplanned, on short notice.
Data shows: Unplanned changes are annoying, interrupting, blocking.
Lesson: proper planning for demos and sound expectation management is crucial.
Example 2: Features and their priorities
Integrate System “X” or not? Difficult ( do it later) but high business value ( do it now).
Decision changed often. Implies that each team must re-validate and re-order their backlogs.
Data shows: It’s demotivating for a team to find its results not being used.
Lesson: Share goals between teams, and keep them stable, so that results are being used.
Focus: Just let people work 2 / 4

13. QAware 13
We prefer „used software“ over „changing goals back and forth all the time“ ;-)
While there is value in the flexibility to adjust goals, there is no value in being indecisive.
If priorities change too often, one team will end up having stuff developed – but no one uses it.
Protect the sprint:
Is a concept to give security to teams, i.e. a stable and productive environment.
Is a deal: You give me security and I’ll give you running software.
Do the same across teams:
Give the security that the goals are meaningful and stable.
Side note on „Agility“ and dealing with change

14. QAware 14
Quality deficiencies lead to re-work  expensive:
Teams wish to produce high-quality, long-living code.
Increase in satisfaction when re-work was actively reduced.
Lesson:
There are many ways to measure and improve quality, including many tools. Feasible and valuable.
Even easier and very effective: Just ask the team – and listen to their response.
Allow to produce quality 3 / 4
Commercial ProductPrototype
Move fast, try things, change stuff
 speed is motivating
Re-work of things that were finished
 tiresome
Change Impact

15. QAware 15
Our approach:
Use an exploration team: make sure that features are well understood before implementation.
The data shows:
Satisfaction rises when tickets get better and re-work is reduced.
Lesson:
“First think, then act” is no contradiction to “Embrace change”.
It’s a huge mind-shift to go from learning “anything” to creating business value.
Is Requirements Engineering old-fashioned?
No, it’s still allowed.
Commercial ProductPrototype
4 / 4
build what is possible to build:
learning is the top-goal
build what is useful for customers:
generate business value
What to
build?

16. Conclusion

17. QAware 17
For the project:
Over time, processes change:
Tools or activities gain or lose importance.
Collaboration between teams changes – even if the overall process framework stays the same.
This is healthy and normal: Different environments and constraints require different processes.
Therefore, teams with a mature understanding of processes will change and adapt processes over time.
Planning is a good thing.
The method:
Simple things like the sprint retro archive offer good insight
to allow for qualitative analysis of the project's evolution and maturity, and
to derive appropriate improvement measures in a lightweight, yet systematic way.
Conclusions

18. Tilman Seifert
tilman.seifert@qaware.de xing.com/companies/qawaregmbh
linkedin.com/company/qaware-gmbh slideshare.net/qaware
twitter.com/qaware github.com/qaware
youtube.com/qawaregmbh