Posts Tagged ‘Agile’

First version the book Agile Leadership


Av Patrik Malmquist 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.

Yours faithfully

Patrik Malmquist   

Enter your name and email address to download My book Agile Leadership

Name: Email:
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.

Collective Ownership

1 Comment »

Collective ownership encourages everyone to contribute new ideas to all segments of the project. Any developer can change any line of code to add functionality, fix bugs, improve designs or re-factor. No one person becomes a bottle neck for changes. People what are running their own raise becomes dangerous for the rest of the team. If you hear someone says “That module I dare not touch its Lotta’s code, it’s to complex. Only Lotta can do that!” you got a problem. Your “bus-factor” (How many people that need to be run over by the bus in order to need to redo that knowledge) is 1, if Lotta is run over by the buss all knowledge of that is gone. Collective ownership is quite closed linked to the practice of unit testing and continuous integration. In order for people to dare do change and not have 100% overview of how other modules might be affected on an accidental way a lot of automated unit test helps the developer to handle parameters that he don’t know by heart. And in order for everyone to be able to work and overview the project frequent check-ins shall be done. If mastodon check-ins is done, people don’t learn as much from each other’s code and it’s has a tendency of develop into that one single person is responsible for a specific class.

Agila projekt till fastpris!

Comments Off on Agila projekt till fastpris!

(About my talk on the Strategy Day 2011 about Agile and Fixed Price with my college Niklas Florén, it’s in Swedish).


På Sigmas strategidag höll jag i ett föredrag om ”Agila projekt till fastpris” här ser du min presentation.

Pressure and Agility

Comments Off on Pressure and Agility

In a TV episode of the show Mythbuster, Adam and Jamie are investigating what can be done with duct tape. They build a rope bridge that is over 10 meters (30 feet) with duct tape, then they both walk over the bridge. They show that it’s possible to build a 10 meter (30 feet) rope bridge with just duct tape, thanks to its elasticity – it stretches when it’s weighed down.

But there is a difference between Adam and Jamie. Jamie is about 10 pounds heavier than Adam. When the duct tape reaches its maximum elasticity, vibrations start to interfere with the construction. It takes Jamie 5 times longer to climb the bridge than Adam because of the vibrations.

You’re wondering, how does this relate to software development?

When increasing pressure (and expectations) on a group to stretch to their maximum ability, the group needs to focus more on fending off all vibrations than on getting over the bridge. This slows down people. Plan-driven processes are harder to stretch because it isn’t as flexible.

But when working under high pressure, plan-driven processes can be a good thing. It’s when you don’t have clear lines or possibilities that generate much discussion. How far are we prepared to go this time? Can’t we make an exception this time? Can we squeeze that in?  This elasticity creates vibrations and the focus on the project isn’t as good. Negative vibrations become noise as we talked about earlier.  A more bureaucratic organization doesn’t stretch and therefore there is less noise under pressure.

Going back to Adam in Mythbuster, the conclusion is that he might use duct tape to build a bridge, but Jamie, who is 10 pounds heavier would gain if he builds it with rope that doesn’t stretch as much. Using the same argument, high pressure projects probably would gain if they were more bureaucratic, to help project members focus more. Being bureaucratic helps increase focus on a project and keep the speed up.  Too much pressure under uncertain circumstances, on the other hand, lowers the speed because you have to adapt to all vibrations.

A Small Anecdote from my Carrier

My team had plans for a big release in a couple of months.  Two days before the release,  some business managers were nervous about us closing down the system for too many hours. They had pressured another partner and convinced him about the need of the system’s availability and uptime.  So it didn’t look good that we were closing the system for 8 hours on primetime.

They started putting pressure on our development team by asking them to start earlier and finish deployment more quickly. We thought of a way to satisfy this demand.

We worked on a new plan, beginning with doing a full backup starting at 10 pm the day before and closing down the system at 6:00 am instead of 9:00 am. This lowered the planned downtime by 3 hours.

When the vice president started calling specific developers and maintenance personnel, they felt the pressure and focused more on the pressure than on the actual plan. When people felt pressured, quality suffered and the downtime became much longer then planned.

What did this all cost? Coming with an alternative plan took one day and five more people – longer time than if the original plan was executed. Hope it was worth the value of the relationship with our partner.

If you’re always flexible and preach the value of flexibility you could some day be pressured to go a little too far. Everyone probably would have gained if I only dared to stick to the original plan and not allowed a late change. Changing plans the night before actual battle is seldom a good idea.

Have you missed the Dubt tape hour on Mythbusters? Here is the episode MythBusters: Duct Tape Hour 2

Agile means that you are Business Value-Oriented


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.

Agile Testing Practices – Stay Agile not Fragile

Comments Off on Agile Testing Practices – Stay Agile not Fragile

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.

Stay agile not fragile

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.

The Benefits of Fast Iterations


The foundation of Agile methodologies is to work in iterations. This has many benefits:

Benefit # 1: Code that is not used by stakeholders is an inventory cost. If you had a store selling clothes in all models but are not visible to customers, they would never get sold. Their value declines because soon they will be out of fashion.

It’s the same with code. If it isn’t used, you never get real feedback or get the chance to test it. The world around the system constantly changes and soon you will be working on new problems if the code isn’t used. When you move on to new features, this unused code becomes an inventory cost.

A ratio that is used in financial analysis is the stock turnover ratio. Stock turnover ratio = annual sales / average inventory. The average stock is calculated by adding the inventory value at the beginning and end of the year and dividing it by 2. For software development, you could say that the turnover ratio would be “features shipped per year” / “average number of features that are waiting for testing or deployment or not being used by users”.

Benefit # 2: Continuous integration and frequent deliveries generates feedback. Small and fast iterations also mean that the code must constantly be integrated with previous work and frequently delivered to users. This means that the code is tested during integration and also tested by users after it has been developed. If something goes wrong it is better to know about it at once. If you investigate a bug which is the result of work done 6 months ago, the root cause analysis will take some time. But if you get feedback on work done today or recently, you can easily find the root cause.

Benefit # 3: The complexity factor does not become large with small iterations. If you estimate doing two things that are about the same size, you think of the work as a having a linear relationship; that is, if I do twice as much it will take twice as long. If the first thing takes 8 hours and the second one takes 8 hours, you can do it in two days.

But if you have to do both of them in one day with the help of one friend, can it be done in just 8 hours? The answer depends on the dependencies. If both works have dependencies, you need to make sure both parts interact as planned so they don’t interfere or overlap one another.

  • If you have one thing to work with, you’re dealing with only one thing.
  • If you have two things, you deal with them, but you also have to deal with the way they interact and interfere with each other.
  • If you have three things, you have those three things, but at the same time you have three different sets of interaction between pairs of the three, plus you have to deal with the way all three things are combined which leads to seven aspects.
  • If you have four things, you have 15 aspects, and so on.

Therefore, if you have 10 things that are related and dependent on each other, doing them might be 1000 times more complex (or to be exact, 1023 aspects to deal with). The number of dependencies multiplied by the number of things to do result in the following formula: (Aspects to handle = 2 x “the things” – 1). What do these things consist of? It could be number of users’ stories, number of integrated components, number of departments involved, number of people in a discussion.

Benefit # 4: Business value comes from the possibility of adapting to change. When you start a project, the decision to start it comes from the possibility of reaching an expected business value. When the first version of the system is released, not all of the features are perfectly adapted to users’ needs. The system, therefore, doesn’t reach the expected business value.

The longer the system is used, the more the business learns what it takes for the system to reach expectations; however, because the releases are infrequent, the system falls short of its value. After a few years, the system shall have reached its minimum accepted value.

Traditional approach

When an Agile approach is used instead, the first release lacks a lot of expected features but because new versions are frequently released, the system doesn’t fall short of its value over time. Releases are delivered, because new knowledge is used to re-prioritize work. When the system is used for a period of time, expectations tend to rise.

Delivery of Business Value

The most important observation is what this does to the stock turnover ratio, since the delivered value of the system is based on the time the system is used. The delivered business value is the red area, because it creates value when it is used. So using a system early on shows that the value delivered is at least doubled when using the Agile approach.


When the minimum accepted value is reached, business people tend to think they need a whole new system; only this time the original requirement has changed. The priority now is to add features, and to change and adapt the system to new acquired knowledge, re-factoring and updating it with new technologies. In truth, what the business needs is not a completely new system with perfect requirement specifications. What the business needs is to continuously develop their system in new ways.

The Evolution of Leadership Styles

Comments Off on The Evolution of Leadership Styles

In the earliest period of industrialism, Taylor and Fayol created new ways of administering work more efficiently by centralizing power. Earlier, I talked about the planning, organizing, staffing, directing and controlling model. The foundation of this model was that uneducated labor was hired in factories and they where managed by people who controlled the whole process. This was based on the assumption that the manager knew more than the laborer.Evolution of Management

The style by which these managers led others echoed the dictatorial style of  “you do it my way or you don’t do it at all”. As the labor force became more competent, the managers’ roles shifted. Managers learned to delegate parts of the working process in the new “Empowerment style”, “Do this but do it your way…”. When power was decentralized, the creative and innovative energy of employees was released. Management trusted employees more and mistakes were regarded as part of the learning experience.But in a more complex world where the future was more uncertain and managers didn’t know “what should be the right thing” or “How the right thing was done” a new way of management came about.  With Toyota as one of the biggest examples of Kaisen and Lean, everything will improve and will be done just in time.  Consequently, management had to change into “follow me and let’s figure this out together”. It became an exploratory journey. We can’t fully understand the problem until the first solution to the problem is delivered. And we won’t know if it is the right solution. The right solution (what) is discovered along the way and solved in ways never done before (how).  Therefore, what is needed to succeed in this trip into the unknown? This approach enabled Toyota to implement a million new ideas a year.  This is why Toyota made more than twice the money as any other carmaker. Toyota has truly demonstrated what a culture of creativity and innovation can do.

A new kind of “manager”

In traditional non-knowledge-based companies, the title of “Manager” often implies that a person is either responsible for a lot of people or earns a high salary, or both. Nowadays, there are a lot of managers that have neither formal power over people nor earn higher salaries.  instead they are responsible for a specific situation.

They are assigned to be advocates for a specific intention, area or goal. Within this goal, their responsibility is to understand what makes this intention as successful as possible. A project manager is someone who is responsible for making an intellectual journey into the unknown, taking a specific context from one starting position to a much brighter and more valuable future.

Management these days is about taking responsibility for a situation. In Jeffrey Liker’s book “The Toyota WayToyota’s leaders are described as leaders who are clear about the purpose and direction; at the same time they remain close to the business  and have a deep understanding of the work. A manager needs to have a deep understanding of the Value to the customer. The value consists of “the right thing” for the customer and that the work is done “the right way” for the customer.

The Toyota Way

The Agile Reaction

Agile methodologies have been around for a while and have been adapted with varying degrees of success.Agile methodologies constituted a reaction against the more document-driven and plan-driven methodologies like RUP.  But Agile work was also a reaction against the traditional way of management (bureaucratic management and task management).

Software development is true knowledge-based work, which means that the persons in the team doing the work know most about the whole system, not the managers as in a factory. This puts the managers in a new role where other things are demanded.

The Agile Manager – the Knowledge-based Work Leader

If management is more about taking responsibility for a specific situation, value is created primarily by the team’s knowledge and creativity. A friend told me a story about curling. Each curling team consists of 4 players and one is the team leader. Everyone in the team plays stones and helps out with the sweeping. The manager leads the work with the strategy, discussing with each member but at the same time is an active player himself.

Sometimes the players need to get on the track and help the other players out, sweeping in front of other players’ stone to give it the right speed and direction. Agile management is similar to this. the Agile manager is the player that helps out with the knowledge-based work but his most important responsibility is to help others perform as much as possible and to focus on strategy and execution.

When I look at myself and my work, the times that I feel becoming engaged in the “production and operations”, I soon lose sight of the macro perspective of the development.

Plan-driven versus Agile = Predictive versus Adaptive


The inspiration for plan-driven methodologies came from other engineering disciplines such as civil and mechanical engineering. In civil engineering, it is less costly to change requirements during the design stage and it is more expensive to adapt to changes when construction has already started.

Therefore a lot of energy is put into the planning phase. When the drawings are specified and finalized, it is reasonably easy to predict the schedule and budget for the rest of the processes, because both the requirements and the technology are known. Once we have the construction plan, the construction is more predictable. The nature of these projects is to resist changes, because it costs too much to make them after construction has started.

Software development is different.  There is no guarantee that a good design will make construction predictable. In civil engineering, the time spent on construction design is often less than 10% of the project’s total budget.  In software development, it’s more common that over 50% of the total budget is spent on design and understanding requirements. When we adopt the civil engineer’s approach, anything that wasn´t planned causes a problem. We need to reach (B) as planned when the project plan (Time, Money and Scope) was approved.
Predictive vs Adaptive

Construction is less costly in software development.  So why not adapt to change as we learn more during the process? Changes in the requirements during the process of developing a system leads to increased information about the system, and thus enabling better decisions because of this additional information. This is how competitive advantage is gained.

If we could use methodology that allows us to change, we will know more without incurring major costs so it would be a mistake not make the required changes. If our methodology allows this, the output (the system or product) is going to be worth more than the product we would have had have from the original design (C) >= (B).

A Difference View of Success

The plan-driven methodologies defined success as the delivery of agreed functions on time and on budget. But agile methodologies promote the idea that there is something nobler to strive for, because sometimes the customer remains dissatisfied even if he got everything he asked for! This is because he got (B) but at the end of the project, he now wants (C).

Customers also adapt but if they change their mind about what they want and you prefer not to make the requested changes, problems could arise.. Either you or the customer will be disappointed.  Success for Agile methodologies depends on knowing more which makes it better for us to adapt to new goals. This gives the customer what he wants at the end of the project (C).


If customers don’t know what they want when the project ends, how can you design a system in the beginning when you don’t know what the understanding was? If your design isn’t good enough to predict the rest of the work, it won’t be such a good idea to design too much in the beginning of the project.

And if you cannot establish requirements you cannot make a good design and in turn, you cannot get a predictable plan. The Agile approach is to welcome change so if your assumption is proven wrong, you redefine the goal and set new priorities. At the end of the project journey (C) this new goal will be worth more than the first defined goal (B).

Because the customer and stakeholders are allowed to change as they learn more new things, the value of (C) becomes greater than (B). This of course builds on the idea that you manage to deliver (C) according to time and budget restrictions.

The conlusion of 2 be or not 2 be

Summary of the Manuscript

Comments Off on Summary of the Manuscript

The agile leader

Here is a small summary of what I think the book will be about:

This book will be about leadership and management of knowledge-based work.  More particularly, it was  about software development as a knowledge-based discipline. Agile methodologies in software development have implications for organizational agility. The shift to Agile methods signals a larger transformation in the workplace. This transition state is turbulent, marked by continuous change with no clear or easy solutions.

The transformation will result in a state of continuous change. Continuous improvements are indispensable in order to be competitive, whether you like it or not. Changes result in a feeling of being out of control, and when work is about making exploratory journeys you can’t feel comfortable. But you are not alone.

When you leave your comfort zone and undertake an endeavor, it’s natural to feel some hesitation and anxiety.  It’s not a personality flaw, it’s very human to want to maximize our ability to survive, both at sea and in software development projects.

Read the rest of this entry »