Mike MacDonagh's Blog

Somewhere in the overlap between software development, process improvement and psychology

Category Archives: methods and tools

Holistic Software Development @AgileInABag London 12 June 2015

Agile In a Bag London 2015

I’ll be presenting with my friend and colleague Steve Handy about Holistic Software Development at the Agile in a Bag conference in London on the 12th June 2015.

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.

Advertisements

The rise of the Chief Software Architect

ArchitectureSoftware 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

Why “Architect”?

The Vitruvian Man - Leonardo Da Vinci

The Vitruvian Man – Leonardo Da Vinci

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:Architecutural assets

 

 

How to write a good strategy

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

Overall
Does the strategy communicate a clear change?
Is it engaging, inspirational and compelling?
Is it clear and unambiguous?

Why?
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?

When?
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?

What?
Are strategic goals identifiable, measurable, tangible business state-change milestones?
Do strategic goals follow a logical sequence to a desired end-state?

How?
Does it consider resourcing necessary to realise the goal?
Is it executable?

 

Extract from Holistic Software Development – Strategic Direction

The Hybrid Dynamic Model

The Hybrid Dynamic Model is a modern approach to structuring an organisation’s portfolio that allows for multiple ways of working to co-exist from innovation to utility work and for that work to change which processes, cultures and practices it uses over time.

An “Operating Model” describes how an organisation does its business in terms of both its structure and its behaviour – it is the business architecture. An “Operating Model” exists in every organisation, whether it is explicitly written down or simply a collection of processes and practices. The Operating Model includes how strategy flows through planning and delivery, how money is spent and controlled, how governance works, how people are organised, how quality is assured etc. If the Operating Model is inefficient or unable to react well to change, everything else suffers.

Many organisations evolve an Operating Model that fits their stable way of working, allowing for a focus on efficiency and improvement, driving out variation. This approach can work well in periods of stability but makes organisations brittle and unable to react well to change because the only way the organisation knows how to deal with things is to apply its tried and tested approaches. When the environment is less stable, or the variety of work types increases a Hyrbid Dynamic Model is more appropriate.

A useful mechanism for understanding different types of work, and the different approaches that may be applicable to delivering them within a portfolio is the “Commoditization Scale”. The Commoditization Scale describes a range of types of work from innovation (undefined, rare, speculative and high risk) to more commodity/utility (well defined, ubiquitous, and less differentiated with lower risk).

These different types of work require different ways of working, contractual models, technologies, supply chains, cultures, processes etc. More well understood work is more predictable and manageable by its nature, whereas the opposite is true for less well-understood work.

Commoditization scale Commoditization scale inspired by Simon Wardley – CSC Leading Edge Forum

As organisations begin to understand their work in terms of a hybrid model they can then look to actively apply a commoditization pressure where possible moving work across this scale. Because commodity solutions (often bought in) are typically cheaper than in-house development, maintenance and hosting commoditizing work earns a “Commoditization Dividend” which can then be used to reinvest into the Innovation parts of a business.

As mentioned in Build or Buy we generally recommend against building utility or commodity components, systems or product (unless disrupting a service industry) – these kind of products are best bought or provided by open source alternatives (COTS). However in terms of inventing/innovating and specialist products different processes, working practices, teams and cultures may be necessary. Innovation work is typically riskier and speculative than more mainstream specialist products and so will be less tolerant of up front planning. “Failing fast” is particularly important in innovative/inventive work and this type of work is typically very unpredictable. As a result building significant structure (in terms of project, programme and Solution Architecture) around innovation work is unlikely to be productive – this work may also be unconstrained by Enterprise Architecture (and indeed “standard” ways of working).

Unless explicitly necessary we recommend that innovative work is treated as self-organized Product Delivery teams that are directly part of the Portfolio, with no programme structure. This (Small Picture) model is preferred for small, simple projects or organizations generally. Small organizations can often outperform large monolithic organizations due to their lack of process, management and architectural inertia – they are free to innovate. Since the relentless commoditization of technology forces all organizations to innovate to survive we strongly recommend freeing people to innovate in whatever manner they need.

