Applitude

In Scrum, there are basically three roles of Product Owner, Scrum Master and Team Member. The purpose of the Product Owner role is to connect product line with product development. A Product Owner in Scrum, you control the project or development work yourself instead of relying on a project, and that means you have a coach (Scrum Master) to help the team to work efficiently and supports collaboration within and outside the team. Compare it with the OGC model with Steering Committee – Project Manager – Team Leader is to be in the scrum map it to Management – Product Owner – Scrum Master.

When Alan Turing wrote his book “On Computable Numbers, with an Application to the Entscheidungsproblem” in 1936, he laid the grounds for computer science. The first “universal machines” were developed at Bletchley Park to decipher the Germans’ encryptions during the Second World War.

Between the 40’s and the 70’s computer science became more of a scientific instrument than a well-established business technology. It wasn’t until IBM and Apple introduced the PC and Macintosh computers that computer science began to spread outside the scientific institutions, making their way to the largest companies. It was at this time that software development started to take off and we saw the birth of large companies.

Up until the 70s, programs often were quite simple and were operated only by those who created them. But as systems became larger, it also became more difficult to develop and organize software development.

In 1970, a director at the Lockheed Software Technology Center, Dr. Winton W. Royce, published a paper entitled “Managing the Development of Large Software Systems: Concepts and Techniques”. Dr. Royce presented a more structured method for organizing software development. This technique was inspired by the manner in which fields like Civil Engineering and Manufacturing organized their development.

The basic idea is that everything is done in sequential phases. This means that you need to understand everything in a specific phase before you can start doing the next phase. If you change your mind in a later phase it will cost you and be hard to finish the project in time. First you need to understand all requirements, and then you need to do all the design (big design up front) and so on.

Each phase was handled by specialized groups like business analysts (for defining the requirements), system analysts (for designing the programs), programmers (for developing applications), testers (for testing applications) and deployment personnel (for overseeing operations). These groups communicated mostly in writing, and handed over work from group to group.

Managing software development with the Waterfall Model (I discuss this model later in this section) is to investigate what the system is supposed to do, make plans so that it does what it is supposed to do, and to stick to that plan. This model, however, had its setbacks: first, people learned a lot from the first system requirements until they went into production and were used by users. This made it difficult to take advantage of what was learned in the various processes.

Second, it often took a long time between the requirement phase and the user feedback phase. If you didn’t figure out what the users wanted or the users themselves didn’t know what they wanted, that meant more time and money had to be spent to change or adapt the system to users’ needs.

In defense of Royce, it would be fair to say that he actually did warn that these things could happen and he therefore proposed an iterative way of work. But no one adopted this part of his model. That’s how it came to be called the Waterfall.

When the US Department of Defense needed a software development process, they looked at Royce’s paper and they adopted a part of it (unfortunately they adopted the worst part) and named it DOD-STD-2167 (Department of Defense Standard 2167).

When the NATO later needed a model they thought that if it was the best model the US military could find, then it ought to be adopted. And from there, more and more people adopted the theories of the Waterfall. Even if the US Department of Defense changed the standard in 1995, it remained the basis of what the academic world is teaching to this day.

The rise of plan-driven methodologies
In the 80th and early 90th a myriad of new methodologies where invented that where focusing on design. These gained popularity in the same speed that object-oriented programming languages like C++, ADA and Smalltalk gained practitioners.

Naturally there were design methods before this time, even object-oriented ones but the popularity of C++ created the need for a new approach. Most design methodologies before this were data driven and/or functional in nature. When programming in an object-oriented language they were found to be not adequate.

Methodologies that became popular where Rumbaugh OMT, Booch, Coad-Yourdan, OOSE from Jacobsen and Shlaer-Mellon to name a few. All were quite good in certain areas, but seem to not cover the whole design process. Each methodology had its own type of notation and often only concentrated on a sequence of even in a system.

Because of this it was hard to use only one tool; developers adapted their favorite method and added other tools into their hybrid design methodology, splintering the industry even more. The so-called “Method Wars” arise and people where arguing endlessly about the pros and cons of their adapted methodology.

But in the mid-90th three design creators Jim Rumbaugh, Grady Booch and Ivar Jacobson joined forces at a company specializing in design tools called Rational. They became known as the famous “three amigos”. They declared the “Method Wars” over and soon came out with a first release of the Unified Modeling Language.

The RUP process and other methodologies from this time were based on a plan-driven but iterative assumption. The critics was mostly based on that these methodologies was to document focused. You would still need to understand the whole problem before you started the next step everything should be documented and this created a very big overhead that didn’t create a business value. A large complex problem where documented and explain rather good but less complex and more simple problem directly became as big to administrate.

The rise of agile methodologies
During the late 90th people started to react against the plan-driven models. Many people were very frustrated on the demands presented that developers became more agile to business demands, adapting better to knowledge gained during the project. Plan-driven methodologies were considered bureaucratic, slow, demanding, and inconsistent with the way software developers actually perform effective work.

New ways of work like XP, Scrum, DSDM, ASD, Crystal, FDD and Pragmatic Programming where developed as an alternative to documentation driven, heavyweight software development process. These new methodologies, however, had something in common: they focus on a construction and planning plan in the beginning phase and stay with that plan. Many of the Agile methodologies were inspired by “New Product Development Game”, an article written by Hirotaka Takeuchi and Ikujiro Nonaka and published in the Harvard Business Review in 1986. This article is often used as a reference and could be considered the birth of agile methodologies.

In February 2001 a group of different methodology developers meet in a ski resort in Utah, to talk, ski, and relax and to try to find common ground of what they were trying to accomplish. The output of this weekend became known as “The agile software development manifesto”.

Another movement that has gained substantial support within organization of software development in the 21th century is the Lean Software Development theories with Mary and Tom Poppendieck as the main figures. Lean is based on the system thinking theory, which sees an organization as a system. The system shall fulfill a clear customer-focused purpose in a so productive way as possible. They mean that your purpose is probably not to develop software. Your organizations customers probably want their demand satisfied or a problem fixed. If the customer could solve their problems without software, they would be delighted. They way Leans work is that it analyzes the system that the software shall be used and also how to produce that in a so productive way as possible, that focus on adaptive behavior, knowledge acquisition and knowledge workers.

To summarize the history of organizing software development, I will use the words of agile guru Martin Fowlers: “from nothing, to monumental, to Agile”.

It might seems like programming is about writing code for computers to understand, that what a programmer do is translating requirement to a language that computers can understand. But no programmers sees himself as a translator, we see ourselves as creative writers. If two programmers are given the same requirement to implement their source code will differ so it’s not about translating from one language to another. The language used to produce the program isn’t either for the computers, it’s for humans. Most programmers write in a language that needs to be compiles and translated to an executable that computers understand, so the purpose of a language is for people to be able to collaborate and understand each other intention.

In a complex solution the time and effort to deliver, maintain and extend software are directly related to the clarity of the code. The lack of clarity creates technical debt that will eventually have to be paid off with interest, debt that can overwhelm your ability to develop new features. Failure to pay off technical debt often results in bankruptcy: The system must be abandoned because it no longer worth to maintaining. It is far better not to go into debt in the first palace. Keep it simple, keep it clear and keep it clean. Grady Booch author of Object-Oriented Analysis and Design with Application writes that you recognize clean code because it simple and direct, “Clean code reads like well-written prose. Clean code never obscures the designers’ intent but rather is full of crisp abstractions and straight forward line of control”.

To be agile and stay agile, you need to change things with confidence without risking change that could result in an unpredictable behavior or in a bug. To do this, verify that previously built features are not affected by newly introduced code. If you don’t create automated tests causing you to do a lot of manual work, you incur unnecessary risks when introducing new features.  As a result, your system will become very fragile.

Another argument in favor of several automated tests is that unit testing and test driven development represents the cost of handling bugs. The cost of fixing a bug that has already reached the production environment can be very expensive. Ideally, a bug should never appear.

Practices like unit testing, automated tests, continuous integration, refactoring, TDD, iterations and incremental development and simple design where separation of concerns are applied is great insurance to be able to be agile without becoming fragile. As soon as you start tamper with these practices your risks increase and ability to flexibility decrease.

After been completely spammed with comments during the summer! Even if I have enabled Captcha and that comments need to be approved, I have decide to turn of comments for a while. I can’t handle hundreds of comments per week and most are just link robots from non-serious SEO companies.

/Patrik

“The ones that demand that you as a project manager shall know what behind next rock will probably appreciate a horoscope more than reality.”

If things keep changing, the best solution will not be the best solution in the end of the project, if it even will solve the problem. Instead an empirical process must be taken in complex situations.  You have to evaluate a lot of possible solution, discussing pros and cons with different kinds of designs. A complex problem have multiple solutions some are just better than others, but you can’t predict them. Some solutions are more efficient and more productive than others just like when you solving Rubric’s cube.

“You are in the undiscovered land now, no one expects you to know what behind the next rock!”

Realize that we’re all seeking simple truth where there aren’t any. By accepting that you work in a complex situation you let go of the presumption that you can predict things. If project steering groups demand predictability they will get a plan, but they will get a false sense of control because complexity can’t be predicted. This only created guilt for the project manager in charge and then down to the team, when people are expected to commit to a non-deterministic process.

IT-strategy is how IT supports the business strategy. It aims to establish a business-driven approach to effectively dividing IT resources. This defines the expectations from IT and how limited resources are to be divided. To manage any software development project, the overall IT strategy must be clearly understood. It’s also important to understand how well the software development supports the business strategy.

This post will cover:

• IS/IT-strategy – what are the demands on IT and how will IT support the business strategy?
• Enterprise architecture – the roadmap of IT-systems for the organization.
• Architectural frameworks – tracing the business strategy to specific projects, applications and features.

IS/IT-Strategy

Having a strategy for IS/IT covers what to do and what not to do with IT. If the strategy is not followed, you will indirectly not do the things you like to do in the strategy. The organization has limited resources and if they are to spend more money on things outside the strategy, chances are you will not be able to do the things you want to do.

IT-strategy summarizes some of the following:

• High level organization: How is the work organized? Who is responsible for what?
• Project portfolio management: an inventory of current and future projects managed by IT. Contains a description of the project’s objective and scope, timeline, and expected benefits or return on investment (ROI).
• Resource summary: how is the IT function staffed and how is budget allocated?

Like most strategies, a common tool is the SWOT-analysis which helps to organize what could and should be done and prioritized.

There are different strategies. Here are a few examples that show what’s expected of IT and what the outcome of a specific project aims to gain.

