Building that Agile Team

build-that-team1

An increasing number of offshore service organisations proffer startup incubation services. Every startup product (or project) owner wants to have the best team to deliver the outcome on time and within budget, irrespective of it availing the offshore service. Building teams is essentially a complex problem; identifying individuals that will cooperate and compete, and work to the same goal. It is therefore important to understand just what the various candidate evaluation methods attempt to achieve, and to what extent (if any) they are successful.

Every potential candidate presents four characteristics, viz.,

  1. tacit-knowledge
  2. explicit-knowledge
  3. experience
  4. mindset

Some of these characteristics are easy to validate through standard test techniques, while others are very difficult. The tests for candidate selection increase in cost as the characteristic itself becomes difficult to pin down. For example, tacit-knowledge, is very difficult to verify objectively, as it is non-transferable. Although, it can be observed in experts, such as, surgeons or highly skilled programmers.

Experience by itself is the easiest to validate and by itself the most redundant of all of them. It is difficult to ascertain if increased experience makes for increased tacit-knowledge. It is unlikely that experience by itself would be correlated to tacit-knowledge, one would also have to add ‘mindset’ to this mix.

Most organisations have a standard number of steps for candidate selection, usually increasing in technical difficulty. This is the most effective way for service companies to show speed while containing costs to build teams for new clients. But, the problem is that all these different layers give a false positive of the candidates suitability, as it only tests for explicit-knowledge. These types of question-answer sessions do not provide idea of the other three characteristics vis-a-vis the candidate. This technique may actually give a false negative, and the organisation looses a potentially good candidate.

Two of the characteristics, viz., tacit-knowledge and mindset cannot be measured through a question-answer sessions, no matter how many levels. It needs a more immersive situational techniques. It needs the creation of a environment that will mirror the actual. And, a situation that will provide an opportunity to observe the candidates responses.

  • Run a mini half-day to a full-day sprint (in the agile language).
  • Up to three potential candidates can be asked to take part at a go, these are selected from the final group selected after the preliminary selection process.
  • An existing employee must be added to the team.
  • The problem presented to them must be verified as executable within the timelines set for the sprint.
  • It must be obvious by now that this is not an easy exercise, and also explains why most offshore service organisations shy away. It is costly. It requires very high competency from the human resource department. It also requires a high degree of technical competency from the organisation.

Conclusion

Getting the composition of members for the team right is very important. If tacit-knowledge is difficult to quantify except through observation, it is equally true of mindset, which is a mix intuition, orientation, and improvisation. These characteristics do not have some mathematical or psychometric formulae that can be used to compare individuals capability to become successful members of an agile software team. They may be observed during execution or can be inferred (with difficulty) after the event.

If you have an unbalanced team (in respect to the characteristics mentioned above) then it is highly likely that something will give. It could delay the drive to market, particularly critical in the current cloud environment. It could delay the feature release, allowing a competitor to jump in first. In the worst possible scenario it could lumber the client with a dysfunctional team. Know your risks when you build a team only comprising of members validated for explicit-knowledge. It is not wrong, but there are consequences to the outcomes and your goal.

Posted in agile, management, team building | Leave a comment

Process Thinking with Promises

the-full-transaction-1

  More than a decade of talking about the need for non-technical business people to take on the task of mapping out the business processes, we are still in the wrong place. Business processes define how the business people do things, achieve their business goals. But, the business process design is done by members of the IT department.

  It is increasingly evident that a process designer is required to be an expert in the symbols of the process language, including those thrust by the design tools. It seems at times as though emphasis on the process design ignores the Organisation and its  structure.

osp-1

  Consider figure on the right, it is a recruitment business process of an offshore service provider. It is purely for illustrative purposes and is thus incomplete. The tool used in this case does not support partner organisations. It is not possible for a business person to understand this except as a superficial chain of activities. There are too many symbols with embedded meaning to fathom all the intricacies of the process. Each symbol in the diagram tells a story, and not knowing this means there is no proper critique of the process from the business person. It is only in its execution that a business person understand the consequences of the design. 

  How Organisations get things done is often found embedded in its business processes. One could even say that an Organisation is just the sum of its processes. Organisational structure plays a large part in influencing and is also influenced by its business processes. The Organisations structure acts as a constraint on its processes, and vice versa. Business process should be designed around the Organisations structure, and the structure should evolve in time as new business practices and external factors come into play.

request_promise_transaction

  How do we make the process designing conceptually more  non-technical business person friendly? We can start by simplifying the language used in process design. The DEMO ontology provides an enterprise wide notion of a transaction, figure on the right.

In this sense a business activity should be seen as a transaction (in the DEMO sense). An activity thus consists of the following, a triggering request, promise, execution, statement, and acceptance.

  • Actor (A1) in the figure is the request raiser; he may be external or internal to the organisation.
  • Actor (A2) is the promissory for the execution of the activity, and the promise is backed by the Organisation. The actor is the owner of the activity from the promise, to the execution, to the statement.
  • Actor (A1) at the end has the option to accept or decline the result, he will accept if it his desired result.

the-whole-request_promise_transaction

  These concepts can be used to redo the illustrative process, to transform the process as set of  linked transactions, see figure on the right. We have the exact same process, but with a lot more clarity for the business person. It is thus possible with a minimum number of language constructs to design all business process, by and for business persons. As a set of linked transactions it is easy to verify that the business goal is achieved, or should be achievable within the constraints of the Organisations structure. We are not aware of any formal verification process.

  Even when the process crosses boundaries into other Organisations, the language used to depict the activity is the same. Thus Partnership relations can be also clear in the diagram.

  A promise in the transaction is not a mere statement with some ethical connotations, but it is akin to contract backed by the organisation. It is also a precursor to trust between the parties in the promise. There are no restrictions that the actors in the transaction have to be human. It is possible (and true) for an actor to be a machine, rule engine, etc. Neither is there any restriction of atomicity on the execution part of the promise. It is indeed possible that the execution may consist of multiple actions by the actor offering the promise to the requestor.   

CONCLUSION

This little snippet of a writeup can not do justice to showing just what DEMO can contribute to business process design. Nor can it begin to stress the importance of DEMO to enterprise architecture. DEMO provides a much tighter and controlled feedback with the Organisations enterprise architecture, both from an informational and process perspective. Process design is for the business people to own, not some tool mastering technical IT person.

Posted in BPM, DEMO, process design | Leave a comment