This blog is written by Marcus Catt, a principle consultant for Infuse with over 40 years worldwide experience working within the I.T sector. 

Some of these thoughts and observations are mine and some are stolen....mostly (but not exclusively) from the DEVOPS Handbook. This is a gross simplification (of course) but I bet if you are "doing agile" and you follow these points you won’t go too far wrong.

Small note. This is not a justification of AGILE as a model......that’s a different topic.

Business Perspective (Product, Marketing, Line of Business)

1. Do try to think of this as something you are very much part of and maybe leading. It is not something Technology are doing to you; it must be a fully engaged partnership

2. Do try to avoid approaching this topic from a purely project perspective – “projects” are a totally arbitrary construct that do not always properly fit with an agile incremental delivery, rapid feedback approach. Ask yourself at the beginning what the dream is and also what you can live with in the meantime.

3. Arrange “things” you want by Value.

4. REVENUE GAIN - SAVINGS - THREAT PREVENTION - REPUTATION LEGALITY are examples. Do put a (pseudo logarithmic scaled) value not just BIG or SMALL. This is order of magnitude stuff.

5. Sub order the resultant list based on complexity magnitude (again, nonlinear). The objective is to get the best value, least effort work ordered at the top of the list.

6. Do not allow Technology to do any of the following:

· Commit to anything that takes more than 6 weeks elapsed to deliver

· Stop work on stuff that is half done - that is a total waste - a write off!

· over complicate it for solutions you dont need yet - You absolutely cannot predict the future beyond the next delivery

7. Do consider how WELL you want stuff to work - and make sure you advise the Tech team. If they don’t know then its your fault.

8. If it doesn’t fit - break it down, ask for something smaller or simpler to implement. Yes, you can always make it simpler. You will be amazed by what you do not need.

9. Try to remember the best possible outcome you can obtain is that you get what you asked for - this may not be what you wanted so do take care.

Technology Perspective (the guys who need to get it built)

1. 3 Sprints (or 6 weeks) to value - your max commit before you check it by going live and getting the ultimate feedback

2. Never ever commit when you have external dependencies - postpone until they are cleared - you will always fail if you don’t obey this rule

3. Get your data ready and own it. That is your test data and your production data and your measuring data.

4. Automate absolutely everything that is possible to automate. If you cant - challenge the approach/design - or the need

5. If it is hard to test, then it is hard to diagnose and maintain. So challenge this and then challenge it again.

6. The ONLY estimate that has value is the estimate of the person doing the job under the circumstances they face on the day - everything else is just hot air

7. Identify, Exploit and subordinate any constraint to delivery. In other words, do not let 5 developers pile up work on the one testers desk on the last day of the sprint and then say it would have been delivered if the tester had worked harder.

8. Commit to Master (or whatever is your main line in your code repo) often - do not get drawn into very complex and clever branched based release strategies - its modern-day snake oil

9. Shift left with your testing and fix your broken tests always. Use escaped defects to help drive this strategy

10. Try not to repeat the code or the mistake. Anyone can make a mistake. But repetition? That Is incompetence

11. Never try to do 2 things at the same time with a single tool or test environment. It is not a saving, it is a complication. And complicated doesn’t work reliably!

The philosophical stuff that I mostly stole from smarter people

Some patterns of thought and behaviour that just make sense.

The Three Ways

· To create a flow of work: Make a habit of finishing and practice the bits that are hard and you do not like, so you get good at them

· To shorten and amplify feedback loops: If it breaks early and often and you shout loud about it, that’s good. It will get fixed

· To create a culture of improvement: Enjoy the process of making it better. Don’t focus specifically on delivering “this” now. Focus instead on improving each part of the delivery process until regular on time delivery becomes just something that is ordinary

The Four kinds of Work

· Business initiatives: Stuff the business thinks it wants

· Internal initiatives: Stuff tech knows they need to do to maintain and improve

· Changes: Get over it, it’s just reality

· Unplanned work: The Devil lurks here. This is the shadow world. Where the real stuff happens. We want this to tend towards zero.

The Five Ideals

· Locality and Simplicity. Decide locally, Keep it simple.

· Focus, Flow and Joy. Stay focussed, concentrate on improving the flow and enjoy it.

· Improvement of daily work. Improve is better and faster. Pick both.

· Psychological safety. Must allow freedom to express without repercussion

· Customer Focus. If we don’t focus on what the customer needs, then we don’t have a business

Improvements?

· Simply dont count if they are not applied at the constraint! What is a constraint? Anything that holds up the flow of work.

· If you are 3 organisational layers away from the work...but are making the decision....you are part of the problem

· Stop starting. Start finishing. Avoid WIP. It’s a killer.