Agile Project Roadmaps

Just enough planning, just in time.

By Murray Robinson, MD Evolve

Murray works with organisations to design digital projects and organizations capable of realizing them. He has 30 years experience in IT starting as a software developer, 20 in digital, 20 in project management, 16 with Agile and 3 in UX. Contact Murray at murray@ev0lve.co if you would like to find out more about planning and running Digital projects.

Executive summary

There is something seriously wrong with the way we are planning and running Digital Projects. Research shows that we spend one-third of our project budget developing detailed project plans and yet 70% of our projects are troubled or fail, and 50% to 80% of the features we develop are rarely or never used. 

One solution is to move away from Project funding to continuous funding of product development, but few organisations have done this. If we are going to continue to do projects, the solution is to plan them in an Agile way. Agile Project Roadmaps provide just enough planning, just in time; allowing you to plan projects in less than half the time and half the cost, which means that you can deliver benefits much faster and catch up when you’ve fallen behind.

The Problem

We spend one third of our effort on planning.

Research and experience show that organisations spend more than half their time and one-third of their effort (and therefore budget) developing detailed business cases, requirements, architecture, designs and project plans. See Phase Distribution of Software Development Effort, 2008

Most projects are troubled or fail.

Research by the Standish Group shows that 51% of Digital projects go substantially over time, over budget and deliver less scope than expected, and 21% are cancelled or not used. Everyone who has worked in this industry for a while has seen this many times. As a consultant, it’s rare to see a large digital project that is not seriously troubled.

Most features aren’t used.

At the same time, Standish Group research on internal projects shows that two-thirds of the features we develop are rarely or never used. Standish research is supported by recent research by Pendo, which shows that 80% of features in the typical cloud software product are seldom or never used. This research shows that we are wasting 50% to 80% of our effort on most product development projects.

Why this happens

Research and recent experience shows that most organisations are delivering digital projects in stages with or without Scrum, as shown in the Water-Scrum-Fall diagram below.

Refer to:

The problem with staged projects is that each group optimises their part of the process at the expense of everyone else. During the business requirements phase, stakeholders add every single process, feature and rule they can imagine because they know that this is the only chance they have to get them built. Architects and UI Designers create intricate designs to deliver all these features without any consideration of time or cost. Development partners underestimate the work because they want to win it and know they can make a profit on change requests. During development and testing these projects always find out that a lot of their requirements, architecture and design assumptions need to change. These essential changes lead to significant quality problems, descoping and time and cost overruns towards the end of the project. 

This happens because most Agile methods are Delivery Frameworks that address development-related tasks. They don’t have much to say if anything to say about budgeting, recruitment, resource management, sales, procurement, contracting or aligning with the company strategy. Hence, traditional approaches are used to provide a basic structure and a framework for project organization and to provide interfaces to the rest of the organisation.

In my experience, this “Hybrid Agile” approach creates a lot of conflict, confusion and change requests that are just as bad if not worse than a traditional staged development process.

Plans and designs decay

Despite the substantial investment in upfront design and planning these projects typically go off the rails when the world changes or they find their planning assumptions were wrong. Projects go wrong because designs and plans decay as the environment, scope and priorities change and as we learn what the requirements and solution should be.

Agile Roadmaps are a better approach

In this article, I will show you how to bring people together for two weeks to build a roadmap that provides objectives, goals and maps for the next three to twelve months. A roadmap that builds a bridge between Agile leaders and business decision-makers so that sponsors can feel comfortable giving you the funding you need to start and lead an Agile project: a roadmap that you update continuously and every iteration in a rolling wave. 

Agile projects

“Plans are worthless, but planning is everything.” President Dwight D. Eisenhower.

Plans are critical because they set expectations on the goals, the strategy and the resources you need. They justify the organisation’s expenditure on the initiative. They allow you to consider the problems you are likely to incur along the way and develop ways to avoid them. With a plan, you can prepare for different eventualities to improve your chance of success. With a plan, you can get the commitment and resources you need to achieve your objective. Without a plan, it’s improbable that people will give you the funds you need to pursue an initiative.

Some people argue that project planning is so unreliable that there should be no projects at all. But plans are still real. Organisations still spend buckets of money on improving a product or business process. This surge of work must be managed and done. The reality is that most companies have not abandoned projects and programs so we must help them do projects in a more Agile way.

Agile Project Roadmaps

Over the last few years, I have developed and refined an Agile Project Roadmap process that allows you to define, design and plan a project in weeks instead of months or years. In an Agile Project Roadmap, you set your goal, strategy and direction in a high-level plan so that you can get the necessary funding and support you need to build a delivery team. When the project team starts, they evolve the project plan with business stakeholders to deliver the maximum business value possible within the time and budget available. 

Agile Project Roadmaps are useful for anyone who needs to get resources for the development of a digital product or service. They are helpful for people in general management, product management, sales, marketing, account management, project management, analysis, design and software development in a company, consultancy, Digital Agency or service provider. 

I have used Agile Project Roadmaps to:

  • Plan a new eCommerce site for an Auto Manufacturer that allowed users to customise and price cars before going to a dealer;
  • Improve the speed and performance of a Telco self-service mobile phone ordering and management portal for business customers;
  • Enhance a self-service network management portal that a Telco provides to Banks and other Enterprise customers;
  • Design and plan a knowledge management website for a Health Insurance company’s call centre staff and
  • Design and plan a new travel website for a travel company.

Before we start

Understand the problem

Agile Project Roadmaps help us develop a plan to solve a known problem. If we don’t understand what problem to solve or question to ask, then we need to discover the right problem to solve. To do this, we take the brief, question the brief, develop hypotheses and plan and conduct research.

Research can be qualitative or quantitative and behavioural or attitudinal. Qualitative research might involve interviews, usability studies and business process maps. Quantitative research includes analysis of your business processes, customers and product data. Most projects benefit from combining insights from multiple research methods. 

The objective of Discovery is to get a clear business challenge summarised in a “How might we ?” statement. A how might we statement should be short and memorable with a character, goal and direction. It should be narrow enough to let you know your context, and broad enough to give you room to explore different approaches.

