The Agile Network Community

This is our community page where you and your peers share ideas and insights.

Share your thoughts and ideas via a video

Join our next workshop!

Write a blog post about your experiences or thoughts that you want to share with the community.

Want to share on the community page?
Share today
See the form below (about the community)

Is there a topic that you’d like to ventilate with your peers in Agile and Lean? Let us know and we will help you to set up a video meeting with us and invite peers from the community. 

"Would you like to become my mentee?"
Christian Wikander
Development Team Manager at IKEA Group

How Scrum builds effective teams

Christian is the network’s first community supporter and he is passionate about Agile and Lean working methods. Here you’ll find his first shared key learning working with Agile. 

While I’ve had the knowledge about both effective teams and scrum for quite some time, I have not considered how they actually interact, not until I attended the event “How to build the best team” at Minc, cooperation with Psykologpartners.

During the event Prykologpartners among others talked about a study by Google which outlines The 5 dynamics of an effective team.

I suddenly realized exactly how some of my scrum habits actually built my teams. It’s not a coincidence. Scrum builds effective teams!

The 5 dynamics of an effective team

 According to Google, effective teams have the following five dynamics :

  1. Psychological safety: This was the single most important dynamic in an effective team. Psychological safety is about risk-taking and being comfortable with vulnerability. People who don’t feel psychologically safe worry that taking risks will mean they’re seen as ignorant, incompetent, negative or disruptive. Psychological safety means feeling confident about admitting mistakes, asking questions, or offering new ideas.
  2. Dependability: On dependable teams, members reliably complete quality work on time. They don’t avoid their responsibilities and they take them seriously, helping to keep the team on track. As simple as it sounds, this turned out to be vital for effectiveness in teams.
  3. Structure and Clarity: This means that a team has clear roles, goals and plans. Individuals understand what’s expected of them, what they and their team is aiming for and how they are all going to get there. Google often uses Objectives and Key Results (OKRs) to help set and communicate specific, challenging and attainable short- and long-term goals, at an individual and at a group level.
  4. Meaning: For individuals on a team, finding a sense of purpose in their work or its output is vitally important for team effectiveness. That meaning is personal, so it varies from person to person, but might include financial security, their ability to support their family, their commitment to the success of the team, or their individual self-expression.
  5. Impact: Do you fundamentally believe that the work you do makes a difference? This subjective judgment marks out the most effective teams and can be based on seeing how one’s work contributes to an organization’s goals and what it has helped to change.

How Scrum helps

Below is a simple diagram outlining a sprint in the Scrum Framework.  The sprint is typically two weeks long. What I have realized is that if you just take care of your Scrum process you will get positive effects when it comes to team performance.

Product Backlog

The Product Backlog helps describe the Meaning of the team and to some extent also the Impact.

Keep your Product Backlog in good shape and make sure it’s known by the team. While not mentioned in the Scrum Framework it’s a good habit to have a meeting in the middle of every Sprint to go over the backlog, discuss new backlog items, adjust story points etc.

Make sure you backlogs are containing User Stories. They help the team focus on when and why a function will be used which has a connection to the Meaning and Impact of what we’re doing.

Sprint Planning, Sprint Backlog, Increment and Sprint Retrospective

Scrum is set up to deliver value iteratively. By biasing your Sprint Planning and Sprint Retrospective towards becoming more and more predictable you help your Dependability as well as Structure and Clarity.

I tend to treat the Sprint Backlog as a firm commitment, i.e. we should do all we can to deliver on these promises. If we fail we should make sure we don’t do the same mistake again by analyzing the problem during our Sprint Retrospect and take action.

Focusing on what we can finish rather than what we can start might also be helpful when trying to become more predictable.

Daily Scrum

Done right, our Daily Scrum will help a lot towards Psychological safety as well as Dependability. We typically build Psychological safety by showing that we are vulnerable. Admit that you’ve done a mistake, ask for help etc. In a safe environment your friends in the team will rush to support.

