How to color cards in Microsoft TFS Online. Add color to a Lean hypothesis card.

I think most of you have heard of Lean Startups and maybe also UX for Lean Startups. Ok if not I will explain it shortly.

In Lean Startup you use something called hypothesis instead of User Stories if using Kanban or any other tools. The main different with a hypothesis regarding a User Story is mostly the way you describe it and its purpose. A user story template often look like this

As a <type of user>, I want <some goal> so that <some reason>.

User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.

In Lean startups you use hypothesis that is an assumption when user story is not.
Lean Startup strategies are designed to test assumptions about customers and the market target.
While User Stories are the description of a technical solution that we can test in our system then Lean hypothesis is a description of an assumption we need to test on the market, the users.

The template looks something like this:
I believe [target market] will [do this action / use this solution] for [this reason].

You simple add that description on your card (post-it) or digital Kanban board. I often want different colors on my cards to increase the visualization better. Bugs are red cards, things I need to look up maybe blue cards, user story a yellow card and hypothesis maybe green and so on. I want fast feedback what’s going on when I look at a Kanban board that’s why I add more visualization to it so I don’t need to spend too much time understand what’s going on in this sprint or iteration.

In Microsoft TFS Online you can’t change the color of the cards based on card types when this blog-post is written (2015 Oct 9). But you can change colors on the card based on styling rules in TFS Online. The cool thing with styling rule is that you can add criteria based on mostly anything that exist on a card and make it show up in different colors. In this case I use Tags and the contains criteria in this demo to add another color to my hypothesis cards. I will show you how to do this in TFS Online.

First of all open you TFS Online project. Add a card. In this case I added my first hypothesis .

1

Then go to the board settings (The icon in the right corner (1)).
2

Go to the Style option (2) and add a new rule (3).
After that just add your criteria. Remember that you can add many different criteria. In my case I will first add a criteria for a tag. And next add a criteria that check if title contains some words. Like the words “I believe” as the hypothesis template starts with.

3

On the image above I added a rule based on tags. If the tag HYP is added then show green card.
Next image show you how it can look like if the criteria contains text in the title .

3a

If using Tags make sure you add your tag to the card.
4

If you used the “contains” criteria just save the settings. And the card will end up green on the board.

5

That’s it… Happy playing around.

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 two time as the top 100 developers in Sweden in the Swedish version of Computer Sweden.

Twitter: @johannormen

Advertisements

Can we use IoT (Internet of Things) with Lean UX?

Almost 79% of global companies already use IoT technologies to track their customers, products, premises, or supply chains today in different ways. And it does not stop there, many large companies spend more time collecting data and use technologies that will teach them what people might want or not. Some companies even use it to see if they can prevent crimes before they happen, like in the Minority Report movie. So why do I ask the question if we can use IoT with Lean UX?

Lean UX is not new. It has been around for many, many years but never defined as a concept, as with many other things. Lean UX has taken ideas from UCD (User Centered Design) with CD (Collaborative Design) and the iterative process itself to meet the MVP (Minimal Viable Product) goals and measure the result when measurements give the most feedback. In other words, you mostly know if something was great when people ask for it, or you can see if they really use your idea and like it or not. UCD guesses and assumes things while Lean UX goes further to really investigate if it was used and if it needs to be improved in the next iteration and so on.
It’s also very common that you add features in products but rarely delete features that no one uses anymore. The goal of Lean UX is to help you with that as well.

The big difference with UCD and Lean UX is that UCD is mostly common as a tool in up-front processes like waterfall. Lean UX focuses on KISS (Keep It Simple Stupid) with small iterations and collaboration with the whole agile team – not just the UX Designers.

One interesting idea of Lean UX is that it’s a data-driven approach. Instead of thinking Lean design as being driven by data, you can see it as being informed by data. That’s why I think IoT will be a very interesting topic in our UX world.

Consider this: IoT can help you in the future to understand what temperature you want to have in your home based on the hours of the day. The systems will know this by collecting data from you. What temperature do you often set at 3 PM? Did you complain on the internet that it’s too cold in your home? And so on… All this information helps analysis tools with understanding what you probably want so you can spend time on more important things than complaining about the temperature at home. The system will help you get the temperature you want before you even notice it.

