A story of growth

My son really loves baking. From an early age, he loved hanging around me in the kitchen, eager to help. Of course, in the beginning his help was of no help to me in my baking. Then, I had three options:

• Since it took less time, I could have done everything myself
• Even if it took longer time, I could involve Peter is different tasks, having him learn the stuff.
• Combine the two strategies
  

I went for the last strategies: I involved Peter in tasks which he could learn to master and explained to him which tasks were not suitable to him and then he could only watch. Of course it took longer time and I chose bakery which weren't too complicated.

As time has progressed, so have Peter, and on Sunday, he was finally making a net value. We baked some cinnamon rolls and 3 kg of home made lasagne to a friend who is giving birth this week. Peter took care of melting the butter, taking out the forms and placing the rolls in the forms. He made his own rolls and he really helped me making the lasagne plates, including fixing the dough.

Imagine his pride when he could serve his father his very own cinnamon rolls and guess how much better he eats when he's cooked the meal. Giving responsibility is enabling confidence.

Are you accountable?

Mike Cottmeyer discusses the combining of the "traditional project manager view" and the "agile leader view" in his thought worthy blog post on accountability.

One very interesting part is when one of the team members says the following to Mike (then new to the agile mindset):

"you just get what you get when you get it."

This is of course true. In all projects it's important that the participants do their best to make the "what" as the right stuff to the right quality and that you get the most right stuff to the right quality as possible. In other words; people do their best to increase the product increment.

What Mike was really worried about was that people didn't do their best, perhaps slacking, perhaps working on other projects or just the wrong stuff.

In other words, he wasn't sure that he count on the team doing their best on his project. Why do project managers feel like this: that they cannot count on people doing their jobs? Are they evil not believing in people or are the participants not to be trusted.

Trust does not come automatically. We all know that. But in agile projects, trust is a necessity. The business people need to trust the developers knowing how to build stuff. Developers must trust that the business people tell them which problems they need solved as soon as they know themselves and that they say when they change their minds.

Managers need to trust their groups doing their jobs. Because everyone on an agile project need to be someone you can count on. That does not mean that managers should stop managing. That just mean that a good manager does not need to scare people to work and they people with a good manager work independently if he's checking on them. He's making sure that things run smoothly and that the team know what they're supposed to do.

Before going agile, make sure the trust is there and otherwise make sure to build trust in your organisation. A good start to get some ideas on the subject is of course reading Five Disfunctions of a Team by Lencioni.

And no, trust is not confiding in someone. Just because a team member told you something personal in confidence does not mean that he trusts you or that you trust him.

Another thing to remember that trust is not absolute. I trust my son being able to make the different exercises at gymnastics but that does not mean I trust him driving the car. You must have reasonable expectations and not give unwarranted trust in someone.

Finally, an important question is how well you have trust in yourself. If you don't trust yourself doing the job, how could anyone else trust you? An interesting insight in this situation is the personal account by Dan Kennedy describing his career in the music industry in the book Rock On.

Go ahead and build some trust: be the person others can trust. Make people wanting to be trusted by you.

Do you have a Collyer?

The term Collyer is used for an area packed with junk, trash and belongings. The term come from a pair of brothers whose house had to relieved from approximately 103 tons of garbage upon their death. The trash consisted everything from dead horses to abandoned trash from the neighbours. One of the brothers had been dead for two years but the surviving brother had kept his body in the house. And now it's happened again, a man digging tunnels through his garbage got lost and died in England.

One wonders how it got started. I don't think the man in England decided that he was going to gather so much junk that he could make tunnels in it. I think it started in a habit common to many. "I don't know how I'm going to use this but I'll just hang on to it and it will perhaps come to good use sometimes." Another (often combined situation) is when someone is like the birds in Find Nemo: "Mine mine mine." For some, having is not as important as others not having. And then this is repeated over and over again. And suddenly you cannot do anything because all you do is dig through the garbage.

Lean Software and agile development identifies this as one of the most important problems in software development. If you look at you project or your development environment as the Collyer house you probably have those routines and documents that you really don't see how you're going to use but you think can be handy. Right.

This does not mean that you should only have things you need right here and now. There are things like insurance and fire indicators which have a value even when they are not used. But then you know that there is a calculated risk and the consequences if the unfortunate happens. But no one will die because you didn't keep that broken umbrella.

(Thanks to my friends at VoF for supplying with details on the Collyer family.)

Suggestion for a new year's resolution!

