Growing Better all the time!

One of Feed Leeds newest and most exciting partners is going great guns. Growing Better is a social enterprise dedicated to better mental health through growing edible produce. As recently as March…

Source: Growing Better all the time!

Posted in Uncategorized | Leave a comment

Competitors as Anti-Stakeholders

When I think about stakeholders and actors I usually start with the standard five groups: customers/service users, employees, suppliers, shareholders and regulators. I can then segment these groups down into more focused and actionable sub-groups.

[For clarity, I’ll state my preferred conceptual view of “stakeholders having interests” and “actors having goals”.]

A recent re-read of Porter’s 5 Forces has left me wondering if I should include competitors in that initial high-level list. Competition can come several sources: existing competitors, new entrants and substitutes. Additionally, although often overlooked, it can come from within the organisation itself, from other products and services that compete for the same customer spend or time. This latter form of competition can be either intentional or accidental. An example might be online sales that cannibalise in-store sales – with potentially a lower net margin.

Both external and internal competitors have a degree of interest, perhaps influence and maybe even power in the product or service under design. The four Marketing P’s of Product (and Range), Price, Place and Promotion provide a good starting point for exploring this concept.

Competitors may also be interested in disrupting or themselves utilising any part of the supporting value chain of suppliers and partners;or the environment by for example seeking to get regulations changed. In this case they might also be considered as Actors – with explicit goals, that we should attempt to confound, rather than, as with supporting actors, help achieve.

As a result such competitors can usefully be considered as a category of stakeholder – which I’m calling an “anti-stakeholder”. I’m not using that term simply in an attempt to attract your attention: it’s loosely linked to the term “anti-pattern” – a pattern that disrupts the achievement of the desired goal (the term is popular with Agilists to describe behaviours but relevant to any aspect of designing or managing change). A competitor will

Perhaps this interest of competitors is represented internally by our product/service and marketing SMEs. However it still may be useful to explicitly call it out when we’re working on a customer-facing product/service to ensure that we’ve considered every aspect of our competitive position with our offering.


Footnote: There is another use of the term “anti-stakeholder” that is used to describe a management strategy (intentional or unintentional) that seeks or results in behaviours and performance that are against the interests of one or more stakeholders. Examples of this are: focusing on the financial success of the business rather than the shareholders; and failing to comply with sector regulations. This “anti-stakeholder strategy” is itself a legitimate focus for business analysts – and potentially for another blog post.

Posted in Uncategorized | Tagged | 2 Comments

Agility and Urgent Optimism

“Urgent optimism” is the sense of urgency that we sometimes experience when we are close to completing a task or achieving a goal. We are motivated to find that extra energy and effort to get over the line – sometimes for an extrinsic reward, and sometimes simply because of the buzz that we get.

The effect of urgent optimism is enhanced by the increasing sense of anticipation that we experience as we approach completion of the task or goal. And this anticipation works in conjunction with a feedback loop to positively reinforce and thereby further drive our goal-seeking behaviour.

This phenomenon is exploited in games design and explained well here . I’m curious as to whether or not it can explain some of the behaviour of Agile teams. Given the relationship between games and work we might expect that it can so here is a starter for ten …

In a Scrum-oriented team with fixed length sprints, the primary driver is to meet the commitment within the fixed sprint time frame. In a less mature and disciplined team urgency and effort may ramp up towards the end of the sprint as the team strives to ensure it delivers on its commitment: burn up / down charts provide the team with feedback as it approaches the end of the sprint and thus increase the sense of anticipation, urgent optimism and ultimately effort. However, if a team is confident it will deliver on time then the primary incentive to perform at a higher level is removed and the team may coast to the line: the feedback loop has had the opposite effect.  However, a more mature disciplined team will still be impacted by urgent optimism and strive to get across the line early. Why ? Because it can use the extra time to advantage: to undertake some learning, experimentation, refactoring or just hanging together and bonding … and because it can !

In a Kanban-oriented team there is no fixed iteration period. Everything else being equal, that would appear to reduce the potential for the urgent optimism effect. Cadences around elements of build, iterate, deploy and activate may provide an appropriate opportunity to celebrate and reflect but are not intrinsically linked to achievement of a defined finite / bounded / completable goal or task and so are unlikely to produce this effect. However anticipating being able to move on to a new feature on completion of a current story, or hitting an delivered value milestone may well trigger the phenomenon. What else can a Kanban team make use of to help it benefit from urgent optimism ? Is that even a desirable goal ?