Sometimes the Daily Scrum becomes more of a meeting where people report what they have been doing. This is encouraged by project managers that want to know the status of the sprint. Usually though the things that have not been done are much more important than what has been done.

Encourage team members that have problems with their task to reach out for help and make sure that there is someone to help when they do so. A good tell is when a high priority task has been sitting in the same column for several days. Make sure that the team understands that it’s good to reveal mistakes and problems. Knowing early means that the entire team can do something about it.

Sometimes it helps to do a short vote on how likely it is that we will finish everything on the Sprint Backlog in time. This can be done using a 0-100% gauge or similar. Have the team discuss the right level of the gauge, if the value is low we should asses why and take actions to raise it.

Conclusion

As you can see, Scrum supports building effective teams quite well. By just sticking to some of the Scrum Events and Artifacts your team will evolve towards being more effective.

This however doesn’t mean that Scrum is a silver bullet for effective teams. Among others Scrum is focused on teams while Google also talks about personal motivation.

By Christian Wikander

Key learnings from two years with IKEA

Christian is the network’s first community supporter and he is passionate about Agile and Lean working methods. Here you’ll find his first shared key learning working with Agile. 

The first learning is the importance of frequent deliveries. Frequent deliveries have a number of benefits and should be adopted as soon as possible. You should be able to get to a delivery cadence of two to four weeks if you put your mind to it.

Frequent deliveries…

… Builds trust. Your stakeholders know that even if you fail with one delivery (you will), they only have to wait two weeks for the next one.

… Enables fast feedback. When you deliver functionality to a stakeholder you also allow them to provide feedback. Early feedback means that you will know early if you are going in the right direction. Fail fast.

… Turns our investment into profit. Until we have released something we are investing our time in the solution. While the investment may seem like a good thing (it is), the sole purpose is to make a profit from the investment. The profit is enabled by delivering your functionality. Until you’ve delivered you are just a cost.

A common objection to delivering often is that there needs to be some minimum functionality available for a feature to be useful. Leave this judgment to the marketing people. Concentrate on delivering and give them the benefit of choosing if we should market the feature. Let’s not be the ones that prevent the profit from our investment.

… Reveals our bottlenecks. When trying to release often you will quite quickly be aware of where your bottlenecks are. Find them and fix them. Releasing software is not a value adding exercise, make sure that the effort is minimal.

The last bullet leads into my other learning, the importance of automation.

When developing software you want to spend as little time as possible on fixing customer problems. An error report from the field means that a customer is unhappy, but it also often means that we need to hold off on our new development to address the issue found.

The best way to prevent annoying your customers is to create an automated regression suite covering all business critical flows. There is a balancing act here. You can build too much automation making the test suite too slow for your needs. But the bottom line is that functionality that is covered by automated testing will not fail. And keep in mind that humans are smart people, if there is a way around a problem, most users will find it. They may still report an error, but at least they are not held up.

If you want to take this a step further, consider test driven or even better business driven development (TDD/BDD). If you are writing automated tests, you are much better off doing it early because that will allow you to save time on automated testing in the sprint. I’d like to offer a provocative thought. If your functionality is not important enough to be covered by automation it means that we do not think it’s important to test all the time. Why then test it at all? Build your automation up front, and let that be all your testing.

In the end, you can spend more time on what most software engineers love the most, building new functionality.

Writer

Christian Wikander

The Start & Stay Agile Workshop

The Start & Stay Agile workshop 4th of June

We had an interesting morning the 4th of June about how to implement change in an organisation.

Katarina Erlingson talked about her experience in how to deal with mind set shifts, finding new ways to approach old rules and toxic cultures/organisations.

In the workshops we identified challenges to change, such as a lack of communication and transparency and when not all levels in the organisation understand what Agile means.

The solutions generated by the participants focused on the people perspective. After all, it is seldom the structures themselves that cause the problems, rather how they are understood and applied.

Identification of challenges:

  • The need of mind set shift
  • The lack of clarity of goals
  • Management need to work in a new way
  • Uncertainties related to change