Yes, I know that New year's has passed but it is still time for a new year's resolution from Kevin Rutherford

In your current job, can you identify:

1. Five regular activities that contribute value towards your organisation’s goal?
2. Five regular activities that do not contribute value towards the goal?

Something we all can do and probably should. Perhaps it's easier than quitting smoking or exercising more.

Modern project management, or?

One of the classes I'm taking at Mittuniversitet this spring is Project Management (Projektledning). The objectives of the course:

The course targets people with interest in project management with focus on software development projects. The objective of the course is giving a basic knowledge about project work and project management.

Kursen vänder sig till personer med intresse för projektledning med fokus på systemutvecklingsprojekt. Syftet med kursen är att ge grundkunskap om projektarbete och ledning av projekt.

The main literature on the course is Arbeta i projekt - en introduktion (Working in project - an introduction) by Sven Eklund. The book is from 2002 but you could never guess it. The book could have been written during the golden days of waterfall.

I got rather suspicious when the author mis spelled the word Gantt chart on the back side of the book, spelling it as Gannt. So, I just flipped through the pages. The same error can be found through out the book. This is not a good sign. So, I started reading. I guess that I won't be the teacher's favorite pupil if he shares the viewes of the author. How about this:

9.2.2 Right or wrong?
What is right or wrong while you're testing? Where is the key to how the product should behave? Well, the key can be found in the documents created during the definition- and design phases. During those you have, often together with the orderer, specified requirements, objectives and behaviour of the product. It is also this the orderers expect that the product should be able to do when delivered.

9.2.2 Rätt eller fel?
Vad är då rätt eller fel när man testar? Var finns facit för hur produkten ska uppträda? Jo, facit finns i de dokument som man tog fram under definitions- och designfaserna. Här har man, ofta tillsammans med beställarna, specificerat krav, målsättningar och beteenden för produkten. Det är också detta, som beställarna förväntar sig att produkten ska klara av vid leverans.

Oh my god. I guess the author never heard about agile software development. The word agile does not even appear in the book. Let alone lean. Is this what the informatics major's in Sweden learn? Today? Of course it's good that students learn the classic way of carrying out an software development project. But just giving this picture without even mentioning that other methods are used and that this method isn't always successful. As I said, I guess I won't be the teacher's favourite student. I hope I can pass the exam without selling my soul to the devil.

(The picture is from a Valtech seminar, given by a what I thought rather well known lady.)

Wanderlust and wonderlust

You can read Alex Garland's The Beach and you can be amazed by the colourful surroundings or you can be troubled by the selfishness by the people described in the book.

We travellers around the world have a big responsibility. To the environment, to each others and perhaps most importantly; to the local people.

When I went to college the word of the day was Information. We were supposed to be information seeking individualists. Information seeking? When starting reading Informatics this winter I understood that this is not fashionable any more. We don't seek information but thrills.

This affects me being a part of the leisure industry. We don't only have the wanderlust in people. We also have a wonderlust to tackle.

But it affects all developing software. People are not content in a system which barely surrenders the information they need. You get frustrated and disappointed if the system is not intuitive and amazing. Developers thinking "well, that (lousy) usability issue is something people have to learn how it works" need to build a sense of craftsmanship or get another job.

On the picture my son is looking longingly at the airplane. Experiences are so much about longing. In the case of leisure travelling this is perhaps obvious. When we start thinking about travelling we start longing for it. The longing period is also part of the experience. But this also applies to the implementation of computer software. Agile software developers leaves room for this phase by their inclusion of users in the development process and this should be exploited better. If you see the introduction of a system as a travelling experience you can give your customers and users so much value.

Most travellers don't only care about the trip from the time the plane lands. They also care about how the alternatives are presented, how the order is put, how the logistics at the airport works, which services and products are available. And I believe the same applies to the users of computer software.

Where were you?

The reason for me working on Confessions of a serial product manager was that even if there are lots of books on scrum, story writing, agile planning, etc, I didn't have a book which brought it together from a product owner point of view. But guess what; Rob Galen of RGalen Consulting Group is just finishing the book I was looking for! The book is called Becoming a great product owner. You can read a free version at their web site. Here are some details from the download page concerning rights:

I've controlled access to the document, so you can't print or copy the contents. Nor do you have my permission to distribute the material--so please honor all aspects of the copyright. However, you can view / read the document as a reference and my hope is that it provides insights and value in that free form

R Galen digs into the deeper questions and details and I can highly recommend you product owners reading his (and mine, of course) view on product ownership.

Thanks Rob for sharing your experience with us!

Break with everyone!

Well, that sounds terrible, doesn't it. And that is not what Mike Cottmeyer means in his blog entry on success in agile organisations.

Agile is so much about communication is that we perhaps misunderstand the need for communication with the creation of dependencies.

Agile the reward, not the method

Some people failing following a diet says 'the diet does not work'. But most of them does not mean that if you follow the diet, they still does not loose weight. What they mean is that they cannot follow the diet.

Reading James Shore's excellent blog entry on the decline and fall of agile, I get the same feeling. When teams pick stuff from an agile methodology like scrum and call themselves a scrum team and it does not work they do not say "we couldn't follow the methodology" since it's easier to say the methodology does not work.

Here is a teaser (and perhaps now you see the parallells with diets):

These teams say they're Agile, but they're just planning (and replanning) frequently. Short cycles and the ability to re-plan are the benefit that Agile gives you. It's the reward, not the method. These psuedo-Agile teams are having dessert every night and skipping their vegetables. By leaving out all the other stuff--the stuff that's really Agile--they're setting themselves up for rotten teeth, an oversized waistline, and ultimate failure. They feel good now, but it won't last.

The blog entry is really recommended to you, thinking about going agile, or thinking about dropping agile.

Taking some time getting to know Kanban

As I've discussed earlier, I believe there are no silver bullets in software development. But I do believe in having as an objective to have the code so stable that users and acceptance testers "often" (and what I mean by that of course differs between solutions, cultures, users and so on) can start up the current version and test the current functionality. Why? So they can confirm that the development is going in the right direction.

Therefore I believe in agile software development and that is why I believe in many of the habits of a acting scrum team.

But something I and my team has struggled with during the project is that we still have the problem that sometimes nothing works. I cannot test anything. The reason for this is multiple stuff in progress. Stuff that makes things stop working.

Kanban is said to address this problems, so I'm going to take some time now getting to know the fabrics of kanban. Keep you posted!

My first agile project, not that I knew that it was a project or that it was agile

Looking back at my career, I find that my first agile project started back in the year 2000. But I never saw it as a development project. Nor did I see it as agile. But looking back, it had lots of agile feeling, even if it was somewhat extreme.

It started when I was working as a computer trainer and project manager at a computer training company here in Sweden. One of our sales guys came and asked me if I knew a program which was called FileMaker. Being born and bred from the Apple world, of course I had. Well, he had this course that needed to be held on using FileMaker. I hate those two day courses in database programs - either they are to superficial so that the advanced users don't get their answers, and the beginners never get enough to be able to create their own useful database. But that is another story. A consultant never says no, so I went to a big hospital here in Stockholm and met this science nurse, who was conducting a study and who needed this database. She had a database, but she needed to change it, so I was going to teach her.

I studied the system while we were talking and I soon realised that the model used didn't fit her needs, she wouldn't be able to answer simple questions as a patient's latest sample result on a specific test. That is kind of crucial.

We had to make radical changes and so my first agile project was on the road. But we didn't call it a project, we called it an education. I rebuilt the foundation of the system back at work but we decided to meet once a month to teach her a little bit more on how she was going to be able to change the system. At the same time I showed her what I've been doing during the previous month. You could call it a demo. During the demo we discussed which changes I was going to do until the next time we met and what she would be doing. You could say we had a sprint planning meeting.

We always worked from the use cases, or in this case: the study that was being carried out. She explained which statistics she wanted and I asked some questions back about special cases.

I was very lucky having this as my first agile project. First: she was an excellent partner (if you have a good product owner, you see that person as a partner or team member). Second: I didn't see this as something as hard as agile software development. I simply worked they way I found worked for us. And finally, I learned a lot and had so much fun. And that is not to be forgotten either.

Agile means agile, not free of charge

Agile means that you can develop more for less. Right. That does not make it free. This little film is for all you product owners and stakeholders. How does it feel for the developer, when you change your mind all the time (so the guy knows that your wish is nothing to pay any attention to, since it will have changed the next time you meet) and too late (so that the change becomes very expensive since hehave to roll back what he has done)? Change your mind, yes. But think first.

Estimating the product backlog items - why using a relative scale

Why do you estimate? I see two big reasons, which are connected:

• You want to build the most business value for the least resources. Therefor you need to know how big stuff is so you know if it's worth it.
• You want to know when new or improved features can be put into production. This so sales people can sell them at the right time and the users to prepare (for example education, integrations and installations need to be planned).

If I were asked how long it takes to build a house of cards I can give you an estimate I could give you one in a second. And so can most people who know what a house of cards is. But if you have a room of 30 persons, you will probably get very different answers from most of the people. Some of the differences lies in:

• Perception of what a house of cards means. It could be two cards or it could be a deck of cards.
  
• Skill in creating houses of cards. Some people are good or skilled at it. Some are not.
  
• Difference in how you measure time. Is it an empty room, no one around and you get to work by yourself? Or what. This gives huge impact on the estimate.
  
• Tools available. If you're allowed to use glue or cards appropriate for building houses of cards you would probably give an other estimate than if you were using some old weak deck.

The list goes on and on with all those little things which affects how we give estimates. So, what can you do? One solution is getting better information. You specify exactly what you want and what the pre requisives are. What is wrong with this approach: well it takes too much time and it makes changes impossible. If you make one small change, well then the estimation falls. The only way to make a good estimation using this approach is building the house and afterwords saying how much time it took.

So, what can you do? Well, what you can do is look at two rough sketches of a house of cards and then ask: which one will take the longest to build? Do you think that it takes double the time or tripple the time?

It is probably hard to say it's 1,3 times harder so you need a scale which you can discuss from. A popular scale is 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40 and 100. And of course the higher the scale, the more insecure is the estimate.

Estimating using planning poker is fun, fast and amazingly accurate. I will not take trouble trying to explain it, because the Swedish consultant firm Crisp explains it much better on their web site. There you can also buy decks of cards (even if I love the Mountain Goat Cards). What I do miss on their page is the use of a Golden List. The Golden List is an example list of estimations. You identify a story of each size. By doing so you can ask questions like "well is it really twice as big as X". The Golden List should be made up by stories which you've finished but if you're starting up you can fake a list from previous projects or simply things people can relate to. Print the Golden List on a big sheet of paper and keep it visual during the estimation session. Break when discussions are going into hours and days: keep comparing!

But hey, this only answers one of my needs: the possibility to compare size to validaing we get the most business value for the least time. How do I know when things are released?

Where are the details in the story?

When I read a story to my son, I don't have to tell him all the details because he uses his imagination to fill in the blanks. And the amazing thing is that the details are just magnificent. Some of us oldies have the same objections to Lego. When we were kids there weren't all of those special parts but you could use your imagination to make those standard parts all the cool stuff we wanted to create or simply play with.

Working with stories like "As a mobile client user, I can book my assignments so that I don't get double booked" is some what like working with standard Lego. Mike Cohn says that a story is a placeholder for a conversation because if you drop a story like that on a bunch of developers and then run as fast as you can from the project, of course you won't get what you want. Just like dropping a handful of Lego parts on a kid and expecting him to build what you want, without direction.

So, a story needs to be completed with some direction. And this in the form of a conversation. If you're building a puzzle or completing some kind of model or Lego structure right from the box: what do you do? Well, most of us look at the completed picture to know what we're aiming for. OK: we're building a space ship. Cool!

Why do Lego use pictures as instructions? Just imagine building a Lego Space ship from a written description. How good are your chances at getting that right? And how much time is spent on trying to understand the text?

When you write the story: you draw the big picture and then you go in to details. Well, We're going to need some landing gear. And then we can get into all those details for that part. So, keep the story short and add details as you go along. When you need them. And when you have enough to make a decision.

But does that not mean that I have to be around those dev guys all the time? well, not all the time, but a lot of your time. If you are the one who can make decisions. For developers make those decisions if you're not there. Or they stop working.

But how can you estimate that story stuff? Sounds crazy. Well, back to my Lego. How long does it take to build that space ship? Well, even if you have the detailed spec and read from that and then give an estimate on how much time you will probably be wrong. And if you have kids, they will disturb you or wreck the stuff while you are working.

But what you can do is that you can take two lego models, look at them and say which one will take longer to build. You can probably say if one is double the effort. But if the model is huge (full size Cottage) you have no idea for it's is simply to big to estimate. And this is why you don't estimate stuff on the product backlog using actual (or as I call it: inaccurate) time but using story points. She's just getting more and more vague? Or... Get back to you!

How do get some user stories on your backlog?

Believe me, I've tried all possible and impossible ways to get those stories printed. They all suck, in some manor. There is probably no such thing as a perfect solution. So, just drop that wish, and just try make the best of things.

The reason for writing in the form of a user story is that you want to catch the objective - what need do you want to forfill. Keep that in mind.