We also have problems today with people that turns off advertisements with ad blockers. So you need to find new ways to certify the customer. To do so you need to understand them. To understand them you need to monitor them, collect data about them to help them get what they really want. When Lean UX is data-driven you can simply use the IoT ideas to analyze and find out where the trends point, what people feel uncomfortable with and so on. In the near future systems will almost know what you are thinking and give you what you ask for before you even know it. Scary? I know. But with a bit of luck it will give us time for more important tasks. To analyze what people might want we can use the IoT to create better UX and features before the customers even know about them.

For example, Apple’s Siri already helps you more than you know. Microsoft Cortana and Google’s knowledge of what you often seek for is already a part of this.

Welcome to the future…

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 two time as the top 100 developers in Sweden in the Swedish version of Computer Sweden.

Twitter: @johannormen

Bring gamification into the agile framework

First of all, what is gamification? The word does not sound so serious right? It’s like… Shall you have fun at work? Who said that? I know that we all want to have fun all the time if we had the chance to choose. And we do have, that’s the best part of being human.

In short gamification is a way to add things and psychological ideas to make things more fun. Let start by look at our job situation.

Tasks in our daily work is mostly repetitive but dull. Goals in our daily work can be unclear, information often delivered at the wrong time. Failure is often forbidden, you don’t talk about it to often and you can get punished by your failure. Collaboration is often bad (not always but we tend to think that people who talk to much aren’t productive.), the autonomy is mid or low. The path to mastery is often unclear. How do I master? What way do I need to go to get from good to great or enter next level in my carrier at my work?

Those are very common issues all of them, but there are some few companies where they are not. If you are one of them I will congratulate you and give you the achievement of success… 😀

So what about games? Tasks are repetitive but often fun right? Yatzy is fun, we do the same thing over and over again and still play it. The goal is really clear, the one that get most points is the winner, it’s clear how to play, and what you need to do. The information is delivered on time (just in time). Failure is ok, if you don’t fail you can’t win. You don’t get punished if failing. Collaboration is there, you have fun, talk to each other, maybe even give each other some tips what dice you shall save or not, get better ideas regarding how to play Yatzy better and master it more.

“In every real man a child is hidden that wants to play” – Friedrich Nietzsche

We know all this, we have known this since the day we invented games, but why don’t we take all this knowledge and implement it in our daily work?

The answer is kind of simple, we need to collaborate and understand people in our organisation first to do so. We really need to communicate outside our boundaries of daily work. How many of you colleagues know that you like sport? But in general you love sport because you can help others to master it? How many of your colleagues love to draw, or learn by doing? How many of your colleagues sees the world by how the world sounds like rather then how it looks like? How many of your friends has emotion based on movies rather then politics? When you talk to your friends regarding trees, can it sound like this from different peoples?

I love this wonderful sound in the trees.
I love the green color on the trees.
I love how the leaves feel like in my hand.
I love the feeling to get rid of dead trees.

This is four different personalities. They all get knowledge in different ways, they all have different ways to communicate problems and so on. We often don’t see this because we are so busy in our own lives. If you play a game as a team you need to understand each other to have the possibility to win. And to do this you must learn to listen to each other and coach each other to mastery. This is one of the main ideas of the agile framework scrum. The American Soccer is the main idea of scrum. You must play as a team with each other to win. To do this you have a coach; a person that sees what you don’t see on the filed. The coach is there to help you get your minds and visions together. Makes you play the game together as a team. Some of you are better at running, others better at tackling and so on. You need to know this and put right person on the right job on the field to succeed. You collaborate for success. And therefore you also have a chance to win.

In scrum you have planning poker as a fun game for collaborating against the same goal. You have retrospectives to solve problems and add new smart and better tactics how to deliver high value with highest quality together. (Like the collaboration together how to defeat Gorash Hellscream in World of Warcraft). In Lean you collaborate all the time and use Kanban board (can be used in scum and other methods too) to indicate threat and visual goals and so on. Some people add a little island on the Kanban-board and put the avatar there if they are on vacation to add some fun to it. In one project we used Star Wars characters though the whole team had Star Wars in common. It was fun. I move Han Solo to next lane. 🙂

Many coachers use games in the start-up meeting as the “learn to know each other socially”-process. Who are you in real life and so on. It’s easy to add this “worker role”-role in you at your work and forget the real life-role. You are often another kind of person out side your job. It’s important to get knowledge about that person as well.  If not you become a hidden status user. Who are you to blame me? You don’t even know me.

In gamification we have four main player types and they all act different at work and in life.
You got the Killer. This one is the person that needs a winner and a looser. If there is no looser you haven’t win anything. We got the achievers, they are like the killers but the main different is that achievers don’t care if some one loses, the achievers just want to be better and need everyone to help him/her. We have the socialiser, the people that love to be around other peoples. Did you know that 80% of the persons on this planet are the socialisers? Did you even know that if you put a person in prison you rather be with the other insane criminals than alone in a room, even if we know it’s dangerous? The last player type is the explorer. The explorer is a person that love to see new things, how it looks like, the roadmap, the path even explore how it went.

If you think of the persons in your team, can you group them by those four games types? I bet you can, think about it for a while. Hey… I told you to think about it so stop reading for some minutes, just reflect on your teammates and see what kind of persons they really are.

1,2,3,4,5 Minutes later.

Hi, and welcome back. Was it hard? Was it easy? I bet you grouped most of them by now, and I also bet that suddenly you start to get another view of them, other feelings now then before right? A more positive feeling right? Kind of the same you get when you play games with your friends? (if not then you are probably in the wrong team, with people that can’t certify your type creatively.) :/

As a agile coach you can take this knowledge and add more items to your methodology framework to make the work more fun. Add a score board for the killers and achievers. Make the socialiser collaborates ideas around this score board. Let the explorer, explore the result. Add a team vision and goal charts on the wall to make the goal more clear. What’s the most important values for the team to succeed? If the team loose focus go to this team goal chart and refresh the main goal and why the values are so important for you as a team. Make the collaboration a rule rather than a punishment of some kind of time-consuming issue. Because it’s not. Maybe all persons in the team love music and work better with music on? What if they all love the “focus playlist” on Spotify? Why not add a speaker in the room and play it in the background for them? I bet you have more fun playing games or party with friends with music in the background right? We love music. Think of a gym with no music… will you perform better?

At the start up meeting let everyone create their own personas profile. Hang it on the wall with nicknames and an avatar. In this personas profile add interests, movies, music styles etc.

Screen Shot 2015-10-05 at 15.04.20
(Image: this is from my Keynote I did with the same topic 2015 at SweTugg conference).

When working with customers you probably identify the personas to make better result for the customer, why not use the same ideas to make better result as a team? It’s no difference just that you suddenly get some focus. Focus that generate flourish (positive psychology).
https://en.wikipedia.org/wiki/Persona_(user_experience)

When a new team member enter the team, show him/her this wall, describe the teams goal and values and add this new person personas to the team-wall so others can see it.  (Maybe he is the main healer you always wanted? 😉 ) If you feel that you are in a conflict with someone, just go to the wall look at the personas profile and think why you see things different, enter the personas personality to reflect and act different regarding the conflict. It’s fun, maybe it will scare you, but games that add some drama and scary moments are more fun than games you will win all the time without any resistance.

Use user stories or something that the whole team feels gives them the best information regarding what to do with each task. Add story points and use that for the score board to reach high scores together if most of the people are killer and or achievers. And so on, be creative. To work shall be fun and successful.

Gamification is 75% psychology and 25% technology…

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 two time as the top 100 developers in Sweden in the Swedish version of Computer Sweden.

Twitter: @johannormen

Definition of done (DOD) in TFS online

Definition of done have been around for a while now. It’s a part of the scrum framework and also used in other contexts. The purpose of the definition of done list is to have a checklist that team together must follow before they can say they are done. The list is often unique and shall be created by the team in the startup process.
Some common topic if using TDD (Test driven development) can be
– Test must have been written
– Test most pass
– Code has been reviewed etc.

The list can be split into many lists if used for different phases in a Kanban board. In this post I will show you how easy it is to add a DOD list mark for alla the columns that you as a team think needs a DOD list before you can move the user story (card) to next column.

