Category: process

How To Make Scrum Work With Company Processes!

A small or medium company could have the following processes:

  • Sales & Marketing
  • Finance & Accounting
  • Management & HR
  • Delivery
  • Development

In addition, let’s go through some basic concepts which we need to go through first in order to form the high-level understanding.

A management system is a set of policies, processes, and procedures used by an organization to ensure that it can fulfill the tasks required to achieve its objectives. ITIL is a framework consisting of best practices and processes that can be adopted in order to provide IT service management (ITSM). Information security management (ISM) describes controls that an organization needs to implement to ensure that it is sensibly protecting the confidentiality, availability, and integrity of assets from threats and vulnerabilities. ISM is a process and a function in ITIL. Quality management (QM) ensures that an organization, product or service is consistent. It has four main components: quality planning, quality assurance, quality control and quality improvement. Usually in quality management system related company processes are highly valued!

Let’s also list a few important frameworks: Scrum itself is a simple framework for effective team collaboration on complex products. SAFe is a commerialized framework for scaling Agile across the enterprise. ITIL is a framework of best practices for delivering IT services. SAFe provides a somewhat complete representation of how it can be used to govern company’s development process – alas, it is massive and complex. We need a simpler and truly agile integration between development and company processes. This is what I try to achieve: in this post I am going to lay down foundations and point out the place where your company can use Scrum for software development, and a simple workflow for creating software and product versions.

My proposal for managing development aka Development Process:

  1. Product development process (PDP)
    • output is Product Release
    • input is Increment Release
  2. Product increment process (PIP)
    • output is Increment Release
    • input is Scrum Increment
  3. Scrum increment process (SIP)
    • output is Scrum Increment
    • input is PDP decision to build or change the product w/ Scrum
CustomerIteration (experiment)Execution (value)
ProductDiscovery (what)Delivery (build it)
SoftwareDevelopment (sw)Delivery (from CD)
Orthogonal view on separation

The software development happens in PIP and SIP (in this model). It requires software life-cycle management (SDLC) practises. Practically speaking, many company processes are strictly defined and too poorly monitored: process should not be detailed but be envelope -like. And yes, the monitoring and reporting must be automated to a suitable and a level where continuous improvement is possible. It specifies inputs and outputs, and constraints: think of a it like an interface, implementation details can change but interface is the abstraction! If you can’t easily perform a process audit/walkthrough using simple checklists, you should refine the company processes. The scope of the upcoming post about aligning sofware development with product development and company processes will be PIP and SIP! You can freely choose PDP because this model only expects that PDP receives a Increment Release from child process. Increment Release is my term and the equivalent term is just a “Release” meaning a version controlled and packaged piece of software delivered together with some technical documentation like release notes.

For more project oriented company which sells and delivers software as projects I would recommend using SAP ASAP method as depicted: source https://blogs.sap.com/2012/08/20/sdlc-vs-asap-methodology/ It is quite common way of customers buying software as it is easy managed: a project has somewhat fixed price, schedule, and scope. In Finland this means: toimitusprojekti for creating the software system using some toimitusmalli and käyttöönottoprojekti for taking it into use in production. Please note that ASAP allows using iterative software development methodologies, and for that I would recommend using Kanban – and not Scrum as it is quite heavy for this method.

To summarize: a company usually has multiple processes. One of them is the development process that can be focused on product development. Software development happens under that process. Processes can be managed and improved with management systems. When processes overlap, the owner process is not present in the owned process: for example, a product development process might have some qualities which arise from Quality process, but it does not include any elements in it. This way it is easy to manage different processes! A product usually is turned into a service or a solution, but that part should be handled with a company’s ITIL process – and forget about SAFe implementation!

P.S. BSI offers some assistance in PAS 99:2006 Specification of common management system requirements as a framework for integration. It is intended for use by organizations who are implementing the requirements of two or more management system standards such as ISO 9001 (Quality), ISO 14001 (Environment), ISO/IEC 27001 (Information Security), ISO/IEC 20000 (IT Service Management)

P.P.S My other relevant blog posts:

P.P.P.S. Software quality according to ISO25010:

Source (iso25000.com)

Reference Model: Software Development Process

In my previous post I suggested that Development Process = PIP + SIP.

Product development process (PDP)

Product increment process (PIP)

  • output is Increment Release
  • input is Scrum Increment

Scrum increment process (SIP)

  • output is Scrum Increment – there can be multiple Scrum Increments in one Increment release
  • input is PDP decision to build or change the product w/ Scrum

