Building a self organizing team of engineers!

 At its peak, a self organizing team is equivalent to a high performance team; A team of engineers that can deliver a quality product with maximum efficiency (minimum timespan!).

 You cannot put together a group of high performance individuals and expect the outcomes of a high performance team. The group of individuals will take their time to get to adapt to each other as well as the product and business domain. This can typically take one or two product release cycles.

 Lets start at the beginning. You are adopting agile product delivery and you want to setup a self organizing engineering team. Historically, engineers are used to management bringing in new processes or project tracking tools, and requesting the team for adoption, and the usual reaction at the beginning is passive resistance and minimal compliance to management requests for adopting the new process or tools. Your team is bound to look at your desire and goal to adopt agile in a similar manner.

 How about letting the engineering team decide for itself on how it will transition to agile product delivery? To make this possible you need one or more of your senior most technical leaders on the team to champion agile with the technical team. Your senior most technical leaders and you, thus have to go through rigorous agile trainings and have your own internal discussions and debates to arrive at how agile product delivery can benefit everyone in the context of your organization and what path and plan of adoption to get the team to transition to agile execution and product delivery.

 If you are setting up a project team of 7-9 engineers to deliver your first project release using agile, its critical that you choose a technical leader on the team who can champion self organization and steer and coach the team throughout the release. If you have multiple technical leaders who can play this role, that you can choose to round robin leaders into this role across releases. If you have no such technical leaders available, you are in trouble :). You may either hire such a leader, or temporarily ask someone from the management team or yourself play the role of the technical leader for the current project and use it as an opportunity to train one or two senior engineers on the team to take up the role in upcoming releases. This implies that you do not yet have a team that can self organize on its own, and you are using a temporary tactic of having a management person orchestrate the organization of work and decisions in the team.

 Having the right technical leader to champion the release is critical. As a next step the technical leader and you need to be clear about creating an empowering work culture and team. You are likely to have engineers with varying levels of experience and seniority on the team. Each such individual should be empowered to be able to own his work at this level, influence technical decision making in his areas of work as well across the team over time, and step up and take on more complex work.

 Initially the technical leader for the release will have to handle much of the self organization required within the team. Over time, he should be able to coach the team and decentralize the process of self organization and avoid being the bottleneck for decision making or self organization.

 What do we mean by a self organizing team? What should the team be able to do independently on its own? What do we mean by the team the team being able to own & deliver a product release from start to finish?

 A product or a product release solves a new customer problem.

 The team should be able to work closely with product owner on following aspects.

• Having a strong understanding of the customer problem in close interactions with product owner and customers.

• Propose solution alternatives and/or technology alternatives.

• Create early solution prototypes in working with product owner.

• Determine the functional release scope (product backlog) as well as non functional (system performance & scale & user responsiveness...) goals for release.

Once the general direction of the product solution is well established, the team should next be able to independently drive product release execution and solution validation engagements with customers.

Here are some critical situations where in the self organizing qualities of a team get really tested.

Situation 1: Coming up with overall sprint plan for release for complex features.

The team should be first able to come up with excellent incremental delivery plans for such complex features, (in terms of what should be accomplished first vs later), and then introduce the time and planning angle in terms of number of sprints and team members required to finish off such a feature. This is a situation where in the technical leader(s) of the team play a crucial part. If the team understood agile principles correctly, then this is the first part it should be able to get right; laying out the plan of attack for the product release. What does the team take up first? Technology evaluation or prototype of a functional solution of customer or both in parallel? If technology choices are well known or straight forward, which is the core functionality to be delivered and tested and validated with customers within the first sprint? And next...This is a situation, phase or part of the release where in the technical leader and the team build the mental map and vision for the rest of the release cycle.

Situation 2: Identifying work to be done in a sprint to meet committed product backlog items.

Does the team show rigour in quickly and comprehensively identifying the work involved in the product stack to be able to implement a set of product backlog items, during the sprint planning session? This becomes a very tricky situation while working on legacy products or components. Work can expand or contract significantly from what might have been originally anticipated, or if the team is new to the legacy components. The balance to be drawn here is over investigating or analysing the legacy code base or component vs jumping straight to execution. Senior technical members of the team again have to show their judgement at sensing when it is best to dig in a little deeper to understand the true nature and amount of work involved vs when to just get going and unearth the work along with the execution of the sprint.

Situation 3: Communicating effectively on sprint commitments being or not being met.

The team has committed to 10 user features in the current sprint; When the current sprint completed, 7 out of the 10 features were completed.

Did the team announce that 3 of the 10 features would not be completed early enough? Or did it catch stakeholders by surprise on the last day in sprint review meeting?

i.e. Is the team able to keep an eye on the entire set of sprint goals, and is the team able to sense that it might have overcommitted, or understand that the work involved was more than anticipated, and communicate promptly and re-organize to complete maximum user features instead of 10? or is the team merely motoring along doing whatever they can, with no real commitment to the end outcome for the sprint?