There are basically two different aspects that drive all IT investment. Either they are competent so the project is completed, or they gain some advantage over the competition. The advantages could be cost savings, reinforcement of the company’s USP, or both. The list below describes of IT investment:

• Basic business costs. Costs are necessary to be able to compete and continue the current strategy. Processes change and IT needs to follow.
• Extended business costs. These costs are incurred when companies develop new solutions required to organize the process.
• Differentiation. Strategic investments to gain an advantage. They could be a cost advantage or a different product or service.
• Next frontier (strategic). Funding new pilots to find new potential differentiators.

If an investment doesn’t fall into any of the planned strategies above it shouldn’t be done. If the companies develop a feature that is not part of the strategy, it may mean non-use of those features or activities. It’s therefore a risk to add features to an application or product that a developer happens to like or finds it easy to build while in the middle of that module. It’s tempting to say yes to small features that programmers recommend, but the # 1 question is, do they support the overall strategy? Time and funding are limited, and resources must be devoted to those aspects of the project that require them; otherwise this can lead to neglecting or not doing the essentials of the project.

IT-Strategy: as it Relates to your Software Project

This isn’t a book on IT-Strategy and how to organize it, but it’s important to establish a relationship between software projects and the overall direction of the organization. In an IT-Strategy, there is a larger plan for what the systems do and how they relate to each other, otherwise known as the enterprise architecture. The enterprise architecture describes how different systems support different business processes. To support IT-strategy, the enterprise architecture tries to address all stakeholders’ needs within the organization’s need.

Enterprise Architecture

An enterprise architecture tries to design an optimized roadmap relative to existing and future resources. Business is constantly changing. The roadmap must therefore be a priority to reflect these changes. This way, there’s no risk of sub-optimization. Sub-optimization, in the context of software development, may mean systems or projects that don’t duplicate functionalities. It can also mean solving the wrong problems, or introducing unnecessary complexities.

The relationship to software development!

It’s important to understand the context you’re working in. If you’re working in a larger company, there are different strategies for deploying technologies that are relevant for the future and technologies that should be depreciated. For example, if the company thinks that websphere and Java are the future, it might be a bad idea to use PHP. Do you think your system will be around for a long time or will it be discarded soon?

Architectural Frameworks

An architectural framework provides a formal and highly structured way of viewing and defining an organization. An architectural framework is not a methodology on how to organize the work in a process; it’s a classification structure to document enterprise architecture.

The most established architectural framework is the Zachman framework, which I haven’t worked with because I was schooled in the 2xSundblads framework. Given that the Zachman framework is the most established, I will use Zachman as the example in this book.

The Zachman Framework summarizes the perspectives involved in enterprise architecture. You can see the framework as a template that forces you to investigate various things from two perspectives. It consists of a two-dimensional classification matrix that forms a 36-cell table. On the rows you find different abstractions (scope, business model, system model, technology model, components, and working system) and on the columns you find six questions (What, Where, When, Why, Who and How).

The Zachman framework is a simple and logical tool to structure complex and evolving enterprises. There is no order of priority for the columns but the rows have a top-down order. The Framework takes into account both the artifact target (for example, stakeholders) and a particular issuer (for example, a specific system). I find that an architectural framework is a great way to organize things when it’s really complex and you don’t know where to start.

Summarizing the IT-Strategy

When organizing a software development project it’s important to take the context into account and how your work is related to the overall business strategy. If the project isn’t aligned with the organization’s strategy the project will never be successful.

The bigger a company becomes, the more complex the business processes will be and hence a larger need for proper coordination. The point is to be successful, it’s important to understand what the effect enablers for the project are. If you don’t have a customer who is clearly responsible for that, you need to address this yourself. You need to connect the overall business strategy to the project’s goals and to ensure that the value of the outcome is greater than the effort. Addressing the business perspective is indispensable.

How large portions of the work should be estimated

In software development, it is difficult to understand the complexity of a project.  It is therefore a good idea to split up the task in smaller parts where the largest part will take less than 40 hours. Large and complex chunks of work need to be split in smaller parts.  My observation in time estimation is that complex tasks seem to be 90% done and stay that way much longer than tasks that are less complex. This is the consequence of undertaking an endeavor in which you have no experience

I will present two methods that I use, both separately and together. We have used planning poker to estimate the most likely value and Lichtenberg to handle the variations.

Planning Poker

Planning poker is a consensus-based estimation technique. The method was first described by James Grenning but it gained popularity when Mike Cohn wrote the book Agile estimating and planning.

When an estimation session is done, one person describes the requirements for the group. The group discusses and specifies how to fill the requirements. Each participant makes an individual estimate but does not say it.  They use playing cards with pre-set numbers. The denominators are 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100 and “Don’t know”. The values can be in either hours, days, ideal days or story points.

When everyone has played their card, the card is shown and the group discusses the estimates with those who provided estimates that were radically different from the rest.  After discussion notes are written (which might be valuable for future development) a new estimation is done. This time the estimates are more similar. If this doesn’t happen, the process is repeated. It is not necessary for the whole group to have the same number because the objective is a qualifying assessment rather than a precise time period.

Lichtenberg’s Method

Professor Steen Lichtenberg developed a mathematical method to estimate time which also provides a measure of uncertainty in addition to an assessment of the likely value. Minimum and maximum values specify the limits of uncertainty. These dimensions should be such that there is more than a 1% probability that the actual result will fall outside the min-max range. The estimates are based on certain conditions, stated or unstated, such as who should do the job. The uncertainty is processed only on those parts which are most important for the project’s total uncertainty. Because there are so many project unknowns, the min-max range will be large. The project’s end date and total cost are not stated, only a probability assessment is made.

