Archive for the ‘Uncategorized’ Category
January 27th, 2012
Up until the industrial revolution, success came from personal competence. You were judged on how well you mastered your craft. When industrialization took over, mechanization became the winning process.
Both craftsmanship and manufacturing have well-understood and static problems – demand is predictable.
Software development, however, is not a product of a well understood and static problem. It is more about exploring unknowns and adapting to reality. It is about collaboration and social learning based on knowledge and creativity. It is therefore a more demanding process combining methodology, process, and leadership.
September 29th, 2011
Traditional plan-driven methods focus on keeping to the timetable. Agile methodologies focus on consistently delivering maximum business value. New information and knowledge about a problem are more valuable; therefore, Agile methodologies encourage change and try to make changing requirements and systems less painful. If new knowledge is better let’s adapt and not stick to a plan that is not based on that knowledge. To do this, you need to adapt some practices; otherwise you face too many risks. For example, you need to do a lot of automated tests to validate there are no new bugs.
Don’t Waste Money on Features Never Used
If you’re working with the waterfall model and are in the requirement capture phase, tell the stakeholders, “Give me all your requirements now or it will cost you much more later if you change your mind”. Not planning everything from the start will entail additional costs later. The next phase is the design phase and all required drawings of what’s to be built are produced. If new things are learned during the construction phase, going back and changing EVERYTHING becomes too expensive for the customer. So what does the poor customer do? He tells them everything he might need for fear of not getting what he wants. In a 2002 report from The Standish Group, an investigation was made into failed projects to see how much the built-in features were used. They found that 20% of the features were used either always or often. The interesting part was that 45% of the features were never used. There could be many explanations for why features are never used in a system or product. But if you ask stakeholders to give you all the requirements up front, you end up with a lot of things that will never be used. If you deliver work in small pieces and work first on the first priority and also allow stakeholders to re-prioritize work, this problem can be addressed.
March 30th, 2011
In a world with endless opportunities for information overload, people tend to get pickier about what they spend their time on. Their time is limited and they need to concentrate on relation they value. So who is valued in the knowledge based economy?
In the book “Netocracy” the author Alexander Bard coins a saying that is “Attension value” is the credibility something’s have times the attentions it gets. In order to something to get valuable it need not just to be serious and unique it also need to get a lot of attention.
Value in the knowledge based economy comes from your attention value. Attention value is credibility times the attention something get. Things and ideas that are new and unique, that could be the next big idea. Things that are credibiitiezed but not known are the things people is looking for the next big idea.
March 25th, 2011
Nowadays, a lot of different works are called projects. The nature of a project is to accomplish something specific within a specific period of time and that involves people who normally are performing other functions but are called upon to participate in the project. A project comes about when people form a new group to concentrate their efforts on reaching a specific goal.
A project therefore begins with situation (A) where two systems work fine independently of each other. Then you have a goal (B) whereby integrating these two systems will produce new possibilities. To clarify this, the goal is not to integrate the two systems; the actual goal is the value that is gained when new possibilities arise that would benefit the entire organization after the two systems are joined together.
What is Success?
You might think it strange that I wish to define success. After all, everyone knows what success is, and can readily identify successful people.
But I believe that the concept of success constitutes one of the foundations of this book. Before achieving greater success, I think it’s essential that success is defined in terms of managing a project. Based on my many years’ experience in software management and project management, I define success as: knowing that the value of reaching (B) is greater than the “present situation (A)” + “the journey”.
What is a Successful Project?
To establish that the value of reaching (B) is greater than the “present situation” + “the journey”, the team needed to do the right thing in the right way in an optimal way. This consists of at least 3 different roles.
First, the role of doing the right thing – this involves researching what activities and features could lead to the expected value (B).
Second, the role of doing it the right way – this involves producing the software so that it does the work it is supposed to do according to best practices in software development and based on the rules.
Third, the role of doing it an optimal way - this involves the planning and execution of the project to everyone’s satisfaction. The stakeholders, end users, as well as the development team should be satisfied with respect to both the short term and long term outcomes.
March 13th, 2011
Creating a Project Plan
For all stakeholders and team members to create a mutual understanding of the project’s direction and goals, it’s a good idea to document expectations and the means for meeting those expectations. This is called the project plan.
Depending on the type of project, the purpose of the project plan will differ. If it is a very formal project, it is primarily written for the project client or product owner. The degree of detail contained in the project plan will depend on how formal and plan-driven the customer is and to what extent he wants these details laid out.
The Plan is Worthless, Planning is Everything
Plans are great for complex projects because they set the direction and the alignment of goals. However, the value of the plan decreases over time. Is it realistic to plan all activities upfront? Projects live in a world of constant change and new insights are gained so planning on a detailed level for a six-month timeframe isn’t practical for software projects.
This is one of the foundations of agile methodologies. For the short term, when an overview is created, detailed planning is helpful. But for the long term, a plan is simply to set direction. Discoveries about the project will be made, you become wiser from gaining all that additional knowledge and you change priorities.
The parallel to sailing
I’m a passionate sailor. I have spent my vacations sailing since I was a child. Each morning we plan where to go and what to do. We use charts to see what to expect during the day and which milestones we can establish to make sure we’re on the right track (milestones). When we start sailing we don’t see our goal (destination) so we rely on our milestones and compass. On windy days the waves splash against our boat and the sea looks dramatic. Looking beyond the horizon, the water appears calm. Reaching our final destination is as dramatic as the enormous waves we encounter.
It’s the same with project plans. From a short-term perspective, you get an overview of the drama, but from a long-term perspective, you can only rely on your compass and milestones.
A common timeframe for detailed plans is 3 to 4 weeks. In Scrum, a common iteration is about 3 weeks’ worth of work. In the beginning of these three weeks, the sprint is planned in detail.
Projects are like sailing trips: changes occur often because of the need to adapt to changes in the temperature and oceanic conditions.
There are different ways to start planning the trip from A->B. It can be hard to cope with dependencies and the order in which things are done. A good step is to identify the whole work package in the beginning and then break it down one at a time. Brainstorming will facilitate project delivery. Another way is to start with the goal and go backwards. To deliver we need to submit our application to the AppStore at least 3 weeks before the “release date.” Another 2 weeks is required for testing and other related tasks.
Large and complex projects can be divided into smaller parts and be planned as single units. Milestones serve to monitor progress and allocate resources. A milestone should have a clear goal that is related to the project’s outcome. Milestones are essential in controlling projects. When combining activities with milestones you can make a critical path method, helping you to identify risks of schedule slip-ups if a milestone is missed.
Critical Path Method
Many projects fail to meet scheduled expectations because there is a timetable slip-up in an activity. The Critical Path Method is a technique that is used to predict total project duration and helps control project overruns. The method takes the different activities and relates them. The critical path can be identified, as well as identify the longest path where there are dependencies in relation to other activities (marked red in the diagram underneath). For effective control of activities, these are the ones to watch and monitor.
February 21st, 2011
Aristotle was a Greek philosopher (384 BC – 322 BC) and is one of the most important founding figures in western philosophy. He systemized a lot things and created comprehensive system of the western philosophy within the field of moral, logic, science and politics. He classified knowledge in three different types Episteme (scientific), Techne (Skill and crafts) and Phronesis (Wisdom).
- Episteme (Scientific knowledge) Episteme means “to know” in Greek. This is the kind of knowledge you get from for example books it tells you about the world and how it works, this is the theory of something. This is explicit knowledge that is easy to store and transmit to others. Good example of explicit knowledge (Episteme) is Wikipedia or encyclopedias.
- Techne (Skill and craft knowledge) The greek work Techne translates to craftsmanship, craft, or art. People are not often aware of the knowledge they possess or how it can be valuable to others. This kind of knowledge is not easy to share; you have to learn it yourself by practice. A common example is the ability to ride a bicycle if you have an easy written instruction set on how to ride a bicycle please send me a email so can I forward it to my four year old son. This type of knowledge is of very common in software development and comes with experience.
- Phronesis (Practical wisdom) Phronesis means practical wisdom in Greek, Aristotle distinguishes between sophia and phronesis. Sophia (translated to wisdom) is the ability to think well about the nature of the world, discovering systems why the world is the way it is. Sophia is the ability to find universal truths and theories. Phroneses is the ability to realize how a specific goals or value is reached. Phroneses includes aspects of a situation, critical analytical reflection and for scrutinizing knowledge systems, practices and impacts of goals which easily are take for granted. When having the needed “Episteme” and “Techne” of a specific domain you can develop the capability to find the “right answer” in a particular situation, which is what phronesis is about.
One of the interesting observation is that there is some knowledge that are easy to learn throw studies some that you have to practice yourself and some kind of knowledge are developed through reflection of the scientific knowledge and your craft knowledge of a specific domain which leads to a practical wisdom within that domain.
Other post on knowledge:
February 8th, 2011
In a knowledge-based economy, the core value in creating activity is to use information and to combine it with knowledge produce something more valuable. For example, developing software is justified because the value that comes from the system is more valuable than the cost of producing it. There is no clear definition of what knowledge is or how it’s obtained. Knowledge is a much broader concept than information. To analyze knowledge, a distinction must be made between different kinds of knowledge.
Know-what is about knowing facts. Example are: who is the prime minister of India? Which team won the Stanley Cup in 2006? These kinds of knowledge are easy to obtain simply by “googling” the question. This knowledge is easy to obtain from the Internet. Another example: you can prepare a presentation on Chinese pottery with pictures in less than an hour. In some complex areas, workers must have a lot of this kind of knowledge in order to do their jobs. Lawyers and physicians need to learn many facts for them to be successful.
Know-why knowledge refers to principles and laws of nature. It is the kind of knowledge that underlies technological development and is sometimes referred to as scientific knowledge.
Know-how knowledge is about skills and the capability to do something. This kind of knowledge has more to do with personal competence; for example, a businessman who judges market prospects for a new product, or a personnel manager who selects and trains new staff. This knowledge takes time to obtain and master. You need to practice and get coached; you also have to leave your comfort zone to develop your know-how.
Know-who involves information about who knows what and who knows how to do it. It involves the formation of special relationships, making it possible to get access to domain experts. Know-who is often the knowledge of the internal structure of an organization, network, or a specific industrial domain. In the knowledge economy, it is all about your personal network.
Learning these four kinds of knowledge takes place through different channels. The Know-What and Know-Why are obtained through reading, attending lectures, and checking the Internet. The other two kinds of knowledge are rooted primarily in practical experience.