Creating your Scrum Cards – Free Template

Hi :)

So after writing about how I prepare my templates (Creating your own Scrum Cards) for the team to write down User Stories, Bugs, Tasks and Improvements, I got some requests to make my template available.

So here it is : US-Bugs-Task-ToPrint (excel format).
Normally I print them using the coloured paper I want (the colours I use are in the Sheet name) and then just cut them in batches using a paper cutter.

In case you you don’t have coloured paper you can just fill out the cells with the color you want and print it in a Color Printer.

Hope it makes your life easier :)

Let me know if I can help you or provide something useful for you.

Creating your own Scrum Cards

Hi!

Quick Tip Today: Creating a User Story Card

You can use index cards and write on them, of if you are like me: a bit lazy but you like things pretty visible and kind of organized, you just have to do some tuned cards in a text editor (Word for 75% population), print them in different coloured paper and.. cut them :). They will them be the basis for your team to use in the
Sprint backlog.

Let me then share my experiments with my tuned Scrum cards.

Scrum Cards – Colour protocol

- Red (or pink when there is no red) for BUGS
- Green for improvements (of previous user stories)
- Blue for tasks – (User stories are broke down into tasks)
- White for User stories (US)

Scrum Cards – The templates

I create a template that I can print because I found most useful to have already in the card the following:

1- USER STORY card:
- User story number (if using a electronic Prod. backlog, you want to refer to the ticket number)
- US component- where this US fits in the big picture of our product
- Priority – we always start by working on most important US
- Estimation – the estimated Story points for this US (just for reference actually)
- UX – name of the Designer who created the concept, just in case we have a question (when having different UX people working with your team)

Looks like this:
USER STORY card

2- Task card:
- User story number (if using a electronic Prod. backlog, you want to refer to the ticket number)
- Estimation – the Estimated effort for this task
- DEV- the team member(s) coding it
- QA- the team member(s) testing it
- REV- Revision number – in which release we can test and find this task

Looks like this:
TASK card

3- Improvement card:
- Same as Task, but ..it’s a green card :)

Looks like this:
IMPROVEMENT card

4- BUG card:
- BUG number (When using a tool to track bugs you want to refer to the ticket number in the tool)
- Component – to which component this bug belongs
- QA- the person that found the bug (important in case we have doubts how to reproduce and also to ask the person to re-test when fixed)
- DEV- the team member(s) fixing it
- REV- Revision number – in which release we can find the fix and test

Looks like this:
BUG card

Hope it Helps!

Older Posts that may interest you:
- Creating Sprint backlogs (Scrum boards)
- Dealing with Legacy Bugs- the BUGLOG

Dealing with Legacy bugs in Scrum – THE BUGLOG!

Hi!

After writing about Sprint backlogs – how you can create one and why it should be the big elephant in the room, I remembered we rarely see people talking about the nasty legacy bugs the scrum team gets during the sprint and how to fit them inside the sprint.

First a disclaimer: when I say bugs, I do NOT mean bugs from the User Story (US) currently being implemented by the team. If the bugs you find are related to the US in progress, then these bugs are part of the current work, part of the current sprint scope. So, when I say Bugs in this post I mean bugs that we have from previous User Stories, from Legacy code.. bugs that don’t fit the current Sprint Scope.

Have you asked yourself several times how to fit legacy bugs in a sprint without endangering the commitment? if yes, then this post might help you.

Scrum
Scrum framework has a very well defined rule regarding injection of “not committed” work: you don’t inject.
If you really need to do something not planned, then you abort the sprint and re-plan. This obviously makes a lot of sense, team has committed for a certain scope withing a fix period, if you add stuff and the time is still the same..well.. no can do. Abort and Re-plan a new Sprint.

Nevertheless this beautiful simplicity of Scrum, we know that life is sometimes not that easy and if a customer is complaining about a bug we should handle it and fast, so how can we do that without endangering the current sprint commitments and at the same time without aborting the sprint and re-plan everything again?

Handling Bugs in a Sprint

The way I found to handle this bugs was to create what I call the BUGLOG.

First step is both team and PO agree that one team member (or a pair if you have lots of bugs and need to keep knowledge in same level) will only be available to fix bugs during the sprint. Nothing else, just bug fixing. By one person, I mean any person, you don’t have to assign one team member in particular, the team members will assign themselves daily according to the bugs in the BUGLog.