When doing an estimate, specific activities are discussed with a view defining what is included and how it was and will be done.  The group tries to estimate how long it will take one of the members to achieve it. This is done by the person or persons who will be doing the activity later.

When the most likely value has been agreed upon, the group estimates how long it will take to do this if everything works out great. Then the group discusses the worst case and estimates the difficulty level of the activity. When estimates of the “most likely” value, “best case” value and “worst case” value are obtained, the following formula is used to calculate the expected value.

This calculates the probability that the team will be within a 95% interval with the following formula.

So let’s look at an example.

Everyone who is affected by the project will have an opinion on how the project will affect them personally and their organization. Users want the best software and customers want it for free. Sales people want a unique product that creates a great business value for as many potential customers as possible. Suppliers want a larger share and your development team wants to use only state of the art tools and technologies. Your responsibility as a software development manager is to make sure that the right thing gets done, in the right time and in the right way. To make this happen understand the needs and strategies of the different stakeholders.

The responsibility of the software development manager, therefore, is to make sure that everyone gets what they want. This makes him the middle man negotiating with all stakeholders. Your aim is to give everyone something – so they feel like a winner. This is one of the main subjects of this book and I discuss it in another chapter. For now I just want to make clear that making everyone happy to a certain extent is a key role of the software development manager.

Might seems like a strange title, now that I preached the importance of leaving your comfort zone and reflective competence. I still convinced direct experience is the most powerful way to learn something. We learn eating, crawling and communicating through direct trial and error. Through taking an action and seeing the consequences of that action we learn so we can take new actions and learn from them.

But what happens when we can no longer observe the consequences of our action? What happens if the primary consequences of our actions are in the distant future or in a distant part of a larger system your apart of? We each have a learning horizon, a breadth of vision in time and space within which we assess our effectiveness. When our actions have consequences beyond our learning horizon, it becomes impossible to learn from direct experience.

Decisions in the agile self-organized software development team first have consequences for the burucratice ITIL-governance infrastructure department, then on the support organization and maybe years later on marketing department and sales force. Drawing conclusions from actions in the development project from the feedback from the sales force can therefore not be done that easily. The longer away in time and organization things happen the harder is it to understand the consequences of one’s trials and errors.

Setting goals

Setting clear goals are important but the current fixation of the SMART goal setting strategy might be needed to be reconsidered, at least when you lead competent co-workers. You have probably been drilled in the SMART goal setting strategy, which preaches that goals shall be Specific, Measurable, Attainable, Realistic and Timely in order for people to be able to strive for that goal. I want to raise a warning finger when you working as a manager in a knowledge-based organization, you need to be very careful what you which for, you will probably get it.

When you lead competent coworkers they probably know more than the managers, therefor it might be hard to create both short term and long term success based on SMART goals by someone that is just based on historical behavior without getting an undesirable side effect. They might not know witch goal to be set or how to reach the goal but they have a far higher ability to adapt their way of work and invent new solutions than what a reactive SMART goal would lead to.

Let’s say that you like to decrease the “hardening” time at the end of a release cycle. Therefor a SMART goal is set to “cutting the verification time by 50% within the next three iterations”.  This target goal will probably be reached, but often at the expense of more defects getting through to the release.

Another approach is to challenge the team to redesign the way development works so that defects are discovered and fixed as soon as possible after they are injected into the code. With this challenge, a team would quit focusing o how many feature are delivered and start thinking about how to make sure that every delivered feature is defect-free. The team would introduce practices like automated test, continuous integration and code reviewing. When done well, this approach has a track record of dramatically decreasing testing time, by far more than half and at the same time raising quality and productivity.  The system verification time was just an effect of how the development was conducted. If you only look on the verification and test time it might be easy to not see the whole cycle and just trying to make the tester more effective.

The point is that goals that are SMART often are reached, but often solved in a reactive way that leads to new side effects. When you lead competent, proficient and expert coworkers they have an ability to reach further than the SMART goal, when they are given a challenge that is open-ended.

A Challenge is different from fixed performance targets:

1. Challenges are not necessarily SMART; they are open-ended, customer-centric, and designed to elicit passion and pride.
2. Challenges communicate confidence that the team is intelligent, innovative, capable of thinking for themselves, and trusted to do their best to further the purpose of the organization.
3. Challenges flow from long-term vision of what is necessary to be successful over time and contain enough information that the team can act independently and with confidence that their work will contribute to achieving the vision.
4. Thus challenges are a pull from the future rather than a forecast of the future.

As I said earlier, knowledge-based work is more of an endeavor than an execution of a well known process. When you undertake a task or project that you’re not sure about, it’s natural to feel some hesitation and anxiety. I have felt this way with some projects, blaming myself.  I attributed the pain of loneliness and anxiety to my personality defects – I thought that I lacked certain traits others had.

When I discussed my doubts with friends who are studying to become journalists, they advised me to read  The Writer’s Journey by Christopher Vogler and Himmel-Helvete tur och retur (English translation: Heaven-Hell and Back which is available only in Swedish) by Bengt Renander (a Swedish creativity consultant).

