agile Archives - Mike Dixon's Blog

How Continuous Planning Revolutionises Product Delivery

Introduction

Traditional project management often relies on planning as a static map, complete with fixed dates to guide a team’s journey. In contrast, a modern, collaborative approach offers dynamic planning, allowing teams to navigate the constantly changing landscape of project delivery. This article explores why this flexible style trumps the limitations of traditional planning models.

The Pitfalls of Fixed Dates in Traditional Planning

Traditional planning tends to hinge on establishing immutable deadlines. While structured, this approach often leaves teams scrambling when faced with unexpected changes, causing missed deadlines and eroding trust between teams, leadership, and the wider business.

A Dynamic Approach: Continuous Planning

Planning evolves from a static page into a navigational exercise in a modern approach. Teams engage in ongoing adjustments throughout the project’s lifecycle, focusing less on specific end dates and more on the journey’s nuances.

Benefits of Continuous Planning

Adaptability: Teams can adjust to shifting market conditions or unforeseen challenges.
Risk Mitigation: Continuous updates to the plan allow for early identification and mitigation of risks.
Clear Pathway: This ensures that teams remain aligned and focused, providing the flexibility to pivot when necessary.
Focused Execution: Teams can zero in on the most impactful areas, ensuring their efforts are optimally directed.
Understanding Dependencies: Ongoing planning illuminates dependencies, allowing for coordinated action.
Transparency: Regular planning updates give stakeholders an accurate view of the project’s status, aiding more informed decision-making.

Real-world Example: The Ripple Effects of a Failed Product Launch

Traditional methods might initially seem appealing in a complex product launch, particularly to executives. A rigid roadmap with fixed deadlines offers the illusion of control and predictability, allowing other parts of the business to align their activities and budgets around those dates. However, this rigidity often turns into a liability.

When the roadmap fails to adapt to changing market demands or technical challenges, missed deadlines can have ripple effects far beyond the project team. These failures can disrupt other departments’ plans, affect cash flows, and even impact shareholder confidence if planned revenues don’t materialise. What was initially seen as a tool for stability can quickly become a significant source of instability across the organisation.

Building Confidence in Dates

Continuous planning doesn’t mean avoiding commitments to deadlines. Instead, it cultivates confidence in those dates, allowing for advanced notice of potential delays and making course corrections as needed. This ensures that trust remains intact, sidestepping the element of surprise and disappointment.

Leadership’s Role: Steering the Ship and Guiding the Fleet

In the modern approach to planning, leadership takes on an expanded role. Leaders are not just directing their teams but also navigating alongside steering committees (Steercos), who may be new to this flexible way of working.

Strategies for Leaders in Supporting Their Teams

Leaders must create the right conditions for their teams to succeed in navigating their journey. Here are a few strategies that Leaders can draw upon to support this effort.

Facilitate Open Communication: Create forums for regular updates, ensuring transparent, two-way communication between all involved.
Empower Teams: Delegate decision-making to those closest to the work, fostering agility and confidence.
Iterative Learning: Advocate for a culture where lessons are continuously drawn, and adjustments are made in real time.
Dynamic Team Allocation: Balance long-term objectives with the flexibility to reassign team members and budget quickly in response to changes, prioritising critical areas.
Outcome Alignment: Ensure that the teams and the Steercos are aligned on the outcomes, reducing the likelihood of misunderstandings and costly shifts in direction.
Engage Stakeholders: Regularly update stakeholders, including steering committees, to maintain alignment on strategy and progress.

How Leaders Can Engage With Their Peers and Steering Committees (Steercos)

Leaders not only need to support their teams, they also need to educate and include their peers and internal functions like Steering Committees to ensure that they are also taken on this journey and understand how to best adapt to this new way of working.

Here are some suggestions on some approaches that could be taken.

Education: Educate Steercos on the benefits of a modern, dynamic approach through workshops or case studies.
Inclusion: Make them part of the decision-making process, not just an oversight body.
Transparency: Share regular and clear updates, demonstrating that a flexible approach doesn’t lack accountability.
Collaborative Decision-Making: Give them a seat at the table when significant project decisions are made.
Celebrate Milestones: Acknowledge achievements, both big and small, showcasing the value of the modern approach.

Conclusion

This modern approach to continuous planning offers a dynamic, responsive, and more trustworthy framework, especially suited for today’s complex, fast-paced projects. This planning style is not an isolated activity but an integral part of the project lifecycle, supplying teams with the flexibility and confidence they need for successful delivery.

By shifting from a static, date-centric model to a more dynamic, adaptive methodology, teams, leaders, and businesses stand to gain more than just completed projects—they build a foundation of trust and flexibility that benefits the entire organisation.