Identification of solutions:

  • Communication of goals to all levels and stakeholders
  • Visualisation to generate concrete outcomes
  • Work on safety of the group and seeing mistakes as a learning opportunity

Tool: SOLO (Structure of the Observed Learning Outcome) as a structure to identify, follow and support a learning process

The challenges identified in the workshop were mostly related to the mind set shift needed; we identified problems such as the difficulty in creating a common understanding of goals and how to get managers to redefine their role (from ruler to enabler). The mind set shift, like all change, also gives rise to uncertainties, many of which has to do with lack of time to understand to processes and what it means for the individual.

The solutions centred around the people processes, the need to get everyone on board. By communicating and anchoring goals, we contribute to motivation and mind set shifts. The goals also need to be clarified, eg by visualisation, so that everyone knows what we are going to achieve. This will also enable the management to let go of micromanagement and focus on the outcomes. The challenges of uncertainties can be met by working on group safety and trust, were we encourage the discussions around what can be learned from mistakes, rather than punishing them. 

We also tried out a tool that enables you to facilitate a learning process (SOLO). Learning takes place in identifiable steps and you need to adapt the learning to the step you are on. If you try to teach on eg step 4 when the organisation is at step 1, you will have no advancement. Hence, a tool to identify where your organisation is in the learning process is vital for mind set shifts.

Download the workshop presentation PDF here or here

Brain-Brain

Our event at IKEA Helsingborg 3/4 produced a ranked wish-list of topics for the coming events

Best way to start Agile – even when you think you are

Measure how Agile an organisation is

Psychological safety to get good teams

Adopt agile to other organisations

Agile alignment in the organisation

The Agile mind set

We also discussed how Agile can help your organisation to develop. Many of the benefits comes from the increased transparency, such as defining what steps needs to be taken and the possibilities opened up by this; anchoring, flexibility and focusing on the basic 20%. Not as often mentioned, but central, is that failure is ok, expected and quickly identified.

Next event will be at Studio, Malmö in the beginning of June. As promised, this will be about the top ranking subject: Best way to start Agile!

Meet our new agile mentor - Christian

Christian is the network’s first community supporter and he is passionate about Agile and Lean working methods. So passionate, that he is offering you his time to mentor you in your quest to become more Agile. 

In January 2017 I reached out to my network to offer my services as a mentor. Given how much fun I think it is to mentor people I feel it’s time to do this again.

I have been working actively with Agile for over seven years. During this time, I have set up and managed several Agile teams that have run different flavors of processes influenced by Scrum and SAFe. Because we have sometimes moved faster than the rest of the company I have also handled situations where we are running with Agile while people around the team are expecting something else.

Since I’m a strong believer in Agile principles I would like to offer you as a member of The Agile Network to tap in to my knowledge by signing up to become my mentee. I can act as a mentor on topics related to implementing or running Agile from different aspects such as line manager, product manager, project manager and scrum master. The only requirement I have on you is that you are actively going to use whatever we discuss.

I will run this in my spare time, i.e. weekends and weekday evenings Europe time. We can meet in person, through Skype etc. There is no cost involved.

If there is a large interest I will decide which mentor relationship I will take on.

About the Community

The Agile Network Community is a space for you and your peers to share ideas and thoughts in a blogish way. Do you want to write and share? Let us know below! 

Do it like this 

Write: Your name, Company/position/title, Subject of the article/video. Title of your post, Your actual post, Contact information (if you like) and send it to the mail link below. 

info@theagilenetwork.se

or just call us 😁 click here

Digital meeting workshop

We are passionate about Agile and Lean and meeting you to discuss how to continue developing these ideas and techniques! Yes, we live in a stressful world, where time to learn and develop isn’t always prioritised. Therefore we are creating quick video workshops that will help you to fit this learning into your daily schedules. 

More about this in shortly.

Stäng meny

Den här hemsidan använder cookies. Genom att fortsätta använda sidan godkänner du vår användning av cookies.