Leadership, projects and technology

“Protect the team” is a double-edged sword

2014-12-03T23:15:00.000+01:00

The biggest flaw in how teams adopt Scrum might be the “protect the team” mentality. It can prevent teams and organizations from reaching their true high performing potential.

At the same time, there are very valid reasons why the “protect the team”-mentality happens in the first place, and these issues need to be addressed.

This combination makes “protect the team” a very interesting topic!

The different aspects of protecting the team are:

protect the team from others
to protect the team from itself
and finally the need to stop protecting the team!

Let us explore in more details each of these different situations:

1) Protect the team from others

This is the obvious one. Many teams struggle to be able to get the peace and time to actually do their work. I have seen months and years of waste due to constant reprioritization, stakeholders directly poking team members, too many stakeholders, silo oriented organization, big up front design, big up front detailed specification (that turn out to be all wrong), constant changes in team composition to name some.

The answer is to find the right balance: a development process based on few and simple principles, which create a heartbeat and fits the organisation’s needs. The most common improvements in order to help to protect the team from “outsiders” have I found to be:

Train organisation to commit to sprint goals

How? By repeatedly ask the question: can this wait two weeks?
What: Prevents random disturbances and constant reprioritizing
Reduces work in progress

To see issues that can not wait until next sprint is rare. I have yet to see it, even in teams that are responsible for systems in production for millions of users. If this is an issue, the first remedy to try is start having shorter sprint. The point of keeping focus within the sprint is essential.

Use the backlog:

If it is not in the backlog it will not be done
How? By having a simple process that works on grooming the backlog (get the right items in, prioritize it right, and reduce the number of items, not include too much details in the stories except the ones for the current and next sprint)

Help on basic meeting hygiene

How? Start with being explicit about the purpose of every meeting and stick to it. Keep a parking lot for everything else. (rather than having a shared parking lot, it is often better that meeting participants write down follow up items for themselves in order not to bring everyone’s attention to side track items)

Reduce the need for handover

Typical symptom: people from other departments bugging the team with requirements and needs. Why does the team feel this as “bugging”? Because it is “out of scope”. Should it be out of scope? Probably not. The solution then is to get the right skillset into the team. The people with their hands dirty are the ones that needs to have the skills and knowledge to solve what they need in order to deliver something potentially shippable

2) Protect the team from itself

This might be less obvious, but still common and important:

Starting on important but “random” work that is not part of the sprint goal

What: the team starts to pick random items of the backlog to start working on, or start working on technical items of their mind
This can be a symptom that technical items are not prioritized. The solution is to train the team and product owner to add technical items as part of the regular system development process. Then the team has their say in an amount of time that makes sense to them and the rest of the organization. I have often seen approximately 20% of the total time, but this varies a lot based on the situation.
This can also be a symptom that the team does not know the business goals, the customer or domain very well. The solution can be to use lean startup techniques and get the customers closer into the development process.

Need training to take unconditional responsibility

This is a chicken-and-egg issue: teams that take responsibility get trust from the rest of the organization, organizations that lack trust are preventing teams from taking responsibility
Culture changes are more in depth reaching than anything else. This is about a culture of taking responsibility to make the best out of any situation –difficult or not
Team members need to have the confidence that they know the best how to do their work
The best way for a team to gain trust from the organization is by transparency and continuous delivery of stories that are ready for production.

Many teams need training on taking responsibility for the whole team and sprint goal delivery, and not optimizing for individual team members and hand over within the team.

Gold plating: being afraid of early releasing

Over and over I have seen how difficult it is to let go of our baby. Even when it comes to internal releases. This might be a matter of habit and mindset. As an agile coach, I spend much of my time in helping teams to get to the point where they want to deliver on a frequent regular basis.
Start getting used to the feeling of being “not ready”. Software is never going to be completed anyway

3) Stop protecting the team

When you are mastering the workflow so that you do not have any big issues related to 1 and 2, then it is time to grow further:

Optimize the whole

Shielding the team from the rest of the organization is optimizing for a too low level. It is time to facilitate for optimizing for the whole looking at the bigger picture
Keep shortening the feedback loop and keep involving more of the customer journey into the software development process

Be aware of complacency

A high performing team that has worked hard and now sees the results from their agile approach might fall into the trap of thinking they know it all
The solution is to focus on continuous improvement and learning, also from the rest of the organization and from the customers

Address the root cause of organizational issues

Protecting the team from outsiders is a short-term solution to organizational flaws. In order to get a high performing organization, we need to find and solve the true cause of these pain points

This is my take on "protect the team". What is your experience?

How to optimize the whole: Do you know your customer journey?

2014-11-12T08:34:00.004+01:00

Lean has been essential to many successful businesses for decades. It is a learning experience, and in this post, I will show you how I have come to discover more and more what the lean principle “optimize the whole” means:

2003: Optimize the whole = Optimize project deliveries

I started out thinking it was much to gain by optimizing the project delivery process. We focused on how we could deliver software that was tested and that fulfilled the requirements from operations -doing it as effective and as fast as possible.

Handover - Tableatny @ Flickr

2007: Optimize the whole = Optimize the sw life cycle

Around 2007 I realized that we had so much more to gain by optimizing the whole development life cycle: from idea via concept, implementation, testing, installation in production, upgrading and rollback. (yes, moving away from waterfall.)

It was popular to start using more agile development approaches, Scrum and Kanban. I got to work in agile teams; the concept phase, implementation, test and deployment happens within short sprints, even in some large organizations. This is a great improvement, and it is a delivery thing. Getting the software out there, in order to be used, not stored, being able to focus on the features that are actually used! and getting better and better at devilvering the right features. Fantastic!

What a great difference!!

2012: Optimize the whole = optimize the customer journey

What if you are great at producing the right features and great at deploying it easily to production, but the customer never get to hear about the product in the first place? Or the customer is not able to get started? Or it is almost impossible to buy the product?

I learned that the whole customer journey was what really matter to the customer. To me, this is the next step if you are into advanced lean thinking: Optimizing the whole value chain, seen from a customer point of view.

So what can you do to get better at this? This is what we did:

Identify the customer (define the relevant personas)
Identify the steps in your customer journey
What works well?
What are your weak spots? where do you lose your customers?
Any low hanging fruits?

The customer journey

The best organizations consists of units that support the whole customer journey, they are able to handle, improve and truly optimize for the whole. (not only the whole software development process, but the whole customer journey)

Pitfall: I have worked in a team where too many people was looking into step number 4, and unfortunately, the areas of most interest was outside the responsibility of our business unit. This is not a good situation, it is damaging to the motivation of the individual and it prevent the team’s ability to deliver if the focus is on what you cannot change. In an ideal world, anything can be changed, and anything can be changed easily.

Top performing organizations will change according to what makes sense, but the larger it is, and the more silos you have, the longer time it take. It also require sweat and lots of hard work, and some tears. Trust is a key word in agile software development, and the same goes for lean leadership; each employee must be able to trust that the top management is handling flaws between business units.

Trust

Where in the lean journey are you?

What is your next steps?

What is pitfalls have you experienced?

From semi-finished to finished user stories

2014-10-23T15:51:00.003+02:00

One of the cornerstones of being agile is to deliver done features by the end of short sprints. Done as in potentially shippable. Done as in implemented, tested, documented and possible to deploy into production.

This is a typical semi-finished user story

Common arguments why user stories are left semi-finished:

we are not used to copmleting them (...yet)
we think it is unfair not to take credit for partly done work (it looks worse than it is, and we are afraid that management does not see this bigger picture)
we do not see the point in delivering smaller parts that is truly done
I think I am more effective if I can focus (all my time) on the one type of task that I am best at (rather than optimizing for the team and product delivery)
we are different than other product development teams –this might be a good idea in other teams or organizations, but not here
we are not prepared for the visibility this will provide (goes for both management and team members)

Ripple effects of done

Why is it so important to deliver finished user stories?

Focus on delivering something that is finished each sprints will provide you great benefits:

1: Deliver real value -early. Get the great features out to the customer, not storing them on the shelf.

