The squad (aka Development team in Agile) – nine folks. The number of guys that could fit in a tent,” It has been identified that the way to build a scalable organization is to focus on the basic building blocks – small, stable, multidisciplinary teams that are expected to independently tackle problems, make decisions, and get things done.
“When it comes to building a deeply efficient engineering organization, there are several things you can do to move the needle:
• Build strong teams first. Assign them problems later.
• Keep teams together.
• Go modular. Remove dependencies.
• Establish a short, regular ship cycle.”
Concept is to have a decent team size that is the two-pizza team – a team small enough to be fed with two pizzas. A team includes everyone needed to design, deliver, and support the service – from specifications to operations. If a service is too large for a two-pizza team, Organization should split the service into smaller pieces rather than to combine teams to deal with the larger service, because this preserves the dynamic interactions of small teams.
WHAT COULD GO WRONG?
If it works for larger organizations like Salesforce, Amazon and Twitter, surely it will work for you… So you form a lot of small, independent, multidisciplinary teams and you are careful to give them all clear goals. What could go wrong with that?
THE DILEMMA
It is a beautiful thing when the building block squads of an organization gel into high performance teams and can be counted on to meet challenging goals. But tricky part is, once you create these strong independent teams, how do you get them to work together? How do teams maintain their autonomous character while working in concert with an increasingly large network of other teams? How do you make sure that each team has a clear goal, but none of the goals are in conflict?
In an agile environment, the Scrum Master’s role is to set up strong teams, to be sure, but it is also to devise a system – let’s call it a goal system –which assigns goals to teams. This is no easy task. Teams need clear, meaningful goals; they have to be the right goals; teams must have the capacity, capability and autonomy to achieve their goals; and most important, the goals cannot conflict with each other.
One of the things Scrum has contributed to the practice of software development is the idea that small autonomous teams perform much better than large project teams or single-discipline teams that work in sequence. So Scrum provides the building blocks of scale, but unfortunately, it does not contain a scalable system for choosing team goals, making sure they contribute to organizational goals and are in sync with the goals of other teams. So we need to look elsewhere for ways to set up a goal system.
THE THEORY OF CONSTRAINTS
When the Constraint is Technical
The first step – after clarifying the overall system purpose and goal – is to find the biggest constraint to achieving that goal. For purpose of discussion, let’s choose one of the most typical technical constraints encountered in delivering a software system: the integration of various components of the system without the introduction of defects or unintended consequences. In fact, project organizations typically allocate a third or more of the project time to release overhead – including integration, testing, fixing defects, and deployment – with the largest portion going to finding and fixing problems discovered during integration. When integration is the system constraint, TOC tells us that the most important focus for development teams should be removing this constraint.
Agile approaches to software development recommend the frequent delivery of working software to customers. When this recommendation is followed literally (software is released to end customers frequently), the integration constraint is regularly exposed and has to be confronted. One of the earliest agile approaches, Extreme Programming (XP), includes technical practices such as Test Driven Development and Continuous Integration that help make frequent releases practical. Continuous Delivery, which expands on these practices, has gained widespread favour as the agile approach which explicitly focuses on the integration constraint. In Continuous Delivery we find actionable advice on how to tackle the integration problem with techniques that scale across large networks of teams.
If everyone working on a system is trying to stabilize and improve the rate at which tested, integrated software is successfully released to end customers, then teams across the system will naturally have to work together and will find that their goals are compatible.
When the Constraint is Knowledge
More often than not, however, technical issues are not the biggest constraint in system development and the fundamental problem is not an integration problem, it is a design problem or a fitness-for-use problem. Far too often we end up with a system that doesn’t work well or is difficult to use. In this case, the biggest constraint in developing software systems is the way in which we decide what to build and parse that decision amongst the teams doing the work.
Organizations with an agile / lean mind-set would frame the problem differently. They are likely to identify the biggest barrier to making good decisions as incomplete knowledge, and thus the biggest constraint of the system would be the rate at which knowledge is generated. So a lean organization would focus on the feedback loop between customers and development teams. They would decrease the length of the feedback loop, increase the speed of the feedback loop, and remove barriers to the free flow of information inside the feedback loop. These organizations would say: If we can test our assumptions and designs more quickly we will learn faster and make better decisions.
Good Leaders set examples
Good and great leaders set examples on the following parameters: Help your team practice these elements to be able to scale and add value to themselves, product, organization and the customers:
Clarity – Eighty percent of success comes from being clear on who you are, what you believe in and what you want.
Competence – You can’t climb to the next rung on the ladder until you are excellent at what you do now.
Constraints – Eighty percent of all obstacles to success come from within. Find out what is constraining in you or your company and deal with it
Concentration – The ability to focus on one thing single-mindedly and see it through until it’s done takes more character than anything else.
Creativity – Flood your life with ideas from many sources. Creativity needs to be exercised like a muscle, if you don’t use it you’ll lose it.
Courage – Most in demand and least in supply, courage is the willingness to do the things you know are right
Continuous learning – Read, at the very least, one book a week on industry / sector / domain / business to keep you miles ahead of the competition. And just as you eat and bathe, organize your time so you spend 30 minutes a day exploring e-mail, sending messages, going through web sites, because like exercise, it’s the only way you can keep on top of technology. If you get away from it, you’ll lose your edge.
agilescrumworld 