Wednesday, August 22, 2012

Lean & Agile Value Suite

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:
  1. Identify the set of Lean and Agile values
  2. Discover relations among them
  3. 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!





Wednesday, March 21, 2012

Re: Velocity - The Agile vanity metrics

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.

Wednesday, November 23, 2011

Development Team management


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: 
  1. recognition of the transformation process as a long-term investment on the organizational level
  2. conscious execution of the transformation as a part of a particular carefully selected project
  3. project sponsors fully aware of the attempt of the transformation
  4. well defined sponsors of the transformation
  5. 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.

Saturday, October 8, 2011

PM encouraged self-organization

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.

Monday, July 18, 2011

Maximizing Agile Value Flow - Achieving Ideal Agility

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?

Thursday, July 7, 2011

PM Rules vs Organization Rules

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. 

Friday, July 1, 2011

The meaning of Done - my definition

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: 
  1. to create my personal definition of done and 
  2. 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.

Wednesday, April 20, 2011

Pigs & Chickens - Responsibilities & Commitments

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.