Relay

 

Software development with Scrum makes all team members responsible for the result. Some tasks need coordination, to make sure the tasks will be completed at the end of the sprint the team assigns a person responsible and hands him a token. When starting with this way of handling certain tasks, make it visible.

I just crafted some relay sticks measuring 28 cm in length and 28 mm across (official measurement 38cm, 38mm). I just put some tape around for colour distinction. The team is free to combine a colour with a certain task.

Sticks will be handed over every week. On a day off the stick needs to be handed over as well.   

We will use one of these relay sticks to make sure the translation of changes are coordinated and completed in time. Another one will be used for the task of checking the completeness of new issues.

Empathy Driven Development: Rescuing Value From the Bermuda Triangle

"Our industry still suffers from the curse of the Bermuda Triangle – the place where all stakeholder value goes to die"


http://blog.scrum.org/empathy-driven-development/

Followers and quibblers

As a manager I notice two kinds off employees, the followers who do the things you say and the quibblers who ask questions. I love the latter, those are the ones I want in my teams. On first thought they might add lag, they might slow things down. However, if your team is big enough, they prevent you from doing stupid things. The first group will never prevent, they will coalesce with you into the abyss of faults. The quibblers will only follow when they are convinced.

As a manager I find it difficult to be and stay a quibbler. I think I'm obliged to be because I carry out a function to advice my superiors, which means I need to make them the best offer my department can deliver in all circumstances. If I would be a follower I wouldn't be able to do this. And if I'm a quibbler I might annoy my superior and lose my job. As long as my superiors are not susceptible for quibblers I might be facing heaps of problems.

This fine balance is a problem for me, sometimes I'm just too blunt. To my superiors the edge feels thin and I can tip over any minute, but on the other side I expect a thick edge from the ones I lead; my goal is to provide them with a solid base to deliver me criticism.
Is balancing things out the trick for a manager? Finding the edge and not tip over? I don't know. I rather do what I think is best and get screwed if that's not what my superior wants. And there's another fact, if a superior asks me to do something, should I interpreted it as a direct order (follower) or as a suggestion (quibbler)? I opt for the latter one, risking my position. Being a quibbler makes it possible to find new ways to do ones work better, when someone is a follower there will be no new ideas or any creativity. Followers do the same work until they retire or die.

But hey, if I need to follow, and I don't want to, and I get fired not to follow, is it really a problem? I can't live following, so perhaps that's for the best as well... What I'm trying to say is: don't follow, think! Criticism makes you better, learn to take it, love it. Be a quibbler to your superiors, minors, team members and above all to yourself!

Nothing beats the team

Building a scrum team is hard. It's hard because the good nerds need to be found. Multi disciplinary people, programmers at first with preferable some add-ons. Each programmer should fit in the team, add value to the team. Not one person in the team should be able to do everything, the team as a whole should be able to take on the world.

Skills

What are the skills needed in a team I wonder. First of all we need someone with programming or testing skills. We need someone to be able to perform the scrum master role to guard the scrum process. We need people that communicate. We need people that feel responsible. We need people that are honest, bloody honest. People in scrum teams should be more honest to their colleges than most people are to their partner. So some skills are important to all, some skills to some. Together they form a team that delivers excellent software in time.

One of the hardest aspects for most programmers is to manage expectations of the product owner and stakeholders. The product owner needs to be informed, and also needs to inform himself, about progression of the development of the product. Any impediments should be mentioned to the product owner as soon as they are known. Of course the product owner will suffer misfortune, but less than when he is surprised at the end of a sprint by finding out the team failed to achieve their commitment. He also has a choice when the team hits a set back. Priorities can shift, work can be altered; he can have the ability to help the team reset commitment. The team can deliver a tested part of the product rather than nothing at all.

So commitment on the backlog, responsibility about the work done and communication are main skills that programmers need to have to be able to work in a scrum team.

Forming teams

