• Store
  • Galleries
    • Travel
    • Landscape
    • Street
  • About

Dan Everard.

  • Street Snaps – July 2023

    July 6th, 2023

    Continuing my month of street photog inspiration, I’ve become a little obsessed with Daido Moriyama and his utterly compelling body of work, with its very consistent low fidelity aesthetic and dynamic composition.

    The following are a selection of photos from recent travels to Greece, specifically Athens, inspired by Moriyama’s work.

  • Street photographers inspiring me in June 2023

    June 24th, 2023

    I’ve been inspired to begin sharing my street photography again this month, in particular due to two “walkie talkie” videos produced and hosted by Paulie B, a New York based street photographer.

    The first, and perhaps more conventional “street photographer” is Matt Weber, whose work I was previously aware of but hadn’t really explored. What inspired me about Matt, beyond the quality of his body of work, was the consistency he has demonstrated over such a long period of time. He has played the long game, adopting a stoic attitude to the probability of success on any given day, and this has yielded some phenomenal results.

    The dust sleeve from Matt Weber’s book “The Urban Prisoner”

    The second, and most inspiring (for me), of the photographers recently profiled by Paulie B is Daniel Emuna. The quality of his given name aside, Daniel’s work speaks for itself. He’s heavily focused on portraits, often of a group, and his body of work tells you almost eveything you need to know about his approach to photography.

    Daniel comes across as deeply humanistic and community oriented. His “walkie talkie” episode reveals a confident, social approach to compassionate documentary photography, with a focus on consent and interaction – a stark contrast to the more candid approach adopted by many street photographers.

    Whilst I do love this approach, the video and a review of some of Daniel’s work did get me reflecting on what is lost in the interaction with one’s subjects. Daniel’s work is authentic and his photography conveys a very strong sense of the characters and relationships at play between his subjects, but there is a tendency towards posed street portraiture which lacks the spontaneity and range of interactions which are often the most compelling aspect of street photography for me. The compositions are also very consistent, which is no bad thing, but I miss the happy accidents of composition which can come from rushing to capture the frame in an instant.

    Reflections on subject interaction aside, Daniel’s sincerity and awareness were utterly inspiring. In one segment of the video, he talked to the challenge of walking the fine line between documenting and appropriating. His perspective on this was so on point that it ended up feeling obvious – perhaps we simply share similar views on this as well as a first name.

    A final point is how niether photographer were talking about kit. Nor were they shooting with an Leica… Most of my street photography is done with an Olympus, and so I was pleased to see Matt with something very similar around his neck. I’ve wondered for years why micro four-thirds cameras are not more popular with street photographers. They are compact, light and generally very ergonomic. They are discreet. They focus quickly and accurately. The small sensor means greater depth of field at larger apertures – great for increasing hit rate with zone focusing. And on the subject of zone focusing, Olympus lenses like the 17mm f1.8 have a clutch mechanism which make it so easy to set and maintain a focus distance at a glance. Matt Weber knows…

  • Evening Photo Walk

    December 12th, 2020

    I was inspired to get out and take some photos in the crisp evening air of Copenhagen in December. Just days away from the winter solstice, it is dark by 3.30pm, and by 10pm when I took to the streets, it is pitch black. Small groups of locals gathered on benches and corners holding tins of beer, the bars closed as COVID cases shoot up across Denmark. The blanket of grey cloud which has covered the city for the past week reflected the lights of the city creating a ghostly halo across the sky, and Christmas lights sparkled from balconies and windows.

    Photograph of a mid-century modern property at night.
  • The “Shift Left” Approach: A Heuristic Breadth First Search Analogy

    December 2nd, 2020

    In the realm of technology and software development, the phrase “shift left” has gained significant traction. At its core, the “shift left” approach emphasizes the importance of addressing issues and tasks earlier in the development process. This proactive strategy can lead to more efficient, effective, and successful technology implementation projects. Let’s delve deeper into this concept and understand its parallels with the heuristic breadth-first search.

    “Shift Left”?

    “Shift left” is a philosophy that encourages developers and teams to tackle potential challenges and issues at the earliest stages of a project. Instead of waiting for problems to arise during the testing or deployment phases, the idea is to anticipate and address them during the planning and development stages. This can lead to fewer surprises, reduced costs, and a smoother implementation process.

    Analysing the Existing Codebase and Desired Outcomes

    Before diving into a new project or adding features to an existing one, it’s crucial to analyze the current codebase. This involves understanding its strengths, weaknesses, and potential areas of improvement. By doing so, teams can identify existing technical debt and areas that might become bottlenecks or pain points in the future.

    Once the current landscape is clear, the next step is to define the desired outcomes. What is the end goal? What business value is the project aiming to deliver? By having a clear vision, teams can align their efforts and ensure that every step taken is in the right direction.

    Defining Slices of Work

    After understanding the starting point and the destination, the journey can be broken down into manageable slices of work. Each slice should:

    Deliver Business Value: Every slice should have a tangible benefit, whether it’s a new feature, an optimization, or a bug fix.

    Incrementally Increase Solution Maturity: As each slice is completed, the overall solution should evolve and mature, getting closer to the desired outcome.

    Reduce Technical Debt: With each slice, any existing technical debt should be addressed, ensuring that the codebase remains clean, efficient, and maintainable.

    The Heuristic Breadth First Search Analogy

    The process described above can be likened to a heuristic breadth-first search (BFS). In BFS, we explore all the neighbouring nodes at the present depth before moving on to nodes at the next level of depth. Similarly, in the “shift left” approach, instead of diving deep into one aspect of the project, teams tackle a broad range of tasks that deliver immediate value. This ensures that the most pressing issues and valuable features are addressed first, providing quick wins and immediate benefits to the business.

    The heuristic aspect comes into play when we prioritize these slices of work based on their potential impact and value. Just as heuristics guide search algorithms to find the most promising paths, our understanding of the business needs and technical challenges guides us in choosing which slices to tackle first.

    Conclusion

    The “shift left” approach, when combined with the principles of analysing the existing landscape, defining clear outcomes, and breaking the journey into valuable slices, can transform the way projects are executed. By drawing inspiration from heuristic breadth-first search, teams can ensure that they are always moving in the right direction, delivering value at every step, and building solutions that increase the overall maturity of the codebase.

  • Epics: the raw materials for scaled agile

    September 22nd, 2020

    The various scaled agile frameworks make use of some common building blocks which many practitioners will be familiar with. Stories are often the most familiar, as they are the raw material of the SCRUM and Kanban practices which have been applied at the team/squad level for many years, particularly in technical teams. However, in the process of scaling these practices a need for larger aggregations of work was needed, and in response to this need, emerged epics.

    Whilst best practice for writing user stories is well documented, the guidelines for scaling this practice to larger groups of activities is not. Having worked with teams using epics for some time, I have seen a range of examples of good epics and even more examples of anti-patterns. Getting epics wrong is probably the number one reason why teams perceive scaled agile to add less value than they expect.

    What follows is a summary to serve as guidance for those embarking on backlog creation for a team or squad within a scaled agile organisation.

    Epic?

    An epic is a group of stories. Each story is a necessary stepping stone to achieve the objective of the epic.

    • An epic can be relatively small or relatively large, but is bigger than a team can deliver in a single sprint. It should generally be a large piece of work, taking between 1-3 months.
    • An epic should represent a concrete piece of deliverable value to the end-user. Having a backlog full of epics representing invisible enablers is an anti-pattern.
    • Epics should articulated as an outcome. The purpose of the epic is to describe what we want our user to experience, not how to achieve that outcome. Having an epic which is overly prescriptive about how to achieve the outcome is an anti-pattern.
    • It should be possible to prioritise all epics against one another. If it isn’t possible to meaningfully prioritise one epic against another, the planning process becomes overly constrained and complex.
    • Epics should be mostly deliverable by a single team. Organisations are not perfect, and therefore this criteria is often a tough one. Some dependencies are OK, but if you find yourself in a position where most epics have dependencies to two or more other teams, it may be time to consider reorganising around your business domains and architectural ambitions. My recommended read on this subject is Team Topologies by Matt Skelton.
    • An epic should materially improve an underlying KPI or key result (in the OKR framework, for example).
    • A team should always learn something from delivery of an epic. Almost all perceived user value is a hypothesis which product teams should be seeking to test at the earliest opportunity.

    Benefits of epics

    Epics:

    • Enable meaningful prioritisation across teams
    • Provide transparency across teams
    • Enable efficient evaluation of work against OKRs or KPIs – attempting this story-by-story is very time consuming
    • Force product managers to work hard at breaking down long term product aspirations into chunks which deliver user value
    • Enable meaningful dependency planning across teams
    • Are a mechanism by which to communicate the value of a group of stories

    Formulating epics

    Epics, like stories, must start with the user. When faced with a blank canvas, the use of design thinking methods can lead to a better understanding of the problems the user faces. To better understand who your user might be, the use of personas will allow you to better empathise with the human beings who will ultimately use your product. Personas are also a powerful tool with which to communicate with your team, helping them to truly feel connected with why a given epic is important.

    The process for writing an epic within a scaled agile context often begins with a process of slicing up a broader ambition. If you are working with initiatives, each epic is a “slice” of the larger initiative. Slicing is possibly the hardest task a product manager faces on a regular basis. There are several mechanisms by which work can be sliced. Most of these can be linked to an underlying principle of “shifting left”: always try to learn as much as possible as early as possible. By bringing learning forward in the roadmap, you mitigate the risk of committing too much time to endeavours which don’t deliver the expected value.

    • Prototyping – can a prototype of a deliverable be developed before committing to a longer roadmap, in a way which meaningfully teaches you something about the underlying hypothesis you may have?
    • Architectural slicing – can you deliver value without committing to an expensive engineering challenge, in order to shift learnings left?
    • Segment slicing – can you offer products to subsets of users in a way which removes complexity from earlier epics, whilst enabling learning from those users who you do target? Try to think broadly about segmentation, as your existing predefined customer segments may not be the most optimal for this purpose. Experiment with slicing customers based on a broad range of characteristics to find pockets of opportunity to target smaller user groups with similar needs.
    • Complexity slicing – can you strip complexity away from the target product in order to deliver value to some users earlier? This is an antidote to the anti-pattern of having too many enabler epics – rather than building a complete solution back to front, build a partial solution through all layers of the technology stack to enable delivery of value early on.
    • Stubbing – can you measure interest in a feature by creating a link to the feature before you even begin working on it? Measure the number of clicks on the link to gauge interest before beginning an expensive development journey.

    Documenting an epic

    An epic, once you have sketched out its place in a backlog, must be documented in such a way as to be meaningfully discussed in a variety of forums, prioritised, and implemented.

    Leadership must be able to understand the epic in the context of the overall value proposition for your product. Other product managers must be able to evaluate the priority of the epic against their own in order for you as a team to prioritise effectively. Teams must be able to understand the objective in sufficient detail to be able to get to work implementing and delivering the epic.

    A four-step process can be followed to document an epic effectively:

    1. Write the epic description. The description is a narrative, structured in a similar way to a user story. “As a who, I want to what, so that why“. The who, what, and why must be specific enough for the relationship between the work and the benefit to the user to be clear. Keep in mind that the user needn’t be a customer – it could be an internal team or stakeholder, a system, or a member of your own team.
      • “As a user…” is less desirable than “As a controller managing incoming invoices…”
      • “…I’d like to manage invoices…” is less desirable than “…I’d like to be able to control, reject, or comment on invoices…”
      • “…so that I can do my job quicker” is less desirable than “…so invoices can be quickly and accurately processed to ensure timely payment, increasing creditor perception of our company.”
    2. Write a summary for the epic. The summary is a short and sharp name for the epic which can be used to unambiguously refer to the epic in prioritisation and status discussions. For example “Invoice controlling workflow”.
      • An anti-pattern for epic summaries is to use the “Feature: version 1” formulation. The summary should still communicate as specifically as possible what the outcome of the epic is.
      • The summary should not be the full description – avoid using the “As a user…” formulation.
    3. Write clear acceptance criteria for the epic. The acceptance criteria, as for a story, are a critical tool for the implementing team to understand specifically what is expected from the user’s perspective.
      • See acceptance criteria as a checklist of requirements to act as guardrails for the team as they design the solution, and as a way for the team to know when they are done.
      • A common mistake is for acceptance criteria to be prescriptive about how to deliver the expected outcome – that is not the purpose, and can fundamentally undermine the autonomy of the team.
    4. Evaluate the epic. An optional final step can be undertaken, to evaluate the epic using a framework which can be applied consistently across all epics as an aid to prioritisation. Examples of scoring methods which can be adopted include:
      • RICE scoring
      • MoSCoW method
      • Cost of Delay
      • Kano model

    Next steps

    Once a backlog has been defined and refined with epics of a high standard, three steps naturally follow. Depending on the cadence of the adopted scaled agile framework, these activities may happen periodically within a product increment (or “sprint of sprints”), or on an ongoing basis more aligned with individual development sprints.

    1. Prioritisation. Leveraging the evaluation scoring performed in the final stage of epic definition, leadership and the broader product management community prioritise epics against one another to create the overall product backlog.
    2. Story refinement. The product manager and team(s) working the backlog collaborate to break down the epic in to deliverable stories which ultimately deliver the expected outcome for the user.
    3. Dependency management. With the deeper knowledge of what is needed to deliver each epic, the team can engage in a forum with other teams to highlight dependencies. The prioritisation across teams from point 1 is used as a reference when deciding whether a team should work on their own stories, or dependencies other teams have on them.
    4. Estimation & execution. The team implementing the epic estimate the stories within an epic and begin working to deliver the stories in priority order.

    Image credit: İrfan Simsar on Unsplash

  • On privacy and contact tracing

    August 10th, 2020

    Contact tracing, the process by which health authorities can identify those at risk of infection by virtue of proximity to a known case of a virus, …

    Link to full post on Fjellfolk: On privacy and contact tracing
  • Minna-jima

    April 16th, 2020

    When asked, Lucy, myself or Magnus would probably choose our day trip to Minna Island as the best day of our trip to Japan. We got off to a bad start…

    Link to full post on our family blog: Minna-jima
    26.6477272127.8168726
  • Big Data in Urban Morphology

    April 15th, 2020

    In this paper Geoff Boeing examines ways in which the Smart Cities paradigm can leverage publicly sourced datasets to enhance traditional forms of …

    Link to full post on Fjellfolk: Big Data in Urban Morphology
  • Morocco 2007

    April 11th, 2020

    I had a choice when packing for this short trip to Morocco in 2007: pack my beloved OM10, knowing that the likelihood of losing or breaking it in the dense crowds of Essaouira’s annual Gnawa music festival were high, or try to get by using just the camera on my phone, a Sony k800. Reminding myself that I was going for the music, not the photography, I settled for the phone camera.

    Needless to say, phone camera technology has come on quite a bit since then, and the quality of the resulting images is not great, but looking back I’m not so unhappy with my decision. I was able to relax and focus on being in the moment, whilst still capturing just enough in the grainy black and white images I took to be able to look back at the photos and relive the energy and vibrancy of an incredible weekend of music, adventure, and friendship.

  • New York, March 2014

    April 9th, 2020

    Back in 2014, a few months before the arrival of my first child, I took a business trip to New York. Along with the usual laptop and suits, I took my trusty Olympus OM10 and a few rolls of Ilford HP5. The weekends bookending the trip were spent walking the streets of Manhattan and Brooklyn, soaking up the raw energy of the city and snapping a few photos. I remember I was going through a period of anxiety at the time, and found the usual calm and solace in the practice of making photographs – creative meditation for the mind.

    For the second weekend, my wife joined me – 5 months pregnant – and we had one of the most spontaneously wonderful weekends of my life, taking in live music, city sights, sports and culture back to back over the course of just three days. A highlight was catching Tinariwen live at Brooklyn Bowl, an experience I must rely on my mind to remember as I had neither film nor flash for my OM10.

1 2 3 … 9
Next Page→
 

Loading Comments...