As you break the stories into tasks and build your backlog during sprint planning (in order to find out what can you commit to), you will consider team availability equal to Team availability MINUS 1 team member.
Example, if your team has 8 people working, and decides to have 1 person for bug fixing, the team availability will be 7 people.
If you base your commitments on your velocity only, then you should commit to a bit less than your average velocity, because 1 person will be “out for bug fixing” :)… consider it has if each day the team has 1 person off for vacations.

Now that you did your sprint planning and you know which user stories you’ve committed, it’s time to build the BUGLOG:

The BUGLOG is a second board, placed next to the Sprint backlog, having the TOP 10 most important bugs – the one’s that need to be fixed first (I use TOP 10 or 5, but it’s actually up to your team and PO to decide… if they are all minor fast-fixing you can have more, but for the sake of simplicity and quick visualization, keep it small… you can add more at any time!).

Team Members assignment to Bug Fixing

At this moment the team has it’s Sprint Backlog, with the committed Us and it’s BUGLog with the most important/ urgent bugs.
The same way the team looks at the sprint backlog and each team member assigns himself to a task (by picking a task which the team defined as priority in the current goals) the team also looks at BUGLog and checks current priorities. According to those, someone from the team assigns himself to do bug fixing that day.
(From my experience the self- assignee is normally the person that knows more about the bug or the area where bug is).

It is really important to repeat this : Everyday the team looks at the list and agrees on who will do bug fixing. Somedays the person from previous day decides to continue doing bug fixing because it makes sense. But the rule is that we all have our share of bug fixing.

We have now the team working in the Sprint Backlog and this Special Bug-hunter-of-the-day team member fixing bugs. Starting by the one in the top of the list and having as goal to fix as many as he can during that day! (you can even propose a contest ;) for the Mightiest Bug Hunter).

Team Synchronization
The assigned Bug-fixing team member should also be present in the team daily scrum. First because the next day he will be back to Sprint backlog tasks and second because it’s important for the rest of the team to know which important bugs were fixed.
My experience: I’ve always carried on the Daily stand up as usual, team members talking about their Sprint backlog tasks, impediments and together defining what to do next (team daily planning). The Team member doing bug fix would be the first or the last to speak during daily standup, about bugs fixed and any doubts or help needed to carry on next bug. We would ask this person to be the first or last talking because that way we wouldn’t break the flow of conversation around the sprint backlog when the other team members start speaking. But nevertheless this small thing, the BUGLog is seen as part of the overall team scope, just with the slight difference of being handled only by one person each day.

Deciding Bug Priorities

As the list gets smaller, with the bugs moving to Done column, the PO will decide which are the next most important bugs.
(In one of the teams I worked with, the PO received every morning a report from an offshore quality team with all new found bugs. In this case the PO would, every morning, look at the current list of ‘Not yet being fixed bugs’ and look at the report received from quality, and decide if there was any new bug more important than those already in the BUGLog. I so, then he would re-order the bugs.)

Conclusions of my Experience

This BUGLog actually proved to be a great solution to our needs:

1- Legacy bugs are fixed
2- You can also use this BUGLog to add small improvements in older stories or deal with technical debt if/ when that is your biggest pain point
3- PO’s are happy cause they see stories being done and bugs from the past being fixed, all leading to a more stable solution for our customers
4- Team is happy cause they don’t feel interrupted from their work in US and they can still fix nasty bugs they are worried with
5- Scrum master happy too, less yelling (kidding) ;), less: “we need to replan the sprint cause if we need to fix all that, we can deliver our US” and feeling of more trust between PO and Team, cause this system allows both to do what needs to be done without anyone feeling that unplanned things can’t be handled.

For me this proved to be a win-win situation, a tradeoff between both the Team, Po, current customers and..future customers.

Hope it helps you as much as it still does help me and my teams!

Happy easter :)

Building your Sprint Backlog / Scrum Board

Hi :)

Today a practical tip for building a Sprint Backlog aka Scrum Board.

Why should we have a board?

The board main function is to allow team to visualize remaining work (tracking) and facilitate daily synchronization (Re-plan).
Everyday the team gets together, looks at the board (which contains the committed work) and the team re-plans it’s day – What should we do today in order to accomplish our goal?

Because of this, Scrum Boards should be:

• SIMPLE – don’t add to much columns and stuff not needed
• BIG – Everyone sees it, knows where it is and just by looking knows where we are (regarding the team goal)
• ACCESSIBLE – everyone can see it and update it – by everyone can update it I mean the team (it’s their plan, they own it)
• FLEXIBLE – should be easily improved and adaptable to team needs
• INTERACTIVE – appealing people to touch it and play with it (example, by moving cards from one column to another) – if you touch it and name it , you own it – yes, tasks are like puppies.
• VISIBLE – the kind of : you can’t avoid it when entering the room – a good way of keeping questions answered without pressuring or interrupting the team

