In this blog series I’ll tell what is high performance team, what is benefit for people and business of them, what is the most important factor of high performing team and how to build them with detailed instructions.
In Part 3 you find instructions how to increase team performance even more with defining performance standards and how to achieve full team commitment to common goal and results.
After you have deal with Absence Of Trust (as instructed in Part 2) you will find it easier to increase team performance even further with these methods.
Fear of Conflict, Level 2
When there is no trust inside the team, constructive and ideological conflicts are being avoid. Instead artificial harmony is preserved. Constructive conflict means conflict with results. Good conflict doesn’t include politics, insults or personal attacks. What are included in constructive is passionate and impassioned debate about ideas. Good conflict doesn’t mean you have to won debate, it means listening to other people opinions and considering their point of views.
Good teams don’t avoid conflicts. They know that difficult and hard things must be handled and then move on. They admit their mistakes, weakness and worries without fear of revenge.
When people doesn’t share their feelings and don’t feel like they are being heard they also don’t want to participate in making decisions.
Politics means that people chose their words according to what listeners wan’t to hear or react, instead saying what they really think about the matter. – Lencioni
Fear of Conflict causes:
- Artificial harmony
- Boring meetings
- Avoiding of difficult topics
- Team members don’t participate in decision making
When conflict are not avoided:
- Meetings become interesting
- Every team member will share their opinions
- Real problems are solved quickly
- Politics are minimized
- Critical topics are discussed first
How to overcome fear of conflict?
First, team must have reached mutual trust (psychological safety, Level 1). Second, you must tell people that conflicts are for good! People must be aware of benefits of constructive conflicts so they can be effective. Sometimes you can even pursuit people to bring up difficult matters for discussion (feed the conflict). It is beneficial to learn to identify artificial harmony.
How to build constructive conflict:
- When you are annoyed by a team mate and hoping that he wouldn’t do something again. Change complain to require (from negative to positive) and tell him what you’d like him to do next time in similar situation instead of complaining about something. Change might seem minor but there is huge different in tone of voice. This lessens frustration and helps to build constructive conflict.
- Real time reminder of need of conflict:
- When team is debating about something in constructive way some people use to withdraw from conflict when tone of discussion exceeds the limits of comfort zone. This is the time when you must remind people that conflicts are for good and encourage them to continue.
Lack Of Commitment, Level 3
Need of consensus and security prevents decision making and commitment which leads to ambiguity about what has been decided and which actions team needs to start doing. Effective teams make sure that everyone’s opinion has been heard and considered. This creates acceptance for any decision that team decides to make.
“Disagree and commit” team can debate about things and disagree but still it is possible for everyone to fully commit to decision. It is better to listen everyone’s opinion and commit to decision even there are no certainty about result than change decision back and forth. When everyone’s opinion are heard there will be no politics. If people feel that they are not heard and if decision turn out to be wrong it will raise “I told you so” comments.
Lack of commitment causes:
- Ambiguity about team direction and priorities
- False feeling about progress and commitment
- More uncertainty and fear of failure
- Possibilities are narrowed down due to too much analyzing
When teams are committed:
- Team direction and priorities are clear
- Whole team has common goal
- Team develops ability to learn from mistakes
- Go forward without hesitation
- Are able to change direction without hesitation
How to reach commitment?
- Setting deadlines for making decision and respecting it makes sure that teams stays in topic and disagreements are handled before they grow too big. When team “forces” itself to make decision after short discussion and analysis they usually understand that quality of decision was better what they expected and that decision would’t have been very much different if more time would have been spent on it.
- Think about the worst possible scenario (Worst Case Scenario)
- By figuring out the worst possible scenario and effect of decision helps to understand that the price of wrong decision is bearable and decision is better that no decision.
- Commitment Clarification
- 5 minutes before the end of meeting facilitator should ask question “What exactly have we decided today?” By being accurate about what has been decided team is able to identify discrepancies before decision is made.
- Commitment to the main principles
- Team must commit to meeting schedules, open communication and accepted behavior. Teams must commit also to other company wide principles such as meaning, purpose, mission, strategy and goal.
Avoidance Of Accountability, Level 4
Fear of stepping out of personal comfort zone prevents team members to require accountability from other team members. Requiring accountability from others demands that team can commit (Level 3) to common goals or accountability cannot be required. When clear goals can be defined accountability can be also required. Team members must be able to bring out behavior or performance which can hinder team. In fact avoidance of requiring of accountability because of fear of stepping out of comfort zone leads to performance declining and that leads to grudge between team members.
Avoidance of Accountability causes:
- Creates grudge between team members because of different performance standards
- Encourage mediocrity
- Team misses deadlines and doesn’t finish what is promised
- Leader of the team is usually seen only one responsible of high discipline
When team takes responsibility:
- Members with low performance feels natural pressure to improve performance
- Potential issues are quickly identified questioning solutions made by others without hesitation
- Removes heavy performance tracking
How to create culture of accountability?
Enemy of accountability is ambiguity. Before you can set expectations clear goals and standards must be known. Setting team goals and some rewards might also help. Team members bring out potential issues more easily when goal is common for whole team.
Team Effectiveness (1 & 2)
Purpose of team effectiveness exercises are to improve accountability by bringing up expectations of other team members and also made a promise about your own performance standards.
1 (Easy, Low or moderate psychological safety. Suitable for new teams)
Instructions on Miro
2 (Advanced, requires high psychological safety. For teams that has been working together for a longer time > 1 year)
Purpose of this exercise is to make possible for team members to give accurate, direct and functional feedback to each other about how individual behavior can affect to team performance.
- Every team member answers to following questions about all other team members:
- What is that person’s single most important behavioral quality that contributes to the strength
- of the team? (That is, their strength.)
- What is that person’s single most important behavioral quality that detracts from the strength of the team? (That is, their weakness or problematic behavior.)
(Note: Any virtual white board tool is suitable for this. Example Google Jamboard. Create own page for every participant.)
When team performance standards are created there is usually decline in performance. But it happens only because it takes time to get familiar with new way of working and eventually team performance will reach higher level than originally.
Inattention to Results, Level 5
Pursuit of personal goals and status crumbles focus on teams collective success. Without accountability people starts to reach for personal goals at the cost of team goals. In sport terms player is satisfied in three personal goals even if team loses the game. For many teams setting clear goals is very challenging.
Goals which team must reach must be made so clear that no one doesn’t even consider doing something just to improve personal status or ego. Because it would inevitably prevent team from reaching it goals. And then everyone would lose. – Lencioni
Team which doesn’t focus on results:
- Don’t grow
- Seldom beats competitors
- Loses goal-oriented members
- Encourages to reach for personal goals
- Is easily disturbed
Team which does focus on results:
- Goal-oriented people stays on team
- Individualistic behavior is minimized
- Wins or loses as a team
- Benefits from individuals who set aside personal goals in favor of team common goals
- Avoids distraction
How to get teams to focus on results?
- Make profit target (or any other goal) public
- Teams who make their goal public will more likely to work for reaching the goal
- Recognition and rewarding based on result
- Bonuses can be tied to results. Although result must not be the only factor of bonus. Economical factors are usually not good way to be the only behavior affecting motivator. Anyway if bonus (full) are given for good work without the expected results, which team was committed, might give wrong feeling about the importance of results.
Most teams gets huge improvement in their performance after they have deal with Absence Of Trust. But once the foundation and momentum of improving team performance is created it is important to use it with methods.
What’s next? High Performance Teams is one step of finding Flow state. In order to reach Flow state and self-steering psychological basic needs (team or individual) must be reached. Psychological basic needs are relatedness, mastery, purpose and autonomy.
Check Gofore’s blog frequently as I will be writing more blogs about how to reach flow state with strenghtening psychological basic needs. Which psychological basic need is the most important from your point of view in order to reach flow state and how have you reached it within a team or individual level?
Technical Project Manager (Scrum Master, Agile Coach)
How to create High-Performance Teams?
Where to start? There are three things every team member can start doing immediately to foster team building:
1. Frame the work as a learning problem, not an execution problem.
2. Acknowledge your own fallibility.
3. Model curiosity and ask lots of questions.
This is a great place to start. If you are interested in more detailed and longer approach, continue reading.
Two perspectives to building high-performing teams
Google researchers believe people can do more working together than alone. Here is their proposal of the characteristics of a high performing team.
According to Patrick Lencioni there are 5 hierarchical levels of dysfunction that might be blocking the way of the team being high-performing. (Patrick Lencioni, 5 Dysfunction of a Team )
The levels are objects that prevent the team from reaching their full potential. In other words, by winning all of these barriers, teams are able to scale their performance almost infinitely and in a sustainable way!
In my experience fixing the absence of trust is “the 20% of work which you get 80% of results”.
Absence Of Trust, Level 1
We trust who we know.
How well do you know your work colleagues? Their hobbies, ambitions or personal background? Forming closer connections with your team members, leads to improved team collaboration. You’ll learn what fires their ambition and keeps them motivated.
– Personal Maps, Improving team collaboration
Absence of trust is the first of five significant factors which prevents teams from reaching their full potential and the high-performance state. It is caused by people are unable to show their weakness and true self in front of others.
Absence of trust causes:
- Time, resources and energy are wasted because of people are building “protective shields”.
- There is a huge barrier to ask or even give help inside the team.
- People feel the need to be invulnerable.
- Team meetings (all) are ineffective.
- People are trying to hide mistakes.
What happens when trust is achieved?
- Innovations are enabled! People aren’t afraid to speak their thoughts and there is no need to be afraid of being mocked by anyone on team.
- Cooperation improves radically.
- Psychological safety is reached.
- Failures and mistakes are shared openly and they are used as opportunities to learn.
How to reach mutual trust?
To practice vulnerability and to improve team spirit can be easily done with the Personal Map method. Personal Map helps team members to share experiences while everyone gets to know each other better (goals, passion, worries and so on). Psychological safety is prerequisite for teams to be proactive. Without trust and safety team members cannot trust that working for team goals also helps them to reach their own goals. Without trust and safety team members will set their own interest before teams interests when making decisions.
Trust is knowing that when a team member does push you, they’re doing it because they care about the team – Lencioni.
Here is how to create a Personal Map (Absence of Trust)
A) Personal map for the whole team
Use this in a team building or retrospectives. Any mind map tool can be used, but I prefer using tools like Miro or Mural. Here is a link to anonymous Mural login: team map. Please contact me, if there are any problems with the Mural.
You need to have an account to use Miro. If you prefer Miro over Mural, here is a team map for you.
Follow these steps when using the team map:
- Create copies of an empty Personal Map for every team member.
- Split the team into 2 person groups (or any other suitable group).
- Randomly give 2 team member names to teams where they are not part of.
- Fill Personal Maps for persons whose name you got.
- Time cap 20min (10min/person)
- Use Post-Its to fill Personal Maps.
- Fill everything you know about the target person in your group.
- Important thing is that in this phase target person is not allowed to participate in filling Personal Map information.
- After Personal Maps have been filled
- Group by group present your Personal Map to target person and rest of the team.
- Target person can fill “gaps” in a way he/she wants.
- Target person can reveal as much or as little information as he/she likes.
- Go through every Personal Map
- This will take time about 5-10min/person.
- That’s it!
- Main point in Personal Map is that it is first created by other team members (that way teams find out how little they know about other team members)
- After that anyone can reveal as much as they like from themselves.
Note! Save your team’s Personal Maps to a common place where anyone can access them if needed.
B) One Person at a time
This is useful when a new member joins the team. The same links and instructions work with this option. The most important thing is that target person is not allowed to participate filling of their own Personal Map. Other team members must do it first. After the Personal Map has been presented to the new member, they can fill in the gaps.
There are also other tools that you can utilize to create psychological safety. Check them out in here.
“A team feels psychologically safe to its members when they share the belief that within the team they will not be exposed to interpersonal or social threats to their self or identity, their status or standing and to their career or employment, when engaging in learning behaviors such as asking for help, seeking feedback, admitting errors or lack of knowledge, trying something new or voicing work-related dissenting views.” – Amy Edmondson
The Personal Map is a very easy method to implement with any team. It is suitable for introverts and extroverts as you can reveal as much as you like from yourself. Do you know how you can grow the feeling of relatedness in your team in order to achieve trust and flow state within a team?
Technical Project Manager (Scrum Master, Agile Coach)
What is the most important factor of a high performing team?
According to Google’s research psychological safety is the most important factor in achieving high-performance teams (or groups with same interest). To put it another way you must feel safe to take risks in front of your teammates without feeling insecure or embarrassed.
High performance teams are build on trust. Research has revealed organizational trust as a key part of culture that directly influences how willing your employees are to go above and beyond in their roles. Frictions naturally occur when humans congregate, but at the same time, our brains are built to work in teams so there is a tension between wanting to be a team member and seeking to avoid conflicts with others by avoiding other humans. Research on the neuroscience of trust has shown that trust acts as a social lubricant, reducing social frictions so working with others is easier, more efficient, and more enjoyable. And when people work more effectively together, productivity and innovation levels rise.
Google’s research revealed that those working in companies in the top quarter of trust, compared to those in the lowest quarter, have 106% more energy at work, are 76% more engaged at their jobs, are 50% more productive, and suffer 40% less burnout. Those in high-trust workplaces are 50% more likely to stay with their employer over the next year and 88% would recommend their company as a place to work to family and friends. Not surprisingly, employees in high-trust companies are 56% more satisfied with their jobs. When one enjoys being at work (high trust colleagues experience 60% more joy at work than those in low trust companies), satisfaction with one’s life outside of work is also higher — 29% higher for those who have the good fortune of working in high trust companies. Trust improves performance no matter how you measure it.
Benefits of a High-Performance Team
Googles research project (project Aristotele) found that psychological safety was both the aspect most reliably shared by high performing teams (among a set of five traits that separated high performing teams from the others with the remaining four being structure and clarity, dependability, meaning, and impact) and also the most foundational of these traits, that is, without psychological safety, you cannot have a high-performing team. Project Aristotle as well as other studies have found that psychological safety is strongly associated with objective (e.g. sales revenue) and subjective indicators of team performance (e.g. ratings of team performance by team members and managers, customer satisfaction with team products). The strongest effect of psychological safety on team performance appears to be through its beneficial effects on team learning with studies reporting psychological safety enabling the faster adoption of new technologies (process innovation), the faster adaptation to new market circumstances and customer requirements, the early identification of potentially catastrophic risks, and the faster development of innovative products.
In this text I’ll tell how to create create high performance teams and unleash full potential of every possible team.
When to invest on team performance improvement?
So how do you know when it is time to start creating a high performance team, is it even needed or is it already reached?
Think for a moment about your work and the work team you are a part of.
Ask yourself the following questions:
- Do people feel comfortable in team meetings asking about things they do not know or they do not understand, or do they generally try to maintain an image of perfect knowledge about work matters?
- Do people feel comfortable in team meetings raising difficult issues, concerns and reservations about specific pieces of work, about ‘how things are done here’ or about how well the team works together or do these conversations take place informally outside team meetings?
- What happens when mistakes, near misses, failures and critical incidents happen? Is people’s first reaction to distance themselves from them so they are not blamed or are they seen as opportunities for team learning?
- How often do people give and receive feedback? Do people invite others who are not members of the team to give feedback on the team’s work?
- In team meetings, are all team members invited to contribute irrespective of their rank or job title?
- Do you feel that your skills and talents are valued and utilized? Are you encouraged to contribute in any way you feel able to? Or do you feel you are you expected to stay strictly within the parameters of your role and to seek permission for doing anything else?
- Have there been times when you felt that your contribution and efforts were compromised by others in the team?
- Do people ask each other and the team for help when they need it?
- In team meetings, do people feel comfortable expressing disagreement and offering dissenting views? Do team meetings include discussions and debates about work matters?
- How much do you know of your team members as people outside work?
What picture do your answers to these questions paint of your team? How much would you say this picture relates to how happy you are with your team and your place in it, and to your team’s performance?
Teams performance can be measured by asking following questions from all team members. If their scores are low then it is time to start investing in performance improvement.
Questions for the team:
1. If you make a mistake on this team, it is often held against you.
2. Members of this team are able to bring up problems and tough issues.
3. People on this team sometimes reject others for being different.
4. It is safe to take a risk on this team.
5. It is difficult to ask other members of this team for help.
6. No one on this team would deliberately act in a way that undermines my efforts.
7. Working with members of this team, my unique skills and talents are valued and utilized.
Tools to help understanding status of teams performance here.
If you think of teams in which you have been a part of, how would you answer to these questions? What are your thoughts to these questions with your current team?
Be sure to check Secrets Of High-Performance Teams Part 2 and Part 3, if you want to get concrete actions on how get your team members to answer “Yes” to these questions and truly improve you team performance!
Technical Project Manager (Scrum Master, Agile Coach)
Design-Systeme gelten schon jetzt als die „neue Norm” in der Produktentwicklung
Die Markttransformation beschleunigt sich auf allen Gebieten und die Bedeutung der Ausfallsicherheit, insbesondere von Produktionslinien, bekommt einen immer höheren Stellenwert. Kundenbedürfnisse ändern sich schneller, manche Unternehmen fusionieren und andere schließen. Einige Lösungen boomen, andere werden obsolet.
Dieser ständige Wandel erfordert auch von den Entwicklungsprozessen für Produkt- und Dienstleistungen, dass sie sich schneller als je zuvor anpassen und auf neue Situationen reagieren. Um dies zu ermöglichen, ist ein systemischer Ansatz erforderlich. Design-Systeme bieten eine Lösung, um Veränderungen in der Produktentwicklung nachhaltig und profitabel zu bewältigen.
Ein Design-System gewährleistet einen effizienten Entwicklungsfluss zwischen verschiedenen Organisationseinheiten in einer sich ständig wandelnden, komplexen Umgebung.
Design-System – was ist das?
Wie der Name schon sagt, nähert sich ein Design-System der Produktentwicklung systemisch, sowohl auf geschlossener, als auch auf ganzheitlicher Ebene. Jedes entwickelte Element – sei es ein Symbol, ein Softwarecode oder eine Komponentenform – ist Teil eines größeren Produktportfoliosystems und kann in mehreren Anwendungsfällen verwendet werden. Das Design-System wird von Designern, Entwicklern und Ingenieuren in Echtzeit aktualisiert und bietet stets Zugriff auf die neusten (Arbeits-) Materialien und Entscheidungen.
Ein Design-System optimiert den Wartungsprozess. Die Pflege eines Systems ist grundlegend, vor allem bei der Software-Entwicklung: wenn eine Komponente verändert wird, passt sie sich automatisch überall dort an, wo sie verwendet wird. Dadurch wird der Aufwand von manuellen Anpassungen drastisch reduziert.
Ein Design-System verbessert die Zusammenarbeit und Kommunikation
Einige der Schlüsselbegriffe des Design-Systems sind Zugänglichkeit und Transparenz. Das Design-System bietet eine Plattform, auf die alle Beteiligten in Echtzeit zugreifen können, sei es beispielsweise die Marketingabteilung, die Konstruktion, die Fertigung, die Produktion, das Industriedesign, die Softwareentwicklung oder die Abteilung für User-Interface Design.
Elemente eines Design-Systems
Das Design-System passt sich an die Anforderungen einer Organisation an, wodurch die Elemente, die es abdeckt, variieren. Einige der gebräuchlichsten Elemente sind:
- Visuelle Bausteine z.B. Symbole, universelle Formen, Schriften (inklusive Schriftgrößen und -schnitten), Warnhinweise, Farbpaletten, Komponenten und Module, Vorlagen, HMI-Muster
- HMI Muster z.B. Fehlermuster, User Interface Interaktionsregeln
2. PROZESSE UND STANDARDS
- z.B. Ergonomie, Tonalität, Gestaltungsprinzipien, UI-Raster, Implementierungsstandards
- z.B. Design-Fertigungs-Workflow, Design-Programmierungs-Workflow, Kontrolle der Komponentenversion, Komponentenanpassung und -verwaltung, Benennungsstruktur
3. EENGINEERING UND SOFTWAREENTWICKLUNG
- z.B. Code
- z.B. Komponenten
Anstatt beim Aufbau des Design-Systems sofort gigantische Entwicklungsarbeit zu leisten, sollten Sie klein anfangen. Gehen Sie Schritt für Schritt vor: in Phasen, die einen sofortigen Nutzen für Ihren Entwicklungsprozess bringen. Seien Sie agil und arbeiten Sie stufenweise.
Starten Sie mit einer Bestandsaufnahme der vorhandenen Komponenten und identifizieren Sie universelle Elemente. Beginnen Sie mit dem Aufbau einer Komponentenbibliothek, auf die jeder zugreifen kann (für weitere praktische Tipps können sie gerne Kontakt aufnehmen). Weitere Elemente können dann später dem System hinzugefügt werden – lassen Sie es parallel zum natürlichen Entwicklungszyklus wachsen.
Das Design-System ist nie “fertig”, aber es entwickelt sich ständig weiter. Es ist also eher eine skalierbare Plattform und anpassbare Basis als eine einmalige, abgeschlossene Lösung.
Ein Design-System spart Geld und beschleunigt den Arbeitsprozess
Häufig auftretende Probleme und darauf basierende Vorteile eines Design-Systems:
VORTEILE DES DESIGN-SYSTEMS:
Ohne ein Design-System:
Nehmen wir an, wir haben ein interdisziplinäres Team aus 40 Personen – darunter Designer, Ingenieure und Programmierer. Und nehmen wir an, dass alle durchschnittlich 30 Minuten pro Tag damit verbringen, über diese Themen nachzudenken:
„Welchen Blauton verwenden wir?“
„Können Sie das neu gestalten? Wir können es nicht bauen.“
„Wo ist unser Logo?“
„Haben wir bereits ein Icon, das wir für diese Funktion verwenden können?“
„Wie haben unsere neuen Kollegen in der anderen Abteilung das Problem gelöst?“
„Wurde dieses Muster woanders verwendet?“
„Wie können wir dieses Muster aufbauen?“
„Wo sind unsere genehmigten Archivfotos?“
„Können Sie das nachbauen, es passt nicht zum Design?“
„Was ist die aktuellste Dokumentation?“
„Entspricht dies den Codierungs- Konstruktionsvorgaben?“
“Wo sind unsere universellen Materialien?” –> 2,5h/Woche pro Person * 48 Wochen * 40 Personen = 4 800 h.
Multiplizieren wir das mit den Kosten von 70€/Stunde = 336 000 €
In diesem Beispiel würde der jährliche ROI eines Design-Systems 336 000 € betragen.
Und noch mehr: diese Berechnung beinhaltet weder die Kosten für die Neuerstellung, noch die schlechte Erfahrung des Kunden im Falle einer falschen Verwendung der Materialien im Entwicklungsprozess.
Und vergessen wir nicht den Faktor Mensch: Der Einsatz des Design-Systems bietet einen Motivationsschub für die Mitarbeiter, indem es alltägliche Hindernisse im Arbeitsablauf beseitigt.
Wir helfen Ihnen gerne bei der Planung für den effizienten Einsatz von Design-Systemen, mit dem Ziel, Ihr Geschäft und Ihre Prozesse bestmöglich zu unterstützen.
Buchen Sie eine kostenlose Planungssitzung bei uns: email@example.com oder telefonisch unter: +49 173 391 0744
Design Systems Simplified – An Outlook Beyond the Trend
A reminder for the weekly team meeting pops up on the calendar. As the participants open their connections, one can hear various sounds of life in the background. Somewhere behind the first participant children are coming up with new games. The second participant’s curious dog would very much like to attend the meeting. The third participant carefully corrects their posture with a sleeping cat in their arms. The fourth arrives and greets everyone: “Hi, we had to negotiate a little, since the whole household is working from home.”
The situation is not fictitious, but at the same time it is not at all unusual. The people working with Gofore’s maintenance services are experienced telecommuters – we work across various cities and even countries daily. The core team of Continuous Services alone is a happy blend of people from all of Gofore’s Finnish sites. Nowadays many things can be taken care of smoothly even while sitting by a lake with a laptop at hand. Functional remote tools alone do not guarantee this fluency. It requires agile, collaborative procedures and efficient knowledge distribution, akin to swarm intelligence, between teams.
During a software development project, it is natural to have one focused core team working on the application and infrastructure development. As the project is completed and the system goes into production, the nature and requirements of the project tend to change. During the maintenance phase, the focus shifts to a more reactive mode of working and new feature development is usually scaled down. At this stage, it is essential that information and know-how about the system and operations is spread across a safety net of specialists. This becomes even more vital in critical situations.
As the current global situation unfolds before our very eyes, there’s been a sudden rise in discussion regarding many things that have perhaps been taken for granted – in particular, remote work and accessibility of services. At the latest this week the entire global community has been waking up to a world that runs rather different from what we’re used to. As anxieties and concerns regarding the global situation and our everyday lives grow, it is more vital than ever that services, large and small, remain operational and accessible. But please don’t worry if it seems like storm clouds are gathering on the horizon – you won’t need to make it to shore alone.
It’s best to pack a life vest while it’s still sunny
When I was a little girl, my grandfather taught me how to row a boat at sea. There was no stepping on the boat dock, let alone actually entering the boat, unless you were securely strapped in your life vest. We blew on the whistles to see that they worked without fault and made sure everything was fastened correctly. We practiced what to do in case an oar should drop into the water. And what to do if the other oar should follow the first, somehow. Someone might consider this silly or see it as an exaggeration, but these lessons taught me more than just safe boating. I learned a surprising amount about risk management in general on the side.
In my current job I rarely get to boat, but I’ve often thought about the similarities between minding a recently released software project and taking proper care of a wooden rowing boat. You should keep the bilge clean, treat the surfaces regularly, and occasionally some more major repairs may be necessary. Choosing a competent partner for the job helps: there’s no need to keep track of required maintenance activities yourself, and the boat (or the application, or the system…) will remain in working order without you having to worry for it – ready for adventures or leisurely rides at any time.
Sometimes a storm can sneak up on even the most experienced seafarer. Peace of mind can be reached even during those times if you’re sat next to a reliable partner who has already double-checked the correct adjustments of your life vest and ensured the oarlocks are in good condition. A professional maintenance service anticipates and prepares for bad weather on your behalf, leaving no room for distress as you are confidently rowing towards more peaceful waters – together.
In addition to meeting and working remotely, we collaborate across teams and sites routinely and steadily. Our agile and modern Service Center operations and maintenance practices are organized to ensure that no service remains a one or two person show. We arrange on-call responsibilities flexibly and distribute expertise and knowledge between teams and specialists, and our service managers ensure the quality of service in collaboration with the Service Center lead.
Our Service Center includes both system specialists and software developers, each one of them just as fluent in collaborating with customers as they are in resolving technical pickles. Our common goal in everything we do is to make sure the customer never has to wonder whether we can offer a particular type of support or whether we have expertise on a particular matter – we will take care of it for them.
What do you say, could we bring you some peace of mind, too?
Service Center Lead
Businesses must adapt, learn and transform faster than ever to make the most of the changing digital landscape. Gofore helps take on this challenge: together we harness design principles, strategic thinking and rapid execution to create new value and competitive advantage.
Diagram 1: Gofore works on all levels of the business
Gofore helps with creating 5G
In the Telecom sector, Gofore has successfully helped clients to enable the infrastructure for 5G and the Internet of Things to transform the human experience – globally. Gofore has enriched software development to support proofs of concept and content creation for delivering services provided by innovative solutions, such as AI, analytics, machine learning and big data.
Alongside strategic thinking and technical expertise, Gofore has brought Agile and Lean coaching to the table. “We have integrated into existing strategy work with our iterative approach. We see that strategy is about fast paced delivery, the ability to scale with the help of standardised practises and building a learning organisation. We continuously analyse change to find useful patterns to apply to software development. Our goal is to focus on what could be as opposed to what is”, comments Juhana Huotarinen, Agile Transformation Advisor at Gofore.
Juhana Huotarinen on stage, walking through the Agile transformation ideology
Feedback from one of our global market leading clients says: “For us, it has been important that Gofore has been fully committed and accountable for what we are aiming to achieve. Our collaboration with Gofore is transparent, committed, accountable and supportive. Specifically, we are very satisfied with the Agile methodology and technical expertise Gofore has brought.”
In practice, Gofore planned and coordinated a new multi-disciplinary, multi-team, multi-site high performing transformation program including Agile coaches and software specialists. This was achieved largely by creating a permissible culture which encourages collaboration and self-learning. The core competence of Gofore is to make complex things straightforward. Whether that means complex business, organization or technical challenges.
The First Steps of Transformation
We are now starting to see commercial 5G networks scaling up for transforming business and delivering better customer experience. Previous wireless technologies were about connecting people. The new characteristic of 5G is that it has all the ingredients for automating business processes and it is a great technology for business transformation. There surely are challenges to tackle in how to build the capacity in a dynamic and flexible way, how to address operational inefficiencies by leveraging automation/AI and how to increase revenue growth by means of service differentiation and the ability to leverage partners’ ecosystems. Not only with bleeding edge software, but with enabling agile strategy and culture.
Have you taken the first steps to transformation?
YOU MAY ALSO BE INTERESTED IN THESE POSTS:
“80’s rule man, best time ever! Then that Cobain had to come around and ruin it all.” is a funny quote from the movie Wrestler. Today’s software experts might also yearn for former times. In the waterfall model, the role of architecture was clear – it was designed up front, after requirement analysis and before the implementation phase. In the current Agile era, architecture is often evolving without clear goals and objectives.
Yin and Yang
According to “Clean Architecture”, the purpose of architecture is to support the lifecycle of the system. The ultimate goal is to minimise the lifetime cost of the system and to maximise programmer productivity. Traditionally, dedicated experts have been accountable for this function. In this blog, these experts are called software architects, but technical leads and stack leads are also commonly used titles. Typically, software architects have a strong technical background and good leadership skills.
One of the Agile core values is the development teams’ autonomy. Teams design, implement, test and deploy independently. Traditional Agile methodologies, such as XP (Extreme programming) and Scrum, do not mention how architecture design should be led in practice. XP advises, for example, that architecture design just emerges alongside other design.
The larger the project (i.e. multiple teams), the more complex is the product’s software itself. This means that architectural decisions will have a bigger impact. The question then arises how architecture design is led and what responsibilities software architects versus teams have?
Make your system visible
Systems thinker and the father of the quality evolution, W. Edwards Deming has said that 96% of organisational performance is a function of the organisation’s structure. Only about 4% of an organisation’s performance is attributable to the people. Part of the structure is to understand how collaboration works in the system.
The following table makes collaboration between architects and teams visible. Every row of the table represents a potential point of leverage. The columns represent different options as to how collaboration can be implemented. Left columns represent a more distributed and emerging architecture mindset (i.e. Agile) and the right columns a more centralised and formalised approach. Organisations are different, and therefore leverage points and options vary as well. Rows are also independent, so for example “Architects are part of the teams” and “Architects are dedicated mostly to architecture topics” can be used on the same project.
<– more distributed more centralised →
Point of leverage
|Hierarchy levels||One level – no special roles, just team members||Two levels. Developers and architects||Three levels+. Team members, architects, chief architect|
|Scope of software architects||None||Architecture principles (e.g. standards, concerns, styles)||Architecture principles and infrastructure & operations||As option 3 plus enterprise architecture|
|Alignment||No architects. Team member is the only role||Architects are part of the teams.||Architects work as free agents||Architects form a team or department|
|Decision making||No architects. Teams make architectural decisions||Teams and architects make architectural decisions together||Architects make most of the architectural decisions|
|Division of Work||No architects. Teams share responsibilities dynamically||Architects and teams share their responsibilities dynamically||Architects have predefined responsibilities|
|Capacity||No reserved capacity. Teams use their time on architectural topics if needed||Architects/teams have reserved capacity for architecture topics||Architects are dedicated mostly to architecture topics|
No “one-fit for all” solution
After the current collaboration model is defined, the next step is to decide the future direction. Organisational systems are determined by their context, so “one-fit for all” solutions aren’t appropriate. Nevertheless, some conclusions can be drawn.
Typically, the long-term goal should be to move to the more distributed and self-organising collaboration model. When people understand the collaboration strategy, it is much easier to take actions toward it. Unfortunately, organisations underestimate the amount of work that the transformation requires. People have different skills and expectation levels and unlearning at both the organisational and individual level is required.
Agile is also a highly disciplined method. Business people and team members must work together daily; the cross-functional team structure is mandatory and software delivery must be frequent, to name just a few principles. If the organisation won’t bend to these demands, a more centralised collaboration model might be the valid option.
Sub-optimising is also a risk in bigger organisations. A team might violate architecture principles thoughtlessly, just to finish their sprint backlog faster. The other team might implement a similar service that has been already created by another. Architects see more easily the whole and are able to make holistic decisions.
Many organisations’ technical debt is huge as well. Products suffer wrong technologies or bad programming practices and an enormous amount of refactoring work is needed. Painful architectural decisions are often made more efficiently by a more centralised collaboration model.
A hero is required
Software architecture is not the hottest topic in the software development field. In addition to this, it is very abstract and hard to lead. However, all software has an architecture regardless of if the architecture is managed or not. Smart organisations understand that the organisation structure should be optimised for the most crucial paths of collaboration – and collaboration between teams and architects is part of it.
The Clean architecture – Robert C. Martin
Technical leadership and the balance with agility – Simon Brown
Have you ever been really into your work but didn’t have anybody who shared your enthusiasm when you started gushing about it? Do you work as a specialist in a multi-functional team and don’t seem to have direct support for challenges related to your specific domain? At Gofore there might be a guild that could help, or maybe you need to start one?
About a year and a half ago the project I was working on restructured which lead to our scrum master leaving and me transitioning to the role of scrum master. Our product owner was also replaced by a team of three product owners. Simultaneously the project goal changed from a proof of concept to get a release of the product out in three months so the number of developers was also ramped up. Because our team was made up of experienced developers already familiar with the product I found myself in a situation where most of my time was focused on getting the product owners on track with their roles. After a couple of sprints I realized that I hadn’t had a chance to even assign myself a ticket, I had transitioned to a full-time scrum master position. While I have several years of experience as working as scrum master and developer I quickly realized that being a dedicated scrum master was a very different role.
My perspective drifted away from the product I had been building in the proof of concept phase and I started focusing on how the team was working not what it was working on. I wasn’t as interested in what decisions the product owners were making but on how to get them to make any decisions at all. And then I realized I was the only person on the team focusing on these issues. I started wondering how similar issues were handled in other projects at Gofore and how I could ask our more experienced scrum masters, product owners or project managers about these issues, so I invited them to lunch.
Since I had been working in project management roles earlier I had a company credit card and reserved a table at a nearby restaurant for lunch and invited everybody working at the Helsinki office who I knew had worked or was working in a scrum master role. I think the offer a company-sponsored lunch combined with curiosity led to around seven people coming and we shared news and thoughts about our project work. Since everybody didn’t have a chance to talk about their project I decided to have another lunch or breakfast the following month and I promised to organize a doodle for the date. This quickly became a monthly thing.
I didn’t ask anybody’s permission to organize these lunches, I just used my own judgement that they were needed. Being true to the Gofore spirit of transparency I was as open about the costs and the time I spent organising the guild lunches as I could be. From the beginning, our lunches were a bit fancier than your regular working lunch, because I thought that it is important to communicate that we as a company value learning from each other. Also having the meetings outside the office gave a sense of detachment that you don’t get in a familiar meeting room.
I happened to mention about these lunches we were having to our Lead Coach Heini while I was visiting our Tampere office and she informed me that I had started a guild.
On the train, on the way back from meeting Heini in Tampere I changed the name of the page recording our lunches in our confluence to the Agile Leadership Helsinki Guild. There are some other guilds in our company but their role hasn’t been strictly defined. Each guild is a bit different in how they work, but they all relate to professional development. Ever since the beginning, sharing and sparring project-related challenges have been a staple of our lunch meetings. At some point, I stopped doodling and we agreed that our lunch date would be on the last Thursday of each month. It was easier that way, and knowing the lunch dates several months earlier makes it easier to reserve the time needed to be away from the client.
We started having short introductions to agile related subjects at the beginning of the lunches. This was a great way to share experiences when somebody attended a conference or external training. At some point, Anu joined me as the champion for the guild and having a dedicated person with whom to share guild related ideas with made guild work a lot more fun. We started organizing training sessions outside of lunches that were directed to guild members as well as open for others at Gofore. The latest thing our guild has done has become a platform for helping members go to conferences and on external training courses.
I gave up the position as guild champion at the beginning of the year and the current champions are taking the guild forward and doing stuff I didn’t have time for. I am still actively involved and enjoying having a community to reflect my project work, Agile Finland work and Agile Transformation and Lean capability work.
Lessons learned from starting a guild at Gofore
While I had a useful experience from working with volunteers in the scouts and in university organizations, this was the first time I had started a completely new organization or community. This gave me the chance to reflect on my previous experience in volunteer leadership, combined with formal academic knowledge from Knowledge Management studies at university and professional project management experience. At Gofore we have many social clubs (or Glubs as we call them) where like-minded colleagues come together to discuss everything from investment opportunities to the latest beer to be launched. Guilds help unite people over professional interests compared to glubs leisure focus. If you have an interest, professional or extracurricular, starting a community around it at Gofore is a good way to network with your colleagues. There are now many guilds covering a wide variety of software solutions and related fields like design. Below are my experiences of setting up a guild for Agile leadership, but they apply for setting up glubs as well.
- Having a personal need to fulfil when starting a new project helps when you need motivation or need to pivot.
- A guild is a community so starting one is really hard.
- Starting a community is basically a culture change or creation project.
- When starting aim for consistency with minimal effort.
- You can never over-communicate or over promote guild related events or issues.
- Culture change projects need a champion so don’t worry about things being personified to you.
- Because it’s voluntary don’t be afraid to make choices and do the work even when you don’t get feedback.
- It is great to have a community for sparring your project work and personal development.
- The strength of the guild comes from the fact that even though participation is work time it still voluntary so people participate from their intrinsic motivation.
- The biggest obstacle for people participating in professional self-development work like guilds is loyalty to the customer and interesting customer projects.
I believe it is important to keep up to date with developments in your professional area of interest. Gofore guilds are a great way to, not only keep up to date with professional developments but also to network with like-minded colleagues. It’s great that Gofore actively support and encourage guilds and glubs. Connecting with your co-workers over shared interests is a great way to contribute to the collaborative and supportive working environment.
By now, it has become an annual tradition at Gofore to conduct a Project Radar survey at some point of the year to gain better insight into our presently running software projects. The 2018 Gofore Project Radar builds on two previous Project Radar iterations, conducted in fall 2016 (in Finnish only) and spring 2017, containing a set of questions relating to currently employed tech stacks, development practices and projected (or hoped-for) technological changes. Most of the questions from last year’s Project Radar made their way into this year’s Project Radar to allow for year-on-year variation detection. We also added some new questions that were considered important enough to warrant their inclusion in the survey.
So with the 2018 Project Radar results in, what can we tell about our projects’ technological landscape? What can we say has changed in our technological preferences and project realities over the past year?
The Gofore Project Radar survey results for 2018 are in! [Click on the image to enlarge it].
Over the past few years, the frontend development scene has shown intermittent signs of “framework fatigue” as a steady stream of new frameworks, libraries and tools has flooded the scene, challenging developers to work hard to keep pace with the latest developments, current community preferences and best practices. A look at our Project Radar data tells us that at Gofore there has been no significant churn when it comes to primary frontend technologies employed by individual projects. Instead, the results indicate a distinct consolidation around React, Angular and Vue.js, the three major contenders in the JS framework race. All these three have gained ground on older frontend techs (AngularJS, jQuery etc.) and ratcheted up their project adoption percentage, React being the top dog at a near-50% adoption rate among projects represented in the survey. If given a chance to completely rewrite their project’s frontend, most respondents would, however, pick Vue.js for the job.
The fact that there was no major change from last year in preferred frontend frameworks is perfectly in line with developments (or lack thereof) on the frontend scene over the past year. While last year saw major releases of both React and Angular roll out (with Vue.js 3.0 still somewhere on the horizon), there were no new frameworks to come along that would have been able to upset the status quo and catch on big time in the community (regardless of distinct upticks of interest in at least Svelte.js and Preact). This stability comes in stark contrast to the unsettled years in the not-too-distant past when the balance of power between different JS frameworks was constantly shifting as new frameworks and libraries appeared on the scene.
Looking beyond the battle of JS frameworks, a significant trend with regard to frontend development is the ever-increasing share of single-page applications among our projects’ frontends. Around 64% of this year’s Project Radar respondents reported to be working with single-page applications, up from 57% in last year’s Project Radar results.
Node.js on the rise
Moving our focus to the backend, where Java has traditionally held a predominant position among our projects, a somewhat different trend emerges. While the Project Radar data clearly brought out a tendency toward consolidation around the three major frontend frameworks, the picture on the backend side, on the other hand, looks a little more fragmented. Last year’s Gofore Project Radar pegged Java usage at nearly 50% among all projects represented in the survey, trailed by Node.js and C# each with a 15% share of the cake. While Java still came out on top this year, it was reported as the primary backend language in only 32% of the projects, down a whopping 15 points from last year’s results.
This drop was fully matched by an upward surge by Node.js, which more than doubled its share of the overall pie, up 17 points from last year. While C# stood its ground at close to 15%, a crop of new languages, missing from previous years’ results, entered the fray in the from of Kotlin, Clojure and TypeScript. Regardless of there being only a handful of projects where they were reported as being primary backend languages, they contributed to the growing share of minority languages in our backend landscape, a group previously comprised of Scala, Python, Ruby and PHP.
Similarly to how respondents were asked to choose their hoped-for replacement tech for their frontends, we also asked our developers what was their preferred language for rewriting their backends if given the chance to do so. Last year most respondents would take the cautious approach and stick with their previously established backend languages. This year, however, there was considerable interest in rewriting backends in Kotlin, particularly among respondents who reported Java as their primary backend language (55% of all respondents were eager to switch to Kotlin from some other language).
Before drawing any conclusions from these statistics, it should be noted that upwards of 55% of respondents reported to be working with a microservices-type backend stack, suggesting that potentially multiple languages and server-side frameworks might be used within a single project. Still, the appeal of Kotlin, particularly among Java developers, is clearly apparent, as is the shift toward Node.js being the centerpiece of most of our backend stacks.
The popularity of Kotlin, on the other hand, has been picking up ever since Google enshrined it as a fully supported language for Android development. Considering its status as one of the fastest-growing programming languages in the world, its increasing presence in server environments is hardly surprising.
Now where do we run our project infrastructure in the year 2018? According to last year’s Project Radar results, more than two thirds (68%) of all respondents were still running their production code in a data center that was managed either by the client or a third party. This year, that number had come down to 59%. While this isn’t particularly surprising, what is mildly surprising, though, is the fact that IaaS-type infrastructure saw an even greater decline in utilization. Only 47% of all respondents reported to be running their production code in an IaaS (Infrastructure as a Service) environment, as opposed to 60% last year.
As the utilization of both traditional data center environments and IaaS services fell off, PaaS (Platform as a Service) and, especially, serverless (or FaaS, Function as a Service) platforms were reported to take up a fair portion of the overall share of production environments. While still in the minority, PaaS services were reported to be used by 12% of all respondents, tripling their share of 4% from last year, and serverless platforms by 16.5% of all respondents (no reported usage last year as there was no dedicated response option for it).
As our projects’ production code is more and more removed from the actual hardware running it, containerization has also become more commonplace, as evidenced by the fact that Docker is now being used by 76% of all respondents (up from 43% last year). Despite Docker’s increasing adoption rate, there wasn’t much reported use for the most popular heavy-duty container orchestration platforms: Kubernetes, Docker Swarm, Amazon Elastic Container Service and OpenShift Container Platform were only reported to be used by 14% of all respondents.
Since running our code in cloud environments enables shorter deployment intervals, one could think we’d be spending more time flipping that CI switch that kicks off production deployment. And to some extent, we do: we have fewer projects where production deployments occur only once a month or less often (10% as opposed to 20% last year), but, somewhat surprisingly, fewer projects where production deployments are done on a daily basis (10.5% vs 12% last year).
- Key-value databases doubled their reported project adoption (32% vs 16.5% last year)
- Jenkins was the most prevalent CI platform among represented projects, with a 57% adoption rate (its closest competitor, Visual Studio Team Services/Azure DevOps well behind at 17%)
- Close to nine percent of all respondents reported to be using a headless CMS (Content Management System)
- Ansible was being used by 71% of respondents who reported using some configuration management (CM) tool, clear ahead of any other CM tools (Chef was being used by a little shy of eight percent of CM tool users, while Puppet had no reported users)
- Development team sizes were smaller than last year (57% of dev teams had five or more team members last year, whereas this year such team sizes were reported by 52% of respondents)
- The reported number of multi-vendor teams was smaller than last year (41% vs 47% last year)
- Most respondents reported to be working on a project that had been running 1-3 years at the time of responding
- Most project codebases clock in at 10k – 100k in terms of LOC (lines of code)
- Scrum was the most favored project methodology, being employed by nearly 51% of all represented projects. Kanban, on the other hand, saw the most growth of any methodology (22% vs 12% last year)
Some closing thoughts
Once again, the annual Project Radar has told us a great deal about our preferred programming languages, frameworks, tooling and various other aspects of software development at Gofore. While the survey is by no means perfect – and I can easily come up with heaps of improvement ideas for the next iteration – the breakdown of its results enables us to more easily pick up technological trends in our ever-increasing multitude of projects. This year’s key takeaways are mostly reflections of industry trends at large, but there are some curiosities that would be hard, if not impossible, to spot if not for the Project Radar. The usefulness of these findings is debatable, as some of them fall under trivia, but still they come as close to a “look in the mirror”, technology-wise, as one can get at a rapidly growing company of this size.
Dave Snowden says that human intelligence is especially based on utilizing patterns. “Our ability to link and blend patterns … gives us the ability to adapt to a rapidly changing context and, critically to innovate”. Metaphors, patterns and stories are the most powerful tool of explanation, knowledge transfer and teaching. We have a limited capacity of information processing capability, but it is not the basis of our intelligence. One group of people make decisions purely based on information processing, and they are autistic. Whether you are communicating a feature in a software project, or a marketing vision of a large enterprise, the best way forward is to communicate it as a story or as a metaphor.
A best practice is a method or technique that has been generally accepted as superior to any alternatives because it produces results that are superior to those achieved by other means. You may find best practices for example in agriculture, medical and manufacturing. Software development has its own best practices. Agility, continuous improvement, prioritization, active communication, design patterns, QA and CI/CD. Agile manifesto itself is a list of best practices. For a seasoned expert, these sound like a no-brainer. Well, how on earth do projects still fail?
While working as a Scrum Master, one realizes that while pursuing well-known best practices, the same bad practices keep popping up again and again. These bad practices form a list of common pitfalls, which are called antipatterns or in an Agile context ScrumBut. The antipatterns can be used as-is, but they are most effective when used side by side with the best practices. Work towards the best practices. Work away from the anti-patterns.
Sprint is too short or too long
- Too short a Sprint (less than a week) increases the ratio of bureaucracy beyond an acceptable level. Too long a Sprint (a month or more) makes it hard to react to customer requests and the feedback loop becomes too long.
- The best practice is to keep the Sprint a bit on the short side, so the feedback and correction frequency stays fast.
- Too long a sprint also allows one to create mini waterfalls inside a sprint
- Often is better
Sprint produces nothing working
- Whatever was developed during the Sprint must be running in at least the QA-environment at the end of the Sprint.
- When software is not integrated, tested or deployed during the Sprint, work will overflow to the next Sprint. This means that it is impossible to change direction between the Sprints. One must first pay off the technical debt that has been created in a form of non-functional code. If nothing new works after the Sprint, the speed is 0.
- Often the “almost ready” features require days of work to finish. You can speed up the completion of difficult tasks by having daily status checks. In the most critical situations, the best way is to set up a “war room”, where everybody concentrates only on finishing or fixing a single feature.
- The best practice is to finish the earlier task before starting a new one.
- Stop starting and start finishing
No (real) Product Owner
- The Product Owner prioritizes and clarifies.
- The Product Owner provides a list of the most important Use Cases and a detailed description of each. The task of a Scrum Master is to tell if those features fit into the next Sprint. The less you start, the faster you finish.
- A common malfunction is a customer who wants software to be developed but doesn’t commit to the development process. Either there is no Product Owner, or the person is too busy/doesn’t know the domain/doesn’t have the authority to make decisions. In this situation the Scrum Master should coach the customer; book a weekly meeting with the customer representative where the roadmap is being clarified and broken down into detailed tasks.
- The best practice is for the Product Owner to have a detailed plan for the next few Sprints.
- The task of a Product Owner is to maximize the value of the Agile team
Requirements are not communicated
- A big up-front requirement specification helps nobody.
- Use Cases must be communicated between the Product Owner and the development team before the development work starts.
- The development should never be based only on a document. This will always cause the first version of the software to come out as unsatisfactory. It is much faster to clarify the details over a telco, than to code-test-integrate for weeks and to find out that the requirement spec wasn’t top notch.
- Coding a non-communicated requirement creates useless technical debt.
- The best practice is to have a clear and shared plan for the next few Sprints
- Prioritization forces the team to have important discussions regarding the content and their importance. What user group to serve first? Non-functional or functional first? New features or regulations? The common symptom of “no estimates” is that the Sprints produces nothing functional.
- It’s the team that estimates the stories being planned for the next sprint, and it’s the team that commits to do their best meeting the sprint goals.
- When the Use Cases have estimates, it is easier to prioritize and plan their development. It is also easier to identify the cases, which need to be divided into more fine-grained Use Cases. Estimates are created semi-automatically when the requirements are communicated to the team. When the Product Owner clarifies the Use Case and the team divides it into technical tasks, estimates will emerge. Estimates will also inform the team velocity. If you divide all stories to roughly similar sizes then you can skip estimation and just count the number of stories.
- The best practice is to have a clear and shared plan for the next few Sprints
- No prioritization usually leads to starting too many Use Cases. This leads to Sprints that produces nothing.
- Incorrect prioritisation also delays feedback on critical decisions, while the team develops something irrelevant.
- The best practice is to have the product backlog prioritized for the next couple of Sprints. It should be fairly easy for the Product Owner, Scrum Master or the Architect to explain the Use Cases of the next few Sprints.
- The best practice is to start nothing new before something finishes AND then start the highest priority task.
- Less is faster
- Each Sprint should provide the team with feedback. The customer gets the demo. The team gets the retrospect. Each Sprint is a step towards better practices. One aspect is the project management tools with their analyses and reports.
- The best practice is to produce a functional demo and have a Sprint Retrospect. Repeat, the best practice is to have a retrospect after every Sprint.
- Reflect regularly
- The best way forward is to support or coach the inefficient team member. Usually, people are not lazy but too busy. Mentoring and coaching are good ways forward.
- The best practice is for everyone to keep developing and improving.
- Each team member must allocate time for self-development
- The team must be able to self-organize. Team members must be able to work individually, but more importantly they must be able to work as a team. Shared ways and common rules. Cherry picking when choosing tasks, coding too low or high quality, forgetting the common rules etc. are signs of a hot-shot not able for teamwork.
- The team must allocate time for team development
Doing the right things at the right time
Agility means making the right decisions at the right moment. Traditional management models are more interested in doing things right. This leads to an inside-out way of thinking. “We have a CMMi5 level quality standards”. And still, the customer gets no additional value. Such management creates tons of additional bureaucracy without creating anything useful. Agile development advances with the best possible speed towards the best possible direction. Speed and direction are revised constantly when new information and feedback emerges. In sports, one improves agility by doing neuromuscular exercises in a well-rested condition. The same goes for knowledge work. Stress, fatigue and haste kill agility; Work becomes stiff and laborious. W. E. Deming stated that 95% of performance issues are caused by the system itself and only 5% is caused by the people. Even talented people will fail if the system does not give them room and freedom to prosper. Organize outside-in. Customer first.
Exploring ScrumBut—An empirical study of Scrum anti-patterns
A fixed project always fails
Why to scale Agile
How to scale Agile
Reflect the ways of working in your organization