In The Writer’s Journey the classic storyline for drama is discussed – how do you build a story that will work in dramatic movies? Vogler, who worked in both Disney and Warner Bros as a screenwriter, divides all dramas into three parts that have twelve different steps or actions.  To build a good story that people will like, he shows how most movies are made as exploration journeys, where the main character in the film faces a challenge or needs to resolve a conflict. This takes the character through the following twelve steps.

Vogler divides a story in two different worlds:  the ordinary world where you first meet the main character and then the special world that he is about to enter during the journey. In the ordinary world the main character is living his ordinary life. For example, you first see Luke Skywalker, the hero of Star Wars, who is bored to death as a farm boy before he sets out to tackle the universe. If we continue with Star Wars as an example, we proceed to the next stage – the Call of Adventure – when Princess Leia’s sends a desperate holographic message to old wise man Obi Wan Kenobi, to ask Luke to join the quest.

Leia has been snatched by evil man Darth Vader, much like Greek springtime goddess Persephone, who was kidnapped to the underworld by Pluto, lord of the dead. Her rescue is vital to restoring the normal balance of the universe. As the story continues, Luke refuses the call of adventure by returning to his aunt and uncle’s farmhouse, only to find they have been killed by the Emperor’s storm troopers. Suddenly, Luke’s reluctance transforms into a burning desire to undertake the quest.

Luke takes the evil of the Empire personally. He is motivated. Those of you who saw the movie know how the story continues. The interesting observation in this structure was made by Bengt Renander who realized that behind all these steps lies a specific feeling that the viewer is supposed to feel. The reason this technique works for many movies is the common order of feelings that humans have when undertaking an exploration journey and when they leave their comfort zone. As Bengt puts it, “a movie where the main character doesn’t develop emotionally will be rather boring to see”.

Bengt also realized that it’s a common misunderstanding is the best result comes when there are feelings of lust and creative joy. All these feelings are necessary – indeed normal – in creative processes. They’re not wrong – they’re feelings that just stir within us. In fact, they are signs that we are on the right track. Feelings of pain are normal in the creative process and that’s a consolation for all creative workers who are aware of that.

Put this into a team and you as a project manager don’t need to feel frustration, anxiety and anger.  You know it’s not your fault, because it’s part of the process. When you leave your comfort zone and undertake a project that is complex and hard to do, it would be strange not to have these feelings.

A friend told me that early in his career, he worked in a juvenile detention center and used to have talks with his supervisor about what he disliked most about his work. The hardest thing is to isolate people from society against their will because this goes against human nature. His supervisor answered, great! What kind of prison would we have if all guards felt that way?

The moral of the story is that it’s natural to be afraid and anxious when leaving one’s comfort zone. The more complex a project is (no agreement on requirements and/or uncertainty about the technology) , the less one’s previous experience can help.

Longing

Longing is the foundation of all creation.. Longing works like a radar – if you long for a new and better job, you will probably open your eyes to new possibilities. If you are longing for a relationship, you will be more open to new and interesting people.

Arousal

When an idea introduces a possible solution, longing is replaced by arousal.  Longing is about wanting to change reality (today something is in a specific state but it might be different in the future). The definition of a problem could therefore be, “the problem” = “what you want and long for” – “the reality”. The larger the difference between “what you want” and “the reality,” the larger the problem is.

The more accurately you identify “the problem” the higher the chance of a successful solution. If the problem is that it is too cold in Sweden, you like to travel to a warmer place. The direction is to go south. To define the problem is to set a direction of where to go.  If you set the wrong direction, the problem will not be solved, even if you compensate by working faster.

Hesitation

If the problem is the lack of previous experience, hesitation sets in. This is because undertaking a new endeavor means travelling into the unknown.  The unknown connotes that danger is lurking and you don’t know what will happen. Your choice is to leave your comfort zone or to hesitate. Interestingly, either choice will cause pain.

If you decide to not start the journey and stay put, you will cause regressive pain, creating anxiety that comes from self-betrayal, from not exploiting your potential. If you decide to continue forward, it will also cause pain – progressive pain. You do not think you can handle the mission with your knowledge and experience. This is a form of growing pain.

Hesitation is natural because you’re considering the risk of failure. The ability to plan and make calculated assumptions about the future is what distinguishes man from animal.  Previous experience enables one to draw conclusions about the future. Without any previous experience and the possibility of losing something creates worry.

To overcome hesitation, motivation is needed. Motivation comes from the belief that the satisfaction of reaching the goal is larger than undertaking the journey – including the fear of failing. One can define motivation therefore as the “motivation to do something” = “The expected satisfaction of reaching a goal” – (“the cost of doing the journey” + “the fear of the risk of failing”).

I have heard many entrepreneurs say that they never would have started their endeavors if they knew what they were getting into. Thanks to that they underestimated “the cost of doing the journey” they become more motivated, so ignorance can be a bless.

Emptiness

Just when you had hoped to get started on your journey, you get that feeling of emptiness. You have to let go of something old without having something new to keep you in. The task seems endless and elusive, you do not know where to start and nothing feels like a natural start. This gap you feel needs to be filled with ideas on HOW the trip will be made.

To get ideas about how the trip can be accomplished, you need inspiration. Vogler calls this phase meeting the mentor in his book Odyssey (700 BC).  Odysseus leaves his son Telemachus with his best friend when he goes to war against Troy. The friend’s name is Mentor and his name has become synonymous with helping others to develop.

