Once you start unit testing, you will find significant benefits to your design, throughput, quality, and peace of mind. However, it is not easy to start in an organization that’s not used to it. Here are a number of practical tips:
Transformations naturally start with a change in the process and the tools, which inevitably create tension that is supposed to catalyze a deeper change in other elements of the culture. Many implementations struggle and even get stuck at that stage. This is the hard part since it is mostly about people’s behaviors and habits and it takes time. This is exactly where HR professionals come in! I’m not trying to say that only at this stage HR people start partnering and pushing the transformation, I am only emphasizing their importance at this stage. HR departments are key in leading Agile transformations to long, lasting and truly impactful ones.
Let’s say we want to improve quality. We decide to use the Scrum framework. The scrum framework talks about sprints, sprint goals, daily scrum, and many other things, yet it doesn’t directly discuss quality. There is a leap of faith here: we believe that if we will use the scrum framework, quality will improve.
We are relentlessly expanding our tools set
We at AgileSparks help companies create effective, efficient and
At the beginning of a Scrum implementation y, you usually finds two main types of team behaviors. Those who embrace the scrum events (Planning, daily, etc.) and try to better understand them to represent one type. There are many issues and many required adjustments and the team is working on them with the coach.
Other teams view Scrum events as a total waste of time. They do them reluctantly and don’t see any value in it. What do you do? We’ve had several such cases and we wanted to better understand what’s going on there. After a deeper look into the dynamics of these teams, we reached some conclusions that let us sleep better at night.
Lately I had the opportunity and pleasure to facilitate a process of designing cross-functional feature teams in a self-selection process. Self-selection is a facilitated way to let people choose which team to work in. It is surprising how rare this practice is sometimes even considered eccentric while practically it is a simple and fast and produces such great results – well-formed teams with more involved and engaged people.
Why teams self-selection?
It’s a fast engaging process that creates the best conditions for a team to reach high performance.
It’s based on the assumption that with the appropriate context, people will choose to work in a team that they feel will make them be most productive, taking into account the personal relationships with the other team members, the complementary skills they bring and their aspirations for personal and professional development.
You may be smart. You may be intelligent. You may be creative. Yet to really achieve something meaningful, to make a real change, you need to do what the title suggests.
I like words and these three did something to me. There are other good words to describe this but these three are special. For me.
As a coach, I’ve had several opportunities to be involved in the process of big organizations moving from waterfall to agile. You usually start with frowning faces, people coming to meetings reluctantly, armed with a load of cynicism and skepticism. Then after some time, something magical happens – things change to the better. Spring has arrived!
During those first months, at the beginning of the implementation, times are hard. People are struggling. And very soon you start to hear complaints and people telling you how great it was before all this. Before all this agile. When design documents were design documents. When they had time to work. Suddenly the past becomes a lost haven. In training, in coaching sessions, you hear people reminiscing about some glorious past.
The key to addressing these issues is to find out how exactly was it at those times.
Invitation and Pull-based approaches for implementing agile at scale have been a reoccurring theme in my work, writing, and talks in recent years – including
Agile Risk Management Reading list Risk Management in Kanban – The TameFlow Chronologist Risk Kanban Board – Zsolt Fabók Managing Risk on Agile Projects with
Request for additional information and prices