Paper or electronic ?

I say: something real you make with markers – so paper or whiteboards.

I can give you at least 3 reasons to stick with a physical board rather than using some electronic version:

1.  Electronic boards are accessible, but they are not visible (unless you can afford a big touch screen and display it in the middle of the room)
It’s true that everyone can access a drive or tool, but it’s not something you see just by entering the room. You have to log in, or search inside a folder, so it’s “Hidden”.

2. Electronic appeals to individuality – paper leads to collaboration

If you have a tool:

- you’ll update your tasks before the stand up for the sake of speed – with this you loose interaction

- or you’ll do it during the stand up- with this you’ll increase the time of the daily stand up (and create waste time)

If you use paper, you can speak while you move or edit it. Everyone around you, listening, will also see the task you are talking about

Just FYI, Science :), that Lovely Lady, says there are 3 learning styles:

a) Visual Learners (say around 60% people)
b) Auditory Learners (around 30% people)
c) Kinesthetic (tactile) Learners (around 10% people)

for more details check Neil Fleming’s VAK/VARK model and here .

This means that if you use a real board on the wall, people will not only listen but also SEE what you are talking about, and as you move your tasks through the board, you’ll also touch, perceive the tasks as something material, something that exists.
So with a simple board on the wall you can reach everyone’s attention.

3- There is nothing easier and simpler than paper/ boards to work with, update, improve erase, add…

By using a tool you are bound to what they have, or in case it’s your own tool, you’ll need to implement extra functionalities (and test it, and train people, and…) – while you are getting the budget or permission for this, I’ve meanwhile created zillions of boards with my team ;>.

So my advice is Stick with paper or whiteboards. Use it, improve it, reach the best possible solution. Then, if still you want your own electronic gadget, then… go for it and good luck :).

My board as an example

I made a draft of the board we use. – Sorry but I just can’t take pictures of our walls due to product confidentiality reasons. So if you like it/ find it useful you can just reproduce it in big size
(Extra Tip: don’t make it toooooooo big, else as it will look ‘empty’, everyone will feel tempted to add more tasks than those that can be handled).

If you get back to the basics, Scrum boards have only 4 columns: User stories, Not started (tasks), Ongoing (tasks) and Done (done done, no buts-> done as in ready to go live).

Although I love simplicity, I’ve faced teams where QA was a bit forgotten. So we had to make this visible in order to deal with it.
These teams had no QA experts and developers would run away as much as possible from testing. When having just Ongoing column, tasks just stayed there in a kind of limbo or would go to Done without being really done.
So we split ‘”Ongoing” into DEV and QA.
Having these columns was the way we found to show exactly what was under testing and when this column grows bigger everyone knows it is time to jump in and do some testing.

You can have it or not, it’s up to you and your team. Some teams just create testing tasks and take them through the flow-> Not started->Ongoing-> Done. – Been there, done that – Works perfectly, but only if you have someone caring about QA inside the team, else, again, everyone will delay those tasks as much as possible.

My advise is: don’t get influenced by anyone, except by your team : Do what your team needs and then keep improving it. Target simplicity and transparency and all will certainly go ok.

Let me know if I can help you building your board or just share your own with me ☺ I appreciate new ideas!

Being a Coach

Hi :)

Here are some thoughts, based on my experience, about being a coach.

I realized it’s not about technology, processes and frameworks.
It’s not about teaching people how to do stuff, although it helps if you can show them a new way or help them finding a solution.
But that is not at all, the most important thing about coaching people.

Coaching is about inspiring.
People are smart enough to study stuff and find better ways of doing their work, but only if they are motivated to do so. Or if they realize they have a need and that they must create their own time for personal and professional growth.

My experience says that if you want to be a good coach, you need to: inspire people

Inspire so they feel motivated and eager to come to work
Inspire so they feel worthy, useful.
Inspire so they feel eager to learn.
Inspire so they feel HAPPY and FUN.

Inspire people to do and be better, to be all they can be, because that’s all they need: inspiration. Just a little push. All the rest they can handle it pretty well. And, oh boy!, once inspired you can’t imagine the potential ahead of you!

And last, but not least: Inspire them to be empowered.