Different outputs:

  • Product Release is a new version of the product including all non-technical and technical material and effort like documentation, marketing & sales material, … The focus is on the service or the solution where the product is used: you need to map customer needs to product features and solve customer problems.
  • Increment release is a set of potentially releasable Scrum Increments. During the time the development (product) spends in this part, the focus is highly on software verification and validation: mainly it involves different types of testing and quality controls.
  • Scrum Increment is the increment mentioned in the official Scrum guide. The increment is version controlled in Source Control Management system, the packaged artifacts are managed in Artifact Repository, technical documentation is managed in form of release notes in e.g. wiki and issues in Issue Tracking System. This level operates mainly at code (change) level.

One product backlog but two levels of views (boards in JIRA). Remeber to clean up the backlog too because it is not good practice to keep over 150 items in the backlog

  1. PDP level view: you can use e.g. product requirements documents and some suitable tool to manage them. When you convert product requirements into software requirements you can define them as features, epics, user stories, etc., but these requirements should be documented and managed somewhere but not in issue tracking!
  2. PIP level view: For managing software verification and validation: e.g. dev, qa, at, increment test. One view in Issue tracking tool, which includes Ready to implement Units of Work. The UoWs can be prioritized here. When UoWs are in Work-in-Progress state they can be further refined into sub-UoWs, but they are not visible here. Testing can be planned and executed based on the listed requirements.
  3. SIP level view: Code change aka real issues for Sprint backlog and Product backlog. Another view on Issue tracking tool.

Temp summary. Note! High-level issues with requirements have also Ready, WIP, Done states (related to envs??? dev, qa, at (of PO?), increment test)

  • Requirements are important. They have lifecycle. see my other post
  • Requirements offer base for testing. Use test management system!
  • High-level issues are managed in one view/board when the are Ready for doing
  • high-level issues which are not Ready are managed somewhere but not in issue tracking
  • code level changes are managed in Issue tracking
  • code level changes implement the requirements

So how to go about it? You need:

  • One backlog for “Product management backlog” that includes product roadmap and requirements
    • One board/view for planning and prioritizing releases. For example, you need to schedule delivery deadlines
    • One board/view for planning and refining roadmap. For example, you need to collect enough information so that you can make sure that the dev team understands items in the Product Backlog to the level needed, which maximizes delivered value in long run!
    • There should be always enough Ready features/tasks so that the development team can work without waiting
  • Another one backlog for “Scrum”
    • One board/view for QA process (for issues which are “Done” from the development team)
    • One board/view for the developement team for actual Scrum backlog items (PBIs).
    • Scrum dev team should always have one Sprint worth of Ready issues

The idea is to get control over the product and software development:

TimeOutputs
1-4 WeeksOne Scrum Increment
0-3 MonthsScrum Increments
3-6 MonthsIncrement Releases
6-12 MonthsProduct Releases
0-1 YearsProduct strategy implementation
1-4 YearsProduct strategy plans
5+ YearsToo much uncertainty
Timespans

So if the SIP process is implemented by the Scrum. What implements the PIP process? Well, there is suitable candidate for it so I rolled up my own suggestion:

PIP Process phases

Security testing is an interesting topic nowadays: starting from various static source code analysis tools to other levels of testing. For example, you should integrate it as part of the process. You should use snyk.io for Javascript/npm security, owasp dependency-check tool for Java/jar dependency vulnerability scanning, Owasp Zap / BurpSuite / https://cirt.net/Nikto2 for scanning application security, vuls.io for scanning server hardening, etc. You can automate a lot of testing too with frameworks like Katalon, BrowserStack, or Robot Framework.

Product Management Process

Previously I have written on how to combine Agile software development with company processes, and how product versions can be built using that process. This time I wanted to dig deep into the Product Management process: note that Product Development is more focused on building the product whereas Product Management is more focused on conceiving the product and taking good care of it during its life-cycle! Let’s start by checking out few examples of a modern product management process:

Notice the different phases listed after the semi-colon. Different processes share the same phases but the description might use different words due to different steps. Anyways, the examples pretty much lay out a structure for a modern product management process. Also, one important point is that how this product management relates to Product development i.e. creating the actual software: please head back to the list and search for keywords like “develop” (280group), “deliver” (Zalando), “build it” (Spotify),  and “delivery” (generic)! Modern software product development lean on continuous discovery and delivery.

P.S. You might want to read my post about Product vision too… And check these product management frameworks…