The new Team Structure

Once upon a time, programming, like painting, was fun. I remembered how I wrote my first program using my 128 steps programmable calculator and how I went into a flow state quickly.

I am quite sure that many artists are having similar experiences - when painting pictures, writing articles, composing songs & etc. We fully engaged for a few hours to at most a few days, creating something we are proud of. When it comes to artistic creation, one thing is obviously in common – the required knowledge during the work-in-progress is mostly tacit in nature. Put it simply, you cannot speed up the job by arranging people working in shifts, asking them to pass on the tacit knowledge between shifts. Indeed, there is no such need because the work-in-progress is usually too short to warrant any sensible “project management”, which might jeopardize the fully engaged flow state and hampered the otherwise high creativity.

Scaling out a little bit, small group painting can still be fun. They first agree upon a common goal and then self-organize and paint together, sharing common tacit knowledge. There are many studies about human aspects of building an engaged and empowered team. Three keys from the book “The 3 keys to empowerment” (Ken et al).

²  Share information with everyone (whole team listen to user requirements, not just Architect, BA or SA)

²  Create autonomy through boundaries (e.g. Governance, tools, architecture and time-boxing development)

²  Replace the old hierarchy with self-managed teams (team members take up jobs themselves. Tasks are not assigned)

Moreover, employees’ biggest motivator is making consistent & meaningful progress (producing demonstrable small pieces), as concluded in the book “The Progress Principle” (Teresa et al).

But what happens if we scale further, from a picture to a mural that involve a hundred artists? What if the surface is unknown and need some research to decide on the priming? Behind arts and creations, we do have Engineering - tools, technologies and architectures. For writing, we need to learnt Grammar and for composing songs, we need to understand music theory. If we want to complete the mural as planned, we have no choice but to manage the Engineering portion of it.

Given the advancement in computing, computer applications nowadays are usually in the scale of huge murals. With more and more mega-projects around the corner, the way we used to program was never be the same again. To manage the sciences behind the scene, the arts & creation portion is partitioned in such a way that it is difficult for us to engage fully, enter the flow state and be highly creative.

Can arts be arts and science be science? That depends on how we “divide and conquer”. I observed that once there are risks arising from the sciences portion, we tend to divide in the same time slice across the board, including arts. We should be dividing the loaf of bread but we divided the chair altogether! In this awkward way of dividing, the artists must stop in the middle of his creation and pass his tacit knowledge between stages.

The very first divide and conquer method I have learnt is SSADM. Using tools like DFD and ERD, we analyze the current physical model to produce the current logical model. We then design the new logical model and produce the new physical model. We then build and deploy the new physical design. The next one I have learnt is RUP which provides us a whole wealth of object-oriented tools and document types. We transit from Business Modeling, Requirements, Analysis and Design, Implementation, Test and finally to Deployment. The major difficulty with these two most popular methodologies is that very often, we rely on the tacit knowledge in our mind to travel back and forth between analysis, design and construction in order to build the “right” product. These methodologies don’t allow us to work on an element from end-to-end but force us to deliver explicit knowledge out of tacit knowledge between stages. These are examples of dividing science and arts together with the same handsaw.

Back to the hypothetical mural painting problem, what we should be managing is the priming and scaling. The most common divide and conquer technique is to scale a small outline sketch into a large wall using grids (picture on the left). Stage I is a engineering stage in which we manage the R&D, priming, gridding and sketching. The skeleton contains the initial agreed contents of the mural and more importantly, the interfaces between adjacent grids. Stage 2 is an arts and creative stage in which all 24 painters paint, in their normal style, simultaneously, from end-to-end (analysis, design & code) on their assigned grid within a time-box of say, one day. When the painters start to add details, the owner may change mind. But everybody has to observe the one day time-box rule. For example, the mural owner has exchanged the table on the beach with a boat. Time’s up; pens down and we enter the engineering stage 3 where we have to manage the drying up of paint and application of protective coatings. If, in stage I, we also do all the design up front in transparencies, project them onto the wall and just apply paints, we will end up with a mural good to look at from a distance but without details when close up.