I’m not suggesting we exploit the urgent optimism phenomenon to drive higher effort on a continual basis: that would be unsustainable – and just plain wrong. However I do argue that it’s good to be aware of it in the context of understanding one of many behaviours that individuals and teams exhibit and thus being better able to support colleagues.


Posted in Agile, Ways of Working | Leave a comment

Increasing Your Business Agility

6th June 2015: Following feedback, I’ve updated – and hopefully improved – the content below. I’ve also changed the title of the post from “Principles of Business Agility” – because it’s primarily about ways of working, not principles.

Agile ways of working shouldn’t be limited to the provision of IT solutions – just as lean isn’t limited to manufacturing. However the language of Agile can be off-putting to outsiders (and I include myself in that), with it’s use of strange terms to define artefacts and ceremonies. With that in mind I wanted to develop a version of the Agile Manifesto and Agile Principles that was jargon-free and would be immediately understandable by business colleagues. I’d very much welcome any feedback on it (or to learn that someone has a better version somewhere !)…

I hope to show that adopting more agile ways of working will increase the chances of attaining, as a team, the objectives that help us deliver on our business goals and commitments.

We all aspire to work in ways that are more likely to achieve the following objectives:

A. Maximise our return on investment by delivering value sooner
B. Reduce the time that it takes to start getting a return on our investment
C. Increase the predictability around costs and delivery of part or all of a change
D. Increase our ability to respond to changing circumstances and priorities
E. Decrease the risks associated with our change effort and deliverables
F. Increase the quality (fitness for purpose) of our deliverables

We have found that adopting the ways of working below increases the chances of achieving the objectives above.

The ways of working are divided into:

  • Foundational: Can be adopted relatively easily, usually with no or minimal change to current ways of working
  • Progressive: Likely to require some changes to ways of working, and training to develop competence
  Way of Working (Foundational) Outcomes Related
1 Investing time in making big requirements and design decisions up front, but leaving decisions on detail as late and as close to where the work is undertaken as possible Balances increasing certainty over timescales and resource estimates, with the flexibility to be responsive to changing circumstances and needs, and to have more time to find the best options  

D, E, F

2 Breaking down big changes into a series of small changes that can, where practical, be tested and delivered every 2-4 weeks (whether used “live” or not) Easier to estimate, resource and manage predictably; fewer dependencies; more efficient (less task-switching); easier to test thus reducing the risk of missing errors; and testing doesn’t get squeezed at the end  

C, D, E, F

3 Delivering* changes as soon as they are ready and the business can test / use them

(*Note that delivering a change doesn’t mean it has to be used immediately)

If using the change in a live environment, start getting the benefits of the investment sooner; get faster feedback on the real value of the change (in test or live); identify and correct misunderstandings as early as possible  

A, B, E, F

4 Delivering changes that have the most value first, and at all times; simplifying to minimise the amount of work needed to be done at any time Get the biggest bang for your buck as soon as possible; make the optimum decision about when to stop and focus resources elsewhere  

A, B

5 Adopting a risk-based approach, deliberately seeking out the least well understood and complex elements earlier and focusing efforts on these early on Improved chances of successful change; increased confidence of both the team and the sponsors; minimise the need for unsustainable heroic efforts  

C, E, F

6 Planning and re-planning on a daily basis, and being transparent and visible about plans, progress and challenges Minimise surprises and blockages; more motivated team, challenges faced into and resolved/mitigated quickly together  

C, D, E

7 Adapting to changing circumstances / priorities and increased clarity over goals / requirements (which may be hazy or simply wrong in the early stages), while being clear about the impact of changes on time, cost and deliverables Ensure that the change effort delivers the maximum value as determined by the stakeholders and delivers a solution that is useful, usable and used  

A, D, E, F

8 Being clear about the trade-off between different options for example in terms of cost, speed of delivery, extensibility, maintainability and re-usability Shared understanding of the total life costs and value of the solution  

A, E

9 As leaders, articulating a clear vision, and challenging but achievable goals for the team; un-blocking issues that threaten to hold up progress; not micro-managing More motivated team; team empowered to make better, faster decisions close to where they are needed; reduced delays  

B, D, F

10 Giving team members the best possible professional training, working environment, access to domain knowledge and tools More motivated team, fewer delays, better decisions  

A, E, F

11 Periodically reflecting as a team on how we’ve worked and how we can do it better – and implementing our findings Shared learning and understanding, leading to improved performance  

E, F

  Way of Working (Progressive) Outcomes Related