Staying True to Agile: A Guide to Identifying and Correcting Common Missteps

In the early days of Agile, the intended focus was on collaboration, adaptability, and delivering value to customers. The Agile Manifesto, penned by seventeen software developers in 2001, was a reaction against cumbersome, process-heavy methodologies. It was a call to focus on a more human-centric approach to software development.

Fast forward to today, and it’s not uncommon to see Agile environments where processes and procedures have taken over, sometimes overshadowing the very principles that the founders championed.

The Agile Manifesto

As a reminder, the Agile Manifesto states:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

While there is value in the items on the right, the manifesto asserts that the items on the left are valued more.

The Slippery Slope of Anti-patterns

The anti-patterns described below often arise from well-intentioned efforts to achieve the values on the left side of the manifesto. In our pursuit of efficiency, collaboration, and adaptability, it’s surprisingly easy to slide into the practices on the right inadvertently.

Regular reflection, tracking progress, and maintaining accountability can help navigate this fine line.

Through the lens of TechPulse, a fictional SaaS company based in the UK, we will explore some common anti-patterns that have emerged in the Agile landscape and how they identified and overcame them.

Individuals and Interactions over Processes and Tools

Value: Empowering our team and fostering collaboration is central to Agile. At TechPulse, we believe that human connections drive creativity and innovation.

Anti-pattern Scenario: A new tool was introduced to automate communication, but it reduced face-to-face interaction, leading to misunderstandings, low morale, and a decline in team cohesion.

Identification: TechPulse noticed a drop in creativity and collaboration, prompting a review of communication practices. Surveys and feedback revealed the tool was hindering and not helping this scenario.

Turnaround: Encourage regular team meetings and use tools that facilitate, not replace human interaction. Balance technology with personal connections and ensure tools align with team needs.

Working Software over Comprehensive Documentation

Value: Prioritising functional software ensures that we meet customers’ needs efficiently. At TechPulse, we focus on delivering value through working products.

Anti-pattern Scenario: Obsession with documentation delayed a release and caused confusion. The extensive documentation quickly became outdated, causing inconsistencies in the project.

Identification: Delays and confusion led TechPulse to evaluate its documentation approach. A review revealed that excessive documentation was hindering progress.

Turnaround: Implement a “just enough” documentation approach focusing on what’s essential and ensure that code is written clearly with clear unit, integration and end-to-end tests.

Customer Collaboration over Contract Negotiation

Value: Engaging with customers for success is key. At TechPulse, we believe in building products that resonate with our clients’ needs.

Anti-pattern Scenario: A rigid contract with a major client led to a lack of flexibility. When the client’s needs changed, the contract’s inflexibility hindered our ability to adapt.

Identification: Client dissatisfaction and strained relationships alerted TechPulse to the need for more flexible agreements. Regular feedback sessions revealed the contract was too restrictive.

Turnaround: Craft flexible contracts that allow for ongoing collaboration. Regularly review and adjust agreements to align with evolving project goals and maintain open communication with clients.

Responding to Change over Following a Plan

Value: Flexibility and adaptability are core to Agile. At TechPulse, we strive to be responsive to market trends and customer needs.

Anti-pattern Scenario: A rigid product roadmap led to a loss of market share when unable to adapt to a competitor’s disruptive technology. The inability to deviate from the plan cost us valuable opportunities.

Identification: Falling behind competitors prompted TechPulse to reassess its planning approach. Analysis revealed that the rigid planning process was stifling innovation.

Turnaround: Adopt an adaptive planning approach, focusing on fewer measurable outcomes, allowing for regular reassessment and realignment with market trends. Encourage a culture that views change as an opportunity, not a threat, and foster team collaboration to ensure alignment.

Conclusion

The Agile Manifesto is about finding the right balance. At TechPulse, our fictional journey illustrates how over-emphasising the items on the right can disrupt our goals.

By recognising these anti-patterns and implementing the suggested turnarounds, we can embrace a balanced approach that truly reflects the Agile philosophy.

Our experience with TechPulse reminds us that the Agile Manifesto is not a rigid set of rules but a guiding philosophy that requires understanding, adaptation, and balance. Continual reflection on the values and principles of the manifesto helps us avoid common pitfalls and ensures that we remain aligned with our core objectives.

Prioritising a backlog doesn’t need to be rocket science!

The common component in most software development agile practises is the backlog – a list of user stories, often written on cards, that represent a feature or a piece of work that needs to be completed by a member of the development team.

This backlog of work needs to be prioritised – and I have seen different people do this in different ways.