Empowerment – not given but taken
Empowered people can change the world, or at least the things they touch. But empowerment is a tricky thing.
Most people, maybe due to education or culture, think that empowerment in a business environment is something that must be given by someone having a position of power. Meaning, if you are a developer you feel like you can only be empowered if you line manager or technical lead says so in front of everyone else.
This is not true. This is not empowerment- this is task attribution or delegation.

Life in an office is not that much different from life in… well, life.
As such, empowerment is not given but rather taken (taken as in assumed not taken as in steal for someone).
Once you put your mind to solve something in your personal life, there is no one who can stop you as well there is no one who can actually give you the energy and will power to do it, except yourself.
Same in office. You should not expect to be empowered, you should take the chance to change or do something and embrace the power and greatness of doing it. Take it, don’t wait for it.

Really powerful people are not in a power position, they make it. They are the one’s you recognize as leaders, opposite to those you consider just silly bastards with illusion of power, the one’s you comply with but whom you’ll never follow wholeheartedly.

Gandhi was a powerful person. And he did not have any high position in the hierarchy of kind lawyers, he was not DR. PHD Master MBA Mr. Gandhi. He was powerful because he chose to be so, he took every single chance to make the difference and change people’s life and or mindset.

It’s up to you to be powerful. It’s up to you to be different and drive for yourself your own path. If you choose to do so, then, you might as well consider yourself a coach.

What about people who don’t want to change?

Yes, they exist. Sometimes out of fear, sometimes envy, sometimes ignorance, but yeah, they are out there. You can bring knowledge to people, but only if they want they will learn. And some, let’s face it, just don’t want to. And that is ok. If we were alike and all inspired people, life would be boring and expectations too high.

So, Know when to give up. Some people don’t want to change and they won’t let you do it. Just go and use your energy somewhere else. You deserve it, as well as all the others waiting for you to arrive and waiting for the chance to evolve with you.

Expectations

Expectations are good, they drive you. They help you aiming and they lead you there.
But, on the other side, expectation can also be a time bomb in your hands.
I’ve always had problems managing both my temper and my expectations. I’m not a patient person, so it’s really hard for me to contain my expectations to a sane level.
If, on one hand, this is good because it helps me eager and open for growth and new experiments, on the other hand it’s a big problem because I may never be satisfied with what I’ve achieved.

So, my personal advice, coming from my own pain, is: Plan your expectations.
For example: Write them down in a paper whenever you accept a new goal. Then, just track them down. Once you’re done or the time is up, you’ll know where you are and how far you are from your initial expectations.

Things will evolve and I really hope you add more and more expectations to that plan of yours, but the point here if for you (and me) to be able to look down to that plan, and know that your achievements are actually good, and although it may feel like they are not, you’ll (we’ll) know that this is only our big-mouth expectations talking and trying to trick us by overlooking what has been achieved.

I once heard a sentence from a writer I never forgot, because it makes a lot of sense on my way of living, he said: It’s extremely arrogant and hypocrite to judge the past, having the advantage of being in the present.

This is how I always managed my expectations. I would judge what I did, but having as basis my current mindset. And that is wrong. I should always fit the results into the expectations defined at the time and considering the situation when they were set.

I did that, now I won’t do it anymore. I learned and now, I know better.

Have a nice weekend, and, please… Go make the difference is this little world of ours.

Leaders and Servants – Tips for the Scrum master

Scrum masters are not meant to lead (lead technically or in terms of business), they are meant to serve. And serving has different flavours.

This ‘epiphany’ started with a 15 seconds chat with a fellow Scrum Master.

- ” Should you be a leader? “- I asked the scrum master

- ” Of course”- He replied

- ” Will you drive the team?” – I asked

- ” Of course, I must drive them to do better”

And here I disagree.

It’s too easy to lead and drive (easy for those who really are drivers and leaders, for the others: this post is not meant for you).

Too easy to make people follow. And good too. But only if you mean lead and drive their motivation, engagement and pride.

So I say – Scrum masters are not meant to lead (lead technically or in terms of business), they are meant to serve. And serving has different flavours:

When you start as a Scrum Master (I call it Type 0) in a new team you serve as the person who helps removing impediments, you serve as the person who helps organizing the work, serve as facilitator on running events as daily scrums, retrospectives, demos and by setting up practicalities.

But for me this is a first level Scrum Master. A servant of practicalities. You won’t grow a team with this, you are just keeping things clean and neat.

So here comes my favorite flavour: The Scrum Master.

