Posts

• 

  Picking the Perfect Process (model)

  Which process model should you pick for your brand new Azure DevOps project? You can change later but its easier to get it right at the start. Some processes might even cause you issues.

  Introduction

  There are four process models supplied currently: Basic, Agile, Scrum, and CMMI. I’m not going to regurgitate the information already available online. Go and read for yourself the main distinctions among the default processes. Some differences might not be that obvious but will become apparent later.

  History

  Azure DevOps has technically been around for quite some time. Before its current incarnation it used to be an on-premise version called Team Foundation Server (TFS). Before that I belive it existed as a Microsoft internal tool called Source Depot, but that might just have been the source control tool. TFS had two process templates - Agile and CMMI. Both of these were designed specifically for the Microsoft Solutions Framework process used by Microsoft Consulting Services, and others. It was part of my job at Microsoft to go and talk to customers about it as you can see from this very dated PowerPoint. Gotta love that gold gradient shadow text.

  

  The two flavours of this process were MSF for Agile Software Development and MSF For CMMI® Process Improvement.

  

  So, the current Agile and CMMI process models have been around for a while. Both of them pre-date the first official Scrum guide release in 2010. They have been tweaked but not really modified to stay current. I can’t imagine any team in Microsoft follows these processes any more.

  Making Your Selection

  The history above is useful context but doesn’t say why you shouldn’t use these models apart from the fact they are old.

  The CMMI process is really heavy with extra work item types and states used to manage a formal change management process. Work items have lots more fields that need to be filled out and steps from start to finish. It doesn’t scream agile.

  The Agile process, on the other hand, is a bit sly. It uses the right terms like User Story, Acceptance Criteria, and Story Points but a couple of things don’t really marry with modern agile.

  Firstly, the state transitions New > Active > Resolved > Closed. There isn’t a state that really represents the backlog. You could use New but then you are mixing up work with the half baked ideas that may not make it onto the backlog. Also, the Resolved state implies there must be some form of verification before closure and that they must be done in order. Cross functional agile teams work together on committed work items until they are done. Sequencing work via a Resolved step means you are queuing.

  Some fields can be unhelpful too specifically the Completed Work field which I wrote about a long time ago: https://snape.me/2014/09/06/tracking-hours-worked-on-a-scrum-task-is-counterproductive/. Interestingly, I’ve just checked my current Azure DevOps and this field has been removed from the Agile process so it is being improved.

  To recap the above in a nice easy summary.

  Do not use the Agile or CMMI process models.

  The two remaining models are Basic and Scrum. I love them both but they have very different purposes.

  The Basic process model it reduced to a bare minimum. All work items are simply Issues with a higher level Epic. To differentiate different types of work you use tagging in the same way GitHub uses labels on its issues. Issue states are To Do > Doing > Done without extra process steps too.

  The Scrum process model really looks like modern scrum with Approved > Committed > Done states to map onto product backlog, sprint backlog and done respectively. Additional approval states are removed to encourage in-sprint completion. Even the terminology of Done vs Closed maps better onto agile. Feature work items aren’t defined in scrum but I find them useful as a unit of release deliverable vs product backlog item (PBI) as a unit of sprint deliverable (more on this in a future post).

  My rule of thumb for choosing between these two process models is:

  It the process is for delivering software then pick Scrum otherwise pick Basic.

  I use the Basic process model all the time for ad-hoc boards and task tracking for example: tracking architecture review board work, personal to do lists, support ticketing, governance structures etc. It is particularly useful for use with business users and other non-technical customers because most folks will understand the basics of a to do list whereas trying to describe the nuances between a task, a bug and a product backlog item can be tricky.

  Dealing With Process Jealousy

  OK, so you picked Basic or Scrum but you quite like some of the things in other process models? That isn’t too much of an issue since you can copy the definition of an interesting work item from the model it lives in to your model. There is an important point though:

  Always create an inherited process before selecting one for your projects.

  You cannot change the standard processes so save yourself a minor inconvenience in the future by creating a model you can modify when you need to.

  Examples of work item types I often add are:

  • Question - used to document known unknowns typically associated with architecture or planning activities.
  • Decision - for tracking decisions that need making and the outcome of those decisions.
  • Feedback - used to formally track feedback from show and tell sessions. Often I prefer to just add new children (tasks or PBIs) to the existing work item than needs more effort.

  Finally

  Its a trivial step at the point you create a project in Azure DevOps. Picking the right process model can help point you in the right direction. I’m interested in how you chose the right process or what work item types would you add? Click one of the buttons below and tell me.

  Photo by Kaleidico on Unsplash

  This entry was posted in agile  and tagged #agile #Azure DevOps #opinion  on Mar 21, 2024 .
  Discuss this on Twitter or LinkedIn