But then, take one step back and think: why do you need a product backlog? Well, you need to be able to tell the developers what they're supposed to build and you need to tell the users what they are going to get. And the things being done should be the thing that brings the most business value.

OK. Who should participate: well, first you need the guys who knows how to define the problem, and then you need the guys who are going to solve the problem. This means that you need some (representants for) the users and you need some developers. And then you arrange a story writing seminar. A story writing seminar means that developers and business people/users/stakeholders get together and try to get the problem needed to be solved printed in some form (digital or analog). If you are many: divide into groups. If you don't want to spend to much time: time box and keep the meeting standing.

I'm often asked: why involve the developers? Shouldn't they be coding? Well, to which use is the code if they don't solve the problem, and how great is the risk that they build the wrong thing if they don't understand which problem they are solving. That's why both groups are involved.

To make the meeting more focused and to have something to discuss around, I've created example scenarios. It's max 2-3 pages long and describes the types of users (personas are great for this) and what the surroundings for the problem is. For example, we're working in the field service management product business and an example scenario can be the small electrical firm who wants to report new cases while in the field.

All that want to participate need to read the scenario in advance and we spend perhaps two hours writing these short stories in the form described in an earlier post. But then you say: what about the details? That was like one sentence. That couldn't be enough for developing or estimating? Or could it?

What can you find on the product backlog? Part 1: the user story

When you know what the objective is, you can start making a list of what you need to forfill that objective. This list is called a product backlog.

So, to be able to answer the question what you can find on the product backlog, you need to know what you lack to meet your goal.

There are many ways to form a product backlog item. I like user stories. This is a good form for a great part of the product backlog. So, what is a user story? The basic is that you specify a kind of user, what he want to be able to do and if it is not self explaining: why he needs that.

To be able to specify a user story, you need to know who are your users. You can use personas or you can hold a seminar with stakeholders. The important thing is that everyone that reads the product backlog should be able to understand which kind of user you are talking about.

For us, that has resulted in an hierachy of users and user groups. We first have the basic User, who can be anyone from an end user to our developers. You can say "everyone with access to the system". If you then take that general user you can divide him into different categories, for example after skill (first time user, experienced user, user with hearing disability, expert user), client (integration, mobile client, web client, windows client), access rights (basic rights, administrative rights) or user type (helpdesk, technician, super user, operations technician, developer) or a combination of many of these traits.

Why you specify the user type is that it is made clear to everyone for whom you're building and for whom you are not building. This does not only make it more clear to the developer how UI should be formed but also how business value is calculated - if the sales division wants to target a certain group the business value of stories targeted at that group can be lifted. It is also tactical to give different groups "something of their own" from time to time to make them feel prioritized and seen in the project. It also tells the developer whom they should ask for details - if the user with poor sight is targeted, well, such a user should be able to give some input!

After you've specified user, you say want you want built: for example:
As a mobile client user, I want to be able to view a case address on a map

If it is not self evident why a mobile client user would want that you can add a specification why:
As a mobile client user, I want to be able to view a case address on a map so I can find my way to the location

That is how easy you write a story. But who writes them and how do you store them? And where do you keep the details? To be continued...

There can only be one

Mike Cohn said that he seldom participate in a project where he'd found any use for digital tools for handling sprint backlog, sprint burndown and product backlog.

I've heard the same on multiple scrum seminars and even heard the phrase 'Oh, you have so much post its, you must be really agile'. As if there where some kind of corralation how many trees that need to be killed and how agile you are.

But the strangest thing is that the same persons who talk so warmly against our forests are often good at showing burn downs from Excel. I do not understand that. If the horrible truth isn't that many using postits also keep the info as a list in excel.

My experience from keeping double records of lists that changes all the time is that one copy is never up to date. And there is something that is more dangerous than lack of visualization and that is visualization of old or wrong data.

There can be only one! That is true not only in the 80's block buster. I want my stakeholders to be able to see the one and only product backlog or burndown. And since my boss wants that diagram in Excel and since we have developers who needs to work from home from time to time we can't keep postits visual to all users. Well, we could place a web cam in our team room but that does strike me as a really weird solution.

My team's main reason against using Team Foundation Server for keeping the backlogs was the visualization but the introduction of Elektropost's Scrum Dashboard even the most stubborn has accepted the solution and we've also started an interest in our services organization. I would really like our consultants tracking their project in such a tool and also visualising it for the rest of the company. And why not the customers?

Defining the team roles - going scrum

This only applies if you're using scrum or a scrummish development model...