If we were talking about building a new suburb, the challenge might be: 

“How might we provide first homeowners, young families and retired people with affordable quality homes in our new suburb as soon as possible?”

Get funding and commitment to develop a plan.

Before you start developing a Project Roadmap, you need to get funding and resources to do planning. In most cases, the Project Sponsor will prepare a presentation for executives that explains what the business problem is and why the organisation should commit resources for a few weeks to develop a plan to solve it. Some organisations may require the sponsor to go through a formal project inception process. It is not necessary to do a business case before you start an Agile Project Roadmap because the Roadmap creates a detailed business case for the project.

Agile Project Roadmaps are an intense process that requires a significant commitment and rapid decision making. Before we start an Agile Project Roadmap, we need to book people in and make sure they are committed to the process. 

What are Agile Project Roadmaps?

An Agile Project Roadmap defines where you are trying to go and how you plan to get there. It describes the team, budget, time and resources you will need. Project Roadmaps integrate product planning, UX design, technical architecture and project planning into a viable strategy to meet stakeholders expectations. Agile Project Roadmaps bring senior stakeholders together with relevant experts to rapidly design and plan a new product so that you can get the funding and resources to develop it.

Roadmaps are about the end to the end-user experience, business process and system architecture. They define multi-step processes, and multi-system data flows. Roadmaps provide teams with a context, direction and strategy for the detailed design done in sprints. 

The Product Backlog in Scrum is a product roadmap that defines what the team is going to do in the next few weeks. Each Sprint, the team, refines the product backlog by adding detail, estimates, and order to the high priority items they are planning to do next. In Scrum, we avoid planning more than a few weeks ahead because we assume that any work to detail items in the backlog “depreciates quickly and must be frequently re-estimated.” The Product, UX and Architecture roadmaps we are talking about here provide the big picture to inform and integrate the Product Backlog in Scrum.

With an Agile Project Roadmap, we aim to avoid delay and waste by doing just enough Technical and UX architecture, design and planning just in time. To achieve this, we create a high-level product and project roadmap for the next 12 months, UX and architecture roadmaps and models for the next 3 to 6 months and detailed designs for the next 2 to 4 weeks. Our goal is to review and revise these plans every day and every Sprint. As the program and teams learn, they change their roadmaps and models. 

An Agile project roadmap is an alternative to the traditional staged project analysis, design and planning process that takes one-third of your project budget and half your project time. Agile Project Roadmaps replace Design Sprints, Project Inception, Business Case, Project Plan, Detailed Business Case, Business Requirements Phase, Solution Architecture Phase, UX Design Phase and Technical Design Phase in Traditional and Hybrid Agile projects. 

Why you need to plan further ahead

In my experience, teams that focus on planning stories for the next few weeks often produce narrow solutions that work well for small features but don’t work well when applied to other areas of the product. So instead of developing consistent and reusable UI styles for a website, each developer creates a version of the UI style for the component they are working on, which leads to a disconnected and fragmented solution with a lot of duplicated effort.

Local optimisation plagues organisations and is very common in AI research. A team that advances in small steps can get easily trapped in a local optimum that is sub-optimal overall. In contrast, a group that looks at the bigger picture can see over the local optima to the global optima more easily.

Agile Project Roadmaps allow you to develop higher-level roadmaps that let you look further ahead so that you can more easily get to the optimal solution without getting stuck in local optima.

Refer to: Ayoosh Kathuria, Intro to optimization in deep learning

Designing Roadmaps

Experience shows that a small number of smart people who come together to sketch models and develop prototypes can define a viable solution design in two weeks, that is 70% to 80% right. This is an example of the Pareto principle, where 80% of the benefit is gained from 20% of the effort. The team can then iterate to 95% right through trial and error in a few months.

Refer to Scott Ambler:Just Barely Good Enough Models and Documents

Refer to Scott Ambler: How Architects Fit in on Agile Teams

Deliverables

An Agile Project Roadmap defines the:

  • Business Problem;
  • Objectives and Key results;
  • Customer Experience Roadmap;
  • Solution Architecture Roadmap;
  • Product roadmap prioritised by value, size and dependencies;
  • Project risks and issues;
  • Project budget based on the resource plan;

In a traditional project, each of these deliverables would be an 80 to 100-page document with detailed and comprehensive models, spreadsheets and prototypes that takes six weeks to develop and two weeks to review. We won’t be doing that.

In an Agile Roadmap, each of the deliverables will be a couple of pages of text, illustrated with 1-2 slides and illustrated through recordings, models, prototypes and spreadsheets. The aim is to provide just enough detail to allow the team to develop a plan that defines a viable strategy and reasonable time and cost estimates. 

The Customer Experience Roadmap will map the end to end process flow, illustrated with black and white wireframes of critical interactions with 1 or 2 colour mockups to test the graphic design. It will not provide finished art, working code or a comprehensive blueprint for every user interface. 

The Solution Architecture Roadmap will be a simple working prototype that passes data from one end to another to show how the main technical components work in our environment. It will not be a complete, detailed technical design, and it will not provide production-ready code. 

Some examples from different projects are shown below.

How do you develop an Agile roadmap?

An experienced team led by a skilled facilitator can create an Agile project roadmap in 2 weeks.  On the first day of Roadmap planning, we explain the approach, set the objectives, determine the customer journey and the feature roadmap and develop the design and technical briefs. Then we simultaneously design the product, the user experience and technical architecture. At the end of Roadmap planning, we bring it all together to estimate, prioritise the features and document our findings. 

The main activities are:

  • Define the challenge and discuss the approach
  • Define the project objectives and the key results expected
  • Define customer personas
  • Define the customer journey
  • Define the product feature map
  • Define the service blueprint
  • Define the current technical environment
  • UX sketching
  • Recruit customers for testing
  • Develop an architecture solution model
  • Define the technical POC
  • Define the UC POC
  • Define the product features
  • Develop UX wireframes
  • Develop the technical POC
  • Define the brand guidelines
  • Define the project risks and issues
  • Develop mood boards
  • Review and integrate the UX and Solution models with the product features
  • Develop interview scripts
  • Conduct UX testing with customers
  • Review the technical solution with architects
  • Review the UX findings
  • Review the features identified
  • Estimate feature value and size and team velocity
  • Develop a prioritised release plan
  • Write up the results as a detailed business case
  • Review the UX, Architecture and project plan with stakeholders

