The ultimate agile team constellation

I often got the question “What’s the perfect team?” and the answer is as always “it depends”. The reaction is usually the same; some angry looking eyes. :-), I wonder why?

I can’t answer the question “What’s the perfect team?” but I can give you some tools and ideas in the process of creating a great team. But then it’s up to you to do all the necessary work.

First you need to destroy the fixed mindset of the ideas with roles, process and tools and try to see people in your organization as different talents that you have in your portfolio to succeed with your main — vision and goal. If you can’t let go of your fixed mindset then I can’t really help you. I guess you are reading this blogpost just because you have tried many times creating teams with this not so agile mindset and it did not go as you expected, right? So get rid of tit for a while and we can continue.

Don’t see people as front-end, back-end, designers and testers etc. The layers and the silos creates trust issues, creates bad WIP (work in progress) limits, creates a complex team before a simple productive team. It’s harder to replace layers, and people with a special role if she/he get sick and so on. If your main tool to handle team maturity is reports, forecasting then you are in trouble. Those things is an early indication of ineffectiveness in your organization.

As one of the Agile manifestos point out:

“Individuals and interactions over processes and tools.”

This is why I want you to erase the idea of roles. You can add roles later on if you want to but for now you have no clue why you need one therefore there is no roles ok? Good 🙂 . All you need to know is that you need talents to succeed not roles. You need individuals that can interact with each other not build walls with layers and silos ok? Cool, lets go on.

“Each team should be full-stack and responsible for taking a component from idea right through to production. Don’t divide by layer (frontend/backend/data) nor by activity (analysis/development/testing). Both layer and activity boundaries have rich communications across them. Remember the central importance of Conway’s Law.”
– Martin Fowler

Next step is to understand how your employees and your self are as person and how to motivate the uniqueness within each of you, to do so you need to understand what motivates us. Dan Pink have a wonderful RSA Animation and presentation about this. I suggest you take a look at it before reading further because it will help a lot. https://www.youtube.com/watch?v=u6XAPnuFjJc

“People can have two different mindsets, he says. Those with a “fixed mindset” believe that their talents and abilities are carved in stone. Those with a “growth mindset” believe that their talents and abilities can be developed. Fixed mindsets see every encounter as a test of their worthiness. Growth mindsets see the same encounters as opportunities to improve.”
― Daniel H. Pink

To understand what motives each person in your organization you need to understand them better. Get in touch with their intrinsic feelings. There are many tools for this. One of the easiest tools is using the same ide as with personas and add some gamification in work. Instead of just identify personas for the project you shall work on do it with your organization. Let each individual create their own personas profile with the same main principle and hang in on the wall so everyone can see it and get more knowledge of each other. What’s their motto, what interests do they have? What’s character traits does each individual have? Skills and talents? It’s very important to understand your team mates, because you shall work with them. 🙂 In agile you take command to lead together with your team mates to do so you need to understand how they are, there positive sides, negative sides so you can easily together help each other feel well and get respect for whom you are. The same way you create respect for your family and children of your (if you have any.). Because the domain is called work it doesn’t mean that it shall not have the same principles needed as with the domain family. There are many more tools for this in Agile and Lean Team Startups. But let’s talk about that in another blogpost.

Untitled-1

As soon you know more about the person, who she/he is its time to go to next level. In the real world you always have your employees for loan. You don’t own them; they are there for you if you don’t motivate them they will leave for someone else that does. People will come and go, therefore it’s important to understand that we need to be open for beginners within our organization and a proactive plan to make them step up towards the expert step.  I don’t like the idea to rank a person as a whole. Like businesspeople do with titles as Junior and Senior. What does that say? What’s in the gray zone between this junior and the senior? And when does a junior become a senior? When he/she knows more than the boss or have worked for ten years?  If you think you can work with the same thing you did in one year repeated nine times and then think you have ten years of expertise, you are wrong. Sure you have worked ten years but you are for sure only an expert repeating the same thing over and over again. So as with the roles get out of the box and get rid of the ideas regarding junior and seniors. Business peoples just created them so they can put different prices on their head nothing more.

