Part 3, Builds upon the subjects of the first two papers ‘onboarding’ and ‘T-shaping’. We look at the value to be gained from using the Agile mindset, the values, principles and practices to move our teams towards continuous improvement and a highly collaborative and autonomous state of ‘T-shaped Agility’.
We break part 3 into the two inter-related topics:
3.1 – Agile values for team ‘Agility’
3.2- Agile Q.A. to support ‘Agility’
Part 3 – Empowering digital teams with “T-shaped Agility”
Part 3.1. Agile values for team ‘Agility’
Our summary model below shows the key compounded ambitions in applying the strategies of the series and the effects on Individuals, Teams, Projects and Organisational Culture.
Note: Most of the suggestions in part 3 are agile mindset related so are methodology agnostic and are relevant under other project management methods also such as PRINCE2, PMI, sigma or any hybrid waterfall/Agile combinations.
The Agile Manifesto: a DNA to inspire teams
Agile is not a methodology itself, it is essentially a flexible business mindset. In achieving any mindset it is the human factors (training, coaching, leadership and cultural acceptance) which have to be in place and managed effectively. This is echoed by the critical success factor (CSFs) studies on agile referenced in section 3.2 below and the 15th ‘State of Agile’ report 27 by DigitalAi.
The report found that 5 out of 6 of the biggest challenges to implementing Agile practices related to human factors and culture:
- 43% Stated organisational culture was at odds with Agile values
- 42% General organisational resistance to change
- 42% Lack of skills/experience with Agile methods
- 41% Not enough leadership participation
- 40% Inadequate management support and sponsorship
The Agile Manifesto created four values and twelve principles that give no definitive structure to Agile but a clear philosophy and direction to the methodologies that preceded and followed that meeting, all of which have adopted the genre of Agile methodologies i.e. eXtreme Programming (XP), scrum, kanban, SAFe, Lean etc.
The spirit of the Agile Manifesto is clear when reading what Bob Martin said at the original inception meeting about the ‘mushy stuff’of Agile:
“a set of values based on trust and respect for each other and promoting organizational models based on people, collaboration, and building the types of organizational communities in which we would want to work”.
Refocus on the values to create team ‘Agility’
10 years after the Agile Manifesto was written, one of the founding members Dave Thomas wrote a post about ‘agile is dead’; it was an earnest statement of regret that the simplicity of Agile has moved so far from its inspiring principles and it’s essential value that it had become lost. Indeed it is the lack of focus on this Agile mindset that is often attributed to Agile not scaling or being adopted by organisational cultures.23
Dave Thomas suggested a reboot; to replace the word Agile with agility, with the word agility representing the focus of the four values once more.
Those four values being:
1. Individuals and interactions over processes and tools,
2. Working software over comprehensive documentation,
3. Customer collaboration over contract negotiation,
4. Responding to change over following a plan.
It is these values and this Agile spirit, or ‘agility’, that we look to utilize as the team mindset. On top of this mindset there are key principles of Agile which must be considered central to building successful teams.
Risk and Agile
Some viewpoints on software development are that risk is a central challenge; author and Fintech open source expert Rob Moffat takes that a step further
“all the work we do as developers is about risk. For example, if you’re working on making the sign-up screens for your web-app less confusing, what you’re actually doing is trying to reduce the risk that potential customers walk away.”2221
As the seriousness or risks escalate within web and digital projects i.e. accessibility, security, privacy etc we need to support each project with comprehensive approaches to quality and risk. While some Agile systems may seem overblown such as SAFe20 they do deal with well-structured risk assessment and management so are very well suited to high-risk projects.
In increasingly complex business environments a little industrialisation is a necessary evolution to reduce burden and stress on teams so they can focus on important innovation and quality. While this paper only addresses the most important human-factors it has to be pointed out that getting our crews fit for flight will be for nothing if there isn’t, as a bare minimum, operational procedures, good air traffic control guidance and good infrastructure to bring each project down safely.
DevOps is proving to be an effective approach to making sure practices and processes are supported while making a minimal impact on development speed and agility30. Below we outline an Agile approach to quality and risk which can be included within any existing Agile or other project management frameworks to improve the support for our teams and increase key skills, this approach is also complementary to devops environments and without co-incidence has roots in the airline industry (see the checklist manifesto).
Part 3.2 – Agile QA to support ‘Agility’
Critical Success factors for agility
A recent study2 by Manchester University recently isolated six main CSFs of successful Agile teams. Four CSFs, Nos. 1, 3, 4 & 5, are methodology agnostic and relate very much to the team approach and agile mindset. If we can instil these principals/CSFs within our project teams then we are making the right inroads into achieving the success of our future projects.
Opquast Q.A. will help realise four of the CSFs:CSF 1. Multi-skilled teams, CSF 3. Customer involvement, CSF 4. Team autonomy, CSF 5. Continuous learning and improvement.
CSF 1*. Multi-skilled teams: Team members possess diverse skills and assume multiple roles when working on projects, allowing them to adapt and work amongst themselves when priorities change.
CSF 2. Iterative planning: Agile teams hold regular planning meetings to stay aligned with demands by setting short-term task goals, and reviewing progress on critical tasks.
CSF 3*. Customer involvement: Agile teams focus on customer needs, collaborate and communicate with customers regularly, and incorporate customer feedback throughout project cycles.
CSF 4*. Team autonomy and empowerment: Agile teams are empowered to decide how to complete and organise their work, which speeds up decision-making and task cycles, and enhances task effectiveness.
CSF 5*. Continuous Learning and Improvement: Agile teams accelerate their output over time through continuous learning and improvement.
CSF 6. Team Prioritisation: Agile teams focus on delivering the most valuable customer outputs
We demonstrate below how these critical success factors can be supported by Opquast.
CSF1: Multi-skilled teams
Multi-skilled teams is a proven critical success factor and common approach with scrum; it is also one of the most complex to balance. The advantages and disadvantages of cross-disciplinary teams and t-shaped individuals we discuss in the 2nd article of this series.
The T-shaped profile is one that has heightened empathy and collaborative possibilities due to their breadth of skills but they also have their own speciality. In keeping with Agile methods and Agile Q.A. the focus is not on strict adherence to the t-shaped profile but to create an environment to inspire learning and for people to find their inner-T-shape through shared learning and continuous improvement3. The broad knowledge areas of the Opquast body of open source resources and training reflects this (figure 2 below).
The increasing complexity of software and digital projects does mean however that all digital-project team members need to have much broader knowledge sets to work better together and to mitigate the abundant and diverse risks. This needs to be balanced with the need to have experts available when needed as we discuss below.
CSF 3: Customer involvement and focus on customer needs
The Opquast Q.A. system is a customer-centric approach which introduces a broad base of essential foundational customer needs.
The training courses and open-license resources focus on improving: accessibility and inclusion, performance, SEO, ecodesign, privacy and other essential elements that effect the user. All of the 240 ‘quality rules’ have been developed by community consensus and they reflect immutable and universally implementable user requirements common to most digital projects. The training aims on building empathy and collaboration centred on the diverse and inclusive user cases.
There is a logical user focused model known as the VPTCS model we have written about this model in other articles12 in greater depth. Essentially this model allows flexible ways of viewing user experience and your web and digital projects and the requirements.
The VPTCS model is useful for Agile and lean projects when we are considering 1st iterations and 1st MVPs (Minimal Viable Products). Firstly the model looks at the ideal skills that need to be assigned to an iteration or to the development of a particular sprint or work item. Secondly, the whole model gives a high-level view of the component parts of a successful web project demarcating the user interface from the user experience. Every project will have different user requirements relating to Visibility i.e. its findability and SEO, Its Perception i.e. presentation style and accessibility, the performance and other Technical parts, the Content of the page and any Services relating to the overall project or any particular component part.
CSF 4:Team autonomy and empowerment
“In Scrum, the team is empowered with the authority and resources to find their own way and solve their own problems” Larson 20049
Agile Quality Assurance
Applying the scope of the Opquast web quality resources is best done in an Agile way. It is the objective of the Opquast training to see that the business and technical people have cross-disciplinary skills so they can apply their skills to each relevant task. With the cross-disciplinary approach, teams collaborate better and can be given the autonomy to do so.
Quality assurance is not something that just needs to be applied at the end of a project. Opquast Q.A. is about empowering staff with a base of essential skills so that at each step within a digital project they can identify the risks and quality issues across very universal and broad risks as accessibility, inclusion, security, privacy, etc . For complex web and software projects not having a comprehensive approach to quality assurance the auditing and assessment of such risks can be an endless job, doomed to failure.
We know from previous studies that removing errors from live software is time-consuming and exponentially expensive7. If we can catch most errors before they enter production i.e. before proto-typing and before they hit code then our projects will cost less and go faster.
By implementing Opqust Q.A. we are extending team agility by teaching new work reflexes through commonly occurring design patterns and quality considerations. The Opquast training really instils this within teams and the ‘quality rules’ open license repository is there for integration into knowledge systems. How the teams decide to organise their knowledge and assign their work is up to them but the fact that they have been empowered as Q.A. generalists strengthens the team and gives them flexibility.
Applying quality rules and checklists
“Checklists enable teamwork and communication, they engage subordinates and empower them at crucial points in the activity, they are more than just box-ticking they are vehicles for delivering behavioural change”25.
The ‘quality rules’ repository and checklists give teams a broad user requirements foundation which is incredibly flexible as guidelines and a knowledge base. They are presented in individual cards which present the Rule with tags (to help search and organise the data i.e. SEO, accessibility, editorial etc) a descriptive label, the goals (with user considerations), and implementation and control advice. These ‘quality rules’ are meant to be extensible, and organisations should be building upon this repository or adding to the spreadsheet their own house-style ‘quality rules’ or lessons learned to record against their success criteria. As you define your definition of ‘what’s done’ you can refer to the control element of each ‘quality rule’ (see example below).
The checklists can create a base for our know-how systems and training, they minimise duplication of effort and human error which in complex digital projects is rife. The checklists are there to free up the mental load of experts who need to work on tasks needing their deeper knowledge and attention. There are openly available checklists for Agile itself to help with preparing sprints, user stories, defect reports etc26 . Atul Gawande’s book the “Checklist Manifesto” outlines the value of the checklist; here are a few words from the pioneering Harvard professor and doctor:
“We need a different strategy for overcoming failure, one that builds on experience and takes advantage of the knowledge people have but somehow also makes up for our inevitable human inadequacies. And there is such a strategy — though it will seem almost ridiculous in its simplicity, maybe even crazy …it’s a checklist.”
CSF 5: Continuous improvement and Learning
Agile accessibility example
Agile accessibility example
For many of the disciplines covered by Opquast (Figure 2 above) experts will frequently be needed for the deeper dive i.e. SEO, Security, Privacy, performance, e-commerce UX (Usability) and accessibility.
Accessibility is another work stream that is commonly done retrospectively which can greatly inflate the cost and diminish success. Audits can reveal so much work that compliance becomes a moving target that is never reached5.
Opquasts’ founder Elie Sloïm proposed a light framework for Agile accessibility in 20105. The premise was to make accessibility a proactive process and not retrospective; to make it affordable and implementable at the same time as well as a practice to create shared learning “Ideally, Agile accessibility could even contribute to the transfer of skills from experts to project teams, to the point of gradually limiting the use of experts”. Sloïm and Deschamp noted the sizeable task left by some audits means that accessibility often has to take a continuous improvement approach.
Example 1 – pair programming
Stephane Deschamps formalised and published some of the principles and practical Agile procedures6. Deschamps recommends pair programming, taken from Kent Beck’s XP, whereby the accessibility expert would be part of the coding procedure for the complex parts of the system to build in the accessibility requirements. While the availability of expert accessibility resources can be scarce, for organisations that employ lots of developers and a few accessibility experts then this is highly valued shared learning and on-the-job training opportunity. Deschamps noted some estimates of workload differences: “ten days for a front-end developer will mean you’ll only need one day for an accessibility expert.”.
The pair-programming has indeed solved other expert issues and grumbles13,14 which are commonly experienced by teams, for instance issues between Agile and UX such as projects where incremental deliverables and tight sprints commonly side-line deeper UX work.
Pair programming is a great opportunity for designers to work with progammers15 to push the UX skills more widely within the teams and to reduce the UX quality problems. Pair programming is also a great tool for knowledge transfer within robust onboarding systems so new recruits can get up to speed quickly on projects and learn relevant skills and business logic. Fowler et al28 stated it’s flexibility and importance in software development “so many dismiss it quickly when it feels uncomfortable. However, in our experience, pair programming is vital for collaborative teamwork and high-quality software”.
Swarming
For accessibility specifically, perhaps more than two experts will work together. Depending upon the skills available within a team and the work complexity demands you may have many experts work alongside each other.
Swarming is an agile practice often used to concentrate larger numbers of a team on tasks and this frequently includes pair programming as a central part of the solution. At the New York Times, Olivier De Meulder’s discusses how by including Q.A. testers in their swarms during the coding of features they identify bugs and off features early on. Olivier’s comments ring more loudly now than ever “Few problems in this world don’t benefit from increased communication and software development is no exception….increased communication leads to better software design decisions”29.
The swarms great influence on driving better communications can be further complemented with the T-shaped generalist skills of Opquast. With Opquast training the swarm will be QA focused and have an understanding of key accessibility requirements so key design pattern errors can be avoided at every point of the swarms development cycle. Besides accessibility knowledge, the swarm will also have user empathy training and UX related knowledge such as ecodesign, performance, security etc for better integration of compliance issues.
To really optimise the effectiveness of swarming and pair-programming the steps and approaches highlighted in this series should be considered. With the write approach and support ecosystem our teams will be en route to achieving something as close to a swarm intelligence as is achievable, making team decisions quicker and more effective.
Example 2 – Foundational training and knowledge repositories
Where smaller organisations want to apply an Agile approach to accessibility, they can apply the Opquast ‘quality rules’ as foundational training and as a working knowledge repository within their know-how systems. As detailed below. Opquasts’ 126 accessibility rules cover the main accessibility errors which ‘WebAIMs’ yearly analysis identified as affecting 98.1% of the top 1,000,000 home pages. Coupled with either interim or end-of-project audits this creates a very Agile and cost-effective solution. Embodied in a continuous improvement and education programme these measures will greatly increase accessibility skills in your web teams, particularly if experts can be employed on some of the projects.
With either solution, continuous improvement is guaranteed. Lessons learned following any supplemental accessibility audits must be recorded so in the future developers can deepen their specialist knowledge and build compliance into future solutions. As teams progress with each project and move through continual learning with these experts the need for experts will diminish over time with the proviso that balancing teams means always having active experts in each field who continually develop their knowledge in certain discipline(s).
Summary and Takeaways
In this series, we hope to have demonstrated some useful and compelling synergies by implementing the three component parts of this series i.e. onboarding, T-shaping and Agile principles. Figure 4 below illustrates a base team support and learning infrastructure which adds the Agile and t-shaped elements to the SHRM HR onboarding diagram introduced in article 1.
By focusing on the human factors of our projects and organisations we will be addressing the most commonly cited reasons for project failures, over-runs and inefficiencies. In trying to achieve the ‘T-shaped agility’(Figure 5 below) our top management must work to absorb the values and approaches into the organisational culture as a philosophies and practices23,24. With the right approach and culture we will be on our way to creating the sort of teams that are continually improving and delivering projects that achieve our customers’ expectations.
By combining great onboarding, coaching, training and Agile practices our teams will have the best collaborative possibilities and most robust blend of expert and generalist skills. In order to build effective t-shaped teams in the longer term, we need to give enough exposure to specialist work to targeted individuals as part of well-designed skills and training matrices, otherwise skills redundancy will never be achieved. We must also be aware of creating equal opportunities for neurodiverse both for inclusion purposes but also for those unique skills and advantages they can bring in certain areas.
As the new hybrid working paradigm settles in it is becoming increasingly important to build reciprocal trust between employer and employee. To do that careful consideration of the continuous development, empowerment and support of our teams is crucial. It is those organisations that balance the complex work-life equation that will come out on top; or at least will attract the best people by offering flexible working conditions. It is those organisations that deserve to become the future places where most of us will want to work.
1. https://www.forrester.com/blogs/expertise-and-the-shared-services-problem-a-conversation-with-don-reinertsen/
2. https://www.forbes.com/sites/alliancembs/2021/01/29/what-makes-an-agile-team-six-factors-for-future-success/?sh=135c07732a5c
3. https://www.scrum.org/resources/blog/t-shape-deception
4. http://agilemanifesto.org/
5. https://openweb.eu.org/articles/accessibilite_agile
6. https://openweb.eu.org/articles/agile-accessibility-from-theory-to-practice
7. https://www.opquast.com/en/certification/web-qa/
8. Robert Pressman , 1992 Software Engineering: A Practitioner’s Approach propose
9. Larman, C. 2004. Agile & Iterative Development: A Manager’s Guide, Boston: Addison-Wesley
10. Henderson-Sellers, B., and Serour, M. K. 2005. “Creating a Dual-Agility Method: The Value of Method Engineering,” Journal of Database Management (16:4), pp. 1-23.
11. T-shaped individuals and opquast training – paul houston
12. VPTCS articles
13. https://uxdesign.cc/ux-unhappy-in-agile-it-might-be-because-of-these-4-reasons-921790326cf
14. https://www.nngroup.com/articles/agile-not-easy-ux/
15. https://medium.com/product-labs/how-designers-and-developers-can-pair-together-to-create-better-products-e4b09e3ca096
16. https://checklists.opquast.com/en/web-quality-assurance/
17. https://www.slideshare.net/AgileNZ/ahmed-sidky-keynote-agilenz
18. https://pragdave.me/blog/2014/03/04/time-to-kill-agile.html
19. Part 2 t-shaped teams Opquast https://www.opquast.com/en/t-shaped-individuals-for-effective-web-projects/
20. https://www.scaledagileframework.com/pi-planning/
21. Risk-First Software Development: Volume 1: The Menagerie Rob Moffat 2019 https://riskfirst.org/overview/Start
22. https://www.infoq.com/articles/book-review-risk-free-software-development/
23. https://www.forbes.com/sites/forbestechcouncil/2022/08/10/doing-agile-being-agile-and-achieving-agility/?sh=671230447643
24. https://www.repsly.com/blog/field-team-management/creating-agility-within-your-organization
25. https://agilescientific.com/blog/2012/4/17/checklists-for-everyone.html
26. https://digital.ai/catalyst-blog/the-agile-checklist-manifesto
27. https://digital.ai/resource-center/content/15th-annual-state-of-agile-report-review-findings-with-richard-knaster
28. https://martinfowler.com/articles/on-pair-programming.html#ToPairOrNotToPair
29 Olivier De Meulder March 2018 https://open.nytimes.com/scrum-swarm-sprint-how-to-take-the-agile-process-and-make-it-your-own-b6416793ff7e
30. https://hbr.org/2016/05/embracing-agile
31. https://www.pentalog.com/blog/devops/agility-without-devops-is-pointless/