There’s nothing worse for innovation than an ideas process

Similarly, and perhaps counter intuitively, there is also less structure required in the Utility and Commodity areas of the commoditisation scale (because the products built are often well-understood, predictable, related to system integration and frequently COTS). This type of very predictable work often benefits from workflow management techniques such as Lean, Kanban or service management processes.processes and commoditisation

Products that are more Specialist may need a “bigger engineering” approach depending on their scale or risk factors. Many large organizations will adopt more formal processes in this area as they seek to find economies of scale, especially around reuse. However over time reusable platforms and architectures can become a hindrance rather than a help. Technically skilled people will notice this point and are encouraged to Bubble Up their concerns. Organizations with significant effort in more than one of these areas of the scale above tend to gravitate towards a hybrid model with a structure embedded in the Specialist, Commodity or Utility part of the business. Applying the same structures, architectures, processes and working practices across all of these work types can cause problems so a hybrid model is likely to be required for large/complex organizations.

We recommend using a hybrid, dynamic model for organising a large/complex portfolio. Large, complex organisations have significant effort and coverage across the commoditisation scale. Implementation of a hybrid model caters for this variance using unstructured and structured models where necessary. Structure is introduced only by exception when explicitly needed to orchestrate effort across divergent teams and portfolio(s) not as the default approach. Importantly as pieces of work become more understood, or product sets evolve they will likely begin to move on the commoditisation scale and so may need to dynamically change their ways of working.

The Hybrid Dynamic Model allows for significantly different ways of working, within the cohesive governance of the H-Model of Holistic Software Development. Using the hybrid dynamic model organisations can have multiple ways if working, cultures and practices co-existing peacefully within a single enterprise portfolio. Using different ways of working, practices and techniques across the portfolio helps bring together the otherwise extremely different extremes of innovation and research work with predictable project delivery. Other business models, such as Incubation, can also be used to help bridge the gaps between areas such as innovation and mainstream engineering practices.

Hybrid Dynamic Model

Many organisations evolve a Portfolio → Programme → Project → Team model which is then applied to all work in the portfolio due to its past success at delivering large predictable engineering projects. However, this model is wasteful when complexity is low and can actually inhibit communication and feedback cycles in more speculative work.

Programme and project structures cause layers of separation, which result in emergent transactional behaviour, effort duplication and confusion over roles and responsibilities. As a result programmes should only be used when there is a genuine requirement for co-ordinating multiple projects that must be integrated for a cohesive product family or business capability. In other cases programme structures should be condensed – removing programmes that are simply funding lines; Portfolio Management can and should manage funding lines and stand-alone projects can simply be part of the portfolio.

Reduction in structural complexity will reduce costs, increase flexibility and adaptability while simultaneously improving an organisations ability to react in a rapidly changing environment. Additionally, simplifying structure will reduce the sheer numbers of people involved in project management and definition work, removing unnecessary barriers between delivery teams and their customers.

This kind of hybrid structure is similar to using the Small Picture of HSD for the Commodity Portfolio, the Big Picture for the Specialist Portfolio and the Small Picture again for the Research and Innovation portfolio – naturally sharing the same Strategy and Governance layer.

COTS implementation may be a signficant piece of work by itself. The COTS Implementation article describes a variant of the Big Picture for use with COTS.

HSD Introduction SlideShare

Epics or Integration Scenarios?

Many teams I’ve worked with struggle to make sense of their huge backlogs of stories, struggle to explain the scope of a release and current work – and most importantly, struggle to explain how the stories they’re working on contribute to business value!

All of these problems are killers when it comes to joining up what a development team is doing to a corporate portfolio, governance and milestones. Features and business benefits seem to be too high level, stories seem to be to low level.


 Epics