I have learnt a great deal from “The Frog and the Octopus” model (Philippe 2011). The frog may say that painting should be the same everywhere while the octopus may say that mural painting is different. My impression is that it is a single tracked project. The octopus may determine which track is the most appropriate and the whole project will change to that track. No matter which track to change to, very often, the frog is to be sacrificed. Ironically, the frog is the primary author of the codebase, on which the successfulness of the product depends!

My question is that why a project can’t have multiple tracks? If we divide and conquer properly, the frog can stay on its own track while each arm of the octopus can has its own track. In software projects, it is the team structure.

Below is the new team structure for the new V-model in my last post. The unusual part is the breaking up of the traditional development team into a Business Process team, build team & PMO team. The build team is artistic in nature especially for the frog. So, it is not hybrid-agile or Water-SCRUM-fall. Some teams are waterfall all the way through while the build team is purely agile. I believe that both extending agile by adding waterfall elements and forcing waterfall to adopt some agile practices are unnatural and unnecessarily confusing (sort of neither fish nor fowl).

Besides PMO, all teams are following the same pattern, Specification with measurements (just the measurements, focus in exploration with users), development work (focus in getting user feedback) and finally checking the measurements (either manual or automated).

(Refer to the new V-model)

Business Goal Team:

1.          Envisioning and determine measurable business goals, including the detail measuring methods.

2.          Ensure that “measuring points” are implemented (goal testable).

3.          Drill and accept the measuring process.

4.          Assign measuring resources and define the reporting process.

5.          Final review to determine success

Business Process Team:

1.          Define Business Processes using UML process activity diagrams and Identify Scenario Steps and decompose into user stories. Prioritize user stories and agree upon the initial iteration plan. This is the sketch outline in grids to kick start the Build team.

2.          With the feedbacks from the build team, manage the change to the Business Processes diagrams and Scenario steps. Perform “test detailing” to transform it to a detail UAT step-by-step plan with User Guide.

3.          Plan and conduct SIT, UAT and final acceptance.

Build Team:

1.          Paint on its own user story grid with relationships between user stories defined in Scenario Steps. Frog: all development works are the same.

2.          Explore with users and confirm user story specification as measurements.

3.          SCRUM iteration with immediate user feedback on UI mockup and working software.

4.          Make the measurements executable (automation) with green lights. Demonstrate to users and energize the team.

5.          Feedback to Business Process team changes to Business Processes, Scenario Steps and user stories (add / delete / changed / merged / split).

Technology Team:

1.          Define non-functional requirements (measurements) and testing steps.

2.          Define architecture, tooling, build prototypes and perform proof-of-concepts.

3.          Produce reference implementations, design patterns and developer training kits for the Build team.

4.          Specify, build and test common / critical / scientific parts, such as workflows, cross-cutting security API, those that require regulatory compliance and those that may endanger human life. Provide API and documents for the build teams to use.

5.          Hardware procurement, installation, testing, hardening & performance tuning.

6.          Deployment drills and non-functional test acceptance.

PMO Team:

1.          Overall resources planning. They can be virtual teams and very flexible. In the extreme, all five teams may be sharing just a few members. For examples, the build team members can join business process team and technical team initially and join the PMO team after the last iteration.

2.          Data Conversion planning: data analysis, mapping, confirmation, mocks & verification.

3.          Cutover planning: existing interfacing analysis, special arrangements, confirmation, cutover steps & dress rehearsals.

4.          Source code baseline versioning, built and deployment management.

5.          Deliver the living documentations composing of Business Processes diagrams, Scenario steps with User Guide and Build Team’s user story measurements.

6.          Operation, Incident management & Support: Produce required operating manuals and deliver trainings.