• 

  Opinionated Agile. Am I doing it right?

  Teaser article for a series on how to do agile without starting from scratch.

  One of the core tenets of agile is continuous improvement and finding out what works for you. This comes from the principle that:

  At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

  For this reason I’m hesitant to provide a ready made process to folks. Saying “here, do all this and you will be agile” feels wrong. I’ve been the subject of one of these consulting led lean transformations so I know what its like to have a bunch of outside folks tell you how to operate.

  On the flip side I’ve been involved with agile projects since the start in 2001 and before that one of the precursors ‘rapid application development’ so I would say I have a lot of experience to share. I’ve worked in high performing teams and seen cases where agile has been misinterpreted and failing. I would like to share these experiences and resulting advice.

  Over the years I’ve developed an system of agile that works for me. My interpretations go beyond the scrum guide or agile principles. It continues to evolve as expected. Some of the articles on this site are going to describe this system, opinions on commonly accepted practices such as planning poker, and other suggestions.

  Whilst these work for me they may not work for you. There is no reason not to continue with your existing improvement process. If you read along you will find thoughts on Azure DevOps process models, team structure, giving value to epics, specific steps to running scrum ceremonies, tips like card styling and more.

  Feel free to borrow the ideas and make them your own.

  Photo by Steve Johnson on Unsplash

  This entry was posted in agile  and tagged #agile #opinion  on Mar 9, 2024 .
  Discuss this on Twitter or LinkedIn
