This free book is about software development without a word on how to develop software; it’s about everything else around the development of software except programming. More particularly, it’s about software development as a knowledge-based discipline and what might make complex software development more productive. Complex problems has multiple solutions, there is no one BEST way to run a software project. It’s like solving rubrics cube it’s got multiple solutions some better and some not so effective, and some strategies doesn’t solve the problem. This book has a specific audience – people how organize software development.
It’s not finished! If we write software in an iterative and incremental way books would probably gain to be written this way also. So here is my non finished first public version of my book “Agile Leadership – A book about the human factor of software development”. So please enjoy and spread it to people that might like it and give me feedback. It free for non-commercial use and licenses under Creative Common – CC BY-NC-SA 3.0.
Enter your name and email address to download My book Agile Leadership
I collect the e-mail address so you can get notice when I add content. I will automatic send you a PDF when you enter a valid e-mail address.
I’m in Barcelona on World Mobile Congress 2013 and discussing how to mobiles enterprises. When looking on technology today everything seems possible but gap between management and today’s mobile knowledge workers grows faster the more technology evolve.
I work with helping companies develop mobile solutions for their customer or creating new solutions in order to make companies more productive. For me work is an activity not a place. I have an office and an own room but when I’m at the office my main activity is to collaborate with colleagues. When I work with companies that are new to the thoughts of work is an activity and not a place I often hear argument like “how do you know that employees are working when they are at home or working from a location other than the office when you can’t see them?” And that is an important question…
How do you know that employees are doing what they should and are maximally productive in the workplace? Just because you see them does not mean they know what they are doing and how productive they are!
Unfortunately only one answer and it is the same answer as when you’re at work, you yourself must simply be competent in the subject matter and really understand what employees are doing. There is no other way. So do you want more freedom in your job, greater job satisfaction and work when it suits you, you simply get yourself a competent manager. I use the work unfortunately because I don’t know how to tell managers this bitter truth, I often sounds like a “besserwisser” that tells them that they are incompetent.
Managers’ primarily focus show be the WHAT’s but need to understand HOW’s
In a world where work isn’t a place but an activity it requires a different approach. We to have a goal-oriented management style, where we sets goals together. This means that managers need to manage the WHAT things but not the HOW-issues. But at the same time they need to understand the HOW-issues in order to set competent goals.
Employees will leave managers, not companies
This means that people that will work in a world where work is an activity they will need a very competent manager that understands the HOW-issues in order to become successful and productive. In my work stimulating work tasks that’s feels fulfilling are more important than earning a couple of hundred $ more. I can recommend Alaister Lows blog post on this subject.
In a world where work is truly an activity rather than a place it will requires a culture of trust, goal-oriented leadership and competent managers. So next time you change jobs then check how skilled your boss is, it’s not only you should be competent for you to be successful in your work.
The more value a system has for a company the more integration with that system will be performed. When companies grow and processes change due to internal or external changes, more integration is carried out. Integration is a field that developed significantly in the last 10 years. Tasks are more transparent and communication is easier. Technology/Design principals like SOA (Service Oriented Architecture) have been the major accelerators in getting a coherent view through the industry. Here are some recommendations for handling integration projects.
What is Integration?
Integration is making two or more systems “talk” to each other. The interesting thing about integration is that it isn’t two different systems that understand each other, but two different teams that try to agree about how they see the world. Both teams already have a model of the world in their information model.
The Psychology of Who is Integrating Against Who
When integrating two systems, it’s common for team A to feel that they are doing team B a favor because team B is integrating into the team A’s system, and therefore have more to gain from that integration. Team A feels that their information model is the one that team B should adapt to.
Sometimes both teams get the same feeling that they are doing the other team a favor. This causes irritations as each team tries to present evidence that their view of the world is the correct one.
Is it a problem to adapt to the other systems view of “the world” / information model?
If the other team has had more integration experience (either by building them or integrating to several systems), it is probably a good idea to let their view of the world teach you. While your system might be easier to adapt to and your team is more agile than theirs, the other team has to make sure the information model works for a lot of different systems.
How to avoid this?
If this becomes a problem for both systems, meet with the other systems owner and do an effect analysis together. Which benefit will each system gain through integration? Are there any cost benefits or new possibilities? If there are new possibilities for any system, include the people who will gain most by these possibilities.
A business developer might see how and if these possibilities might be “harvested”. If there are no new benefits by integrating, no efficiency gain, no cost reduction, or any new possibilities that can be harvested, integration is discouraged. Another alternative is to get upper management / executive support, either enterprise-wide or between the organizations. Present the new possibilities that integration will bring. It’s always good to have “executive blessing”!
How to use this to benefit your team!
If you fear that your project will be the one that has to adapt to the other team, you can manipulate the situation to your advantage. But do it with caution, because these aren’t exactly “kosher” recommendations.
Conduct the meeting with the other team in your office or conference room. The other team is in your territory and you’re hosting the meeting. The meeting host can set the agenda for discussions.
Be proactive and send out the agenda before the meeting. That way, it’s easier to chair the meeting. If you are conducting the meeting, the other team will feel that they report to you.
Take down minutes of the meeting and send them to all meeting attendees.
If the meeting is via phone or video conferencing, (live meetings) use your account and pay for the facility.
Integration projects tend to have hidden stakeholders. Since there are two organizations to be integrated, one has no knowledge of the other. all stakeholders. For the success of the entire project, it should be made clear that every stakeholder is involved at the beginning of the project. Unfortunately, business people show up only during the testing phase when they should have been present much earlier. In large organizations it also common that there is a specific security department, it becomes very strange when they are not involved early. I has responsible for delivering as system as a supplier to and a week before product delivery the purchaser called and ask if we could have a workshop with the security department and discuss the design and solutions. The purchasor had the prior day accepted all acceptance test so we feelt like this was a bit late in the process to start discussing security design principles might have been better to done this earlier in the project.
The most important success factor in integration projects
The largest factor is relationships – accounting for 53% of success (According to the standish rapport). For integration projects this becomes more important especially when it is carried out between different organizations, each with their goals and views of the world. Communication and building relationships must therefore be done at every level as well as obtaining upper management’s support. Hold regular meetings – for example every Friday after lunch. Things tend to happen on Friday morning when people promise deliveries or need to prepare.
The technical conditions for a more mobile society is really starting to come into place. Since we got a telecom infrastructure in combination with more powerful phones and tablets in combination with cloud services have their mobile motto ”Anywhere, Anytime and Any Device” is created. This has made it possible for those who work in the service sector has many tasks that are no longer tied to a physical location. Work has gone from being a place to being an activity!
This will lead to so much more changes than in technology, we will need to:
We will get a completely new way of relating to work!
We need to reflect on the relations between time and value.
We need training, procedures, systems and practices to show our presence at a distance.
We need training, procedures, systems and practices to collaborate remotely.
We need to shift from a culture of control to a target-oriented leadership.
We will change our physical offices, as we come to the office for another reason.
We will often work harder in places other than the office. I myself often sit in cafe’s, libraries and hotel environments.
We will digitize all new processes and situations.
It’s important to acquire new “best-practices” for this change. Some call it a paradigm shift, but I think it is more about evolution than revolution. Personally, it fits very good to sit at home and work when I have a deadline to relate to. But worse if I just work at all, need to cooperate and coordinate different tasks with others. So the work life is changing, our digital work life will become much more mobile in the future.
When talking about agile projects many books seems to be written under the assumption that you work with the whole life cycle, from its initial conception to maintenance and support of the system. But quite often, parts of the project are done by another supplier. This other supplier may have a different underlying motivation and his business may not be the same. The most common price unit in knowledge-based work is probably price per hour, direct or indirect. The buyer’s income model is probably different; it may be based on cost savings, or on either revenue from or new opportunities emerging from the product (or transaction), or interval based, such as price per month. Therefore, a built-in conflict may exist between the revenue model for the buyer and that of the supplier.
Who should take the commercial risk?
The buyer can handle the project on their own and just hire or contract some consultants that will work on a per-hour basis, in which case the full risk remains with the buyer. Or the buyer can outsource a part of the project to a supplier, who also takes an agreed-upon portion of the risk as part of the deal.
This is often handled with a requirement phase that produces a requirement document that one or more suppliers use to develop a bid for winning the contract from the buyer. The contracts often include the total cost, some options (often add-ons) and a time when the delivery shall be done.
The problem with this is that it doesn’t facilitate changes and the flexibility to apply knowledge that you gain during the project very easily. When the project starts, keeping to the original plan becomes more important for both parties instead of maximizing the business value. This prevents either party from incurring cost or schedule overruns that could turn their side of the contract into a losing proposition.
This inflexibility negates the benefits of agile development projects, which are adaptive so as to maximize business value. But there are alternatives to fixed-scope/fix-price types of contracts. I will talk about different kinds of contracts soon but first I would like to explain maximal value focused.
Continuous integration is a way to applying quality control by integrates pieces by pieces of effort into project. When embarking a change, the developer takes a copy of the current code base on which he works on. As other developers submit changed code to the code repository, this copy gradually cease to reflect the repository code. When the developer submits his code to the repository they must first update their code to reflect the changes in the repository since they took their copy. If a lot of changes have happen to the repository, the more work the developer must do before submitting their own changes. If the repository becomes so different from the copy the developer is working on it becomes what is called as “integration hell”, where the time it takes to integrate exceeds the time it took to make their original changes. In a worst-cast scenario, the developer may have to discard their changes and redo the work. In order to avoid “integration hell” the practice of continuous integration is used. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.
One warning when adapting CI!
The focus of integration and automated builds leads to a false feeling of secure, as long as it builds and all tests passes people tend to be satisfied. But in order to gain all benefits that you strive for, like getting feedback on just work done these test isn’t enough. In order to be as productive as possible you need to really test as close to the development as possible. You will save a lot of time if you find a bug or mistake that you done today or this week, rather something someone may have done to the code base during the last 6 month.
Continuous integration is like one apple a day, it keeps the debug doctor away. But it doesn’t gain its full power if you also complements with frequent testing and verification of the system.
How to separate different aspects of a project in which the modules are tightly bound together can be a real challenge. If many people are involved in solving a complex project, it can be hard to decide how closely together everyone should work. Shall we have collective ownership or a hard pre-defined contract between modules and different aspects?
Mel Conway wrote in his book “How Do Committees Invent?” that “organizations which design systems are constrained to produce designs which are copies of the communication structure of these organizations”. When people are dependent on people in other parts of the organization, a conflict of interest can easily appear. People might share the same view today, but in the future, someone’s boss might set different priorities. When that happens, one team will follow its own objectives and might not prioritize another group’s needs as highly as their own. The further away people are from each other, the more disjointed and incongruous their objectives are likely to be.
People working in the same room can easily discuss things spontaneously within the room, or on a short notice attend a design meeting within the room. People on different floors start booking meetings with each other, either officially or in more informal settings such as over a cup of coffee. People on different offices write memos and specifications to each other have phone meetings and occasionally meet each other in real life. When people are geographically separated from each other, have different underlying motivations or are in a different part of an organization, clearer contract of responsibility and modularization is needed.
Making business more mobile is about making your digital work life as mobile as your digital private life. Thanks to social media like facebook, twitter and cloud service like mobile me, dropbox, exchange, etc. our digital private life is totally mobile. Success within Enterprise Mobility is about enabling the same kinds of flexibility within a work context in a secure and flexible way. When we are traveling we like to be able to work with the same routines and processes that we can at the office. For business to be able to enable this to understand how mobility change the view on security, strategies for multiple channels, SOA, Integrations platforms and strategies for mobile phones and devices. But also understand softer values as change methodologies and tools for collaboration to succeed in a changing world. This and much more is my presentation from the Camp Digital conference 2012. Here is a film from the presentation.
Another important concept in agile software development methodologies is technical debt. When you write code you don’t fully understand a problem until you are finished solving it. This means that your application isn’t designed and implemented the way you would have if you were to do it again. If you continue to add functionality and features to this application without aligning the code to what you have learned and understood about the domain, there could be disagreement. This disagreement between understanding of the domain and reality will lead to a decrease in the rate of development. Ward Cunningham called this technical debt; he did an economic analogy to software development to explain code quality.
When you write code, you make a monetary or time investment to understand and solve a problem. And time is money. You have limited resources at your disposal so you prioritize the use of these resources in solving the problem. To meet deadline, shortcuts can be taken. This means that the job can be completed more quickly, but in doing so, time had to be borrowed. Time, as stated, is money.
When you borrow money, you pay interest until the loan is paid in full. It’s the same in software development. If you don’t re-factor your application and align with newly discovered insights about the problem or fix previous shortcuts, you need to adjust other parts of the system. However, this adjustment is in vain because the other parts don’t align with how it should have been built based on current or newly acquired knowledge.
Every minute spent on the wrong code is time spent in vain. It lowers the speed of solving the real business issues. If you keep borrowing money and not paying it back,this eventually leads to your income going to interest payments, bringing down your purchasing power to zero. It’s the same as developing a program for a long period of time and only adding features without reorganizing them for a better understanding of how they work. This translates into very low productivity.
A friend told me that his latest consultant assignment involved a project with a very large technical debt. He was added to the project very late in the development cycle, and he felt like an archaeologist trying to clean up an artifact that would crumble unless he worked very slowly and cautiously. This project had been running for three years and it was now one year late.
When several programmers pointed out that the problem arose because the project was not aligned with the system and did not take into account the new knowledge and understanding of the domain. Management’s comment was there was no time for refactoring as there were only 10 months left according to their earned value analysis, so the decision was to add the last feature. My friend left after a year and the project was only 90% complete.
What happens knowledge is not synchronized with code?
Management indirectly state that they don’t appreciate quality in the long run. If it’s not appreciated in the long run, it might not be so important in the short run either. If you are not allowed to take pride in your craftsmanship you will not do your best, because it doesn’t matter. Mikael Feathers author/blogger says, “We need to see clean flexible code as an asset and count it as an asset.” Whether it depends on deadlines, dispersed teams, or unfamiliarity with a new technology, it’s easier to let code rot than keep it up to date.
I found a great video with Ward Cunningham when he explains Technical Debt that I have to share with you:
On the mobile developer conference Devmobile in Gothenburg I talked about “What suites our users best in term of the mobile channel!”. It was real crowded and over 110 people (too bad the conference room only had 70 chairs!) attend my break out session about what pros and cons for different solutions regarding. I have got rather many questions and contacts after this speak which is real fun. Here are my slides if you interested!
Cooking is one activity that I have organized a couple of times with my development teams. It’s a good way to share common experiences and to get to know each other outside the office. When we were in a restaurant one evening, the chef in charge told us about yesterday’s session. They had a group from an organization that was very hierarchical. No one dared to show they were more knowledgeable than their boss and no one dared to be different from their boss. No one dared doing anything they haven’t done before, because they didn’t want to risk failure. When no one dares to risk anything or go outside their comfort zone, the food turned out to be very ordinary, and no one enjoyed the meal.
It’s the same with software development – if differences are accepted and group members take advantage of differences, the project tends to be better adapted to the needs of customers. If no one does something different or takes risks, the capacity of the team is minimal and is only based on what members know as accepted.
Milestones are like a progress bar indicators for internal stakeholders, they give everyone involved feedback on the progress. In different software I have come across at least three different progress bars, the first quite easily reach 90% then stalling and you’re wondering if stopped. The second one just shows that it’s working and never stall but you don’t know how much work that’s left. The third one gives you the feeling that it’s accurate and that it’s adopt in order to give you a realistic estimate. Even if the progress bar says it’s a long time left you prefer that because then you can do something else. Sincere (Swedish: uppriktigt) estimation is more valuable than working in the dark and hoping that the first 50% of the work will be evidence that the 50% of the remaining work. But this is not so easy as it sounds. Let’s look on some aspects of tracing progress.
Your project is getting closer to a release deadline and you ask the lead developer, “How’s is it going? Are we going to ship in time?”
“Hmm, something have come up!”, she tells you, “I have done really great for the last 4 weeks, but today I found something no one have thought of and the timetable slipped 3 month.” How big chance is that? Quite small I will say. Because timetable slips don’t happen at the end of the milestone or project. Slips just show up at the end. But they happen every day and every hour. As soon someone answers an unexpected e-mail, have to be home with sick kids or tracking down an intermittent but catastrophic bug, slips happens. These things are also important and needs to be done but the sooner you can identify how much that’s left and if there is a timetable slipping risks the better time estimation it will result in. Team members and stakeholders will be more able to trust the timetable.
This week I was speaking on “Projektverktygsdagen 2012” to inspire the 250 project. My presentation focused on why enterprise mobility is important to keep an eye on as a project manager in a knowledge company. It was also about what enterprise mobility is and what opportunities it creates. Then I took with some examples of tools for managing knowledge workers in a creative situation by demonstrating a little google docs. Here is my speak if you like to watch it:
Processes and methodologies are great for some kinds of work. If you have a repeatable process that consistently yields a high quality product, you can emulate McDonalds’ approach and hire teens to be chefs. But at McDonalds you will not find the next Gordon Ramsey. People that really want to understand and master their craft will not achieve that in a repeatable industrial process.
Well documented processes are a great foundation for any part of a company when you working with a repeatable process or don’t have a dream team of smart, disciplined and attentive people whose work is more of an exploratory journey. A process helps people to align their collaboration and work at getting better at repeatable tasks. Processes are also good to be run from a checklist so that people don’t forget things, especially when they rarely or never do a specific task.
ITIL is the McDonalds process concept for governance of infrastructure and solutions. ITIL isn’t the process used by creative advertising agency that is looking for best and maximal business value. Software Development is more complex and isn’t a software factory that has a universal solution.
What software development organization need is a reflective improvement framework, with a wide range of tools to choose from. Some tools and practices are designed to help a larger group to collaborate whereas others just focus on quality aspects. There is no universal solutions for complex work, McDonalds approach might work for handling infrastructure and teens in a kitchen but handling complex change in a high tech work where nothing stays long enough to be normal isn’t a solutions.
According to Wikipedia, an expert, more generally, is a person with extensive knowledge or ability based on research, experience, or occupation and in a particular area of study. For me an expert is someone that intuitively knows the right answers and is able to draw conclusions about future events and to predict their outcome. Experts have gained intense experience through prolonged practice and education in a particular field. Let’s analyze how one becomes an expert.
In Japan, there is a concept that describes the stages of learning to gain mastery in a domain. It is called shuhari. Shuhari is roughly translated is to Learn, Detach, and Transcend. Shuhari describes how skill is acquired.
In the “Shu” stage you learn the fundamental techniques – the traditional wisdom.
In the “Ha” stage you start looking into similar areas and techniques, and collect new methodologies and tools.
And in the “Ri” stage (mastery) you mix techniques to do or make the best solution.
To develop personal competence and gain wisdom, you will need to learn many techniques. You will have to leave your comfort zone and take risks to gain new personal experience. At the same time, you need to ensure quality, which means not just getting things done but also getting it right, even if it is more painful. When you combine this with analytical reflection about what works in a situation and what might work better next time, you gain more insight.
Becoming an Expert
Follow and learn
Learn a technique
Collect related techniques
With the concept of Shuhari in mind, you can reflect on the best technology, process or methodology. How many times have people debated about which of these solutions is the best?
.Net, or Java?
iOS, or Android?
Windows, or Linux?
Scrum, or RUP?
People who just learned a tool and are trying to master that tool are often quite loyal; they try to solve everything with that tool. If you have only a hammer, your perception will be limited to everything being a nail. To become an expert, you need some time to leave the comfort zone and use a tool like you have not been used. Therefore expertise begins with curiosity, humility and willingness to learn something new.
Development is mentally difficult because that’s what we need to reconsider ourselves. Many of us have learned through years of socialization and school systems that being right is good. If you are right you are rewarded, and if you are wrong you are punished.
As a result, many people become obsessed with being “right”. But what does this lead to? It convinces us that one way is more “right” than others and that which is different is wrong. To develop, you have to realize that the way things were done before was not necessarily optimal for its outcome, therefore you were wrong. If prestige was involved in the “right” way, it is difficult to re-evaluate the situation and develop. So the feeling of being right can be dangerous because it doesn’t help us develop.
Up until the nineteenth century, most people were engaged in agriculture; others learned a craft like carpentry. They were organized in small communities and worked together from sowing seeds to harvesting, milling, and baking. To be successful they needed to learn and master a specific craft that was passed from person to person, often within the same family. The real master of the community then decided to leave the comfort zone to explore things that no one dared to explore. Most of the time, these exploratory ventures ended in failure. But sometimes, the adventurer would stumble upon something that opened new doors for them and eventually for future generations as well.
As late as 1870, 80% of Europe’s population worked in agriculture. In 2010, less than 0.8% of Europeans worked in farming. This demonstrates an enormous productivity gain for farming. And then in the 18th and 19th centuries, a major change happened: manufacturing shifted from manual labor toward machine-based manufacturing. It started with the mechanization of the textile industries and the introduction of steam power. This also changed the organization of work, where people specialized in a particular phase of the work instead of getting involved in the whole process. By specializing in a specific time/phase-based work, Henry Ford was the first to increase productivity in car manufacturing by using assembly lines for mass production.
To make manufacturing as efficient as possible, managers were needed to oversee the whole process. It was during this era that the first management theories and business schools began teaching what Mary Parker Follett (1868-1993) termed the“art of getting things done through people”.
Lesson Learned from Craftmanship & Industrialization
Craftsmanship is building on experience and can lead us in the right direction, but experience will only take us so far into uncharted territory. In these instances, we must take what we started with and rely on controlled methodologies and engineering tools. Engineering is the application of tools and methodologies to handle the unexplored.
Craftsmanship is critical to knowledge based work in terms of providing quality, whereas in industrialization, quantity was the primary measurement. Allan Cooper, author of “Running with the Inmates” and inventor of Visual Basic, said the following about craftsmanship:
“Craftsmanship is all about quality – it’s all about getting it right, not to get it fast. It’s measured by quality, not speed. It’s a pure measurement, and a delightful one.”
“Craftsmen do it over and over again until they get it right. In their training, they build things over and over so they get the experience they need to get it right.”, more info see.
I do not fully agree with Allan Cooper because good craftsmanship must strike a balance between quality and time/cost. This demonstrates the concept of personal competence but this also has a disadvantage. I’d like to quote one of my favorite bloggers – Joel Spolsky – on his view on craftsmanship. “Craftsmanship is, of course, incredibly expensive. The only way you can afford it is when you are developing software for a mass audience. Sorry, but internal HR applications developed at insurance companies are never going to reach this level of craftsmanship because there simply aren’t enough users to spread the extra cost out.”
A craftsman takes pride in his profession, his experience, and his tools. Because his performance is based on his personal competence, he prioritizes the mastery of his tools, upgrading them and improving his work methods in an evolutionary way. Craftsmen prioritize their continuous improvement and appreciate quality because they know that their product becomes more valuable when done the right way. They know that quick-fixes will rarely be successful in the long run, because that can require more work (and less profit to them) to remedy.
The most important lesson learned from industrialization was that deterministic goals and processes are better achieved by investing in structure capital (developing process / routines and establishing them). This especially applies to a process that is 10% design/analysis and 90% production. A changed requirement after the production phase has begun can be very expensive. Software developments of product and unique system aren’t like this design isn’t just a one thing you do before production is started.
For example, when building a bridge, you can’t consider adding a few new highway lanes when the bridge construction has started. Complex software development isn’t a deterministic process and is therefore more of 50% design (where you figure out what to do and where to go) and 50% production. Following a plan is therefore not the ultimate solution it’s to be prepared and know you domain and tools so that new knowledge present itself you can take the opportunity.
Throughout history, success factors for work have changed and gone from individually mastered methods of efficiency and quality to a world where craftsmanship was learned and handed down from generation to generation. During the 18th and 19th centuries, the industrial revolution changed the key success factors into pre-defined processes that were mechanized, automated and as efficient as possible.
In a world that changes every day, differentiation and uniqueness come from transforming information into a product through creativity and knowledge. The most important considerations for knowledge-based companies are how good they are in getting the best information and then transforming that information into products or services, through their creativity and knowledge. But in a complex world where goals are uncertain and there is more of a need to explore possibilities, success is increasingly dependent on collaboration, creativity, and knowledge.
In my new role as Enterprise Mobility Manager for Sigma I have work with marketing of Enterprise Mobility solutions. In this role I do a lot of public speaking which is a new thing for me, both terrifying and fun. I have done 5 public speaks on different conferences so far this year and I will do some more this spring. It’s about Sigma’s products and solutions, and the demand of a strategy for companies in times of change. Mobility affects everyone and companies has a lot to gain from mobility, business change and so do behavior and the need of a different kind of leadership. If you like to hear me speak this spring you can hear me on some of the following conferences: