I team uppstår olika dysfunktioner när teammedlemmarna inte ges chans att lära känna varandra, eftersom man då inte heller visar sig sårbar. Det i sin tur leder till konflikträdsla som skapar en konstgjord harmoni. Eftersom konflikträdslan hämmar viktiga debatter så skapar det reservationer hos teammedlemmarna som då leder till ansvarsflykt. Människor engagerar sig inte i det som ska göras om de inte förstår varför. Oförmågan att avkräva ansvar leder till resultatblindhet. Därför är det viktigt att hantera dessa dysfunktionerna i team så att teamen faktiskt kan nå bra resultat och trivas på sina arbetsplatser.
This is a translation of a prior post in Swedish. Se originalinlägget på svenska här >
This post is about the most common way of working for an agile team, namely the Scrum framework. Scrum is a minimal, lightweight framework that gives good support for both new teams and more experienced teams, as well as for organisations with many teams, under the name Scrum at Scale. In this post I show the basics of Scrum, but if you are interested to know more and get the latest correct updates, I recommend the official Scrum Guide >
Scrum is based on empiricism and lean thinking. It provides good support to deliver solutions to complex problems where we cannot predict whether the solution will produce the effect we want. It has become by far the most popular Agile way of working over the past 20 years.
The team can work within software development, product development, or as managers in any sort of organisation. Even functions like HR can benefit greatly from this way of working, or why not healthcare or construction projects? Anyone who works with complex problems where they cannot predict if the solution will achieve the desired result, and cannot plan more than one week in advance, will benefit from working this way of working.
The 5 Scrum values give the team the conditions needed to build a high performing team. If these values are not lived by the team, they will not be able to build and maintain an Agile approach either. Process alone will not bring a team all the way to agility.
Focus All in the Agile team focus on the work in the sprint or the goal for the team.
Courage Agile team members have the courage to do the right thing and work to solve tough problems.
Openness The Agile team and its stakeholders agree to be transparent with all work and challenges that come with doing it.
Commitment Individuals in the Agile team personally commit to achieve their shared goal as a team.
Respect The members in the Agile team respect each other and have trust that all are capable, independent people.
Agile way of working for teams
The process is simple and has few elements and rules, as well as only 3 roles; Product Owner, Scrum Master and Team Member. Regardless of what the team is working on, these roles are used, but depending on what the team’s mission is, the team members have different competencies (more on that below).
Product Owner Responsible for optimising value that the team and organisation deliver. Owns the product backlog, product vision, and has the mandate to make business decisions. NOT a project manager.
Scrum Master A coaching leader for the team and PO. Responsible for facilitating work processes and optimising flow in the team. Helps the team to improve and build a mature and strong team. NOT managing anyone.
Team Members A self-organising team is responsible for “the what” – i.e. the solution. The team works together with the PO to understand the business and customer value and is responsible for how the solution will work to solve the prioritised problem. NOT with individual goals and priorities.
“-With my style of clothing and your company name, we would be a match made in heaven.” That is a paraphrase of my first comment on The Dandy People Instagram, sometime in 2019.
The Dandy Intro Package arrived a few days ago. Some fun and interesting books to start the journey right. And stickers of course.
And that’s how my journey began really, because after that I just started reading up on them on their webpage, finding what I thought, a company that encapsulated everything I had thought about and looked for without even knowing it. I barely knew what Agile was back then but when I found out about the Agile Mindset everything fell into place. I instantly felt at home in the Agile world because I already had the Mindset without even knowing there was a name for it.
So, I signed up for everything Dandy People; their webinars, going over their awesome “-In a Nutshell” posters, and some of their courses. And read A LOT of books!
Then I had my first zoom-call with Mia Kolmodin and the week after that, Corona hit – and everything closed down. So we had put it on hold.
This is the fifth post in the November Agile Leadership and Management Series.
So, now the time has come to look into a number of setups and activities that you can use to help get your Agile Leadership Team up and running and, continuously use for effectiveness and smoothness in their daily work.
Agility is about adapting and delivering value. More and more organisations are discovering that they either need to get on the agile train or fall hopelessly behind.
Many of them turn to frameworks to adapt agile ways of working. But what they get is another framework that will sit on top of the others and cause more confusion and frustration. What they need is to focus on the real problems like organisation, leadership and culture. I’m going to use SAFe as an example in this text (there are other frameworks trying to solve this out there but I know more about SAFe).
A framework with a clear hierarchical role chart, process arrows, planning cycles and new roles is a way of satisfying the controlling part of an organisation. And it is exactly this part that we need to remove, if we want to be truly agile. To dare go down the agile road you need trust from leaders and in many organisations that is the exact thing they are lacking. So their own fear of losing control drives them to turn to things their recognize, roles and hierarchy, processes and planning, things that are feeding the controlling needs and is satisfying their own fears.
When introducing a framework like SAFe you are forced to focus on roles and planning cycles instead of culture, organisation and leadership. To get the right people in these roles is not an easy task an one that is impossible if there are no people with an agile mindset in the organisation. When people without agile mindset take on these roles what we get is another gant chart and detailed planning that will not adapt to the changing needs of the customer.
There is a an increasing trend in big companies and organizations to go Agile, and of course that is awesome in my opinion. What is really confusing though, is that many of the same companies and organizations also decide to change to activity based seating. This is really confusing in many ways, since it will bring contradictory behaviors than what you are looking for when working Agile, and in the short – and long run, make the company fail to go agile.
The only conclusion I can do, is that there is not enough knowledge around how Agile seatings need to be – nor what the consequences of not being Agile when trying will be (costly and frustrating). Or perhaps it’s that the people that do the work (and know about this) and the people making these decisions are too far away from each other and don’t communicate in a good way. Either way, it’s a huge waste – and so unnecessary.
I have several times been contacted by people working in organizations where they have had Agile teams sitting and working together with good results – and out of the blue, usually over a weekend or over a holiday, their office space was changed in to activity based seating with clean desk – and clean wall policy. The team shows up on a Monday finding all their stuff that was put up on the walls in a cardboard box and their 2-3 computer screens gone… These people tell tales about how their colleagues went home after that day, refused to come back in weeks. Their delivery pace went down with below 50% of normal and quality of work and innovation went down the drain totally. Everything the team had fought for to build up was erased over night.
Flexibility in Agile and Activity based offices must be a perfect fit – or does it?
Organizations that decide to go with activity based offices probably have the best of intentions. I’m sure of that, people usually do. But I’m also sure they need better advisory. It might look as if the flexibility in both agile and activity based office works really well together (and this is an argument I’ve heard sales people for these solution use). And it might look like you will save a lot of money, not having as many seatings as before, and it might look like people will get to know each other a lot better when they move around every day, and you might think they will love their new updated beautiful workplace with special designed chairs for people who like to sit alone not seeing or being seen by any one else. But it´s all wrong – so wrong – at least if you want collaboration, innovation and high speed in your organization and culture. Flexibility is not always what you need after all. (more…)
Many of our decisions, conclusions and actions in a team come about after a good meeting. But what is a ‘good meeting’? How do we make them productive, informative and how do we engage all invited in order to close it with the expected results. Meetings do come in many different shapes and forms, quick stand-ups, day or two long workshops, planning, retrospective the list goes on.
How do you engage people in effective collaboration? Should you entertain them? When you walk in loaded with your beautiful agenda, prepared meticulously ahead of the meeting, to find yourself demotivated by yawns of few attendees. And you, dear meeting goer, ever find yourself spending meetings daydreaming? Not feeling like your voice is heard? Already planning not to show up on the follow up meeting? Daydreaming? Sleeping? (more…)
The online version that you can run in Google Drive via Google Slide.
The speedboat format for retrospectives is something I like a lot and have used with teams or even whole organizations (divided into teams). I find it to be a good way for the team to think individually, and then collaborate and define solutions for their problems through visualization. Visualization helps the team to more easily figure out what problems they should solve them selves, and what problems needs to be solved through collaboration between the teams, and what they need to ask management to help with. Some Agile coaches or Scrum Masters only highlight the negative on retrospectives, I believe it is a great thing to focus on the positive and also help the team take action more easily on real issues. It´s the teams responsibility to handle issues within the team, the Agile Coach/Scrum Masters job is to give them the capabilities to do that (not to do it for them).
This is a dialogue board, created to facilitate good discussions around business strategy and tactics in a startup. At Dandy People we are using it to start up our consulting business, but it can be used by any type of organisation, or part of an organisation that wants to improve their customer focus, culture, leadership and take action as a team.
At Dandy people we like to build our new business in a way that involves and inspires the people in our organization. To facilitate the discussions we wanted to have on our first mini-conference 2 months after starting up our shop, and after hiring 2 new people, I did this Lean Business Strategy & Tactics Dialogue Board. Off course we had already done som strategy and tactics work already before we started our company, but we felt that we wanted to be transparent and bring our new Dandys onboard with the idea of the company to enable them to feel as involved and motivated as possible. And off course, they are smart and experienced people, so why shouldn’t they be able to help us improve and grow? And I can just say that it worked like a charm 😀
Feel free to use the board if you want, also we would be happy to facilitate the workshops with you and your team if you feel a need for that. Thats kinda what we do at Dandy People 😀
Cross functional teams are complete in expertise but not necessarily collaborative. Sometimes team members hold on to their expertise too much and the team does not perform to its potential. This Lego game illuminates the difference when members allow themselves to take on tasks outside their expertise, being so called T-shaped. Play the game to kick-start your change and create collaboration.
Ever since I saw Henrik Knibergs movie “PO in a nutshell” about how the PO role work for the first time I have been thinking about how he could have included the discovery process in the picture too. A while ago I created this as an example of how it could look and work for a X-functional team.
All ideas could be good ideas
The process starts with some kind of idea that could come from any stake holder – even from anyone in the team (this is usually a very rare occasion in most companies). The idea is verified in a concept (see example of a concept in my blog post on discovery framework) by the owner of the idea and the Product Owner decides if it worth starting the discovery process to figure out what it is they are supposed to build – or if it is not, based on the information in the concept. (more…)
Product Discovery defines what should be built – and why. Collaboration Is Key. Your success with agile development depends on delivering the right product requirements at the right time.
During the past few years when I have been working as Lead UX or Product Owner I have come to a core process of how to do the discovery. At my latest gig on Viaplay as Chief Product Owner I had great use of some of these methods and also found it to be a great tool to have it visualised for all Product Owners in a one pager.
Within this process I see lots of different methods that may be used.As I use it I pick different methods in each level depending on organisation, product or project. Sometimes not all steps are neccesary off course. When working methodically for some time you start getting a feel for what seems like a good ide or not.
In this post I’m presenting a framework of the process as well as the methods in short formats. I will try to post more in dept posts on some of the methods going forward. Please let me know what methods you would like to know more about 🙂 Hope you find it useful in your daily work.
Note: Due to some lazyness there are some Swedish material in this article also – sorry for that!
1. Strategy
Why are we doing this? What is the goal & desired impact?
1.1 Concept Concepts enables people passionate about a product idea, regardless of role, to realise it all the way to happy client. Concepts is a one page specification, in A3 format that represents a product idea of feature. It is enough to enable a prepared conversation with engineers developing the product. Think of it as a “flexible minimum specification”. Mattias Skarins blog post on this http://www.crisp.se/concepts
Target Group:Agile coaches, Product Managers, Product Owners, Business developers, Architects and developers, User- and Customer Experience (UX/CX) (User Researcher, Interaction design, Graphic Designers, Art Directors) Anyone involved in the process, and those facilitating it.
There is a an increasing trend in big companies and organizations to go Agile, and of course that is awesome in my opinion. What is really confusing though, is that many of the same companies and organizations also decide to change to activity based seating. This is really confusing in many ways, since it will bring contradictory behaviors than what you are looking for when working Agile, and in the short – and long run, make the company fail to go agile.