A common approach to trying to solve these problems is to use “epics”. Originally intended to just be another type of story (one that was too big for a sprint) “epics” are now commonly used in a requirements hierarchy by teams and organizations. I’ve seen loads of backlogs where every story had an epic “parent” – sometimes even a 1-1 mapping from epics to stories(!!!!). I know that some process frameworks recommend this approach, but I don’t and here’s why:

Stories can just be on a backlog

Stories don’t have to have a parent. A backlog made up of stories is just great, it doesn’t need a hierarchy that’s a Work Breakdown Structure using some agile-y sounding words to hide the fact. A backlog isn’t a gantt chart, stop trying to turn it into one by stealth!

Actual epics are useful for teams

“Epics” in their original form were simply stories too big for a sprint, sometimes that just creeps up on you so it’s useful to be able to tear up a big story and replace it with some smaller ones. By formalizing a Feature -> Epic -> Story hierarchy as an “agile at scale” process I’ve seen corporate processes become protectionist over epics, trying to use them to fix scope, counting and metricating them to the extent that teams can’t simply discover some of their stories are epics.

Bigger stories need more than a sentence

I know that a story can have more elaboration than the standard form of “as a user I want to…” but few stories in the wild have more than a sentence (you’re often lucky if you find some with acceptance criteria). I find that describing how various stories contribute together (especially when across several teams and/or systems) to deliver business value I need more than a sentence. I often need a diagram or a paragraph or two.

“Epics” sound silly

What’s in a name? Would a rose by any other name smell so sweet? Probably. Names shouldn’t be that important and yet they are, what we call things has a significant impact on how people represent them. “Epics” are part of the money spinning agile movement’s language. They either sound silly to businesses or as a way to pretend they’re doing “agile at scale” by adopting the term for their portfolio requests.

I like Integration Scenarios more

Ok, so this is clearly subjective and personal but that’s kinda my point. I don’t use process elements because someone told me to, and I don’t think that something like Integration Scenarios are always better than epics. I prefer to pick and choose different tools for different jobs. In my experience Integration scenarios are frequently a better tool for scoping, elaborating and agreeing  end-to-end threads across a system or system-of-systems so they’re one of my “go to” tools.


So what are Integration Scenarios?

Originally from Holistic Software EngineeringIntegration Scenarios

Integration Scenarios describe an end to end workflow across a Product or Product Family. Integration scenarios are threads across a number of low level requirements such as user stories that collectively deliver Business Value. They are ideally suited to describing the scope of Releases and providing the input for integration testing necessary to achieve higher levels of acceptance.

Integration Scenarios can also be used to manage cross-cutting Non-Functional Requirements and drive the discovery of Architectural Mechanisms.

Integration Scenarios provide the context for discussions around User Stories

Integration SceExample of graphical Integration Streamnarios can be described in a number of ways, ranging from textual to graphical depending on the nature of the system and the best way to achieve clarity. In all of these examples we recommend using a meaningful title, not “Integration Scenario”!

One of our favorite ways is to draw an activity diagram of user interactions using GUI mockups in the nodes with references to features/use cases/stories as appropriate. We do not recommend strictly following a diagram format but using the visual or textual elements that will communicate the scenario as effectively as possible. Story-boarding can also be an effective way of describing Integration Scenarios.

When using a graphical view we recommend including links to stories or systems that are covered by the scenario and adding rich graphics to standard modeling notation to increase communication.

Example of textual Integration Scenario Integration Scenarios using textual formats are best described as a narrative with links to contributing stories or systems.

They should ideally be no more than a couple of paragraphs that describe interactions between actors across a number of stories. Sometimes adding extra alternative or exceptional flows can be useful, in the style popularized by use cases, but if there’s a lot of “flow logic” involved then we recommend using a diagrammatic form (e.g. workflow) to avoid convoluted textual documents. Similarly adding a non-functional section indicating non-functional requirements or constraints that apply across the stories making up the scenario can be useful.