An immature team can be two dimensional. Merely point to new work identified, call it a part and parcel of software development, speak of how this is acceptable in agile and pass on everything to the next sprint. A strong team of winners, will naturally think of a successful sprint, and think about what's possible, and what it can demonstrate as a sprint outcome which in turn acts as a sprint WIN for the team. This mental make up of the team is crucial. A team looking to win in every sprint vs a team mechanically going about identifying the work and laying it from sprint to sprint. Again the attitude and approach of the technical leader in team, majorly influences how the team conducts itself in this situation.

Situation 4: Setting the right standard on product quality.

The product build quality is not up to expectations; The team is generally on track to deliver on all sprint commitments, but there is a risk to quality of output.

Does the team set the right standard in such situations, and drive quality early and upfront? Even if it means implementing one less feature than what was committed in the sprint? In this case, is the team able to effectively work with the product owner and trade off on the sub feature in the interest of quality? Again, who keeps the pulse on the quality from the development team? An immature coding team might keep on coding, and generally, be aware of what functionality has been coded so far, and speak of progress, success and completion in terms of what's code complete. An experienced coding team looks for test results, drives and influences what is tested upfront, and looks for the most critical test results upfront, and then declares success on the basis of positive tests results and data points.

Situation 5: Overcoming technical impediments.

Developer X is struggling with a implementation of feature A, due to certain technology challenges. Feature A is core to the success of the sprint.

Does the team rally around this developer, and pull in skills and knowledge or take external help to get past this technical impediment, and in the worst case, even eliminate, reduce a non critical feature from sprint commitment in the interest of successfully implementing feature A? Understanding the critical themes and success factors for a release as well as a sprint, is a very crucial, and a mature team keeps this aspect in mind at all times, in its day to day organization and execution.

Situation 6: Handling product defects throughout the release cycle

It takes an experienced technical leader or team to determine defects that should be fixed immediately vs a little later, vs defects that are as per designed behaviour (and thus not defects!), vs defects that are outside of solution scope and hence would require change management to kick in to extend solution scope or the defects will move to next release. Defects can result in silent creep of project scope. An immature team will fix what it is told to, or what ever is open as a defect in the defect management system. An experienced team with a seasoned leader, is very effective at staying focused on the core, as well as the committed, and steer clear of busy work on defect management system, or clearly call out, what is out of solution scope, vs what is net new and unanticipated and has to be planned for, vs what can be deferred.

Situation 7: Handling non functional requirements.

The team has to work closely with product owner to ensure adequate attention to non functional requirements. Be it system performance or scale or user experience or user responsiveness or product security or legacy technical dept..

Can the team define the right goals and measures? In what sprint are these goals to be met? Work involving performance tuning and scale can take an unpredictable amount of time. How does the team proactively design for building the right system to meet required goals? If new architecture is being put in place or performance or responsiveness is a significant theme for the release, then such items, due to their complexity as well as relevance to the release have to be taken upfront in the release, as it constitutes a significant success factor or risk. Does the team adequately keep the non functional success factors in mind throughout the release?

Situation 8: Engaging cross functional stakeholders

The engineering team constitutes the majority of the overall team strength executing on the release, and need to have a sense of ownership, responsibility and drive on product release execution.

Does the team sit back and complain about the smallest of impediments across functions, or does the team demonstrate a winning attitude at driving the release forward, engage, collaborate and move thing forward, or effectively leverage the scrum master, product manager or even the leadership in doing so. An effective team and the right technical leaders, understands the significance of the product release to the business, and the part, relevant stakeholders are expected play in the release, and can hold stakeholders accountable to that expectation.

Situation 9: Engaging customers, executing customer validation & feedback

A good team expects the product owner to be the leader in such phases. A great team expects no one else to lead any aspect of the success of the release, that it is truly in the act of owning and delivering.

Again, a great team can easily define such customer engagements, and define the exact feedback it needs to gather to confirm success. And not merely execute a customer engagement event as a ceremonial phase of the product release cycle, to be completed as per process!

Your teams ability to self organized can be well understood from how well it can handle such situations. And in a positive environment, the team will learn and get better and better. The product owner, scrum master and the technical leader should form a critical leadership triad to work with the rest of the team during sprint retrospective meetings, to ensure that the team learns from its first mistakes, and continually gets better.

As a coder, I never wait on a tester to tell me what the quality of my code is, as per his own sequence of testing. That's putting my fate in his hands. I would always test what I should and can on my own, and then convince the tester about the right order in which critical tests results are to be measured, and the order in which I'm completing my code to make that critical sequence of test results possible. This sequence and the anticipated data points act as the mind map as well as the success criteria for a product or feature release. Well organized teams are simply good at working extremely cohesively in their coding and testing to hit the success parameters in testing in the shortest possible timespans!