2: True visibility of progress, and make any unresolved issues visible. Handling unresolved issues before moving on to new stories will reduce risk for the company/product delivery, and create visibility of the reality. This is important for any team :)

3: Ability to deliver the true minimal viable product. Help each individual on the team to participate in dividing the user stories into small enough pieces. This in turn will help the company to deliver the true minimal viable product, making the product development more flexible: you will be able to deliver a first release, then learn, then add more features, learn more and so on. –A great place to be!

4: Pull together as a team. The team will become great at collaborating to finish a user story and helping each other out on that rather than only optimize for the individual preferences of tasks to solve. This can seam harsh in theory, but in reality, the reward is intrinsic motivation triggered by being a part of something greater than the, it gives a sense of purpose. (of course the teams needs to be put together with interesting tasks for everyone most of the time, and by people that are motivated by and skilled at similar and different tasks)

5: Trust. When you deliver finished stuff, the rest of the organisation trusts you. Then you get the freedom to make smart choices work a way that make sense.

How to get there?

In Scrum you do get some help on visibility of how good you are on finish user stories:

You do not review any partly done user stories (show only finished stuff)
You do not take credit in any sense of user stories that are partly done (it can be visualized on a burn down chart)

Does it seem harsh? Maybe. Still I think the reasoning behind focus on completing user stories makes it worth while, I can not see how anyone can be agile and still leave unfinished work.

Understand the reasoning behind by reading up on the topic, talk to others and join the agile community. Then you need to work the knowledge into your culture. Inspire, educate and engage.

I reccomend any team to give it a whole harted try for 6 months

I would also allow time to make the necessary adjustments:

Most certainly, there are many reasons both technically and human that needs to be addressed in order to get to a place of making user stories that is done and truly done.

You can do it!

Further reading:

This is a great read! http://www.mountaingoatsoftware.com/blog/dont-take-partial-credit-for-semi-finished-stories
Read this if you are interested in the details on velocity:
http://www.agilelearninglabs.com/2013/08/story-point-accounting-across-sprints/

This is related, about pulling together as a team to complete stories:
https://www.ibm.com/developerworks/community/blogs/c914709e-8097-4537-92ef-8982fc416138/entry/are_you_struggling_to_complete_user_stories_each_iteration1?lang=en

How to be successful in moving others

2014-10-08T22:27:00.000+02:00

I just read Daniel Pink’s book “To sell is human – the surprising truth about moving others”. This post is a short summary of it.

Pink claims that these days we are all in sales. This resonates well with my experience, both when I have been leading teams, worked as a people manager and as a partner in a start-up; much of my work has been about moving others. I have also some experience in selling to customers, and I agree that the basic principles of moving others apply in the different settings.

Moving others is also important amongst high performing team members; I have had the pleasure to see how team members of high performing teams elegantly work to move the rest of the group.

So, how to be successful in moving others? Pink’s answer to this is by Attunement, Buoyancy and Clarity:

Attunement: Understand the other person’s perspective

You can improve your skills here by knowing if you are extrovert or introvert. If you are extrovert (like me) watch out; you will benefit from making sure you are a good listener, ask the right questions and truly listen to the answers, not being too eager to speak yourself. Power, ego and extroversion can be a hinder. Find the balance of being soft spoken, listen and observe in addition to add your voice and make your point when the timing is right.

Buoyancy: Sense of possibility, and keep a positive spirit

"Positive emotions like amusement, appreciation, joy, interest, gratitude and inspiration broaden people’s ideas about possible actions … making us more receptive and creative Negative emotions on the other hand will do the opposite."

Also in this matter, balance is king: The ideal ration between positive and negative thoughts are 3:1 [Barbara Fredrickson, Positivity: top-Notch Research Reveals the 3 to 1 ratio that will change your life]. Appropriate negativity is what provides feedback and help us adjust and learn.

“I have not failed. I've just found 10,000 ways that won't work.”
― Thomas A. Edison

Clarity: Find the right problem to solve

Pink argue that traditional sales came to life when information sharing was limited, and therefore the sales people had an information knowledge advantage. This is no longer the case today.

From product development, I know that it is hard to communicate and to know what the customers want (not only from the product development point of view, but the customers themselves does not know what they need nor can they explain it). Today you get an advantage if you are able to help people to find and articulate the right problem to solve.

Do you find yourself in the business of moving others? if so, I recommend you to look at this video and to read Daniel Pink’s book yourself. Enjoy!

Further reading:

Want to work agile? Deliver on time!

2014-07-29T22:35:00.000+02:00

How often does this train leave the station? It is obvious that it is too seldom. I think this is the best picture to show how feature creep looks like. We have all seen it in software development:

The less frequent the train leaves, the more important it becomes to get on it! All features "needs" to get on the train, because they are so few and far between.

And this train will be delayed. That is for sure!
It becomes a negative self-fulfilment: the releases are happening too seldom, and consequently we need to pack them with features. The result is delayed releases, and because of this there will be even longer to the next release, and therefore it becomes even more important to get all on-board before the train leaves the station.

This is the tram close to where I live. It leaves every 7th minute. It started departing with this frequency last year (down from 15 minutes), and it resulted in several changes:

1) I do not look at the time before I leave my house: I am ready when I am, and there is no need to rush or worry that I wait too long

2) The driver does not wait for passengers that are too late and who is running the last 50 meters to make it. The driver just closes the doors and drive away on the scheduled time.

How do we get to this beautiful state when delivering software?

1: Create awareness, acknowledge the problem
I used to work in a team where the stability of our software decreased between releases. This was not a happy state. We saw that it could be rectified by increasing the release frequency.

Other good reasons for having more frequent releases could be: delivering value sooner, time to marked, need to respond to change, as a means to reduce work in progress and produce finished stuff

2: Build up the urge to change the situation
Change can be difficult, and it is hard to convince others. Therefore, I have usually worked with those that agre this is a good idea in the first place. Working with people that share the idea together identified the bare minimum to get started.

3: Just do it
It has sometimes felt like being a bit irresponsible to release without a big fat release process. It is important not to underestimate the power of habit and learned behaviour. Just make sure to have a new behaviour to replace it with, and that the team itself develops this, so all have the right ownership.

We also tried to release early to a few customers in the beginning, and I was suprised to see the enthusiasm and willingness to receive software before we "officially" had released it.

I have also fought (and won) against internal release-departments accusing us for being irresponsible. Fortunately, we flew under the radar for some time so that our practice of releasing often was well developed before the other departments attacked us.

4: Be aware that it is no free lunch
I learned this: there are lots of reasons we do have this long release cycles today. In order to get to short release cycles, those reasons need to be dealt with. And this is not so fun. Just hard work. You need to be patient and remember your goal and the pain you had with your long relase cycles. Someone in the team should have the role to keep the goal sparkling in front of the team, and remind them of the pain and gain relevant to your team's efforts.

Good Luck and good summer :)

I am looking forward to my tram is back on a normal 7 minute schedule, currently they run on reduced summer time tables, waiting for late running passengers, getting delayed, and making me stress getting on time in the morning.

Do not underestimate the value of team t-shirts

2014-04-28T20:50:00.003+02:00

All teams collaborate with people that are not regular team members. They are more peripheral to the team, and the more peripheral they are the more chance of you getting in trouble related to handover.

This post is about why it is a good idea to give them your team's t-shirt. The solution is simple, low cost, low tech and high value :) It remove pain and minimize the risk of handover trouble.

Examples of "peripheral team members" I have had are people in operations, in support and in technical writing. Ordering the three of them a team t-shirt did trigger important questions:

What does it take for them to want to wear the team t-shirt?
What does it take to make it feel natural?

Picture: http://vintagetshirtsguide.co.uk

In my case the answer was simple and pretty obvious areas for improvement and involvement. Realizing that we the only focused on our day-to-day team members, forgetting about other important ones that should have had been included more.

The answer on what to improve and start doing:

invite to sprint reviews
include them regularly in the sprints, so that

they know if an area with more need for collaboration on solutions is needed
share what is going on
provide opportunity for early feedback

invite to informal lunches with the rest of the team
invite to informal coffee
invitation to team events and if the team grabs a Friday pint

Why not order team t-shirts today, and see what it takes to make your peripheral team members feel at home in it?