First login to your TFS Online account and your project. After that just go to the board settings.

1

In the settings area, go to the columns and select the column you want your Defition of Done checklist for and just add what you as a team think must be made before the user story (card) can be moved to next column.
2

As soon you are done and enter the board you will see this little mark

3

In this case I just added some text on the Active Columns Definition of done textbox.
Move your mouse over and a box will appear with the text.
4

Easy and very nice and helpful little feature in TFS Online.
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.

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 2.

The big difference between agile methods and other methods is that you focus more on value and results before time and deadline. The word focus does not mean that time is an unnecessary factor, it is but agile is more about using it effectively in an agile manner.

Many of us that are really passionate about the agile methodology, have actually succeeded with good results in our projects. And our customers have been extremely satisfied and in return we got good relations.

Our highest priority as agile coachers and team is to satisfy the customer through early and continuous delivery of valuable software.
We welcome changing requirements, even late in the development phase. The agile process yields change to the customer’s competitiveness and give us as team leaders or developer the creativity to do good.
We want to deliver working software usually with the timeframe of few week sprints or within few months. Together with the team we want to create good design and code to get out as much of the customer’s requirements as possible, based on requirements with the highest ROI (Return Of Investment) value. And deliver it all within the client’s budget and desired time frames.
We know that business people and developers must work together daily throughout the project. We also like continuous meetings to synchronise with customer continuously. We are simply motivated to deliver high value to the customer together with the customer. And we remove unnecessary management works to visual instead. Therefore, we must constantly work to reduce factors in our own process that does not give teams and customers a good ROI. That is what Agile is all about. As agile team we also know that our time costs money and we need to use it effectively and profitable. We use product owners and agile coachers to remind us.

Heres where #NoEstimate comes in as one of many factors to decrease waste in our projects. #NoEstimate does not mean we should stop estimating, we shall. #NoEstimate focus is to make it right to bring out the best value for both the customer and the team. In Part 1, I talked about the Chaos report that more or less says that about 78% of our estimates are wrong. And therefore classic estimates are waste of time in our process and can instead be used for other things. Like delivering value to the customer, right?  So why not use it to deliver more value to the customer instead? We can never trust our estimates, they are truly lying for us.

Let me give you some more examples.

You estimate with planning poker or something similar to get as close estimates as possible right?
There is a problem with planning poker. Say that a team set an user story with the number 13. What does that mean? 13h? (2.1 days?). A space of time against Another User Story? 13 as in 13 days? The higher the number is, the harder it is to get the correct estimate. Higher numbers are higher risks. The higher it is the more complex it is. If we want to trust the Chaos report, then 13 user story point has 78% chance of being wrong. It even has a chance (if it is a medium sized company) to go 220% over  the time.
That mean that a 13 user story point can result in about 30 instead. If 13 is a estimate number for days it’s 78% chance that such a point would take 30 days (a month, it is more than a full sprint if you have four weeks sprints.). Imagine then if our project has 10 x 13-day points then it is 78% chance that our 130 days user stories instead will take about 290 days.
(Remember there is also statistics that say that the more experienced you are as a team the better you will hit the right time. But how many elite teams do we have in today’s society? We must constantly replenish with new people so we will never be able to have 100% elite team. That is how our reality looks and the reality we have to adapt.)

Another problem is also the negotiations on the requirements during the project. The customer wants a new requirement but would not extend the deadline. So we negotiate away less important requirement for this new requirement. But how? We do this by estimates the new requirements with Planning Poker and get the number 8. But what does it mean? Normally replace another 8, right?. But is an 8 equal another 8? What if the 8 we will replace actually happened to be one of the 25% chances you have to spot the right estimate and the new 8 happen to be one of the 78% that we gets wrong. There is therefore a risk that the new 8 takes about 18 days and the one you removed actually took 8 days to finish. So it’s 10 days overtime instead. It can also be the other way around, but less likely.
Why do we expose ourselves to this risks when we know about this? Why spend unnecessary time to estimates like this instead of use it to focus on delivery on time instead? In next part (part 3), I will describe some #NoEstimate ideas that will provide safer time estimation and much more measurable velocity quality and ROI for the team and customer.

Stay tuned…