“…Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done…” – 5th principle behind agile manifesto!

What I found very useful is the Dreyfus model. Dreyfus model does not rank you as a whole it just ranks you for each individual skill and talents of yours. For example, you might be very good in golf and maybe an expert in golf. But for the talent painting you might be novice. You can draw some lines but you are not very good at it.

Dreyfus models have different states in each individual skill of yours. Dreyfus have five states each of them different mindset based of knowledge, experience and skills.

1. Novice – Need rules and clear guidelines.
2. Advanced beginner – Need less rules , uses guidelines, but without holistic understanding
3. Competent – Develops conceptual models, sees actions in long and short terms
4. Proficient – Sees situations holistically, will self-correct based on previous performanc
5. Expert – No longer relies on rules, guidelines, or maxims, works primarily from intuition

dreyfus-model-of-skill-acquisition

Do you want to know more?
Read more:  
http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2887319/
or
https://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition

As soon you have the tools and knowledge about your organization and people’s talents it’s time to create the team.

The best principles for combine talents is like creating software, don’t decide architecture, techniques, platform before you understand the project. So DON’T create a team before you understand the vison, goal and type of software. Is it desktop system? Does it need many integration specialists? Is it a Webb tool? Is it e-commerce? is it a highly transactional system? Does the customer use any own system we need knowledge about? Like Navision? CMS and CRM of any kind? Is responsive design a requirement? This is typical questions in a startup and as soon you know this you can create your fabulous team. Try to pick people as full stack as possible or at least people that can work cross many functions. Like the image below. (The color indicate a unique talented individual, not a role. The columns just indicate required skills needed for the project, they are not roles just requirements for the project. It needs design, it needs a front-end and so on…)

4
The above image describes this.
Blue person has skills in design, front-end development (sass, less, html, javascript) and understand testing. The orange person has some knowledge of design maybe a novice in design but can help with design if needed, the person also has skills in back-end coding and testing. The green person has little talents in front-end and more skill at back-end and testing. Can be a great mentor for the team regarding TDD, system testing, regression testing and so on, And the yellow one is more like a full stack person that can help in all areas if needed.

Tips: It’s not good to put only experts in one team, novice in another. Spread them out if you need to increase the skills overall in your organization. The best suited person to help another to go from one step to the other is the person that just left that step.
So if you need someone to understand angular for some front-end work it’s easier to add an advanced beginner to the team if you also got a novice talented angular to the team, instead of just add experts in that area. The advanced beginner can more likely explain the problem better for the novice person over an expert talented person. Because they mostly talk the same language.

As soon you have your team-setup you can start asking your team what necessary service functions they need. Service functions can be cross-functional mentors, it can be a product owner if the team think they need one, it can be an agile coach, a team leader or scrum master if they feel they need that kind of service. This is a big change from the old traditional organization design. In this case the team create the process. It’s not strange at all even if it feels little odd, the team are the people that shall make it possible so the only correct thing is letting the team get what they need to succeed.

Remember that a development team in agile is not just developers. People in the whole process of creating a project are the development team even the service function competences is part of the team.

Remember, a named method is not a silver bullet so you need to be open minded. You can simple collect information by checking what correlations and interaction you got between the customer and teams. Maybe you need a waterfall approach, agile-waterfall, scrum, scrumban, lean, XP or your own setup of tools and processes. Maybe you just need to use Kanban and no project owner and such because the team are the domain experts together. Why add extra waste when there might be no need for it?

IMG_0515 (1)

It is important to not fall back in old ideas like the project manager where he/she is supposed to handle everything. Then you are back at the main problem again and you have just wasted your time reading this blogpost. 😀

“We can’t be afraid of change. You may feel very secure in the pond that you are in, but if you never venture out of it, you will never know that there is such a thing as an ocean, a sea. Holding onto something that is good for you now, may be the very reason why you don’t have something better.”
― C. JoyBell C.

Who is Johan Normén?
Johan Normén is 37 years old, work as a speaker, mentor, team leader, agile coach, and senior .net developer at Softhouse in Gothenburg Sweden. He has over 18 years business experienced and worked in many different projects and roles. Was one of the creators of Swenug (Sweden .Net User Group) with over 3000 members all over the country. He started the computer era as game designer at the age of 12 with his Amiga and team. He has been nominated as the top 10 developers in Sweden in the Swedish version of Computer Sweden 2015

Twitter: @johannormen

The top 3 most important skills for being a great team-working agile developer

1. The Skill of Collaboration
Why agile work with teams in agile frameworks is because of two factors. Cooperation skills and collaboration skills. Cooperation is the part when you work as a whole with the customer, product owner (if scrum), agile coach (scrum maser if scrum) , organisation and the team. Cooperation skill is one of the most important requirements for continues delivery and success. Without it you are lost. On top of cooperation you got collaboration. Collaboration is the part where there is room for innovations. When you as a team brainstorm, discuss how to go forward together, innovate new features or maybe effective ways to solve hard problems. Collaboration is working with others to do a task and to achieve shared goals. Agile works because cooperation and collaboration is a must. In other methods like waterfall this is often split into all the different phases and different roles that poorly talk to each other. Every phase do its own work and deliver it to the persons in the next phase. It’s not effective at all and cooperation and collaboration will get lost.

You also need to welcome changes of the requirements. Waterfall mostly don’t. And we know that customers never know what they really want in detail so we really need to have a model that welcome changes. To welcome changes we need to cooperate and collaborate as a whole team. Use Collaborative Design if needed, use Agile UX, Lean UX or whatever you need for the user experience model. The UX people must talk to the designers and the developers to understand if the idea is too expensive or even possible to do. Testers might also have inputs regarding the UX. The developers might have learned some new technical frameworks that make the UX even better. Technical information that UX people often do not know about if no one present it to them. And it’s also important for the developers to understand the UX ideas. It’s also important for you as a developer to be curios and ask why to understand. Never assume anything (we will come to that later.) It’s also important as a team to be able to explain the goal to each other so we are all on the same page all the time in the whole process.

To get the most out of collaboration shared workspaces is important. The more distance to each other the harder it will become to collaborate with less misunderstanding. So as a team it’s important to have the possibility to talk to each other, and understand that talking with each other is a must. Your mission is to help each other despite your role. If you are not willing to spare time for a discussion you will probably harm yourself in the long run. The team as a whole will probably get problems. The team’s problems is also your problem. You are not alone in an effective team. The best tool for collaboration is people standing with a whiteboard. Different people understand information in different ways. To draw, talk, use metaphors mostly is enough for the teammates to understand the issues. If you are unsure if the persons you talk to understand what you just told them, let them explain for the team the same thing you just did to see so everyone is on the same page. Second best collaboration tools is video or skype calls, the worst media for collaboration is chat-programs and e-mail conversations [Cockburn – Agile software development].  So as a team try to demand for an open space where you can draw, talk without disturbing other teams any time you need to. If that’s not possible the collaboration part can be tricky and not as effective as needed. As a team member it’s important to understand that communication and meetings are not bad things. Meetings are held to solve problems and conflicts, communication in general to understand the goal and help each other reach this goal. Work close to each other so you can ask a question, let others review your work and you others and so on. Be open to share your ideas and thoughts and listen to others, work with the same principles and guidelines.

If you put people in different rooms they will surly produce something but without collaboration it will probably be something no one wants. The assumptions will increase and the blame as well. To blame people in your team indicates bad collaboration and only destroys it. So it’s important to handle conflicts in the collaboration part as well. Conflicts will be there when working so tight to each other, it’s unavoidable. So don’t be afraid of conflicts. But handle them as soon they arise.