- The one who causes pain by uncovering what’s wrong  and does not heal people by making small patches that hide reality or solve temporarily stuff (does not loose time fixing symptoms) .
- The one that, above all, believes that the team must heal for itself no matter how hard, how painful and how long it takes. For every fall you take, you will rise stronger. And this is true also for teams.
- The one that believes, that knows!, that each team is smarter than any Scrum Master in earth and they’ll find better and or most suitable solutions for their own illness.

I guess this is why Scrum Master as troublemakers for some. These little bastards keep pointing out your problems and they don’t let go until you fix them.

I’ve had my count of type 0 Scrum masters, so nice and protective. Always keeping things neat but unfortunately with no impact on the team growth. Sometimes it’s also because it’s really hard to justify where a Scrum Master spends it’s time, so we do this neat boards and cards and things (which are ok and needed, but nor what teams need the most). How do you explain and justify that 100% of your time relies on observing the team, making questions and reading? That’s waste, right? May be. But, isn’t it needed?

I also had my share on type 0 too. Now I guess I don’t care anymore. I dedicate myself to do silly and hard questions. Of course that I still try to do (as much as my skills let me) neat boards and things to increase visibility and transparency, but if they don’t use them, that means they see no value, so I stop. Ok, there’s a minimum you must keep, but what’s the point of doing stuff for people if they can’t fully use it? We should be helping with answers not more waste, right?

And the only way I know to help with answers is by making questions.

Are you helping with questions or giving the answers you want to see? Is that the answer they need? How can you tell?

Sometimes we know the team needs something, for example, to do a brainstorm and get a common understanding by sharing different perspectives, but  it happens that they don’t feel they need it. That’s ok. If you know you are right, just prove it. Show why they need it, make questions that will help them figure out that actually they need to do something.
But don’t just recite the books you read: they are smart enough to give you all the arguments to prove their reality is different, and how your suggestion doesn’t fit.

Question everything, maybe even suggest a way and ask them to experiment it – you’ll probably end up with a new way of doing stuff: a better way for all.

Bottom line, don’t try to be a leader. But also don’t be just a team assistant doing practicalities. Observe, question, suggest, try. Be a servant. A servant of pain and doubts. Make them think out of the box, new perspectives, new ways.
Don’t be a driver, just show them how to hold the wheel if they need too. show them how it can be done, don’t trap yourself on thinking that’s the only way of doing it. Let them evolve.
And scream, scream a lot while you are all taking a ride with them driving, they’ll surely improve the way they drive just to shut you up. My dad tried that and it worked ;) I’m a better more confident driver now, and he… well he sleeps while I’m driving.

The 7 Feet Under model – losing good people

It’s time for me to finally publish and share my famous 7 Feet Under model.

WARNING: this post contains strange things as Zombies, dirt, graves, stupidity, sarcasm and some other weird thoughts that may hirt the reader. enter at your own peril.

The ’7 Feet under model’ is a simple visual summary of  my observations during a Workshop, as a second title I called it ‘Losing good people’ because this is what happens when we submit people to constant failure without listening or helping them to take actions.

After drawing this model, actually without thinking about it but just drawing it by heart while listening to people talking, I became aware of several things. The biggest one may be that I realized that people aren’t demotivated just because they like it, people are not giving their best because they don’t want to. This happens also off course (not liking or not wanting), but what I observed is that most of people in the room had aspirations and dreams, and they were all lost due to a long exposure to failure. And, I’m afraid to say, they no longer knew what to do to change, whom to talk to about it without showing vulnerability. And as we all know, vulnerability is a funny thing and leads to an amazing distorted perception from those who show their vulnerability and from those who hide it. In short: It means weakness to those who hide it, it is strength to those who embrace it.

Well, but let’s not go through vulnerability today, Let me just explain you what happened and the model, let me take  you back in time with me and show you what I’ve observed, learned and reflected later on.

The Stage

I was asked to run a workshop where people would reflect on the meaning of Sense of Urgency (SoU) and later brainstorm what could we do to wake up or boost everyone’s SoU.

(It was actually a funny workshop where I heard lots of, well, silly things, if you have time just enjoy yourself here).

It was an interesting session full of different reactions, although the most common one was blaming and denial. At the time I was  a bit stressed and losing my patience because I was feeling like I was in a freak show. I saw people I knew better blaming everyone and finding the most extraordinary escape goats to every single thing being discussed as a probable root for lack of SoU.  I knew they were ,are, capable people. Fighters. People who can and do better. So I could not understand why they couldn’t just deal with it – Face it and deal with it!

