5 Levels of Agile Planning


Within Agile, planning is done continuously. Planning is about working out what to do, and that must come before working out how long it will take.

In this post I would like to present a process that will allow team members to understand the whole sequence of planning from vision to user story.

5 Levels of Agile Planning

Level 1, Vision:

Every product needs a vision, a destination postcard that will guide the team towards the goal. The vision also helps to have a keen eye for opportunities, to focus on value (to the user and business) and return on investment (ROI). Every decision is taken with the product vision in mind. This ensures clarity for the development team and increases the chances of success.

Level 2, Roadmap:

This is a long-term product strategic roadmap (from 3 to 6 months max), this can also be explained by de-composing the vision into phases in a logical order. The roadmap will help to see how the product would evolve.

Note that it does not usually make sense to make a plan based on user stories that go further out than three months. Beyond this point, use a road map based on story themes.

Level 3, Plan Releases:

If the roadmap gives the phases, the release plan de-composes each phase into sprints. These sprints are conditioned by the roadmap; market conditions the status of the product. The product backlog consists on more than only features, for example: technical requirements, bugs, defects, spikes, non-functional requirements that should be taken into account.

Backlog refinement is very important, this must be granular and well understood by the whole team.

Level 4, Sprint Planning:

During the sprint planning the team plan and agrees the prioritised product backlog stories they are confident they can complete during the sprint and help them to achieve the sprint goal.

Here are 3 basic steps to create a plan:

  1. Understand priorities: Start with the team a conversation about the user stories the product owner would like to get in the next iteration to release.
  2. Size the work: 
When the stories are understood, help the team work out what needs to be done to deliver the stories.
  3. Agree on the plan: 
Wrap the meeting up by getting agreement on what can realistically be delivered.

Level 5, User Story:

If the team members want to deliver valuable software, they need to go the extra mile to understand both user and business benefits, and user stories help them do that. User stories underpin all the work an Agile team does, they are the basis of plans, development and testing.

The whole point of user stories is to ask questions to better understand what users need and to find ways of breaking requirements down. Break the tasks into smaller pieces so that everyone has a deliverable every day.

User stories are a simple technique that a team can use for understanding their customer through talking about what users need.

The main point is that Vision must drive decisions and User Stories are the means to achieve that vision.

Better Performing IT Results in Better Business Value


IT performance and well-know DevOps practices, such as those that enable continuous delivery, are predictive of organisational and business performance.

DevOps

How IT performance is measured? the most used criteria is measured in terms of throughput and stability. The individual measures that make up IT performance are:

  1. Deployment frequency
  2. Lead time for changes
  3. Mean time to recover from failure

Bear in mind DevOps has always been about culture, not just about tools and processes. Healthy cultural practices and norms that characterise high-trust organisations are required for the successful implementation of agile methodologies, these are: good information flow, cross-functional collaboration, shared responsibilities, learning from failures and encouragement of new ideas.

Practices Leading to Increased Deployment Frequency

  1. Continuous delivery ensures that your software is always in a releasable state that can be performed on demand.
  2. Capability for easily recreate environments for testing and troubleshooting.

Practices Leading to Reduced Lead Time for Changes

  1. Version control as the ability to get changes into production repeatedly in a reliable, low risk way.
  2. Reliable and comprehensive set of automated tests, so code is releasable without lengthy integration and manual regression testing cycles.

Practices Better Mean Time to Recover

  1. Version control, when an error is identified in production, devs can quickly either redeploy the last good state or fix the problem and roll forward.
  2. Monitoring system and application health so is easy to detect failures and identify the events that contributed to them.

Implementing continuous delivery means creating multiple feedback loops to ensure that high-quality software gets delivered to users more quickly. Continuous delivery requires that developers, testers, designers and UX, product and operations people collaborate effectively throughout the delivery process.

Continuous integration is a development practice whereby developers routinely merge their code into build servers with version control systems. Each change triggers a set of quick tests to discover serious regression, which developers must fix immediately.

Six Recommendations to Apply when working with DevOps:

  1. work with other teams and build empathy, build bridges, understand challenges and put yourself in the shoes of the others
  2. build trust between teams, trust is built on kept promises, open communication, and behaving predictably even in stressful situations
  3. actively seek, encourage and reward work that facilitates collaboration, make sure success is reproducible
  4. learn by sharing knowledge & create opportunities and spaces to share information
  5. create a training budget, and advocate for it internally
  6. make it safe to fail

Read more: Puppet Labs. “2014 State of DevOps Report“. PDF report.

What is Digital Disruption and How Companies can Embrace it?


Today the only source of competitive advantage and value delivering comes from seeing what customers need and delivering it.

Digital disruptors are changing complete industries, delivering value at a lower costs, with faster development times and with greater impact on customer experience.

Digital disruption

Digital disruption is simply a mindset that leads to a way of behaving; a mindset that bypasses traditional off-line obstacles, eliminating the gaps and boundaries that prevent people and companies from giving customers what they need in the moment that they want it.

Digital disruptors are obsessed with measuring results and rapid innovation cycles in which failure and mistakes are viewed as feedback.

Always evaluate your customer, benefits, business and product

  1. Customer: isolate the core target customers and make some smart guesses about what makes them tick. Ask yourself what your target customer really needs
  2. Benefits: what is the next thing that customer needs?, express the need in terms of what the customer will get out of the deal if you succeed.
  3. Business: what will we get out of it if we innovate?
  4. Product: the art of harmonising Customer, Benefits, Business and Product into a single approach

In other words, you need to focus on creating innovations that are most likely to give the consumers you want to reach the benefits they really desire while achieving strategic outcomes that are meaningful to the organisation.

How to deal with digital disruption inside a large company?

  • Create small innovation teams
  • Identify silos and break down the boundaries between them
  • Get senior executives to commit their support
  • Insist on short development time frames

Digital disruptors constantly seek for the adjacent possible:

  • Asking a simple question “what is the next thing my customer needs?
  • Iterating so quickly from one adjacent to the next
  • Giving the customer the next logical thing, or things

Digital disruptors keep the scope of their innovations small. Rather than creating a five-year innovation plan, digital disruptors proceed from adjacent possibility to adjacent possibility, occasionally failing, but failing so quickly and so cheaply that recovery can be nearly immediate.

Read more: James McQuivey. “Digital Disruption: Unleashing the Next Wave of Innovation“. Amazon Publishing.

How Leaders Create Conditions for Change


Leaders can not dictate the culture, but they can nurture it. they can create the right conditions for change, creativity and innovation. Leader can multiply the effect of a team. Liz Wiseman interviewed more than 150 leaders to research her book Multipliers: How the best leaders make everyone smarter.

Leading a team

Leaders who are multipliers can double the output of a team or a company and improve morale in the process, here is how you can become a multiplier:

  1. be a talent magnet, who attracts and retains the best people and help them to reach their highest potential
  2. find a worthy challenge or mission that motivate people to stretch their thinking
  3. encourage debate that allows different views to be expressed and considered
  4. give team members ownership of results

Basic group dynamics

  • great groups believe they are on a mission beyond mere financial success, they believe they will make the world a better place
  • they are more optimistic than realistic
  • they ship
  • belonging to a strong creative group can be one of the most rewarding aspects of working life

In Agile, What to do if Team Velocity is not as you Planned?


If after three or four sprints you notice your velocity is not where you had hoped it would be, do not panic. This might happen, this is why you need to set expectations accordingly and told your client not to trust your initial plans. The good news is that by the time you know about it, you can adjust course as necessary.

Team velocity

Being flexible about scope is the preferred method for restoring balance.

The important thing is to have the conversation and give your client some options. Yes, this may make you uncomfortable, but you can’t hide this stuff. Bad news early is the agile way.

There is one strategy for ensuring that when you do have the “too much to do, not enough time” conversation:

If you can’t deliver a minimalist version of the application with the time and resources you have got, then the plan is clearly wrong and needs to change.

It works like this:

  1. take one or two really important features for your project (something core that goes from end to end through your entire architecture) and
  2. measure how long it takes to build a minimalistic version of those features

Then use that against your remaining relatively sized stories to see whether a minimalistic version of the application is even possible with the time and resources you have.

If your dates are looking good, right on, if your dates are looking bad, great, at least you know about it now.

When you need to change the plan conversation from, It is not based on wishful thinking. There is no need to get emotional, it is just the facts. It is better to know this now than later.

In Agile, How to Handle New Client Requirements?


When your customer discovers what they really want in their project, ask them how they would like to handle it. You can push out the release date or add more resources (which is like saying we are going to need more money), or you can drop some of the less important stories from the to-do list (preferred).

Managing change requests

Don’t get emotional when you have this conversation. It is not your call to make. You are simply communicating.

Your responsibility is to:

  1. make them aware of the impact of their decisions and
  2. give them the information they need to make an informed decision.

If your client really wants it all, create a nice-to-have list and tell them that if there is time at the end of the project, these are the first stories you will do.

But make it clear, the nice-to-haves are currently off the table and are not going to be part of the core plan.

How to move a slow project to Agile?


You are running a project that is not going well, progress is not as planned, confidence on meeting a deadline is low, what you are currently doing is not working and you need to get something out of the door fast.

You have read about agile and understand the benefits of this way of delivering, but you are already in the middle of the project and do not know how to transition your slow motion project into an agile one.

Project Management

How to transition a slow motion project into agile?

1) You need to make sure everyone is on the same page

  • Why you are there
  • What you are trying to accomplish
  • Who’s the customer
  • What big rocks you need to move
  • Who’s calling the shots

If there is any doubt about these, ask the tough questions and get some alignment.

2) You need to start delivering

If you have to ship something fast, throw out the current plan, and create a new one you can believe in. Just as if you are creating a new agile plan from scratch, create a to-do list, size things up, set some priorities and deliver the minimal amount of functionality to get something out the door.

If you need to show progress but have to work within the confines of your original plan, start delivering something of value every week.

Take one or two valuable features each week and just do them completely. Once you have shown you can deliver (and regained an element of trust), slowly rework the plan and define a release based on your now measured team velocity and how much work there is remaining.

Then simply keep delivering until you have something you can ship. Update the plan as you go, execute fiercely, and use the sense of urgency you have been giving to blow through anything standing in your way.

5 Delivery Principles for a Digital Team


Too many of digital projects do not work well, are delivered late, over budget or not fit to purpose. To increase the success rate of these projects, there is the need of a new approach.

1. Put users’ needs first

The products and services you deliver should be driven by the needs of your users, not what suits you as providers. This means you need to invest time and effort to regularly engage with users and the contexts in which they interact with what you produce.

2. Make decisions based on data

Simply stating a user’s needs is insufficient, you need to counsel these needs with sound qualitative and quantitative data, and use that data to make objective decisions about what to deliver and when. Data is not making choices easier, but it will help you to take better decisions.

3. Release iteratively and often

Stop doing ‘big’ releases, these tend to frustrate users and put at risk the organisation. Work Agile, start small with the minimum viable product, test it and release it as soon as possible on a timescale of days and weeks, rather than months or years. Repeat the process many times over, adding to your products and services based on feedback, tests and changes to technology.

4. Keep it simple and consistent

You will do the hard work not to over-think or over-complicate things. Whether a user is new or experienced, task-driven or browsing, they will able to get started quickly, flow through the process with ease and trust the integrity of the results. Keep always usability in mind.

5. Do the hard work behind the scenes

Great digital product or service doesn’t rest entirely on what  appears on-screen. Your work doesn’t stop when you send something live. Care about the running of products and services, from their discovery, development and throughout the time they are operational.

If you want to know what other organisations are doing, the U.S. Digital Services Playbook is a fantastic read.

Agile Product Development


In agile product development is very hard to have the best product right away, so commit to rapid and continuous improvements is the way to go. Of course, the messiness of trial and error may seem uncomfortable, but action allows us to learn at a faster rate.

In agile product development avoid the paralysis by analysis
In agile product development avoid the paralysis by analysis

The following insightful story comes from the book Art & Fear by David Bayles  and Ted Orland.

A clever ceramics instructor divided his pottery class into 2 groups. One half of the students would be graded on quality and the other half would be grade on quantity.

Thought out the course, the “quality” students funnelled all the energy into crafting the perfect ceramic piece, they studied the right mix of materials, the correct measures, weight, optimal temperature, did an extensive research and produced one “perfect” product.

While the second half students do not care about the “perfect” product, but produced pots in every session non stop.

At the end, although it was counterintuitive to his students, you can guess how his experiment came out at the end of the course, the best pieces all came from students whose goal was quantity, the ones who spent the most time actually practicing their craft.

This lesson is applicable to a much broader view, if you want to make something great, you need to start making. Looking for perfection can get in the way during the early stages of the creative process. Do not get stuck in planing and start acting.

All the over-planing, talking are sings that we are afraid, that we don’t just feel ready;  that tendency leads us to wait rather than act, to perfect rather than launch.

* Image credit istock.com

Digital Project Management and the 5Ds


The 5Ds in project management is a phase breakdown of large milestones that every project team needs to complete. This model gives a full vision of the tasks and deliverables for each phase.

This process is thought with Agile / Scrum Project/product methodologies in mind.

We call these phases the 5Ds:

Digital project management 5ds

Discovery: validates the business reason to kick-off the project, the benefits can be to revenue growth, cost reduction or risk management. Depending of the benefits these can also be short, medium term or strategic.

  • Define business value
  • Target market
  • Competitive analysis
  • Deliverable: Business Case

Definition: once the management team validates the importance of the project, a clear functional definition is required in order to specify the right set of user, features and business requirements.

  • Define personas
  • User stories
  • Technical dependencies
  • Information Architecture
  • Core functionality
  • Deliverable: User Stories and Product Technical Requirements Document 

Design: gives not only the look and feel to the solution but also aligns user and business requirements with the user experience. Why this is important?, imagine a disruptive user experience, this will affect the engagement and traffic to the Live solution and this at the end will put off advertisers, can you see the picture?.

  • Paper prototypes / sketches
  • Wireframes
  • Usability evaluation
  • Visual design explorations
  • Visual design approval
  • Deliverable: User Interface (UI) Designs

Development: the development, QA and product/user team start working every day, moving stories from backlog to the sprint and working together from technical analysis, development, quality assurance and user validation, this is an iterative process and is the core of the Agile methodology.

  • Architecture design
  • Daily scrum
  • Code iteration cycles
  • Usability evaluation
  • Release management
  • Unit testing
  • Code refactoring
  • Deliverable: Working solution and source code

Deliver: when the final user validates the solution, technical team performs performance testing and release plan, the full working solution is ready to be deployed to Live.

  • Case testings
  • Test reports
  • Build releases
  • Deliverable: Shippable release 

Remember that the project doesn’t finish when is released, the market will give important product feedback and is the job of the Agile product team to constantly improve the product by always aligning user experience and business objectives.