You do not need a mentor to find some inspiration. The word inspiration comes from “Spirit”. To become inspired means to nourish your soul, you breathe in and fill the emptiness.

Transition from Act 1 to Act 2

In Act 1, you defined the problem, weighed the advantages and disadvantages but does not inspire you. The question is if you are motivated enough to want to solve the problem. Act 2 is about facing your own barriers and limitations.

Enthusiasm

When developing complex systems the difficulty comes from not having done them before. It could be that the technology and application are new to you. Or, the domain is unfamiliar that you have to learn the prerequisites of the business or you don’t know the persons you are working with. In most cases, all three of these factors are in some degree new to you, so you need new knowledge to succeed. As you learn new things (tools or information about the domain) you gain new insights. This gives you a feeling of enthusiasm.

Frustration

Developing complex IT systems is a highly collaborative activity. When you’ve figured out the solution, the next is to sell this solution to others.  You will need to motivate your thoughts and also adapt to new thoughts. Vogler calls this the phase of tests, allies and enemies. Like a film, the project also needs to be aligned so that everyone’s efforts are pointing in the same direction.

This is a very frustrating process.  You had problems convincing yourself, now you have to convince others. This makes creative work that depends on collaboration more frustrating than working solo. Collaboration is a core concept to take into account when working on complex software development projects.

Fear

In Vogler’s work, the hero’s journey is described when he approaches the innermost cave where the battle is to be fought. The hero is starting to realize he will have to face his worst nightmare; the fear of dying is pronounced. During the creative process the same thing might happen to you when you realize that this journey is taking a road you are afraid of. A line that is frequently heard in films is, “I would do anything to succeed without this”.  In the film Return of theKing (The Lord of the Rings) we listen to Gandalf and Peregrin Tok talking on the night of battle where Gondor is waiting to be attacked. Peregrin Tok says, “I don’t want to be in a battle, but even worse is waiting for a battle you can’t escape. “

All you do is wait, and the only thing you can do is to prepare.  Defense mechanisms are triggered. The project’s orientation is about to change, or your role has changed into something you do not want. Your self-image is clearly an issue; you are afraid because you know you have to change.

Pressure from others leads to self-doubt. I’ve been through situations where people came to me in anger and threatened to resign if the system was not designed in a certain way. The person’s anger was caused by two things; first, questioning his role as architect, and second, wasting his investment in terms of time and commitment because of the change.

Anxiety

In movies, the dramatic high point is the last battle for mankind or the final battle against the star’s death.  As Conan put’s it “enough talk, let’s kill!”  Vogler reveals that the big secret of “the ordeal” is that the hero must die so that he can be reborn.  In the creative process, we will have to accept change. You accept to let go the old baggage go, otherwise you will be doomed to failure.

In Bengt Renander’s book, he tells the story about how monkeys are hunted in south India. The hunter drills a hole in a coconut and then the coconut is chained to a tree. The hole is just big enough so a monkey can stick his hand in. Inside the coconut are some grains of rice that the hunter put in.

During the night, a monkey puts his hand inside and grips the rice grains but can’t get his hand out. On the morning the hunter returns, but instead of letting the rice go and running away, the monkey continues to try to get the rice out.

On the physical level, the monkey won’t let go of the rice. But his mental picture of himself is that even if chained, he is still a creature that thinks food is important. The monkey realizes that this mental picture will spell his doom.

It’s the same with software development projects:  if you don’t accept change and you don’t adapt,  you will be doomed.

Lust

For as long as you accept change, you will manage. When you have changed your mental picture of the problem, that’s when ideas come to you. They pop up, often when you’re thinking of something else.  Ideas come when you leave your cubicle.  In my case, ideas come when I’m in the car on my way home or when I’m about to retire for the night.

The idea is crystal clear in your mind and you see relationships you didn’t see before. You will feel an excitement to experiment with it right away. In the beginning of this book, I wrote about enthusiasm and how it is best used as soon as possible. If you get an idea today, how motivated will you be if you don’t start it until next week? The idea will probably not give you the same energy.  Many people think that it is at this point where the creative process starts.

Act 3

Act 3 is about making it happen in movies.  It’s the point of no return, it’s the road back to normal, but it is not the same normal you came from.  It’s a new normal. It’s now the idea it will become reality? Are you motivated enough to make the idea a reality? If Act 1 was WHAT and Act 2 was HOW, the last act is “ACTION”.

Joy

In a creative process, the most important thing is delivery. If you know how the feature and its dependencies shall be constructed, it’s time to build it. All creative work is characterized by a craftsman based realizations phase. Otherwise the output of the work had been reproducible with the same input. This is one of the things that motivates people. When done the same way or doing similar things several times, creative motivation disappears. Nothing wrong with that. Personally, I think it goes in periods. If I have a high level of complexity in my personal life, I can’t handle as much uncertainty in work. Since complexity and creativity are causing uncertainty and stress, it may be too much to have it on all fronts. People are different, some can handle more stress and uncertainty than others, and their ability to handle stress varies with time.

Anger

You must adapt your idea to reality. The idea will not become as ideal as it was in the thoughts (the Platonic world of ideal forms); we need to fit idea into other real concerns. The ones that are angry when the idea is adapted to reality are the ones that worked with the idea, it’s their idea that has to adapt. People who haven’t been that involved and haven’t invested any time in working the idea judge the idea only by the end result.

