Why not StratDev, BusOps, etc.?
The term “DevOps” refers to tight integration between the Software Development and Operations parts of an organization. As I mentioned in my article on Conway’s Law the reinforcement of there being two separate parts “Dev” and “Ops” causes a separation in the way we think about these problems and then how we interact within an organisation. If the industry truly believed in DevOps then “dev” and “ops” would no longer exist. I realise that some people intend “DevOps” to be a verb, but it sounds like a noun.
Of course the idea behind of DevOps, of bringing together stakeholders involved in creating, hosting, running and maintaining is a great idea – focussing on these things can make it easier to deploy products and get user feedback. However we might just end up building the wrong products quickly. We must make sure that the things we build are aligned to strategy and deliver business value. To do that we need a holistic approach, that involves all stakeholders (not just the dev and ops folks).
Operations stakeholders should be involved in the Portfolio Build/Selection practice to ensure that the impact of new product development or maintenance decisions on current Operational positions are understood. Significant changes to current Operational positions are raised as Portfolio Requests so they can be properly costed and scoped.
Work that is approached holistically must by definition include addressing the needs of all stakeholders from any part of the business. If a divide exists between parts of the business then the dysfunctional relationship needs addressing rather than process and tooling being introduced. Processes and Tools are helpful to gain agreement on a common approach and automate ways of working but not to solve dysfunctional relationships.
HSE promotes regular builds and releases in either iterative/agile or continuous flow models Operations stakeholders must be involved early and often in software development product delivery as a product is likely to be delivered frequently, or even continuously, and so will need transitioning activities performed repeatedly.
So, I like the idea of joining up dev and ops stakeholders and work. But I only like it in the context of also joining up business strategy, requirements, architecture and quality with dev and ops – all flowing business value to customers. On it’s own, DevOps isn’t enough and worse could just be a management fad.
When I started doing software I was a simple developer interested in elegant code and shiny things. I worked in a small software house that taught me many bad practices in terms of configuration management, change control, estimation, management etc. It was an incredibly valuable experience for me in learning how not to do things and led me to strive for something better even though at the time I didn’t really know what it might be.
That led me through a path of process definition and documentation (RUP) and a rather limited following of an iterative lifecycle. I remember a conversation I once had with one of my project managers (when I was an architect) asking if we were going to do “Use Case Analysis” on a particular project or just skip straight into “Use Case Design”. The question puzzled me then because it felt like a trap and I didn’t really understand what I was being asked.
It puzzles me even more now as I know understand “analysis” to be a stop-and-think-for-a-moment activity and I’d always do a bit of analysis of my requirements, however these days it’s extremely unlikely that it’d be an analysis UML model, instead it might be a sketch, a conversation and a bit of thinking before another conversation.
So I moved from process prescription to process understanding, applying the spirit of doing things well rather than the letter of whatever current process law was in fashion. Following on from that I’m not really interested now in the details of what a book says someone’s role should be or how people should interact instead I think the real challenges in software development are social, not collections of technical practices (although there is value in evolving better practices and tooling).
A colleague of mine commented recently that 20 years ago when he was doing software it was possible to understand everything from the metal all the way to the blinking lights on his bit of hardware. Software development in just 20 years has progressed incredibly and it’s just not that simple any more. We can understand the basics all the way through the stack but not all of the details. There are so many bits interacting that it’s just too complex. As a result the problems, technology and team working are all abstracting away from the tangible mechanistic past.
Developers are on a path from technical skill to mastery, as they begin to understand the kung fu of software engineering they can apply experience and deep understanding to solving the technical problems, doing away with formal process and just using the practices that they intuitively need, happily breaking the “rules” to get the job done in an efficient high quality way. I’m not entirely sure where brogrammers are on this evolutionary path, I’ll leave that up to you.
The problem, if it even is a problem, is that each person in an organisation is somewhere different along this path and even if they’re at the same point in the same dimension they might not be aligned in their interests and motivations. This makes team working amongst inherently complex social creatures a tricky proposition. The sweet spot is a team of fully enlightened software kung fu masters but that’s a really hard target to meet for a number of reasons. Consider the flower of team working evolution weirdness, which area is your team in?
One reason that this sweet spot is difficult to hit is because in any organisation half of the developers are below average in technical and social skills. Sounds horrible but is obviously true and the larger the organisation the more likely it is to be the industry average, not the organisational average.
This means that the centre of skill gravity for any team is unlikely to be on the w00t side of the scale.
In most large organisations the teams are more likely to be flattened pancakes across this bell curve taking in a reasonable representation of the organisation as a whole (especially as the highest skilled are often distributed amongst an organisation to attempt to bring up other teams.
This isn’t necessarily a problem though as there is value in diversity and individuals will each have different ways of thinking about things that can bring value to teams and organisations.
I’m beginning to think that the purpose of classic software process, and classic software process improvement is to try and move people along this scale from basic developer to software ninja, helping them to gain mastery through experience and feeding in the experience of others. When a team moves along this scale they begin to not need their process mentors any more and will seize their autonomy.
Technology is increasingly commoditised by innovation, as is software development and software process. I used to spend a lot of time teaching people Object Orientation but these days everyone just seems to know it, it’s nothing special or new, it’s just what people do. Similarly people are increasingly aware of the value of iteration, limiting work in progress, continuous integration and delivery. They need less process and less instruction as this stuff is becoming business as usual at least in more mature organisations.
As these problems are being solved I think that bigger problems are coming to the fore as they’re less hidden by low level development issues. The questions I see a lot of clients wrestling with are things like:
- How can we foster the right kind of organisational culture?
- How do we deal with requirements, architecture, releases, resources etc. in a complex system of systems environment?
- How do we bring together multiple divergent interpretations of “agile”?
- How do we manage outsourcing contracts in high speed agile projects?
- How do we motivate and engage the business and technical communities?
- etc. etc.
Solving these problems is less about technical skills and technical process content and more about social skills, psychology and understanding. Both from a coaching and business perspective.
So what’s my point?
My point is that software process improvement needs to focus less on individuals and more on teams, and teams of teams. That we should avoid ideology and take the best bits of knowledge and experience wherever we find them, growing our teams and individuals.
Also that we should apply more psychology to software process and business change finding socially resonant patterns for how we do things. True mastery involves not worrying about “breaking the rules” and from the outside can easily be confused with ineptitude.
The idea of a self-organising team is pretty established in agile software development, as a (post-)agile coach/mentor I sometimes find myself working with teams who are trying to self-organise. Here’s my approach for transitioning a team from being externally organised to becoming autonomous and self-organising.
The first thing to point out is that I believe that the result of a self-organising team practice is an organisation. I don’t know what the the organisation will be ahead of time, that’s what the team work out. What I do (and I think others should do) as an agile mentor/coach is:
- Bring to the team methods and techniques they can use to self-organise
- Information of self-organising and how to interact with other teams in an organisation
- Experience of different structures and behaviours
- Facilitation and support of the organisation
It’s not my job to organise a team, it’s my job to help them organise themselves.
Being an architect/designer at heart I take a simple approach to this kind of thing and think about it in terms of mission, structure and behaviour.
Team’s need to have a purpose. I believe in team’s seizing autonomy and declaring their purpose, even in a complex bureaucratic organisation. So long as senior management are willing to let people they employ to do a complex technical job actually do a complex technical job then there tends not to be a problem. Unfortunately it sometimes takes enlightened leaders to do this but I’ve seen more and more of them in both the private and public sector. A team needs to know it’s purpose and agree on it.
Structurally there are some nice ways of working out who should be in a team and what their role is. I recommend using competencies rather than roles. Competencies are a description of the skills required to deliver the mission of the team and come in levels ranging from the most basic to the most advanced form of e.g. Tester. Either grab some from a suitable process.
Get the team together and get them to score themselves on the range of competencies required. This achieves a couple of things:
- Builds mutual understanding between team members of where the various skills lie and what level they’re at leading to mutual respect and avoiding misunderstandings around what people are “meant” to do
- Establishes whether the team has enough coverage of the required skills for the job, without this knowledge how can a team commit to anything?
Team’s need to know how they’re going to work so they need to understand their functions. As a starter I’d suggest that software development teams have the following functions:
- Production (delivery of working product)
- Communication (both internally with customers and with external stakeholders)
- Decision making
- Way of Working
- Buy-in to the mission and direction
- High level scope
- Changes to agreed scope
A true agile team does all of these things as it includes all of the people and skills necessary (from devs, testers, users, customers, ops people etc.) to achieve them. The team is the vehicle for doing these things.
Each of these things is the tip of a fairly large iceberg. But the team need to work on understanding their Way of Working to do the production job. The team need to agree how they’ll communicate with each other and externally. Both of these are Ways of Working decisions. All function in a team comes down to decision making. Ways of working, communication techniques, scope management etc. need to be constantly refined which means you need constant decision making within a team.
Even buy-in to the team mission and direction (planning and/or technical) is a decision making process. It often happens implicitly with someone charismatic selling a vision and everyone kind-of nodding but that’s not the only way of doing it.
Different decision types deserve different methods
Just because a team is groovy and agile doesn’t mean that every decision should be fully democratic. For example when doing a customer demo to see if the product is on track it’s not normally open to a general vote on whether the product meets the customer’s needs or not. Usually the customer tells you and you have to put up with it.
– identify the different categories of decisions the team needs to make
– identify (using a variation of the Vroom-Jago model) the mechanisms the team will use to make each decision type
– facilitate the decison making process reminding the team of their chosen mechanisms
The output of a self-organising practice is an organisation. Since I believe in honesty and transparency I think that the best way to define and communicate this stuff is in a Team Charter. A Team Charter can simply be:
Some blurb about what the team does – Mission statement
Assertion of rights the team assumes – Autonomy
Who the team is
Who’s in the team, what’s their ability, how do they contribute to the required competencies – Structure
How the team works
A little bit about the practices the team uses. Such as using a continuous flow model, an iterative approach etc. Including the decisions the team makes and how they make them – Decision Making
If you’d like me to help your team self-organise get in touch. Do you have any other ideas on self-organising? Do you use a different approach?
The purpose of a daily standup is to bring the team together to answer some questions (What did I do yesterday? What am I going to do today? Are there any blockers/impediments?). One of the client teams I work with has a daily standup every day in the business change team I’m part of. I’ve always found the first two questions rather pointless as basically the team would get together and read out their diaries for yesterday and today. It just wasn’t helpful and so in the past I’ve argued against the Daily Standup in it’s normal form in business change teams. It was too long and boring, especially the team is mostly comprised of mentors who’d spend the day working on their own patch of the organisation rather than with each other.
Recently I wasn’t working for the client on a Monday and my son was doing a school play on Tuesday morning so I arranged to go into work a bit late and missed the standup. And at this point I had an epiphany, I was at my desk and didn’t know how the team were feeling. I still wasn’t particularly interested in their diary commitments but I was interested in their mood and if anything of team level significance had happened since I’d last been in.
So it hit me, the value of the daily standup, as described in my first sentence, is the more about the former than the latter.
The purpose of a daily standup is to bring the team together to answer some questions…
Being able to look around the team and see who’s around, what their mood is and make the human connection is the important point. Even the metaphorical bringing of the team together physically (if possible) reinforces the team identity.
So now we’ve improved our standup process. The value of bringing the team together is paramount, the questions reworked for our team and it’s context. We examine new incoming work, how to resource it and raise impediments. So we’ve dropped the creeping death of diary exposition and just kept the value 🙂
What do you get out of standups?