Forming scrum teams can be hard. Who is doing the interviews? When will the new programmer meet the team? When you have multiple teams, who should go where? There's a simple answer: Include the members of the teams. Some managers respond to this like I'm insane, but if I talk about trust and honesty, who better to decide to open up to than the people who should work with the new programmer? They have the last word whether or not a person joins their team.

When it all goes wrong

What? Isn't scrum the holy grail all the world is talking about? Nope, it isn't. Many people oppose scrum nowadays and ask development teams to drop scrum and go back to programming. Personally I disagree to those people. We picked up scrum to avoid being interrupted all the time and to be called into meetings whole day long. We picked up scrum to get insights in our own performance, to deliver software in time. Of course we are failing sometimes, on the other hand, we are failing way less than before we adopted scrum.

Performance is a result

A good performance is a result, not a goal. People win championships because they prepared well, they were coached well. They win because they have the best facilities and environment to do so.

When a manager asks you to perform better, what does he or she really say? I think it's more like a question: "What should I do to make your performance better?" A manager, coach, facilitator, scrum master, whatever you call a manager these days is the only one responsible for your performance. A bit of talent helps ofcourse but without a facilitator that talent will never show.

A scrum master should always approach developers individually and try to make them better. The team should be more then the sum of the members, a good team can make outstanding performances, but only if they are coached right. Think of it as a football team, without a coach the best individuals will never win a world cup. But a mediocre team with a good coach can reach the finals. He will select individuals and put them on the right spots, he will train the team in what they do best. He can make the difference.

So as a scrum master you should find the talents of your developers and develop them. Develop the developers. Put the right developers together to make the team better then the sum of it's individuals. You need talented developers of all shapes and sizes. Train them like a football team and harvest the best result possible.

Think outside the box

Have you learned about thinking of solutions instead of problems? Does it feel right? Nope? I thought so. How can you think of solutions if you cannot think about the underlying problem. Solutions are sometimes hard to find, even when the problem is clear.

Einstein once said: "Solutions should be as simple as possible, but not simpler". 

Almost all solutions are simple if you can understand the problem. But finding the right solution is a discipline itself. There are all kinds of laws, norms and standards that trouble our vision. We even learned at school to stick to the subject; problems should be solved within boundaries. Let's call that the framework of our thinking. The framework is build on what we learn; what we experience though learning and observation. Anything influencing us from outside the framework can cause stress. We are not used to dealing with that pattern. Except we are; we just don't want to acknowledge that.

This is were we should change and start thinking outside our framework. Understand the stress factors that are around us and use them. This can only be achieved via learning and perhaps a little acceptance. If we learn we change our framework, make it wider, narrower, bigger or smaller. It's a constant process we are barely aware of, but it happens all the time.

Learning new things every day, week, month or year keeps the mind young and makes it easier to find solutions to everyday problems. In software development time flies like the wind, progression is made in a very high pace. Therefore developers should try and keep up with new information. In my opinion a developer who only understands one programming language can be very good at his job, but never as good as he (or she) can get. Learning more programming languages will give insight into how certain programming problems are solved in other ways. This will break open the framework of thinking and create new possibilities for solutions on problems.

From yes-but.org: 
Wherever we work and live, people experience problems. Things don’t go as expected. What’s our response? We say “Yes, but…”. Yes, but I can’t. Yes, but that’s not allowed. Yes, but how much will that cost?
And what happens then? Irritation, stagnation, decline. People who approach life in a yes-but way, think in terms of threats, difficulties and limitations. The glass is always half empty.
There is also another way of thinking: the ”Yes-and” posture. People who approach life in a yes-and way, think in terms of chances and opportunities. They not only see a glass of water, but also ask the question: “Where is the faucet?” This yes-and thinking we call “flipthinking”.

Thinking outside the box can be empowered by flipthinking. A yes-and approach on things. Look at solutions, try to look at problems from multiple directions. Is the before mentioned glass half empty, half full, is the glass just too big or perhaps it is full; with water and air. There are lots of ways looking into problems, try to find them, try to find a hypotheses why any of the problems might be right.

