Flow Framework Part 2: The four types of items in a product backlog
I am a Technical Product Owner, working for Croesus, and I’ve always felt that something was wrong in my product backlogs for a long time. After reading the book “Project to Product” several times, and gained some experience with the concept, I can now confirm: there are four types of items in any product backlog. They are mutually exclusive and comprehensively exhaustive (MECE). Mik Kersten, the author of “Project to Product”, makes it clear when explaining the Flow Framework, but I wanted to try it before writing about it. Are there really four types? Why not five or three?
Four types of items flowing the value stream
Features
Everybody knows that type of flow item… I mean, it’s the obvious one! All product managers, or project managers, are asking them most of the time. According to M. Kersten, a feature will “deliver new business value and will be pulled by internal or external customers”. This new value will add new business results and will be visible to the customer.
Defects
When the customer experiences a problem with the product, we call it a defect. It means that there is a quality problem so the fix will deliver the missing quality.
What are the two other types of items that we should find in our product backlog?
For years, I thought only about bugs and features. But, now that I have spent the last year experimenting with the four types of items in my product backlog, and getting demands about security and refactoring, architectural changes, I had to admit that they are not bugs or features. The two other types are Risks and Debts.
Risks
This type of item includes various kinds of security, regulation, and compliance. This work can be pulled by business analysts, chief security officer (CSO), or any tools like Claire or Nessus analyzing security breaches. Any findings will have to be planned, worked, tested, deployed, and maintained. This work will not be visible to the customer if done appropriately. On the contrary, the customer will be notified via the front page news when an important risk item will have been dismissed by the product team. So, the priority of the type of item will have to be fairly high over defects or bugs.
Debts
The last kind of item is my favorite one and I will have many articles coming up to explain how we control it in my teams. It’s technical debt reduction, which, according to M. Kirsten, “describes the need to perform work on the software and infrastructure codebase that, if not done, will result in the reduced ability to modify or maintain that code in the future”. Examples of that will be refactoring, API addition, infrastructure automation, performance improvement. We will do this kind of work to speed up the future delivery of features and bug fixes.
What advantages will I get to manage my product backlog with these four types of items?
The short answer will be “Agility”.
Transparency
The first and obvious advantage is transparency, one of the three pillars of agile. Once you get each type of item his own space, you will be able to see what is going on with your product. It will be very informative for the stakeholders and will lead to technical, and business discussions.
Inspection
If you have better visibility over debts and risks, you will be able to better inspect, by making the right analysis. If the risk and debt items are lost and hidden behind features and bugs, or worst, invisible, it’s not possible to do the right inspection in time.
Adaptation
Better transparency and inspection will lead to a better adaptation. With the right processes in place, you will be able to take better strategies when dealing with features, defects, risks, and debts.
Conclusion
I was pleasantly surprised when experimenting with the last two types of items. Most of today’s tools like Jira, Azure DevOps Boards, Trello, are not offering these four kinds of items by default. It’s very unlikely, but at least, now, I know, and you know too!
Flow Framework Part 1: The Discovery
Aha…. This Flow Framework looks very promising!
I have just discovered the Flow Framework through the book “From project to product” by Mik Kersten. I must say that, even if I’m only halfway through the book, it already blew me away! I am so excited about it that I plan to make it a series of blog posts here on TFOC as I will keep digging.
The Glue
I have been practicing Agile methodology for more than 10 years now and DevOps for 3 years. I am also studying and practicing Lean thinking in my day-to-day work. From the moment I was introduced to Value Streams through “The Phoenix Project”, my journey to understand my own flow of values at work started. It led me to very interesting discoveries until now, but there was something missing.
I was trying to connect all the dots between Lean, Scrum, DevOps, SRE, and even Leadership and Management activities and thinking. How to make our work visible to everyone? How to find bottlenecks in our value streams or even between teams dependent on each other? At Croesus, where I work, we try to manage our technical debt, but not many books talk about it. Why? Is there a way to manage our streams by putting emphasis on business results instead of proxy activity metrics?
This week, I started to read “From project to product”, a book by Mik Kersten. I got so many “aha” moments on the same day that I got very excited. The Flow Framework seems to be the right framework to enable software companies to visualize the items flowing inside all value streams, making them visible. It also provides all the groundwork to capture the right metrics. Another thing that looks very promising is its ability to not interfere with existing frameworks like Agile Framework, DevOps Tools and principles, etc. Instead, it provides the glue to enable them to work together at a company level.
Stay tuned!
I will definitely give it a try in the next year and I planned to report back here my progress since it looks very promising! Stay tuned for the next parts!
DevOps Ignition - Want to know more about it?
DevOps Ignition
“I want to know more about DevOps, where should I start?”
This is a very good question that many people asked me a couple of time until now. So, I decided to write this article to share my list of articles, blogs, tutorials and books that I have read, consulted or watched. DevOps ignition may be easier with the proper resources. Here is a list that helped me to understand what is DevOps, why it matters, and how to make the transformation where I work.
In order to ignite your internal flame for DevOps, you should definitely take a look at the books The Phoenix Project and The Unicorn Project. These novels will surely capture your attention and open your mind towards DevOps.
Then, The DevOps Handbook is a very good reference book to apply the three ways of DevOps mentionned by Gene Kim in The Phoenix Project.
They are also available as audiobooks:
DevOps Transformation Examples
DevOps at Microsoft
In my opinion, one of the best examples of success stories is the DevOps transformation at Microsoft. They started their transformation in 2009 and it last for many years. Today, they are no longer the same company than they were in early 2000s.
Many videos are availables and explain lots of very interesting concepts and they implement them like:
- Moving to Cloud cadence
- Branching Strategy
- Shift Left
- From monolith to cloud service
- Feature Flags
- Safe Deployment Practices
Have a look by yourself: https://www.visualstudio.com/learn/devops-at-microsoft/
State of DevOps Reports
Those reports give lots of information on trend, what makes good and bad performers, how to build quality in, etc. It’s a must if you are responsible of a team or a product.
Puppet also have lots of white papers that can be consumed very quickly and worth giving a try.
Applying DevOps Principles
The next ones are more optionals but if you are going to dive into DevOps, you should definitely look at them. Especially, The Lean Startup that gives really good tips and directions to follow in today’s world where everything goes so fast. The Goal exposes the theory of constraint and will push your reflection on value streams and flows to another level.
Pluralsight DevOps Path
I recommend you to do the DevOps path at Pluralsight if you want to do a DevOps 360 degrees. It gives lot of information about just everything that you must take into account. https://www.pluralsight.com/paths/understanding-devops
IT Revolution DevOps Blog
This blog expose lots of great content to assimilate. Obviously, it belongs to Gene Kim, so no surprise here!
DevOpsDays Montreal 2019 - Presentation available!
Presentation “Agile et DevOps chez Croesus” maintenant disponible
Suite à plusieurs demandes lors du DevOpsDays 2019, je rends disponible la présentation que j’ai fait. Merci à tous les organisateurs de DevOpsDays! Un merci particulier à Carol Trang pour son implication dans le processus. Je suis très content d’avoir fait partie de cette aventure et j’espère renouveler l’expérience l’an prochain!
How to create a multi NET framework NuGet package through TFS 2017.3
Here are the steps to make a regular .NET project become a multi framework NuGet package. I have also included the steps to build it with TFS 2017.3. This article came to life after I have come across a problem that took me some times to debug and finally figure it out. I needed that an existing NuGet package have more than one .NET framework to be available. The solution is so neat that I needed to share it.
Changes to the project file
The initial project file
The project I am working with is a regular C# project. Here is the content:
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="..\packages\xunit.runner.visualstudio.2.3.1\build\net20\xunit.runner.visualstudio.props" Condition="Exists('..\packages\xunit.runner.visualstudio.2.3.1\build\net20\xunit.runner.visualstudio.props')" />
<Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
<ProjectGuid>{D645388E-F937-4310-9D13-F2107612C36C}</ProjectGuid>
<OutputType>Library</OutputType>
<AppDesignerFolder>Properties</AppDesignerFolder>
<RootNamespace>BuildLogParsers.UnitTests</RootNamespace>
<AssemblyName>BuildLogParsers.UnitTests</AssemblyName>
<TargetFrameworkVersion>v4.5.1</TargetFrameworkVersion>
<FileAlignment>512</FileAlignment>
<SccProjectName>SAK</SccProjectName>
<SccLocalPath>SAK</SccLocalPath>
<SccAuxPath>SAK</SccAuxPath>
<SccProvider>SAK</SccProvider>
<NuGetPackageImportStamp>
</NuGetPackageImportStamp>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
<DebugSymbols>true</DebugSymbols>
<DebugType>full</DebugType>
<Optimize>false</Optimize>
<OutputPath>bin\Debug\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<DebugType>pdbonly</DebugType>
<Optimize>true</Optimize>
<OutputPath>bin\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
</PropertyGroup>
<ItemGroup>
<Reference Include="Castle.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc, processorArchitecture=MSIL">
<HintPath>..\packages\Castle.Core.4.0.0\lib\net45\Castle.Core.dll</HintPath>
</Reference>
<Reference Include="Moq, Version=4.7.10.0, Culture=neutral, PublicKeyToken=69f491c39445e920, processorArchitecture=MSIL">
<HintPath>..\packages\Moq.4.7.10\lib\net45\Moq.dll</HintPath>
</Reference>
<Reference Include="Newtonsoft.Json, Version=10.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed, processorArchitecture=MSIL">
<HintPath>..\packages\Newtonsoft.Json.10.0.3\lib\net45\Newtonsoft.Json.dll</HintPath>
</Reference>
<Reference Include="System" />
<Reference Include="System.Core" />
<Reference Include="System.Xml.Linq" />
<Reference Include="System.Data.DataSetExtensions" />
<Reference Include="Microsoft.CSharp" />
<Reference Include="System.Data" />
<Reference Include="System.Net.Http" />
<Reference Include="System.Xml" />
<Reference Include="xunit.abstractions, Version=2.0.0.0, Culture=neutral, PublicKeyToken=8d05b1bb7a6fdb6c, processorArchitecture=MSIL">
<HintPath>..\packages\xunit.abstractions.2.0.0\lib\net35\xunit.abstractions.dll</HintPath>
</Reference>
<Reference Include="xunit.assert, Version=2.1.0.3179, Culture=neutral, PublicKeyToken=8d05b1bb7a6fdb6c, processorArchitecture=MSIL">
<HintPath>..\packages\xunit.assert.2.1.0\lib\dotnet\xunit.assert.dll</HintPath>
</Reference>
<Reference Include="xunit.core, Version=2.1.0.3179, Culture=neutral, PublicKeyToken=8d05b1bb7a6fdb6c, processorArchitecture=MSIL">
<HintPath>..\packages\xunit.extensibility.core.2.1.0\lib\dotnet\xunit.core.dll</HintPath>
</Reference>
<Reference Include="xunit.execution.desktop, Version=2.1.0.3179, Culture=neutral, PublicKeyToken=8d05b1bb7a6fdb6c, processorArchitecture=MSIL">
<HintPath>..\packages\xunit.extensibility.execution.2.1.0\lib\net45\xunit.execution.desktop.dll</HintPath>
</Reference>
</ItemGroup>
<ItemGroup>
<Compile Include="Issues\IssuesTypeManagerTests.cs" />
<Compile Include="Loader\DataTextLoaderTests.cs" />
<Compile Include="Loader\IssuesJsonLoaderTests.cs" />
<Compile Include="Parsers\BuildLogParserTests.cs" />
<Compile Include="Parsers\SubProcesses\AbstractSubProcessLogParserTests.cs" />
<Compile Include="Parsers\SubProcesses\GenericLogParserTests.cs" />
<Compile Include="TestsFoundations\Helpers\AbstractSubProcessLogParserTestsHelper.cs" />
<Compile Include="Properties\AssemblyInfo.cs" />
<Compile Include="Streams\StreamsManagerTests.cs" />
<Compile Include="TestsFoundations\UnitTestsFoundation.cs" />
</ItemGroup>
<ItemGroup>
<None Include="App.config" />
<None Include="packages.config" />
<None Include="Settings.StyleCop" />
</ItemGroup>
<ItemGroup>
<ProjectReference Include="..\BuildLogParsers\BuildLogParsers.csproj">
<Project>{ff436071-73cc-4141-903c-c0b418120f49}</Project>
<Name>BuildLogParsers</Name>
</ProjectReference>
</ItemGroup>
<ItemGroup>
<Service Include="{82A7F48D-3B50-4B1E-B82E-3ADA8210C358}" />
</ItemGroup>
<ItemGroup />
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
<PropertyGroup>
<ErrorText>This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
</PropertyGroup>
</Target>
</Project>
I would like to point you out a couple of concepts in this project file:
- All files to be included in the project are declared. It can become a source of problem when merging branches with big project files.
- All default information is listed for each configuration.
- The old format of NuGet is used (with the package folder).
On the way…
First, let me tell you a couple of ways I have tried and did not work. I tried to set one debug configuration and one release configuration per framework I wanted to build. Something like that:
- Debug-Net451
- Release-Net451
- Debug-Net452
- Release-Net452
- …
The problem is that the NuGet restore command will failed because NuGet does not know how to deal with multiple build configuration like that. Also, the build in TFS was getting complicated to setup with all the build configurations for each platform…
The Solution to Multi Framework NuGet package!
So… the solution is to take advantage of the new format for dot net core!
Unload the project, edit the csproj file and replace the content with the new dot net core project format:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFrameworks>net451;net452</TargetFrameworks>
</PropertyGroup>
</Project>
Note the s in TargetFrameworks tag. This is the way you can declare the number of frameworks you need to build against.
If you reload your project, you will see, Visual Studio will reload all the files correctly. In fact, it takes the reverse approach of including all the files and will add the files you want to exclude in the csproj when you specify them. Better than that, once your project will be reloaded, you can now edit the csproj directly without having to unload/reload the project. Reload your project, and have a look to the new option on the right click on the project: Edit YourProject.csproj.
Missing Packages
It’s possible that if you were using some packages for your project, by replacing the csproj by the code above, you flushed them out. You must now add them back and you can add conditions depending on the framework targeted. For example, in one of the unit tests projects, I added those lines with the conditions attributes:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFrameworks>net451;net452</TargetFrameworks>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Moq" Version="4.8.1" />
<PackageReference Include="xUnit" Version="2.3.1" Condition="'$(TargetFramework)' == 'net452'" />
<!-- xunit 2.2.0 is not compatible with .net 4.5.1.-->
<PackageReference Include="xUnit" Version="2.1.0" Condition="'$(TargetFramework)' == 'net451'" />
<PackageReference Include="xUnit.runner.visualstudio" Version="2.3.1" />
</ItemGroup>
</Project>
As you can see, I have specified a condition for the xunit framework because the version 2.2.0 is not compatible anymore with .Net 4.5.1.
Duplicate information
If you try to build, you will probably run into compile errors specifying duplicate information in the AssemblyInfo.cs. With the new csproj format, the compiler is now generating all those information for us. Copy your information if you have some information customized to your csproj file:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFrameworks>net451;net452</TargetFrameworks>
</PropertyGroup>
<PropertyGroup>
<Version>1.0.0</Version>
<FileVersion>1.0.0</FileVersion>
<Authors>The Futue of Code</Authors>
<Description>Library used for demo purposes.</Description>
<Copyright>Copyright (c) 2018 The Future Of Code</Copyright>
</PropertyGroup>
</Project>
The NuSpec information
When creating a NuGet package, you must usually specify the information inside a nuspec file. This file is now embedded into your new csproj as well (pretty interesting no?). You can enter the information from your nuspec file by specifying a property group just like this (add all the information you need):
<PropertyGroup> <PackageId>TheFutureOfCode.DevOps.LogParser</PackageId> <PackageVersion>1.0.0</PackageVersion> <PackagerequireLicenseAcceptance>false</PackagerequireLicenseAcceptance> <PackageReleaseNotes>This is my release notes.</PackageReleaseNotes> </PropertyGroup>
You should now be able to build your project. If you have any missing references, add them, but there is nothing else special to know. What is pretty cool about this approach when you build your project is that it just restore and build all the platforms needed in the bin/Debug or bin/Release folder.
MSBuild 15 to restore and pack
NuGet.exe does not know how to deal with this format. So, you must use msbuild 15 that comes with VS2017 to handle that. Open a developer command prompt for VS2017 and type:
msbuild YourProject.csproj /t:restore
I suggest you to have a look at this link for more information.
So, yes, we get rid of the nuspec file, and the AssemblyInfo.cs. Pretty cool no?
How to build the multi platform NuGet package into TFS 2017.3
Let see what it looks like to build such a project in TFS 2017.3. Here are the basic steps to make the restoration works properly:
The importants points are:
- MSBuild version 15 (2017) must be selected, otherwise, it won’t work.
- You can ask MSBuild to only restore, this is the important part. You can do the rest of your process the way you want.
- I enable the regular build, there is no need to ask MSBuild to do it, but I could have done it via
msbuild /t:build. - I am running my tests using the regular way with the VSTests task. It will run all tests for each framework.
Finally the pack command must use the one from msbuild 15 also (msbuild /t:pack):
Run your build and you should get a nice package with all the frameworks binaries you have specified.
References
Some of the good references I found that help me to figure out how to put all of that together:
- https://www.bartwolff.com/Blog/2017/03/20/targeting-multiple-net-platforms-in-a-single-nuget-package-w
- https://blog.nuget.org/20170316/NuGet-now-fully-integrated-into-MSBuild.html
- https://docs.microsoft.com/en-us/nuget/consume-packages/package-restore
- https://docs.microsoft.com/en-us/nuget/reference/msbuild-targets
Conférence DevOps @ ÉTS
Hier était un jour spécial. J’ai eu la chance d’aller parler de ma passion pour DevOps aux étudiants de l’ÉTS. J’ai rencontré des étudiants brillants qui ont démontré beaucoup d’intérêt pour ce sujet qui les touchera à court ou long terme dans leur carrière. Croyez-moi que si j’ai l’occasion de partager à nouveau ma passion avec d’autres étudiants ou même des collègues professionnels, je vais le faire! On apprend tellement dans le processus, et bien que ce soit la deuxième conférence que je donne dans le cours Système d’exploitation LOG710, l’expérience n’a été que plus enrichissante.
Dans cette conférence, j’ai abordé l’univers DevOps en parlant de ce que c’est DevOps, en parlant du Release Pipeline, de l’intégration continue, du déploiement continue, de la dimension Ops, de l’univers agile, des tests, des outils utilisés aujourd’hui et de mes réflexions personnels. J’ai également pu partager mon travail en tant que Spécialiste en Architecture DevOps chez Croesus Finansoft. J’ai terminé la conférence avec une démo dans laquelle je monte un release pipeline en utilisant Microsoft Team Services.
Bref, un gros merci à Maxime Turenne pour l’opportunité en or et je te souhaite tout le succès que tu mérites! Bonne chance à tous les étudiants que j’ai rencontré et j’espère que les 3h que nous avons passé ensemble vous seront utile!