In my experience, an Agile Project Roadmap works best with a team of six to twelve people. Three to six people to run the process and three to six people to provide direction, share knowledge and make decisions. If you already have a delivery team for this product, then that team should do the planning with some help from experts. If you don’t have a product delivery team available or you haven’t set up the project yet, then you should bring together the people that you expect will be taking the project forward. 

I estimate that there are about 70 days of work in an Agile Project Roadmap spread across the team. The planning team should include a facilitator, designer, architect, business leader, business expert, technical expert and project manager. We can split each of these roles between two people if people are not available full time. For instance, the business leader who is the Project Sponsor could participate for 30 hours with the support of a Product Manager / Product Owner on their team who participates for 50 hours. And the UX/UI Design role could be split between a UX Designer and a UI Designer.

RoleHours Effort
Facilitator / Agile Coach / Business Analyst80
UX / UI designer80
Solution Architect / Dev Lead80
Project Sponsor / Business Unit Manager / Product Manager / Product Owner80
Subject Matter Experts80
Enterprise Architect / Integration Developer / Technical Domain Expert80
Project Manager / Business Analyst / Documenter80

Pitfalls to avoid

Traditional managers can inadvertently sabotage the Agile Roadmap by demanding all of the deliverables that they are used to in a conventional staged planning process. For example, they may insist on a detailed:

  • Business requirements document
  • Solution architecture document
  • Technical specification document
  • UI design document with finished wireframes and art assets for every page
  • Project Plan with a Gant chart.

Traditional managers may also try to turn the project roadmap into a fixed scope, fixed-price contract for the delivery of everything defined in the Project Roadmap without change.

You can combat these problems by bringing traditional managers into the planning processes and using your time in workshops to teach people about fixed price, fixed cost, variable scope delivery with agile teams and explain what the deliverables will be.

You may also have a problem with the behaviour of participants in the planning process. Some people may skip workshops or spend their time in the workshops on laptops or phones doing emails. The facilitator should bring this behaviour to the attention of the sponsor and the planning team, explain the impact and ask the group what they should do about it. 

What happens after the roadmap

After the planning team has developed the Project Roadmap, the sponsor can use it to request funding for product delivery. Or they may decide that the project is too expensive and they need to find a cheaper way to solve their problem.

An Agile Project Roadmap is not a one-time event that creates a fixed scope that must be delivered without change. A Project Roadmap is a living plan that evolves through continuous review and replanning at all levels throughout the lifecycle of the project. At the next level down, there is sprint planning, then acceptance tests, all the way down to continuous development, integration and deployment. If the team discovers that one of the assumptions in the Roadmap is wrong, then they change the plan to maximise business value within the time and budget available. It’s not plan-driven, it’s adaptive and evolutionary. 

Scaling Agile Project Roadmaps

You can use Agile Project Roadmaps to plan large programs by mapping out big chunks of work that can be done in 3 to 6 months and then planning each piece as a separate initiative. Research by the Standish Group shows that smaller projects are much more likely to be successful than larger ones, so it is always a good idea to break an extensive program into smaller parts. 

Scaling your program

Rather than starting a massive program in one go, it is best to start with one team, prove that it can deliver the value expected and then split it into two groups, which divide into four and so on through a process of mitosis.

You should split your teams so that each one has an external customer or an internal client. Some of these teams might deliver value to customers directly, while others provide platforms and features that support the business-facing product teams. The more independent the groups are, the better. Complex inter-project dependencies slow you down.

Growing your program over time substantially reduces risk and allows you to develop a coherent culture and strategy across teams.

Integration Team

In programs, an integration team manages the cross dependencies between groups by developing the integrated product, architecture, UX, project and budget roadmaps for the next six to 12 months. This team has a Product Owner, Project Manager, Agile Coach, Solution Architect, UX Designer and representatives from each of the individual groups. The integration team is similar to the one defined in Scrum Nexus but with a broader focus on budgets, resourcing, architecture and UX design. The integration team will lead the development of the Project Roadmap for new projects making sure to include the people who will deliver if it is approved.

Benefits 

Plan quicker, plan better.

Agile Project Roadmaps define an approach that a Product or Project Manager can use to quickly and effectively determine the product plan, solution architecture and project funding for a new project. With this plan, they can get budget and resources for the project, start earlier, deliver faster, increase customer satisfaction, reduce risk and realise benefits sooner.

Roadmaps put your customer at the centre of the project so that you can develop a solution that meets their needs. They allow you to define a realistic plan to deliver a valuable product quickly and efficiently, on time and budget. And they put you in control of the development process so that you get the best outcome from your suppliers or develop the project yourself. 

Agile Project Roadmaps cut your planning time and cost by more than 50%, allowing you to deliver benefits much faster and catch up when you’ve fallen behind. The chart below shows the plan for a mid-size website redevelopment compared to what usually happens and what could happen with an Agile Planning. As you can see by using Agile Planning combined with Agile Delivery, you can finish the project in the time it would typically take to plan it.

I have found this to be true in practice. For example, the Digital Director for a major car company we worked with told me that they saved 12 months and hundreds of thousands of dollars by doing an Agile Project Roadmap. The Project Sponsor for a Knowledge Management project at a health fund told me that we got further in 2 weeks than their IT organisation had done in the previous 12 months with a Water-Scrum-Fall approach.  

I have developed and evolved Agile Project Roadmaps over the last seven years for many large and small organisations. If you would like some help to implement this approach, let me know, and we will run it for you.

Murray Robinson is Managing Director at Ev0lve. If you would like to plan your digital service much faster with much less waste, you should contact us, or just learn more about Ev0lve, here.

References and Acknowledgements

Agile Project Roadmaps draw on ideas from a lot of different thinkers in the Lean, Agile, Scrum, XP, Agile Architecture, UX and Design community. I owe a lot to Kent Beck and Martin Fowler for Planning Extreme Programming, Mike Cohn for Agile Estimating and Planning, Jeff Patton for Story Mapping, Scott Ambler for Agile Architecture, Eric Reiss for Lean-Agile Product Development, Jake Knapp for Design Sprints, Jeff Gothelf for Lean UX and Henrik Kniberg for Scrum and Kanban in the trenches.

I would like to thank Dean Netherton for introducing me to Agile XP in 2004, to Ben Scown for helping me develop an Agile planning approach at Telstra in 2009 and to David Cox for introducing me to Design Sprints in 2016. I would also like to thanks the many people who reviewed and provided feedback on this article.

I hope that you find that the planning approach that I describe here provides you with a better way to initiate and plan an Agile project.

Agile Anti Patterns

When traditional organisations and managers embark on an agile journey they often apply agile with a traditional mindset that leads them to violate the agile values and principles. This article describes some of the fundamental agile anti-patterns so you can avoid them. An antipattern is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive.

While it is possible to give a list of common violations of the scrum rules as others have done, I will take a more fundamental approach and look at anti patterns from the point of view of the agile manifesto which defines what agile is.

Agile value anti patterns

Agile is a philosophy based on working together to uncover better ways of delivering value to customers. A good agile implementation is an evolutionary process tailored to the organisations context. Over time it may require major changes to the organisations structure, culture and processes.

One common anti pattern is to apply agile locally in the development team without the leadership support required to change the rest of the organisation. When the agile team is blocked by structure, culture, funding or waterfall processes the agile implementation stops and is often rolled back by command and control managers.

Another anti pattern is to take the agile ways of working developed by another organisation and apply it in a big bang, top down, cookie cutter change focused on cutting costs. This is a very disruptive, high risk approach that can cause a lot of damage before it pays off. If there is no real change in the way the work is organised those costs will come back somewhere else, usually as expensive consultants and contractors.

Processes and tools over individuals and interactions

Good agile teams focus on individuals and interactions. A common anti pattern is for Managers to use JIRA and daily stand ups to micro manage the team. Coaching groups become the new methods police dictating agile processes and tools. Real agile is about removing blockers and empowering teams with new ways of working so they can continuously improve.

Comprehensive documentation over working product

Good agile teams focus on creating valuable products instead of documentation. A common anti pattern is for agile teams to be embedded in a waterfall process that requires comprehensive documentation for downstream teams. If you want to get the benefits of agile you have to change your structure to allow teams to deliver a value stream from idea to implementation. Agile teams produce just enough documentation, just in time.

Contract negotiation over customer collaboration

Good agile teams co-design solutions with customers and partners throughout the product life cycle. But many agile teams never talk to a real customer. They rely on managers to tell them what the customers wants and they lock customers and vendors into fixed price, fixed scope contracts that cause adversarial relationships. Open up to collaborate.

Following a plan over responding to change

An agile organisation makes change easy so that teams can learn and adapt. A common anti pattern is for managers to demand that agile teams commit to a fixed scope, design, time and cost developed up front. Often organisations apply agile in their development teams and leave the rest of their waterfall process intact. Adversarial contracts and annual budget commitments prevent change and increase time and cost. Real agile teams do just enough planning, just in time.

 

Agile Principle anti patterns

Deliver value slowly

Good agile teams deliver valuable product features early and often. Unfortunately its still common for organisations to spend many months designing and planning a project before the agile team starts and then to deliver releases in big blocks every six to 12 months. To get the benefits of agile you need to apply it to the whole product development life cycle from concept to cash.

Prevent change or don’t control it

Agile teams work with stakeholders and partners to get the best business value possible from the time and budget available. A common problem is for managers to demand that agile teams deliver a fixed scope in a fixed time and budget. This forces teams back into waterfall delivery to defend themselves. On the other hand new agile teams can get confused about how to manage scope and end up going over budget trying to give stakeholders every little thing they asked for. This isn’t agile either.

Big bang delivery

Good agile teams deliver valuable products to customers every few weeks. A common anti pattern is for organisations to make agile teams deliver to downstream test, deployment and operations teams. This forces teams back into a big bank waterfall deployment every six to 12 months. In an agile organisation teams do their own test, deployment and operations so they can deploy to production every day if necessary.

Departments prevent collaboration

In an agile organisation stakeholders, partners and delivery teams work together in cross functional, co-located, client focused teams that deliver valuable products to production.

A common anti pattern is to implement agile in the software team while leaving everything else the same. This leaves all the traditional conflict, delays and costs created by a department structure and waterfall process in place.  It’s common in this situation for technical teams to appoint their own product owners because business people aren’t available to work closely with the team. As a result stakeholders lose confidence that the team are delivering what they want.

Command and control

Agile managers trust and support their teams. They explain the mission and ask the team to work out how to achieve it. They provide resources and remove blockers when asked.

An anti pattern is for managers to use JIRA and the agile processes to micromanage teams. Micro management forces people to spend a lot of time providing updates and justifying their approach when they could be doing work. It forces them to work at an unsustainable pace leading to serious quality issues and burn out. It turns teams into passive, stupid machines unable to take responsibility and  improve the way they work. Agile managers coach and support their teams, they don’t command and control them.

Poor communication

In an agile organisation people work in cross functional, collocated teams so they can have face-to-face conversations. If people are remote they are on persistent video conferences with the rest of the team.

A common anti pattern is for teams to be made up of people from different departments and companies with different interests and different values in different locations. Most communication is via documents, email, phone and video conference. The ball is dropped a lot. Leaders manage perception and hide issues so that things look better than they really are. Issues get worse until they blow up and cause serious damage.

Focus on tasks

Agile organisations measure progress by how much value they deliver to customers. Often organisations don’t understand or measure the value they deliver so they focus on measuring the number of features and stories produced. This turns the agile team into a factory mindlessly churning out features that managers want but customers don’t. Ultimately executives question the value of the team and remove funding because they cant see the value delivered.

Unsustainable pace

In agile organisations the work flows smoothly and people work normal hours. An anti pattern is for managers to drive the team to work long hours to meet impossible time frames developed up front. Product owners don’t prioritise the backlog and managers focus on maximising utilisation. High pressure, bottle necks and long hours lead to conflict, mistakes, poor quality, rework, long delays, high costs and burn out.

Technical Debt

Good agile teams invest in excellent technical practices and good design because it increases their speed, efficiency and flexibility.

An anti pattern is for agile teams to sacrifice design and technical excellence to rush through stories as quickly as possible. Often teams resist agile technical practices like XP, OODD, Refactoring, BDD and DevOps because they don’t understand them. This leads to rigid, poorly designed solutions with lots of defects, rework and technical debt.

Overly complex solutions

Agile teams deliver high value quickly by focusing on delivering the features that deliver the most value to customers. When they have tested these in the market they develop the next most important features.

A common anti pattern is for Product Owners to insist that 80% of features are must haves. Then designers and architects create a complex solution that delivers everything in one big, complex, expensive solution. The team doesn’t find out what customers really want until they have invested a considerable amount of time and money. Only then do they find that a considerable amount of their investment was wasted on things customers didn’t care about.

Micro management

Agile organisations structure teams so that they can take responsibility for designing solutions and delivering value to stakeholders. A common anti pattern is for teams to be set up so that they cant take responsibility for end to end delivery. In these organisations managers drive the team, run the meetings and manage dependencies. Managers use agile and JIRA to micro manage the team. Team members become passive, defensive and demoralized, robotically producing mediocre results.

Ignore important issues

Agile organisations continuously improve by collaborating regularly to identify blockers and resolve them. If the team cant resolve the issue themselves they ask managers to resolve it at the organisation level.

It’s a common anti pattern for managers to refuse to allow teams the time to hold real retrospectives.  It’s also common for major organisational blockers to remain unresolved because senior managers don’t want to admit there is a problem or do anything about it.  If individuals or teams raise issues to management they are ignored or punished. This often happens in organisations that have a culture of manipulation, favoritism and perception management. Eventually issues get so bad that they cause serious damage to the organisation. Real agile organisations discuss sensitive issues openly and honestly, resolving them quickly and rationally. If you’re organisation isn’t prepared to be honest agile may not be the right fit.

 

Conclusion

There are a large number of fake agile and bad agile implementations out there that don’t deliver the benefits expected. Often this is a transition stage from traditional ways of thinking to agile ways of working. The solution is to go back to basics and work together to uncover better ways of delivering value to customers using the agile values and principles. You can do it if you try.

Contact me on murrayr3128 at gmail dot com if you want some help.

 

Further reading

What’s Missing In The Agile Manifesto: Mindset

Breaking bad agile transformations in 5 minutes

Better outcomes in software development


https://dzone.com/articles/agile-antipatterns
https://ronjeffries.com/articles/016-09ff/defense/

Requirements are untested hypotheses about customer needs

In agile our highest priority is to satisfy the customer through early and continuous delivery of valuable products and services. We achieve this through rapid build, measure, learn cycles.

Research shows that 80% of features are rarely if ever used. Managers don’t know what customers want so they put in everything they think customers might want. This means that business requirements are untested hypotheses about customer needs.

Screen Shot 2018-12-20 at 1.45.01 PM

In agile we believe that simplicity is essential. If you can focus on what customers really want you can cut project time and cost by 80%. To achieve this you need to test your requirements and design concepts early and often.

No alt text provided for this imageThis is why you should be deploying to production every sprint. If you cant deploy a feature then watch how customers are using your product, show them a design concept or prototype and find out what they think.

Product Owner v Product Manager – what’s the difference?

Managing the development of new products and product features is a complex process, with multiple stakeholders and competing priorities. Often, in large teams, the role of product lead is split between Product Manager and Product Owner.

The roles can overlap, but the main difference is that the Product Manager is focused on product / market fit while the Product Owner is focused on getting the development team to build valuable product features.

Product Manager

The Product Manager is responsible for ensuring that the organisation develops and delivers a profitable product that meets the needs of the market. The Product Manager develops a product vision with customers and stakeholders and turns it into a prioritised, high level roadmap of activities that maximise business value. The product roadmap may include a mix of customer research, sales, marketing, feature development, training and process improvement activities.

Product Managers have a broad scope which means that they may not be able to give the development team the time and attention they need. In this case they may appoint a Product Owner to work full time with the Development team on their behalf. If they do this they should meet with the Product Owner every few days and attend the planning and review session with the development team every couple of weeks to ensure that the development team is prioritising business value correctly.

Product Owner

Product Owner is a role that was popularised by Scrum, an agile framework that helps you to develop valuable products in half the time. The Product Owner is the interface between business stakeholders, customers and the delivery team. Their primary goal is to maximize the value of the work done by the development team.

Product Owner is a full time job that requires skill in product management, business analysis, communication and project management. Located alongside the development team day to day, the Product Owner works closely with stakeholders to define the objectives, understand user needs and work out what features are required to improve the user experience and meet business objectives.

At the same time they work closely with the development team to rank the product features by business value, risk and dependency and analyse, design, develop and test the features in an incremental cycle, showing stakeholders what they have developed every few weeks.

Summary

The Product Owner is the critical role in an agile development team. A good Product Owner is customer focused, passionate, empowering, honest, analytical, detail oriented, decisive, available and engaged. It’s a fascinating role for a Product Manager, Business Analyst or Project Manager that provides considerable career growth for people lucky enough to do it.

5 ways to be an effective Product Owner

A Product Owner has the most important role in an agile team. Their job is to maximise business value by communicating the product vision, prioritising the product backlog and taking key stakeholders on the journey. Here are five tips to help you be a better Product Owner:

1. Advocate for the product

The Product Owner should be the champion for the product. They should know the product vision and details inside out so that they can communicate it to stakeholders and the team throughout the project and they should make sure that the team get the resources and information they need to maximise business value. The role of the Product Owner can be intense, as they’re pulled in many directions, but they should remain present and proactive, bringing clarity and direction to the project.

2. Adaptive planning

Effective Product Owners plan quickly and replan frequently. They do “just enough planning, just in time” because they understand that projects are full of assumptions about what customers want, what the business needs, and what the solution is. At the start of a project they develop a high level plan with the team in a few weeks so they can get started as soon as possible. Then they deliver in small iterations so they can test their assumptions and adapt the plan based on feedback.

3. Estimate business value

At the start of the project and at the start of each sprint the Product Owner should estimate the relative business value of the features and stories in the backlog. The Product Owner can use affinity estimation with key business stakeholders to quickly synthesize everyone’s views. When you know the relative size and value of the stories in the backlog you can organise them into releases that produce the maximum business value in the shortest time possible. Involve the technical team to ensure that they understand what the business priorities are.

4. Communicate with the team

Team effectiveness depends on good communication. To maximise communication the Product Owner communicates face to face with the delivery team every day. The best way to do this is to physically sit with the team to get involved in all the discussions that occur. When the Product Owner is communicating well with the team then the team can make good decisions about what they need to do to maximise business value and the Product Owner understands what support the team needs from the business.

5. Be decisive

The list of things that a team could do is always bigger than the list of the things they can do and this list increases as more people get involved with different priorities. The Product Owner is responsible for balancing competing priorities by constantly re-prioritising the product backlog. This means saying “no” to feature requests that have low business value. A Product Owner can deliver a product within the time and budget available if they are decisive about what features are in and out of scope. They understand that bad news delivered well improves relationships and increases trust.

Summary

The Product Owner is responsible for satisfying the customer by delivering a valuable product as soon as possible and then iterating on it to improve it. This is a leadership role where you have to say ‘no’; work within a budget; motivate teams and be across both the vision and the detail. These are just five of the many things a Product Owner could do to achieve successful outcomes in this challenging and rewarding role.

5 ways to increase your business agility

Agile is a new way of working that was created to address serious problems with the way work is traditionally done. First implemented in software development teams, the increased speed, productivity and customer focus that agile brings has seen it applied to all areas of business.

Below are a few ways to check if your business is truly agile:

1. Is your team customer focused?

Agile teams solve the customers’ problems, whether the customer is internal or external. They understand the customers’ objectives and have key performance indicators based on customer satisfaction and retention, not cost. Agile teams know that doing the right thing by the customer the first time leads to lower costs than doing the job wrong and then trying to fix it afterwards.

Product Managers have a broad scope which means that they may not be able to give the development team the time and attention they need. In this case they may appoint a Product Owner to work full time with the Development team on their behalf. If they do this they should meet with the Product Owner every few days and attend the planning and review session with the development team every couple of weeks to ensure that the development team is prioritising business value correctly.

2. Is your team able to solve a customer problem from end to end?

Agile teams contain all the different skills and functions required to solve a customer’s problem, from end to end. These people work together full time to continuously deliver outcomes that customers want. Cross functional, colocated teams are hyper productive because they remove waste, rework, delays and communication costs. An agile team that is developing a new product or service would be made up of people from sales, marketing, design, development, testing and operations colocated in one cross functional team.

3. Does your team make their work visible?

In a factory you can see the work people are doing and all the supplies and unfinished work that piles up. In offices you can’t see the work in progress which means that you can’t see the wasted time and effort in the system. Agile teams visualise the work on a scrum board or kanban board so that everyone can see what’s being worked on, what’s done and what’s next. When a team visualises their work they can manage it themselves without needing to be micromanaged. They can also see where there are bottlenecks in the system so they can fix them. This leads to faster and more productive teams.

4. Is your team regularly reviewing and improving the way they work?

Agile teams meet face to face every day for 15 minutes to discuss what they are doing and identify blockers. When they find a blocker team members help solve the problem. Every two weeks the team gets together with the client (internal or external) to review what went well, what didn’t go well and what they could do differently next time. This leads to gradual and continuous improvement in the way the team and the organisation works. Regular retrospectives are the core of agile.

5. Is your team testing and iterating?

The highest priority of an agile team is to deliver early and often.  Agile teams focus on delivering the simplest possible version of a product early so that they can deliver value quickly and get customer feedback early. Agile teams know that requirements are untested assumptions about user needs. The best way to deliver a high value product is by testing it early and often. If managers are expecting to deliver a rich, complex product in the first release then they are not adopting an agile mindset.

Teams that truly adopt agile are faster, more productive and more effective at meeting customer expectations. Agile workplaces are also more collaborative, cohesive and sustainable for those of us lucky enough to work in one.

The agile future of business

The age of the customer

We have moved from the age of manufacturing to the age of the customer. In this new age customers have more information and more choice than they’ve had before which leads to increased expectations.

In the past, businesses spent years designing mass produced products for a mass market and selling them through mass media. This no longer works. To succeed in the modern world, businesses need to quickly design tailored products for target markets, sell via two way conversations and use rapid feedback to continuously improve.

Fast-fashion brand Zara is a great example of a company that does this. Zara is surpassing competitors by releasing new items four to five times faster than a traditional retail brand. In just five days store managers, designers and commercialisation teams work with pattern makers, in the same office, to develop a concept and prototype a garment. In just two weeks, manufacturers make several thousand garments and send them to the logistics centre in Zaragoza, Spain, and from there the garments are flown to stores all over the world. This means customers can buy the latest fashion, from design to storefront, in less than a month.

How do businesses achieve agility?

Agility is a simple concept, but difficult to achieve in practice. Behind the scenes this fast delivery pace requires autonomous, empowered and cross-functional teams that are able to collaborate and adapt quickly to ever changing needs. This is where agile values, practices, and their associated benefits come in. No longer limited to software development, agile principles and tools are being applied across all aspects of the workplace to achieve faster outcomes.

Agile is fundamentally about breaking down silos and bringing people together into cross-functional, co-located, customer focused teams that can deliver solutions many times faster than before by being highly collaborative, iterative and focused. Agile methods are now used by many companies in non-technical areas such as legal, marketing, finance and customer-service areas of online companies. Companies that practice agile include Spotify, Microsoft, Google, CBAANZREA Group and SEEK.

In practice, implementing agile involves replacing slow business processes with new ways of working. Many organisations do the following:

  • Restructure their organisation so that work is done in cross-functional, co-located, client focused teams.
  • Leverage visual work tools, such as Kanban boards, to provide a shared understanding of the work in progress so that teams can swarm on bottlenecks.
  • Hold short, daily team meetings to communicate and identify if anyone needs help
  • Use two week sprints to plan and complete work.
  • Create the minimum viable product (MVP) necessary to test customer demand before investing heavily in new products.

How do businesses manage agile teams?

Managements teams need to ensure that their structure and key performance indicators reward this new way of working. Teams need to be rewarded for experimentation, learning and the delivery of business value rather than the delivery of documents. They need to know that it’s better to find out that you’re wrong with an early version of a product, than it is to find it out after huge investment of time and money.

Agile is an approach that can deliver substantial value in many areas of a business, not just software development. As we move towards an agile business future, executive, HR and marketing, to name a few, have successfully implemented agile and accelerated profitable growth.

Learn more about Silicon Block agile courses.

Speak to an advisor

How to be a good leader

We have all had good leaders and bad leaders in our careers and often people who are a mix of both. Unfortunately there seem to be far more bad leaders than good ones. This really isn’t acceptable because leadership has a big impact. Good leaders help us do our best work while bad leaders stress us out and make it difficult to do good work. Fortunately you can learn to be a good leader with coaching and experience.

As part of IE’s agile training I asked people to take part in a retrospective on managers and leaders during their careers so that we could define what it takes to be a good leader. This is what we came up with.

1. A GOOD LEADER SUPPORTS PEOPLE. A BAD LEADER BLAMES PEOPLE.

Good: encourages, supports, defends and rewards good work.

Bad: negative, complains, attacks and blames.

2. A GOOD LEADER GROWS PEOPLE. A BAD LEADER UNDERMINES THEM.

Good: coaches and trains, shares the glory, gets the best out of people and helps people move to a better role.

Bad: takes credit for other peoples work, blocks training and blocks career moves.

3. A GOOD LEADER LISTENS. A BAD LEADER SHOOTS THE MESSENGER.

Good: encourages people to raise issues, discusses issues and happy to be wrong.

Bad: doesn’t listen, shoots the messenger and has to be right all the time.

4. A GOOD LEADER ACCEPTS RESPONSIBILITY. A BAD LEADER REJECTS PROBLEMS.

Good: accepts issues, takes ownership of problems and discusses difficult issues with people.

Bad: refuses to admit there are problems, won’t take responsibility for problems and refuses to discuss difficult issues.

5. A GOOD LEADER RESOLVES ISSUES. A BAD LEADER LETS ISSUES GROW.

Good: resolves issues blocking the team, resolves conflict, calm under pressure and says no when required.

Bad: doesn’t resolve issues blocking the team, doesn’t improve team methods, doesn’t resolve conflict, is afraid of upsetting people and doesn’t challenge broken systems.

6. A GOOD LEADER IMPROVES THE WAY THE WORK IS DONE. A BAD LEADER MAKES IT HARD TO DO GOOD WORK.

Good: understands the work, helps improve the way the work is done, challenges bad rules and poor practices, streamlines administration, makes good decisions and helps their team efficiently produce high quality work.

Bad: doesn’t understand the work, doesn’t provide enough resources to do the work, gets in the way of people doing the work, forces people to comply with stupid rules and bad practices, increases administration costs, makes poor decisions about the work and makes their teams slow and low quality.

7. A GOOD LEADER DELEGATES AND COACHES. A BAD LEADER MICRO MANAGES.

Good: delegates, empowers, coaches, mentors and teaches.

Bad: micromanages, doesn’t trust anyone, demands frequent detailed reports, wont delegate and doesn’t coach.

8. A GOOD LEADER IS OPEN AND HONEST. A BAD LEADER IS MANIPULATIVE AND UNTRUSTWORTHY.

Good: open, honest, encourages discussion, doesn’t tell you what you want to hear and leads by example.

Bad: manages perception, denies involvement in decisions, is deceitful and deceptive, breaks promises and says one thing and does another.

9. A GOOD LEADER CARES. A BAD LEADER IS SELFISH.

Good: understands people, cares about people, builds relationships, leaves their ego at the door.

Bad: feels entitled to power and privilege, is jealous of others, doesn’t care about people and treats people like tools.

10. A GOOD LEADER IS CALM AND ORGANISED. A BAD LEADER IS CONFUSED AND DISORGANISED.

Good: calm, organised and clear.

Bad: disorganised, poor briefing, sudden urgent tasks and frequent changes in direction.

How to reduce waste in IT – Waiting Costs

article-2255693-16B57A8C000005DC-948_964x647[1]

Waiting costs time and money. When customers have to wait for a product or service they are spending time and resources they could have used for something else. This means that the total cost of a product to a customer is the direct cost plus the cost of waiting. The more time you make customers wait the more expensive your products and services are.

waiting cost2

It’s the same for employees and internal customers. The total cost of a product or service to an organisation is the direct cost plus the cost of waiting. When employees have to wait for the instructions, permissions, parts or tools they need to do their job then the organization ends up paying them to do low value activities when they could be adding value to a customer.  So the cost of waiting comes straight out of profit.

When waiting becomes a regular problem people respond by hoarding which increases cycle time and inventory which increases waste further.

The causes of waiting

Waiting is caused by bottlenecks in the system which are in turn caused by a poor system and by a failure to provide the people doing the work with the information, parts, tools and resources they need.

In command and control systems senior executives usually don’t consider waiting costs because they are too far away to see them and aren’t measured on them. As a result they drive internal and external suppliers to provide products and services at the lowest direct cost even if it causes delays. One of the main ways to do this is to centralise work into large batches and send it offshore to the supplier with the lowest labour costs. The problem is that this creates major communication, quality and alignment bottlenecks which lead to high waiting costs across the organisation.

For example a high quality in-house or outsourced IT team can usually deliver a fully configured and installed test server on site for a development team in a few days for $10K with only a few hours of client input. In comparison a big low cost offshore service provider might be able to do the same thing for $7K due to low labour costs. If you install a lot of servers it would seem like you could save a lot of money by outsourcing it all to one of these big offshore companies.

The problem is that it often takes a low cost provider six to twelve months to deliver, configure and install a test server. For example one large multimillion dollar project that I was involved in was delayed because the infrastructure provider said they would be able to deliver the environments needed in six months and then took nine months to deliver the test environments and fifteen months to deliver production environments. While the team of 80 were waiting they minimised the impact by escalating to management, developing work-arounds and doing any work they could. As a result the project was delayed by six months and went over budget by more than a million dollars which was a lot better than it could have been. This is unfortunately a common experience in large organisations which happens when management don’t count the cost of waiting.

Some other common examples of waiting in IT are:

  • waiting for stakeholders to provide feedback on requirements;
  • waiting for the architecture team to review the design;
  • waiting for management to provide approval to proceed through a stage gate;
  • waiting for management to provide funding for the build phase;
  • waiting for procurement to approve a vendors statement of work;
  • waiting for another team to change a shared component;
  • waiting for defects to be fixed that are blocking a test module and
  • waiting for a deployment window.

How to reduce waiting costs

In free market economies decisions are made locally by the people impacted by them. To these people waiting costs are obvious and serious. When stakeholders and employees can choose between suppliers then they will choose the one that has the lowest combination of direct costs and waiting cost. These decisions drive down waiting costs across the organisation. As a result one of the best ways to drive down waiting times is to push resource and supplier decisions down to the users of those suppliers.

Another way to reduce waiting times is to implement the Plan Do Study Act cycle to remove blockers and streamline your work. That is to: study your process to identify issues causing delays, plan changes to resolve these issues, act to implement these changes and check the impact of these changes on cycle time.

deming_pdca_cycle[1]

 

Control charts are an important tool to help you study delays in your process. Control charts measure the time it takes to complete a cycle of your key business processes for software development and infrastructure delivery from you’re stakeholders point of view;

waiting cycle time2

Cumulative flow diagram’s are another useful tool which helps you identify which part of your process is slowing progress;

waiting cfd

Once you’ve identified the area where delays are occurring you can address it by using the following techniques.

  • Allocate more resources to the bottleneck area to increase it’s capacity;
  • Put in place a buffer before the bottleneck to make sure that it doesn’t run out of work;
  • Stop previous processes from increasing the queue of work for the bottleneck station;
  • Reduce batch sizes to improve flow through the bottleneck;
  • Use daily scrum meetings and visual project management tools such as Kanban boards to ensure that everyone is clear on what they need to do each day;

You can also increase the speed of the bottleneck station by using “Five S” to reduce wasted motion.

  • Remove all steps that add no value to internal and external customers;
  • Streamline the work process to remove any unnecessary effort;
  • Develop Standard Operating Procedures to reduce time and improve quality;
  • Continually improve the standard procedure;
  • Implement reviews and automated acceptance tests to improve reliability and quality;

Waiting is a major cost to organisations that can easily out way any benefits gained from driving internal and external suppliers to drive their costs down as low as possible. To reduce waiting costs measure them, push decisions down to users and implement the PDSA cycle.  This is well worth doing.

 

How to reduce waste in IT –Wasted Motion

In manufacturing wasted motion is any movement by a worker or machine in a work space that does not add value to the customer. It includes searching for instructions and tools, retrieving parts, making and modifying parts and rotating or twisting during assembly. Wasted motion reduces efficiency and increases wear and tear which causes injuries and breakdowns.

Since 1900 industrial engineers have made huge improvements in production efficiency by using assembly lines and time and motion studies to reduce the time and effort it takes for workers to do their work. This approach led to the modern industrial era of low cost, mass production, commodity goods.

assembly line

In IT wasted motion is any effort by the IT team that does not add value to an internal or external customer. It includes things like working off old version of documents, fixing defects, creating documents instead of code, deploying software changes manually and waiting for a server.

Wasted effort is ultimately caused by uneven work flow and unreasonable demands.

In Lean production you reduce wasted effort by applying a process called 5S or CANDO. At first this approach doesn’t seem to apply to IT but when you translate it from a physical space to a virtual one it has a lot of value.

5S

Sort or Clean up.

Remove everything not needed in the work space so you can find what you need easily. In IT you can apply this by regularly archiving old versions of documents in your file system and refactoring your software to make it easier to understand and change.

Streamline or Arrange.

Organize your work so that it flows smoothly and consistently without waste, defects or delay. Define your end to end business process from the customer’s point of view and track your work on a Kanban board. Work in small batches. Set up cross functional teams and keep them together. Use Scrum and XP. Use acceptance test driven design and development. Automate software builds, tests and deployments.

Shine or Neatness.

Review your work flow regularly to maintain standards. Build review steps into your business process. Get testers to review requirements and design before you build and get developers to review each other’s code before you deploy to test.

Standardize or Discipline.

Develop common standards and ways of working. Develop and use standard business processes, templates and coding standards. Develop checklists for code reviews and new accounts.

Sustain or Ongoing Improvement.

Use standard methods and continually improve them. Set time aside to write down your methods regularly, train new people in them. Encourage people to experiment with methods and improve them.

The dangers of over optimizing

In the service sector many companies have adopted an assembly line approach to cut costs so they can be more competitive. This approach often leads to a situation where you have to wait a long time for a service only to find that it doesn’t do what was promised and costs more than expected. When you follow up it’s common to get pushed from one person to another with no resolution to your issue and no updates on what’s going on. This happens because it’s possible for one step in the process to reduce costs by cutting staff so much that it increases time and costs for the customer and other steps in the process.

To avoid these problems we need to make sure that when we are reducing wasted time and effort in our own step we increase the value of the end to end business process to the customer not decrease it.