I normally avoid posting on controversial things but this is a topic that shouldn’t even be controversial.
The world is full of a marvellous variety of people and they come in all shapes and sizes, with a staggering range of ways of thinking. People are different due to things like gender, race, ability, sexual orientation, cognitive difference and all sorts of other things that affect identity. Importantly people are never just one of these things, real people exist at and between all of the intersections.
In the software industry we often rally behind people based statements such as “Individuals and interactions over processes and tools” and yet discrimination and unfairness are rife in the technology industry with “brogrammer culture”, sexist pay situations and the infamous glass ceiling. And yet we talk about being open and inclusive in how we do software in teams? And wonder why there aren’t more women taking technology courses at universities?
Feminism is a collection of movements and ideologies that share a common goal: to define, establish, and achieve equal political, economic, cultural, personal, and social rights for women. This includes seeking to establish equal opportunities for women in education and employment.
Women aren’t less than men. Men aren’t better than women. Instead people are just people, and each individual isn’t just a woman or man, they will be different in many other ways, expressing their identity, individualism and indeed diversity in each of them. There is value in diversity, and as people that can understand recursion we should be able to grasp that concept. The more ways we have of looking at a problem the better our solutions will be.
I believe that everyone should be treated fairly, that equal opportunities should exist for individuals, that if we need to differentiate between people (e.g. in terms of who to hire) that we should do it on merit, on skill, attitude and behaviours not on what makes a person different. I guess that makes me a feminist.
I’m a feminist because I believe in equality. Gender is one axis of difference that is used to discriminate against people and women are generally treated less fairly in the tech industry than men and so that’s why I’m a feminist not an “equallist”. I realise that this is an unpopular stance to take amongst some groups, especially those who are uncomfortable with a man using the word “feminist” but I think those people should take a good long hard look a themselves. If you’re not a feminist, you should probably go and explain why to your mother rather than argue with me about it.
Men, and women, and in-betweens and neithers, all need to stand up for equality, need to challenge unfairness when it raises it’s ugly guise. The amount of times I’ve seen sexist treatment, casual racist and homophobic language in the tech and gaming industry is shocking and it needs to change. Otherwise we can hardly call ourselves civilised. Of course, there are always weird situations where it’s not clear whether something is discriminatory or friendly banter – exploring those situations in an open and honest way, discovering if behaviour, language or tone has crossed a line helps us all understand each other better. Conflict is best avoided through clarity of understanding between people. Ultimately though the meaning of any communication is that which is received, regardless of the intentions. If you accidentally offend someone it’s still you who are offensive, not the victim who needs to grow thicker skin.
As men, we are morally bankrupt if we leave standing up for equality to those who are marginalised and discriminated against. Equality requires us to collectively act.
An embarrassment of Project Managers
An impasse of Architects
A confusion of Business Analysts
A mob of Developers
A silo of Testers
A brethren of Scrum Coaches
A waste of Lean Consultants
A conspiracy of Process Improvement Consultants
People are important, not roles! But recently I saw a weekly team meeting for a project that had 12 project managers! I thought it was a joke at first.
Can you think of any others?
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.
How do we join up business strategy to agile development? Is program management relevant? Where do project managers fit in? What about architecture?
Holistic Software Engineering (HSE) answers all of these questions – for free.
Agile and continuous flow are great for small teams or a small number of inter-related small teams working on exploratory or maintenance work. But what if we’re spending 100s of millions on an IT strategy of inter-related products that need to work together to deliver business value. What is business value anyway?
To answer these questions (and more) my friend Steve Handy and I have distilled our collective 30+ years of software experience in a single, cohesive model of software development. We’ve developed the H model that moves on from the v-model and it’s siblings by combining:
- Business strategy
- People and team issues
- Iterative and feedback loops
- Lightweight requirements and architecture
- Lean portfolio and program management
- Agile and continuous product delivery
- A focus on integration, quality and business value
…all elegantly combined and de-conflicted by release planning.
We’ve not invented very much, we’ve simply put a lot of good ideas from others together into a cohesive framework. We’ve drawn it all as a big picture and developed a website that shows how to get value from all of this stuff. Everything is clickable, everything has content.
The best bit: it’s free! There’s no paywall, there’s no private “full” version, you can just use it or not as you like.
We don’t believe in process zealotry, or putting academic concerns above clarity and usefulness. HSE is indicative, not prescriptive. You’re already doing it and if you use the big picture to draw red blobs on the bits that aren’t working well, or missing, in your organisation then you can use the model to make tangible improvements – immediately.
Using HSE doesn’t replace any of your existing processes, it provides the glue that joins them all up together in one simple, elegant and cohesive model.
And if it’s too big, we’ve got a small picture, which is essentially “normal” agile development.
Please share HSE with your friends and colleagues.
I was reading some course material recently that was trying to teach people something to do with software development and it was using the same old tired “ATM machine” example. I’ve worked with hundreds of projects, many in the finance sector and none of them are anything like an ATM machine. One of the reasons that example is soooo tired is that it’s describing commoditised software development, it’s something I’d expect to buy off a shelf or go to a specialised vendor for. It’s not something I’d put my team of uber |33t haxorz on.
Developing software products is a balance between a creative and scientific pursuit, so it’s a little hard to describe, especially when that software can range from a tiny smartphone app, to a website, to router firmware, to an enterprise hr system (urgh!), to a big data processing system of systems etc. You get the gist.
The things these types of system have in common with each other is how different they are. And yet the traditional approach to managing these diverse kinds of work has been classical project management with a one size fits all process (I’m looking at Prince2, RUP, Iterative, Agile etc.) or worse hiring a large company full of body-shop project managers. For me this is one of the root causes behind large scale IT disasters.
I once had a discussion with the leader of a PMO in a large organisation of thousands of people about the nature of Project Management for software and he assured me that “someone who knows how to manage a bit of work can manage software, it’s just a different type of work” and indeed I should “stop thinking of software as special”. I’ve seen this attitude resonate in many organisations and is to me best summed up by the same Head of PMOs statement “from a project management point of view building software is the same as building a bridge”.
Now then. I know a little about software development, but not that much about bridge building (if you exclude my illustrious Lego engineer career when I was 7). If I managed the building of a bridge next door to one build by someone with a track record of bridge building who’s bridge would you drive your family on? Not mine if you’ve got any sense.
There are so many problems in the software development industry caused by people not understanding it and applying bad metaphors. When people who do understand it start to get the point across (e.g. the early agile movement) they often get misunderstood by the old guard who dress up their normal ways of working in new language.
Many of our “best” metaphors come from manufacturing lines where the same thing is made over and over again. That’s nothing like software.
To me a software project is more similar to making a movie than anything else:
- It’s a unique one off product (or a remake of a previous version) with new parts working together in new ways
- Once made we’ll often duplicate and digitally distribute
- It can cost a lot of money because it can be very complex and needs lots of specialist skills
- You need a high level plan for how you’re going to make it
- There’s no guarantee on return
- What’s written down originally bares little resemblance to the finished product
- We know when it’s good or bad but it’s hard to objectively quantify
- There’s lots of different types that need different collections of specialist skills
- Both involve people and time and so are subject to change, they have to be adaptive
- You can tell when the people making it had fun
- It’s not feasible that any team member can fit in any role
- There’s almost always going to be some quality problems
- You wouldn’t get a movie maker to build your bridge
- You wouldn’t get a bridge builder to make your movie
- You don’t make a movie faster by telling the actors to act faster
So, I don’t want a Project Managers that know how to work a gannt chart. I want movie producers that know how to work with a team holistically to get the best out of them both technically and artistically.
Big A vs. Little a
Huh? What? I’ve written a fair bit on this blog about agile topics, but I always try to write about agility with a small “a”. I’m not really into Agile with a big “A” though – I’m not into doing things according to a set of rules and having arguments about whether I’m doing it right or not. I’m not anti-agile, but I’m increasingly anti-Agile.
To me, the ideological arguments, definitions of everything, frameworks, money-spinning certifications and money-spinning tooling are what’s wrong with doing “Agile”. Being empirical, reflecting and adapting, honestly communicating and putting people first as an approach is being “agile”.
I don’t really like the term “post-Agile” either though as it comes with a bunch of baggage and is easily misinterpreted – and I still see benefits in adopting agile practices. I don’t want to see another specific set of rules or a statement or beliefs with elitist signatures. For me what’s next after agile is about dropping the ideology in software process, destroying the ivory tower of trademarks, formal definitions, money spinning tools and money-spinning certification programmes.
We need to get rid of the League of Agile Methodology Experts and if anyone says “Ah, but this is different” when showing a website of process content then you have my permission to hit them with a stick.
So what does the future look like?
Software development is a complex social activity involving teams of people forming and self-organising to work together, sometimes in teams of teams which is even harder. As technology is increasingly abstracting up and raising in maturity so is the way that developers, managers and organisations think about software and doing software. I think the problem is getting increasingly social, and the solutions will start looking increasingly social using more “soft practices”.
Software process improvement agents/consultants/coaches/mentors (including myself) need to take a long hard look at themselves. Are they telling people how to do it right when they can’t even write HelloWorld in a modern language? I’ve said that to some acquaintances in the industry, generously qualifying “modern language” as something significantly commercially used in the last 10 years and seen them look quite offended at my insulting affront to their professional integrity. I’ll go out on a limb and say you can’t coach a software development team if you don’t know how to write software.
So… software process improvement?
The world runs on software, it’s everywhere and it’s critical. Getting better at doing software, improving the software value chain, is a noble aim and will continue to be as it means getting better at doing our businesses and our lives.
For me process improvement (dislike that phrase as well) is going to be more about combining psychology based business change practices with the best bits of a wide variety of ways of working (agile, lean, Scrum, what you currently do, RUP, Kanban, various workflow patters etc.) with technical software development practices like continuous integration, continuous delivery.
We need to work together, not as “leaders and followers” or “consultants and clients” but as collaborative peers working together to apply specialist skills and experience so that we can all improve. Smart people should be treated as smart people, we have much to learn from them and should be thinking in terms of fellowship rather than leadership.
I’m calling this overlap “soft practices”* because the term is evocative of:
- The practice of doing software
- The practices involved in doing software
- Being able to deal with people is sometimes called having “soft skills“
- Soft power
What do you think about “post-Agile”?
* I’ve even set up a company called Soft Practice to do this stuff, that’s why I’ve not been blogging much recently, who knew there’d be so many forms to fill in!