14 steps towards Thriving with Agile in a Major Corporate

For years now, I have been working in and trying to enhance the way in which Agile plays out in the corporate setting. This write up is intended as a guide for those who want to make sure that they aren't compromising on Agile philosophy (or end up doing "Half-Agile") whilst also acknowledging the realities of working within a big company environment. Let me also be clear about what this isn’t supposed to be: This isn't an exposé on how to become an Agile company/ team or the role of a Scrum Master or Product Owner. I assume you're already there with those and convinced of the benefits, but still interested in getting things running smoother; knowing how to manage all the stakeholders – which you have in a “big” setting. (For articles on how to become Agile or the benefits of Agile you should start with the Agile Manifesto and then look to Mike Cohn’s blog on the Mountain Goat Software website, or follow the likes of David Hicks (from Agile8, London) or Jeff Sutherland (co-creator of Scrum) on Twitter. 

Agile is easy in a Garage. It’s you and the two others. Once you’ve brewed the coffee, eaten your #SmashedAvo on gluten free toast, switched on the heating, and powered up the laptops you have your stand up and off you go... So when, you're operating in a corporate giant do you have to compromise and accept "Half-Agile"? 

Agile is easy in a Garage. It’s you and the two others. Once you’ve brewed the coffee, eaten your #SmashedAvo on gluten-free toast, switched on the heating, and powered up the laptops you have your stand up and off you go. Agile works really well in this environment. It’s all about releasing early (showing each other [and your end users!] little snippets of innovation) and collaborating as much as possible (rather than sending off your requirements to “the IT department” and getting something back in 6-12 months time). Transparency of what everyone is working on is pretty easy – maybe you even have a homemade Kanban board up on the wall (or simply gaffer tape + post it notes against the brick work). You test and learn daily, pivot quickly and stay connected. There is no “them and us” it is the team. You’re all in it together. 

So when, you're operating in a corporate giant do you have to compromise and accept "Half-Agile"? When you operate with Departments and Org charts, how do you keep it up? Can you still be purist in your approach to Agile but also work within the matrix? I believe you can. From 6+ years of being involved in and leading Agile teams at big blue chip companies, over the last 18 months I have developed a 'Team Process Flow', and within it are 14 steps towards thriving with Agile in a major corporate setting, spread over five phases:

1. Are we designing the right thing?
2. Are we designing the thing right?
3. How will they experience it?
4. Are we building it right?
5. Did we build it right?

Here is the Team Process flow diagram, that you'll soon see the 14 steps and 5 phases relate to.

1. ARE WE DESIGNING THE RIGHT THING? 

The first phase is: 'Are we designing the right thing'. Easier said than done? Here are the first three steps:

Step 1: Gathering Insights & Assumptions

Are you designing "inside out or outside in?". Too often in blue chip companies we believe our own hype and think about what we have that we can sell to someone rather than asking “what is this needed?” So, where do you get your inspiration from? 

"our highest priority is to satisfy the customer"

This isn’t strictly an Agile stage or phase – but principle one in the Agile Manifesto states that “our highest priority is to satisfy the customer" through early and continuous delivery of valuable software”. It sounds obvious (hopefully!) but make sure you get out there and talk to or observe your users and target market before you start designing products for them. Who are they? What do they do? What do they need? What pain points do they have? (For a great insight in to some different techniques you can watch this Google Hangout I recorded when some of my team had the opportunity to meet Chris Earney, the Co-Lead of Innovation at the UNHCR... the topic of conversation was 'User Testing in extreme locations'. 

You might think that the topic isn’t relevant, think again! We compared the techniques and testing needs he described to what we do in my Digital teams today, and all the UNHCR's approaches but for maybe the requirement to be able to “air drop the refugee shelters from a Chinook helicopter”, were 100% applicable and adoptable by our team.

Let me tell you that when you create a “nice to have” or “not needed” product, it is really hard to sell and get users to adopt it. It’s the easiest way to waste (often) millions of dollars in a short space of time! So, once you have listened or observed your target audience make sure you step back and think about whether your insights fit with your assumptions? Are there any trends that you can relate their behaviours to, externally, that support the direction of travel? Often the external trends, matched up with user behaviour give rise to some really exciting new ideas! Get your observations up on a wall, so that you can see them all in one glance. Spreadsheets are fine but walls with lots of post its that you can move around, group, write over, draw lines between, is much more helpful at this stage.