Story:
I was one of the developers in a project for a big company that own buildings. The company I worked for was very fond of roles. UX, Designers, information Architects, Developers, Testers. All grouped together in different rooms based on their roles. Testers in one room, Designers in one etc. Every role had x-total time to deliver their part. The UX person got 100 hours. After 100 hours the UX person went to another project and the Designer gets the material and had 200 hours to add look and feel of the wireframes. The designer only got 70% of the work needed from the UX person. Because the UX person was assigned to other projects as soon the time was out the designer was forced to do the best he could. When the designer’s time was up the UX material and design sketches was delivered to the developers. The designer only managed to give the developers design for 55% of the projects main requirements. The UX never talked to the designer and the developers, the designer never talk to the UX person or the developers. When the developers needed to understand all the missing parts the project manager gave us this answer: “The UX and Designer are now in other projects” when we told the project manager that this is an issue, he just told us to assume what to do. We are the experts, how hard can it be? I think you can figure out the rest…

You are the expert [You tube]

2. The skill to gain respect/trust
Respect is a powerful skill, but also a really hard one. Respect others and you will also be respected. We all have different skills and talents, if we respect that we also get stronger together as a team. A respected team will get better relationships with the customers and the organization. Try to understand the strength and weakness within your teammates. Don’t blame a weakness, it’s your responsibility with the team to compliment them. Get rid of “me” and increase the “we”. We are doing this together, we support each other to solve the problems together, we can do it, we will do it… It’s not one person’s code that’s failing it’s ours (even if it’s a certain person who wrote it). If something is broken, fix it. If you blame the creator it will only split the team with conflicts and trust issues. One day you will be the one that break something and find gratitude if someone help you fix it.

Show gratitude to each other, compliment the achievements of each other. Even small parts count. If you say you will fix something, do it. Don’t commit to something you can’t handle. Offer assistance if someone got a problem and respect each other abilities. A highly respected team will get less conflicts and will cooperate and collaborate better to meet the same goal. By trust you get respect. Trust and respect are both two ways communication. You must trust others and respect others to gain both. Some organizations think that developers are the solution to everything and forget that the organization as a whole is. With bad leaders you get bad teams. It’s important to let teams coach leaders and leaders to coach teams. In agile frameworks like scrum you have retrospectives as a golden opportunity to bring this up if it’s a problem. If you got many conflicts in your team, then you know that you have trust issues. Bring them up early before they end up in resentments.

Be open minded, let go of control and make you vulnerable. It’s important to make mistake and it’s also important to be able to. Making mistake is not a weakness it’s you motivation for establish strength and knowledge. See things from other perspectives is a skill. That’s why you also must let go of fear and control and make yourself vulnerable. Let others know when you did a mistake rather than activate defensive mode. Take a moment and reflect how you act in front of others that just made a mistake. You don’t blame them, right? You often give them your hand and help them do better, right? We are all the same, other people have the same feelings, don’t judge yours. Be transparent with your team. The same goes with collaboration with customers. Be transparent, try to see their side before you criticize them. If there is some kind of conflicts with the costumer it’s mostly because you don’t see the vision and goal the same way. Open up your mind for new ideas and give yourself the opportunity to change how you think and how you view the world. Doing so increases the options to enter new ways to solve problems and increases your confidence with others and you will gain more respect and trust too.
Coach your teammates, let them know that mistakes are not bad, give them positive feedback, don’t blame them for their mistakes. And most of all listen to what they have to say.
That doesn’t say you cannot have strong opinions, but you need weakly held.