The power of stepping back

2014-03-20T20:28:00.002+01:00

Check out this great post written by Therese Ingebrigtsen: The power of stepping back

No estimates; hype or not?

2014-01-30T22:39:00.000+01:00

#NoEstimates seemes to be the next big thing in software development

Is it because

estimates are lies and estimation waste ?

-hey: wait a minute! I have seen value in the estimation process. This post shows the difference.

The first thing to figure out is: Why do we estimate in our team? Is it due to lack of trust, and the urge to micro manage and illusion of control, not focusing on value? in that case, maybe solving the underlying issues should be the number one priority :) just tossing away estimation will not solve any of these more severe issues.

On the other side; estimations might be for the internal use in the team. An estimate is a solid number, it is something that all team members can relate to, and figure out if the team has roughly the same understanding of

the problem
and solution,
what is out of scope,
what is needed,
what is nice to have,
what is over-engineering,
what are the risks involved,
what dependencies do we have,
what test coverage and state is in this part of the code,
how familiar are the team members with the code, domain and goal.

In other words: Estimation can be used as a means for communication within the team.

And: Only a limited number of software development challenges has a fixed scope. To discuss in the team what is the smart thing to do is a positive effect of valuable estimation.

The impartant question is this: Does estimation give you true value? If not, see if you have more severe underlying issues to deal with and get rid of your estimation process.

How to master the power of «No»

2014-01-10T09:13:00.002+01:00

It is easier to say yes than to say no. But remember:

Saying "No" is not having a bad attitude. Saying "No" is making a choice.

Every good software project has some people that are great at making choices

This is how to do it:

I often find myself talking with business people. And usually they want everything in the whole world (at once): they want all the functionality you can think of, there should of course be no bugs or downtime in the system, and they want it all as soon as possible! This is especially true at the start of any project, or early in the release cycle.

Delivering software boils down to the ability to say no to some really appealing features. These features will not make it into the next release –a harsh truth. And we leave this out in order to secure and deliver what is even more important.

Sounds simple, but it is hard in real life!

Why is it hard to say no?

You feel better if you say yes –in the short term. In the long term you will need to handle to much, and you will see some of your things slip
You make the requester happy –in the short term

What is the art of saying no?

Ignore the instinct to get the rush of reward when you say yes. Think of the implications:

Reprioritization is always possible :) It is all about doing the right stuff first, and not fall into the trap of scope creep
What stuff will need to slip?
What will be the implications for the customers, the organization, the employees, the short term and the longer term?
What is most important?
Do not bluntly say “no”. Start with your purpose (your shared goal), what options you have and implications.
Ask back: what is more important?
And a really helpful question: is this a showstopper?

After this exercise, you are back on the same page on what is most important and how to move on. You are helping each other to focus on the right stuff and you have the right amount of work to keep the flow. This is a great place to be!

"No" means "Yes" to something else!

· No to random interruptions scope creep

· Yes to the right focus

· Yes to flow

· Yes to shorter releases

· Yes to fewer bugs

· Yes to reprioritization

· Yes to take something else out

photo attribution

Handling a 60% contributor

2013-12-06T09:28:00.001+01:00

Photo: José Manuel Suárez

A 60% contributor is a person that is not contributing to his or her best abilities. This has a big impact on any team, but most importantly, it is a bad situation for the person himself/herself. Handling this type of situation is maybe the most important part of the job when leading a team.

The situation is both common, difficult and important to solve. I will share some thoughts on "how to" in this post.

It is a sensitive topic, so I will spend some lines introducing why this is so important, common and difficult.

Important: In a situation where a person is underperforming, this has a big impact on the rest of the team in regards to motivation, trust and ability to deliver. In the end, this also affect the ability to fulfil the organization's purpose and to deliver customer value. The most important aspect is the one of the individual that is underperforming: I believe that all people want to live their lives to their full potential, and work is an important part of life. This situation is therefore one that has no winner: neither the environment nor the individual. It is a leadership responsibility to address this as quickly as possible: Habits, also bad ones, grow fast, and there is a chance of getting stuck in the mud.

Common: During a lifetime, most people will experience problems either personal or at work. This could be anything on a range from lack of initiative to serious medical conditions. It can be physical, psychological, legal, addictions to gaming/drugs/alcohol, issues in close relationships, or at work: conflicts, lack of motivation, stagnation, wrong position/environment or company. It could also be nothing serious at all: just ignorance of the impact of one's own behavior.

Difficult: Each situation is unique; the manager and the employees are different, the history, relationships and context vary in each situation. It is also much nicer to bring good news. Handling tough situations are more demanding.

Each of these situations are unique, still some takeaways are generic:

Picture: momentum.se

1: Prepare

Communicate the problem clear and concise:

To avoid uncertainty and misunderstandings: use solid situations that you have experienced
If you are vague, this will only lead to misunderstandings and does not make a solid foundation to find the right solution, it even might feel like the Spanish inquisition

Possible solutions:

Think through the boundaries and limitations that neither of you can change. Prepare to ask the employee to think through if this is something that he can live with.
Think through what you would like to achieve (first meeting, follow up/next steps)
Look up any supporting services that your company can offer (medical, legal, coaching, psychologists etc)

Prepare to listen:

Prepare yourself mentally that all these thoughts are just a preparation: the key to any solution is in the hands of the employee: there are several aspects that you do not know -or solutions that you have not evaluated
Prepare yourself to listen actively

Key focus of the meeting:

What is the topic (max 3-4 bullet points)

As important: How to handle not related issues that may come up (you can use a "parking lot" for issues not related to the key focus area. Parking lot items must be dealt with in a separate track)

Plan to have the meeting early in the week

so that you are available to clarify or follow up

Find the right words:

If you are more experienced, you can think of difficult situations like this, where you handled it well to the best for the individual, the team and the company.
If you are not as experienced, you could

get help from HR
practice (role play with a colleague), try to have both the role as yourself and as the employee, and see the effect different approaches has. Find words that is best aligned with your intention
practice alone: talk to a chair or a mirror

Write down a summary (pretend it is after the meeting). Did it capture what you wanted? Did you focus on things not related to the focus area, which you should not have spent time on?

Photo: Richard Ling

2: During the meeting

Introduction
You need to get the scene right: find the balance of being honest and direct on one side, and to create an environment for dialogue on the other.

You need to spend enough time on finding a common ground where you both see what is the challenge, and at the same time emphasize more that we now start working together to find a solution. I have good experience emphasizing my good intentions for the person and for the team, and by this avoiding to bring out defense mechanisms.

solid examples/your observations
you want find a solution/how can you help/how can you work together on finding a solution

Know your responsibilities
As a leader, I have a responsibility of the work environment and things at work -at the same time, the leader does not need to know all the details on employee's personal issues. In situations where the employee is going through a tough time, he might not evaluate clearly if the details revealed might feel awkward for him afterwards. It is a good idea to say that you do not have the expertise on the matter, and offer the contact details to any professional aid the organization offer.

Main part of the meeting
The best solutions are the ones that comes from the employee. To facilitate in order to get to this is the main contribution from the leader. There are several solutions:

temporary arrangements to help out for a difficult period in the employee's life, if that is the case
find a solution to get the motivation back, if that is the issue
sometimes change of environment could be a good solution

End
End the meeting by a summarizing what have been discussed and next steps.
If something needs to be communicated to the rest of the team, agree on what that should be.
It can be a good idea to send out a summary of the meeting afterwards.

Good luck!

Picture: favim.com

Handover: "us" and "they"

2013-11-15T09:33:00.002+01:00

In October, I got this question: “Can you help us to make our hand over process work?"

Interesting question!

Many agile-religious-people will automatically answer that there should not have been a hand over process in the first place. I think there is no such thing as "should not" in IT or in organisations in general. There are many very valid reasons why things evolve into what they are, and most organisations do have some form of hand-over at some level. The challenge is therefore; what to do within this scope?

Interesting topic!!

This organisation have looked at what is the root cause of this situation in the first place:

Optimisation for silos; this have ensured high quality of technical expertise, but also not optimising for the whole value chain

The needs of the customers have been primary focus (very important!) now the focus needs to be on the longer term and market transitions as well (also important!)

Then the organisation looked at next steps:

Acknowledgement of situation

Management decision making for long term solution (including some reprioritisation)
Communicate the target picture

Involvement

Firefighting: Add people with great people skills that can fix things between departments and make people talk to each other, and just make things happen

Start working on the long term solution

Being part of this now, make me reflect on the whole "us" and "they" as a topic. And I do not think there is one single organisation completely without this challenge in one form or another. The big question is; how to deal with it?

I remember back in 2003, when I was fresh out of university with my masters degree, and got my first job. The company I worked for had recently re-organised from service-centric units to be divided into three departments: development, maintenance and operations.

We believed documentation to be the main API between the development and the maintenance parts of the organisation. To make software from development/projects work in production, the maintenance department only needed to list specific requirements to them –and perform audits.

This created an optimised environment for both projects and maintenance, however we also got some frustration based on the "us" and "them" feeling:

Frustration in the projects: somebody from the outside (the maintenance department) came in and disrupted the flow they were in. Lots of the requirements were way out of scope (not part of the contract) and presented in a not so collaborative manner

Frustration in the maintenance department: why did not the projects take into account how the systems were to work in the real life (real servers, real security, real logging, real installation files that actually work at night in the short and few hours of downtime the SLA could allow)

However, we also had some great people on board, that helped us remember that we were in the same boat:

I worked with a great project manager who repeated her mantra; “We have a shared goal here, for our customers and for our company. How can we make this work together?” This is a great take-away, and I have brought it with me and thought of it every day since. This learned us to see that we were part of the same problem and the same solution.

How to change the “us” and “they” mentality is only possible by working together. Working in different departments might work only if:

the managers are well aligned and share the same goals.

people from all departments are included in the project work during on a regular basis, at least weekly

people from all departments are informed, before it is strictly necessary, and kept in the information loop.

I do not think it is possible to over-share! invite to reviews, send out summary e-mails, drop by for coffee, have lunch together

people from all departments are invited to parties, kick off and other events

do not underestimate the importance of team t-shirts :)

A great exercise is to think this through on a regular basis:

Where in my organisation do we have "us" and "them" challenge?
What can I do to improve the "we-are-in-the-same-boat"-spirit?

Presentation skills -and how to improve

2013-11-10T09:55:00.001+01:00

Last week I did a talk at Smidig2013, and I did my best to use the presentation skills I learned earlier this year in a practical training class. You can find the talk here (in Norwegian). In this post I will summarize my notes from the presentation skills class:

1) Body language:

a) Standing still:

Stay still and firm when you talk. Be grounded on the floor.

I had a tendency to sway, both in hips and in knees. In the presentation I held last week, you see that I do this a little bit in the beginning, then remembering to stand still.

b) Moving around:

It is great to use the whole floor, do this: talk, move, talk. This means do not talk when you move, and it is ok to move and turn your back to the audience, but do pause the talking when you do this.

I have a tendency to much more swaying when I move, so for me, it is more important to focus on a then on this.

c) Arms

do not touch yourself (not in the face or anywhere else.)
you may have your arm(s) straight down beside you
or you may use your hands to gesticulate –not in front of you, the best is using large movements out to the side (feels wired, but looks great, use video and record yourself and you will be convinced)

For me, I have focused on the first one of this, I am aware of the last one, but think this is hard. Most of my gesticulation is in front of me.

d) Words

Skip all words that do not have a meaning. Words like “ehm”, “sure”, “right”, “like” and so on. It is much better to pause and to have just silence. It feels strange, but sounds great!

After practising this and recording myself, I have been aware that silence is definitely my friend. When I need to think, it feels like minutes, but in reality, it only takes seconds. A pause only makes the content standing out.

2) Content

When all the rest is in place, off course content is the most important part of the presentation.

a) Introduction part one

(10-30 seconds) Get on the same page with the audience, let the audience know that you know the context and domain, and get each and one of them to buy in to the idea of you being able to contribute in the area of topic.

For me this was an eye-opener. Before I attended this class, I had the impression that it was smart to present any controversial ideas or summarise the whole point of the presentation in the introduction. Big mistake!

b) Introduction part two

(10-30 seconds) Let the audience know what they can expect during the presentation, i.e.: “in this presentation I will start by examining the three different options, and summarize pros and cons. I will also present the recommended solution and how to bring this forward”

I did not know how important it is to let the audience get a sense of what to expect, and this being key to engage the audience during the presentation, making them curios.

c) The PowerPoint

Who are the slides for? –It is not supposed to be for the presenter J The audience are only capable of either reading or listening –not both at the same time.

If it is important that the slides capture content for people not present (it is going to be sent out) consider making two separate slide decks or provide the extra content in the “notes” section.

I have fallen in love with pictures on my slides only. This is also what I used in my presentation at Smidig 2013. These are three slides from that slide deck:

d) The end

Summarize your point and present next steps or actions that the audence should take.

How to get rid of forced ranking; story from the trenches

2013-10-25T09:14:00.003+02:00

All companies have boundaries; things that you just have to live with. Values are essential in this context; you use them to know when to fight, what to accept and when to move on.

This is a true story of getting rid of Forced Ranking: A group of colleagues challenged our 70.000-employee-company-boundaries based on our values, the values of the team, and the values of the company:

Forced ranking
this is also known as vitality curve, forced ranking, forced distribution, rank and yank, and stack ranking.

The concept was made by Jack Welsh in the 80's, and the point is to divide and label employees into three groups: the 20 % top performers (that should be rewarded with bonuses and stocks), the 70% majority, the bottom 10% (that should leave the company).

I do not see anything positive about labelling all employees with grades like this. In a high performing team it does not make sense to label 70% as average!!! Who wants a team where 70% are dis-satisfied?

This labelling system break trust between leaders and employees, between peers, and create economic incentives to be in a weaker team. It prevents collaboration, learning and teamwork.

The system is also linked to goals and this create a system of goals that everyone make sure they meet ( = weak goals and not revealing the company's true potential). If the achievement of goals is linked to compensation, the intrinsic motivation is replaced with money motivation, the extraordinary work is replaced with average performance that is aligned 100% to the plan rather than aligning to adapting to constant change and stretching for the extraordinary.

Ok, so what to do with this?

1) research
I knew in my heart that forced ranking was wrong, but had to put my thoughts into more precise wording. I started to write down my thoughts and searched to find what others have said and done in the matter. I found some great material:

Edward Demming's book Out of the Crisis
Daniel Pink's book called Drive, here is a ted talk and a RSA animate of it

2) reality check
I also talked to my peers (other team leaders and project managers). This was disappointing, because half of the people I talked to did not see the problem at all. One person with 50 employees and several managers reporting to him said to me: "if this was a problem I would have known".

But (of course) I did not give up, and I focused on the ones that did see the problem and could help in finding a solution.

3) proposed solution
I worked close with two peers, and together we made a three-slides-deck describing the problem, effects and possible solutions.

4) escalation
We presented this to our site manager, and he accepted it and scheduled a meeting with our General Manager and Senior Vice President.

5) case closed?
Our GM and Senior VP joined forces with their HR representative, and we were able to get rid of the whole rating system!

Hurray!!!

So, when you meet a boundary that you just think is important enough to fight; I encourage you to do something about it. It is in your company's best interest. Use your values as a guideline :)

Have a nice weekend!
Eira

Change: story from the trenches

2013-10-16T08:01:00.001+02:00

Marc Garlic/Science photo

This blog talks about three lessons I have learned about the change process. The examples are from when I introduced Scrum into an existing team.

Change is so interesting because it happens all the time, and this is true also for the work place: The last three years this is some of the change I have experienced:

being project manager for a team that changed from developing a soft client (sales numbers of 1,5 million clients!) to develop sw for hardware
three sw teams being merged into one large group of over 80 people
lots of changes in the culture and organisation due to the acquisition
not to mention change in sales processes and marketplace

All this -and more -in just 3 years!

Forestwander Nature Photography upload bot

I think change is interesting and fun, it can absolutely form the basis for new opportunities and growth. Both on a personal, team and organisational level.

So, let's go back to the "introducing Scrum into an existing team" story:

1) Team involvement

How did the idea of implementing Scrum come up in the first place? It was based on some challenges that (almost) all of the team members agreed was painful. The situation was long release cycles and huge instability in the code base during this development cycle. It was hard to get the code stable before release. And it required lots of time -both hours and calendar time to get to the point of having the overview of bugs -both the number and scope of those blocking the release. (= big risk!!)

However, there was no agreement in the team on how to solve these problems. To see if Scrum could be a solution, all the team members attended a scrum master two day class and we looked into benefits, pitfalls, principles, techniques and vocabulary. We decided to get "all in" for 6 months, and then evaluate if we needed to do major changes (during this six months, we did make adjustments based on retrospectives, but only within the principles of Scrum). Like a Chinese saying: First learn the rules, then break them.

I can imagine several other variations of this where the team buys in on the principles of Scrum, while the business side and management parts of the organisations might not. In that case, I believe the part of using some of the existing challenges as a starting point for change is still a valid case. Then being smart and deliver value on a frequent basis and build trust, and take it from there.

2) Do NOT put up the "here comes a big change" sign

My mistake in this process was to do exactly this: I held up the sign of change, emphasising the parts that was the "change" bit in how we did development.

Don't do this!
Picture: denstad.com

I soon found that a much better approach was to build on the smart things and good principles that was already implemented by the team and being a part of the team culture. I did this by pointing to the evolution part, building gradually on the great things that was there already, not mentioning "change" at all.

One example is the short feedback loop. This team had the best culture on writing automatic tests, not one commit during the last year had been committed without tests. To release to a friendly internal gang (we called them "the gang of five"), was however not something that the team wanted to do at all.

Rather than emphasising that releasing every sprint to the gang of five as a new idea, it was much more successful to get people on board by answering the question: "We have done a great job of getting a short feedback loop into our continuous integration system. How could we involve "customers" into a short feedback loop as well?"

Evolution brings out less resistance than revolution

3) Focus on the intentions behind, empowered teams find solutions
Each Scrum team decided if/how to do estimations. The group as a whole did not do estimations before we tried Scrum, and there was different opinions in the group whether or not this was something they wanted.

The intention of release planning, backlog refinement and estimations are for the team to get on the same page of what is this project all about. What is the order of doing things? What do we believe make sense in order of milestones? What options do we have to make different choices; could we do less on one part in order to get something else in? (I do not believe customer value is the only aspect to consider when prioritising the backlog, but also risk, a mix of smaller and bigger epics/user stories/tasks, motivation/competency in the team, and if the user story is understood)

On the question on "do we need estimations or not?" we rather asked other questions:
How can we get on the same page on what the different user stories is all about? How can we as a team get to understand intentions of user stories and get to the "why" part of them? How does the team have the same understanding of the acceptance criteria?
Could using numbers or size help us in explaining to each other what we are thinking? Here there was different answers in different teams, and we tried out different solutions (no estimates, t-shirt sizes, ideal days, variations of relative numbers).

One team wanted to discuss the topic (it started as quite a heated discussion by the coffee machine). This is what I wrote in the invite to the estimation-discussion-meeting:

Estimates are lies, and estimation is waste
-Unknown

Plans are nothing, planning is everything

-Eisenhower

We ended up doing estimates not for the estimates own sake, we did estimates to get on the same page in the team.

One of the release plans we made in the process
of getting on the same page (3 scrum teams, 25 people)
The picture is taken mid release, this is capturing finished
work and guesstimates.

More info on change:
Kotter international: 8 steps of change
Toyota kata

How to control everything in your project!

2013-10-11T15:08:00.003+02:00

Guess what!? I have discovered a process that let you control not only timescale, budget and quality but also scope, risk and produced benefits!

During the initial project stage, the business side will know all these aspects and make the well-informed decision to start the project or not.

And this process is called Prince2

By now, I guess that you have realized that I am not serious.

I find it a bit strange that people buy into this illusion, that it is possible to know all these aspects up front.

On the other hand, I find too many agile practitioners being too fundamentalists in their approach to agile. We have to take into consideration that organisations do have some boundaries that they need to adhere to. Not everyone can or will go all in from day one.

I think one solution is for the Prince2 fanatics to emphasize the “management by stages” which equals “embrace uncertainty”.

I also think Agile fanatics should be less fanatic in their communication, because what is the result of fanatic communication? People that already think the same way as you; they will nod, whereas the rest will dismiss all you say.

Prince2 provides a common vocabulary that is great when communicating, and the agile community provides the values and methodology that we need to deliver (the right) software.

I think we can use both to get where we want. We just need to

be practical about implementing Prince2

not getting bureaucratic

emphasize the flexibility that is built in

implement agile and lean into this super-thin framework

After all: this is what we want:

“Speed, Quality & Low Cost are Fully Compatible
Companies that compete on the basis of speed have a big cost advantage, deliver superior quality, and are more attuned to their customers' needs.”

-Poppendieck

Have a nice weekend!

Cheers,

Eira

-Prince2 certified, agile at heart

The crazy agile project family

2013-10-08T10:40:00.001+02:00

Two months back my husband and I wanted to fix some major issues in our everyday life, experiencing too much stress and even passing it on to our kids age 4 and 7. We did not find any solution, and discussed back and forth. Then suddenly, we had a breakthrough:

Me: What would you have done at work? If you joined a project as a leader of a team, with the same level of stress, what would you do?

Him: I would not take on as much in the sprint

Me: Ok, what else?

Him: I would reduce the product backlog

Me: Ok, great. How?

Him: By visualizing the bare minimum on a board, and use that as a starting point

Me: Great idea! Let's do it: not take on as much each week, reduce the backlog and get a board

Then I thought: how can we hide that board from our friends and family visiting us??
My second thought: You are old enough to live the way you want, aren’t you?

This is our scrum board

At work one of my best capabilities is to focus on what is necessary, focus on the most important stuff. I usually find myself visualizing to others (stakeholders, team, product management) the consequences and opportunities that we have in the project, getting everyone on the same page: prioritization is key, and it is not in our interest to hide our head in the sand pretending we are able to do everything.

At home, I found it much harder to leave out what I thought I needed! I just need to remember what I usually say (and do) at work: saying no to one thing is to say yes to something else! Lots of great stuff happens when we say no.

Now we are running Scrum for kids - agile family - lean living

True ownership (notice the drawings)

Short disclaimer: we are not running true Scrum, but the potential is there: weekly plannings, weekly retrospectives, I think we can get even more of this incorporated into our family life. (and become even more crazy!)

getting more lean!

Mer smidig? -del 3: Tillit og ledelse

2013-10-04T15:38:00.000+02:00

Alle team og bedrifter har rammer å forholde seg til. Vi begynner nå å vite mye om smidig, lean og ikke mist scrum -men noen lever med rammer som gjør det vanskelig å få ut de effektene som er mulige. Her tenker jeg å skrive om ett aspekt som er helt vesentlig i smidig, og som alle, uansett ståsted, erfaring med smidig eller hvilke rammer som gjelder, vil ha mye å hente på å jobbe med!

Temaet er Tillit og ledelse

Tillit kan man som kjent ikke kreve, det er noe en får. Spørsmålet blir hvordan. I prosjekthverdagen tenker jeg at det to helt grunnleggende ting som gjelder for å få tillit i organisasjonen, det er leveranser og kommunikasjon.

Hva kan du gjøre for å levere hyppigere og mer synlig? (se her for eget innlegg om temaet)

Hva kan du gjøre for å bli bedre på kommunikasjon? Hva er viktig for dine stakeholdere? Kan de inviteres på review? Kan du sende ut en kort oppsummering på mail? kan du oppsøke kaffemaskinen der de er? kan du ringe dem? har du prøvd video? Vet du hva de er opptatt av? er du god nok på å få frem poengene kort og konsist, og ikke minst fengende?

Tillit på prosjektnivå:
Min erfaring er at når prosjektet klarer å levere verdi hyppig, og kommunisere godt, da får man tillit og ikke minst handlingsrom til å gjøre skritt i riktig retning som igjen gjør en bedre i stand til å levere bedre og så har man en super spiral gående! Det er lettere å få aksept for å ha et tydelig fokus og scope når omgivelsene føler trygghet på at dette er noe som blir levert.

Tillit på individnivå:
Dette er relevant også på individnivå: en ting er å være god, en annen viktig ting er faktisk å jobbe hardt. Snakker ikke om å være på kontoret sent og tidlig og slite seg helt ut, men snakker heller ikke om å komme sent, gå tidlig og ta halve fredagen fri. Trening (holde seg up to date og øve), hygienefaktorer (at man tar seg av koden), og innsats (tiden som legges ned) skiller de som er medium til de som er virkelig gode (og som holder seg gode). En forutsetning for et high performing team er når hver enkelt er seg bevisst dette og sin påvirkning på de andre.

Tillit i et prosjekt er altså både mellom prosjektdeltakere og ledelse, mellom prosjektmedlemmene og mellom prosjektet og organisasjonen. Og dette må fungere på kryss og tvers :)

Hva med ledelse i prosjektet?

Empowerment av teamet, det er teamet som bestemmer

hva som skal være med i sprinten,
hvilke team som jobber med hvilke oppgaver,
hvordan oppgavene skal gjøres,
tidsplaner som er realistiske og som teamet kan tro på
det brukes ikke estimering for å holde enkelpersoner/team "accountable" (estimering: kun som verktøy for kommunikasjon, synlighet, risikohåndtering og prioriteringer)

Ta med teamet på reisen for å forstå visjon, hensikt, rammer og mål for prosjektet

alle får et ektefølt personlig eierskap

Vær en spydspiss for kommunikasjon innad i teamet og utover til eksterne

Reflekter over tillit på en jevnlig basis, hvor fungerer det bra, hvor må det jobbes med? (f.eks tillit mellom enkeltpersoner i teamet, dette må også håndteres)

Tillit: et spennende teama; og som med mye annet begynner det med leveranser og refleksjon :)

Mer smidig? del 2: Samarbeid i kryssfunksjonelle team

2013-09-24T12:57:00.000+02:00

Vil du bli mer smidig? da er det mange steder man kan starte. Helt sentralt står det å jobbe i kryssfunksjonelle team. Dette innlegget tar for seg dette viktige aspektet

For å lage programvare er det mange ulike faggrupper involvert. Jeg tror alle både bedrifter og team, uansett ståsted i forhold til systemutviklingsmetodikk, kan ha mye å hente på å jobbe mer kryssfunksjonelt. Det gir:

bedre optimalisering for hele prosessen "from concept to cash"
mindre work-in-progress
mindre hand-over
en bedre forståelse for hva som skal leveres

Dette innlegge handler om hvorfor og hvordan :)

1: Bedre optimalisering av hele prosessen "from concept to cash"
dvs optimalisering for helheten -ikke per fagfelt

Hvis hver faggruppe sitter for seg selv, og leverer for seg selv, blir resultatet at hver faggruppe optimaliserer for sitt fagfelt. Det vi ønsker oss derimot er å optimalisere for at helheten skal løses på en god måte: hele produktet slik som kunden opplever det, og ikke bare en isolert bit. Da sier det seg nesten selv at en optimalisering per fagfelt er en optimalisering på et for lavt nivå.

Bildet er lånt av Maree Reveley (aka Somerslea)

Løsningen er at folk fra ulike fagdisipliner sitter i kryssfunksjonelle team.Konkret betyr dette at designere, testere, utviklere, database-eksperter og ikke minst forretningssiden/produkteksperter/PM (product management) eller product owner jobber sammen.

Det er en del fagpersoner som synes det er mer effektivt å jobbe sammen med de andre fra sitt eget fagfelt heller enn i kryssfunksjonelle team, og det er ganske naturlig når de tar på seg brillene "mitt perspektiv". Det er viktig å ta på seg "vårt perspektiv" i stedet, hvor "vår" er bedriften, kunden, produktet.

Effektivitet er også et ineressant ord. På engelsk kan det oversettes med to ord som betyr forskjellige ting:

effective; is sometimes used in a quantitative way, "being very effective or not very effective". However, neither effectiveness, nor effectively, inform about the direction (positive or negative) and the comparison to a standard of the given effect

efficient; on the other hand; is the extent to which a desired effect is achieved; the ability to produce a desired amount of the desired effect, or the success in achieving a given goal

Olve Maudal har brukt analogien med vaskemaskin: effective er å trykke vaskemaskinen helt full, man presser inn den siste sokken og klemmer igjen døra; resultatet blir ikke særlig rene klær, men man får vasket utrolig mye! Efficient blir da heller å sortere ut en passe liten mengde tøy, slik at tøy, vann og såpe kan sørge for et rent og bra resultat.

Jeg tror at ledere må være en kommunikasjons-spydspiss når det gjelder viktigheten av å optimalisere på et høyere nivå enn det mange intuitivt føler som mindre effektivt.Utgangspunktet må være at dette er kunnskap som alle i teamet har. Når denne plattformen er på plass, må lederen være obs på at det kan være ferskvare, og at dette temaet er noe som må taes frem igjen.

2: Mindre work-in-progress (wip)
"Work in progress hides defects, gets obsolete, causes task switching, and delays realization of value."

-Mary Poppendieck

Dette er en utrolig god oppsummering av hvorfor vi ikke ønsker mye work in progress.

Bildet er lånt av: nrksuper.no

Hvordan redusere mengde work in progress?

Først og fremst ha alle de fagpersonene som skal til for å utvikle noe i teamet
Sørge for redundans i teamet (dvs ikke bare èn person fra hvert fagfelt)
Hindre unødvendige forstyrrelser
Ha fokus på å redusere wip (ledelse)

Et kryssfunksjonelt team består av de fagpersonene som skal til for å utvikle noe. Dette gjør at teamet kan bli ferdige uten å være avhengig av andre eller vente på andre. Da kan kan ballene landes en etter en :)

Når vi har de fagpersonene som skal til, er det viktig å sikre redundans i teamet. Det vil si at det ikke er bare èn person fra hver faggruppe med. Dette kan være en motsetning til avsnittet over, for teamene kan ikke bli for store heller (ideell størrelse er 7+-2). Det opplagte er at hver person kan gjøre mer enn bare en type oppgave. Men her kommer det an på hvor spesialisert oppgavene er: det er forskjell på en doktor i signalbehandling og en mer generell utvikler.

Uansett hvordan temet blir satt sammen til slutt, er det viktig å hindre unødvendige forstyrrelser. Korte sprinter (på 2 uker) er et bra hjelpemiddel her. Når det kommer en entusiastisk person inn fra sidelinjen og vil at vi bare skal se litt på denne ene tingen her, så er det lett å spørre; vil det ha noen betydning om dette venter til neste sprint? Svaret er stort sett at det er ok, så husk dette viktige spørsmålet!

Det er lettere å si ja enn nei. Men å si nei til noe, er å si ja!! til noe annet. Jeg fokuserer på at det er lurt å si nei til unødvendige forstyrrelser.

Jeg tror også dette med at det er lett å si ja, er en av årsakene til at man ender opp med mye wip. Og det går ikke over av seg selv :) bevissthet, fokus og teknikker må til for å redusere wip. Her må det en champion, en leder, en smidig-entusiast til, en som kan gå i bresjen og utøve smidig ledelse :) En effektiv teknikk er å sette en grense på antall oppgaver på work in progress (som i Kanban, og kan også gjerne brukes i Scrum).

bildet er lånt av www.modalisa-technology.com

3: Mindre handover; mer kommunikasjon
Pri èn er å få de man trenger til å lage systemet til å jobbe kryssfunksjonelt, men hva med alle de andre som man også trenger for at løsningen skal bli en suksess? De som jobber i andre deler av organisasjonen, som ikke jobber med prosjektet i det daglige, som er mer relevante i ulike faser av prosjektet?

Realiteten er oftest at vi ikke får alle de forskjellige menneskene vi trenger i teamet.(Hw og Sw sitter kanskje ikke i samme team, de som skal supportere, drifte og forvalte løsningen sitter kanskje i en annen del av organisasjonen, hva med marked og salg? hva med selve produksjonssettingen og de som jobber med det? hva med miljø og infrastruktur.... listen kan være lang...)

Bildet er lånt fra: www.goodwilltraining.co.uk

Så, hva kan vi gjøre med dette?

Behandle alle som trengs for å få levert noe ut til kunden som en del av teamet. Bygg relasjoner! og forståelse for hva dere skal oppnå
Gjør det du kan for at de du gjerne skulle hatt med på teamet føler seg som en del av teamet (ikke oss/dem, men vi)

Ta de med på team-eventer, inviter til review, ta formelle og uformelle møter, del ut team-t-skjorter.
Ta de med i loopen før du tror du trenger det.
Spis lunsj sammen hele teamet, og inviter dem med.

4: En bedre forståelse for hva som skal leveres
"There is nothing so useless as doing efficiently that which should not be done at all."

– Peter Drucker

Godt sagt!!

Heldigvis er det stadig en bedre og bedre forståelse i bransjen for at den viktige forretningssiden må være en del av et systemutviklingsteam til daglig, og ikke bare levere en kravspesifikasjon up front! Dette er et viktig fremskritt!!

Likevel finnes det stadig rom for forbedring. Jeg tror de fleste kjenner seg igjen i at de skulle ønske at forretningssiden var mer til stede og mer involvert. En produkteier som jobber med teamet daglig kan være løsningen. Og hvem kan brukes i denne rollen? I overgangen fra mer tradisjonell vannfallsutvikling til mer smidig metodikk, kan den tradisjonelle prosjektlederen ofte være en god product owner.

Og hva gjør en produkteier? Teamet trenger en som kan forankre visjonen, det strategiske, hva vi skal oppnå/hvilke utfordringer er det som skal løses og for hvem (personas, kundegruppe, markedssegment).

Produkteieren blir en god hjelp for teamet i daglige gjennom:

gode kontakter internt: mot spesialkompetanse som trengs fra forretningssiden.Det kan være at en som er product owner til daglig henter inn for eksempel en aktuar som skal få enkelte beregninger korrekte.

nærhet til kunden: Produkteieren bør ta med seg noen fra teamet og besøke kunder og/eller potensielle kunder for å se med egne øyne hva som gjelder (ta med videokamera, det er lett å ikke få med seg alle detaljene, og det er effektivt å vise til andre)

metodikk: det trjedje viktige perspektivet som produkteiere representerer er en veldig god forståelse av hva som skal til for å utvikle systemer, prøve det ut og justere kursen. En bra bok for å få denne forståelsen er The Lean Startup.

Nok av spennende utfordringer å ta tak i, ikke sant :)

Spørsmålet blir så: Hvor har du mest å hente?


bildet er lånt fra: lewiscollard.com

Mer smidig? del 1: Kort feedback loop

2013-09-20T12:43:00.003+02:00

Vil du bli mer smidig? da er det mange steder man kan starte. Helt sentralt står det å ha en så kort feedback loop som mulig:

Kort feedback loop vil jeg påstå at faller seg veldig naturlig for ingeniører! Det er ikke vanskelig å få med seg de flinke fagpersonene som faktisk utvikler systemer på dette, her er det de som går foran og som har gjort det lenge. Selv jeg som ikke lærte test drevet utvikling på skolen, fikk fra første stund tilbakemeldinger fra kompilatoren. Og vi ønsker oss tilbakemeldinger fra testene våre så raskt som mulig. Enhetstester, integrasjonstester og automatiserte funksjonelle tester. Disse kjøres så ofte vi kan, og vi jobber for at vi nettopp kan gjøre dette så tidlig som overhodet mulig.

Tommel opp!

Font Awesome by Dave Gandy

En kort feedback loop, hva betyr egentlig det? Jo det betyr rett og slett at vi ser resultatet av det vi gjør raskt! Og forretningssiden er ofte utolmodige for å få ut sine ideer til sluttbrukerne, sånn sett er det heller ikke vanskelig å selge inn ideen til forretningssiden om at vi skal levere verdi til ekte kunder så raskt som overhode mulig.

Flere tomler opp!!

Font Awesome by Dave Gandy

Men: Mange ingeniører og forretningsfolk krymper seg likevel når de tenker på å release noe tidlig (når de får tenkt litt på det). For, det er jo ikke ferdig.

Jeg vil påstå at de aller fleste vil mye å tjene på å virkelig jobbe med å få en kortere feedback loop og muligheter for å release til ekte kunder tidlig.

Picture: Jeff Patton

Det er nødvendig å jobbe med dette både med medarbeidere som representerer forretning og teknologi. Og hva får du for å korte ned feedback loopen? Jo du får muligheten til å treffe blink! Og ikke bare det, du treffer også rett blink!! Du får tilbakemelding på hva som virkelig fungerer og ikke, og du får en nærhet til kunden og produktet som faktisk lages som er fantastisk og veldig motiverende. Du får et fokus på de rette tingene, og det gir en enorm motivasjon og fart.

Spørsmålet er hvordan få det til: og svaret på det vil være forskjellig fra bedrift til bedrift og fra team til team. Likevel tenker jeg at dette ofte vil gjelde:

· 1: Tester: Hva gjøres i dag? Hva kan gjøres med automatiserte tester? Er det unødvendig overlapp i de automatiserte testene? Kjøres de automatiserte testene ofte nok? Kan det gjøres noe for å kjøre testene med riktige intervaller og å redusere tiden de tar å kjøre? Følger teamet med på testene? Kan teamet stole på testresultatene? Er det riktig nivå av automatisert testdekning?

Jeg har flere ganger fått spørsmålet: tar det ikke uforholdsmessig lang tid å levere et prosjekt dersom man skal lage alle de automatiserte testene?

Til dette vil jeg helt klart si "nei". (Aller helst "leverer viikke et prosjekt", men en serie av funksjonalitet ved hjelp av hyppige releaser og continous delivery, men dette blir en digresjon akkurat her).

Automatiserte tester gjør heller det motsatte: vi får mer testing og oftere testing. Dette igjen gjør oss trygge! vi vet at vi ikke brekker noe eller introduserer nye bugs eller regresjoner (ukjente side-effekter ved introduksjon av ny funksjonalitet).

Hver gang vi gjør endringer i kode som har dårlig test-dekning, da vet vi at dette er risikofylt og tar ekstra tid. Å skrive selve programmerings-koden tar ikke ekstra tid, men tiden fra vi bestemmer oss for å implementere funksjonalitet til det er klart for produksjon, det er denne tiden som blir lenger, spesielt i kalendertid. Men ikke bare i kalendertid, også i tid for avbrytelser, forstyrrelser og feilsøking i flere uker fremmover etter at endringene er gjort.

· 2: Backlog/Minimum viable product (MVP): Hva er det absoultt minste som det er mulig å få released? Det vil si det tidligste tidspunktet det kan gi bare bittelitt verdi å levere til en ekte sluttkunde? –Dette høres kanskje lett ut, men når svaret kommer, hvordan kan du skrelle bort enda mer? Og enda mer? Og enda mer? Gå gjennom hver eneste feature, og spør deg selv: er dette en showstopper? Ja eller nei? Hvis du bare skulle velge en eneste feature, hva hadde du levert da? En endeløs backlog (eller enda værre: kravspek fra tre år tilbake på tusen sider), er waste.

· 3: Releaser: Den hele verdikjeden blir først testet ut når vi releaser.

Mitt store forbilde er Mary Poppendieck, hennes bøker er vel verdt å lese, og jeg har også vært så heldig at jeg har truffet henne flere ganger. Hun har et utrolig godt bilde på hva som skjer ved kort feedback loop: Hvis du ser for deg at prosjektet er et vann eller en elv, så vil det under overflaten være gjemt mye som man ikke ser. Når man releaser ofte senker man vannstanden, slik at problemene kommer til syne, akkurat som steiner under vannet. Jo mer vann man fjerner, jo mer kommer tilsyne av utfordringer, og man kan håndtere dem og skape bedre flyt. (En variant av "å feie noe under teppet")

Bildet er lånt av fotografen: http://kjiver.no/index.htm

Og hvis sluttkunden ikke er interessert i å få en release hver time, hvem er det som er interessert? Begynn med å release til dem! Få en krets av «early adoptors» først internt, deretter eksternt. Kjør alpha og beta programmer. Og hvis det finnes definisjoner internt med kriterier som må oppfylles for å kunne gjøre dette, så finn på noe lurt: kall det for pre-Alpha og pre-Beta. I slike termer kan du legge det du vil (og det skal føles litt ukomfortabelt for alle i prosjektet, dere venner dere til det :)

I realiteten krever dette en hel del. Hvorfor?

Når du senker vannstanden får du rett i fleisen alle de tingene som ikke fungerer. Og alle de tingene som fungerer dårlig. Og alle de tingene som ikke er på plass som burde vært det. Heldigvis får du også alle de tingene som du ikke visste om, som du får mulighet til å gjøre noe med på et veldig tidlig tidspunkt. Alle de andre vanskelige, kjedelige tingene som faktisk var kjent, men ikke løst, var uløste for en grunn og disse årsakene er ikke borte.

På toppen av det hele må prosjektet levere også, ikke bare lage verktøy og fikse tester eller gjøre andre løft for hygienefaktoren. Og det som må til for å kunne release ofte krever en god del å få på plass. Og forretningssiden og alle som har et eierskap til sluttproduktet er ikke så interessert i å forsinke prosjektet, kanskje ønsker dere å være tidlig ute med noe nytt og spennende, eller dere må ta igjen konkurrenter, dere må kapre nye kunder, eller levere det de eksisterende kundene krever. Og utviklerne, de har noen skjelett i skapet som de ikke gleder seg til å ta ut....

Så da er det bare å innse at «Rom ikke ble bygget på en dag»:

Bildet er lånt fra: commons.wikimedia.org

Ta de letteste tingene/viktigste først, lage noen milepæler som er realistiske å nå, og ta det videre derfra. Men vær klar over at ingenting skjer av seg selv. Det er som med all endringsledelse. Det krever minst en som driver prosessen, denne må ha en kritisk masse av supportere, teamet eller organisasjonen må kjøpe ideen. Man må være på hugget, kassere inn de første seirene, og håntere alle setbacks. Og set-backsene vil komme, spesielt siden dette er laget for å synliggjøre alt som er vanskelig, utfordrende og til hinder for hyppige releaser.

Vaner må endres, og teamet (og kanskje bedriften også) må og pushe seg selv ut av komfort-sonen og det som føles som "trygt". Sannheten er at det aller tryggeste man kan gjøre er å release ofte, det gi en mulighet til å omfavne usikkerhet som allerede finnes, og som ikke lenger skyves under teppet. Det er mer komfortabelt å levere noe som er «ferdig». Men det kan man venne seg av med :)

Motivasjon – en enorm kraft!

2013-09-15T21:57:00.000+02:00

Jeg -som de fleste av oss, bruker det meste av min våkne tid på jobben. Det er så utrolig viktig å ha en jobb hvor jeg kan gi av meg selv og som gir energi.

Fotograf: Gabriel Pollard

Det er så deilig å gjøre en god jobb! Noe av det som interesserer meg mest her i verden er også hva som nettopp gjør oss motiverte, og da tenker jeg på alle rundt oss. Jeg får som mor se den ufiltrerte, rå og brutale sannheten om hva småtrollene har lyst til og ikke. På jobben er det mer tilslørt av sosiale normer.

Et topp motivert team har det ikke bare gøy, forutsetningene ligger også da mye bedre til rette for å levere fantastiske resultater! Dette tjener alle på, både økonomisk/bedriften og når det gjelder arbeidsmiljø/individet. -Så dette er noe som alle vil ha!! Heldigvis er det også noe alle kan få til!

Fordi: Motivasjon er ikke noe mysterium:

Bildet er lånt av tlth.se

Det er flere gode stemmer innenfor dette feltet som både fungerer utmerket i praksis og som er forskningsbaserte. Jeg tenker på to som sier mye av det samme: Herzberg og Daniel Pink.

Herzbergs berømte teori om hygienefaktorer og vekstfaktorer går i korthet ut på at det er en del hygienefaktorer som vil gjøre folk demotiverte dersom de ikke er tilstede eller ikke er tilstrekkelige. Eksempler på hygienefaktorer er lønn, forhold mellom medarbeider og leder, firmabil, status, fysisk arbeidsmiljø. Får du ikke en rettferdig lønn, er sjansen stor for at du blir misfornøyd. Samtidig er det viktigste poenget med hygienefaktorer at folk ikke blir mer motiverte dersom man legger til mer av dem. Mer lønn er derfor ikke det samme som mer motivasjon (hvis lønnen i utgangspunktet er fair). Så hvis det ikke gjelder å pøse på med mer av hygienefaktorene, hva skal vi gjøre da? Svaret ligger i det Hertzberg kaller vekstfaktorer.

Vekstfaktorene ligger på motsatt side av skalaen i forhold til hygienefaktorer. Dette er de virkelige driverne når det gjelder motivasjon, å kjenne entusiasme og energi rundt det man jobber med: utvikling, arbeidet i seg selv, å oppnå resultater, ansvar.

Daniel Pink har skrevet boka «Drive», og det er flere flotte videoer som oppsummerer boka. Se her og her. Dan Pink snakker om tre faktorer for motivasjon:

Autonomy: å være med og bestemme

Autonomy går nettopp ut på å enable hele organisasjonen, og at ikke enkelte ledere tar alle beslutninger. Det er det motsatte av micro-management, og det er det eneste som skalerer. Med Autonomy menes at medarbeiderne både er med på å påvirke hva som skal gjøres, dvs små og store beslutninger som tas på det lavest mulige nivået i organisasjonen, i tillegg til være med å bestemme måten vi jobber på. I Skandinavia har vi en lang og flott tradisjon for dette, som vi med rette kan være stolt av!

En metafor for å beskrive dette er et hullet og drillen: Som leder er det viktige å beskrive det vi ønsker å oppnå, et reelt behov en kunde har: for eksempel et hull, og ikke hvordan hullet skal lages: for eksempel ved hjelp av en drill.

Bildet er lånt av www.headfi.org

Bildet er lånt fra: http://commons.wikimedia.org
og fotografen er Luigi Zanasi

Mastery: mulighet til å bli bedre innenfor noe som betyr noe for en selv

Dette passer veldig bra inn i dagens samfunn, som kjennetegnes av en rivende utvikling. Hvor er vi om 50 år? Hva er viktig om 5? Hele adapsjonskurven blir kortere og kortere, noe som betyr at kontinuerlig forbedring og forandring er en forutsetning for suksess. Å lære noe nytt er like viktig for bedriften som helhet som for enkeltmennesket. Å være sulten på ny kunnskap ligger grunnleggende i alle mennesker, og det er viktig å spørre seg selv: hva skal til for å blåse på disse glørne? Hva kan jeg gjøre selv som medarbeider, og hvordan kan jeg som leder legge forholdene til rette?

Fotograf: Michele Campeotto

Purpose: være en del av noe større enn seg selv

Sist men ikke minst: Purpose. Det mest motiverende jeg og andre medarbeidere kan jobbe med er nettopp å levere noe som er en del av en større helhet. Selvsagt er ikke alle oppgaver i seg selv like morsomme, men dersom alle i bedriften har et eierskap til visjonen og det sitter i ryggmargen hvor vi skal, så er det utrolig motiverende å være med å bidra til at vi går nettopp i denne retningen!

Bildet er lånt fra Wikimedia commons

Soria Moria-bildet gir meg assosiasjoner til å kjenne visjonen, og å finne veien dit. Dette bildet viser jeg ofte når jeg jobber med teamet for å avgrense et prosjekt og få en skikkelig god felles forståelse av hva visjonen betyr for oss: hva er vår purpose.

Denne prosessen er spennende, givende, og ikke minst en forutsetning for et high performing team. De små og store beslutningene alle i teamet gjør basert på denne forståelsen er utrolig kraftfull. Jeg ser på felles eierskap av visjonen som den viktigste forutsetningen for både et high performing team og arbeidsglede!