Spreadsheets are fine but walls with lots of post its that you can move around, group, write over, draw lines between, is much more helpful at this stage.

This might mean you needing to have a dedicated space where you can leave things up for extended periods of time. A ‘war room’, ‘scrum room’ or ‘innovation space’ will be invaluable every day for stand-ups, retrospectives, impromptu meetings, whiteboard sessions, presentations to stakeholders, reviewing wires/ designs, getting feedback on your product so, don’t think it is just for step 1. Another key part of the Agile Manifesto is: "Build projects around motivated individuals. Give them the environment and support they need". If you are reading this as a Leader trying to empower Agile teams, then this is a key part of it! At the end of this step you should be confident in articulating what your users need, and preferably in a priority order.

Step 2: Develop a Strategy & Vision of the future

So, you have your prioritised user insights, and matched them up with the rapidly changing world, and validated them. How does what you've learned from users apply to the skills and resources you have available? How are you, as a company or organisation, uniquely positioned to make a difference in the moments that matter to the target audience? Can you create some unfair advantage that will help you stay ahead of the traditional competition and the new challenger brands coming in to your market? This may involve things like skills, teams, relationships, contracts, partnerships, or intellectual property that can't be easily replicated. I’m not going to go in to how to write a slide deck, but you should be able to articulate, at the end of this step, how what your users want relates to the company and how you think you can best deliver against the needs. Test this with a few people before you take it to stakeholders. Ask questions like:

• Does the story make sense?
• What’s missing for you?
• Can you see how the revenue model would work?
• What else do you want to know? 
• Would you buy it?
• Do you think we can deliver this?
• What are the key risks you can see?

Ask them to be ruthless, you do not want to be debating any of these things in front of senior stakeholders who will (and should be) ruthless in terms of prioritising their investment dollars.

Step 3: Develop (and prioritise) a set of HLBNs

Once the strategy is validated you need to write your initial list of High Level Business Needs (or requirements). Group your observations from step 1 and start to articulate needs that the observed group has.

Organise the needs under Themes (Log in, Reporting, Data, Marketing etc). There are no hard and fast rules as to how to start to write them, so if you don’t want to write them in a set format initially, just get them out however you can articulate them. This is a great opportunity to get your internal stakeholders involved, to help them feel ownership. The important part is going to be the discussion around them. There is certainly no need to get technical at this stage about how you will deliver them. That comes much later! Right now it is purely about describing the things a user wants to be able to do. Remember to think about the needs from all angles. What does the Accountant want to know? What does the data or compliance officer want in the backlog? Below is a picture of one of such 'events' that we organised recently, including plenty of stakeholders.

Getting small teams focused on defining parts of your product (over a day or two), and then getting experts (from outside the process) to come in and challenge them (say, every 3-4 hours), can be a way to keep the team focused on producing value in short time-boxed periods, but also avoiding tunnel vision during the innovation process.

Step 4: Get early consumer validation (or feedback)

Once you have this list of HLBNs, test them. Find a way to share them back with the target audience who you observed and check that they are really correctly expressed. This is one of the earliest 'Test and Learn' opportunities you have. You will quickly learn what's missing. Don't skip this phase, you'll get in to tunnel vision, and start believing your own hype. How many people should you talk to? Try 8-12. Typically once you reach these sorts of numbers the feedback starts to repeat.

Whilst user testing is a whole other topic in its own, some simple ideas to get feedback on your list could be: (1) Ask them to draw pictures of what it could look like - it will generate a whole new level of insights, and will tell you what they value most. Ask them what they drew (get them to describe it) and why they put 'x' feature in 'y' position; (2) If you think your users might get stage fright when you give them a pencil and a blank piece of paper, you might give them early wire frames (or low fidelity designs), and get them to write comments on it about what they like/ dislike about it - try giving them a red pen and a green pen! - this works best if you can get someone else to run the session, i.e. not people who created them - they're too close/ passionate about what they created; (3) You could give your users/ testers a list of features or stories on cards and ask them to put them in a real order of priority. Ask them why they put them in that order. 