There is so much good literature on Scrum and just by googling it, you'll find loads of definitions and good advice. My advice is: keep it simple. Use the basic roles. See the roles as such and not individuals. Get everyone to understand what the different roles are responsible for. Select the best for each role.

Keep it simple, use the basic roles
Don't try implementing a lot of your own roles. Product Owner, Scrum master and scrum team. That's it. By for example including different proxies and stuff, the roles get more and more difficult to understand. For example product owner: if you can't take the responsibility, don't take the role. It doesn't get easier by adding another role. You're still stuck with the original problem which in that case is lack of responsibility.

See the roles as such
I'm just product owner when I'm acting product owner. When I'm off, someone else has to play that role.

Get everyone to understand the difference between the different roles
If your team and stakeholders don't know the difference between the scrum master and the product owner, you loose. It's not the most important thing what you use as definition, but make sure everyone understand and respect that difference.

Select the best for each role
Well, since Greg is XCY, he must be the product owner and since Gladis used to be a project manager, she'll be scrum master. Bad, bad choice. Or, to be correct: wrong given reason. Look at the different definitions for each role and choose the right person. While attending a product owner course for Mike Cohn, most of the participants said that they didn't have the time it took to forfill the role. So, why did they take it? Pride? I've heard somewhere that about 60% of all scrum projects fail because of a failing product owner. Hope they are proud to be part of that statistics.

A good product owner needs to be able to make decisions, stand by those decisions and be there for the team.

A good scrum master must be able to know when to open the door and when it should be shut.

A good scrum team member can commit to working on the sprint backlog and forfill the tasks taken.

Step 1: what is it and what is it not?

Before you write one line of code, you should know what you're building? Well, that does not sound very agile, does it? Well, this is not getting into details but creating a product or project vision. The question that needs to be answered is why are we spending all this money and time? What is the objective AND what is NOT the objective. My experience is that besides the most simple solutions the problem is not saying what you're building but drawing the line: here but not beyond! Using the Moore template for a project vision is a good idea. Getting all the known stakeholders together and just specifying it. And don't settle for a novel. When I first asked the original product owner at our team for a project vision I was handed a A4 tightly written sheet. But even so, the limits where not included. It is hard for a salesperson to say which customers we don't want or which processes we won't support.

But this is not a one of occasion - a project vision should be specified for each bigger release of a product or in a project. If you find the Moore project vision boring you can also follow Mike Cohn's advice and produce a poster or a box - if we were packaging this release in a box, how would that look? Force the participants to use the marketing form and don't settle for a simple list. The box or the poster should be able to sell the release to new and old users: why should I buy or take the trouble upgrading?

But shouldn't you select iteration lengths, PO, scrum master and so on first? Well, how do you know who makes the best PO before you know what you're building and do you know which resources are the best? You probably have a good idea before but hopefully, this will make it easier.

The project vision should be something the developers can look at when making the small decisions: how does this bring the project/product closer to the objective. It is easy to aim for a goal but easier to miss it and often enough being close or being very far off is as bad. This is not true for sports like football. By setting a project vision, people hopefully know which goal they should be aiming for.

Is it a project or is it a product?

For me, working at a product compay, I had big problems when reading literature on software development. Everything concerned projects but we have a product. Big difference. And yet not. I believe that you, indifferent of you working in a project or working with a product, benefit from taking both perspectives.

With that I mean that sometimes you should look at your work as part of a project and sometimes you should see the product. And if you look from one of the perspectives, you should try switching to the other. Just to see what you are missing.

For example, if you're working in a project to implement a new software to your organisation and you're discussing deployment. Think of it as a product. Think how you're going to handle updates, bugs, new versions of components, etc. Think of implementing the software at multiple organisations. This might not be the case right now, but what if the organisation buy another company or is split. I don't say build for that scenario but it gives interesting thoughts which might change your priorities. And also, the users might not understand that something like that could be a problem and there is really a plan to implement the system on another team. Yes, we're doing Boston now but we plan to move on to the Dallas department later. No problem? Well, what if both have installed but want to run different versions or have different environment to deploy on. Building for operations was not the reason for me going into the software industry but that is really what makes it hard and interesting. It's not like in the good old days when the big system was built and it hanged on until it died and was replaced.

The project view is good when applying agility: if you're working at a product company you might not see the end of it. What is a product burndown chart when we don't know how many versions we're going to build? Well, in this case I see every release as it's own project and if I just focus on getting that to work, that is something I can handle.