I’ve seen these items prioritised individually in excel by a single individual, where many different factors have been scored and a calculation applied to give a final score where weightings have been applied. This took a lot of time and a lot of toing and froing – all the while the development team were working on lower value items. Made no sense to me.

This list is then ordered largest value to smallest, resulting in one person’s opinion on what his list should be. This did not take into account any development team member’s experience, as well as any other teams that may be impacted by the work.

Any new items would need to be scored in this fashion, debated extensively and then slotted in to the backlog.

As far as I am concerned, this is not the way to prioritise work – especially in an agile environment.

A big part of agile is collaboration, responding to change and having working software at the end of each release. Why not apply these five principles to prioritisation.

Get everyone together

If someone is involved or impacted by the functionality being discussed, get them involved in the prioritisation – within reason obviously. At least have each department represented and ensure that there is one mediator and someone who can make a final decision if there is a disagreement.

Understand the goals

Set out at the start what the strategy is for your product and set out the objectives. Each user story or card needs to constantly compared to these objectives and ranked according to how far it goes to achieve these goals.

Relative priority

Keep things simple. Select a starting point buy placing a card in the middle of a table. Discuss this card and ensure that all involved understands exactly what this card represents and how it helps to achieve your product’s strategy and objectives.

Select the next card, discuss what it is and explore it’s benefits, risks, amount of dev work etc and then place it above the card if it is more important or below this card if it is less important.

Keep doing this with each card until you have a fully prioritised backlog. If its a big backlog, then you may need to split this into a couple of sessions.

Be flexible

Through discussion, you may find that items are no longer required or require more definition or to be defined. You can do this in the meeting itself or separately.

Future proof

Once finished, when new items come up, they can be easily prioritised as all members of the team understands the backlog and how it is made up. You place the new feature in the backlog relative to everything else.

In my experience, this is by far the best way to prioritise work. Having items prioritised relatively compared to other work get’s the business to understand that they cannot have everything all at once and that a decision has to be made as to which is more important than the other. You do not have a spreadsheet that gets ignored with multiple items with the same value.

Items can be redefined as you go and the team as a whole has been included and feel valued. The whole team has a voice. This leads to highly motivated team who have bought into the product and what is trying to be achieved.

What is Validated Learning and how can it be applied to Kanban?

I’ve been reading the Lean Startup by Eric Ries and he has introduced me to the concept of Validated Learning. Validated Learning is the practise of effectively measuring the accuracy of assumptions and using the results of the Validation to understand whether the assumption was correct and if so, continue onto the next test. If not, decide whether your strategy, assumption or feature needs to be improved or to change direction.

The main thing that I found interesting was an example of how this could be integrated with Kanban, a practise that I am an avid user of since launching Mousebreaker.com in 2008.

The example spoke of the founder of Grockit, an online teaching site that enables students to learn either socially with other students online or individually. They assumed that a user story was not actually delivered until it had been confirmed as a success through measurement of Validated Learning.

In addition, the feature is aligned to the product’s strategy and therefore had a set of assumptions associated with it. The process of Validated Learning either proves or denies the assumptions.

If it is found that a feature has not been a success and actually improved the product, then that product is removed. In addition, the feature is aligned to the product’s strategy and therefore had a set of assumptions associated with it. The process of Validated Learning either proves or denies the assumptions.

In the example, Grockit uses A/B Testing and cohort analysis to validate the success of the feature being delivered by the development team.

A/B testing allows you to test different versions of pages or parts of pages to different proportions of your users to test a metric such as registrations or visits to sections of your site – although you can measure much more than this. You can then determine which version works best and then make the winner available for all users.

Cohort analysis is very similar but takes place a step before the A/B Testing. You may use a number of different marketing channels using a number of different messages, for example. Each user that comes from one type of channel/message would be associated with that channel/message and then tracked throughout their lifetime on your product. This would allow you to understand the cohort group’s lifetime value for example, so that you can understand the value of those messages or that channel.

You can use each of these methods exclusively or together and measure against the metrics that matter to your business. What you are looking for is actionable data, something that up you can make a decision on or understand the value of a change.

I really like this concept; however it does seem to go against the basic principles of Kanban. Kanban is an agile methodology that is used, partially, to eliminate waste during the build process of a product through practises such as limiting work in progress and kaizen – the constant improvement of the process.

My question is whether removing a feature that is not deemed a success as wastage; and if it is, could that have been avoided?

Whenever I have built a web site and we have launched a new feature, we have measured and iterated based on the data collected until it has worked – a form of validated learning. Only, of a feature has not worked, I have seldom, if ever, removed this feature. My main thought on this is that it would have been a waste of the time to develop the user story.

