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
Strategy is a plan that provides overall direction for an organization and a framework for decision making.
Strategy is the instrument by which executive decision makers communicate and drive the future direction of their organization, without clear well-communicated strategy the organization becomes directionless. The purpose of strategy is to set the overall direction that an organization will take; it is the expression of executive intent and is effectively a contract between the directing layer of an organization and its sponsors (shareholders or elected representatives for public sector concerns). Strategy, specifically in the form of Strategic Goals, forms the very top of the requirements stack driving the portfolio of work and shaping enterprise architecture.
Recommendations for effective strategy
Articulate how Business Value is understood and measured – this helps everyone understand the business purpose and the primary measurement of success helping avoid implementation of intermediary measures that are mis-aligned to strategy
Minimize the number of organizational layers – this avoids unnecessary translation of information across layers and unnecessary middle-management resourcing. See information on Resourcing Levels and Workforce Shaping for more.
Make bold strategic changes – if change is required then sometimes drastic change is required rather than a series of small changes, it might be painful but it’s likely to be more cost-effective to make a bold change.
Push tactical decision making as low as possible in the organization – this empowers individuals to use their skills properly within the organization and prevents stragic decision makers from getting swamped by minor issues. Business Leaders must back up tactical decisions made by their staff for this to work.
Continuously make small tactical improvements – don’t wait for a large change in a year to improve something small that can be fixed today. Make the change and measure the improvement to validate the change and ensure systemic improvement.
Forget the past – Business situations involving large numbers of people are extremely complex and so similar situations from the past are not good indicators of present or future events. Correlation does not equal causation.
Tests for a good strategy
Does the strategy communicate a clear change?
Is it engaging, inspirational and compelling?
Is it clear and unambiguous?
Does it describe the rationale for change?
Is the Business Strategy achievable? or worth risk of failure?
It it relevant to the prevailing business environment?
Do the business goals provide value to the sponsors?
Does it contain a roadmap/plan? Or can one be easily derived?
Does it contain short, medium and long-term goals?
Are strategic goals identifiable, measurable, tangible business state-change milestones?
Do strategic goals follow a logical sequence to a desired end-state?
Does it consider resourcing necessary to realise the goal?
Is it executable?
Extract from Holistic Software Development – Strategic Direction
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.
HSD stands for Holistic Software Development which is a process framework that extends the principles of agile philosophy throughout the entire software development enterprise. Similar to “agile at scale” ideas HSD goes a few steps further integrating software development concerns from business strategy to continuous development, structural organisation to governance on the H-Model of software development.
HSD provides the “big picture” of software development providing a glue that combines other techniques and practices. It doesn’t replace what you currently do (e.g. Scrum, XP, Lean, Prince2, whatever) instead it provides a simple way to join them all up together, without introducing any new TLAs (Three letter acronyms)!
HSD is free to use, free to access and free to implement!