As a facilitator I tried not to intervene much, and if at the beginning I was stressed with the things I heard, the fact is that after embracing my observer role, I start finding it funny (the proof is the post I’ve made at that time). But after some time I stopped amusing myself and tried to understand why such good capable people showed so much despair and lack of faith in others and consequently in themselves.

I was listening and I noticed myself drawing this thing I called the ’7 feet under’ model.

You may not agree with the things I’m about to write, but actually in this post there’s no place to agree or disagree. This is the result of an observation, as such I really hope you read it and find something helpfull to you, to your own inspiration, reflection, perception or simply to your aspirations. I added some advice – which actually you can take at any stage (check the ‘Try this’ sections) and I hope you see the value and usefulness in it, maybe for you or for someone next to you.

The 7 FEET UNDER model
(click image to expand)

 

Explaining the Model

 

1st Project / 1st foot under

The Ignorant

When you fail for the first time, or your project fails, mainly you feel Ignorant, as if you didn’t see it coming. You feel as you couldn’t know better and that’s because you are new so you had no way to predict, or expect and deal with so many bad things at the same time. So in the end, when you fail for the first time you feel a bit ashamed but you dont feel ike the worst professional in the world, specially when there are more people working with you and they’ll surely finding other reasons for failure.

Try this:

Reflect on this: During first failed project you are learning. Everything, including failure, is part of learning process and it does grow your knowledge, in business, impediments, risk, people, in all that surrounds you. Includes also a bit of learning on how to feel bad afterwards, how to be humble and how to live with it. So, as I see it, your first failed project can still bring you something good: you can learn. Just don’t expect things to be great by default. You need to, you have to, do something about it. You have the power to influence things around you, so just do it. Use all the energy you couldn’t use in celebrating that first project into making the best of the next project.

2nd Project / 2nd foot under

The Blamer

Second failure and you start feeling.. well.. angry. It shouldn’t have happened again, something went wrong and it certainly wasn’t you because this time you had more experience and you prepared yourself. So, you get into resistance mode, you blame others for failure and you point your mighty finger to every single thing that made your project fail. You take sides. We did everything right, it was their fault, the platform guys, the architects, the designers, the dog…

Although this is demotivating, the good thing is you can still learn. And trust me, you have a lot still to learn, else your project wouldn’t have failed. Also this is the first time you can start feeling some willingness to change. Change your behavior, as in collaborate more openly and often with people around you. Or simpler solution, you can also change your job, but keep in mind that if you do so, you have to leave behind your frustration.

Try this:

You got to realize that blaming takes you no where but demotivation and frustration,  and it endangers your credibility towards your colleagues. Read about the @ChristopherAver’s Responsibility Process , you’ll understand how usual your behavior is and that actually you can change it by mastering the  responsibility Keys.

 3rd Project / 3rd foot under

The Indifferent

When your 3rd project fails, you feel…nothing but dirt upon you and the grave getting deeper beneath (My apologies to sensitive readers).  You are feel indifferent.  It’s like you don’t care, you are getting used to that flavor in your mouth and you already said last time that the dog is the one to blame. This is a crucial time for you and your turnaround. Being indifferent to the things you do is one of the most dangerous things that can happen to you as a professional and lately as a person. Just think about the long hours you spend, in misery I say, in the office.. do you think it will be easy to leave that frustration behind office doors? No buddy, you’ll take it home with you..straight into your personal life. This is the right time for you to jump. Up or Out.

Try this:
Stop for a moment. Reflect on what makes you happy: Your passion. What drives you? What brings meaning to you? If you don’t know how to find the answer to these questions, you can always start by reading something about what drives humans- if you understand what we value, it may happen you’ll find out what makes you go forward. You can read about motivators in @DanielPink ‘s book DRIVE  (or watch in youtube the short animated version) and in @jurgenappelo‘s blog here

4th Project / 4th foot under

The Proud Ignorant

Congratulations, you reached the peak, from now on no way up, always down. This is the  phase of conscient Ignorance. At this point you don’t care, you don’t know what’s going on and you know it and you don’t give a damn.

Basically you are like this guy?

(BTW, I love this picture. I don’t know who did this, but my appraisal to this amazing human being.

Please forgive me for not adding your name here, but I don’t know where to find you.

If by any chance you find this, let me know and I’ll fix it immediately. Respect!)

Try this:

Pair work with newbies. Work with people new to the project and shake down your sarcasm and skepticism.  Working with new people gives you a new perspectives  plus may boost your own energy by watching how passionate they can be regarding the things they do. Let yourself be influenced by their motivation. Grow a relationship with someone that needs help fitting in, nurture that person. You’ll be asked a lot of things and you may actually feel like it’s important to provide and answer or, better, to find out a solution together. I propose this because I believe that at this stage you are incredibly fed up with everything, so having someone in need around you may actually rescue you from all that and give you a chance to build something great and recover the sweet taste of usefulness.

5th Project / 5th foot under

The Self Inflicted Ignorant

Boy, from this point onward there’s no return (almost). You better find yourself a winning  project and turn the table else you are doommed.

People that unfortunately reach this phase, get into a state of Self Made Ignorance. As in first failed project, the ignorance they carry is genuine. They really don’t know better. They are completely alienated from the current world. But if on the first failed project your ignorance came from inexperience, now it exists because you let yourself grow stupid. Basically this is it. You let yourself grow STUPID (I felt this several times already in my short life, not always it comes from failed projects… grow stupid is a natural thing, sometimes because we are lazy or just because we chose a different road and forgot to keep up our knowledge).
In this stage, because you feel you’ve been failing for too long, you got used to it, there’s no apparent punishment (if it may be true that no one fires you, actually your punishment is worst – you are growing exponentially stupid day by day).

Try this:

Start small projects at home. Recall the things you used to be happy doing and do them again, even if that means rewriting the same small application or paper you did in college. Start small, grow big. Go to meet-ups, conferences, interest groups. You don’t have to speak, actually you  shouldn’t or you may loose respect  at first sight :D (kidding) (I guess), just listen..and as you feel yourself  less stupefied you can start sharing.

6th Project / 6th foot under

The Zombie

Your 6th project failed. Should I thank you for that? No, because I guess you didn’t even notice it. You come in the morning because you are used to. You sit and you do some stuff on the web (facebook keeps you alive still).

You lunch with people you used to know (the one’s calling you for lunch are just like you, the others avoid you), you wonder around the coffee area, you feel lost and lonely, and there’s nothing like some gossip to sparkle your mind.  You manager keeps rating you as low performer and you don’t care as long as the paycheck is  the same. People stopped asking you things because they don’t find it funny anymore that you answer to every question with a:  ’uh?’

Try this:

Find someone patient and respectful in your team and ask if you can sit next to him and learn. Call it pair working. Be honest by say you have given up sometime ago but you would like to know more about the project and learn something and who knows? even be useful. If you don’t feel comfortable with this, maybe you can try to do some other stuff the team is not doing (because they forgot it, delay it, don’t like to do it or simply don’t know about it) and do it. You can, e.g.,  test some of the stuff your colleagues are doing, but watch out!, testing is not easy and it requires great skills to be a good tester, but maybe you can start slow. Test simple things and compare them to the requirements. Then humbly help team improving their stuff (don’t throw crap into their vent else your a dead arrogant useless zombie).

7th Project / 7th feet under

The Coma

At this stage you have some similarities with the zombie but, you don’t move anymore, nor you talk to colleagues.

You come to office, not too late because people would dare looking at you and salute you. You leave early though. But no one cares or even sees you. While leaving you try to look like you are busy, like if you need to leave for an important meeting. Meetings are your favorite place, not lunch time anymore, no. Now you like meetings, specially Calls. You just sit there with your headphones and you turn on all those voices talking about products and budget and funny stuff, you don’t understand half of what they say but it’s your job to attend those Calls. So you just do it. Headphones on and some excel report with lots of numbers. And so you day goes by and you feel as if you’ve done something.

Try this:

Find a new job. Honestly: Find another thing to do.

Lots of people have done it before you, actually lots of people are doing it right now, while I write these lines and also while you read them..and in between! Change is difficult, of course! All good things carry risk or uncertainty but after doing it, when you look back you’ll feel proud of yourself for having the courage to take that first step. I advise you to read about change in @olaflewitz ’s blog , or here in @yveshanoulle book you can see how lots of people changed their lives and found some meaning to it!

Seriously! What are you doing there? Wasting your time, being unhappy, frustrated, no passion, lonely.. useless. You can do better. You know better, the world is full of possibilities…get out and find something that makes your eyes sparkle… maybe some other area, doesn’t matter, don’t waste your life.  Life is just one shot, don’t throw it away for nothing.

And there you go… I salute you because you finally got there, 7 feet under!

