Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Process Evolution and Product Maturity

181 views

Published on

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.

Published in: Software
  • Be the first to comment

  • Be the first to like this

Process Evolution and Product Maturity

  1. 1. Experience Report Tilman Seifert Process Evolution and Product Maturity: From Prototype to Product Wolfsburg, 29. November 2018
  2. 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. 3. 1. Situation and Challenges 2. Approach 3. Appropriate Processes in a Changing Environment 4. Conclusion
  4. 4. Situation and Challenges
  5. 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. 6. Approach
  7. 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. 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. 9. Appropriate Processes in a Changing Environment
  10. 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. 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. 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. 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. 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. 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. 16. Conclusion
  17. 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. 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

×