So in short: start learning, start looking around, think of other ways to solve a problem, do it with everything around you; not only work, start flipthinking and most of all have fun doing it!

More:  yes-but.org

It's all in the use case

Let's talk about how developers would like to work. Developers love their job, they want challenge not per se competition, but a challenge to themselves. They are very qualified in thinking in how things should work and how it should be made.

There is one trade off. They almost never know what a customer wants. Most frustration in projects is in this part. Developers build what they think a customer wants, a customer thinks the developer speaks his language and doesn't need many words. Both wrong. When you find a developer who does know or a customer who can speak nerd language, call me! There must be telepathy or magic working there.

So, we can say that both the customer and the developer live in their own world, they speak there own language, have their own fun. And all in all, the don't understand each other, but say they do. The trick here is that both should stay in their own dimension and talk a language both can understand. One way I like very much is the way of the use case. It's not a perfect way, not a holy grail, but then again, nothing ever really is. It comes close though, both people can stay in their comfort zones and talk their own language but understand each other, because they understand use cases.

Goal
In a use case a customer defines what he wants, not how he wants it. The developer can make how he wants it. What now exactly should be in a use case then? Well one of the most important thing is a goal. This should be a short, SMART, sentence what the customer wants to achieve when the change requested is implemented by the developer. Erhm, a what? Glad you asked. SMART is a abbreviation of the following: Specific, Measurable, Achievable, Relevant and Time-bound. Which means a goal should be very clear and because it's measurable, there should be no debate whether or not the implementation of the change is correct or not. A goal should never be ambiguous. One of the features of a SMART goal is about achievable; can it be done; do we need extensive resources to pull this off, or is the goal realistic? Is the change relevant at all? Is it relevant to the project? And last but not least make it time-bound. There should be a timed element in a goal.

Actors
When we defined a goal we start in defining the actors which are needed to achieve the goal. We don't talk about the developer or certain persons, we talk more generic in the way of "a customer", "a sales employee", "a marketeer" and so on. All persons needed to achieve the goal are summed up. To be honest, in most cases there are one or two actors.

Scope
One of the items I like most. Scope sounds simple, but it can be so hard to define. Everything you don't mention in the scope is up for debate. So besides defining what is inside the scope, it's important as well to define what is outside of the scope. This defines the narrow barrier of what a customer thinks he will get to what he actually gets. Scope is mandatory to define, this is the point where are discussions are spawn from. When talking about software change there should be a definition here about what the change should imply on the system and what is should not do. 


Preconditions

Preconditions or requisites are the elements or changes that should be in place before this change can commence. Think about version numbers, hardware capacity or even any other change that should be implemented before this change can be made.


Description
What should go in the description of a use case? Well start with the main success story (MSS). Define the happy flow through the application when this change is made. Did you finish the happy flow? Nice, work on a couple of failure scenario's now. When will the change fail? What message should the user get? A tester will use these scenario's to define if the change is successful and if all fail cases are hit.

To make sure a customer gets what he wants and to ascertain it is of a certain quality, do describe precisely how the application should work when the change is implemented.

This is about the smallest form of use case I use, or allow to be used. If a customer cannot define a use case in this form I will try to help him, interview him and educate him. If the customer understands the how's and why's of a use case he will never want to make incomplete stories anymore. He will find a quality change when he delivers a good use case. But bare in mind that he needs some help!

Template
Although I hate templates because people use them as they are, instead of pragmatically convert them for their own use, I believe in this case that it can help a bit.

• Number: each use case has a unique number, so it can always be referred to.
• Name: a use case has a name which uniquely identifies the use case.
• Goal: every use case should have a SMART goal
• Actors: define at least one actor. A system can also be an actor.
• Prerequisites: any law, rule, system that should be respected or interacted with.
• Description: the main success story and preferably a fail scenario.
• Exceptions: any exceptions on this use case
• Result: what is the remaining product when the use case is finished. Use this to measure if the use case is achieved.
• Trigger: describe the trigger, if any, that fires the use case.

More

http://alistair.cockburn.us/Use+case+fundamentals