To everyone in or getting into any of this stages, or just slightly disappointed with life, I advise a few books and talks (feel free to add more here):

Books

The Dip by Seth Godin

Epiphany by Elise Ballard

TedTalks

The Power of vulnerability by Brené Brown

3 things I learned while my plane crashed by Ric Elias

The 3 A’s of Awesome by Neil Pasricha

Dare to disagree  by Margaret Hefferman

School kills Creativity Ken Robinson

Name(required)

Email(required)

Website

I recommend: (required)

Thanks!

Cátia

Engage your team – seeking and finding followers

Dear reader,

How often when leading we use good examples to support us?

How often when talking, while trying to explain something, we use that person (which we know it’s already engaged) as an example to support to our case?

It’s human, we always seek for supporters. That’s why we try to be surrounded by family and friends. Football clubs. Religion. Going to same grocery store, Church, Same strip bar*. Whatever.

But today I was thinking that maybe sometimes we should just seek for something else, rather: someone else than our “star supporter” .

Just try to go and seek elsewhere. Pick up someone else, even if you don’t know if you are really being supported by that someone else, go for it if you see some empathy or slight engagement.

There are at least 3 reasons to do this, as far as I see it:

1- You don’t fall into the old trap of everyone listening to you feeling that you have favorites (even, specially!, when it’s not true.. )

2- You empower someone else and praise his engagement  (and everyone else will pay attention and feel like: oh! I can do that to0)

3-  You. For you.  If you start seeking new followers, you’ll start finding them. And at the end of the day you might just find yourself surrounded by people that ..well: follow you, and  maybe even inspire you to keep on and, if that’s the case: do better.

Hope this helps you today. Just popped up on my mind.

See ya!

*Strip bar  was used here only for SEO purposes :D

Perceptions – How important in a TEAM

 

 

Wikipedia says that PERCEPTION is..

..The organization, identification, and interpretation of sensory information in order to fabricate a mental representation through the process of transduction, which sensors in the body transform signals from the environment into encoded neural signals

 

And how important this is!

… Perception simply defines the shape of the world for you.

And how interesting this may be!

… Aren’t we just living around perceptions daily?

Everything you do, see, smell, tastes…the way you think: nothing but the product of your perception.

How much of you does it take daily? How wrong and right can you be at same time?

And if perception is just the way our head decides to store information, how hard can it be to .. I don’t know.. Defragment our brains and rearrange info? Shouldn’t be that hard right? Think about it…

 

SO, here’s my advice for you today…

• Listen and acknowledge
• Store it the way your brain is wired to do so (you can later thank to your parents, society, culture,.. for all that)
• And then, just when you perceive a different view, don’t deny it or fight it. Stop for 30 seconds and reflect on:
  • “What I know about this is MY perception. What I hear now is ANOTHER perception. Not better or worse. Just another perspective. Another way of storing, identifying and accessing info from a different brain”.

 

I knew perception since I was young, but I just stumble on it some time ago while preparing a retrospective about relation between teams. No damage can be done with perspectives, opinions, and comments if you get your teams to understand (or remember actually) what perception is.

And when you do so, you are much more open to talk and more secure about feelings (yours and others).

 

As far as I’m concerned, and to all people that think that perceptions are just smoke and should not be address inside a working team, I keep my perception on this: YES, they are perceptions and not facts, but that doesn’t mean they don’t exist. They do. As such they should be address and talked about. It may end in someone changing behavior or mindset, or someone else changing his perceptions: either way it’s a positive breakthrough and brings people closer. Teams closer.

 

If I can trust you, I am not afraid to talk and confront you.

If I can talk and confront you with my opinion I will commit to what we decide together.

If I can commit to what we decide together I will act accountable for what we do.

If I can act accountable I will fight for our collective results.

 

And then, just then, we, together, won’t be dysfunctional anymore.

 

Deadlines: a boost

When you work with a team of smart people, deadlines can actually be positive thing. But there’s a catch: deadline cannot be fake.

If the deadline is something with meaning for end users (not just for the sake of plans- although we all understand the importance of those), the team will take a responsible approach towards delivery .

It’s a pretty simple principle: people need a purpose.

If the deadline is something that makes sense to the real world, then the team will be able to take decisions based on priority, will be more aware of consequences and will be able to keep decisions and options simple  and focused. Better than any manager, after all they know the real consequences of every option.

Have you read about Real options?

Read it, @PapaChrisMatts and @Olavmaassen have made a pretty good job explaining  it.