Integration Scenarios describe the dynamics between stories and how they collectively contribute to delivering business value. To that end we recommend highlighting and directly linking to the stories that make up the integration scenario. In this way Integration Scenarios add context to the mass of user stories and provide a sound basis for scoping a system, describing a release, functional architectural mechanisms, integration testing, and product acceptance.

Regardless of format we recommend that Integration Scenarios are described from the user perspective and focus on achieving business value. The choice of formats should be driven by the type of Product being developed (e.g. graphical/user facing vs. back end service) and further influenced by team experience and available tooling. We strongly advise not being concerned with the constraints imposed by formal modeling languages, the communication is important not the notation.

Example of simple graphical list view of an Integration ScenarioSometimes we wish to use Integration Scenarios as part of diagrams, even workflow/activity diagrams (e.g. for Value Stream Analysis) in which case the full text version might be a bit big. In these situations we recommend using a “zoomed out” view which just lists a title and the related stories. In fact this “elided” form of an Integration Scenario is sometimes useful for simply gathering up a collection of stories into a larger chunk for planning purposes. Story lists in these diagrams don’t have to be exhaustive, just indicative.

Practicality

Textual Integration Scenarios can be crafted in and decent rich text editor that allows for hyperlinks. We recommend trying to keep them short since the detail of the requirements should be in lower level stories or UX designs/storyboards. Instead the Integration Scenario focuses on the dynamics between requirements. A good rule of thumb is that they should be only a couple of paragraphs, and at their biggest if alternates/exceptions and nonfunctionals are included they should only be 2 or 3 pages. Creating a large number of fully documented Integration Scenarios prior to any development effort is a very bad idea as it will introduce the problems inherent in waterfall development, however elaborating the Integration Scenarios for a Release prior to development iterations/sprints or continuous flow development (with customer representation and team representation) is an excellent way to align collective understanding of scope and requirements.

Each Release should have no more than a couple of Integration Scenarios in it, if there’s more and they are not too interdependent then they can be delivered in separate Releases enabling earlier feedback cycles, (even if they are internal Releases rather than operationally deployed customer release.

Links to other elements

The H-ModelIntegration Scenarios provide a mid-level requirement type, higher than User Stories but lower than Portfolio Requests containing a lot more information than a Feature. As a result Integration Scenarios provide a unit of incremental business value which can be used for Release Planning, tying in milestones for programme/portfolio tracking and governance.

Because Integration Scenarios are constructed in a narrative form that describes a scenario, tried and tested scenario based testing methods can be applied for Integration testing.

Integration Scenarios also provide a useful starting point for understanding Solution Architecture, in the case of Product Families or systems of systems,  and even System Architecture in terms of indicating structure and identification of mechanisms. It is possible to resonate architectural structure with Integration Scenario structure although there is a risk of inappropriately introducing a Homomorphic force to the architecture.

By aligning Integration Scenarios with Integration Streams, Releases and Milestones we can focus the various views of Portfolio Management, Programme Management, Project Management, Architecture, Delivery, Quality, Deployment, Acceptance and and Business Change onto Releases at the center of the H-Model de-conflicting business management and technical delivery. Providing a context for requirements, planning and delivery Integration Stories are a common currency for the entire IT organization to work with.

Integration Modeling

Example of an Integration ModelIntegration Scenarios can also be used as part of Integration Modeling (creating scope diagrams) to indicate which actors/systems sets of requirements interact with, helping to clarify overall scope and identify potential gaps in scope.

If using Integration Modeling we recommend color coding Integration Scenarios based on priority (e.g. Musts, Shoulds etc.).

A Scoping Diagram is used to draw a picture of the primary requirements and users/interacting systems.

Read more: Scoping Diagram


What are your experiences of “Epics”, “Integration Scenarios”, “Scoping Use Cases” or other alternatives?

%d bloggers like this: