Agile Product Development

Lean & Agile Value Suite

2012-08-22T11:06:00.000+02:00

The strength of Lean & Agile originates from the level of its mindset and values, not from the level of some specific framework alone. There is no better way to evangelize your teams than by referring to the roots. How often do you do that?

The subject I have been exploring recently is the shape and the structure of the Lean & Agile Value Suite based on Lean & Agile mindsets presented in Agile Manifesto and Lean "manifestos" by Mary Poppendieck and David J. Andreson.

The goals of my work are:

Identify the set of Lean and Agile values
Discover relations among them
Identify the baseline - the set of core values causing the whole eco-system to function and grow.

My understanding is still evolving. I am sure this is not the final version :) Anyway, let me know your thoughts! I encourage you to draw your own version of the concept map - this is so exciting!

Re: Velocity - The Agile vanity metrics

2012-03-21T01:23:00.001+01:00

I bumped onto a very interesting post the other day on Velocity - the Agile vanity metrics. It challenges core Agile metrics indicators: Velocity and Time Remaining.

I must say this is a very interesting post. It represents an opinion that is quite common these days, I am afraid. Plus the post is nicely wrapped into the guesswork-as-an-integer-value slogan ;)

Fortunately, the situation is not that bad in my opinion – one just needs to stop mixing apples with peaches in a single basket. Here are my thoughts:

1. Estimation, velocity, time remaining, etc. are concepts that build one of a long list of statistical models aimed to predict work completion date. Usage of models throughout disciplines of science is indispensable. Still, when using a model one needs to keep in mind its nature and built-in limitations (e.g. one cannot apply classic physics to atom-scale phenomenon – it needs to be described by quantum model.).

2. Estimation only becomes “guesswork described as an integer value” when someone, usually a development manager or sales department, grabs the estimates and turns these into a commitment expressed in number of days. Such approach clearly violates the core assumption behind statistical model predicting work completion date – estimations are not commitment, estimations represent current development team’s understanding and assessment of complexity of what is to be done.

The proper question here is why let the bad guys turn estimations into commitment? Or in the wider context, the question is why have we been letting them do this for 30+ years?
Agile is on the scene for 10+ years now, so it’s time to get out of the estimation-turned-into-commitment-behind-the-scenes ghetto. The true answer to meeting deadlines is variable scope!

3. Activity metrics serves to feed current data into the statistical model aimed to predict work completion date. There is nothing wrong with it. On the other hand, actionable metrics remains in the domain of project owner’s accountability. Although this responsibility can be delegated to a develoment team, activity metrics is an independent topic having nothing to do with the statistical model of predicting work completion date. No reason to blame statistical models for not meeting business goals.

Development Team management

2011-11-23T02:29:00.001+01:00

The whole range of various approaches to managing development team extends between two ends: PM-centric micromanagement and PM encouraged self-organization. One may expect a tendency that junior PMs more often start from the former one. Junior PMs stick strictly to controlling execution of all micro-tasks as a result of their lack of appropriate level of trust and/or courage to delegate work to development teams. As time elapses and junior PMs gain more experience they gradually shift towards the latter option of modelling self-organization of development teams facilitated by task delegation and self-organization moderation techniques. The difference between these two edge approaches boils down to a difference between feeding starving people with fish and providing them with a fishing rod. Variety of intermediate attitudes towards managing development teams exist between these two edge approaches – the road to mastership takes time.

Let’s have a closer look into the two edge approaches first to then switch to discussion of Scrum’s built-in team management model and organizational aspects which need to be considered when deciding for appropriate approach of development management for a particular project.

Micromanagement

The first approach – the micromanagement – focuses on addressing current project’s and development team members’ needs and current matters. PM is highly involved in all current issues irrespective of how minor they are. S/he tries to cover all aspects of a project and be involved in literally every activity within the project. This is a natural approach for beginners who personally commit to deliver a project. However such an approach creates handicaps for other participants of the project. First of all it means that decision making gets fully centralized on the PM. A Team lacks motivation for proactive behaviours as nothing can happen without PM's knowledge and decision. Thus the Team switches to a passive mode of waiting to be assigned successive technical tasks. Development team members focus on individual tasks that get assigned to them. This is very uncomfortable for individual team members as it significantly limits their natural need to make use of their intellectual potential. At the same time they focus less on business goals a Product Owner wants to achieve. They shift this responsibility to PM as s/he keeps it all under control. Some individuals like such setups because these let them stick to their comfort zones. Some others do not like such setups as they, in some sense, feel uncomfortable to compete with the PM for responsibility even if they feel they are in a better position to handle particular area of the project. Both cases are harmful to the project. Such environment, created by over-acting PM, seriously decreases development team’s empowerment and commitment. A Team can never become more mature under the above circumstances – it is simply not given a chance to grow its maturity.

This mode of PM work is called micromanagement approach to development team management and project management in general. (BTW I think Wikipedia takes it to extreme referencing obsessive–compulsive personality disorder as the root cause for micromanagement practices and behaviours). Personally I also call this approach PM-centric management as opposed to team centric management. It is needless to say that micromanagement has destructive results in long term, not only negative connotations. In fact micromanagement is one of the classic managerial anti-patterns.

Please notice that a need for micromanagement may originate not only from PM, but also from development team. Usually this is the case with just-created teams that are still progressing on their way to establish initial self-organization or teams that expect to be micro-managed based on past experience. The former case is pretty healthy – development team can and should expect a PM to support them towards mature self-organization. After all, it is one of major goals of PM’s work. The latter case, on the contrary, is a clear sign of malformed organization culture and solving it is more of a matter of organizational effort to change the existing culture. A PM should discuss limitations s/he sees in the current model and her proposals for change using channels and mechanisms existing in a company for these purposes rather than begin a lonely struggle with introducing the culture change locally.

Notice that as long as the former PM's approach will be perceived well as a proactive action to building company’s culture, the latter approach can be assessed as an individual battle against the rest of the world. Any attempts of PM to change the culture locally – exclusively in his projects – must be undertaken very carefully and as a matter of fact have limited chances to be successful. Such attempts may result in tensions between a PM and those of development team members who got used to the so-far reality. They will hide their impedance for change and preference to stay in their comfort zone behind arguments praising value of existing processes and culture. For them it is more of a PM problem to adjust to the existing organization culture. This is all understandable. Avoiding the change is quite natural for some of us and one of quite reasonable approaches to change management ;). My recommendation in such cases is to start work on altering organizational culture using existing company’s channels dedicated for such purposes. The changes to existing reality will be much easier pushed through and communicated to teams by people / committees / bodies widely recognized as accountable for area of organization culture, i.e. heads of practices or heads of project management, PMO, etc.

Self-organization of Development Team

The second approach – PM encouraged / moderated self-organization – is a complete opposite of the micromanagement approach. This is a Team-centric approach. In this approach a PM lets Development Team take full ownership of technical aspects of a project. PM herself stays at a level of business requirements and not their technical solutions. In other words PM’s duty is to answer question What and When? and Development Team’s duty is to answer question How? From the Development Team’s perspective such approach opens door for all the goodness. It values intelligence of individual team members and lets them reveal their intellectual potential. It lets individual team members gain a chance to become fully productive and empowered. At the same time ability to make decisions leverages everybody’s commitment and responsibility to deliver high quality software.

The above work environment models a Team world according to one of the key principles to managers for transforming business effectiveness given back in 1980s by W. Edward Deming - it removes barriers that rob people in engineering of their right to pride of workmanship.

From a PM’s perspective Team's self-organization takes PM’s thinking a few levels higher to a wider timescale perspective which allows focusing attention to systematic long-term resolution of core managerial issues and process improvements. A PM's mind is reliefed from the burden of low-level details and free to focus on core aspects of her work. Still a PM remains 100% responsible for moderating the process of development team self-organization. See Mike Cohn’s Succeeding with Agile book for discussion on PM’s options to influence Team’s self-organization.

Scrum’s built-in approach

The Agile methodologies rely deeply on the notion of self-organizing teams. In fact, self-organization is a core building block for all of them. There is a clear shift of responsibility down onto individual members of Development Team. The world is not PM-driven and not PM-centric anymore - the world is Team-driven and Team-centric. PM is not a member of a Team anymore. This is only possible through empowerment of individuals and acceptance of responsibility by them. As a result PM’s position is, by design, in the areas facilitating the above notions more than anywhere else. Yes, Agile defines self-organization as its built-in development team management model, not leaving much space for PM to choose his favourite development management model. Agile PMs fall into PM-moderated/encouraged self-organization approach by the nature of things, or should I say by the nature of the Agile development management model.

And here comes the difficult part – self-organization it is not granted for free to every organization starting from day one – Agile does not work out-of-the-box, one cannot switch from waterfall to Agile with a single managerial decision. Why? Because Agile needs mature Teams that are ready to accept responsibility as decisions will not be coming down from a PM in a ready-to-process form any more. Your development team may not be ready for this. For some reasons a development team may not be mature enough to accept the challenge. This can have root cause in either some reason internal to the team, e.g. lack of experience, sticking to good-old habits or equally well in shortcomings of a PM not fully facilitating agile management responsibilities.

One of my favourite quotations, originating from eastern culture says: Achieving your goal does not matter; it is getting there which matters. The whole journey of getting there to the stage of mature self-organization of development teams in its full extent starts from initial team’s immaturity and complete reliance on a project manager. Getting there is a process that takes time and needs sponsors and as such getting there should be treated as a long-term investment in ability of the organization to deliver quality software. There is no doubt about it - getting there to mature teams' self-organization is a process that needs to take place on the organization level and be conducted as a change of organizational culture.

So before overeagerly claiming your organization is Agile, as too many organizations do nowadays, just because there are daily standups implemented here and there I recommend you to take a conscious and responsible approach to take a step back and see where you are. The first step is to accept the fact that getting there needs practice towards reaching the state where the self-organization has a chance to succeed.

Self-organizing Teams - preparation

It would be really optimistic to assume that the process of leading your team to full maturity is your individual decision and that it can be happening during project execution at arbitrary time of your choice. More realistically various factors need to be taken into account. It matters whether you work for software vendor or in an internal IT department of a non-IT company. It matters what delivery model you are obliged to follow – this can be anything between Fixed Price Fixed Time and Time & Material. Finally it matters who your sponsor is and what his needs are. What is the sponsor’s level of awareness wrt goals of the transformation? Is your sponsor ready to accept additional time and money spend to go through the transformation process to pay off in a long-term by increased ability of your team to deliver quality software? The key pre-requisite factors of the transformation process that need to be agreed up-front are:

recognition of the transformation process as a long-term investment on the organizational level
conscious execution of the transformation as a part of a particular carefully selected project
project sponsors fully aware of the attempt of the transformation
well defined sponsors of the transformation
level of transformation transparency agreed with project sponsors

In my opinion it takes very conscious and mature client to understand long-term benefits of the transformation. It is even harder to find a sponsor who, understanding the need, decides to go for it – very rarely sponsors themselves are rewarded for long-term results. Speaking from my experience, after 10+ years of Scrum on the scene, it is still difficult to step across such mature clients and organizations. Agile became attractive and well perceived as a sales item in RFPs, but this is rarely reflected on project management level.

One other thing is worth noticing when considering the transformation – in the aforementioned book Cohn is able to plot a diagram showing level of Scrum Master’s involvement throughout a process of Team’s way to full maturity. As one can expect the initial involvement starts on highest level to fall down to lowest levels when the transformation is done.

Self-organizing Teams - Getting there

If you are given a chance to grow you team by project sponsors – take it – it may not repeat for the second time. You may wish to make the change in steps.

The classic Hersey’s and Blanchard’s team leadership model - Situational Leadership theory may be of help. The SL Model defines four phases of team’s evolution and PM’s involvement in leadership:

· Telling – full Team reliance on PM and his instructions,

· Selling – PM gradually buys Individuals into the decisive process,

· Participating – shared decision making between PM and Team, and

· Delegation – Team fully responsible for decisions

As one can see Telling level corresponds to the micromanagement approach while Delegation level corresponds to Agile’s PM encouraged self-organization approach. Selling and Participating intermediate phases let you drive the transformation more smoothly.

In parallel, Tuckman's stages of group development aka Forming-Storming-Norming-Performing model of group development may be of help. Again, the model is based on four phases in which the corresponding PM's role is defined:

Forming - the forming of the team takes place; Supervisors of the team tend to need to be directive during this phase.
Storming - different ideas compete for consideration; Supervisors of the team during this phase may be more accessible, but tend to remain directive in their guidance of decision-making and professional behavior.
Norming - The team manages to have one goal and come to a mutual plan for the team at this stage.

Performing - It is possible for some teams to reach the performing stage. These high-performing teams are able to function as a unit as they find ways to get the job done smoothly and effectively without inappropriate conflict or the need for external supervision. By this time, they are motivated and knowledgeable. The team members are now competent, autonomous and able to handle the decision-making process without supervision. Supervisors of the team during this phase are almost always participative. The team will make most of the necessary decisions.

Backbone idea driving the above models is that Team has a lifespan, it needs time to grow mature and it needs help on its way to maturity. Please notice that the kind of help they need has nothing to do with micromanagement. The process of growing mature is not driven by any sort of a PM -it is a natural process. All they need from a PM and Organization is encouragement, motivation, freedom, moderation and support.

During the transformation you need to constantly take into account that getting there needs changes to organization’s culture as well as mental changes of individuals. You may need organizational help in this aspect.

Summary

Scrum, as well as other Agile development methodologies, like Kanban, are based on most mature Team organization level – delegation aka self-organization. The underlying scientific model of the team maturity phases was created back in 1970s by behavioral scientists. I will not be surprised if this is eye-opener for many of you. It was for me too! One may ask: But wait, weren't I told that Agile is a simplified version of managing development? That it is all lightweight and straightforward to use?! Well, yes, I am sure you were told this all... I am just not sure you were ever told about the work and time necessary to build Team's maturity level high enough to fulfill Scrum's pre-requisites and most importantly – how to get there.

I personally believe that this work is only necessary because of bad-old habits - the way organizations got used to work. For years people were told exactly the opposite – to follow the instructions from one’s boss and not to think too much about wider perspective - the exact copy from the Ford's production model. Luckily some of you work in organizations understanding a need for continuous improvement and willing to invest time and money in researching ways to improve business effectiveness. If you are not that lucky - find some time to re-think your current professional situation.

Side note 1: Planning management of development team in Organization

Having said that there exists the whole spectrum of approaches to managing a development team, one needs to notice that every PM has its own preferred approach to managing teams. This is something s/he has worked out throughout her career. It is a very individual thing originating from a mixture of factors characterizing an individual PM: domain knowledge, personality and experience in terms of work environments, teams, methodologies, contractual models, etc.

On the other hand each organization has worked out its level of maturity throughout the years of its existence. Again, it is quite individual thing originating from a mixture of factors: how projects were executed in the past, how mature teams are, and also the company’s culture.

Team’s maturity always reflects company’s maturity. The same is also true for Team’s culture. There exist differences between individual teams, but the correlation with company’s maturity and culture is always there.

So how should an organization plan management of development team in order to execute a project successfully or at least in a controllable manner?

First one needs to select a development team management approach corresponding to the assessed development team’s maturity level. Having identified the match one then needs to find a PM capable of managing the development team according to the above parameters.

Side note 2: Attempts of unification

As usually one needs to be careful and sustain temptation of making assumption that projects are executed uniformly across the organization. I think it is much safer and feasible to assume the opposite. A degree of formalization of project management and software delivery methodologies does not influence the uniformity of project execution much. Please notice that except from the factors that can be uniformed like delivery methodologies there exist factors of other natures that cannot be uniformed. I can see at least two groups of these: 1. the above mentioned human nature specific factors characterizing individual PM, and 2. variety of business domains and characteristics of clients for which projects are executed.

Unification of project execution should focus on pointing a PMs the right place on the whole spectrum of choices rather than on nailing down a list of uniforming rules and / or processes. The approach to development management selected on the scale of options should be the one most closely corresponding to company’s reality at the current level of growth and maturity.

Notice that the not recommended approach of producing lists of uniforming rules / processes is also based on assessment of the best matching project execution model from the same spectrum of choices. However the assessment is not done by a PM and is made implicit to a PM. Instead a PM is given a hardcoded list of processes produced based on the implicit assessment. As a result a PM does not have a chance to understand to full picture, and underlying layers of logic, but is limited to follow the already processed information. This can be and usually is quite misleading and what is worse leads to nowhere in the long perspective.

PM encouraged self-organization

2011-10-08T00:42:00.000+02:00

Similarly to Organization leaving maximal freedom to a PM (see PM Rules vs Organization Rules post), a PM is responsible to leave as much freedom for Development Teams as possible. My experience shows that trials to impose uniform cross-project set of rules always result in some pathology or at least turn out to be a sub-optimal choice in a context of a project. Remember that different Development Teams work out usually different set of rules based on specific project needs and needs of individuals.

It is a PM role to encourage such self-organization processes and not to sacrifice them by any means for a set of rules applied dumbly from managerial layers. (The technics for supporting self-organization are described very interestingly in Mike Cohn’s Succeeding with Agile.) One can be truly surprised with an amount of ways a Team can self-organize. I have worked with many Teams and to be honest the way of self-organization is almost always different.

Since all value emerges from the level on which a piece of work gets done, it is a mature’s PM and Organization role to be responsible to spot the most valuable set ups, or Best Practices if you like, and propagate the value to higher levels – a Programme level, Account level, Department level, and so on, up to an Organization level. A challenging intellectual effort here for management is a creation of a work environment in which such propagation is not only possible but happens by default in a natural way, or I would say unconsciously, without any case-based encouragement.

Still it is very common in ego-based, or pecking-order-based Organizations to go in the opposite direction. Producing too rigid suite of formalized processes, sticking to these in an inflexible manner, managing based on a position in a hierarchy rather than creativeness, neglecting a need for a continuous improvement, etc. is seen too often. This is one of the key managerial anti-patterns and the shortest way to a disaster.

Maximizing Agile Value Flow - Achieving Ideal Agility

2011-07-18T17:49:00.001+02:00

One can think of a transformation to agility as of a challenge of maximizing the throughput of Agile Values across organization structure. The goal of striving to maximize the Agile Value throughput is to ensure that every staff member is fully productive and produces as much business value as possible. In a long term, a maximized Agile Value throughput should result in an organization being capable of producing better and cheaper software than others.

To maximize to Agile Value throughput, the whole suite of Agile Values must travel smoothly in both directions: up and down the organization layers. Empowerment, Freedom and Responsibility travel down in the direction of level of Individuals. Visibility, Products, Solutions, Know-How and Best Practices travel up in the direction of an Organization level.

In a truly agile organization both arrows extend across all the levels in the organization structure. This ideal case maximizes throughput of Agile Values across the Organization and leads to ideal implementation of agility. Any limitations of the Agile Values throughput through the organization structure, either in terms of limiting some layers from participating in the Value flow or in terms of limiting suite of agile values travelling through the organization constitutes a limiting factor for a transition to agility.

Without a proper Agile Value Flow down the structure organizations suffer from low morale and frustrated staff. On the other hand without a proper emergence of value produced by Teams onto Organization level, organizations suffer from a product stream being of comparatively low value. For example, not emerging value properly means that an organization approaches a new project like they never did a project before and as a result software production is too slow and turns out to be too expensive.

Staff on all the layers is ultimately responsible for both participating in the flow and facilitating the flow in both directions in order to maximize the throughput of the flow. If on any level of organization structure a bottleneck arises, the organization’s implementation of agility may be suboptimal.

An organization is ultimately responsible for supporting staff by clearly communicating its strategy and promoted values, removing limitations and pumping energy to encourage valued behaviors.

By the way, if you think your boss is reluctant to give you more responsibility and support your empowerment, you are most probably right. As Tim Creasey and Jeff Hiatt describe in their Best practices in change management, 2007, Prosci, the managers’ biggest resistance to change comes from the fact that they fear to lose control and authority. It is understandable that after long years of building their position managers are reluctant to simply give up the insignia of their position without understanding the post-abdication reality.

On the other hand bosses may encounter resistance of individuals. For instance some individuals are reluctant to accepting any more responsibility than just doing what they are told. Again, it is understandable that some people prefer not to come out of their comfort zone.

How comfortable do you feel about the Agile Value throughput being maximized in your organization? Do you participate in pumping vital assets through the organization layers? Do you feel responsible for the Agile Value Flow being in your position? Do you know who you pump the substrates down to and who you pump the products up to? Is the suite of Agile Values complete? Is there a space for improvement?

PM Rules vs Organization Rules

2011-07-07T11:23:00.001+02:00

In the same way each Project Manager has his own definition of done, I described in my previous post, each PM also has his own set of PM Rules that he wants Project Teams to follow during project delivery. In a wider perspective PM Rules constitute a third level of law following the Country Law and the Organization Rules. The set of PM Rules serves as closure of general Organization Rules that defines specific rules in a context a given project. Such rules should be communicated clearly to a Development Team at the project inception phase, referenced and applied coherently throughout the project delivery to guarantee smooth collaboration and common understanding of project and work environment.

Depending on the level of formalization of processes within the Organization, PM Rules need to cover variable set of areas. The more mature the Organization is, or for some – the more corpo-like the Organization is, the smaller set of areas is left to cover for PM. In other words the PM’s freedom is a derivative of the level of maturity of the Organization. Thus in general Organizations should be very careful about the level of formalization of internal processes and make decisions being aware of their consequences.

Finding balance between Organization Rules and PM Rules is the key factor for creating flexible and productivity-oriented work environments. On one hand having a fully-blown set of rules or processes allows easy transfers of resources among various projects, because work environment in all of them is pretty much the same. On the other hand too much of formalization may be perceived as a factor limiting flexibility and/or even limiting creativity in individual projects. Limited flexibility makes adaptation to specific project needs very difficult for a PM as some Development Team members may prefer to follow the well-known tracks they learnt and got used to in former projects. Similarly, limited creativity causes less value added coming from individuals. All in all, too tight suite of formal processes is potentially a root cause of evil of disempowerment of individuals – both Team members and PMs.

My personal preference is for Organizations to leave as much freedom for PMs as possible. And not only that - it is just a pre-requisite for the truly valuable deliverables. Organizations are ultimately responsible for identifying values emerging from PM level and incorporating the most valuable practices on the Organization level. IMHO, only Organizations capable of conducting the above process gain a right to call themselves mature Organizations.

The meaning of Done - my definition

2011-07-01T16:18:00.001+02:00

The classical question What does it mean done? is one of the most known questions in software delivery. It is very common for conference speakers and trainers to spend some time on this during presentations as this subject is very fertile and audience reactions are vivid.

Many books define the meaning of done in various contexts, for instance in a context of internal processes, software delivery model, business domain, etc. Each developer has its own definition of done. And finally each Project Manager has his particular view on this. Project Managers must take care to introduce uniform definition of done for development Teams so that the understanding among Team members is common. As a warming up excersice let's quote some well-known definitions of done:

Code checked-in into source code repository and / or builds successfully
Functionality works fine on Test environment
Functionality has been tested by internal QA
Functionality has been tested during UAT
Functionality has been presented on Sprint Demo

I am sure you have your own definition of done or at least discussed this subject in Teams you participate.

When defining my own definition of done I had two goals:

to create my personal definition of done and
to incorporate the requirements and consequences of the definition as deeply and smoothly as possible into software delivery processes I use. To my understanding the definition of done needs to be integrated deeply into delivery processes. Without creating strong anchor in the delivery processes having even the best definition of done will suffer from people not following it (either consciously or unconsciously).

So finally, here it is - my personal definition of done:

A task is done when all Clients of the task accept its conformance with their requirements.

You would say this is obvious. Well, it is at first, but believe me - as simple as it sounds it is a very powerful definition. Let me share with you all indirect implications / consequences of such definition.

First, notice that the definition leaves the field for defining arbitrary acceptance criteria by not hardcoding any single general rule in it. This means each task can potentially have different acceptance criteria. In other words, acceptance criteria are defined on per task level which is much more flexible and powerful than defining acceptance criteria on project level as in examples above. My experience is that there is no single general rule that can be defined on project level - sometimes a formal Proof of Concept is required and sometimes on the contrary - verbal assurance that a task is completed works fine for a Client. Hence the need is not to fix anything too eagerly.

Second, the way the definition is formulated forces a task executor / implementer to think in terms of task's Clients. This constitutes remarkable difference when compared to a standard way implementers think of their clients. What usually happens is implementers are assigned a task (or commit to a task themselves) and they consider either Scrum Master or Product Owner their client. No-one else is on the list. Nothing can be more wrong, but this is the most common setup I saw in multiple organizations. Very often it happens that Product Owner designated from Client side is not present and Scrum Master from vendor's side takes up a role of Product Owner Proxy. In a consequence, task implementers think of him as of their Client. Also, it still happens very often that development Team gets a spec and implements the spec requirements contacting a Product Owner designated by Client if need be. Usually in such cases the spec does not describe requirements of a single person, but contains inputs from various members of Client personnel accordingly to fields of specialization. So Product Owner is de facto a proxy of the real authors of requirements. Either of the above proxying models shows that Product Owner is not always the author of requirements and thus he should not be treated as a Client of task by definition.

What is even more powerful in my definition of done is that it enforces the moment when Clients need to be defined. An implementer needs to identify task's Clients as the first thing, even before he starts implementing the task. He cannot start the implementation before he knows the requirements and he cannot gather requirements before identifying Clients. In a natural way Identification of Clients becomes the first step in Task Delivery Process.

So who might be a Client of a task? There are plenty of options. Task Clients may be external - on client-side, may be internal - a team-mate (or in general a set of team-mates) whose tasks are dependent on the task, a QA, a document-writer, etc. Interestingly I saw examples of developers adding themselves on the task's client list. It sounds extreme, but is perfectly legal approach - people wear multiple hats and play multiple roles so being Myself-Blue-Hat it is valid to ask questions to Myself-Red-Hat for requirements. In general, my experience shows that there are often multiple clients for a task.

After a task implementer identifies all of the task's Clients, he verifies the list of Clients with Scrum Master or Product Owner. Once this is done the task implementer follows the standard way – gathers requirements from the Clients, implements the task and gets acceptance from all the task's Clients.

Pigs & Chickens - Responsibilities & Commitments

2011-04-20T23:44:00.000+02:00

One of the classical Scrum anecdotes is the one Ken Schwaber quotes in Agile Software Management with Scrum. In short in the story a pig refuses to open a restaurant serving ham and eggs with collaboration with a chicken. :) And the reason the pig gives is that chickens would be only involved once pigs would be truly committed to the business.

The power of the message is extraordinary. Never expect chickens to take on any responsibility nor commitments. Chickens will always be there to give you good advices, fertilize your brain with nice ideas for generalizing solutions and provide speculative answers. However at the end of the day you will find yourself alone with your responsibilities and commitments, especially if something went wrong.

It is each team member's responsibility to distinguish between pigs and chickens. If someone discovers chickens being responsible for something than it is a clear sign to reorganize. Fingers will always be pointing the pigs.

Why Fixed-price fixed-time model dominated the scene?

2011-04-18T00:28:00.000+02:00

Fixed-price fixed-time, time-material or managed time-material software delivery models - they are all ultimately primitive. They are full of co-operation anti-patterns, promote negative habits and may turn potentially destructive both for Clients and Software Vendors. As you might have experienced or as you can imagine exploiting vulnerabilities built-in the above models happens on regular basis. In a case of fixed-price model the Client is potentially benefiting from the weaknesses of the model. On the contrary, it is the Software Vendor who is a beneficiary of the time-material model’s constraints / assumptions. Tendencies for exploiting vulnerabilities origin from various reasons and exist on both sides. Well, this comes at no surprise as intelligent human beings tend to adapt to surrounding environment. Mary Poppendieck’s Lean Software Development gives an excellent insight into the subject.

I will not be surprised if fixed-price and time-material models are the only delivery models you have ever come across in your carrier. You must be extremely lucky if you actually had a chance to work in some other models. You might have come across a composition of a fixed-price from the client perspective mapped onto Agile model used internally by a Software Vendor. This is very popular approach, but it does not gain from the synergy between Client and Software Vendor offered by Agile.

Yet the fixed-price fixed-time model have dominated the market. Background of this phenomenon is composite, but in my opinion two reasons constitute the backbone of mental background for their domination.

First of all, at the inception of software management people applied production models existing in other branches of industry and transferred them directly into software development. This is described by Frederick Brooks Jr., in The Mythical Man-month. Such decision makes sense at first sight, however with time the understanding arose of its limitations. The cardinal flaw of such approach was that software development is a creation process rather than a production process. This has severe implications on applicability of production models to software development. In fact, as noticed by Ken Schwaber in the Agile Software Development with Scrum - the nature of software development is too complex and cannot be handled by production processes as they are suitable to control well-defined processes. On the contrary software creation is so complex and unpredictable that empirical process control should be chosen for dealing with it.

The second reason for domination of fixed-price fixed-time model is business model at client organizations. Typical Clients of a Software Vendor are usually very busy and hard-working people, experts in their domain of specialization. Clients have internal clients, usually their bosses who originate the project. To get an anual bonus a typical Client need to make a project happen within a given deadline and within a fixed budget. The budget is available during the current accounting year and no longer. A natural approach for a Client is to agree with a Software Vendor on a scope of what can be delivered for some fixed-price and in some fixed-time. This is exactly the background of the fixed-time fixed-price delivery model. Of course requirements are fluid and a lot of areas are not thought through at the moment of signing a contract thus opening the doors to all evil to come. A Client leaves the project to Software Vendor to deal with it, because (s)he has a lot of other duties and (s)he is pretty certain that (s)he transferred all risks onto the Vendor - after all the Vendor will not get paid if something goes wrong, right? When a Client comes back shortly before deadline, (s)he usually gets something different than what (s)he expected. We all know the story… What is more, in this very moment a Client realizes that the risk was never really transferred onto Vendor! Yes, there will be consequences to the Software Vendor, nonetheless and in spite of how high they are, they will not cover concequences of a Client side - consequences for each party are of different nature and are most commonly separate. So what the Client really did when signing a contract was to create new risks on the Vendor side rather than transfer any of the Client's risks onto the Vendor side.

Anyway, did you notice how natural fixed-time fixed-price approach appeared to a Client?! Thinking in categories of what can I get for my money and when it can be delivered is as natural as checking the price of a product in an internet shop!

And yes, another eye-opener - the goals of Software Vendors in a fixed-time fixed-price delivery model are to deliver working software in an agreed scope, according to the agreed schedule and within the agreed deadline. No less no more. Do not get me wrong - the respectful Vendors always tend to deliver the best product possible including also other aspects, but usually hardly have any chances to cover anything extra due to tight budgets and deadlines. Exactly these deliverables result from the nature of the model. I encourage you to think of all aspects of the delivered software not covered by these three constraints. Scary! But again, does it surprise you? Isn’t it a natural choice for Software Vendor? As said above - intelligent creatures adapt to surrounding environment and in this case an environment of choice is fixed-price fixed-time model.

It takes a highly aware client to choose other delivery models. Recognition of Agile models is still very limited although it is probably the most attracting marketing slogan used nowadays by Software Vendors. In spite of 10 years on the scenes and tremendous amount of Agile mentoring done by Agilists it is not widely used by Clients (except from usage as marketing tool). An advice of Ken Schwaber given in the above-mentioned book to persuade Client to use Agile is not that easily applicable.

Iterative vs Incremental Development? Is it 'vs' or 'and'?

2011-04-01T00:50:00.000+02:00

So do you do iterative or incremental software development?

Be careful - this is a tricky question. Agile Software Development is based on iterative AND incremental (notice AND here) development. The article on the Wikipedia on iterative and incremental development explains the idea behind it - deliverying a shippable software product increment in every iteration. This reflects a well-known traditional change management approach defining a change as a well-defined transition from one stable version of software to another stable version of software product.

As a beginner project manager I lived in a confidence that I actually needed to choose between iterative OR incremental approaches. This is because I used a misleading metaphor for software product development. Let me dig into my past for a second...

I used to keep in mind a metaphor of a painter's dilemma. The painter's dilemma is a choice between iterative OR incremental approaches (notice OR here). Imagine two painters creating portraits. First painter's approach is to start with a sketch of the whole person and iteratively fill-in individual details across the whole person, details evenly distributed across a person. The second's painter approach is to sequentially work on individual parts, like an arm or leg or head till they are fully completed and mastered together with deepest details. The former approach resembles the way browsers display a picture that they download - starting from rough, obscured approximation of a picture and progressing iteratively till n-th approximation becomes a complete picture. The latter approach is not based on approximations - a painter can switch to next part of the body only when he mastered the part of a body currently being painted.

Having the painter's dilemma metaphor in mind as a project manager I was often tempted to go for iterative approach. It gives an overview of the whole project starting from the first iteration - it reflects the Top-Down programming paradigm - start with a do-nothing stub implementation of a program / system and dig down gradually into implementing individual areas. Also the iterative approach lets to postpone irreversible decisions till later which follows the Lean software development ideas.

As you can see such approach puts me into an inconvenient position between Agile approach and my conclusions from the painter's dilemma. Or does it? I understood my mistake during one of the projects when it turned out we were not able to close testing of any of a few dozens of features until very late stage of the project.

I suddenly understood that iterative approach is a kind of re-incarnation of waterfall. In fact it is called Agile-fall as I found out where iterations are in place, but they do not produce any business value as Stories are not ready to be delivered till the last iteration. Agile-fall in spite of using iterations delivers all Stories at the end of a project thus inheriting all disadvantages of a waterfall model's Big Bang effect. This completely breaks the Agile approach - to deliver working increments of software product in every iteration.

Clearly with respect to delivering value the incremental approach really shines. It allows a Product Owner to start making money early and have satisfactory Return of Investment (ROI), to stop after k-th iteration, to change requirements for unimplemented features. It is all possible as successive iterations deliver the most valuable increments possible at given moment.

And what about 'iterative' part of Agile's iterative AND incremental foundations? How does it apply? Is it AND at the end? Well, iterations are a tool providing Inspection - the second leg of SCRUM as Ken Schwaber used to call it. Thanks to iterations a Product Owner can assess quality of an increment. And they have nothing to do with increments of functionality evenly distributed across product as in the case of a painter's iterative approximations of a portrait - the value does not necessarily distributes evenly across project's functionality. Thus the approximation-based approach lying at the heart of painter's iterative approach is not a good model for delivering maximal value in an iteration.

The Nokia Agility Test

2011-03-29T00:10:00.000+02:00

And here is a copy of the before mentioned Nokia Agility Test. I copied it here while it is still for free... Who knows how greedy the trainers of the new religion become? ;)

LEVEL 1 - tests whether you do Iterative Development (Agile-fall)

- Are your Iterations time-boxed to less than four weeks?

- Is the software completely tested and working at the end of an Iteration?

- Can the iteration start before specification is complete?

LEVEL 2 - tests whether you do SCRUM

- Does the team know who the product owner is?

- Is there a product backlog prioritized by business value?

- Does the product backlog have estimates created by the team?

- Does the team generate its burndown charts and knows its velocity?

- Does the team have outside people disrupting the work of the team during the sprint?

How Agile your organisation is?

2011-03-29T00:01:00.000+02:00

So how Agile do you think your organization is? Are you sure you are agile? Sure you are not waterfalling anymore? Or may be you Agile-fall torn somewhere in between waterfall and agility? How can you prove you are truly Agile? Have you ever used any Agility metrics? What factors were taken into account in such metrics?

Throughout my carrier I worked with quite a few software vendors playing a role of a Scrum Product Owner. Once asked to describe their model of software development they'd all say - But of course we are Agile! What do think, huh? We will show you how you should develop software the agile way! Well, I can assure you - I could recommend few of them as agile practitioners... Most of them had no clue what agility was all about... Most of them did not understand that fixed price contracts with end-customers had to undergo some sort of transformation to map into internal implementations SCRUM... And most of them never thought about measuring how agile they were. Being agile became so attractive on the market that literally every IT department claims to be agile experts. This is really a shame...

If you consider yourself a respectful agile enthusiast, please think about taking some measures of your agility. One can find ideas how to approach such measurements even on wikipedia article on Agile Software Development. As a great example of Agility test I recommend the Nokia Agility Test.

To be honest with you I was never satisfied with the results of the Nokia Test - usually and for various reasons varying from company to company it used to ruin my hugely-blown ego of Agile practitioner. As Chineese say - the road to success is much more important than reaching it. Well, at least I take it as my excuse...

Criticism of Agile movement - misses the point

2011-03-27T21:16:00.000+02:00

Definitely Agility deserves to be called a revolution itself. It drastically changes approach to software development management. Fascinating is the fact that Agility is not inventing anything new - all the ideas were well-known before term Agility arose. Hence there is a plenty of criticism for Agile Creators as for selling well-known ideas after repackaging them into new smart-looking boxes.

IMHO this kind of criticism misses the point...

The major value of Agile Revolution is not selling well known ideas in new boxes. The Agilists go further than just pointing out weaknesses on the traditional project management. The value of the Agile Revolution lies in replacing the mental framework used in traditional software development management for years. The new mental framework is based on completely new hierarchy of values. Agile Manifesto describes the new mental framework in detail.

Notice that it took 30+ years for the revolution to happen. As with all ingenious ideas one cannot understand that it was so difficult to "invent". Once in place, Agile takes over with its natural grace.

Agile and Web 2.0 - do they have anything in common?

2011-03-27T15:49:00.000+02:00

When my wife noticed me creating this blog she couldn't be more surprised. She shares my concerns about usefulness of this way of knowledge sharing. Yes, I have to admit we live the life as the Web 2.0 revolution did not take place. We don't twit, don't facebook, haven't blogged so far. It takes time to understand values of a revolution and start utilizing the values to support personal aims.

IMHO the Agile revolution have roots in the same observations as the Web 2.0 revolution - human beings live in societies and human beings are individuals. Thus both the revolutions are based on idea to build support for human specific behaviours rather than create unnatural ideological frameworks and force people follow them. Making use of mechanisms built-in to humans by nature is incomparably wiser than having geeks experiment on us with their conceptual frameworks.

So no-one tells you how to use the Internet and no-one tells you how you have to create software anymore. Feel empowered. Ain't it great?

Why this blog?

2011-03-27T15:01:00.000+02:00

This blog aims to collect my personal thoughts and reflections on Agile Software Development Management - the most vital and influencing movement in the Information Technology (IT) management of the latest decade.

My story with Agility began on 2006 when I worked for Secerno Ltd, Oxford, UK and rapidly became my passion.

I made the blog public, but honestly - read it only after you made sure you don't have anything better to do. And once you do - please share your thoughts with me.