It sounds obvious, but: allow the feedback from users to affect your list of requirements. Once you have your prioritised list you should be able to define your initial Minimum Viable Product (MVP) or the expression I prefer: the Minimum Loveable Product (MLP) - this is the product that you can actually launch, which your users will LOVE and which you can get useful feedback from. Here is quite a subtle difference between Agile in garage and Agile in corporate. When working with clients and stakeholders who are shelling out hundreds of thousands, or even millions ... they want to know people are going to buy it or use it! The (western) corporate isn't always ready to fail - so the early stages of feedback and observation are even more important!

When working with clients and stakeholders who are shelling out 'hundreds of thousands', or even millions of dollars or pounds ... they want to know people are going to buy it or use it! The corporate isn't always ready to fail - so the early stages of feedback and observation are even more important!

I'm not saying I agree with this. There should be plenty of room for test and learn (read up on Kaizen if you want to explore this more), but this is a tension in deciding what you include in your Minimum Loveable or Viable product. Draw a line under the last story you need to get to this. That's your list!

Once you have confidence in the list, move on to the next phase.

ARE WE DESIGNING THE THING RIGHT? 

So, after the first phase of "Are we building the right thing?" we now move in to "Are we building the thing right?"

Step 5: Write detailed user stories

Now that you are creating the backlog for the product, you need to be doing this preferably in an 'User Story' format: 

As a <type of user>, I want <some goal> so that <some useful value is created>.

Take the needs that were described in the previous steps (hopefully now grouped under Themes) and turn these in to Epics and User Stories (with individual user stories sitting underneath the Epics). The best way, still, I think, is to write them in a simple format, and (if you have the space) get them up on a whiteboard or wall. Write them on cards, so that you are precise, and make sure you always get the “so that” value statement in there. Remember that this is the start of a backlog that (in totality) might take months or years to complete (in fact, if your product is successful and continues to grow, it may never be finished!). I’d be aiming for ~200 user stories to get started at this stage. Remember to capture negative scenarios too, for example: if the user doesn't get the right username and password combination then what happens? Presumably they don't log in!

If you and the team are experienced at writing these, then of course, enter them straight in to TFS, Rally or JIRA. 

An important step here is to make sure that you are adding the detailed acceptance criteria that sit outside of the team's Definition of Done (DoD).

Advanced Scrum teams might want to get Product Owners/ BAs to write their stories in Gherkin Script so that Test teams can use these to easily automate Testing later on in the product lifecycle.

Step 6: Define reporting needs

Assuming users pick up your product, how will you know if you are succeeding. Agreeing on some Key Performance Indicators (KPIs) is important for you and the team to agree on, but also for your sponsors or stakeholders. How can you show what good looks like?

• If it's a commercial product how many products per user do you need to sell? What does that look like in ￡/$/€'s (maybe in total, or do you define it as a per-user metric)?
• If the product is focused on repeat engagement is it purely about 'Time on site' per session, or is it the Daily Active User (DAU) or Monthly Active User (MAU) metrics that matters? I heard a friend say that they were being measured purely on these two (DAU+ MAU) metrics for their annual review, showing how important they are in a mature product. 
• Maybe your approach is more qualitative: Which user journeys are the most important? What % of users do you expect to see going in to the different parts of your product? Can you get some feedback from users directly about why they are completing some parts of your product and not others?

It might be helpful to think about KPIs in a couple of different ways. KPIs can be seen from a corporate perspective, or from a user perspective. If you have partners integrated in to the product, you might like to think about it from their angle too.

One watch out: Do your corporate KPIs drive or reduce your user experience? If the corporate KPIs do have a chance of overruling user benefits, don't compromise what's important to your end users for the sake of who will buy or pay for your product (assuming that this might be on a B2B basis in a corporate setting). 

By the end of this stage you should have a set of KPIs that lead you to key reporting needs that you will need to make sure you bake in to your product, and track.

Step 7: Talk to key stakeholders 

Perhaps one of the key differences in a Corporate setting is that you are likely to have people who need to sign off on what you are doing. So, who are your key stakeholders? In the Team Process Flow (this is the step is shown as a vertical highlighted blue column) I have suggested a list of people I have found are practically useful to engage at this stage. They are:

• Your Technology or DevOps teams (to test early on whether practically, you have got the (cap)abilities to deliver on the vision. A good question might be: "Is there a quick way to learn/ prototype how we might do X?", before we invest tens or hundreds of thousands!).
• Legal, Risk, Compliance, Data Privacy, Ethics teams (To ask them to challenge and interrogate you about the product will work or needs to work to be compliant. Do you need to consult any external industry or market regulators?).
• Digital, Brand & Marketing teams (How can they help you shape your thinking? Is what you are doing 'on-brand'? Can they help you prepare for launch?).
• Capability or Product partners (Do you need anything from an external partner? Are you selling their product? Do you need an API or Data feed from a third party? Now is a good time to engage them to test any high level assumptions). 
• Other Geographies? (If you're going to expand or roll out your product in other countries soon (or at some point) then now could well be a good time to get their input too - it might mean that you get some feedback, that you may not implement now, but is useful for context for building your product in a more scalable way).

So, how do you get their feedback? Well, in my experience, getting face to face is always best. It avoids misunderstandings, and it is easier to read the body language, and going to see these teams on their terms, and in their environment can really put them at ease, and shows you respect their position. Take the time to get this right. Don't forget that if you don't get their input now, you will pay for it later. Imagine if you get to 'launch' stage and suddenly a company lawyer says it can't go live ... better to have them involved early and fully, even if they say things you don't want to hear. All feedback is useful!

But what if a face to face isn't possible? You still need to be able to explain it to them to avoid misunderstanding. Here are some other options: a conference call and screen share (not ideal); a ZOOM meeting (intuitive video conferencing technology - free to use for up to 40 minutes); a Google Hangout even?

Whatever route you choose, I would say it probably isn't worth going too deep and showing them detailed user stories (but do have them to hand if they ask), but you do need to tell your product story and give them some context and then help them understand it - "when we spoke to users 90% of them said that they want to log in with their Facebook ID, hence why we are asking to implement this feature". 

Also take the time to walk them through each of your sections of the product in sufficient detail. You may find that splitting up the sections of the product (an hour at a time, rather than overloading) in to different meetings may help, to allow time for reflection.

At the end of this step you want them to agree or sign off (do make sure you get the decision documented - an email will do,) so think about it from their perspective: what do your stakeholders want and need to know in order to be able to make the right calls? Be open and honest with them. Data privacy might want to know where a user signs up to your privacy statement or terms of use for your app, but they might also want to know how you are going to use that data; is the use ethical?; will the data be passed on to a Third Party? 

Remember that you're talking to your stakeholders with the purpose of getting feedback early so you don't have to make changes later that will mean a lot of rework. Ask questions even if you don't like the answers.

Step 8: Do you need to adjust anything in your HLBNs? 

This step is represented by the orange arrows/ feedback loops going back in to your User Stories, after the research spike with your stakeholders. Remember a key part of the Agile Manifesto is responding to change. Is there anything that you've learned that affects your product? What were the 'aha' moments? 

• Get a list of changes you need to make to your user stories
• Do you need to do some more research on anything?

Once you have made the changes, go back to your stakeholders if you need to and get their sign off, or ask them to tell you why they can't, so that you can adapt to the point that they can sign off. You don't want to be making changes once you start build.

HOW WILL THEY EXPERIENCE IT? 

We are moving now from asking the questions of the first two phases: "Are we building the right thing?" and "Are we building the thing right?" to: "How will they experience it?"

Step 9: UX and Visual Design 

Although you may have made some early mock-ups or wireframes for user testing, this is the right time to really start to invest in full UX and Visual Design. The point I want to make is: if you spend a lot of time on UX and Visual Design before getting the other steps completed (like User Stories and Sign offs from stakeholders, or god-forbid, before you have your business case together, and budgets agreed!) then you will potentially waste a lot of early efforts because a lot of re-work will be needed as you learn more, so ... keep it low-fidelity until you have learned what you need to from users and stakeholders. This also avoids your UX and Visual Design team getting too demoralised with all the re-work.

Things worth remembering here (when you are set in the corporate context) are that there may be patterns or UX and Visual Design guidelines to adhere to (or challenge/ evolve). Ideally this might have surfaced in the consultation with the Digital governance team, in previous steps. Make sure that if you are doing something completely new, that you do stay connected with the governance teams - assuming you have these - as if you try to launch something that isn't within their guidelines or understanding, you may come up against a blocker later on!

Step 10: Define detailed event-level reporting tags

Once you have the finished Designs, you'll want and need to take these back past your stakeholders, before you submit them in to Sprint 0. This is to give them the last opportunity to comment and feedback on the final designs. This, to be clear, isn't an opportunity for them to change everything or add features, but more to confirm that the stories and agreements you had agreed have been appropriately represented, and they have no objections. I know, this sounds like bureaucracy and "too many cooks" but if you do this well, you will get smoother product releases and less bugs or change requests post launch - and avoid the risk of getting shut down (and possibly not being trusted to release products again in the future).

Then, once you have the sign offs, define the detailed event-level reporting needs and where you are going to place those all important reporting tags (you can use any kind of analytics tool to do this, but we use Adobe Analytics).

The key question is: What level of reporting is enough? I guess it depends on how much insight you want! Page level reporting will give you a certain amount of insight, but to be honest, if you are operating at a large scale you should (in my opinion) really be operating with Event-level tags. Event level tags means tagging key parts of the journey within pages too. So, anything that a user can interact with (buttons, CTAs, banners, images, social sharing etc). This will tell you whether users will complete the journeys you designed, and in the way that you had imagined. Where are the drop off points in your journey? Where do you need to make improvements?

A thing that you may not immediately think of, but should be an important consideration is: How will you get to the data once you launch? Sometimes this is an after thought for teams, and they find that the data is locked up in the development environment (databases), but isn't easily accessible for the business teams that need to get access to it. Consider who needs access to the data, and how they will access it. What is the right level of access?  Make sure you plan for an analytics tool to allow you to access, query and manipulate that data too.

ARE WE BUILDING IT RIGHT?

So, enough of what you want to design is designed, and you have some of it defined to a level whereby you are confident you can start to build. This isn't waterfall, so you won't have everything designed, but the parts that will deliver the greatest value have been brought to the front of the line, and these are well enough defined for a conversation with the team who will actually develop the product. Now we get in to 'continuous delivery'. We are taking the things to be built to the development team.

Step 11: Sprint Zero - "The promise of a conversation"

Even in the best Agile teams "business people and developers must work together daily throughout the project" and this is no different when you are communicating and discussing your user stories with the development team. As the Agile Manifesto principles state: "the most efficient and effective method of conveying information to and within a development team is face-to-face conversation", but again this isn't always possible in large corporates, especially with the prevalent belief that development teams can be outsourced or off-shored. (My skepticism probably rings through loud and clear here, however the decision to outsource and/ or off-shore is really about whether you think that either: you can't get the same quality of skills for the same price on-shore, which in many cases I don't believe is true; or, that you don't think that you will need those resources in 6 months time - i.e. you need to have the flexibility to slim down the team - which ultimately is down to your unique scenario. Suffice to say, that when you have the luxury of full time developers on your project, you will naturally have a more engaged and invested team. Having said that, there are great outsourcing companies out there. Rant over.

Back to the agenda of 'Sprint Zero'. In new or early maturity Agile teams, this is the opportunity to assemble the team and make sure that your whole team understands what you want to build. Don't make this phase too long. It doesn't need to be a whole "sprint" (e.g. 2 weeks) long. If you are going to use this time, make sure you/ your Product Owner clearly explains the intent and value of the stories you have at the top of your priority list, in detail, to the development team. The responsibility for communicating the stories sits with the Product Owner, however, all attending should be engaged. Since stories are there to allow for a conversation, allow your development team to make suggestions about how you could design it differently to get better outcomes. We've found on occasion that a very simple change has reduced a development effort ten-fold. You may get your MVP or MLP out sooner! 

Next the development team will write technical stories or tasks and do story point sizings. Often Business teams or stakeholders will ask "how long is it going to take to build this product?", and the answer should be "once the development team have had a chance to size the effort we will know". Only then can you get any idea about how long it will take to build. Herein lies a fundamental difference between methods like Agile Scrum and Waterfall - in Waterfall you do all the analysis upfront and then move to build. So, theoretically you have a good idea of how long it will take to deliver. In Agile, you deliver as much as you can within fixed time boxes, so you will get early sight of deliveries, but you don't always know exactly how much you will get - because the principles of 'time boxes' and fixed resources, means that the only thing that can give is the number of items delivered.

Herein lies another potential corporate trade off: Is it acceptable that the requirements be cut in order to meet a deadline for clients or a market opportunity - in which case the MVP or MLP may not meet all the expectations you had hoped, or can the business afford to wait to get everything developed you wanted in the MLP? Where do you compromise? 

Don't compromise on quality! If possible, add resources (i.e. 'burn' your budget faster, if that is possible - it needs to be a conversation with the development teams), rather than reducing scope, if you have a fixed timeline. However, in the first instance, you might also go back to clients or stakeholders and ask whether it really is a fixed deadline and show them what of means in terms of reducing scope. They may soon change their minds! Don't try to squeeze on timelines or reduce the time you have for things like testing (even if this is on an ongoing basis).

Step 12: Sprints 1-X (Continuous Delivery) a.k.a. "the Build Phase"

Make sure that this isn't the step where waterfall takes over and you hand over your requirements to your DevOps/ Technology teams and you get something back in a few weeks or months (at worst years!). The Product Owner and Development teams need to be talking daily. As the principles of the Agile Manifesto clearly outline: "Business people and developers must work together daily throughout the project" and whilst I agree that "the most efficient and effective method of conveying information to and within a development team is face-to-face conversation", you can use all the same technology tools (JIRA, Zoom, etc) that we talked about previously to stay connected, as at least some of them are likely to be based elsewhere (offshore, west coast, far east or near-shore). I would argue that having, as a minimum, the Development Leads sat with the product teams is pretty essential.

A quick tip to help with daily communications like standups: When all the Development team are based in one place (but this is apart from the Product Owner), then I would advocate for using something like the Polycom CX5000. It's a great way to be able to see everyone in the room for the daily standups. I used this when I was based in London, but my development team were based in Phoenix, Arizona.

I'm not going to describe the full 'DevOps' model here that we have developed, but suffice it to say that when you get that right you get huge efficiencies and things that used to take months to build now take days or weeks! When the development team has clear direction and they write clean code that is also secure, and they create and run automated unit tests, and perform peer code reviews, as well as using dashboards to review the quality of code and ensure there are no defects, then you're winning. In essence you have a certain amount of QA going on as soon as any code is being checked in.

Having a clear vision and a full, well-defined and prioritised pipeline of work is key to having an engaged development team.

What I will say is that having a clear vision and a full, well-defined and prioritised pipeline of work is key to having an engaged development team, that stays with you. If you keep having gaps in your product development then you will very likely be unable to justify having a full time development team, or be able to hold on to the best resources, and those that understand your product vision. This will cause delays.

Communicate your vision to them regularly. It will mean you can start to create the product together, and the development team will start to think ahead, as opposed to just coding the stories your team has outlined. If they know that at some stage the Mini will become a Monster truck then they will be able to lay the foundations for something much more scalable. Equally, without giving them that foresight, you might end up having to rebuild a lot of your MVP.

When the team development team does start delivering working code, make sure that the team is regularly getting together for 'Show n Tells' (or that the business/ PO team has direct access to the working code). Hopefully a weekly or bi-weekly celebration of progress should be energising to everyone! I have seen teams do this on a thursday or friday evening at 4.30pm with some beers, and that seems an ideal model to me.

The retrospectives after each sprint are another key success factor. It should help develop learning and cohesion in the team. To avoid these becoming blaming sessions, the right mindset is needed going in to them. Coming from Norman Kerth's (2001) work, the attitude should be: "regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand". Per the Agile Manifesto's principles: "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." Because Agile stresses the importance of continuous improvement, having a regular Agile retrospective is one of the most important of Agile development practices.

It is worth noting that Western society, and especially Major Corporates, don't typically reward (perceived) 'failure' as a key step to learning, so unfortunately the retrospectives part of the Agile philosophy often falls by the wayside in immature teams, or those that haven't experienced the value of it. It follows as well that these things shouldn't just be about what went wrong, but also what went well and the team should do more of, or grow in! A whiteboard or section of the team room dedicated to "things we have learned" be that failure or success, should be encouraged.

Step 13: Quality Assurance and User Acceptance Testing

In terms of Quality Assurance (QA) and User Acceptance Testing (UAT), these should be fully integrated in to the development cycle. And whilst, logically (and in the Team Process Flow) they come after something has been built, whenever you see a team that seperates this out (by which I mean: they do all development and then all testing), you immediately understand the maturity of that team. Testing should be embedded in the build cycle. Continuous delivery and continuous testing.

Automated software testing is vital, especially if you are building a big product or platform. Automated software testing is when software tools execute pre-scripted tests on an application before it is released into production. Imagine performing regression tests manually across a whole application or platform each time you do a release! It would take huge amounts of test resource or time! Invest in getting to 100% automated testing from the start. If you write your user stories in Gherkin script, then this is a pretty easy process to implement!

Beware though for anyone who says that by releasing working code that has been through QA/ Testing Automation that it is fully tested. It simply isn't true. If you are still testing to personas, scenarios or with dummy data then you aren't getting to all the scenarios, you are simply executing 'planned for' scripts. That's why teams or super users (if you have an engaged audience) need to be able to have access to restricted (alpha or beta) releases, so that small(-ish) groups of people can test new features and functionality in a real environment, with (and this is the key bit) REAL DATA. This is where you learn the edge cases (someone earns more than the 7 figures you had planned for, or has more than 10 children, or more than three homes). You also cannot predict user behaviour, and so this is where you will learn a LOT, before you put it out to the whole world - more on this in the final phase.

Testing isn't the sole responsibility of development teams, nor the product team nor the end client or user. Everyone should be involved. Don't fall in to the trap in large corporates of handing this over to the "testing department" or team. As the business owner you best understand the vision you had, and there is a certain amount open to interpretation, so make sure you get the product you want by being engaged and involved.

DID WE BUILD IT RIGHT?

The final phase is asking the question "are users using it the way we had designed it to be used?" and if not, why not?

Step 14: "Launch" and Production validation

So, 'coming in to land', you're ready to launch. The reality is you've just completed the sprint(s) that got you to the start line, now you're settling in for the marathon. Assuming that you have completed all your 'pre-flight-checks' and that everyone is happy (at least happy-enough) that you can go live, make sure that this isn't the last time you care about testing or refreshing content, or listening to user feedback. Now you're product is live you're about to learn what huge volumes (we hope!) of people think of what you've created.

Of course you tested it, but now it is in the hands of real people, what do they think? Did you build in the feedback loops to make this simple? For website or app feedback on an ongoing basis I don't think you need to look much further than Usabilla. Separating themselves from the competition with detailed feedback options, and not just the standard NPS questions like: "did this page fulfill all your hopes and dreams", for which you don't need to ask the question (otherwise the user wouldn't have just clicked on the button), they are the best I know of in terms of implementing a simple Feedback button on every page.

The key to enterprise product/ platform feedback though is really having a joined up approach to gathering feedback. If you have B2B clients, will you meet up with the sales and relationship management teams regularly and listen to them? If you have a Call Centre or Customer Success Team, how will you get the feedback back from them? These are the eyes and ears on the front line of your product. On the back end, look for scenarios that fall outside of your planned scenarios. How are users using your product? Are they doing unexpected things? Good! These are opportunities to expand the product, or take features away! The sign of a good and mature product is when you start to learn what you can take away because it doesn't add any value! I particularly like this picture that illustrates the way in which 'real life' has a way of finding it's on way to change the way things are designed:

If people are using boxes designed for phone numbers to store notes, or membership numbers to their health insurance then maybe they are saying: "please give me a notes box or dedicated membership number box, in this section". Keep watching the data, it will tell you everything you need to be successful! One of our Product Owners now always logs in to Omniture first thing in the morning - what a great way to start the day!

So there you have it. There is no timelines on this Team Process Flow, on purpose. You'll find that it should become a very fluid process. Often my team say to me, "well it doesn't really work in that linear way", and that is probably a sign that they get it, and that things have become second nature. But for those that desire or benefit from a visual model, I hope this Team Process Flow and the various anecdotes, tips and 'pitfalls to watch out for' has been useful.

I also hope you and your teams can put some of it to practical use. Questions, feedback or your comments and points of view about the practical outworkings are of course very welcome through Twitter (@calomas) or through the comments section.

Good luck!