Peace

When an idea becomes reality and “the problem” no longer exists, you are relieved and at peace. You have now solved the equation of “what you want and long for” – “the reality” and it is rewarding.

A project shall deliver something “a scope” on a specific time and to a predictable budget. As your project progresses, things happen differently from how you’d planned. You find that you need extra computer hardware, and some tasks have taken longer to complete than you originally predicted. To get the tasks completed on time, you consider recruiting more contractors. But, to do this, you’d have to take other costs out of the project’s budget. You think about not buying the extra computer hardware that you need, however, this would mean changing the project’s scope, so that some functionality isn’t delivered. In many projects, the budget, scope and schedule are closely linked. Changes to one of these three key constraints will most likely affect the others, or impact on the quality of the project. In order to plan and manage the project you will need to know how the customer will prioritize. They probably say they need the entire scope on time and on budget. But here is an advice to see how the customer really is going to prioritize when things will not follow the plan. When planning the project you ask your customer or product owner the following: “its two week until delivery and the two most prioritized features are not finished, what will you do?” Does he say do whatever it takes or never mind that feature or how much more time will you need. Or he might say takes as many shortcuts as you can. This gives you an idea of how privatization will be in when things starts gets pressured.

Different prioritization themes

It’s rare that we have the time to everything we need to do, so we need to prioritize. The agile methodology is preaching that you shall prioritize to maximize the business value, but often business value is something vague. And at the same time you should prioritize knowledge acquisition and risk minimizing. I will introduce you to four different prioritization themes and show how you can use them and combine them in order to know in which order you shall implement your project.

1. The financial value of having a feature.
2. The cost of developing (and supporting) the new feature.
3. The amount and significance of learning a new knowledge created by developing the feature.
4. The amount of risk removed by developing the feature.

Because most project are undertaken either to save money or to get new opportunities for making more money, these first to factors often dominate prioritization discussions. However, proper consideration of the influence of learning and risk on a project is critical if we are to prioritize optimally.

Value

How much money will the organization make or save by having this new feature. This is often what is meant when products owners are given the advice to “prioritize on business value”. The ideal way to determine the value of a feature is to look in its financial impact over time – usually the next few month or possible years.

Cost

In order to judge if something is worth doing you must weigh value against cost. Many features seem wonderful until we learn their cost. When considering cost is important to evaluate the cost over time, some features cost more to maintain than to build. Adding language support might be cheap but slow us down and cost a lot to maintain. It might be better to wait with that a couple of month.

New Knowledge

In complex projects much of the overall effort is spent on perusing new knowledge. The knowledge can be either what shall be done or how it shall be done. If the team has no prior experience of something, start as early as possible with that task. You can do a proof of concept and it will help you to uncover the borders of the technology you using. It could also help you to agree upon requirements, because when people see how the programmer interpreted the requirement you’ll be able to see if it is what the customer expected. If the customer or the stakeholders don’t react, that is also good news – that mans they thing you interpreted their view.

By prioritizing features that have a big impact on the system and develop them iterative and deliver the system to users frequently helps you to learn new knowledge. Complex products biggest risk is probably the risk of building the wrong product.  This risk can be dramatically reduced by developing early those features that will best allow us to get working software in the hands of actual users.

Risk

Risk is all about the knowledge you don’t have. A complex project becomes complex because we don’t know “what we going to do” and “how we are going to do it” and at the same time have a lot of expectations on what the project shall accomplish. Risk is anything that has not yet happens but might and that would jeopardize or limit the success of the project.  There is many kinds of risks they can be outside the project “What happen with the system if the company is split?” it can be a schedule risk “If this doesn’t work we will not be done by April” or a functional risk “We might not be able to get that to work”.

There is a classic struggle between high-risk and the high-value features of a project. Should the team start on high-risk features that have a big impact on the system, the things that if they go wrong have many dependencies to all part of the systems and just must work. Or should the team focus on the low hanging fruits, which will deliver most bangs for the buck?

Conclusion of prioritization

There is no ultimate way to prioritize! But it might be good not to just look on one parameter like value or value/cost. And the preferred method should probably link to the project main enabler, saving money or getting new opportunities. You can also combine different aspects like risk and value.

I often get the question how do I convince my manager, customer or team to change? And the answer is you don’t! How do you like being “convinced” by a salesperson?

The only person you can control is you, if you can’t change yourself, how can you expect to change anyone else? If you can’t make yourself or other motivated of change nothing will happen. People need to feel that they know that the “journey” is worth doing in order to reach a goal. And people only feel that they really know if they have personal experience from something. So how do you solve this moment 22, which you don’t feel that you know until you do it, and therefore don’t know that the journey is worth undertaking?

Causes of resistance

There are many causes why someone might not be motivated to change.  Here are some causes of why people might not want to change;

• Don’t see any problems with the current situation. Why change if things work!
• Doesn’t see any path to the goal. Don’t see a natural next step.
• Don’t see that we are making progress. Why change if nothing ever gets better?
• Doesn’t understand the destination or agree the value of reaching it

Trying new ways of working

The easiest way to solve this is to try in a small scale, so that you get some personal experience.  Don’t do big bang changes but try different things and evaluate if it works for you, do it both incremental and iterative. See if you can measure the change, do you become more productive and do people like it. There are no ultimate solutions; there are no “silver bullets”! There is only hard work, and continues improvement. And in order to improve you will need be prestigeless and realize that past ways of work haven’t been optimal.