Perhaps I would have removed the feature if it had a detrimental effect on the metrics used to validate the functionality.

I would be happy to do this as long as it informed decision making in the future. This is what Eric Ries is arguing. A user story or feature that is being developed is actually a test of a theory or an assumption. You are assuming that this new feature will improve the product and will improve a core measurement to your business.

If it does not do this, why keep this feature live? If it does not deliver enough improvement, then why keep it live? As long as these lessons learned helps to change the strategy or assumptions around your business, you should be able to reduce wastage as your strategy should be directly influenced by validated learning through the use of your product.

I really like this concept and will keep this in mind when I next get the opportunity. I will definitely be posting about it once I have some personal evidence of this in practice.

Please comment if you have used Validated Learning in practise and how you have found it in the comments below.

A Practical example of Feature Driven Development

Feature Driven Development (FDD) is often theorised about on many web sites with blog posts, articles and essays being published on a regular basis and this blog post will give you a much needed practical example of it in use.

One article that is worth pointing out is DZone’s Introduction to Feature Driven Development. This is part one of a two part article describing a theoretical project and a theoretical team and the first three of five steps to achieving Feature Driven Development. It is extremely well written and gives you some really good insight into what is needed.

In my experience, I find that when you take these theories and methodologies and apply them to real life situations and projects, that they need adapting and shaping to fit with what you are trying to deliver.

An example of this is when I was leading the Product Development across five different web sites and one development team. The way in which I had implemented the Kanban methodology was different for each site due to different stakeholders and different commercial strategies needing to be delivered.

Anyway, back to a practical example of Feature Driven Development.

The example that I am using is the build of Mousebreaker, a casual gaming site that utilised a mixture of Kanban and Feature Driven Development to quickly and effectively deliver a new web site with a new code base in 28 days.

Traditionally, my approach had always been to gather all requirements, build the infrastructure, then the code, and finally the front end for a web site. This information gathering and the writing of functional and technical specs can take a long time to complete. Then, when the development begins, the whole spec needed to be delivered before the site could launch. By which time 6 months has passed and requirements may well have changed and what is delivered is not necessarily what the business or the market needs.

Feature Driven Development tries to get around this by defining the requirements as features, then the business owners and development teams prioritise these features into a backlog of work and then the developers deliver these features in the order that offers the most business value.

One thing to note is that there is some pre-work that needs to happen before development can start. The general technical approach needs to be agreed; technologies need to be discussed, terminology needs to be agreed and basic development, testing and live environments need to be created.

In addition, certain standards would have been discussed such as coding, SEO and accessibility standards and any automated testing. In addition, any front/back end frame works that will be used as well should also be discussed.

If you look at the Mousebreaker site, you will see that the primary user function is for the user to play flash games. So the first feature that was worked on was that the user needs to be able to play a game on a web page.

At first, the developers approach was to start building a database infrastructure that could be used for the whole site. They were also wanting designs for pages etc. You need to be careful here as that is not what was required by the feature. All the feature required was for the user to be able to play a game. Nothing else.

So to deliver this feature, all that was required was a static html page with some embed code that would allow a user to play a game. The game needed to be in a web facing folder.

Once complete and tested, the feature can then be released.

The next story was that a user needs to be able to play all games on a web page.

This is where the database gets created and the initial html page is turned into a template. Again, the developers only needed to create a database that delivers the feature’s requirement.

In the meantime, while the initial features were being delivered, the designers were working with the development and business teams to deliver the designs for the site. There was a further feature for the site to have a premium look and feel that eventually would need to be delivered which could be applied to the site around the templates that were being delivered.

This felt a little back to front, but you need to remember that we were delivering features in the order of business priority.

As the features kept being delivered, the site quickly started to take shape. Throughout the development, the business representatives were always attending the stand ups and were constantly making decisions on scope of work and what would be required for launch.

We found that the close collaboration between the business and the development team was the most effective way of managing scope and ensuring that what the dev team delivered is what was expected.

I have applied this form of Feature Driven Development many times and I find that it really works. You do need buy in and effort from the business owners, and you do need to make sure that the developers do only focus on what is required to deliver the features rather than architecting a full solution before understanding all the requirements.

This allows more of a front to back development process. Where the features take priority over the implementation. One thing that I would like to point out is that there would be occasions where future considerations are sometimes ignored or put to one side to get functionality out and that this may result in refactoring work further down the line.

The thing to remember is that you will have already delivered the highest business value functionality required at that point and that the business will understand that any refactoring work should also have a value and then a discussion can be had about options and whether this work needs to be done or not. If it does and it takes a longer period of time, then allowances should be made for this.