• 

  The hidden effects of queuing on cycle time

  Queues are used to load balance work between teams but its easy to overlook a decrease in efficiency they bring.

  Its fairly common knowledge that batching work causes inefficiencies. This is why a core technique for lean software delivery is map your value stream and then limit the amount of work in progress. I wanted to see just how much efficiency can be gained by removing queues so started to map this with an idea example.

  Traditional Batched delivery

  Imagine we have a fairly standard software delivery pipeline: specify, build, verify, and release. I’m being purposefully vague here as the actual work doesn’t matter. In a traditional waterfall style delivery you would generally work on the specify part first to create a big requirements document; chuck it over the wall to the next team to build; once they have done that the built code gets chucked at the next team to verify; and finally the finished product is released to live.

  It not that obvious but the requirements document, the built code and the release package are queues. They contain a batch of work for the next stage.

  Lets visualize this by creating an ideal delivery pipeline. Imagine we have 10 work items; all exactly the same size; so they all take exactly one day to complete at every stage. (I know this isn’t the case in reality but that would only makes things worse.) The delivery plan as work flows through the process is shown below:

  Day	Backlog	Specify		Build		Verify		Release	Done
  	Waiting	Doing	Done	Doing	Done	Doing	Done	Doing	Done
  1	10
  2	9	1
  3	8	1	1
  4	7	1	2
  5	6	1	3
  6	5	1	4
  7	4	1	5
  8	3	1	6
  9	2	1	7
  10	1	1	8
  11		1	9
  12			10
  13			9	1
  14			8	1	1
  15			7	1	2
  16			6	1	3
  17			5	1	4
  18			4	1	5
  19			3	1	6
  20			2	1	7
  21			1	1	8
  22				1	9
  23					10
  24					9	1
  25					8	1	1
  26					7	1	2
  27					6	1	3
  28					5	1	4
  29					4	1	5
  30					3	1	6
  31					2	1	7
  32					1	1	8
  33						1	9
  34							10
  35								10
  36									10
  Total		10	100	10	100	10	55	1

  Each step in the above process has an active ‘Doing’ column and a waiting ‘Done’ queue. Since the output queue for one stage is the input queue for the next I leave the work items in the done queue until they can actively be worked on. This helps calculate the active time and waiting time metric for each process.

  Since the release stage doesn’t involve processing items at the individual level you can see the whole package is released in one go.

  If we add up the values in the columns and work out the active and waiting times and also calculate the average cycle time for this configuration we have a maximum work in progress of 10 and timings:

  	Days
  Cycle Time	29.5
  Active Time	31
  Waiting Time	255
  Total Time	286
  Calendar Time	36

  So what if we don’t batch the work into a document?

  Limiting WIP by Sequencing

  This time the only thing we will change is to pass work to the next queue as soon as we have completed it. Everything else stays the same.

  Day	Backlog	Specify		Build		Verify		Release	Done
  	Waiting	Doing	Done	Doing	Done	Doing	Done	Doing	Done
  1	10
  2	9	1
  3	8	1	1
  4	7	1	1	1
  5	6	1	1	1	1
  6	5	1	1	1	1	1
  7	4	1	1	1	1	1	1
  8	3	1	1	1	1	1	2
  9	2	1	1	1	1	1	3
  10	1	1	1	1	1	1	4
  11		1	1	1	1	1	5
  12			1	1	1	1	6
  13				1	1	1	7
  14					1	1	8
  15						1	9
  16							10
  17								10
  18									10
  Total		10	10	10	10	10	55	1

  Immediately we can see the whole thing is far shorter. Calculating the metrics for a WIP of 1 we have:

  	Days
  Cycle Time	11.5
  Active Time	31
  Waiting Time	75
  Total Time	106
  Calendar Time	18

  Note the active time is still 31 - its the same amount of effort as before but the whole thing is done in half the time because we removed 100 days of waiting time! Consequently the average cycle time has dropped by over half too. Remember nothing else changed apart from removing the batch.

  I could stop here but this is a good point to look at further optimization.

  Remove the Queues

  The next simplest optimization is to remove the queues between stages. This is harder in the real world due to uneven work size and arrival rate but we can look at the theoretical flow.

  Day	Backlog	Specify	Build	Verify	Release	Release	Done
  	Waiting	Doing	Doing	Doing	Waiting	Done	Done
  1	10
  2	9	1
  3	8	1	1
  4	7	1	1	1
  5	6	1	1	1	1
  6	5	1	1	1	2
  7	4	1	1	1	3
  8	3	1	1	1	4
  9	2	1	1	1	5
  10	1	1	1	1	6
  11		1	1	1	7
  12			1	1	8
  13				1	9
  14					10
  15						10
  16							10
  Total		10	10	10	55	1

  The stats are better still - active time is still 31 days but there is only waiting at the end of the process because the release time still need to deliver a bunch of work into live in one go. Cycle time is only 10 days.

  	Days
  Cycle Time	10
  Active Time	31
  Waiting Time	55
  Total Time	86
  Calendar Time	16

  As this point the only optimization left is to ask if the release team can increase their deployment frequency. It could be possible since items are queuing at release.

  Increase Release frequency

  Whilst we could release every day like the very best DevOps practitioners lets assume there is a limit in the release process which means every other day is the best possible.

  Day	Backlog	Specify	Build	Verify	Release	Release	Done
  	Waiting	Doing	Doing	Doing	Waiting	Doing	Done
  1	10
  2	9	1
  3	8	1	1
  4	7	1	1	1
  5	6	1	1	1	1
  6	5	1	1	1	2
  7	4	1	1	1	1	2
  8	3	1	1	1	2		2
  9	2	1	1	1	1	2
  10	1	1	1	1	2		4
  11		1	1	1	1	2
  12			1	1	2		6
  13				1	1	2
  14					2		8
  15						2
  16							10
  Total		10	10	10	15	5

  The stats for this configuration are interesting - for the first time the active time has gone up because we are asking the release team to do 4 more releases. Similarly, the calendar time remains the same because we are still limited by the time it takes to get the last work items released but there is far less waiting and the overall cycle time has dropped to just 5.5 days.

  	Days
  Cycle Time	5.5
  Active Time	35
  Waiting Time	15
  Total Time	50
  Calendar Time	16

  Summary

  This simple exercise demonstrates how hidden waiting time delays deliveries and smaller batch sizes can rectify that. In reality you will need some queuing between stages to balance out demand in this configuration. Look out for hidden queues:

  • Documents handed from one team to another - the entire document is a batch.
  • Pipelined iterations in scrum teams - where the requirements are written in the sprint before dev and the testing in the sprint after; the iteration backlog becomes the batch.
  • Done states between Doing states
  • Approval steps

  If you practice Scrum then aim to complete work in a sprint (specify, develop, and verify) or you are leaving waiting time on the table.

  Photo by David Clode on Unsplash

  This entry was posted in agile  and tagged #metrics #lean #devops  on Mar 2, 2024 .
  Discuss this on Twitter or LinkedIn