There are two factors that determine an IT project. Projects aim to raise the return on invested capital; the two main enablers are to save money or raise the perceived customer value. Either you become more efficient or you generate new opportunities. There is often a combination of these two where projects aim to both get new opportunities and save money at the same time.

If the first priority is to generate new opportunities and to raise the perceived customer value, the marketers will probably be your customers. And if the main enabler is saving money, you customer will probably be a administrative manager.

Deciding which one is more important – cost savings or opportunities – means analyzing requirements and establishing priorities. You might have several different stakeholders and users and it may be difficult to understand what they really wish to accomplish with a specific feature or demand. That’s when it might be helpful to ask, is this a cost saver or a new opportunity?

If you come up with a plan, you might surprised to learn that your customer will be dissatisfied about cost savings if you developed a project with new opportunities in mind after consulting with various stakeholders and users.

This means that the motivation of IT problems isn’t to solve technical problems; you are foremost there for solving organizational and business problems.

The Agile Manifest says that people is more important than a process. But what if you don’t have a great team that are smart, disciplined and attentive. If you projects consists of three trolls, a senior fresh out of school consultant from Accidenture and a relatively bright project manager, who happens to be deaf, blind and mute. No amount of coaching can help this team to magically self-organize and deliver a successful product. Then rules, micromanaging and a step-by-step process might be the only way. Smart, disciplined and attentive people simply do their jobs well and don’t get ticket for dangerous behavior. And the agile methodologies build an assumption of that you always got the great team. But the world isn’t perfect, sorry all employees. So self-organizing might not work so good for all teams.

Related post: Self-Organizing Teams the most debated Agile Principle

Higher Management

Higher management staff – CEOs, CFOs – CIOs – Business Development – are normally more interested in how products and services reduce cost, generate new revenues, strengthen the trademark and brand, improve customer relations, create new market positions, and acquire competitive advantage. They regard their respective departments as unique and special, so out of the box solutions would probably not be welcome.

Higher management individuals work at a strategic level and their decisions are seldom short-term. It’s therefore important to show them clearly how the solution will support the business. Why should they invest in this? Their perceptions are influenced by those they serve and the costs of providing this service.

Middle Management

Middle management staff – product or system owners, line managers, administrative managers, software development managers and business development managers, ), focus on what their respective business unit does. They are often focus on a specific project or responsibility making sure that the proper “housekeeping” is done so everyone else can work efficient.

They work at a tactical level and prioritize different activities. Their main preoccupation is how to make things more efficient. They do comparisons and benchmarking. Their perceived customer quality is based on the ratio between prices in relation to the perceived value. They are responsible for their assessments of new systems and features.

It is therefore essential to demonstrate to them why the solution or feature they require is produced with cost efficiency in mind and which would be the best solution for them. The keyword for middle management is what. What does the solution, system or service do in particular that it cannot be obtained at a cheaper price elsewhere?

The competitive factor is not price, but the perceived value that can be obtained. They like to know that what they like to achieve is clearly understood. Documenting their requirements is one way to prove that their needs are understood.

Team and Operations Management

Management at the operations level is often very close to execution with good insights about the process. They know how work is performed. They are more interested in how things are done and how they should work with a specific solution. Business value is easier to measure in terms of work and costs.  The interest is on the details of the solution. At the operations level, the right competence for the right task is what matters most.

The following conversation is typical between a manager and developers:

Project manager: How long will it take you to develop this specific feature?

Programmer:  One month of uninterrupted work

Project manager: Oh, I need this done faster.  Can’t it be done in a week? Need this before next month’s fair.

Programmer: It might get done in three weeks.

Project manager: Two?

Programmer: Deal!

The project manager will note the estimate of two weeks and will hold the programmer accountable for it.

So what was this discussion about? It’s about three different concepts: estimate, business targets, and commitment:

• An estimate of work is based on a calculation of quantity of the value of something. How long has this type of work taken to complete before or what do the different parts cost and how long do you need to assemble them? The estimate is used to decide if the work is worth doing or not.
• A business target is a desirable business objective, “I need this before the next month’s fair.”
• A commitment is a promise to deliver by a certain date or event.

What the project manager wanted was a commitment based on a business target, not an estimate. This is now a commitment but don’t call it an estimate. The estimate was 4 weeks. What happened was that either the scope or quality has changed or the programmer worked more hours than he originally planned.

Pair programming is sharing knowledge not only about how the code works, but also why it looks that way. It is sometimes difficult to write explicit instructions on why code looks a specific way and how it’s organized in pair programming. A common question about pair programming is will pair programming slow us down? The answer is yes and no. If the purpose is to spread knowledge, I would reformulate the question to will pair programming slow our learning or speed it up? Another advantage of pair programming is that interruptions tend be minimized.

Sometimes a group’s efficiency is linked to the specific knowledge of one or more people. When an expert becomes a bottleneck, let that expert be the adviser. By spreading the knowledge and letting the team try it first without the expert, it might not be as efficient, but in the long run, the knowledge spreads.

If you are not allowed to make mistakes, you will not understand the whole picture. If the expert isn’t directly involved, the rest of the team has to take more responsibility but still must have access to the expert as an adviser. The expert being fully involved is probably the most efficient approach, but if it limits the team’s performance, it would pay off in the long run.