The Software Organization under EDT

The software organization under EDT (Enterprise Digital Transformation) In this (coming) world, the way software will be written, delivered and deployed, will be radically different. Naturally, it will have consequences for organization structure, HR policies, and work processes. Software will be developed, tested and deployed by small teams of 6-10 people, which may include members of the customer organization and, in some special cases, even end users. The same team will be responsible for design, development, testing, deployment maintenance and the continuous changes they will need to keep making to the software deployed. The teams will operate entirely in agile scrum mode. They will, by definition, be self-governing teams, with little direction from higher levels. The contribution of each member will be crucial but impossible to measure, since it is the team who takes ownership. They will be coordinated by a scrum master, who is a member of the team. Reviews will consist of daily stand-ups of 10 minutes. Because the teams will be working closely with customers and users, and may in fact include members of these outside organizations, security and privacy issues, i.p. protection etc. will take on a different hue. People working on the teams will have to understand key aspects of the customer’s business, technology, and how the user actually uses the software – today, teams are required to understand only technology. Testing as an independent activity will simply disappear…it will become an integral part of the design/dev/deploy process. Consequences for organization structure: The company will be just a collection of self-organizing teams. It is not clear what layers of management above this will actually do – SBU heads, delivery heads etc. will never know enough about the progress of the project to be able to guide and control it. If they insist on reviews, they will only slow it down, and speed will be at a premium in the new world. How will we manage a portfolio of such projects? Who will assign people to them? Who will decide what the team does next, after the project is done? Does the project ever get done? Certainly, account managers will be needed, to nurture the relationship with the customer. Product managers will also be needed, since the software deployments will increasingly look like products – with training, documentation, road maps and so on. But above this, it is not clear what value management can add. These are troubling questions to which we do not have answers today. Consequences for HR policies: The only measurable performance will be of the scrum team, not of individuals. Ownership and accountability is with the team as a whole, not even with the scrum master. How will we reward and promote people? Promote them to what? To a largely meaningless managerial role? Not everyone will be fit for, or interested in, the roles of account manager and product manager. What will be career paths for people? Do they spend their entire lives in one scrum team after another? Do they grow as experts in a certain domain or customer type? Should we consider rewarding and promoting, not individuals, but the team, all together? How do we train and develop people to play multiple, overlapping roles – in multiple technologies, for instance – and in domain, business and user experience? The team will have to include designers, developers, testers, and deployment specialists – and their roles will naturally overlap and even switch as people learn and grown within the team. How do we encourage this to happen faster? Companies who answer these questions first, and best, will be leaders in EDT...