12 Reducing the number of concurrent activities and the size of each Increased value delivery; less “waste”; removal of bottlenecks; increased ability to cope with unplanned work
13 Focus on measuring and managing the key outcome metric – value, over output metrics such as hours or projects completed Reduces “gaming the system”; removes false sense of security; allows team to focus on the work; improves line relationships  

A, F

14 Identifying the acceptance criteria for each requirement up front, and regularly testing to ensure that later changes don’t negatively impact earlier ones Improved predictability of delivery dates;  regular testing of smaller units of change will result in fewer surprises; testing doesn’t get squeezed at the end of the project  

C, E, F

15 Working collaboratively and continuously together in a cross-functional partnership with all parties involved in the change rather than in a customer-supplier relationship Less focus on “contractual” type documentation, handoffs and chains of approvals saves time and resources; increased confidence in effort and focus of all parties  

B, D, E

16 Encourage working at a steady, sustainable pace, avoiding heroics where at all possible Inclusive culture for all; no burn out; increased retention  

C, E, F

17 Committing adequate and stable / enduring resources from all parties to work closely together every day, ideally co-located Higher quality and quicker decisions due to collaboration; more productive and higher quality work over time; less time lost on-boarding new team members  

C, D, E, F

18 Focusing on the competence, work and output of the team rather than the individual; rewarding team-centred behaviours; letting the team set its own pace, with requirement to improve Together Everyone Achieves More; self-managing teams; cross-pollination of skills; increased resilience to loss of individuals; improved retention; less management overhead  

B, D, E, F

Posted in Agile, IT and Business Strategy, Ways of Working | 2 Comments

The IT department as a strategic business partner

I’d like to share a neat summary I came across of what being a strategic partner would look like for an IT department – and it’s this:

To be a strategic business partner, an IT department needs to:
– Forecast the business impact of emerging technologies
– Lead the development of new IT-enabled products and services
– Drive adoption of innovative technologies that differentiate the organisation from competitors

My paraphrasing and italics. For reference the source of this is:
(you may need to register to access this document)

Posted in IT and Business Strategy | Leave a comment

A new word – Glasshole

There’s been a backlash against Google Glass – whether that’s justified or not remains to be seen. However, I defy anyone to read this and not smile….

A person who constantly talks to their Google Glass, ignoring the outside world.
Glasshole: “Glass do this, Glass do that.”
Co-rider: Shut the **** up and enjoy the bus ride!
(My **** to spare those of a sensitive disposition)
Posted in Innovation | Tagged | Leave a comment

Reflections on when to define the problem / vision

Conversations in a couple of meetings this week have got me thinking about this topic. It’s “conventional wisdom” to think that we should start our voyage of change by clearly defining the problem, or alternatively (or both) the vision of where we want to be. The challenge goes something along the lines of “how can we decide what we want to do if we don’t know what the problem is or where we want to get to ?”. Seems reasonable – and the famous extract from Aice in Wonderland where Alice asks the cat which path to take is often used to illustrate this.

However, in the spirit, I’m going to ask you to challenge that wisdom.

I’ll start by asserting that we don’t always know what the problem is or even where we want to go. We may sense a symptom of a problem, and the destination may be over the horizon. So we know that there is likely to be a problem and there is possibly a better place to get to. We have a hunch and a direction of travel – but not much more. If we settle on the problem or vision too quickly, or assume that we know what it is and never challenge that assumption, then we increase the risk that we will be wrong, at least in part – and head off in the wrong direction with the wrong equipment.

To go back to the Alice and the cat story, we might consider investing some time in wandering up and down a few paths before deciding on the right one. In the business world, this translates into being prepared to fail (and celebrating that), and being prepared not to work in a purely linear way from problem to requirements to design etc etc, without looping back.

Quite often, our understanding of the problem or vision will change, sometimes quite dramatically, as we move through a project or building an team/organisation, and we need to loop back. That’s a good thing, not a bad thing. It doesn’t show that we were wrong first time, it shows that we are learning as we go. (As an aside, I’d go so far as to argue that a vision statement is almost the last thing a team/organisation needs – in both senses of “last thing”).

So my challenge is to not get fixated on getting to and committing to a rigid problem or vision statement up front. Invest enough time in walking up and down a few paths (for example looking at potential solutions) and allow yourself the opportunity to re-frame where you are going or even the purpose of your journey. The problem or vision will emerge at the right time, when it’s ready, and possibly when you least expect it.

Posted in IT and Business Strategy, Ways of Working | Leave a comment