• 

  ExcludeFromCodeCoverage considered harmful

  Metrics are only useful if they help you improve. Code coverage KPIs are most often circumvented. Liberal use of the ExcludeFromCodeCoverage attribute is to be avoided.

  Abuse of the ExcludeFromCodeCoverage attribute

  I once worked on project that had a mandatory code coverage target. If your commit didn’t maintain the overall coverage ratio of 75% then it was rejected. The reasoning came from good intentions; a high code coverage is good therefore we will create the mandate that is must be high. It had some unfortunate side effects though. The first unintended consequence is that developers only wrote enough tests to keep the value above the target instead of considering how they needed to test their code. The second consequence was the proliferation of [ExcludeFromCodeCoverage] attributes adoring all sorts of classes.

  The attribute was originally designed for generated code but more recently I’ve seen it be applied where the code that is hard to test or too simple to test. Ultimately this hides code from testing metrics. Your code coverage metric is no longer accurate nor useful.

  Yeah, we are at 85% code coverage ignoring the code we excluded because it was hard to test.

  My immediate response to this is “How come it isn’t 100% then?”

  I would much rather have a lower, but accurate, code coverage metric so I consider the use of this attribute harmful on any code that isn’t generated.

  I wish code analysis tools like SonarCube or the Roslyn analyzers treated this attribute like SuppressMessageAttribute - the Justification property should be filled out when applied. Better still, just fix the issue and avoid the need to use either of them.

  Why should I test properties?

  The consensus on Should you Unit Test simple properties? seems pretty much for testing and you can use the examples here to test yours. I prefer property based testing though because it can find edge cases you didn’t think of. There is a great intro at Property-Based Testing with C# using FsCheck. Your code will effectively look like:

  [Property]
  public Property Set_Then_Get_Returns_Same(string exampleValue)
  {
      var target = new ClassYouWantToTest();
      target.PropertyToTest = exampleValue;
      return (target.PropertyToTest == exampleValue).ToProperty();
  }
  

  FsCheck will generate a bunch of random values to try this test with so these 4 lines of code are resulting in hundreds of unique tests for this property including, for this example: blank string, null value, very short, very long, non-printing, accent characters, etc.

  Why should I test … something else?

  I will come back and add more examples as I encounter them.

  Summary

  • Code coverage metrics are only useful if they help improve the software quality.
  • Mandatory targets can lead to harmful practices such as excluding code from testing or writing superficial tests.
  • ExcludeFromCodeCoverage attributes should be treated in the same way as SuppressMessage - they hide warnings that should really be fixed.

  Photo by Luca Bravo on Unsplash

  This entry was posted in code  and tagged #metrics #testing #csharp  on Feb 17, 2024 .
  Discuss this on Twitter or LinkedIn
• 

  I have a confession to make

  If you already know how to code in one language then using GitHub CoPilot Chat can be super helpful as a virtual colleague when you are working in new or unfamiliar territory.

  I have a little confession to make, this blog site hasn’t entirely been written by me. I mean I did a lot of the typing but I’ve had a little help from Github CoPilot.

  By trade I’m more on the backend side of things with C#, APIs and databases. I understand Typescript, HTML and CSS but its not natural for me to write. In the office I would find someone with complimentary skills to help out but this kind of personal project doesn’t have that luxury.

  GitHub CoPilot normally sits monitoring your code as you type offering completion suggestions which is do find a little annoying since they tend to pop up just as you are typing and then disappear. Maybe one day I’ll get use to it in the same way I have intellisense. Until then I far prefer the newer CoPilot Chat - its a tool window that sits next to your code and you chat to it like you would IM a colleague. The clever part is it can reference the code you are looking at.

  Initially I just created an empty folder and run git init to initialize a blank repository. Lets kick off with a starter to get things going.

  

  This doesn’t look right; the Astro Docs say its far simpler to call npm create astro@latest instead. They may be equivalent but for now I’m going to trust the documentation. In fact I got pretty far with the docs and their Build a Blog Tutorial. Whilst I was doing this I pretty much forgot about CoPilot Chat since the panel isn’t always visible. I did get stuck later on though - trying to complete the archive list on the right I couldn’t work out how to sort based on year and month. I figured it would be an idiomatic thing in JavaScript so asked:

  

  Notice how the code I was looking at has been used as a reference. Here is another example when I was building the monthly archive:

  

  I really like how the code comes with an explanation. This is teaching me as I work. The next challenge was to convert a month ordinal into a name for display.

  

  Now this is frustrating. It seems that since I get my CoPilot license through my work at Avanade, they have flipped a switch to ensure I don’t copy any public code and open them up to legal issues. I can see the rationale but I’m just trying to learn here. I did wonder if the typo in the question had reduced the set of results coming back and that’s why it thought I might be copying.

  Correcting the typo did work.

  

  This tool is super helpful when things aren’t working too. For example, first time I viewed the archive list there were duplicates in the month names. Psychic debugging tells me that there is probably a duplicate for every individual post in that month because the Set class wasn’t working as expected so I asked why.

  

  Ah, in JavaScript, Dates are objects not values and compared by reference.

  Similarly I had a warning about a possible null value. In C# I would use a null coalescing operator ?? with a default value. I want to know the JavaScript equivalent and could have asked but thought it best to just ask for the outcome I wanted.

  

  For the last example I have, I had used CoPilot to help me build a simple search form that would submit the query by opening a new window on Bing with the search as a query parameter. I also appended site:snape.me to restrict the results back to this blog. Hard coded would have worked but I knew I already had the site name in the config and it would be better if loaded from there.

  

  This is really useful because this isn’t just about writing JavaScript, it tells me how to use the libraries I have included in the project. Alas it doesn’t work though but not for long:

  

  I used Co-Pilot to fix a lot of additional issues along the way but mostly boring TypeScript warnings so won’t inflict those on you.

  So would I recommend this approach?

  Absolutely, if you are a beginner or someone with skills in a different software area it can save a whole pile of time iterating whilst you find a solution. It will save you time looking up stuff on the web but just be aware that it might not always give you the best solution. It’s a tool not a replacement but a lot less annoying than tapping your coworkers on the shoulder to ask dumb questions. Don’t leave your brain at home though.

  This entry was posted in code  and tagged #astro #javascript #typescript #github-copilot #copilot-chat #gen-ai  on Feb 14, 2024 .
  Discuss this on Twitter or LinkedIn