Story:
The first time I was a full time Team Leader I did the biggest mistake ever. I thought I could handle everything. The requirements with the customer and the team, the architecture of the system, the design of the system and to lead the team. I got trust issues, the respect was very low, the collaboration was bad, and everything was bad. I could not understand why. I was there supporting the team with every little question that was delivered to me. I told them what to do all the time. I worked overtime for my team and all I got was angry comments, no respect at all. When I told something they ignored me and went to someone else. Later on I found out that my good will was just bad. I wanted so badly to help my team to succeed so I took all the responsibilities from everyone. That’s a nightmare for a team. You can never create a self-going teams if you take all the responsibilities. It’s important to hand it over to the team, let them solve the problems together. I took all the trust from them not letting them decide by them self. I was not open minded, I never saw the forest for the trees. This is also important for the team members, don’t take too much responsibilities let other have some. Even if you are or think you are better than them. It’s so easy to be the one taking most of the responsibilities, the one the team must ask if they want to go forward. In the end you are the one your teammates will blame if anything is broken. Let all take responsibility and let them learn from each other’s and their own mistakes, just be the mentor and the mentee.

3. The skill to challenge Assumptions
Assumptions are our worst enemy. It often give us bad business. We often make assumptions when we don’t fully understand a situation or a need. The reaction is natural for making up our own story by filling in any missing information. We do this because we try to make sense of uncertain requirements or customers need. The problem with this is that most of the time our story is incorrect and most often causes all kinds of complications. Assumptions is like the red devil on our shoulder while the good angle is on the other side and try to tell us something but we won’t listen. We are afraid of showing weakness and think we do well by our assumptions. Bad assumptions just don’t give you bad decisions or features it infect the whole team.

Challenge assumptions by getting more information about something if you are not certain. In some mysterious way questions seems to be a weakness but it’s not. To not ask is. So when you don’t know it’s a clear sign you need to get all the facts. Coach your teammates to be open with questions. Don’t blame or reject questions, they are often you and your teammates guide to success.

There is no stupid questions only stupid answers. The fact is, we don’t know what the truth is unless we ask. If you find a bad requirement go ask for more details. In agile frameworks like scrum you got the product owner as your service to help you understand the requirements. Never blame the product owner for bad requirements, the product owner also need help to get the best out of the team.

You also need to be curious to challenge assumptions. If someone talk about things you don’t know anything about, just ask or go and google it for a while, you will be amazed what you will find out. Don’t stop with “I don’t know”. If you can’t find any answers at all, remember it’s no weakness to ask for help on forums or in other teams. Ask for help is strength. It also increase respect and awareness. With high curiosity you will also grow up and continue to learn and practice new topics. Knowledge is your tools for success.

Let your teammates know that words like “how? Why? etc. are the words of curiosity and also very important to understand to move forward as a team. If you feel that someone in your team are not curios at all and always want you to fix the problems for them, try to motivate them by ask them questions back rather than just give them an answer.

Story:
Some years ago I took over a project after a team leader who quit his job for another one. The project was one month late. I asked the team how long they had come. The answer was that 70% was done. When I asked the customer if they were satisfied so far. I got the answer NO. We haven’t seen anything yet. I found it odd and asked the team do demonstrate the system for the customer. What we found out was that it was only 30% done. The rest was just assumptions by the team. I asked how this was possible. The team told me the team leader and product owner was too busy in more important projects so they were never around. When I asked the customer they told me they wanted continues deliveries and continuous feedback loops but got none so they thought we know what we were doing because of the silence. I think you can imagine how that project ended. I bet most of you have been in this kind of situation before.

Summary:
Delete the “Me and you” and add the “We”. Never assume anything and ask when uncertain and give feedbacks and be open minded for all kinds of collaboration, even if it’s about solving a conflict within the team, with the customer or just find out how to solve a problem.
Who is Johan Normén?
Johan Normén is 37 years old, work as a speaker,mentor, team leader, agile coach, and senior .net developer at Softhouse in Gothenburg Sweden.
He has over 18 years business experienced and worked in many different projects and roles. Was one of the creators of Swenug (Sweden .Net User Group) with over 3000 members all over the country. He started the computer era as game designer at the age of 12 with his Amiga and team. Has been nominated two time as the top 100 developers in Sweden in the Swedish version of Computer Sweden.

@johannormen

Special thanks to Linus Norén for the review of this post.

#NoEstimate, successful projects in an agile world. Part 1.

It is known and has been documented that up-front work rarely delivers more than unnecessary time spent in our IT projects. CHAOS Report 2005 showed that this traditional approach was not viable. Approximately 16% of all projects were delivered on time 2005. Over 80% was delivered after budget and time, and the rest was more or less failed projects. Only 9% of the 16% successful projects had been supplied with all the requirements customer wanted. 78% of those 16% had about 74% of the customer’s requirements and expectations.

And the size of the companies did also matter, small and big delivered different results in losses on budget. The large companies went over with a budget of about 180% while smaller companies went over by more than 220% in several projects.

That means there is a 75% chance that a project of 1000 hours will cost a small business about 2200 hours for all the requirements.
Source: http://www.projectsmart.co.uk/docs/chaos-report.pdf

The numbers were changed in the CHAOS report 2013 when agile methods have reached their success by 2005. Approximately 39% of the projects was delivered in time and budget with a 100% agile methodologies such as Scrum, Lean, XP…

Why does so many project fails?
The answers are many, it is everything from how we manage projects, knowledge in organisations, how we manage our customers and attacking redundant work.

A big mistake is that we are so fixated with time. We use time to estimate the costs. This approach automatically more or less means that you agree to an up-front process that’s likely limit the customer the opportunity to request changes and you for welcoming them.  Customer thinks that estimate is almost a contract when we are done. This approach is often called Budget-Driven Estimation or Promise-Driven Estimation. And the real problem here is that customers know that estimate is just a “guess”. But they always refer to it as a promised timeframe. So in the community people want to change this word to something else though estimate is almost always converted as a promise. It would be much better to call it. “We guess it will take 1000h!” instead of telling the customer “the estimate is 1000h.” You get the point right?

And remember that estimate does not actually tell the story about the delivery time frames. The actual delivery time depends on current priorities, WIP and lead-time. But! When a customer asks “how long?” and we answer “eight weeks”, or “1200h” they think the clock has started, and expect to see results after 8 weeks or exactly 1200 hours. But the reality may be that the team will not begin work on the basis of existing PIA and priorities.

Another reason is when leaders see the team members as a developer that you can move around or replace whenever you want. We believe that a developer is equal another developer in skill and knowledge.
Two brothers created in 1980 an idea that people are not equals because they have the same title. They identified that people attack problems differently based on their experience and knowledge. And therefore created the Dreyfus model.
To rank where people exist in all there unique skills.
Source: http://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition

It is also common to add people to an ongoing project and believe it will create greater efficiency when it’s usually do the opposite. Each new person has to be trained in collaboration, customer requirements, knowledge of the customer, etc. and it usually takes focus from an already productive team. “Nine women can’t make a baby in one month.” It’s called The Brook’s law.
Source: http://en.wikipedia.org/wiki/Brooks%27s_law

To prevent much of this we can focus out processes on the agile manifesto.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

It is important to keep an open dialogue with the customer to ensure that risks are lifted up early on the surface as soon as we learn about them.
Then there is also plenty of time to reduce them. Clients / stakeholders do not like surprises as for the development team!

An estimate should never be treated as a commitment or a promise. It’s not a contract. Therefore, avoid negotiating with time to calculate the budget. Instead focus on the value for the customers and charge for them instead. Be value-oriented not time-oriented. (Part 4 in this series will show some ideas how you can get paid and sell your projects value-oriented.)

So when estimate seams so bad, do we need them? Yes and no.
You can read more about it and #NoEstimate in my Part 2. (will be published soon.)