If you can make it, do come along to this great 1 day conference to have some fun, share some thoughts and ideas and meet some interesting people 🙂 Here’s the blurb for our talk first thing (9am) in the morning:
These are not the practices you are looking for
Is your time to market quick enough for your business to respond?
Is your Programme and Project Management smoothly joined up with your agile teams?
Does everyone understand how their work contributes to business value?
Do you know what end-to-end scenarios will be delivered in the next programme release?
Come to this talk to hear how these common problems are easily solved, even in highly complex system-of-systems organizations by using the freely available “Holistic Software Development” (HSD) framework which aligns agile philosophy throughout the enterprise, at-scale engineering, architecture, strategy, portfolio and programme management. Using a novel but lightweight end-to-end scope level requirement type we iteratively drive the development of well understood Releases and customer feedback loops.
Combined with layered iterative or continuous integration and clearly understood progressive Definitions of Done we can simplify the complex resulting in a perfect join up between customers, requirements, planning, delivery teams and governance. HSD is the glue that plugs together your existing agile team practices (e.g. Scrum) with PPM practices (e.g. Prince2) and business strategy providing people focussed, lightweight guidance firmly based in evidence, experience and excellence.
And here’s the learning outcomes we’re aiming at:
- Understanding how to de-conflict agile and enterprise portfolio and programme management
- How to unify agile teams, governance, customers and executives in a simple model
- The “H-Model” of software development
- How to join up different schools of thought/processes into a cohesive way of working
- How a strong approach to understanding business value enables effective software businesses
You may detect a slight Yoda-like grammar to the title… Come or come not, there is no spoiler.
Software is increasingly important to everyone, it’s everywhere. It’s in our phones, runs our cars, our cities, our healthcare, entertainment and utilities. There are few businesses without a software element and many that are critically software dependent. What these organisations are finally beginning to understand is that the business of doing software is difficult, in fact it’s complex. It needs C-suite level direction and coverage.
Being good at software isn’t a matter of hiring the good coders, buying the right workflow management tool, using the right Configuration Management system, hiring the right management consultants or using the correct technology. These things all have a part to play but they’re supporting parts to the most important factor: culture.
Software Development is a team activity and the team is bigger than we used to think it was (a few developers, testers, direct customers, managers, analysts etc.). A good set of development practices at team level isn’t enough to be effective because software development is a business enabling activity and so it touches all parts of an organisation (development teams, hr, procurement, security, business change, legal, financial, business services, operations, support etc.).
As organisations evolve to make the maximum use of technology they are making increasingly complex software products, often through diverse technology stacks, using a variety of in-, near-, and out- sourcing partners. Delivering systems of systems across teams of teams is not simple and so organisations are now looking to embrace the importance of software, technology and ways of working to their businesses at board level.
What is a Chief Software Architect?
Whether a “Chief of Software“, a “Chief Software Officer“, a “Chief Digital Officer” or “Chief Architect” the role tends to include:
- Leading and encouraging a positive software development culture
- Where delivery of business value is the primary measure of success and decisions are based on business value
- Where failing fast is a cause for celebration not a career ending issue
- Where software is designed for users/customers needs
- Where continuous/iterative development integration and deployment are the norm
- Where teams collaborate and co-create with each other and their customers to produce the best products
- Where thinking all day to write a perfect algorithm is worth more than pushing out hundreds of lines of code quickly
- Where professionals are trusted to do their jobs properly
- Where organisational impediments to smooth software development are removed, from board level if necessary (due to Conway’s Law transformational change is often impossible without such top-level leadership)
- Providing top level architectural direction and governance (sometimes called Enterprise Architecture) that strikes the balance between directing technical decisions towards alignment but not imposing restrictive unchanging standards on development teams
- Architecture is understood cohesively at Enterprise, Solution and System levels
- Architecture exists in the form of directed (but community driven) standards, off-the-shelf mechanisms and principles
- Architecture exists primarily as executable software although appropriate weight documentation, models, examples and usage guides describe it
- Architecture provides a context for making technical decisions in normal development, makes technical decisions on commoditized platform/software/operations choices but does not constrain innovation and research (architecture has a different impact in different parts of a hybrid dynamic model)
- Architecture enables control of whole-lifecycle costs by smoothing the flow of work from innovation and research into mainstream development and support
- Ensuring that teams can use the tools they want and need to use, not those that had the best sales pitch to a non-technical board (hint: these are normally small, simple and/or open source, not those provided by large vendors) balanced by creating a cohesive community that isn’t unnecessarily fragmented by every team needing to set up different tools environments
- Tool chains take the pain out of development, testing, build and deployment – automated wherever possible
- Development environments are appropriate for actually developing, building, testing and deploying
- Ensuring, and embodying, the principles of agility, devops, and agility-at-scale at the organisational level – promoting the evolution of working practices, operating models and ways of working while avoiding endless management fads
- Building and championing the needs of the development community, attending to their needs
- Ensuring that portfolio selection takes into account technical issues, shaping it in line with architecture and in turn using business priorities to shape architectural choices
At a business level Architecture exists to guide organisations through the business, information, process and technology changes necessary to execute the organisation’s strategy. Because “architecture” has always been more than just the technology bit, it also focusses on the non-functional aspects necessary to make the technology work terming a “Chief Software Officer” an Architect is an organisation recognising that to be successful at software a holistic approach is required that combines business concerns with technical concerns.
The idea of an “Architect” role with such a broad focus is analogous to that of a structural architect concerned with buildings. Indeed in 25 BCE Vitruvius (a well known Roman writer and architect who inspired Leonardo Da Vinci, hence the Vitruvian Man ) described an architect as:
The ideal architect should be a man of letters, a mathematician, familiar with historical studies, a diligent of philosophy, acquainted with music, not ignorant of medicine, learned in the responses of jurisconsults, familiar with astronomy and astronomical calculations.
Virtuvius is famous for stating that architecture must be solid, useful, beautiful (De architectura). The same three qualities relate to software architecture. Architecture is a fine balance between a subtle science and an exact art – as such it is the magic sauce that turns a technology strategy into business benefits.
If your business is reliant on technology and/or software and you don’t have a Chief Architecture, you should promote/get one before you become technically irrelevant, encumbered by lumbering traditional delivery approaches based on manufacturing and negative development cultures.
It’s time for businesses to recognise the important of software, and architecture, before they’re outmanoeuvred by those who have.
For more on Architecture see:
- An overview of architectural purpose and concerns, including detail on different levels and approaches: Holistic Architecture
- Architectural Profiling
- Agile Architecture
- What makes “good” software architecture or design
- Intentional vs. Emergent Architecture
- How to write a good strategy
- Hybrid Dynamic Model
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.
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!
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.