Team Individualism

In our organisation we have multiple competing priorities – before we reach for our agile project management practices, we triage our prospective work.  In this process we need to decide, collectively, what is the most important piece of work and articulate in a clear plan how we are going to execute. Once we make a commitment, we are all focused, as a development team, on delivery. This quasi-agile practice can create a chasm between the plan and execution, where value can get lost. Value, I suggest, can get lost over time . Well, that’s my observation at least and a good product owner tries to maintain value by delivering the right outcomes. During a project you can maintain the initial idea, the product vision, a great set of stories and a well-defined backlog – but still drift away from the north star, value.  Imagine you have a product vision to build a single report for the business, you have a set of stories to articulate each part of the report and a set of technical items to

 In any conversation you require a skilled communicator who can apply the  most appropriate methods in a situation. John Adair's communication Star model is a practical framework when planning for any interaction It’s a visual model that’s  show interconnectedness of 6 aspects of communication. The sender, content, methods, receiver and situation being 5 points in the star and the AIM or desired results in the middle.  The star model is intended as a way to keep you thinking during a dialogue. It asks of any message, what you want to accomplish.  Each point in star  is a way to help us visualise the  strength of any relationship. This is most obvious between communication and communicator The star model fits the needs for effective professional communications as it describes how to plan for and potentially take remedial actions. We can ask as the sender, if the situation is appropriate for our message. The proverbial elevator pitch limits our content and focuses our aim. Adair uses

For others to make sense of our  written communication in a professional context we need to review and make revisions to our message so that  its clear, impactful and invokes the desired response in the reader.  You may find this self-review process difficult and time consuming. we often don’t hear our words as heard by our reader. This is a result of trained neural pathways in our brain that help us focus and avoid the constant bombardment of distracting stimuli. They help us to recollect make allowances for our mistakes -- they blind us of opportunities for improvement.  Through the review process of deliberate disconnect, we deliberately allow ourselves to be distracted and disconnect from the matter at hand.  This electrical short circuit for our brain can aid in reengaging with our words and provide new insights and potential fixes. When a negative emotion surfaces, our tendency is to go over the problem repeatedly and ruminate on our worries and fears.  You've no doubt been 

...in part reflection, part response  to my good friend Chris, on 15 years at Microsoft  I've always believed in the power of software. Yeah, that might seem overly romanticized, nerdy, or just plain silly. But there it is. It's something that drew me in as a kid and it’s still something I think can, in many ways, create "magic". Type a few words here and copy a few things there and with a few short, disjointed statements you can run something new. Something fresh. Something you created out of thin air. Repeatable and dependable. Plus, you can use fancy mathematically derived terms such as idempotence and lamdas to make yourself look smarter. Neat! I believed in Microsoft, still do, in its underlying push to make people more productive. I'd seen it grow throughout my software journey, my studies and work - change seemed palpable and real. Some might even attribute Microsoft as proponent, neigh bastion, of the  democratization of technology ,  they literally made

When you have multiple developers creating similar applications there are inevitably styles that are introduced. Assuming you are a team of developers responsible for a suite of Azure Logic Apps you might be wanting to standardise on some areas.  The first decision you have probably made is  in choosing Logic Apps as a platform - server-less and limited coding environment can be attractive and the temptation is to go wild when it comes to style.   Slight diversion here: I'm going to assume too that you understand  the difference between power automate (flow) and Azure Logic Apps. If you don't you are probably wondering if they do essentially the same thing? And if not am I using the right one?  This handy comparison (in the Azure Functions documentation of all places) may help. Whilst most of my notes refer to Azure Logic Apps you could apply the principles to both. Standardisation has done wonders for all sorts of scenarios (e.g. containers, real or virtual ) but can come wit

In our continued journey with Logic Apps we wanted to create some unit tests.Since all of our Azure Logic Apps are accessed from Azure API management with an HTTP request, we could simply have our unit tests call the endpoint directly. Instead of calling individual Azure Logic Apps, their SDK or some other more granular mechanism).  First you will need to find your HTTP endpoint Open the Azure portal Goto API management Service  Select APIs from left menu Select API you want from right blade Select API version  Select Test tab selection from top Select the Operaion you need from the left menu Make note of the Request URL (example HTTP request is provided) Since our customer preference was Typescript we elected to use Axios which enables the use to easily make Promise http requests. In this example we dont have user authentication, so relatively straightforward calls. Below is an example of a test helper that creates an event based on some input event data and creates an HTTP post in