Managing Work Items with the Excel Add-In Primer

Bob Morris is a Project Manager and a Principle Scrum Master at ThreeWill. He has over 20 years of experience with successfully leading technology projects and teams in both project management and senior technical management positions. This experience includes delivery of software product development, enterprise software deployment and I/T infrastructure projects.

Microsoft provides a comprehensive set of online documentation and guides for using TFS/VSTS, including the Office Add-in. However, I wanted to provide a blog post with some additional tips we’ve developed based on real-world experiences. Hopefully one or two these will be beneficial to others attempting to use the Office Add-In for TFS/VSTS.

Team Foundation Server/Visual Studio Team Services (TFS/VSTS) has long been a cornerstone development tool for software development teams. In the past couple of years, Microsoft has been enhancing this tool to provide additional features for work management using Agile project approaches. TFS/VSTS now has a wide range of features to manage the work of a team in terms of lists, e.g., product backlog/user stories, bugs, tasks, features, etc. Although TFS/VSTS has plenty of built-in features for managing these lists, there are times when you really just want to be able to manipulate these lists in a spreadsheet. Thankfully, Microsoft has also provided an Office Add-in that provides additional capabilities for managing TFS/VSTS lists using familiar tools like Microsoft Project and Excel (this post focuses on Excel use with VSTS).

When you need to add/update list items in bulk or generate quick reports on list content, this Add-in can be invaluable. A common use case for our team is to build product backlogs during an initial envisioning/sales effort with a customer to create cost estimates. Due to portability and flexibility considerations, we typically use a spreadsheet for this purpose. We then need to import this backlog (with lots of supporting information) into a project in VSTS so that the project team can align their work with initial expectations set with our customer during the sales process. The TFS/VSTS Office Add-In is built for this type of need.

The Nickel Tour

Before describing some tips, let me summarize the how the Office Add-In works for any newbies out there.

The main idea is to create a list on a tab of an Excel workbook to either “add/update” or “read/update” work items in VSTS. You can have multiple tabs for this purpose within a single workbook as long as they all point to the same VSTS project. Step 1 of creating a list for this purpose in Excel is to click the “New List” button on the “Team” ribbon tab as a first step. If you don’t see the “Team” tab in the Excel ribbon, you need to download and install the Add-in (see links below).

When you click “New List” you will be prompted to select the “type of work item list you want to create”:

  • Add/Update – Pick the “Input List” work item list type. This is the ONLY way to add new items. You can also selectively pull items down from VSTS, update locally then publish back to VSTS using this list type.
  • Read/Update – Pick the “Query list” work item list type. This allows you to download a filtered list of work items (based on a query you define in VSTS) for reading/reporting purposes or you can update the items locally and then publish back to VSTS using this list type.

The general process flow for using the TFS/VSTS Office Add-in is…

  1. Create a new workbook in Excel.
  2. Click “Team” ribbon menu.
  3. Select a VSTS project to connect with in the “Connect to Team Foundation Server” dialog box.
  4. You will the see the “New List” dialog box pop-up where you will select the type of list you wish to use for the data connection. This is the same pop-up you will see if you create a new worksheet in the workbook and press the “New List” button on the Team ribbon.
  5. Data from the query (if you selected a Query List type of work item list) will be populated in the current worksheet within the workbook. Additional data column can be added to the worksheet list using the “Choose Columns” button.
  6. Use Refresh/Publish buttons on Team ribbon toolbar for download/upload functions. (CAUTION: See tip #3 below before pressing the “Publish” button.

If you are brand new to using the Office Add-In, you can start your learning journey at the following links:

Add-In Download: (look for the download link in the “Team Foundation Server Office® Integration 2017” section of the page)

Basic User Guide:

Tip #1 – Use a “Staging” worksheet to fix errors before they occur

The publish feature has a pretty good UI for reporting/identifying errors during “Publish” operations. (Remember that this is the only function that allows you to make changes in the data stored in VSTS). However, the Publish function will skip rows in your data where it encounters upload errors. This can create a confusing situation as you sift through rows in your spreadsheet to make corrections with some rows having already been uploaded and others not. Sometimes this will also cause item numbers for newly uploaded items to be out of sequence in VSTS (if that is something you are concerned with).

Bottom line…I really try to correct errors before they occur in the Publish function by using standard Excel data validation features and functions BEFORE any attempts to Publish new work items. To make this process cleaner/easier, I typically use a separate “Staging” worksheet where I perform all data validation and manipulation. Then I copy data columns from the “Staging” worksheet to the worksheet I am using for Publishing, typically a list type of “Input List”.

The above screen snap shows a sample staging worksheet with a standard type of validation, i.e., ensuring that a field width is less than the maximum allowed by VSTS. In this case, the column with the red highlighted title is used to perform a validation on the title field to ensure that it is less than 255 characters. Standard Excel conditional validation is used to highlight specific rows in red where the title is greater than 255 characters (note that wrapping characters are not shown in the figure above). In these situations, I would manually edit affected titles to trim characters either by truncation or editing/abbreviating before copying to an Input List worksheet.

The screen snap below shows an “Input List” worksheet (before executing the publish function) that could be used to publish information to VSTS. The green highlighted column headers indicate columns that have been populated by manually copying from the staging worksheet above.

The screen snap below shows the same data after pressing the “Publish” button.

Tip #2 – Overload fields if you want to stick with standard work items

When creating a product backlog spreadsheet in our envisioning/sales process, we often collect data in columns that aid in planning discussions with customers but don’t necessarily correspond to data fields in VSTS. In this situation, we will typically “overload” fields before uploading to VSTS by combining multiple staging worksheet columns into a single column.

The screen snap below shows overloading of the “Description” field that will be uploaded to VSTS. Overloading is accomplished by combining multiple fields into a single field using standard Excel string concatenation functions. Of course, VSTS has a capability for defining new work item processes and data templates with new data fields. However, if you don’t have time for that or want to stick to standard templates this tip can help.

Tip #3 – Measure twice – cut once when using the “Publish” button

This is a small tip…but by far the most important! The old carpenters saying of “measure twice cut once” (referring to ruining a piece of wood if cut too short) is appropriate for the Publish function. You can do massive damage to your lists in VSTS if you inadvertently change rows in an input list and then publish to VSTS. Remember – all rows in the input list are uploaded and overwrite existing rows with the same IDs in VSTS.

Tip #4 – Start slow using flat lists

Newbies just starting out with the Publish function should use “flat” lists as opposed to “tree” lists. Tree Lists allow you to upload multiple records and the hierarchical relationships between records. In the screen snap below, a backlog item and related tasks have been uploaded to VSTS.

Tree Lists can be powerful ways to enter and manipulate data. However, for beginners, they can also create massive confusion if erroneous data is entered. By default, the “New List” button will create a Flat List. You can use the “Add Tree Level” button to convert this into a Tree List. Again, Flat Lists are a good/simple starting point for beginners.

Tip #5 – Keep your data in sync – refresh early and often

OK – I’ll admit this tip is already available on the VSTS website at the “Basic User Guide” link mentioned above. However, it is important enough to mention here again. This tip relates to the following best practices to ensure your spreadsheet data is in sync with the online VSTS data store:

  1. When you first open a saved worksheet, use Refresh icon in Excel on Team ribbon (Refresh) to download the latest data from the data store.
  2. To avoid data conflicts, publish your additions and modifications often.
  3. To prevent loss of data before you publish or refresh, save your workbook periodically.

If you ignore the above, you may notice strange behavior when attempting to publish information or worse, you may overwrite information others are entering in VSTS while you were editing your spreadsheet!

Tip #6 – Name your tabs according to list type and purpose

This simple tip is a good way to help others understand the structure of spreadsheets you’ve created for use with the TFS/VSTS Office Add-In. In general, tab names should provide clues as to the type/use of the worksheet as indicated in the screen snap below.

Tip #7 – Use values in cells, not formulas

The Publish function does not automatically calculate values for formulas when uploading to VSTS. Instead, it will simply upload a stripped version of the formula itself. This can be simply overcome by copying and pasting in place as values in your input list worksheet prior to publishing.

Tip #8 – Leverage pivot tables for simple reporting

If you are an Excel power user, you are most likely familiar with the power of pivot tables for visualizing data. These are also handy for providing quick roll-up summaries of list items. We commonly use this to generate on-the-fly roll ups for total story points in various columns of our Kanban board as shown in the screen snap below.

Hopefully one or more of the above tips will help you have a more enjoyable experience with this great tool!  Please feel free to share any of your tips in the comments below.

read more
Bob MorrisManaging Work Items with the Excel Add-In Primer

User Acceptance Testing – It’s Time for Some Clarity

Bob Morris is a Project Manager and a Principle Scrum Master at ThreeWill. He has over 20 years of experience with successfully leading technology projects and teams in both project management and senior technical management positions. This experience includes delivery of software product development, enterprise software deployment and I/T infrastructure projects.

If you were my customer on a typical ThreeWill project and I said to you “we need to confirm that the solution we’re developing will actually fulfill the day-in and day-out needs of users prior to production go-live” and I called this “User Acceptance Testing”, I’d bet you would agree that this is a reasonable assertion. (Duh!) However, I’d also bet that if we left the conversation at the point, you and I would likely come away from our discussion with different expectations on how this would be accomplished. Why am I willing to make these bets? Well, my experience in past projects plays a part for sure. However, it’s also the proliferation of testing terminology and common misuse of those terms, particularly in Agile project approaches, that is a sure-fire way to cause confusion and miscommunication. So, I thought I would write this blog post to alleviate some of that confusion.

To be clear, I am discussing UAT (User Acceptance Testing) in terms of the most common project implementation approach we use at ThreeWill, i.e., Agile/Scrum. Our most common scenario involves standard Scrum roles. This will typically include roles fulfilled by our customers (at minimum this includes Project Sponsor, Product Owner, and Subject Matter Experts) and roles fulfilled by ThreeWill (usually including Scrum Master and Development Team). All references to “customer” in this post refer to the ThreeWill customer for the project and “Development Team” refers to the team of development, testing, and business analysts responsible for the delivery of product backlog items in our Agile/Scrum project approach.

What’s in a Name?

One common impediment to clear understanding we see is the actual terminology used to describe testing in Agile projects. There are many different types of testing that might be employed on a project and it’s easy to get confused on the purpose of each. The figure below shows one of the most concise visual representations of Agile testing and was originally developed by Brian Marick and later included in one of my favorite Agile testing books by Gregory and Krispin called “Agile testing: A Practical Guide for Testers and Agile Teams1.

Figure 1 – Agile Testing Quadrants

As indicated in the figure above, UAT is considered a “quadrant 3” type of testing and focuses on a “business-facing” critique of the product/system and will typically involve mainly manual testing. Testing in other quadrants, particularly functional testing, is also a key component of typical ThreeWill projects (see Brandon Holloway’s recent blog post on “Quality Assurance Levels – Which One is Right for Your Project?“). However, a key difference between UAT and these other types of testing is that customer roles typically perform the actual execution steps for UAT.

Why (you ask)? It’s because we are interested in validating that the solution supports the needs of real end-users as they execute their own job functions. There is no value in having end users simply re-execute testing already performed by the development team during iterations (aka sprint cycles). In fact, it’s not uncommon for a UAT team to be unfamiliar with details and acceptance criteria from the product backlog. So, by the time we enlist future end-users in a UAT effort, the testing by the development team should have already verified that the solution performs according to the acceptance criteria defined by the Product Owner. Instead, we are interested in potential patterns of use of the solution in broader testing scenarios that may not have even been envisioned or covered by functional testing performed by the development team. For this reason, Product Owners will typically be responsible for defining the test scenarios to be included in UAT and will define those scenarios at a very high level, avoiding detailed testing steps or user interface interactions. The idea here is to encourage some variation in the actual test steps being performed by each UAT tester as long as they validate that the solution supports their needs. The bottom line is that UAT is more about “validation” than “verification”.

The concept of having actual end-users of a system perform testing scenarios to confirm that it supports their needs as part of an overall business process is not new. In older plan-driven project approaches, this was often planned as the final step or “phase” prior to production go-live of a system. However, that kind of thinking is distinctly “non-Agile” because it contradicts the iterative nature of Agile which eschews a phased project approach. So, should UAT be executed as part of an iteration in an Agile project or should it be executed only once per release or should it be executed on an ad-hoc basis? These options can be confusing.

By the way… this earlier use of the term “acceptance” in UAT also causes confusion in an Agile project because it is often overused to mean different things. For example, some would say that “Acceptance Testing” and “User Acceptance Testing” mean the same thing while others might claim that “Acceptance Testing” is related to functional tests executed to confirm specific acceptance criteria in a single user story rather than broad scenario-based testing executed by end-users (which is what I’ve described above).

When in Doubt – Channel Your Inner Bruce

So, how do we select the appropriate approach for testing given all of the options mentioned above? How do we deal with confusion in terms? How do we handle differences in project approaches in the application of testing?

One of my tried-and-true approaches for dealing with too many options or uncertainty in making a decision is to find a Bruce Lee quote that applies (OK – maybe this doesn’t always provide an exact answer but generally it helps me focus!). In this case…

“Absorb what is useful, discard what is useless and add what is specifically your own” – Bruce Lee1

In other words, there is no “one size fits all” answer. The appropriate approach to UAT needs to be tailored to each specific project and we place a high priority on working with Project Sponsors and Product Owners to determine the right fit. Our experience has shown that the keys to success with any UAT effort

Our experience has shown that the keys to success with any UAT effort is:

  1. Don’t be too dogmatic about process. We see each customer as being unique in their needs and constraints related to UAT,
  2. As with anything agile, favor “individuals and interactions over processes and tools”. Keep the process as simple as possible when viewed from the perspective of a UAT tester, and
  3. Generate enthusiasm. The most “bang for the buck” in any UAT effort depends on a team of highly motivated testers that recognize the benefits of both the planned solution as well as the UAT effort related to it.

I’ve provided three examples below to illustrate the variety we see in UAT approaches. There certainly are others. I just wanted to illustrate the variety of approaches that might be needed for different projects.

“One Man Band”

A common “minimalist” approach we see relies mainly upon the Product Owner managing a modest effort, maybe including only the Product Owner or a designated SME running some testing based upon very high level/informal test scenarios. The timing of this testing is usually ad-hoc and based on the Product Owner’s view of when enough features have been completed to support a particular desired testing scenario. Any issues resulting from this testing are reported informally via email or verbally by the Product Owner.

It is possible that, even with this minimalist approach, new user stories may be generated as a result of testing in addition to issues/bugs. As with all of the approaches mentioned here, any new user stories or bugs resulting from UAT never interrupt the iteration plan being executed by the development team and are considered as potential items for the next project iteration. The only exception is “blocking bugs”. If a bug is preventing execution of UAT testing and testing delays cannot be accepted, then a development team member may need to address the bug immediately.

“Don’t Slow the Roll”

This approach is a more traditional plan-driven project approach where UAT is delayed until the end of the project as indicated in the figure below. Feature development iterations proceed without any UAT feedback until a final “hardening” iteration.

Figure 2 – Traditional UAT

The Product Owner typically selects a group of SMEs (subject matter experts) that serve as a “UAT Team”. UAT team members commit to a fixed time period where testing is their top job priority. The development team executes feature development iterations to a planned completion point (“Feature Dev N”) followed by a “hardening” iteration where the development team is focused on resolving issues/bugs reported by the UAT team. After completion of the hardening iteration(s), the development team is focused on any remaining steps necessary to promote the solution into production use by the client. This final iteration is sometimes designated as a “Transition” iteration.

This approach may be dictated by availability of SMEs to commit to a focused UAT time period or may be a required process step in the client’s production readiness process. Regardless of motivation, there are some definite drawbacks to this approach.

The idea of treating iterations as having “types” implies the presence of “gates” to move from one type to another, e.g., “finish all features before hardening” or “resolve all UAT issues before transitioning”, etc. Taken to extreme, this results in a “phase gate” project approach which defeats some core agile benefits like delivering value in increments that can be regularly reviewed and used as a basis for decisions for future increments. In this approach, the ability of the development team to respond to any UAT issues that might motivate a Product Owner to request new features or nontrivial design changes is severely limited. This might result in “compromise” resolutions to UAT issues in order to meet project timeline commitments.

“Go with the Flow”

This final example is a more agile-friendly approach but requires at least a part-time commitment of UAT team members over a longer period of time as indicated in the figure below.

Figure 3 – Parallel Iterations

As in other approaches, the Product Owner typically identifies a group of SMEs that can commit to a series of iterations that run in parallel to development team iterations. Typically, there is some lag period before the start of UAT iterations so that the development team can provide enough features to support the scenario-based testing required by the UAT team.

Similar to other approaches, the Product Owner identifies the high-level testing scenarios that the UAT team will execute for each iteration. The level of testing included in each UAT iteration may vary depending upon the timing of availability of product features coming out of the feature development iterations. Any issues, whether ultimately related to bugs or new feature requests/changes, will be considered by the Product Owner and development team during planning for the next feature development sprint. In the above figure, care must be taken to avoid development of any significant new features beginning with development team iteration “Dev N”, since the UAT team would not see those features in their final iteration “UAT N-1”.

With this approach, the UAT Team is able to see resolved issues and any suggested new/changed features in subsequent UAT iterations. Coordination of the development team/UAT sprints can be facilitated in multiple ways, including UAT team attendance at development team iteration reviews and vice versa or even with a periodic “scrum of scrums”-type meeting.

“Making It Your Own”

As a final point…you may be thinking…” OK – how do I determine the right fit for my project?” Unfortunately, there is no single formula for this and experience does play a role. However, as indicated in the table below, there are some factors that you should consider when making decisions on UAT approach. Thinking through these items can serve as a basis for deciding on the proper UAT approach for your project.

Table 1 – Considerations for UAT Approach Selection

  • What is the motivation for UAT?
  • Do we only want issues (defects) reported or are suggestions that turn into new backlog items acceptable?
  • Are there any customer-specific testing requirements (e.g., regulatory) that must be covered?
  • Will we have a “dedicated” UAT team?
  • How large will the team be?
  • How much time can each team member dedicate to the effort?
  • Will the team consist of multiple levels of expertise or single level?
  • Can we find testers that want to make a contribution to the testing effort or are we dealing with a pool of testers that are already overworked and view testing as a burden?
  • Do we thoroughly understand the main motivations of system users?
  • What resources are available for developing testing scenarios? Are they high level (e.g., story maps, vision statements, etc.) or lower level (e.g., workflows, procedures, use cases, etc.)
  • Do we want to base testing scenarios on specific business processes/sub-processes or do we want to base on roles (e.g., “a day in the life of a <insert your role here>”) or even user “journeys” that cut across multiple processes?
  • What format do we want to use for communicating testing scenarios?
  • Will team members be available for a continuous effort (even if part time) or will they only be available on a periodic basis?
  • Are there any customer-specific testing requirements that dictate the timing/reporting format for testing?
  • Can UAT team members attend sprint/iteration reviews throughout the project?
  • At what point in the project do we believe we’ll have “critical mass” with enough features to support useful scenario testing?
  • How do we want to report issues?
  • Are there customer-specific requirements for tracking issues?
  • Will someone be able to “curate” reported issues to avoid duplication or erroneous issues?
  • How will testers receive feedback on issue status?
  • Are there any formal sign-off procedures that need to be satisfied before calling UAT “done”?


I hope this post has helped to provide some clarity on what we mean by “user acceptance testing”, why it is an important consideration for projects, and practical ways that it can be accomplished. UAT is not a substitute for other types of “quadrant 3” testing mentioned at the beginning of this article and may be used in concert with alpha/beta testing or pilot program approaches to promote solution adoption by business users. I’ve focused on direct benefits of UAT in this article. However, there are important “side benefits” as well, including building a core group of knowledgeable/enthusiastic users that can help promote buy-in from the rest of the user community and ultimately drive project success.

read more
Bob MorrisUser Acceptance Testing – It’s Time for Some Clarity

Low Friction Requirements Using SCRUM

Bob Morris is a Project Manager and a Principle Scrum Master at ThreeWill. He has over 20 years of experience with successfully leading technology projects and teams in both project management and senior technical management positions. This experience includes delivery of software product development, enterprise software deployment and I/T infrastructure projects.

Danny Ryan:Hello and welcome to the ThreeWill Podcast. This is your host Danny Ryan and today I have Bob Morris here with me. And Bob, so what’s your official title Bob? Give it to me.


Bob Morris:Principal Scrum Master.


Danny Ryan:Principal Scrum Master. I salute you Principal Scrum Master.


Bob Morris:It’s very commanding.


Danny Ryan:This conversation, well I guess it’s important to this conversation, because we’re going to talk about using scrum and a low friction requirements with using scrum. So why don’t we just get this whole thing kicked off with why should we talk about scrum and requirements?


Bob Morris:Well, you know, requirements for any kind of project or the types of projects that we get involved in are sort of the fuel that drives, not just the delivery process for us, but also the sales process. Scrum nowadays is a pretty broadly accepted approach. There’s some confusion out there about how we do requirements in the scrum process, and maybe confusion about some of the artifacts people might be familiar with with other project approaches, and they get those confused with what we do in scrum. And then there’s some misconceptions here that I think it’s worthwhile mentioning. I think two of the common ones are that there is no documentation in scrum, including for requirements or sometimes scrum teams end up kind of wandering in the woods when it comes to requirements and completing a project. And then as the title suggests, you know really want to explain to people why we think of this approach as a low-friction approach for getting requirements.


Danny Ryan:So what do you mean by low-friction?


Bob Morris:Well what we’re talking about there is essentially adopting an approach, a set of processes that hopefully speed up the process of gathering requirements, and we do that mainly through trying to minimize impediments that typically get in the way or delay getting those requirements. And we also try and really focus on steps in a process that add value to the customer, and to getting those requirements. And try and minimize those things that don’t really add the value that we need, in trying to get those requirements.


Danny Ryan:So where do we start?


Bob Morris:Well, it’s like a lot of things related to Agile types of project approaches. It goes back to the core principles and values from Agile. And all of these things are geared towards trying to be able to support rapid and flexible reactions to changes in a project. And really I think the ones that apply most to the process of getting requirements, are first I would say eliminating waste and in requirements there potentially is a lot of that. Particularly with detailed specifications that get created early in a project before we really have a great understanding of what exactly it is that we’re implementing.


And those things end up getting thrown away and rewritten. The other thing that I think is core to this is understanding that we want efficient communications. Scrum process that we use is heavily focused on a conversations, as a primary communications mechanism, as opposed to the written word. And, also interactions, direct interactions with our stakeholders. That’s a very low effort type of way to communicate and we really focus on that. There’s a thing, a term called progressive elaboration, and it’s just a fancy way of saying that, you start simple and then you gradually refine and add more detail to something. And requirements are an excellent example of how we use that in practice.


And then the last piece is, you know we are always trying to improve, refine, and seek clarity with these requirements. We don’t expect them to be perfect up front. And they don’t need to be. Basically the trick is having just enough detail to support the stage of the project that we’re at. So you know those principles and values, that’s kind of the bedrock that we base all this on and I guess the fundamental building block to answer your question about starting is what we call a user story.


Danny Ryan:For listeners that are not familiar with that term, what is a user story?


Bob Morris:So, basically a user story is, I guess in it’s simplest form, it’s a placeholder for a specific user need. And I talked about the principle of progressive elaboration. Starting simple, adding more detail. And at the beginning, user story is just a single high level statement, usually very high level, that summarizes the who, the what, and the why of a particular need that a stakeholder has. And they’re very simple written in first person from, from a users perspective. So they’re very approachable and easy to understand. And basically we call it placeholder because it’s the basis of ongoing conversations that are going to occur about that user story or that need throughout the lifecycle of the project. Both during the sales process for us and after the sales when we go through implementation. Each of these conversations that we have throughout that process, as I mentioned before, we are just trying to get enough information to support the information we need for that particular project stage.


That’s kind of in a nutshell what it is.


Danny Ryan:Give me, do you mind just going off script a little bit? Do you mind just giving me example of what is it, what would be a user story like, a real user story that you would say.


Bob Morris:Yeah, you know there are people that are maybe a little to dogmatic about kind of how you format a user story. I think the most common method to do this, is, you know I mentioned the who, what, and the why. It’s to have little ques you use in every story. So as a who, so it’s a role, as a website user. And then the what, I would like to, well what is it that you want to do? What is this need that you would like to do? I would like to be able to submit my credit care information. And then the why. Well why are doing that? So that I can pay for my order with credit card. As opposed to some other method. And that’s the value, that’s the why.


Danny Ryan:That’s awesome. Thank you. So if your continuing to add detail after the start of the project, how do you define the overall scope and schedule and cost for a project as a part of the sales process.


Bob Morris:Yeah it seems a little counterintuitive because people I think are used to trying to collect a lot of detailed information to use as the basis for a sales proposal. And for us, again I go back to this idea of just enough information at each stage. And in a sales process usually the thing we’re heading towards is a statement of work. And so, at that point we will develop user stories, but at that point it may only consist of the summary statement and usually something we call, acceptance criteria or conditions of success for that user story. So that gives us enough information that we can track that as one of the components of the SOW and to estimate the amount of effort that it will take. Later after we’ve done the sales process and we’ve done an SOW, we might add more detailed descriptions, could even attach test case documents, design documents, or other supporting artifacts. So there are documents involved but we only do it at the point in time where we feel like we have enough knowledge to fulfill the need for the information.


Something else that happens, not really as part of the sales process, cause we’re after an initial set of user stories, but we will split a user story into multiple user stories so we get into more detail. And again that’s that concept of progressive elaboration. The bottom line here is for an SOW or sales process, we take the initial version of these user stories, and combined we think of them as a product backlog. And probably a lot of people listening are already familiar with that concept. And we take this product backlog which basically contains, it’s a summary of the prioritized scope of the project. It allows us to produce an overall level of effort estimate for the project. And it allows us to take that information and put it into, kind of one final piece of this, which is what we call release planning. And what release planning is, is just a high level definition of what is the schedule, how will that scope be delivered according to what time frame.


And once we have all those pieces, that’s enough for us to generate an initial statement of work for a customer and oftentimes that ends up being kind of like a laundry list. So, we have a pretty flexible process where we can go back to customers with a quote and that quote can actually be tailored after their initial review based on their needs. Maybe they have a particular schedule need or budget need.


So, that’s how we do that.


Danny Ryan:What are the inputs into this process you expect from customers?


Bob Morris:Well you know I mentioned earlier, rapid and flexible are the keys words here. So we are flexible. There’s a pretty wide spectrum of what we would get. And sometimes it’s sort of proportional to the size of the project that’s being considered. I think we also, we always welcome a few things like some concise initiation documents. That’s usually would be a business case or product vision, either written or even just described to us. And when I say business case I mean information about the why of a project. Sometimes it might even include the anticipated benefits or return on investment. And a vision is just, explains how those benefits would be delivered by the product or the project that we’re working on. So those are all nice to have’s but we are flexible with this process and if we don’t have those, we can actually just go through a series of interviews and get the information that we need.


Danny Ryan:So why do we consider this a low friction approach?


Bob Morris:I mentioned earlier that it has to do with removing impediments, focusing on the pieces of a process that actually add value to what your aiming at. And really the way this process is low friction kind of breaks down into those areas again that I mentioned, the 4 core principales and values. So, mentioned before about reducing waste. Having this concept of progressive elaboration means we’re trying to reduce throw away documents. People are very familiar with being in a situation where a lot of very detailed documents are generated at the beginning of a project only to have to go through multiple revisions before you get to the end of the project. So that’s one area of waste that we try and eliminate. The other thing is that we have detailed design and test cases for user stories that may change. So if we try and develop all that stuff up front as part of a robust set of documents, we may have to rewrite those as well. Either due to market conditions or priorities that change with the customer.


The second area is for low friction, again in communications. I mentioned user stories, we try to make them clear, easy to understand, written from the perspective of the user. We try and promote conversations as opposed to exchanging a lot of documentation back and forth. We will capture the details, when we need them as we go through the project, but not before.


The last piece about continually refining and improving the requirements, that’s something that is just built into this process. Just to give you an example, we’d start out, we’ll actually do a high level release plan that I described earlier during the sales process. So it’s an excellent spring board for the project. Then when we start a project, typically it’s during the first iteration, it’s something we call sprint zero. We’ll refine those requirements again during that iteration and review them with a customer. And then as we go through the project, as the team learns more, as the person or the people on the customer side that are making decisions on priorities and the content of what we implement get better, we’ll refine these requirements even further.


Danny Ryan:Now before we wrap up let’s address a couple of the initial points that you mentioned. First you mentioned confusion on scrum requirements compared to other project approaches.


Bob Morris:There’s some terminology out there that typically we’ll hear people maybe misuse the term or get confused between artifacts and other types of product approaches and what we’re doing in scrum. And I think the 2 most common areas has to do with something people will call requirement specifications or detailed requirement specifications. And usually what they’re referring to, and this is very typical of a project in a lot of large enterprises, there’ll be a requirement for a very large and detailed document that lists requirements in very minute detail.


A lot of times people call this a system shall document. It’s literally a kind of compendium of statements that all begin with “the system shall”. You know the system shall use a certain version of java or the system shall provide the following options, you know those kind of things. And while we are interested in that information, we’re only interested in it at the time it’s needed, so we might need to go to that detail for a particular testing of a feature. And we may have some of that information show up as acceptance criteria. But we don’t write a detailed requirement specification at the beginning of a project.


So that’s the one area and the second area is something called used cases. Somethings that’s been around for awhile and it even sounds a little bit like user stories. But used cases and user stories are definitely 2 different things. The used cases have been used in other project approaches, basically describes interaction scenarios between an actor or a user and a system. And it covers multiple scenarios. Usually there’s a happy pass scenario, which is the desired behavior, alternative scenarios when something goes wrong. And it will cover multiple features that are needed for example of a particular product. So in general, used cases are a lot broader than a typical user story is. And generally they are fixed at the beginning of a project and they’re signed off, and again with user stories we’re focusing on keeping things simple. And to use the term Agile, that can be updated and refined as we go through the project. Quite a difference from used cases.


Danny Ryan:Your bringing back some memories, I remember writing used cases and exception cases.


Bob Morris:RUP, remember that acronym?


Danny Ryan:Yes, we used RUP fairly, at Extreme Logic, which was the company Tommy and I worked at before this, and then we had a very that was our own at Pricewaterhousecoopers, so yeah a lot of this, your bringing back some used case memories. I’m not going to say they’re all pleasant, but they definitely came up.


Bob Morris:Yep, Yep, your not alone.


Danny Ryan:Not alone. You’ve been through that as well. You know, you also mentioned dispelling misconceptions about no documentation and wandering the woods. What did you mean by that?


Bob Morris:There’s again, people set of values and principles that are kind of part of core Agile. People will take those very literally. There’s one in there that talks about valuing working software over comprehensive documentation. And it doesn’t say no documentation, it just says you really want to focus on the thing that’s adding value which is working software. So we do have documentation, we talked about user stories, we talked about adding progressive information at the level required, we talked about being flexible and being able to add, if we need detailed test case documents, if we need detailed design documents, we’ll do that and attach them to the user stories as we proceed. But we don’t necessarily just spend a lot of time up front trying to generate those things. So in general at the end of one of our scrum projects, yeah I think the level of documentation will be less than other project approaches like a waterfall project approach, but that doesn’t mean that there isn’t any.


Danny Ryan:Yep.


Bob Morris:This last thing, wandering in the woods. This is really important because even though Agile and scrum are pretty mainstream nowadays, there’s still a preconception from some people that really it’s to loose of an approach to try and accomplish a project where your signing a contract or a statement of work. They think that basically there is no clear completion date, cost, or scope. Your asking stakeholders to just fund a project while the team goes through a journey of discovery trying to figure out how long it’s going to take to do something or how much it’s going to cost. That’s the term wandering in the woods searching for project completion. And scrum projects definitely have a defined schedule, scope, and cost that are clearly stated in some of the contract documents that we typically have. And we have an initial product backlog and a release plan as I mentioned that basically cover those things.


I think that the key to trying to use terms like flexible and rapid with also having specific targets for schedule, scope, and cost. The key to resolving those 2 things is in managing scope at the detailed level as these user stories are refined.


The last podcast I did with you talked about a mechanism we had for prioritizing and ranking user stories as we’re going through a project for managing scope at a very detailed level. And it turns out that is the key thing that allows us to delight a customer with where we end up in a project while at the same time being flexible and delivering according to a budget that we’ve agreed on up front. It basically relies on the idea of trading off high priority items that have to be supported with a project budget by deferring or eliminating things that may not be very high priority.


So we rarely if ever have a situation where we have a project change request to budget or schedule based on this approach.


Danny Ryan:And I’ve been just with some of the projects that we’ve been doing, especially with some of the migration work and things like that, we’ve been talking the strategy of how do we get enough details up front before we write a plan for how were going to, I’ll use migrations as an example.


So we’ve sort of broken it up into, we’re going to go do this workshop, which is sort of a fixed price. You get this out of the workshop and then out of that comes the plan for all of this. And the idea with that is that sometimes we can’t get all of the details during the sales cycle and it takes a little bit more for us to sit down with them and dig in a little bit deeper. But they may not want to, they want to have a fixed cost around that. And they want to know hey were going to go through this exercise here, your going to get this out of it, its going to cost this much, but then out of that we’re going to get a not to exceed budget for us to go after for the rest of the project.


I’d love to say that everybody buys off on this because typically what ends up happening is folks say, okay that’s great before I fork out the 10k for the workshop, I need to know what the overall ROM estimate is for the project. Are we talking 50 thousand dollars, 100 thousand dollars? Cause I am not going to do the 10k workshop and get to the end of it and you guys tell me it’s a million dollars and I have a budget for 100 thousand. You know, I’m not going to waste my time doing that.


But you know it seems, working with Bruce, we work very early on with trying to capture a lot of these details and for some engagements doing it like that 2 step where we have a workshop that’s a fixed price and then the rest of the project is more of a, its almost like I see them buying a team for a series of sprints to hit off a certain number of story points. And we’re going to be flexible is what we deliver, things are going to change. And then in the end your going to have to make some decisions about where to spend the money on the story points.


But giving that flexibility on the project, I think that really, I do a lot of the customer satisfaction surveys, and over all the process that we use, even more than the technology, is brought up time and time again as their favorite part of the project.


Bob Morris:I didn’t mention this Danny earlier but one of the things, we do have tools we developed internally to help us manage pulling together the user stories, the product backlog, the release planning discussions, we have some tools that we use to manage all that. It allows us to provide a very concise way of communicating an estimate back to a customer. A lot of times you’ll get somebody that really is having a hard time understanding the motivation for the cost for a project. And this provides a very clear kind of modular way for them to understand it. And if they want to influence it, you know start tweaking it. And we’ll work with them.


Danny Ryan:Anything before we wrap up here?


Bob Morris:Well I guess to be fair and to put this conversation in context. What we’re talking about here, first of all I know it was very high level and it’s very much sort of works great with our small and medium projects, there are other approaches and techniques that we would use for very large projects. That’s probably going to be for another podcast. But as an example a lot of time with large enterprises, they have a waterfall, overall a waterfall kind of program management approach and they may have certain artifacts or documents maybe related to requirements that we have to provide. When we get in those situations we will modify this process a little bit. Like you mentioned before, you talked about the idea of a workshop. Sometimes we’ll even have sprints that are geared towards generating baseline artifacts that are required for their process. But we can talk about that exciting topic in another podcast.


Danny Ryan:I can just see you writing the documents up as user stories as a overbearing product owner, I require, I want these documents to be done, why because I need this.


Bob Morris:My boss says so.


Danny Ryan:Cause my boss says so. Because we’ve always done it this way, because whatever reasons. But yeah I guess we could just write those up as user stories and have some obnoxious estimate towards them.


Bob Morris:And we laugh about it, but we, the people that we work with are really appreciate this kind of flexibility. But a lot of times they can’t control that process. And we have to support them in that. So we understand that.


Danny Ryan:Great job with this topic Bob, I really appreciate taking the time to come in here and do this. And I just continue to hear great things on projects that your leading up. And so thank you so much for doing an excellent job day in day out.


Bob Morris:Thank you. I appreciate it Dan.


Danny Ryan:Thank you everybody for listening and have a wonderful day. Thank you. Buh-Bye.


read more
Bob MorrisLow Friction Requirements Using SCRUM

Creating Value on Projects

Eric Bowden has over 19 years of software development experience around enterprise and departmental business productivity applications.

One of my favorite aspects of working within the framework of a scrum team at ThreeWill is the effort we take to ensure that the tasks to which we apply our best effort provide results which are the best value for our customers.

Consider the hierarchy which leads to a billable task hour: 

  • Vision/Mission leads to Objectives
  • Objectives lead to a Project
  • A Project leads into a Project Plan
  • A Project Plan contains Product Backlog Items (features)
  • Product Backlog Items lead into Tasks

There is a level of certainty, and thus uncertainty, at every level.  When I’m introduced to a project, I often remind myself believe none of what you hear and half of what you read, a variant of a quote by Benjamin Franklin.

Essentially, if I consider the hierarchy above for any endeavor, my understanding and/or the communication at each level could range somewhere between “completely wrong” to “mostly correct”.  Why?  Maybe I misunderstood.  Maybe these points were not communicated well. 

More often, maybe the authors of these points weren’t sure of the answers themselves (i.e. do not know what they want, do not know the objectives) and thus the points communicated were simply incorrect.  For example, maybe the vision/mission or objectives were set, but afterward, it was discovered that the vision/mission or objectives need to be corrected.

Of course, often, a plan is set, and we complete the project according to the plan.  But, what if?

Not a problem, this is where tight feedback cycles help.  Through daily stand-ups and weekly sprint reviews, the team lead(s) are having conversations, reviewing the product backlog, and reviewing sprint plans to be sure that we’re building the right software, heading in the right direction.  We may not be setting high-level vision/mission or objectives for a project, but we’re doing our part to contribute, be sure we understand, and make any adjustments if the vision/mission or objectives change.  The point is that we take steps to be sure we get it right and provide the best value for our customers.

Make the plan, throw away the plan:  It is very likely that what seemed like a good plan yesterday is not a good plan today.  Most likely, the plan will need a slight correction, and a larger correction may be needed too.  The sooner we can discover that an adjustment is needed, the lesser the impact.  As part of our process, we’re flexible, we’re open to updated ideas/direction, and re-planning, all to be sure we provide the best value.

read more
Eric BowdenCreating Value on Projects

Process Simplifies 700 Workflows to 80

Eric Bowden has over 19 years of software development experience around enterprise and departmental business productivity applications.

Danny :Hello and welcome to the ThreeWill podcast. This is your host Danny Ryan. Today I have Sir Eric Bowden here with me. Hello Eric, how are you doing?


Eric:Hey Danny, I’m doing great. Glad to be here.


Danny :I just knighted you, how about that?


Eric:That’s awesome. That’s fantastic.


Danny :Well, thanks for joining me in here. It’s late in the day so I’ve got my coffee right here beside me in case I start falling asleep. Hit me on the back of the head if I do, as well.


Eric:That’s right. It’s dim in here.


Danny :It is. It’s nice and relaxed.


Eric:It’s chill.


Danny :Yeah, it’s a little hot though. I guess they started turning the heat on and now it gets too hot.


Eric:That’s true.


Danny :Today, let’s just catch up. Let’s talk about one of the recent projects that you’ve been on. I know when we were talking a little bit earlier about it, you were saying, “Well it’s more process related than technology.” I’m like, “Babe, we talk about process all the time on this podcast. It just happens to be one of the ways that projects are successful, and usually the key way that a project is successful.” No issues with talking about process.


Eric:That’s right, that’s right.


Danny :Give me a little bit of background on the project. I know we’re not going to bring up the client name because just keep it anonymous, but just give me a little bit of background on the project itself.


Eric:Sure, sure. Yeah, and I think as I introduced … You and I were talking about it … I think years ago coding, programming, that was my hammer that I hit every nail with. As time goes on, process has really become my hammer. Not that many people know that, but that’s where I think that’s where the most challenges are on projects are around process. It’s more around identifying what needs to get done and tracking our progress toward that goal, and making good decisions as we’re progressing along. This particular project … It was a little bit of a mix of process and technology. There’s some engineering tasks, but it was a project that had started.


The client had been working on it internally for probably in the neighborhood of three or four months. It really didn’t have a lot of process around it. There were things that they maybe thought they were accomplishing, but really wasn’t being tracked. Just not really a feedback loop on the project. I got involved just maybe about a month ago now. They had a concern at the time was really more around architecture. This is a portal site. They use it to communicate with external entities and there were about 39 of those external entities, so they were going to have 39 portal sites. They’re using Nintex workflows for various purposes. The design path they were going down was leading toward a number of workflows in the neighborhood of about 700.


Danny :700 separate workflows?


Eric:Separate workflows. I’m looking at you to let that sink in. Exactly.


Danny :Really?


Eric:Yes. The project manager there recognized that, “Hey, wait a minute. I think we might have a problem here. This is going to be a maintenance issue down the road if you have that many workflows.” We had been working with this client, great relationship for years. They contacted us to come in for an architecture review. That’s how this started was an architecture review. This really wasn’t … We weren’t thinking process at the time, so I take a look and I say, “You know, recognize some updates that could be made. There’s some libraries and some workflows that can be combined and so forth.” We ended up with two workflows per site, per 39 sites, to make it-


Danny :Oh, I thought you were per 350 sites.


Eric:No, no, no.


Danny :I was like, Eric, well done.


Eric:Per 39. From an architecture standpoint, resulted in a net gain.


Danny :Where we’re down to 80.


Eric:Yeah, which is good. That is a reasonable amount because there’s some benefits to multiple copies of these workflows. That comes into the fact that the downside is that you have to change it across 39 sites, but the upside is that you can change it to one site without having an impact on all the others. That was a reasonable place to land, and the customer … I work collaboratively with the team so we had some really sharp folks, professionals on the team to work with. We all arrived at these enhancements together, but where that led to … It’s where I naturally gravitate toward, is thinking about how are we going to get this project to the finish line? What is this project? Where are we trying to go? How are we going to get to that end result? What we do to achieve that is we start building a product backlog. We’re into scrum process. I started building out a product backlog. My desire is …


I just love to see projects complete and fulfill their mission. That’s really where I was heading toward was hoping that the client would engage us so that I could help bring this project to the finish line. Ultimately that’s what happened. It was really a great way to lead in to an engagement. We started and it was a collaborative team. Me working with from a process side, from coming to architecture and a tech lead side. Helping them get to the finish line. They had engineers. They have a product owner and a QA tester. They had been working on the project previously and they continued. Just really an experienced team, so they just really merged in with the process right away.


Danny :Nice, nice. You like finishing things. You and Tommy would get along.


Eric:Yeah, yeah, we do, we do. We are such … I think of myself as a closer.


Danny :Yes.


Eric:And too, an obsessive degree sometimes.


Danny :I’m nothing without you guys. I need your help to finish things off.


Eric:You have that entrepreneurial spirit. You’re the opener of the possibilities-


Danny :It drives me as nuts as it probably drives you guys though.


Eric:It doesn’t me because I’m such a natural closer that I have to seek out those that want to open up and take some risk and so forth.


Danny :Always be closing Eric, always be closing.


Eric:That’s all right, that’s all right. No problem. I can’t help it. I can’t help it. Anyway, it’s been a … We’re just about a week from being ready for user acceptance testing.


Danny :Nice.


Eric:Yeah, it’s just been a really great experience.


Danny :Did you use two week sprints or longer sprints? What did that look like?


Eric:Yeah, we were on one week sprints for a short project like this, which I think it was about six weeks in total. We like short feedback cycles, so it’s just one week sprints. Of course, we have daily stand-ups. That’s an even tighter feedback cycle. Our tester was pretty much active. We were releasing builds, of course during the sprint. You don’t want that sprint reviewed and be the first time that you’re features are being tested or that your product owner is putting their hands on the end result. We had a very active product owner who was right behind the QA tester accepting the results. Really a neat model project for I think how a process can really make a big difference.


Danny :Did you feel like the project was building momentum once … Typically when you come in on a project that’s floundering you’re just looking for something to build some momentum to get you going in the right direction. Did you feel that way with this project? How did this end up?


Eric:That’s a really good point. I would agree that that is the case on a lot of projects. This particular one, and I pointed this out to the team, … I will tell you that within the first week the product owner was just amazed at the results. I know I’m patting my own back, but that was the feedback that I was getting.


Danny :Well you’re Sir Eric Bowden so you can pat your pack as long as you want to. Geez.


Eric:The reply that I gave was and it’s true, is that while this project was floundering, which it did for … Let’s see, gosh, in the neighborhood of six, well it might have been as long as six months. While that was occurring, what they were doing was they were refining the requirements. Now that you know the technology side was in the implementation side and the progress was zigzagging back and forth, but they were coming to a better conclusion as far as what they actually wanted. When I started, we didn’t have a lot of understanding requirements of them deciding what they wanted to do. That had already really been firmed up. That was a fantastic springboard really for me when I got involved and got the team organized and turned in a little bit different direction. It was just a fantastic springboard for us to really make great progress in the first week.


Danny :Nice, nice. Anything else that was unique about this project at all?


Eric:It was a decent combination of out of the box configuration with a little bit of app dev. There’s a little bit of custom code in the background for copying files, but mostly out of the box configuration and Nintex workflows. That allowed me to really … I’m the coder so I’m doing some coding on the project and then we had another engineer who was doing more the configuration. That was a good aspect of the project was being able to divide up and say, “There’s a ton of work that needs to be done here and it’s all configuration, and then it was less work needed to be done that was coding.


Danny :Was that another ThreeWiller? Who was that? Was it someone from their team that was helping?


Eric:Doing the-


Danny :Doing the config.


Eric:The configuration yeah. That was an engineer from the customer who had been involved actually to a lesser extent on the project as a head, you know initially started, and then that person became more involved.


Danny :Did we do the QA or did they do the QA?


Eric:No, it was their QA team. They had an engineer doing the configuration, performing the QA, and a product owner. Then me from the process and coding standpoint. We did have a ThreeWiller joined for a little bit for some of the Nintex Workflow support that was really useful. We had a couple of folks here who were doing Nintex workflows and just great to be able to add them all to the team briefly.


Danny :About to say, you sound like a one man turnaround artist. I don’t know if you want to do that for every project. You’re like, “Ah, this is just …” It can wear you out coming into one that’s floundering and trying to … That’s tough stuff. What project here at ThreeWill is easy? I’d like to see that one. I don’t know if we take on those types of projects around here.


Eric:I don’t know, I don’t know. It’s a finish line. You show me a finish line and that energizes me. It’s hard to turn it away honestly. I enjoy it. I love those kind of projects.


Danny :Well you’re awesome. We are so lucky to have you here Eric.


Danny :Appreciate you filling us in on this project. Love all the stuff you’re doing. I tried to slow you down with stuff about trove and channel but you just … I’m trying my best to slow you down but there’s no slowing you down man.


Eric:I own the target.


Danny :Well thank you for taking the time to do this Eric.


Eric:Sure Dan. Thanks for letting me.


Danny :I really appreciate it. Thanks everybody for listening. Take care, bye bye.


read more
Eric BowdenProcess Simplifies 700 Workflows to 80

What does Moscow have to do with SCRUM?

Bob Morris is a Project Manager and a Principle Scrum Master at ThreeWill. He has over 20 years of experience with successfully leading technology projects and teams in both project management and senior technical management positions. This experience includes delivery of software product development, enterprise software deployment and I/T infrastructure projects.

Danny:Hello and welcome to the ThreeWill podcast. This is your host Danny Ryan and today I have here with me Bob Morris. Bob, how are you doing?


Bob:Doing great, Danny, how are you?


Danny:I’m doing wonderful and you are, your title is Principal Scrum Master.


Bob:Yes. Yeah, it has a nice ring to it, huh?


Danny:Doesn’t it? When I’ve tried to say that I want to bow to you or I want to do some sort of … It sounds like a very official title, I like it. What we’re going to talk about today is some real world project management topics. I think it’s always nice to talk about reality, what is some of the things that you read in books and then you have the real world and how do we apply some of that to the real world? We’ve had plenty of discussions on this podcast about process and most folks know that we typically use Scrum on projects, which is one of the Agile processes that are out there. We actually had a conversation this morning with Rob and we were talking about how we combine some of these different processes depending upon what we’re trying to do.


What I wanted to talk with you was about Scrum, about how do we deal with the fact that things change? How do we continue to be flexible? What is it that we need to do in order to maintain flexibility in the projects that we have?


Bob:I think we’ll talk about one specific aspect of how we typically execute our projects and as you mentioned, we use an Agile Scrum project approach. I guess this whole discussion is predicated on the point that change is part of human nature. One of the things that we commonly deal with on projects is customers’ expectations get set pretty firmly upfront with our projects on features and functionality and cost and schedules, but the problem is, is that the detailed business objectives and requirements that go along with those expectations tend to change as the customer learns more about what it is we’re doing and they start seeing things actually getting a little flesh and bone on. This is all about how we deal with that.


I guess the central conundrum you have is something that relates to an old project management concept people from there with the triple constraints, sometimes people call it an iron triangle. Basically, it’s just saying that you’ve got scope, time and cost and that applies to any project. Doesn’t matter if you’re using Agile Scrum or any other approach. Typically a change in one of those areas and the most typical change is maybe an increase in scope, it’s going to impact those other areas. It can impact both of those other areas. Increase in time and increase in cost. In the real world and expectations that customers have, that’s just not a realistic way to deal with those kinds of specific changes that occur along the way. In other words, every time we have a change, we don’t immediately say that these other things, time and cost, you’re going to have to change.


Danny:Yep. Somebody the other day threw an iron triangle at my head and it hurt so much.


Bob:Yeah, they’re heavy. It’s heavy, yeah, it’s dangerous.


Danny:It is heavy. It seems like we’re going to … It is one of those tenants that you have to deal with that, but change is inevitable. It’s one of those things that just it happens and how do we deal with that in the real world? I know there’s a recent project that we want to dive into and let’s talk about how this played out with dealing with some of those real world constraints?


Bob:As you mentioned at the top, one of the most common approaches we use for our projects is Scrum, which is an Agile project approach. A lot of times, there’s a term that gets used a lot in Agile Scrum circles called the art of the possible. It’s something that we use to describe how this approach helps us cope with those changes. Essentially, what this phrase means is just all about avoiding perfectionism. Sometimes you hear people use the phrase, “Perfect is the enemy of good.”


We had a recent project and we’re talking about a project that had thousands of hours of human effort involved in it. It started out being something that was … It seemed relatively straightforward, a lot of it had to do with porting code from one platform to the other. Even in projects like that, that upfront look like they’re going to be pretty clean and no changes, inevitably you start getting these changes. People come up with ideas, they see new capabilities and a new platform they weren’t previously aware of. The team comes up with ideas as well. It’s not just the product owner, and so it’s inevitable that you’re going to have these changes.


Danny:Yep. I think one of the key aspects you’re hitting on is, is a project can fail if you’re inflexible.




Danny:It’s one of those things if you started out, you can be technically correct and, “Hey, you agreed upon this,” and when we’re working on projects, we do change controls, but we typically try to work with the original budget that was put in place and try to add flexibility as a part of the project, instead of trying to say, “Hey, you agreed to this in the beginning, we’re sticking with this and blinders on, we’re moving ahead.”


Bob:Yeah. That’s sort of the philosophy, but trying to make that actually happen, that’s where the art comes in, the art of the possible. Basically, the main mechanism we use for that, something that, I think, everybody is familiar with that has been involved in Scrum projects in the past is the product backlog. That’s the list, essentially, of the requirements that we need to fulfill in order to say, “We’re done with this project.” We use that product backlog in a very particular way. We call it ordering the priorities. It’s something we do on a continuous basis with our customers as we go through the project and it is what allows us to fight the good fight in terms of not letting perfect overwhelm the good enough in a project.


Whenever change occurs, we always respond with this technique of ordering the priorities. It’s basically, a couple of steps. The first step, I think, most people, again, that are familiar with Scrum are already aware of and that is assigning a priority level to everything in our backlog. There is a pretty standard way of doing this. We’ve subscribed to that as well, it’s called the MoSCoW method, which is just an acronym for must have, should have, could have. We even have a level called won’t have. We will include things in that backlog we won’t have just so we have clarity with our product owner or a customer on things that maybe were considered, but are not going to be in scope from the project. The way normally the projects work is everything that’s in that must have category, we know we must have them in order to say that we’re done with the project. Things that are in the should have and could have, those are the things that we might deliver if we have availability, a budget and a schedule permits. We’re typically trying to be optimistic on those things.


The problem with stopping there is it just doesn’t give enough information to the team on what they need to do day to day and the project to be efficient. There’s a second step to this, which is we actually go in and, again, this is on a continuous basis with our product owner or a customer and we order those backlog items with each of those priorities and we review those and basically, the order tells the team what to do first. This ordering is something that can be based on business or technical constraints. For example, we may say, “We need to build out some development environments before we can actually start creating the first bill.” Those 2 steps, that’s really the key that we’re using here to try and bring this concept of order the possible to the project.


Danny:A quick question. You’re doing this … We’re first working with a customer and we put together the initial backlog and then we have them, at that point in time, they’re the ones who decide which of those must have, should have, could have, won’t have, so they’re the ones who are setting that up. What stops a customer from saying, “I want all must have.” This may be just if everything’s a must have, then we’re going to set the budget pretty high, because we need to get all of that done, then we’re just factoring that into the overall time and cost of the project.


Bob:Right. I think the key to that is we align on expectations at the beginning of the project. We have a high level backlog at the beginning of a project. It could be that everything in there is a must have. I’ve seen some projects like that. It could be that there are things recognized upfront that from a business perspective, would be nice to have, but they don’t absolutely have to have them. They might not be in the must have category. The key thing is as we go through the project, we’re working off that initial alignment of expectations and we’re very protective about making sure that both, we and the customers are in agreement and alignment on what gets into that must have category for things that end up getting added to the project.


In some cases, we’ll go into a project and, again, you learn as you go. A lot of times we’ll end up there’ll be new items that may come into the backlog that a product owner makes a decision that actually that’s got more value to the business than some of the original things. This approach that we’re using here accommodates flexibility as far as that goes. As long as we’ve got something in must have and the existing backlog that we haven’t started on and there’s no dependency on other things, they could actually pull that out and substitute something of equal amount of effort and we’ll just absorb that change as part of the project.


Danny:Is this where you start talking about story points where you say you may be able to change one that’s of similar story points to another …


Bob:Exactly, yep.


Danny:Then I think it’s interesting that on the second step of this as well, it sounds like you’re looking at both business and technical constraints. I think some of the technical, what I would think there would be, you would look at the story points. What’s the estimate on this? Sometimes when you’re filling up that shopping basket, you might not reach for something that you know is really expensive when you could get 2 of something else. You are really factoring in both business and technical constraints to what’s the order of what I’m doing?


Bob:Yeah, it essentially boils down to taking what could be very big decisions in terms of cost and time and features and breaking it into a set of very small decisions. Then a lot of times, it’s much easier to make a bunch of small decisions than one huge decision. Certainly less risk.


Danny:You’ve mentioned an analogy with a house in a tropical rain forest. Tell me how does this play out to that?


Bob:Sometimes to try and give people and understanding of why we’ve got these priority levels and then we need to order those, this is something that’s pretty well-known, I guess in Agile project circles. It’s a house in a tropical rain forest. I think it’s predicated on the idea that there are many things you could think of that would be must have for that kind of a project, the construction, walls, roof, floors, all those things. There could even be things that are should haves, meaning maybe the decision between silver and gold-plated plumbing hardware or 10 year and 15 year shingles. Those things represent what we call the backlog. They’re really great guides in terms of figuring out what do you really need to get finished? To give the most value to a customer at a predictable cost and duration of the project.


Again, you could really make a mistake, for example, if you go in and the first thing you start doing is putting in floors. It’s in a tropical rain forest, so you’re going to get rain and it’s going to destroy the floor. You need that extra layer of information to order these must have items, so that you know well, you’ve got to put up 4 posts first and then put the roof on top of that and then you can start building the floor and the walls while you’re dried in. That’s the idea of ordering within the priorities.


Sometimes people wonder why you’re ordering things that are maybe in the should have category? As we’re going through the project, if we have something in a should have category and we have confidence that we’re going to get everything that’s in the must have category finished, we want to know, “Well, if we have extra time, what’s the very next thing we should work on?” We don’t want to have to go back and have a lot of meetings and discussions, so you order that should have list and the team knows they can just take the first thing off the list.


Danny:Another thing I like about this is that typically project … We’re talking like a project has a start date in day. Typically, what happens for us is we’re working on maybe the first phase of something and it might have multiple phases to it. What I think of is these must haves or what we have to have maybe for this first phase of the project. What I like about this is you all must roll very easily into the second phase and some of the should haves might become must haves for that phase, but at least you’re maintaining a list of …


This is a living, breathing creature that you’re creating and with it, there’s your first phase, you’re really just worrying about the walls and the roof and the floors, but then the second phase you’re worried about other things that pop up to the priority, but at least you’ve got them captured in the backlog and you go through it. I guess, that’s part of the planning for phase 2 as you go to the backlog again and then say, “What things might be must have that are in second phase?”


Bob:Yeah, in fact, it’s a good point, Danny. You talk about growth of the backlog in the should have, could have area. When we see that in a project, that’s certainly not a sign of poor health of a project. That’s actually a healthy project and it provides ways to our customers. Maybe they’re not going to do that now, but they’ve got a head start on planning and understanding what really should come next? What’s the next thing that could provide value? Even if it’s not something they’re going to budget for to do right now.


Danny:Excellent, excellent. It’s with having the requirements and ordering the requirements and knowing what’s going to happen next, it seems like there’s a better flow to the project, as well.


Bob:Yeah. Earlier when I was taking about splitting big decisions up into a bunch of smaller decisions, is sometimes a product owner will have some other stakeholder even come in with a new idea, something that really would improve something that we’re trying to deliver. When they look at that at a detailed level and they think about, “What will that mean in terms of trade-offs of other things?” If I want to stick within my current budget, maybe I can’t do that unless I’m willing to pull something else out. It really requires them to make those kind of value decisions at a very detailed level and they’re able to do that, other than just saying, “Everything that I previously identified, just do it, here’s a new thing, tell me how much it’s going to cost and we’ve got to go through the change management process.” It’s a lot more efficient way of trying to make those judgements.


Danny:For wrapping this up, let’s talk about a recent project that you had, it seemed like you had a relatively straightforward set of requirements. Tell me more about that particular project.


Bob:It certainly wasn’t one of our smaller project, we’re talking about thousands of hours of work.


Danny:I like this, I like this a lot. I wish this was our typical type of project.


Bob:This was, I think, I mentioned earlier, it was, initially we thought to be something that was going to be pretty straightforward, involves porting some code from an earlier version of an application over to a new platform.




Bob:The first priority is don’t disrupt the user experience. This should be completely transparent to users. It’s inevitable when you’re doing that work, you start noticing some of those little inefficiencies maybe in the application that you’d like to clean up, since you’re already in there working with the code or maybe you see a way to do something differently that could really leverage some new functionality of the new platform. That’s how those changes crept in there. There’s wasn’t a lot of wiggle room in terms of trying to add new things and there wasn’t a lot of wiggle room to remove things, because ultimately, we had to port over all the existing functionality to this new platform. We had, I guess you could say, scarce resources in terms of the ability to add things or enhance things in our project.


This worked really well, because it allowed us to be very, very smart with the scarce resources in terms of being able to add a few things that didn’t require a lot of work, but really had a lot of bang for the buck and we were able to do that. We ended up delivering this project, again, it was thousands of hours very, very close in terms of the original cost estimate, but it actually had some features and functions that were enhanced above what was in the original plan, so a pretty good outcome for everybody. Our product owner was able to point to sticking to our budget and, at the same time, his users were happy because they saw some changes and improvements.


Danny:I love a good, happy ending. Yeey. It seems to me that your role on some of these projects is really just to report reality. You’re almost that you’re trying to help the client make good decisions as you’re going along on this project. You’re guiding them and helping them to make sure that they’re doing the right things, with setting priorities, with making sure what we’re working on next is the next highest value thing for us to work on.


Bob:First of all, the Scrum Master name sounds strange to a lot of people that aren’t involved in this kind of work. The most common way that I tell people what it is, is it’s a coach role, it’s a coaching role. Our philosophy here is that coaching world is not just for the ThreeWill team, but it’s for our customers as well. We don’t take that responsibility lightly and that’s one of the things we do, is to help coach our customers through this process of making these smaller decisions that lead to really good, large outcomes.


Danny:Awesome, awesome. I think it’s a great way of ending this principal coach or I’ll just call you coach head coach.


Bob:Yeah, let’s head to the showers.


Danny:Okay. With that, let’s wrap it up. Bob, thank you so much for taking the time to do this, I really appreciate it.


Bob:My pleasure.


Danny:Thank you everybody for listening today and have a wonderful day. Take care, bye bye.


read more
Bob MorrisWhat does Moscow have to do with SCRUM?

Why the First Step is a Workshop

Tommy serves as the President at ThreeWill. In this role, he works with his leadership team to hire the best people, find the right business opportunities, and ensure that ThreeWill delivers for our clients on projects.

Danny Ryan:Hello, and welcome to the ThreeWill podcast. This is your host, Danny Ryan, and I have Tommy Ryan here with me, as well. Hello, Tommy.


Tommy Ryan:Howdy, Danny.


Danny Ryan:How you doing?


Tommy Ryan:I’m doing good.


Danny Ryan:Good.


Tommy Ryan:I’m doing good.


Danny Ryan:We’re on a Thursday afternoon. We’re usually getting together in the morning.


Tommy Ryan:Yes.


Danny Ryan:You’re like, “Yes, that is a true statement.”


Tommy Ryan:I love the obvious statements, yes.


Danny Ryan:Ah, well, you know, anything to get you to agree with me, Tommy.


Tommy Ryan:All right.


Danny Ryan:You can’t disagree with that statement that I just made.


Tommy Ryan:That is a correct statement.


Danny Ryan:You got fancy colored socks on today?


Tommy Ryan:Hmm, sort of.


Danny Ryan:Let me see them. Oh, that’s nice. That’s nice, it’s still conservative.


Tommy Ryan:Yeah. Okay. I have to go shopping, I guess. I’m running out.


Danny Ryan:You’re running out of socks. That’s okay. Today, let us cover, I actually want to write a blog post about this, but, you know me, my preference would be just to, why don’t we just talk about it?


Tommy Ryan:Yeah.


Danny Ryan:Which is, why begin with a workshop? Then we’re, on the website I, over the last couple years, this has been working out fairly well with us. I think it originally sort of started with the SharePoint Deployment Planning Services, and then, as we sort of built out package services for different service offerings that we have, but, you know, what we’re doing is really trying to take the typical project and break it off into two pieces.


One, starting with a workshop, a fixed-price, well-defined workshop, and then the second piece is something, you know, that the implementation itself, and something that is, sort of scoped and defined during the workshop. You know, just to get us kicked off with this, this sounds a lot like, I guess, with Agile, you have Sprint Zero. Are we, I guess, does that workshop itself, do you sort of see that as sort of getting through Sprint Zero?


Tommy Ryan:I think it has a lot of the same activities. I think structuring it as a workshop, what we’re trying to do in many of our workshops is take a subject matter or a type of solution, and really have a structured conversation that walks them through the things they need to think about. Things like the Jive Migration workshop, you know, that’s taking a known thing, going from Jive to SharePoint, and what are all the things you need to consider, and have a conversation around, before you know what you’re going to do going forward with that plan.


The workshops are trying to condense something that, maybe, would take, you know, two to four weeks, and try to do that in a matter of days, because we’ve honed in on what are the critical things you need to talk about. Yeah. Is it equivalent to Sprint Zero? I think it is, in a sense that you’re trying to establish a baseline of your backlog.


Danny Ryan:Yeah.


Tommy Ryan:A lot of our projects, we go in with a backlog, but we, you know, did that backlog at a level of estimation, and we need to confirm some things, drive out a little bit more detail, before we start rocking and rolling into implementation sprints.


Danny Ryan:Yeah, I think, you know, and we have, we’ve done it where we’ve tried to build out the product backlog in the whole estimate, and do that as part of the sales process, and what seems like, what happens is, we don’t, we’re not able to get into enough detail for that, or not talk to the right people, or for whatever reason, it just seems like, you know, we’re trying to put together a high-level estimate, but then, we don’t want to be too high or too low, and maybe having this additional time during the workshop allows for us to come up with a better estimate than if we just sort of did it through a couple sales conversations.


Tommy Ryan:Right. You know, the money for a workshop is, in the grand scheme of things, a small portion of what people are going to spend to go after that endeavor. When you’re spending money, usually, you can get more attention. I mean, even though it might not be a big dollar figure, it’s enough that people feel like, “I’ve got to pay attention, I’ve got to get involved, because, you know, there was money spent, and we want to have some answers coming out of that engagement.”


Danny Ryan:Yeah. You know how many times through the years this has happened, where you’ve had plenty of sales conversations, then when you get down to it, you get to the budget question, and they’re like, “We really don’t a budget for doing this,” and you’re going, like, “Well, how exactly were we going to do this, then?”


I guess with just doing the workshop, you’re like, you know, if you can’t put together, you know, typical workshops are, you know, they’re in the tens of thousands of dollars, you know, or like the Jive one that we have is right around that. It’s just, I think for us, it’s a little bit of a sanity check of, “Do you just want to talk about trying to go do something, or do you actually need to go get this thing done?”


Tommy Ryan:Yeah. I think that is a good litmus test, to say, “Do we want to spend time? Do we have approval to do this, or is this just an idea that doesn’t have any backing from leadership or people that have funds to execute against the idea?” That kind of vets that out. You know, from a standpoint of a consulting company, it allows you to go through the process of, “Let’s get contractual things in place,” and that’s a nice catalyst to get that done. Because, when you go into the full-blown project, you need to have that in place, and so if we get that done during the workshop, then when they’re ready to go forward, we’re not waiting for the contract process. We can move very quickly after that workshop.


Danny Ryan:Yep. Absolutely, absolutely. There’s a part of this, I think, as well, is, you know, when you put together the product backlog and put together the estimate, we have what we call ‘project factors,’ and with those project factors, I think we’re, you know, they’re different for each project, and I think a part of what we’re doing during the workshop is trying to figure out, how fast are we going to be able to move?


Tommy Ryan:Right.


Danny Ryan:We don’t know this until we start divvying some things together. You know, case in point, we’ve had some of these workshops where, maybe we need to get something, a piece of, a tool run on a server inside their environment, and if we’re asking them to do that, and they’ve got to get something done, and, you know, it’s taking a month and a half to get something, you know, set up for that, it’s going to impact when we go do this for real. Part of this is just knowing, how fast are we going to be able to move together?


Tommy Ryan:Right. It is, it gives us the ability to understand, what is the pace, what is the typical processes that are in place to get decisions made, to get things accomplished. At the end of the day, it is a team effort between you and the client, that, together we have to accomplish this. I mean, we can’t do it in total isolation. Working together through a workshop and having to get certain things accomplished during that, allows us to do a better estimate. It allows us to understand how fast or how slow we need to move to accomplish certain things.


That way, we can budget things appropriately and not over or underestimate things, because on either side of that spectrum, it can be difficult to adjust, if you didn’t calibrate to that early on. I think it’s, you know, getting a sense of, what is that environment like? So when we assign a team, we’ve got the right type of individuals that know how to work in that type of environment. Believe it or not, there’s environments that people want you to go a little bit slower.


We always think that we want to go faster and faster, but sometimes it creates strain, and you have to have people that have maybe a little more patience for certain types of situations. Then you need some people who are a little bit more aggressive, in other situations, so that’s the tricky part, I think, of success on projects, is knowing your customer, and these workshops are great ways for us to get to know our customer before we make a bigger commitment.


Danny Ryan:Absolutely. Absolutely. Anything else that you’ve picked up, I guess some of the, either pros or cons of sort of taking this, you know, workshop approach and then the full project afterwards?


Tommy Ryan:I think it’s really all positive things.


Danny Ryan:Really?


Tommy Ryan:I think, at the end of the day, it’s a pretty good sign to say, if we can’t go into that workshop mode, then maybe we can’t provide the value that they need, because I think these workshops are very high-value and very low risk, and if we can’t start there, then maybe we shouldn’t be, you know, starting at a bigger project that has a lot more costs and risks associated with it. It’s not every engagement we have starts with a workshop, but the ones that we have repeatable tools and processes around it that, we really need to calibrate to that, to be able to take that and make a big impact. The workshops are the best way to go.


Danny Ryan:Yep, yep. I agree, I agree. You also get a sense of, when you’re doing the workshops, are folks going to show up?


Tommy Ryan:Yeah.


Danny Ryan:I think it’s a little bit of a, you know, “How high of a priority is this? Are we able to get the right people together?” I think that’s very telling for us, as well.


Tommy Ryan:It is, and I think, what you can do is, get a sense of, you know, of pace. For an organization that you see it’s really hard to get ahold of people, then you know, okay, well, we’ve got to schedule all the Sprint reviews at the beginning, and lock in to everybody’s calendar. When we start saying, we’ve got to interact and have an interdependency with the customer, let’s, you know, be realistic about what that takes, you know. It’s not going to take a day. It’s not going to take a week. It’s going to take a couple weeks. It allows you to plan appropriately and make sure you’re planting the seeds early enough to be able to accomplish that and manage it for the customer.


Because at the end of the day, we’re coming in, and we want to be part of the solution, and if we come in through a perspective of, “Oh, it’s going to go fast and it’s going to be easy,” and we plan, and budget and approach it that way, we’re going to frustrate ourselves and we’re going to frustrate our customer. Having a chance to interact and get something accomplished with a customer before you make a big commitment, it’s a way to, it doesn’t guarantee success, but it definitely puts you in the direction of more success than if you go in cold turkey.


Danny Ryan:What I think is interesting is, this workshop is typically done for new customers, and I think it’s there to reduce risk and give us an opportunity to work together. They’re able to work with a couple of the ThreeWill folks and sort of try us out. It’s a way for new projects, and, as you were just mentioning, not every project starts out with a workshop. For a lot of existing customers, you know, we’re charging backlogs, we’re doing a lot of the things that are done for a workshop, but it may not be package. It may be packaged up more as the time and materials, and then we’re just getting together and spending, doing a traditional Sprint Zero, and doing what we need for getting ready for the project.


Tommy Ryan:Right, and that makes sense. I think, you know, that’s the typical path for a new customer. Would we ever not do that for an existing customer? I don’t think so, but I think it is so important to have that opportunity to work with the customer before we make a big commitment, and because the workshops are fixed-price, low-cost, it puts us in the position that we can sell, based on how we deliver.


We know, for us, that’s a great way to have a client understand the value we can provide. When you’re talking about, say, hundreds of thousands of dollars that you’re going to spend with someone that you haven’t worked with before, it’s a harder conversation to have, and it’s harder to convince people. If you show them, you know, how we can help, that allows us to build the trust that we need to enter into a bigger relationship, a bigger commitment.


Danny Ryan:I was just thinking, you know, sort of the other way that we’ve started doing work, which we typically, you and I typically are not, stay away from RFPs and RFIs and RF-what-do-you-want-to-call-it, and do that because it’s just somewhat set up to make everybody who’s bidding be the same, and there’s no real way to differentiate sometimes.


What we’ve also seen, you know, we’re a part of a recent RFP that was run pretty, I think it was somewhat, had some interesting aspects to it. Maybe we can talk about sort of that, next week, but sort of talk about how to run a successful SharePoint, RFP, and some of the things that we’ve seen different people do through the years, where it’s been better than the typical one that’s out there.


Tommy Ryan:Sure, sure.


Danny Ryan:I think that might be a good subject to throw out there, especially the recent one that I’m thinking of, might be good to bring up some points that came out of that.


Tommy Ryan:Sounds good.


Danny Ryan:Anything else, before we wrap up here, about the workshops, or anything you want to mention?


Tommy Ryan:No, I think we covered it. I appreciate having time to talk about this, Danny.


Danny Ryan:Absolutely. Thank you for doing this, Tommy. I appreciate you doing this. Again, we’ll, if you hear this, definitely come out to our website if you want to look at the different practice areas that we have. You know, we’ve got, really, the first area where we really put together some very strong workshops, are around migration. If you’re looking to migrate from Jive to SharePoint, we’ve got a great workshop for that.


If you’re just trying to move from SharePoint to a later version of SharePoint, I have a workshop for that. Also have, there’s a certain set of folks who are out there, especially the larger companies, who are on Office 365 dedicated, we’ve got a workshop about, some of those folks want to move over to multi-tenant environments. We’ve got a whole workshop around that. Come and check out our website, we’re also, you know, I have someone, have one for intranets, one for extranets, some for Azure apps, and for Office apps.


We’re really putting together a number of workshops that might be of interest to you. Again, the purpose around them is to keep it low-risk, and something where you can try out our services, and minimize the amount of time that’s involved with this, and really put together some solid plan for the project. Come out to the ThreeWill site, and go check them out, and thanks again, Tommy, for your time.


Tommy Ryan:You’re welcome, Danny.


Danny Ryan:Thanks, everybody, for listening, and have a wonderful day. Bye-bye.


Tommy Ryan:Bye-bye.


read more
Tommy RyanWhy the First Step is a Workshop

Using ASP.NET vs SharePoint on Projects

Tim is a Senior Consultant at ThreeWill. He has 15 years of consulting experience designing and developing browser-based solutions using Microsoft technologies. Experience over the last 8 years has focused on the design and implementation of SharePoint Intranets, Extranets and Public Sites.

Danny Ryan:Hello and welcome to the ThreeWill podcast. This is your host, Danny Ryan and today I have Mr. Tim Coalson here with me, the famous or infamous Tim Coalson here with me. Welcome Tim.


Tim Coalson:Thank you Danny. I think infamous is probably most appropriate.


Danny Ryan:For this podcast what we’re going to do is we’re going to follow up with one that we did yesterday with Mathew, since you’re working with Mathew. Yes?


Tim Coalson:Yep. Working with Mathew.


Danny Ryan:Awesome. In fact we brought that up yesterday during the podcast, which I’m sure you’ve listened to, right, Tim?


Tim Coalson:What podcast?


Danny Ryan:It was a podcast about the project that you and Mathew are in and on right now and we actually brought you up in the end and we had some nice things to say about you. Can you believe that?


Tim Coalson:It’s hard to believe but I will have to say that my customers apparently listened to that podcast and brought it up on one of our calls today.


Danny Ryan:We didn’t say anything negative about you Tim. For some reason, I guess it’s your great personality, you tend to take the jokes really well and put out the jokes really well around the office. Sure.


Tim Coalson:Yeah.


Danny Ryan:Awkward silence. Quite. Yes? Today, our topic. Since Mathew already stole the thunder with what’s going on with the project that you guys are working, we did a followup with him for folks who may have not heard that specific episode, it’s on a public facing site. Is that correct?


Tim Coalson:That’s right. A support site for tax and accounting software.


Danny Ryan:Excellent. A lot of our projects are using SharePoint for intranets, extranets, and then with these public facing site, we pointed this out with Mathew as well is that we’re using for this site for the web technology. Correct?


Tim Coalson:Right. In this case it’s a site that’s been out there a while. We were brought in primarily to do a rebranding of the site but over time we are starting to expand the site, to leverage some more current, I guess, back end systems. For example, now we’re changing the site and ya’ll probably talked about this yesterday, to integrate with Salesforce on the back end for case content as well as knowledge based content. We’re moving from integration with some homegrown systems that have been developed in-house to now using more standard systems like Salesforce.


Danny Ryan:The question I wanted to get to in this episode was, you’ve been our go to SharePoint front end guy for quite a while. I know you’re not into the graphic design but more into implementing it on SharePoint, but I wanted to get your thoughts on the differences between using versus using SharePoint on projects. It doesn’t have to be an expansive list, just some initial thoughts. It could be pros or cons about using versus SharePoint.


Tim Coalson:It’s interesting, with SharePoint, especially in large corporations or maybe even not even large, but corporations that already have a SharePoint presence, SharePoint as a corporate asset. One of the things about working on projects, usually we’re brought in by the business. We can focus on the business problems, coming up with a good business solution, and with a SharePoint infrastructure already in place we don’t have to worry about a lot of the logistics that we do in non SharePoint projects. For example, acquiring IIS front end web servers, worrying about a database back end. With a SharePoint infrastructure already in place, a lot of the logistics, a lot of the networking things that have to be thought about for a non SharePoint site, a lot of those have already been taken care of by the time we come in, because there’s already a SharePoint infrastructure in place.


Then, our time and energy is spent on providing a customer solution, working with the customers, understanding what the problem is, coming up with the appropriate list and other SharePoint configurations, workflows, to help solve that problem. With, of course the advantage to that is you’re not constrained by some of the constraints that SharePoint would put on you. SharePoint, especially Office365, some of the customizations are generally, don’t want you doing a lot of heady customization of the UI, because Office365 is a ever evolving platform. They’re continuing to roll out new features, so they don’t always guarantee from one day to the next that everything’s going to be the same. With for example, you’re in full control of everything that you do. Therefore you can come up with a more creative UI, use some of the more modern Java Script libraries to integrate. Even though you can use those with SharePoint, you’re not constrained by using a cloud platform that you don’t control. You have a lot more creativity that you can bring to the table.


Danny Ryan:Nice. It sounds like what I’m hearing you say is with SharePoint we end up being able to focus more on the business problem or the solution that we’re trying to create as opposed to, it sounds like with something where you’re starting from the ground up with, you’re having to put a lot of that infrastructure that’s typically already in place for the project.


Tim Coalson:Right. In some cases some of these companies already have that infrastructure in place so you’re possibly building on existing platform, IAS web servers, single server databases. In some cases a lot of that infrastructure may already be in place even for an solution. It depends on where they’re at. If you’re going to reuse existing infrastructure then you don’t have to spend and energy on that.


Danny Ryan:Mathew and I talked about, the process doesn’t change here. We’re still using scrum, we’re still doing sprints. Anything from your standpoint as far as the user interface, as far as mocking things up and things like that. Are you working with their graphics department? How are you working together with someone to produce out the screens?


Tim Coalson:Our initial work was a rebranding which we’ve rolled out that rebranding to production, now we’ve moved on from that to an integration but in the original rebranding we did bring in our graphic designer, one that we work with a lot, who has a lot of great experience building a lot of public sits. We came up with a lot of concepts. We looked around at some of the leading sites. Your Apple, your Google.coms and tried Linkedin as well, to try to leverage what are some of the more common metaphors that are being used on websites for notifications, for example, breaking new on CNN. We wanted to leverage that type of concept on our site so that when there was something important that we wanted to communicate to users, that we would have that banner across the top in red that would get their attention, but we would also allow them to be able to acknowledge that notification and then they would reclaim that real estate in UI.


We leveraged a designer to help us go through. We created various screen mocks and ran those by our customers, got feedback, made modifications and then also in this case, we had to work against corporate standards that had already been defined. They actually had a branding website that had a lot of details, color palettes and even more detailed design specifications that we had to adhere to. In this case it was bringing both our creativity but also leveraging their corporate branding assets.


Danny Ryan:What’s been the big difference from moving where you’ve been doing more about front end rebranding to more of an complex integrations on the back end? What’s been the primary difference? Has it been more communication or is it less communication? What sort of differences that you see as you move more into integration typed work?


Tim Coalson:It’s involved a lot of communications. Essentially there’s three teams. There’s the support site team, then we have a enterprise service bus team. They’re developing the services that we consume and then of course on the back end there was actually a group writing apex code in Salesforce who read and write data into Salesforce itself. Really trying to make sure from a interface perspective that we’re all in agreement as to here’s what the interface is and then as changes are made in each of the different levels, making sure that we’re all in sync in terms of the timing of those, so that all of sudden things don’t quite working.


Really a lot of communications that’s necessary. Then, even beyond the interface itself, coming to a common understanding about, from a business perspective, what is their requirements on the back end and making sure that flows all the way through. For example, today we were talking about dates. Salesforce stores dates in a UTC format. Part of our discussion was, how do we want to deal with those dates on the front end website? Do we want to convert to some common date that would be an offset of the UTC or do we want to have more of a localized date so that based on each user’s locations we would show that date for that person? Things like that have part of that conversation.


Danny Ryan:You’re focusing in on the integration. The site’s live. I found that out from Mathew. What’s the next couple of months look like for you?


Tim Coalson:Right now we’re integrating with cases in Salesforce, then we’ve got a second phase that will integrate with knowledge based content. Our knowledge based content will now come from Salesforce. Some of the next phases include some enhancements to the functionality today. Today there are certain payment options that a customer can go in, they can sign into the site, then they can set up different payment options. In the future we’re going to expand those options to include more options to pay, credit card typed payments. Be able to do monthly payments, things like that. We’re going to expand some of the user options to make it a more customer friendly site to give them the most flexibility and to allow them to be able to do that through an online instead of having to make a call into a call center.


Danny Ryan:Nice. We’re over ten minutes, Tim. Wasn’t that quick? That was painless, right?


Tim Coalson:Time flies.


Danny Ryan:Do you want to talk about the client is or how great Mathew is? Or, who do you want to talk about how great? Or how great I am, how about that?


Tim Coalson:Yeah. Obviously. We do have a good team. We do have a good customer. That’s certainly a big one. You are viewed as a partnership where your customer trusts you that you’re going to make good decisions, and you trust your customer. It does make for a much better working relationship. We have fun on the project. It’s a much better experience and I think the customer gets more out of it, we get more out of it. It’s all around a good relationship.


Danny Ryan:That’s awesome. Thank you for taking the time to do this, Tim.


Tim Coalson:Thank you.


Danny Ryan:I’ll see you in three months, then?


Tim Coalson:It’ll fly.


Danny Ryan:It will fly by and thank you everybody for taking the time to listen. Please drop by and have a wonderful day. Thank you so much. Bye bye.


read more
Tim CoalsonUsing ASP.NET vs SharePoint on Projects

5 Areas We Focus on for Managing Customer Expectations

Bruce is the Vice President of Delivery for ThreeWill. Bruce has over thirty-five years of extensive experience and proven success in IT Professional Services Management, COTS Product Development, Application Management and overall Financial Management.

Danny Ryan:Hello and welcome to the ThreeWill podcast. This is your host Danny Ryan. Today I have Bruce Harple here with me. He is the, and I’ve got a frog in my throat, he is the VP of Delivery for ThreeWill. Welcome.


Bruce Harple:Hey, Danny, good morning, glad to be here.


Danny Ryan:Excellent, excellent. What we wanted to talk about today was customer expectation management. This can go, I think, in a lot of … It’s probably, mainly process focused, but I think can really also focus in on some of the soft areas with regards to expectation management. I guess, just sort of get us kicked off with the subject.


Bruce Harple:Yeah, so yeah for me, customer expectation management in a service business is critical, right? It’s critical that we successfully deliver to our customers and that we meet and exceed their expectations. I kind of think about the tools that we use to help do that. There’s really 5 areas I wanted to talk about today. One is, and we’ve talked about this before Danny in a previous podcast, and we’ll summarize it, but just really how do we leverage the Agile, Scrum process, and really setting and managing customer expectations, especially around scope. Then I want to talk about risk management, and what we do there, and then talk about our weekly staff reporting, and how that’s evolved in to a more effective way to communicate risks, to communicate status to customers.


Danny Ryan:Great.


Bruce Harple:Then something we’ve started to do more recently is, is bi-weekly leadership status meeting, where we try to get up a level in the organization and really just talk about the rag status, and where a project’s at and what we can do to better collaborate together, and remove any impediments and risks that might be there, and then just really, at the end of the day, this gets in to more of the softer skills, but we have to adjust the way we deliver to our customers to better fit that customer’s, I’ll call it personality. Every customer is different, and the way you engage with them, and the way they like for their partner to engage is different. You really have to learn and understand those personalities, and adjust and adapt your delivery process to that customer. Those are the areas I want to drill in to today.


Danny Ryan:That’s great. Let’s jump right in to the first area.


Bruce Harple:The first area, talking about how we leverage Agile Scrum, and we’ve covered this a bit in the past, and obviously in Agile Scrum shop, and the key thing that Agile Scrum really helps us do is to really drives out the scope for a project. During a sale cycle, we build a product backlog, a product backlog contains a number of user stories. The user stories, just a definition of a customer requirement. Those user stories in a sale cycle are prioritized and they’re sized, they’re sized using a technique called story pointing, which we’ve talked about that in the past. Those user stories, and the story points assigned to them, and that prioritization, that sets the scope for the project. When we write a SOW, we references that product backlog, we reference all the user stories that were identified as must-have, and the size of those user stories. If all those user stories are up to 50 story points worth of effort, that’s our scope, right? That’s our baseline.


Danny Ryan:So you’re really from the get-go starting to set expectation around, this is what you’re going to get.


Bruce Harple:Yeah, not only this is what you’re going to get, but this is how long it’s going to take us to do it. Here’s how many Sprints it’s going to take to do it, so here’s your schedule, and then obviously we take those story points and convert those in to hours and dollars, which sets the budget. Those story points, that really drives that scope and sets that expectation, along with those user stories.


Danny Ryan:I like that you’re also from the get-go, you’re prioritizing as well, so you sort of know what’s important to the customer, sort of getting that up front so we can focus in on those first.


Bruce Harple:Yeah, it’s that concept of in the product world of kind of identifying that minimal viable product, that NVP solution, so what’s the minimum requirements that have to be implemented for this solution to really meet the needs of the customer’s business or to solve the business problem they’ve brought us in to help solve.


Danny Ryan:I know when we’ve talked previously, we talked about, and I’m sorry if I’m jumping ahead here, but like acceptance criteria. How does that feed in to this?


Bruce Harple:Acceptance criteria is a key part of that, so for every user story, we do identify what’s the acceptance criteria for that user story. What is it that the customer is going to look at to indicate that yes, I accept that this requirement has been successfully implemented. That’s a key piece of setting those expectations up front.


Danny Ryan:Great, so sort of how we run projects really is focused around expectation management, really is important to us.


Bruce Harple:Yeah, and then to kind of follow on that, during every Sprint review, throughout a Sprint, we always uncover new requirements, which is a new user story, which means new story points, and so part of the Sprint review and Spring planning process, we go through all the new requirments, all the new user stories with the customers. Maybe there’s 5 story points worth of new requirements that have been identified, so we sit down with the customer, we say, “These new requirements have been identified, 5 story points worth of work, how do these rank in importance to the other user stories that have already been prioritized and included in scope.”


If these are more important and you want to bring those in to scope, they have to make a decsion, are there 5 other story points I can now take out of scope because they’re less important than these new requirements, or they can optionally sign a change order, write an increase scope, which in turn increases budget and could impact schedule. It’s a great process, and we’re doing it as we go, so you’re continuously looking at that scope, continually managing that scope, but also given the customer, the tools and the information for them to make the decisions that are right for their business.


Danny Ryan:So you’re giving them the flexibility to switch out different items that are the same size, but then also if you’re running in to something where they really need to have something that’s larger, that hey, we’re talking this is apples to oranges, this is more scope or less scope, whichever one we might be talking about, but really trying to make sure that you’re not staying inflexible as needs change, as priorities change, we’re allowing for that to occur on projects.


Bruce Harple:Absolutely. It’s our job to the best job we can and educating a customer on the changes we’ve uncovered, what that means in the way of scope, cost, duration, and let them make the decisions that are best for their business.


Danny Ryan:Nice. Are we in to item 2 yet?


Bruce Harple:Yeah, why don’t we jump in to the next item is risk management. In any consulting world, everybody understands the importance of risk management. I think the key thing here is it’s real easy at the start of a project to identify, here’s the risks we see with the project, we have a lot of standard risks that we call out to customers, but the important piece is as part of that 2 week Sprint cycle, to continuously be looking at risk, and assessing those risks and raising those up to the customer. I categorize risk in to 2 categories, at a very high level. We either look at technical risk or business risk.


So for technical risk, the way we like to mitigate those risks … Technical risk tends to be there’s either some level of technical complexity, to implement a requirement, or there’s some level of technical uncertainty, maybe it’s something we’ve not done before, or it’s some new technology in the customer’s environment so there’s some risk associated with that. Most of the time, when there’s technical risk, what we tend to do is include user stories, we call them proof of concepts, like a technical proof of concept, to really eliminate that risk. Really, if there’s complexity, maybe there are 3 different ways we can implement a user story with different levels of complexity, different levels of cost, different levels of effort, and we mock that up in a proof of concept and then share that with the customer. Really, again, it’s all about giving them the information to make the decisions that make the most sense for them.


Danny Ryan:This sounds a lot like a spike, is that what we’re talking about here?


Bruce Harple:Yeah, exactly.


Danny Ryan:Excellent.


Bruce Harple:It’s a spike. With business risk, those tend to be focused around solution adoption, maybe you have a passive customer. There are customers that just don’t engage with us as much as we’d like them to engage, and that’s a risk, right? We want their feedback, and as you know with Agile, we want them involved every 2 weeks in our Sprint reviews, we want them re-planning with us. It could be organizational churn, right? Right organizations change, there’s mergers that take place, acquisitions, business processes change. For the business risks, I think we tend to really focus on very specific mitigation plans. Each of those risks tend to be different. They’re not as … With a technical risk you can do a spike, you can do a proof of concept, there’s some things you can do to mitigate those risks. With the business risk, each one is unique, and I think you do have to have a mitigation plan to address each of those risks. It’s important, I think a lot of times it’s easy to not think about risks on an ongoing basis. We try to be proactive in that, and try to stay on top of that risk management, because it all relates to, am I going to successfully deliver this solution at the end.


Danny Ryan:Is this a share point list that’s up on the extranet, or how do we communicate what the risks are to customers? How is that typically done?


Bruce Harple:Two ways. It is on our project extranet site, which is kind of the collaboration sites we establish to collaborate with our customers. We’re very transparent, so we let our customers see everything associated with the project. Then it’s also what we call our weekly status reports. Which actually leads to the next item, number 3.


Danny Ryan:Number 3? Let’s go to number 3.


Bruce Harple:Great lead in. The third way of helping us expectations with customers is through weekly status reporting. Any consulting firm does that. When I think about weekly status reporting, the old model that we used, and even the old model for ThreeWill is, we did a brain dump on, here’s everything we’ve accomplished in this past week, here’s our plans for this week, and they were lengthy. In today’s world, executives and leaders, time is precious to them. They don’t have time to read a lengthy status report, and we’ve gone to a model of what we call the rag status, it’s red, amber, green. We look at 5 key metrics for a project, which it’s scope, schedule, budget, customer dependencies, and external dependencies. Really, for an executive, our goal is that when they look at a status report, it’s colored, so they’re looking for anything that’s yellow or red. If they get a status report and it’s all green, they might not even read any further. They’re done. I’ve had customers tell me, “I don’t even read your status reports. There’s too much detail.” Now we’ve moved to just this very concise rag status type of reporting. It’s much more effective for them, they appreciate that, and it saves them time. If there’s something amber or red, I do get emails from customers saying, “What can I do to help that issue?”


Danny Ryan:This came from like a project retrospective where people were saying … It’s funny, I’m thinking of a quote that I saw recently, which was something to the extent of, I didn’t have time to write you a short letter, so I wrote a long one. Basically, sometimes it’s more difficult to condense the message of what you’re trying to give to somebody. But you were saying this came out of a retrospective where people were saying, “I just didn’t have the time to get through the status report?”


Bruce Harple:Absolutely. We do project retrospectives at the end of our projects, and that is the kind of feedback that we get from customers. In the way of being more precise and more crisp in our communications, and just looking to save them time.


Danny Ryan:Awesome. Are we on to 4 yet, or are we done with 3?


Bruce Harple:Yeah, I think we’re done with 3, and 3 kind of feeds in to 4, in that something that we’ve recently started doing, recently being over maybe the past year to 18 months, is scheduling what we call a bi-weekly leadership status meeting. The intent is to on a bi-weekly basis kind of move up a level in the organization, to an executive level, above the people you’re working with as product owners and maybe sponsors. Really taking that rag status that’s in a status report and really reviewing that at an executive level. So that you’re making sure that that visibility in to, especially anything that’s amber or red, that you’re making sure that that visibility is getting pushed up in to an organization. The other thing we do is we call up any new risks, and we talk about that. We talk about any critical impediments the team might have and how we can collaborate together as a leadership team to solve those impediments.


We also share observations. A lot of times there could be ThreeWill consultants that aren’t meeting a customer’s expectation for some reason, and we want to know that. We want to know that sooner rather than later. In some cases, the same thing applies on a customer’s side. There might be somebody on the customer’s side who’s not doing the things that we need for them to do to keep the project moving forward. We want to have a transparent, very open and honest conversation with our customers around those kind of things. If there’s things that we could do better or they can do better, to make us more effective as a team, as a collaborative team, we want to be able to call those things out in a non-threatening way, in a way that we can all work together and get better at what we do. It’s just another great way of getting executives visibility in to what’s going on, but again, trying to do it in a way that it’s a 30 minute conversation, it’s really focused on the key things that require discussion, that require some decision making, and really just collaborating with that customer.


Danny Ryan:It’s funny, before this conversation, I don’t know if I’d heard the term rag very much, so it’s red, amber, green, so folks who are wonder what’s rag status, what does that mean. It’s basically a stoplight.


Bruce Harple:Yeah, it’s a stoplight metaphor, exactly.


Danny Ryan:Got you. Excellent. So this is wonderful. I think raising it up too also makes sure you have the executive sponsorship of this, isn’t going to be sideswiped later on and find out, oh well we had this problem. Everybody has concerns sometimes about raising things up, but it’s important every other week. Is this done at the end of the Sprint? Since we have 2 week Sprints typically, is it something that’s done at a certain time during the Sprint?


Bruce Harple:We don’t tie it to the Sprints at all. It really is tied more to availability of that executive team more than anything else. We all know they’re busy. They are more than happy to engage, and most executives want to solve problems. If there are issues that the team is having, and if it’s issues over things they control, they want to know, and they want to know how they can help, and they’re more than happy and anxious to help remove any barriers, remove any impediments that the team might have. We’ve found them really valuable in keeping those expectations set, making sure that we’re collectively mitigating risks, solving and removing impediments, and making sure that things are on track.


Danny Ryan:Excellent, and we’re to number 5. Number 5.


Bruce Harple:Number 5. I talk about the personality of a customer, right? Every customer is different, every customer is unique. The way they engage with their partners is different. Examples might be does the customer want you on site, do they prefer remote? Are they more responsive to email or telephone calls? Meeting times and durations? Are they detail-oriented, or are they just give me the big picture, give me the net of what I need to know, and the decisions I need to make. What is their decision making model? It’s important for us, as we go through a project, to learn more about that customer, about their personality, about the way they engage, about what they like, what they don’t like, and how they respond to us. Really adapting our process, adapting the way we report to them, adapting the way we communicate with them. A big part of this is something that I talk about with our principle consultants and our Scrum Masters, it’s what I call situational awareness, right? I kind of captured the definition of situational awareness. It’s a military term, or an aviation term, but it applies to business, and your interaction with customers.


It has 3 pieces. The first one, by definition, is perception of the elements in the environment with a space. It’s perception of that customer’s environment. It’s perception of the way they engage an environment. Perception of the body language that you see with that customer. With the intonation with that customer. Then there’s comprehending that meaning that’s part too, so really understanding what is that message that the customer is sending to me, either directly or indirectly. Then the third part of it is projection of the status of that situation in the future, so truly understanding how do I need to adjust to that situation. It’s really just shifting expectations and making sure you’re aware of the situations, the events, the dynamics that change throughout a project and change within that customer’s business, and really making sure you’re really aware of that. It’s having radar and being sensitive to that, and being able to adapt to that. That’s a skill that is learn and developed over time. It’s something that we talk a lot about.


Danny Ryan:It’s probably something you end up having to coach individuals on as well, is maybe after a meeting talk through what happened in that meeting and trying to make sense of it, because we are a … Tommy and I are engineers, and typically engineers are a little oblivious to sometimes what else is going on in the room. They’re very focused in on what’s the problem and how to solve the problem, and so sometimes some of the soft dynamics of working with teams, with individuals, sometimes are missed. So really love that you’re focusing in on this.


Bruce Harple:Yeah, and you know the consultants at ThreeWill, they all are consultants that want to please their customers. They want to make the customers happy. A bit part of that is making sure that the leadership here at ThreeWill, the people engaging with the customer and setting expectations, that we’re really continuously managing those expectations, because at the end of the day, we want our customers to be happy, we want to make sure we solve the problem, the pain that they have, and that their lives get better at the end of the day.


Danny Ryan:Bruce, we are so fortunate to have you here at ThreeWill, because you do such a great job with managing expectations with customers, and just they come out of projects thrilled, and we just hear so many good things, and it makes it so much easier on Tommy, on me, on everybody at ThreeWill, so thank you for having such a great focus in on this vitally important thing to us. If our customers are not happy, we’re going out of business, and going out quickly.


Bruce Harple:Absolutely.


Danny Ryan:It’s a huge reason why we’ve been in business for so long. It’s a huge reason why so many people like to come back and work with us time and time again for different projects that come up, so thank you so much, Bruce.


Bruce Harple:You bet. I’ve enjoyed it.


Danny Ryan:Thank you for taking the time to do this as well, and I hope everybody got something out of this. Especially if you’re in the situation either where you’re working with vendors, or you’re a consultant yourself and trying to work through how do you manage customer expectations, that this was helpful for you. Thank you so much for listening to the ThreeWill Podcast, please drop by our website,, and have a wonderful day. Thank you so much. Bye!


read more
Bruce Harple5 Areas We Focus on for Managing Customer Expectations

Creating a Lifestyle Business

Tommy serves as the President at ThreeWill. In this role, he works with his leadership team to hire the best people, find the right business opportunities, and ensure that ThreeWill delivers for our clients on projects.

Danny Ryan:Hello and welcome to the ThreeWill podcast. This is your host Danny Ryan, and I have my co-host here with me, Tommy. How you doing today?


Tommy:I’m doing great, Danny. Good morning.


Danny Ryan:Yeah, missed getting together last week. It’s nice having some little bit of time sitting down with you every week. It’s a nice thing.


This week maybe it’s a little bit of a followup from other conversations that we’ve had. I just wanted to spend a little bit more time on it, which is talking about creating a lifestyle business.


We’ve talked about the history of the company and the evolution of the company over time. I think one of the things that has had an impact on us as a business as far as where we are today is this underlying goal for us to create a lifestyle business.


Guess just to kick this whole thing off, when I say a lifestyle business, what does that mean to you?


Tommy:I don’t even think about creating a lifestyle type business, more of a business that supports a work/life balance, your personal goals, your work goals, career goals and keeping it balanced between those two. It’s not all about work, but it requires commitment to work. You are leaving room/margin for your family, your significant others in your life. The other aspect is being able to enjoy where you work, creating a good company culture. I think we all think about, “Are we keeping a good culture at ThreeWill?” I think a part of that great culture includes work/life balance. Those two aspects together probably define a lifestyle business at a high level.


Danny Ryan:Consulting is a tough business. You are constantly having to reinvent yourself. You need to stay ahead of your customer. It’s a difficult business to be in. How does that factor in to the core business that we are in and continuing to keep a balance and creating an environment where people can stay balanced in that environment?


Tommy:You have to be very intentional about how you structure a company that will be a lifestyle type business. When you look at consulting, it really goes against the grain of a lifestyle business in a lot of aspects because the economic engine is, the more you work, the more money you get. The existence of a business is creating profit. When you look at how do you create more profit, you work more hours. That doesn’t play in well to a work/life balance. We have been very intentional about how we set up utilization, how we set up how people take vacation, what roles people play in the organization so they have enough margin to play the roles that they had outside of projects. Those are the important aspects to say we have this goal, it’s a reasonable goal to achieve, and at that goal, we are healthy as an organization. If we go beyond that, we are going to go out of balance. Let’s be careful about the incentives we put in place that bring us beyond what we think is a good target to be healthy and be able to function well as an organization.


Danny Ryan:That’s great. I want to dive a little deeper in to these different aspects. The first one I’d like to get in to is with the roles, how do we set this up so that somebody who is a principle consultant has time that’s on projects and has time that may be doing pre-sales or other activities? How do we structure the utilization to allow for that to occur?


Tommy:We just do some simple math. We look at how much time do we need on average from someone playing a principle consultant role to be in sales and marketing type activities. Inspect what that really is year after year and calibrate to we need 8 hours a week to support sales and marketing functions. We will adjust the goal to say let’s provide that margin for the person that’s doing that more often. Everybody works on sales and marketing activities. Everybody is doing blog posts. Everybody will occasionally go to a sale’s call. We ask of our principles more time towards that. We’ve given them some margin to allow them to do the activities that help feed that next project. If they put all that time and energy towards just billing that’s great for the existing projects, but where does the next project come from?


Danny Ryan:Their expectation is a certain number of hours, something less than 40 for billable. A certain other portion of hours, the expectation is to be working on pre-sales and other activities that they have out there.


Tommy:That’s right.


Danny Ryan:It’s almost like they can on a weekly basis be looking at what hours they are spending towards what and making sure they are allocating their hours appropriately.


Tommy:Right. I think naturally a consultant will think about how many hours am I billing? We constantly have to remind people that we are carving out time. We are saying 8 hours. When there are times that the principle consultant needs to help, we try to take away that stress of “I need to bill.” We’ve set aside time to do this activity. It’s accounted for, and we can do that without impacting the overall team. We do have a team goal. Everybody gets compensated on our variable comp based on the company making the utilization. There is a tension that, I want to make my goal because I don’t want to impact the rest of the team. We want to make sure that we are adjusting those goals based on where you are in the roles that you play in the organization. We have one person in our organization that is putting some effort towards supporting our interns. We have three interns this summer. Two of them are technical interns. The technical interns-


Danny Ryan:Austin’s pretty technical, too. He’s getting technical. I’m bringing him over to the dark side.


Tommy:I saw he just got certified in Google AdWords. That’s more than what I have.


He needs to invest some time there. We are carving out a certain amount of time so he can invest in to the interns, so they can have a positive experience, and we can have more progress in what they accomplish this summer.


Danny Ryan:I think that’s key because if you just keep on adding these expectations and roles to people, and you’re not really factoring that into their work week, then you overwhelm people. I think it’s important that you set this expectation of saying, “It’s going to take some time for you to go do this, so we are going to pull some time out of your utilization that you would typically be spending on projects to go and do this.”


Tommy:We think people are doing things outside of billing so we create some of that margin to do those day to day things outside of billing. It’s when we get to a point where we’re going to intentionally pull you into a lot of activity that’s going to take away from your time to bill. Then we say, “We need to adjust that, so you can have your work/life balance.”


Danny Ryan:Great. The other thing that I want to talk about that relates to this is how does PTO factor in to this and also a little about VTO as well. I think that helps with understanding our culture and so maybe let’s talk about that for a little while.


Tommy:Okay, so PTO … We’ve changed this over time. We’ve inspected and adapted. We originally had a utilization goal, and it was based on this is the goal for the year and total hours and let’s just break it up and spread it across week after week. When you were working, you would go way above that because we spread that across the year. When you would take vacation, all of a sudden, your utilization would go down. We adjusted it where when you’re taking PTO where there is a holiday, that counts as a 8 hour day. That’s not necessarily rocket science. Other consulting agencies do that. We made that adjustment being new to how to run a consulting business. We said that’s not creating work/life balance. If someone is right on the edge of making their utilization goal and then they have an important family thing to do and it requires PTO to take that, then they are in this tough decision of do I let down my team and myself from a compensation stand point or do I go take this vacation? We have created it to where when people go on vacation it does not tank our utilization.


Last week we were expecting something like 90, and it ended up to be 100. We said, “Oh yeah, Eric took vacation this week.” That actually helped in utilization because he didn’t have a project on the horizon. It also encourages when people are off projects and they have PTO built up, to go take that PTO. You can, when you are not assigned to a project, get that done. That keeps the utilization up. I keeps us from building up a lot of PTO where people are getting out of balance because they never take that time to take the PTO. I can never take that opportunity to do it because I’m going to let down the team if I go take PTO.


The other thing that you mentioned, VTO, something that has come though the ThreeWill Foundation that you’re leading up. That ThreeWill Foundation … One aspect that we have is, “Let’s give back to the community.” That’s Volunteer Time Off. It acts just like PTO. When you take that time off, it’s like working for a day. It doesn’t count against you. Your utilization stays up when you take that time off. People even struggle taking that time off because when they are on a project you always have that tension of I don’t want that project to fall behind. We tried to create incentives that will lean towards a work/life balance. We know we hire people that are driven and so we don’t have to worry about the stick mentality of driving people as much as let’s give you that balance so you continue to stay driven and not get burned out.


Danny Ryan:Nice. The thing I liked as well is how things are set up around here with regards to sprints and capacity on sprints. If you know you are going to take some time off, they know not to assign you what can’t get done within those 2 weeks. I like the whole idea of capacity and seeing what the team can do. It’s almost like we’ve got this built-in mechanism to not over-commit ourselves on projects.


Tommy:It’s beautiful because you can get in to situations where you over-commit. That two week sprint, by the end of it, it was tough. You maybe put in a lot of extra effort to get there. Maybe you just didn’t get there. Now you go in to the next sprint, you can re-commit. What am I pulling in to this sprint based on what I’ve learned from the past and what types of adjustments do I need to make. Some of those adjustments are someone needs to take a day off. Something’s coming up personal. There’s a funeral. You can’t control those things. As they come up, you go into the next sprint, you can plan for those things. You can say you want to have less capacity from the team, so let’s not over-commit and create undo stress to the team when we know we only have this capacity.


Danny Ryan:I think that really helps because there will be stressful times on projects where things need to get done. Often in consulting you have death marches, which is the next 6 to 9 months will be horrible and the team knows it. I like it that we don’t commit ourselves to things like that.


Tommy:I think we are very good about avoiding death marches. I think it’s our attitude. I think it is our methodology. We’ve been in a lot of situations where it can naturally lead to a death march. You just have to be brave enough to make the right decisions along the way. In our culture and our process thinking encourages us to make those tough decisions so we don’t create a death march situation.


Danny Ryan:One of the things that I really love that Bruce focuses in on when he’s putting together product back-logs is making sure we have the acceptance criteria. I think a large part of the issues that people run in to are either making vague commitments or not really being up front about what they’re doing, what is success on a project or in a sprint. He takes the time to go in and make sure we have acceptance criteria. Acceptance criteria for folks who are not familiar with Scrum is basically saying you write a requirement typically in the form of a user story and you say if I’ve done this, this is acceptable to both sides as far as what should happen. It’s something where you are saying if this is done properly you and I can both sit down and look at this and say, “Yes, we’ve delivered this.” The reason why I like that is because it’s begin with the end in mind. It’s talking about if I’m going to do this thing, what is success for getting this one user story done.


Tommy:I think that keeping a work/life balance … A key aspect of that is being good about setting expectations. Setting realistic expectations that we can meet or exceed. That keeps the relationship going with our clients. It also helps our teams not get out of balance because there’s implicit expectations that we really don’t know and we are figuring them out along the way. There’s always a little bit more, a little bit more versus saying this is our goal and let’s achieve that goal. If we want to go after a new goal after that, that’s fine. That might require different resources, maybe more time or budget. Let’s achieve the goal that we set out to do.


I think that what we are finding, and I don’t want to go too far down the process route-


Danny Ryan:That’s fine. It always leads to process. It’s fine with me. I brought up the dirty word, so you can continue.


Tommy:I think we are moving towards doing more envisioning type engagements. It’s seems a little counter to Agile, but what I think it does is that, one, it blows out more detail around what is the goal. Not getting into the nitty gritty wasting detailed design around something that we really don’t need to go that far until you get to the point of you’re going after it in a sprint. When we do these envisioning engagements, one, it builds a relationship. It gives us an understanding of what’s important. It allows us to get what those expectations are. That way we can go in to a project really setting ourselves up to exceed expectations. Otherwise, there’s a little bit more of a shot in the dark. Our Agile estimations I think have been great, but every once in a while you get something where the customer, not intentionally, just doesn’t show you all of the detail. You estimate it based on what you see. If you do that in a couple of hours of exposure to the business problem, you’re at risk of missing some things. We’re starting to think more about what is that small really fixed cost so there’s low risk investment from the customer for us to work together to set those goals of what is success.


Danny Ryan:Austin, we are not running sprints, so we are not quite there yet. We are doing daily stand ups. That helps for us to adjust a little bit. I’ve been throwing a lot of things at him and we’re seeing what sticks, what doesn’t stick. In order for us to make some of the adjustments, we’re just getting together and doing daily stand ups and that’s helping us. We have some overall goals for this internship but then tracking along the way, it’s nice to do the stand up where you’re getting together and talking about what happened yesterday. We both look at each other like, “I know I worked hard yesterday, but I can’t remember what happened yesterday.” To me, the important part is talking about what are you doing in the next 24 hours as well. Taking a little bit of forethought and saying marketing is tough because you aren’t sure where you are going to get the most value out of what you do next. You are sort of weighing a bunch of options out there. I think the two of us just talking through, well, I can focus on this and I’ll go after this has helped us out as well expectation-wise. We may add some other Scrum stuff in to our stuff maybe.


Tommy:Now do you actually stand up during your stand ups?


Danny Ryan:Do we stand up, Austin?


Austin:We do stand up.


Tommy:We are going to have to teach the delivery to you about standing up.


Danny Ryan:A lot of this original idea with the lifestyle business came from you and I, early conversations where we were really challenging ourselves to say can we … We love what we do at work. We are very passionate about what we do at work. We wanted to at the end of this all to have also a great relationship with our wives, a great relationship with our children and not miss the important things in life. I think that’s a large part of why we’re trying to create this lifestyle business. Because of the choices that we’ve made, we’re at a point where we’ve been in business for 15 years, we’re a 30 person company, we’ve got just the greatest people who work here. I love the people that we’re able to work with. We’re not huge. I think that’s part of some of the decisions that we’ve made and that doesn’t drive us. It’s more of what is the environment around here than how many people we hired last month.


Tommy:Also, I get a kick out of the companies we work with and the type of work that we do is at such a large scale. We go in to organizations and do things that the large Fortune 100 companies that these large consulting companies can’t do at the level of success that he have. That’s exciting to me. It’s a little bit of the minimalist attitude, less is more. When we do have such a really tight team, we can go in with confidence that we’ve got an A team every time we go in. That gives you less stress. I was actually having breakfast with Bruce this morning. When he’s in town, every once in a while, we’ll go out and catch up. I’m sponsoring Bruce and just there to make sure we take some time to just talk because we have a lot of work that we do day to day. We were just reflecting on what we like about ThreeWill. It really has been people caring and people that get the job done. We always feel that we don’t go in to projects worrying about do we have a team that can be successful because we have such great people. That gives a lot of job satisfaction.


It’s one of those things that from a work/life balance the thing that we give back to the people at ThreeWill is we’re not putting them in a situation where they’re going to regret I didn’t take time to be a part of whatever is my personal life … If that’s a family, if that’s friends … Whatever that is. We didn’t create a situation where they could not do that. To be able to run a business and have people that get a good compensation, a good work environment, and they can be connected outside of work … That’s so much better than running a business that we get to the sides of a censure. I see more success. I see more fulfillment out of that. I don’t want, and I think we are both like this, we don’t want to look back and say, “We did this professionally, but we have a really messed up personal life.”


No one has a perfect personal life, but it’s hard enough to do it without having a work situation that pulls you in and doesn’t give you that opportunity to at least try. We want to give everybody at ThreeWill that opportunity of you can come in and work your butt off and really do a great, bang up job, do some awesome things, and you can have a personal life where you actually make an impact on your family and your community. I’m proud of that, and I know you’re proud of that.


Danny Ryan:Absolutely. One last thing. I think you and I could probably talk for a while about this subject. It’s been a great subject. You mentioned sponsors and how does that fit in to this? The idea of sponsors came from the both of us from some of your interactions at W.L. Gore. When I worked at Intel, I had a sponsor and it was a different concept than this whole manager concept. How does that fit in to this whole idea of a lifestyle business?


Tommy:It fits in to a lot of aspects. As it relates to lifestyle, it’s the culture. It supports the culture of we want people to choose to succeed. This whole free will thing. That’s an important shared value for us. We want an environment that people are self-motivated, that will naturally choose to do the right things. In the boss environment, a highly hierarchical structured environment, you tend to back off on that free will aspect and the way you run your business. Having an upside down type of approach in terms of how we structure people leading other people, having sponsors, allows us to help people be successful. At the end of the day, I think it’s a culture aspect. Work/life balance, I don’t know if it really “impacts” that, but as it relates to feeling like I come in to work and I don’t have anyone telling me something to do. More of an autonomous type of environment. We attract people in our type of work. We are problem solvers. We don’t want things to get in the way to that problem solving. There’s enough challenges at our clients’ environments that we don’t need to add any more of that barrier to be successful.


Danny Ryan:I know for me as a sponsor, I feel like one of my roles as a sponsor is almost like an accountability partner for making sure that they’re staying balanced in their life.


Tommy:It’s true.


Danny Ryan:I’m fortunate enough to sponsor Kirk. There’s times in which he’s very passionate, very –


Tommy:He’s one of the hardest working people here.


Danny Ryan:Hardest working people here. When I check in with him, I just want to make sure you are not over-committing to things and making sure you’re not working too many late nights. There are stresses that come on to projects, but –


Tommy:I think that’s very true and that’s a common conversation with sponsors and the people they sponsor is, “How are you doing?” “Are you keeping that balance?” Because if you encourage and hire people that are self motivated, they naturally will put themselves out of balance because they want to achieve at work.


Danny Ryan:This is great. Having a great culture starts with you. You’ve done a lot to create this environment in here, and I really appreciate all that you’ve done to make sure we stay true to what we say. This is great being in the lifestyle business. It really is.


Tommy:No regrets.


Danny Ryan:No regrets. Well, thank you everybody for taking the time to listen. This one went a little bit long. If you can’t tell, it’s a subject we’re pretty passionate about. Thank you, Tommy, again for taking the time to do this.


Tommy:You’re welcome. Thank you, Danny.


Danny Ryan:You betcha. Everybody thank you for listening and have a wonderful day. Take care. Bye bye.


read more
Tommy RyanCreating a Lifestyle Business

Cross Company SCRUM Complexities

Bo is a Principal Consultant for ThreeWill. He has 18 years of full lifecycle software development experience.

Danny Ryan:Hello and welcome to the ThreeWill Podcast. Today I’ve got Bo George here with me, thanks for joining me, Bo.


Bo George:Thanks for having me.


Danny Ryan:You’ve driven here just for the day from the great state of Columbus, Ohio … I mean Columbus, Georgia. Correct?


Bo George:Yeah. Yep. As soon as you say Columbus they assume Ohio but I should just start saying Fort Benning because that’s more recognized around here.


Danny Ryan:How was the ride up here this morning?


Bo George:It was good. It was 5 o’clock in the morning, made it to Atlanta by seven, beat the traffic, so it was the way to go.


Danny Ryan:It’s very important when you leave. When it comes to Atlanta traffic that is very, very important.


Bo George:It can be the difference of hours.


Danny Ryan:I wanted to have a lovely talk with you on a Friday afternoon about process, what else? It’s been a topic for Tommy and I for at least a couple of episodes. I think it’s really important for us to focus in on it because how we do is really important, how things happen on projects is really important. In particular, I know you’ve been playing Scrum Master recently and you’re on a project where it may not be unique in this way but you have members of your team that are not just folks from ThreeWill, but also the client has team members on there and there’s also a third party involved with this as well. I just wanted to talk with you about what are the things you’ve learned in this situation, maybe some key tips that you would have from it or stuff that you’ve learned so far when you’re in that situation.


Bo George:Okay, sure. Let me start with when I was thinking about a topic and I was talking to you. I don’t know what it says about what I’ve been doing but I couldn’t think of anything cool from a technology standpoint that I thought would be just the most awesome thing to talk about and so I picked process over technology, I guess that’s how much I’ve been a Scrum Master.


Danny Ryan:Bo’s becoming a man. You’re growing up.


Bo George:Yeah, yeah. Process on the projects I’ve been on lately, in particular the one I’m on right now, we had a large, a pretty large diverse team with developers and administrators from the client that are involved. Then, off shore resources, our team, and we’re all one big, happy team on the project so this is a rather large project. We envisioned it, did the product backlog and all that sort of stuff, November time frame, about end of 2015. It was just a big backlog, it was a lot of work to be done resource-wise, budget-wise, and all that sort of stuff. As we do with our product back log and we prioritize, we also shifted it and sliced it into backlogs that the customer would own.


We envisioned the backlog, we kind of captured all of the things they wanted, but in the end we aren’t the one doing all the product backlogs. We’ve divided them between the customer and ourselves, and then within ourselves on all of our teams. We manage it that way and there’s a lot of inter-dependencies in product backlogs. We capture things like information architecture and capturing requirements for metadata, and lots of stuff like that that are the inputs to actually developing a content type or a site column or producing a site collection structure. Not only do we divide the product backlog between teams, we even have dependencies on product backlog items that maybe the customer are doing and then we do, or vice versa. We may do something that they need us to finish before they can do theirs.


Danny Ryan:But everybody’s running off the same Sprint schedule so it’s not like having Scrum to Scrums or anything like that. It’s all, everybody’s coordinated on the same Sprint schedule.


Bo George:Yeah. We’re all synced on a two week Sprint schedule now in Sprint five of seven Sprints, which our last one’s a stabilization Sprint. We’ve learned a lot through those five Sprints about the team, about our velocity, and all of that sort of stuff. I’d say, for a big, fast moving project with a lot of change it’s been going well.


Danny Ryan:How are things trending backlog-wise, I guess, with this? Does it look like you’re going to … With the current velocity that you have, that you’re going to be able to reach the finish line, have a happy client and …


Bo George:I think so. I mean, we today …


Danny Ryan:You don’t sound overly confident about that.


Bo George:Well, I never really know if they’re happy because a lot of times I feel like, did I come off as mean or whatever. I’m always a little bit paranoid that I’m being a bad guy when we’re talking about the product backlog. Like today for example, it was a normal meeting but we kind of broke it out as a little bit of a product backlog grooming session. As with any project, new things come up along the way. I try to be good about listening and capturing those and putting them in the backlog, and then we can talk about them. Today, maybe five of ten or whatever, 50% maybe are ones that said, “You know, now that I know how many story points that is, it’s not really that important to me.” Or, “Oh, I thought that was going to be a lot bigger. If it’s only that, let’s do that.”


We did a lot of that today and a lot of the outcome of this is that it’s additional scope that wasn’t in the initial product backlog, and so we can do a change order for it. Given our current velocity, we actually … When we started this project we were going after about 110 story points.


Danny Ryan:Per Sprint, that is?


Bo George:No, that’s the total project so …


Danny Ryan:Total project, okay.


Bo George:110 story points, and so I’ve been watching our velocity. Our velocity actually says we can finish about 120-125, so we’ll probably get more done …


Danny Ryan:You know I’m recording this, right? Somebody might listen.


Bo George:We actually might get more done than we initially thought and there’s been a lot of change. But even the stuff today we talked about is above and beyond that 125 so even with the change and additional scope that we’re trying to tackle there’s going to be probably a change order for some it.


Danny Ryan:You’ve seen some backlog growth over the course of the project.


Bo George:Yeah. I think … I’ve heard some of these with Tommy, I think that’s a natural part of the process. It’s part of … A lot of this comes from our Sprint reviews where we get through that Sprint one, we show them our features, we have that celebration and demonstration of all the things we’ve done. The client will see it, feel it, and then have another idea of a little bit something more they want with it or some other layering in on top of the features that we’ve shown. It’s a natural part of the process.


I think a great thing about the two week Sprints and the Sprint review is that you get a sea working software rather than a mock or a little picture or whatever that doesn’t let you get a sense for the actual interaction with software.


Danny Ryan:The Sprint reviews actually you go through, all three parties go through and show that they’re done with what they had taken on for that Sprint.


Bo George:Yeah. Predominantly just due to time. A lot of the feature demonstration is purely our team demonstrating to the customer. The product backlogs that our customer is working on, a lot of those are communicated to us or worked together so they don’t do as much demonstration of their accomplishments, per se, but they definitely are. A lot of their things that they’ve given us we’re upon now, like external integrations with other software and stuff.


Danny Ryan:They’re … You mentioned an off shore component to this as well?


Bo George:That’s right, yeah. One of the things … Everybody has this kind of thing in their mind, outsourcing and being able to save a little bit of money by having off shore resources, it’s a natural part of a lot of projects. I’ve worked in a lot of big companies with off shore resources and here at ThreeWill we’re leveraging where it makes sense. We have some of those that are a part of our core development team that we manage, and Agile and Scrum is really effective in helping us manage that because we have … Communication is super important for any project but if you have the time zone differences and the communication and cultural differences that we have with an off shore resource it’s quadruply important.


Our daily stand up is a great way to first establish, “What have you done? What do you plan to do?” And probably most importantly, “What are your impediments?” Because those are the things that you’ve got to work on right away to enable them to keep moving. With the time difference and stuff like that, you don’t want to waste a minute delaying them as a resource.


Danny Ryan:Are they a part of this sprint review and all, or did somebody else represent them in the Sprint review?


Bo George:Due to the timing of when our Sprint reviews are, I usually demonstrate and cover their product backlogs, so they’re usually a part of our internal Sprint planning and all of our daily stand ups. Then, the Sprint reviews, I’ve had some in the past where we kept the resources but those Sprint reviews tend to have to be seven, eight, nine in the morning so these I typically just represent them.


Danny Ryan:Did you do any retrospectives yet on the project?


Bo George:We try a little bit at the end of our Sprint reviews. The last few Sprint reviews have tended to go a little bit long. We have a lot of opportunity for conversation where we’re hearing additional features we want or discussions on upcoming product backlogs and stuff like that so the retrospective is always kind of that last bucket on our Sprint review. It’s always the one that we run out of time. My Sprint reviews have been an hour but we run about an hour and a half the last two of them so we haven’t talked much retrospective. I think we’ll need to have at least a project retrospective. Ideally, we’d have a retrospective each Sprint to make sure that we’re on track, that the things we’re doing that they’re all right and there’s not feedback about, “Bo, would you stop emailing me 700 emails at nine at night, please?” That sort of thing.


Danny Ryan:Did you have a single product owner or were there a group of folks who were product owner? How did that work on this project?


Bo George:I think it’s really a shared product ownership. I think we have sort of a singular person that makes decisions, but a lot of that isn’t an immediate answer. A lot of times you think of a product owner as they’ll give you a yes, no right then. In our case, a lot of times I’ll ask the question and then it’s got to be put before a group of people, vet it, because with anything you want everybody to have buy in so I would say you have a product owner that represents a lot of other people, if that makes sense.


Danny Ryan:What was this like, this was for a consulting company which is a larger … A much, much, much larger consulting than us. What was the dynamic with that because it’s … What did that add to the project or how did that change things?


Bo George:Well, everybody’s got their opinions of what’s important, that’s always a challenge for anybody to balance. I know the product owner has those challenges and we have those challenges as well. On one side of the fence, you might have people who the look and feel is the most important thing. It’s got to be well branded, which is certainly one aspect of the solution. Mobile responsive might be important to somebody else, “I need to access this thing on iPhone,” and that’s another aspect of the solution. Then, there’s information architecture, site structure, taxonomy, metadata, all those sort of things about the nuts and bolts of tagging content so that it shows up in search. Those are all aspects … You might have different people that think different parts of that are the most important thing and so it’s a balance.


We’re trying to get the best of all of that stuff but obviously you can build and all that stuff and just have an insane budget and still not get there. You pick your battles, you rank things in a product backlog to say, “What’s most important?” I really like the idea of force ranking product backlogs, that makes you make the hard decisions. If you have 10 product backlogs and you’ve got to rank them 1 through 10, that’s a hard exercise versus saying, “Well, just tell me which ones are high, medium, and low?” Because then you’ll end everything high. I like the force ranking, that really makes you make a judgment call between alternatives.


Danny Ryan:Is that something you picked up on this project or where’d that come from?


Bo George:I think Bob Morris might have been the guy that I’d seen start to do that and I’ve seen others do it, but Bob’s one of the ones that really made me think about force ranking things.


Danny Ryan:Bob’s coming back, baby.


Bo George:Oh yeah. Scrum Master. Enjoy.


Danny Ryan:Do you want to be Scrum Master on your next project?


Bo George:I’m torn. I jokingly say that I don’t get to write code anymore, which I still do, but it’s just a different challenge. I like being a Scrum Master sometimes. I think the challenge really comes in, and I was joking about this at lunch with the guys is, if you are the Scrum Master but you also happen to be a developer or maybe the Dev lead, and the fact that you’re playing three roles that maybe can mess with each other, it becomes a challenge. Because if you’re wearing your developer hat and you’re like, “I’m not going to do my tasks right now, I’m writing code. Who’s going to get made at me, the Scrum Master, well I am the Scrum Master.”


Danny Ryan:It sort of tends you towards multiple personality disorder.


Bo George:Yeah, a little bit. Sometimes that might be the challenge with having multiple woes. But if you’re a dedicated Scrum Master on a project and you’re not in the code then you get a stay at that mindset of monitoring the tasks and risks, the product backlog, and all that kind of stuff.  In some respects, it’s a thankless job but I think it keeps the project moving. Doing it more lately is giving me a lot more appreciation for the stuff that Bob and Bruce and Tommy and everybody else that’s been a Scrum Master on a project I’ve worked on before. It makes you appreciate all the stuff they have to do.


Danny Ryan:The end product for them is a new Intranet, I’m assuming. Is that what comes out on the other side of this, is a new internet that they’re using?


Bo George:Yeah. Share Point 2013 Internet and highly branded. Corporate branding’s a key thing. Mobile responsive which you know this is the second or third Share Point 2013 that we’ve made mobile responsive which is … It’s a challenge in itself. I know just recently that Patterns and Practices released some stuff that looked good but this is … It’s a little bit more than that in that it’s branding, Share Point, and making that branding mobile responsive. Then you deal with things like publishing pages and the content in there and making everything look good. So yeah, but it’s an internet solution, large corporate internet for knowledge management and even project site collaboration, communities, offices, and all sorts of organizational areas and stuff like that.


Danny Ryan:Is this online or On Prem?


Bo George:On Prem.


Danny Ryan:Okay.


Bo George:Yeah. We talked early on about the … It’s always that first conversation, Office 365 versus On Prem, and I think there’s some constraints around customer data and things like that that lean a bit towards On Prem.


Danny Ryan:Very nice. Important question, how tall is Baird?


Bo George:He’s 11 going on 21, and he’s probably four inches shorter than me.


Danny Ryan:You’ve still got four inches on him, very good.


Bo George:I’m 5’11”, I think he’s at least 5’6″, 5’7″, and his foot is the same size as mine. Which means I get to wear cool shoes if I can sneak them out, Kevin Durant’s and Jordan’s and stuff.


Danny Ryan:Yeah, I’ve seen pictures of him every once in awhile on Facebook. You guys look like you have a good time.


Bo George:Yeah. He’s a hoot.


Danny Ryan:Yeah, awesome. Well, thank you for what you’ve done on this project. I look forward to, once you’re done with that final Sprint, celebrating with you guys over getting it accomplished.


Bo George:Yeah.


Danny Ryan:That’s great. I know it’s a difficult situation that you’re in. It’s difficult enough having your own team, but then involving others I know there’s a certain layer of complexity to everything. I appreciate you working with them. It’s sort of like, “Who am I serving? Am I serving others on the project?” You end up having to serve other multiple masters which can put you in very difficult situations. But from everything I hear about the project, everything’s working out well. Look forward to getting that wrapped up. Thank you so much for all your hard work that you’re putting in there.


Bo George:Thanks, it’s been fun.


Danny Ryan:Absolutely, absolutely. Thanks everybody for taking the time to listen to this. If you’ve got any questions or anything like that, feel free to leave a comment up on the blog post. We really appreciate you taking the time to listen to this today, thank you so much. Thanks Bo.


Bo George:Thank you. Bye bye.


Danny Ryan:Bye.


read more
Bo GeorgeCross Company SCRUM Complexities

Why Do SharePoint Initiatives Fail?

Tommy serves as the President at ThreeWill. In this role, he works with his leadership team to hire the best people, find the right business opportunities, and ensure that ThreeWill delivers for our clients on projects.

Danny:Hello, and welcome to the ThreeWill podcast. This is Danny Ryan. I’ve got Tommy Ryan here with me. Hey, Tommy.


Tommy:Good morning, Danny.


Danny:Erin go Bragh. It is Saint Patrick’s Day and Tommy has a beautiful green shirt with another green shirt under it, and green socks, polka-dotted socks.


Tommy:Green polka-dots.


Danny:I am impressed. You got some kickin’ socks. If your feet get too large or too small for those socks, you can [crosstalk].


Tommy:Sorry, I can’t hand those down.


Danny:Oh, come on. Half my wardrobe is from Tommy or from Bobby. Bobby is my other brother, so I guess I won’t get the socks for hand-me-downs. Oh well. Aww, shucks. We’ve got a great topic today, and it’s something that I know we get pulled into a lot of projects because essentially, the earlier SharePoint initiatives fail, so I wanted to spend some time with you talking about that.


The topic we were talking about as well, which is sort of why SharePoint … What are the benefits of SharePoint? When we talk through that, it sounded like you really need to apply it to individual’s needs, and it was a little bit more difficult to talk about. For this one, let’s talk about, what have we seen through the years? It’s been what, 15 years since we’ve done that? Of that 15 years at least, maybe 10 of it that has been SharePoint. We did some SharePoint stuff very early on, but for the majority of those years, we’ve been doing things with SharePoint. Can we sort of just talk through some of the things that we’ve seen as we’ve worked with clients, as far as, why do they fail? What happens when somebody tries to use SharePoint and it’s not successful?


Tommy:That question, I think you can put it in some general categories. One category is, they’re looking at SharePoint as just a document repository, so there’s a mental shift of: instead of stockpiling documents on my hard drive or network drive, I just stockpile them in SharePoint. You’re taking something that … It’s more convenient to work off of your local hard drive, to work with files, and then you put it up on the SharePoint and all you’re doing is … It’s a dumping ground for documents. It gets disorganized quickly. Imagine how, with your own local file system, that can get disorganized and you’re constantly trying to organize that. Amplify that by your whole organization just dumping files into SharePoint. That’s one area where people just don’t think about, “How am I going to organize my content across the organization?” and set that up and start with that in mind.


Another area, I think, is in the area of over-engineering SharePoint where organizations see a lot of shiny new stuff that comes with SharePoint, and for technology’s sake, they start using those things and not really have a business driver that says, “We need to do this, and this is important to our organization.” When that occurs, you end up seeing low adoption because it’s just over-complicated. Maybe there’s good intent about the value, but the organization is not bought in, the organization doesn’t understand, and it’s used by maybe the IT department and no one else. We saw things like My Sites. That was a feature within SharePoint that looked like a cool little feature, but everywhere we went, the only people using My Sites was the IT department. It was never rolled out past that. I think that’s one of the warning signs of implementing it just because it’s there, versus a business driver that says, “We need to use this part of SharePoint.”


Probably another classification is people don’t know what SharePoint is. I hear that a lot, “Well, what is SharePoint?” Certain people in the organization get it, but then you go up to the president or you go to people that are not normally using IT-type tools and they don’t get it. “Why do I need to use SharePoint? I can do the work I need to do today. Why over-complicate things and throw another tool into the mix?” Those organizations, they struggle with SharePoint because there’s just not awareness and knowledge about, how can we use SharePoint where we are today as an organization? Where’s our maturity level of how we collaborate together, the type of work flows and business process we have in our organization that we’d want to enforce in a tool like SharePoint?


Being able to take that and take the right baby steps along the way to say, “Okay, what’s really important now? What’s some of the low hanging fruit, pains that we have an an organization, that we can take that extra step in the effort to learn SharePoint, to evangelize it, to support it, and kind of point back to, “Let’s do it that way.” I think naturally, we tend to go back to the things that we know and that’s email and storing a file on our local file system, and a lot of things degrade away from SharePoint when there’s not that support of saying, “This is where we’re going to do it and we’re behind this as an organization from the top and the bottom of the organization.”


Danny:Is that support … I know folks can work with us to do things like training and help with communication in rollout. Is that a group with them? Is that an individual or a group, or how is it when things have worked … Let me put it that way. Has it been a group of folks who are promoting it and are really putting it out there as, “Hey guys, this is an enabler. This is something that you can use.” How has it worked? How have we seen it work? Or maybe we haven’t, because all of the clients we worked with, it hasn’t worked. Where have we seen it work?


Tommy:Well, I think where it’s challenged is in much smaller organizations. As the organization gets larger and can have specialization of someone taking charge of something, you see someone that’s like a Director of Collaboration, VP of Collaboration, or someone that is a leader as it relates to internal PR. I’ve seen that, also, as a title, kind of internal PR. That’s someone that needs SharePoint as a key tool to say, “How do we roll out information to our organization? How do we get together and work together as a team?” You need that type of champion.


In smaller organizations, it’s that one or two people that get it, that know, “For us to grow and for us to be more effective in the work that we do, we need something like a SharePoint. We need a platform like SharePoint to enable those repetitive things that we do, to be able to do it in a better way, to be able to do it in a way that we can retain the knowledge in the IP of our organization in an organized fashion that, as we bring new people into the company, it’s available to them. It’s not locked into inboxes in people’s email. It allows us to put some structure on how something gets accomplished as it relates to content and contracts and all those documents that we create that run our businesses.”


Danny:This reminds me of, with a lot of things, there’s a maturity continuum and you can’t cheat it. You sort of have to build up internal competencies, and competencies as an organization, and you move to the next step. You can’t jump two steps, and if you try to do that, you’ll fail if you try. There’s this natural sort of thing that’s built into this that you have to think about it as a continuum, as a sort of growing through this. When you and I were talking about analogies and some of those, “How can we compare this?” Now that I think about it, in some ways, it’s very much one of your favorite things, which is gardening. You can’t cheat in gardening. You have to nurture it. You can’t plant right before you sow, all these things. I think it might be, in some ways, be a very valid analogy in thinking of how are you growing yourself, maturity-wise, within your organization as far as collaboration? Where are you? Are you at the very early stages, or where are you with that continuum?


Tommy:I think that’s key, and I think as it relates to failure, some of the organizations that we come across … It’s not common – actually, it’s interesting to see it when we do see it – but it’s organizations that jump ahead and kind of use some advance features of SharePoint before they’ve really used the basic features. It speaks to that maturity continuum of … It takes time as an organization to grow in your ability to work together as a team using technologies that support team-based collaboration.


Danny:I think this often happens, which is, for some of these larger organizations that we work with, they’ll have people who have backgrounds in .NET development or in different technologies, and we’ve seen it where they try to take what you do in SharePoint … If they don’t know how to do it in SharePoint, they’ll sort of intermix this with something and you look at it and you go like, “Why were they trying …?” They could have leveraged something from SharePoint that would have done this, but instead, they did something else and they come up with this really kludgy solution. Part of it is because they didn’t take the time to invest and understand what the platform has.


Tommy:You can see where that comes from. I think SharePoint … There’s certain things that, out of the box, you just don’t like the way it works, but you have to realize that the more you can embrace the way SharePoint does it and come up to speed with that and get accustomed to that, the more you’re going to get out of the platform and the more kind of fringe benefits of … As the platform grows, you’re getting these features that come up for free, versus, “I have to go build this.” If I go and take a totally different direction on how to accomplish something that’s already in SharePoint, then when SharePoint matures and gets better in that area, then you can’t take advantage of that because you’ve kind of gone off on your own path.


I think the beauty of SharePoint is, it’s a platform that can be extended. If there are some rough edges that you have to address, you can do that, but you have to do it with caution because it has a cost of ownership to do that. Our philosophy is, how much can we use that’s out of the box, so you can get to business value very quickly and you’ve put the person in a situation that they can grow with the platform versus having to go build it yourself every time you want a new feature in your portal.


Danny:I know we have a lot of developers here at ThreeWill. I can remember when you made it a point that they not develop … Basically, that they use out of the box features and functionality when we were first picking up SharePoint because we didn’t want to miss what you could do with it through configuration through out of the box features, and then get to a point where we said, “Okay, we know the edge. We know what this is supposed to do. Now is the point where we can see where we can customize, or we can see …” Typically with that, with SharePoint, you might have a couple of different ways you can go after it and there are pros and cons to each way. To some folks, they may throw up their hands to a consultant. They’re like, “I love that. I love this.” I know for us, it’s also been a sort of maturity continuum, and we had to make a conscious choice to say, “Understand what’s in the platform before you start building things out.”


Tommy:That was key, and it was a painful period of time for, I think, some individuals to kind of put Visual Studio aside and really understand the platform. We want to embrace as much as possible and then only pull out the customization when it’s not there or it really isn’t something that you’d ever see in SharePoint, you have to extend it to get that type of capability. That’s come through a lot of areas that have to do with integration. At the end of the day, SharePoint doesn’t create this integrations, it’s up to either the company to do that or the software, the ISV, that provides the other solution to come up with that integration.


Danny:We’ve been talking a lot about migrating to Office 365 and I don’t know if … Have we started to see some … How the SharePoint – maybe instead of saying SharePoint, Office 365 initiatives are failing. Is that change at all when we start talking about things in the cloud? Any insights that we’ve seen so far, maybe over the last couple of years, where we’re looking at things changing versus on-premise versus the cloud. Have we seen anything that [crosstalk 00:14:58]?


Tommy:I think time will tell. Right now, we’re too early into the lifecycle to come up with what are the standard things that fail in a Office 365 initiative. I think what you’re seeing is people are approaching it in a healthy way, where they look at, “Let’s get the commodity services that come with the platform of Office 365 in place, and then let’s enhance and extend that.” For us, that can be a little frustrating because that’s … A lot of what we do is that enhancement, so that’s a big reason why we’ve beefed up our migration practice, is because that’s where we think our customer needs the most help and we can help them with that piece and have the patience to say, “Okay, now when you’re past that maturity of just embracing what’s out of the box, now you’re going to want those things that you wanted before like workflow and the customizations to integrate it with other platforms.”


Danny:Anything else you would point out, as far as somebody listening to this episode, any insights you would want to share with them, maybe about things to steer away from, failure-wise, or anything else you want to add to this?


Tommy:I think as it relates to failures with SharePoint and how do you approach that, be sure that there’s business value driving it and that there’s buy-in from the organization, there’s a certain amount of hunger from the organization to want to do this versus it’s something being forced upon me. On that same note of help the adoption through, plans around training and communications and that evangelization. It really is not going to happen naturally on its own, it’s going to need some work. It’s going to need people pointing out the use cases and why we’re using this and making sure that what you go after, you embrace and master and then build upon that.


Just looking at SharePoint and making sure you’re using it in a way to enable value versus, “It’s there, so let’s just use it.” That’s probably some high level advice on how to approach SharePoint and avoid failure. Make sure it’s not for technology’s sake, there’s a business driver for it, that people are there to support it, to make it successful, that requires a lot of communication and training and making sure you’re hearing the pains and addressing those pains as they come up, to make sure that there is that adoption you need to get the value at the end of the day.


If you put SharePoint out there and it’s not being used, of course there’s very little value, and it actually is a distractor. It ends up being, “Okay, I’ve got stuff in SharePoint and I’ve got stuff in Dropbox, I got stuff in my local file system.” It’s just another place where content is, so you have to have a very clear initiative of, “This is where the work gets done, and when people are doing it outside of here, let’s address that so we can have everybody on the same page and getting the benefit of being in one place.”


Danny:I’m going to brag on the delivery team a little bit here, which is, even though I pull them in to some opportunities where in the past, there has been failures and SharePoint failures … I’m having a problem right now thinking of a project that we came out of that we said, “It failed.” Maybe I have a bad memory, or maybe nobody wants to tell me about that, but I am amazed at how many times we end up taking something and sometimes it’s on fire. A lot of people, when they want to pull in an outside organization, it’s because it’s not working and there is something that could be inherently a problem with being successful with a project. I’m just amazed at how many times we go in, we settle things down, we get things moving on the right path, and we get them to a point of being successful with SharePoint.


Tommy:I think we have done a great job there and as with anything, we can always improve. I think what we’ve done in the past is using the Agile process to understand the need and being able to feed that back in a very quick cycle. That, in itself, I think has given us a lot of success. Where I think I’m seeing even better success is in the projects where we challenge the stakeholders for things that they want, and really saying, “That’s probably not the right thing to do, and this is why. We’ll do this for you, but here’s some things that we want you to know that could be things that are drawbacks and things that are going to make this not sustainable in terms of using it.”


I think we can get into a lot of projects where the customer’s happy, we’ve implemented everything they asked us to do, but there’s not the level of adoption that we would like to see. To address that adoption is giving that consultative advice of … Being brave enough to tell the customer, “That’s not probably a good idea and this is why,” and then having that conversation and trying to get to the same page where you can both have an understanding of, “Yes, this is the right thing to do,” or “No, this is something we should hold off on.”


Danny:I have seen us do a lot of … I don’t know if you would call this failing early, but the whole through the estimation process with Bruce, and going through and seeing what it takes where the project hasn’t made sense. On both sides, either what the expectations are around the effort, or the cost involved – investment, I should say – and it doesn’t make sense, so we don’t … Either side won’t take on the engagement. From my standpoint, I think that keeps us out of this situation where we’re failing on projects. I think very early on, I feel like what Bruce does for us is he gives us good estimates, and we’re able to use that to decide whether that company can make that investment or not, or are the expectations set up properly yet.


Tommy:Right. That’s where a lot of times we’ll fail early, which is, we’re bringing up what the costs are and not going in there where we … We don’t tell all the truth, because we want to get the project, and we want to get in there and start and then you can do change orders to get more. Change orders I think can be good, and sometimes they can be bad. I think a good change order is new ideas emerged that weren’t discussed, that we’re having good conversations that we’re coming up with better ideas. Where it’s bad is if you’re having change orders for things that you really knew about and didn’t disclose. We’re always challenging ourselves. That’s a fine balance, because you have to raise enough awareness to understand total cost of ownership, but you don’t want to overemphasize that where you’re kind of being a Debbie Downer for this initiative, but you want to give enough information so people don’t go in and get blindsided as they continue on with what they’ve invested in.


Danny:Well, thanks folks for taking the time to listen to this. Thank you, Tommy, for your insights. I think this was very helpful. I know I learned a couple of things. For folks, if you can’t tell, Tommy and I are very invested in our projects being successful. I think that’s a small aspect of it as well, is that there’s skin in the game from both sides. If you’re looking at this next project and aren’t sure about whether SharePoint’s the right platform or, “We’ve failed in the past and we’re not sure if this next initiative is going to fail again,” just reach out to us. If you go through the “contact us” page on our website, I will set up a meeting with you and … We’re not sales folks here, we’re just consultative, we want to make sure that the next thing that you go after is successful. Feel free to reach out to us, to leave a comment if there’s things that you’ve run into. Maybe you’ve seen sort of a pattern with failed SharePoint initiatives, and definitely interact with us through the website.


Thanks again, Tommy, for your time and thanks everybody for listening. Have a wonderful day. Bye-bye.




read more
Tommy RyanWhy Do SharePoint Initiatives Fail?

What is Sustainment?

Matthew Chestnut is a Senior Consultant at ThreeWill. He has over 20 years of software development experience around enterprise and departmental business productivity applications. He has a proven track record of quality software development, on-budget project management and management of successful software development teams.

Danny:Hello and welcome to The ThreeWill Podcast. Today I’ve got Matthew Chestnut here with me. Thank you for joining me Matthew.


Matthew:Hello Danny.


Danny:How are you doing?


Matthew:Doing well. This is our second or third time we’ve gotten together. I can’t remember exactly how much fun we’ve had in the past but here we go again.


Danny:We’ve had a lot of fun. It has been fun. It’s good for me to check in on you every once in a while. Matthew is across the wall from me here, if he’s having a bad day I know because he’s kicking the wall and he’s abusing it. No, I never hear you kick the wall. You don’t get mad. I don’t think I’ve seen you get mad.


Matthew:I can tell when Danny’s busy doing his work because I hear a low rumbling from the office. It’s just a series of continual phone calls, I can tell Danny’s busy doing stuff.


Danny:Doing something, something in there, he’s doing something. What I’d like to talk to you today is about a couple of things. One is, I know you’ve done a lot of work with what we call sustainment. I’d like to start off with that, and then I’d like to talk a little bit about when you’re working with people all over the world, with offshore partners, with people in various locations, maybe some of the things you picked up in on that projects.




Danny:Just starting off with sustainment, tell me for folks who may not know what it is, what is sustainment?


Matthew:In ThreeWill world sustainment is an outcropping and offshoot of work we did for a major company, where they did not want us to just dump this particular product on their support team and have them support it. It really worked out to be a great thing, they asked us if we would put together a 1 year, 2 year, 3 year plan to support them in this particular product, so that if questions arose or new features needed to be added we would be ready to do so. It spawned this whole new ecosystem within ThreeWill where we now offer that as a standard offering for our enterprise customers, as an option, it’s certainly not required.


The idea behind sustainment is you’ll be guaranteed that you will get our attention. Obviously if you’re a customer we certainly want to pay attention to you, but if you’ve purchased a sustainment agreement you certainly will go to the top of the queue if you have any issues that arise.


Danny:That’s great. You have a certain number of hours that you’ll have committed towards to the years that the way that it’s all set up.


Matthew:It works a lot like a lawyer and a retainer fee in many ways. Now, we don’t hold on to your money, if you don’t use it no big deal, it usually rolls over to the subsequent year, which is great. But it gives our customer the peace of mind knowing that if things come up during the year, that may not be big items but they’re certainly something that affects the production or affect the use, that they can get those issues resolved without having to go through a budgeting or bidding or any process like that. They just call us and we get it taken care of.


Danny:This is things like level 3 support, is it building new features in [crosstalk 00:02:56]


Matthew:I wish it were level 3 support, sometimes it’s level 1 support, which we don’t mind. Just like anything else, if you develop an application for someone you’re name or your company gets associated with that, so if there’s a problem with X they call Matthew. It’s not because there’s a problem with the program necessarily, but it is associated with it. We sometime will triage, which we certainly don’t mind. In fact we’d rather them call us than them be frustrated trying to figure out who to call within their organizations. Sometimes we deal with some really, really big companies and they’ve got such a diverse set of products on their infrastructure, the people working in IT don’t know who to route these people to. We can help with that.


Danny:That’s great. Can you use these hours to perhaps build in new features.


Matthew:Certainly, yeah. We’re not just sitting around waiting for bug fixes. A lot of times we can work with a customer who’s got a set of features that might be small in nature, or they might be large. It’s really just trading dollars for dollars. It’s just a bucket of pre-allocated money that they know that they have. If they don’t use it it gets to roll over. But a lot of times we find is that towards the end of the year, end of the budget year, the customer will say, “Hey I’ve got this bucket of money, and I’ve got these things that have been building up, these feature requests et cetera. Let’s go ahead and get these take care of,” and that’s what they’ll do.


Danny:Awesome. As you’re looking at this, Tommy and I have been talking a lot about process lately, and knowing that we use Scrum internally how does this all fit with getting the request from a client? How does that work?


Matthew:Yeah, it really works as little mini projects. The mini project may be as simple as a question and an answer. What we’ll do is the question will come in, either via phone, email, directly to our personal email, or to [email protected], we have a email address that the customers can use. Regardless of how we get it we’ll create a ticket inside of our ticketing system. The idea behind capturing this information in a ticket is invariably we have other things that need to be attached to this ticker. Whether I’m talking with a colleague, there’s time involved, what have you, conversations. We always want to be able to go back to an audit trail if you will of when the customer called, what they called about, did we resolve it, how fast we resolved it, et cetera. It depends on the scope of the question.


If it’s small in nature, where it’s a quick answer, we get it done in 15 minutes no big deal. If it’s something that takes a little bit of research we might call the customer back within that day or maybe the next day. But if it’s a series of things that they want done, new feature request, et cetera, we will usually provide the customer with an estimate. We use our standard sizing spreadsheet. We call it the t-shirt sizing, small, medium and large, just to give the customer and idea of what the estimate in effort, which turns to dollars, would be for a given set of features that they’re asking for.


Danny:Is that what Bruce uses for creating a product backlog or is that more lightweight.


Matthew:It’s much more lightweight. We realized that the sustainment items that come up, we don’t want to overdo it with heavy project management because that doesn’t do anybody any good. We spend too many cycles for something very small. But we realize we need to be able to give the customer an idea, what’s it going to cost him in time and effort. We needed to do that quickly. This t-shirt sizing really is a great way to do it. We’ll think, as a developer we’ll say, “Okay, I think this is going to take me an hour or 2,” or, “It might take me half day,” or, “It might take me 3 days.” Based on that we simply plug it into a spreadsheet, or we just look at a chart, and it translates 3 hours of development time equals 6 hours of development time, QA, user acceptance testing and deploy to production. There’s all these layers that get added on. If it takes me 15 minutes to do, great, but we have processes we have to follow to get it into production and we have to account for that as well.


Danny:That’s great. Just earlier today I had a request from a prospect asking about, it was basically some customizations to the things that we Trove, with the Office 365 and Salesforce integration.


Matthew:Salesforce, yes.


Danny:They were asking for sort of a lightweight, “How much does it cost to do this, this and this?” It wasn’t something I needed a full product backlog around. I forwarded it on to Bruce and to Eric and said, “Hey, can you t-shirt size these.” The size are extra small, is it’s less than $1,000. Small is it’s less than 5,000. Basically gave them some buckets to fill them with. I’d be interested to see what you guys to see if we could use that for when those types of requests come in.


Matthew:What’s important, and we probably wouldn’t do that necessarily for a new customer or an application we’ve never dealt with before because there’s too many unknowns. But for a product that we originally developed or we’ve picked up and started supporting, so we’re familiar with it and we’re talking to the subject matter experts who have dealt with it before, we can get a pretty good idea how much effort it’s going to take. Sometimes we also balance it based on the resources going to be doing it. For example if I’m the world’s greatest person at digging holes and I’ve only got so many holes I can dig and we’ve got to get somebody else to do it, they might not be as fast at doing that, so we adjust the estimates accordingly.


Danny:That’s great. That’s great. Let’s switch over to the second subject that I would like to talk about, which is on some of your projects you’re working with teams that are really spread across the world. What’s the challenges that come to play with doing that? What are some of the things that you’ve learned when working with teams that are really distributed everywhere?


Matthew:It’s interesting, even with a team size of you plus 1, communication is very important. Even in our sustainment world we’re always trying to document. Not crazy documentation where we’re writing novels and books about a certain process, but facts that help us in the future. We just had a scenario yesterday where we had to figure out why we did something back in June of last year. We went back to the history and we found it.


When we’re talking about a geographically distributed team, we use our standard technique of stand up meetings. When we’re doing a project type work, where we have our daily stand ups, 15 minutes, tell me what you did yesterday, tell me what you’re going to do today, tell me what is blocking you if anything. Those are invaluable, because it keeps the finger on the pulse of the project for all involved. It’s important I think for everyone involved in the project, even if you’re not working on a certain area to know if a area’s going well or not. Certainly as a project manager you must know that.


We use a variety of tools. We use our own SharePoint Office 365 instances. We have a project extranet that has lists for issues, lists for backlog items, sprints, et cetera. We’ve also used commercial applications, some of our customers deal with Atlassian and Jive for example and we’ve used that to manage issues, track them, et cetera. The idea here is you need to keep track of your backlog items for the project, you need to keep track of your print items for the given sprint that you’re working on, whether it’s a 1 week sprint, 2 week sprint, 3 week sprint. You need to know what those tasks are, because that’s what you’re going to be reporting on in a daily basis, how are you progressing against those items you’ve committed to complete by the end of the sprint.


Danny:What are your … I guess for some of the recent projects you’ve been on, what, is it a 2 week sprint? What’s a typical sprint for you [crosstalk]?


Matthew:It’s interesting, the project I’m currently is kind of in a strange phase where we did a lot of work and we were doing 2 week sprints at the time. Now we’ve gotten to a certain point where we’re transitioning it into a production environment. We’re resolving any issues that arise, not necessarily with our application but issues with the environment, what is blocking us from getting this thing deployed to production. There’s lots of little things that we’re discovering in this website. It’s static content that we never knew existed on the website, it’s processes on all these other machines that might be SQL server agents that are running every day to transfer information from one enterprise Oracle database to a SQL server database.


It’s more like, this thing, this website hasn’t changed in years, and we’re discovering more and more about it as we get closer and closer to the production deadline. We’re really triaging issues that come up, the customer helps us prioritize them if they’re important to get resolved before we got to production, they’re marked high or higher, high, critical or blocker, and we address those as quickly as possible. Then we let things settle down. In this particular situation we’re dealing with about 20 items that are in this state of, we’ve got to get these things done. We get it down to maybe 15 and then it bumps back up to 22, and then we get it back down to 20.


But it’s not program stuff, it’s not stuff that we did necessarily but it’s stuff we’re finding about the project, about the implementation that we never knew about because the people who implemented it years ago are long gone. We’re uncovering archaeological artifacts as we go on. That’s where having good communication, having the proper issue list, dealing with a world wide team, we’ve got group doing load testing, QA all around the US and even around the world. Just coordinating those efforts is an important aspect of successfully delivering a project like that.


Danny:Great. It almost sounds like you’re … Some projects have a deployment sprint or deployment set of sprints.


Matthew:They have an infrastructure, which is really good, where we’ve got a sandbox environment where we can do with it what we want, a QA environment that we share for deploying into and doing strict QA testing and then a brand new production environment that ultimately this application will reside in. They’ve got their existing production environment that we don’t have to touch. We’ve got all the infrastructure we need to do the testing, we’re just trying to make certain that the new production has all the functionality of the existing production, and that’s the trick.


Danny:Any other tips or pointers when you’re working with a team that’s distributed across the world?


Matthew:It’s interesting, just be aware of timezone difference. Sometimes when you have those meetings at 6:00am in the morning it’s not fun. For them it’s not having a meeting at 10:00pm at night either. Just be aware of cultural differences too, be certain you are clear on your communication. If you’ve got a 12 hour, or even a 24 hours turn around on a communication you send, make certain that you send it and it’s very clear. You don’t want to get this back and forth because the latency will just kill you if you’re taking 3 or 4 days to finally get to the real question, where if you just spend a little bit of time at the outset, crafted your communication, your email properly, you could have gotten your question answered much sooner.


Danny:Do you do screen sharing? What’s been some of the … You mentioned some of the tools that you use which are like your SharePoint client side and those type of things. What are you using to maybe get everybody on the same page?


Matthew:Quite frankly having a common QA environment, and having a methodology that we use to deploy to those environment, makes it easy for us to replicate the problem. Since we’re on a shared environment if they say there’s a problem happening with this set of steps they followed, typically we can reproduce it. That’s hugely helpful. If we were on 2 different systems, that might be harder to do, but because we’re on a shared environment that makes it much easier.


Danny:Awesome, yeah. Thank you so much for taking the time to do this. I appreciate our little cordially get-together. It’s always nice …


Matthew:Yeah, I look forward to the next one.


Danny:It’s always nice to pull you out of the room and say, “Come into my office Matthew, come hang out with me for a little while.” I appreciate your time.


Matthew:You’re quite welcome Danny.


Danny:Thank you for all that you do. It’s incredible what you guys are doing with regards to sustainment, with regards to the stuff that you’re doing on the large project that you’re on right now. We feel so lucky to have you as part of the team.


Matthew:Thank you Danny.


Danny:You bet you. Thanks everybody for listening and have a wonderful day. Thank you. Bye bye.


read more
Matthew ChestnutWhat is Sustainment?

Using SCRUM on Migration Projects

Tommy serves as the President at ThreeWill. In this role, he works with his leadership team to hire the best people, find the right business opportunities, and ensure that ThreeWill delivers for our clients on projects.

Danny:Hello, this is Danny Ryan. Welcome to The ThreeWill Podcast, I’m here with Tommy. Tommy thank you for joining.


Tommy:Glad to be here Danny.


Danny:Awesome, thanks for getting together here on a weekly basis, it’s nice to see your smiling face.


Tommy:Sure, it’s good to be here.


Danny:We’ve had a couple of podcasts leading up to this topic that we’re going to cover today, which is about the process that we use on doing migrations. I know we’ve been doing some complex migrations recently. It seems like really trying to get our customers to get over onto Office 365 has been one of the challenges that folks are seeing. We’re seeing a lot of projects related to this. For folks who might not know we us Scrum. Scrum is one of the Agile processes that is out there. There are some small modifications that we make just for the fact that we’re dealing with an external client, working with a client, but for the most part we’re using the fundamentals of what Scrum is about. What we wanted to talk about today is maybe any of the modifications that we might make, or maybe even just pose the question, does Scrum work with what we’re doing on these migration projects?


Tommy:First of all Danny thank you for the opportunity to geek out on process.


Danny:Oh jeez.


Tommy:I don’t get this opportunity too often and I don’t believe you let me do this. Yes we can geek on processes.


Danny:This is a sign of true love Tommy.




Danny:I love you my brother. I love you. I will sit here and listen to you about process for the next, don’t say 30 or 40 minutes. Maybe I’ll give you 15 minutes, how about that?


Tommy:Okay, 15. [crosstalk] 15.


Danny:Okay, ready? Crank them up, ready, 1, 2, 3 and go.


Tommy:Yeah, the process as it relates to migration. We’ve really enjoyed using Scrum as our methodology for doing custom implementations and the work that we do with SharePoint (Scrum on migration). As we’ve approached migrations we thought about using Scrum, and should Scrum be the methodology that we use? That’s what we use today and it’s working for us. I was taking some time recently to step and think about, is that the right choice? Are we just forcing it down the path of Scrum because that’s what we know and we’re comfortable with?


I posed that question out to our Yammer group and had some really good feedback on that. The question came up, should we use Scrum? What are the options to evaluate it against? I said, “There’s really any option.” Is there something better than Scrum to do these migration projects? When you see a migration you automatically think about, there are distinct phases when you approach a migration. You have a step, some kind of analysis type step, or people might call envisioning of what is this scope of this migration? What’s the bounds? What are we trying to accomplish as a part of this migration?


That goes to another phase which is a planning phase, is, okay this is our scope let’s do the proper amount of planning to know how this is going to fit into the grand scheme of things. Because you can’t just be willy nilly about going after a migration. There’s a organizational impact, it’s not just planning for the work you’re doing to make that migration occur but how does this fit into the grand scheme of things and how can we do this and minimize disruption to the organization.


Danny:Yeah it seems like communication is just … This is typically things that we might be working with our client, but ultimately our client’s responsible for the communication that goes out to the people who are using what you’re migrating off of and onto.


Tommy:That’s such a huge part of a successful migration, is the communication’s piece. Just like real estate it’s location, location, location, migration it’s communications, communications, communications.


Danny:Good [crosstalk]


Tommy:If you do not do that you’re destined to have a lot of pain in that process.


Danny:I know for a lot of the Jive to SharePoint migrations that we’ve been doing we do them with the workshop upfront and then we have the project afterwards. It sounds like what we’re doing is those … Maybe those first 2 steps during the workshop and then coming up with the plan afterwards.


Tommy:Yeah, when you look at those workshops at the end of the day it’s helping a organization decide, should I do this? What’s the rough budget for going after this? Especially with the Jive to SharePoint migrations it’s, okay I’ve got this in Jive, where does it go conceptually over into SharePoint. What we do in these workshops is we’re doing an inventory for them in an educational piece to let them know what is involved of this process of moving from Jive to SharePoint. We come out of that and we’ve done some of the analysis piece basically, some of the planning, really, really rough side of the planning side. It’s really enough planning to arrive at a budget so you can make an ROI decision and you can get a sense of, can I get this done in time?


Because a lot of times the approach with these migrations is, okay I’ve got a renewal, we’re ready to move and it’s going to be financially advantageous to move by this day. Our workshop allows them to understand what are they going to do and how much is it going to cost. Then we really need to go through all those steps, they might be compressed after our workshop but we’re still doing a certain amount of detailed analysis and planning before we get into some of the more implementation steps.


Danny:As you know I find it refreshing that there’s a deadline out there, because for a lot of typical collaboration types of projects that we’re doing where there isn’t a deadline to get something done by a certain period of time, it’s sometimes tough to make a decision whether to do it or not to do it. It’s just nice to have something. Fairly early on when working with clients who want to do migrations I start putting together and action plan around it, which is saying we do this during this time, we do the workshop here, we do this next, and sort of work our way backwards. It’s one of those things as a good project manager I] want to give a sense of urgency at the right time. If you don’t spell out, “Hey guys, really it’s like … I know we need to move over in October of this year, but if you back things out, we need to get a services agreement in place right now if we’re going to make it.”


Tommy:When we’re doing those we’re estimating certain things, one is the actual physical migration and the other is what types of enhancements do we need to make as a part of that generic process and tooling. What additional scripts or enhancements to the tool needs to take place? Do you have anything that needs to be custom built on the other end? Let’s say maybe you’re using for the case of Jive, you’ve got a landing page in Jive that has widgets and it’s arranged in a certain way. Maybe we need to build that on the SharePoint side so we can give the user a similar experience when they show up at the new location, when the previous location is shut down.


When you look at those steps, the analysis and planning, what comes right after that is what we call configure and develop. Configure and develop is, what do we need to configure in the tool and the environments to run a migration, and then what do we need to develop to enhance the kind of out of the box migration experience. That might be from the tooling or the destination side to create some things custom to get a better adoption after this is migrated.


Then we go into a pilot and we go into an actual production migration, and then a stabilization transition to get that platform finalized so you can shut down the previous environment. With those phases, the way I look at it when I put my Scrum hat on is I look at each of these phases-


Danny:You have a Scrum hat? Wait a minute.


Tommy:I do, I do.


Danny:You have a Scrum hat.


Tommy:It’s kind of messy.


Danny:Where is it? You keep that by your desk? You pull that out when somebody takes the wrong move?


Tommy:I wear a few hats around here.


Danny:You wear so many hats you don’t have hair on your head, neither do I but that’s not the reason, that’s a whole nother thing. Go ahead, sorry. You were saying about a Scrum hat?


Tommy:When you’re look at these phases … Let me get back to my process please. When you’re looking at a phase, I can draw the analogy of that phase is like a release in Scrum. When you have a release, within that release you have sprints and within that you have your daily cycles. What we look at is when we get into that phase of planning, or let’s say if the configure and develop phase, we have a budget set for that that is enough budget to get the goal accomplished, but we want to accomplish that goal in the most optimized way possible. You go into that phase and you say, “Here’s the 10 things that we know, the 10 stories that are inside of this phase,” and we want to give the highest value during that period of time.


When we come up with other ideas, let’s say, during that phase then we can adapt to going after the better ideas. That’s, I think, the beautiful thing about Scrum is you’re not committed to a story until you get into that sprint. You’re flexible enough to change your mind if you want to spend that money in a better way.


Danny:It all goes back to your manufacturing days, just in time, minimize rework. It just seems to be that’s what you’re ultimately trying to do, is not creating a bunch of rework.


Tommy:Right, but with migrations the, quote, standard is you really do have those phases that are logical steps to get you there. You’re not going to flex as much on that because it just doesn’t make sense. You skip one of those steps and then you end up putting yourself at risk for a successful migration. We’re finding that it really is a mixture of a waterfall, you have this phase and this phase and this phase, that you don’t do them all together every sprint.


You really need to be in a mindset of, “Let’s finish a certain amount of analysis. Let’s finish a certain amount of planning. We need to finish the configuration and development, and then let’s pilot this thing to prove out everything that we did leading up to that is working. Then let’s go into production, guns loaded,” doing this as fast as possible. Because as soon as you start that migration now you’ve got 2 places where that content is and the sooner we can get it all in that destination and be able to shut down the source, the better off that organization is going to be in terms of being confused and disrupted.


Danny:Yes. Chris and I talked about ludicrous mode.




Danny:We need to then go into ludicrous mode.


Tommy:It’s all about ludicrous mode, yes.


Danny:We’ve got the special sauce for turning on the ludicrous. I want to thank you today also for wearing cool socks again.




Danny:You have outdone me.


Tommy:How do you like that?


Danny:I know people can’t see this.


Tommy:You’re going to have to have a vlog so we can show the socks.


Danny:I think I need to take a picture of that and I’ll put it up on the blog as I post it up. Man, that’s pretty nice. He’s got grey and blue and dark blue socks. Does that match your Scrum hat?


Tommy:It’s why I have multiple hats, whatever the color of socks I have I put on a hat.


Danny:I like it. You met with somebody today as well.


Tommy:I did. I actually met with 2 clients today, very good morning.


Danny:It’s great. That’s good. I’m glad to hear that. Anything else we want to talk about with this?


Tommy:You’re ready to be done with processes, aren’t you?


Danny:I know, I know. I know. You’re like, “I just got started Danny, I’m about halfway through the subject.” To wrap it up Tommy what do you …


Tommy:No, I think a lesson learned, and I’m working on the blog when I get to that point. I’m really just making sure that we’re doing the right thing by applying Scrum to our migration projects. It seems to fit. I think you have to put it in the right perspective and not make it Agile from the perspective of it’s just one big project. We can go in any direction. I think that works well for some app dev that we do, but when it comes to migrations we need to have some discipline of these phases and there are certain things that have to take place in those phases to be successful.


Danny:Good. That’s great that we’re taking the time to learn that. I, from an outsider again looking in on a couple of these projects, it seems it’s continuing to serve us, flexibility wise as well.


Tommy:Yeah, that’s what we want.




Tommy:We have the 3 Cs. I think having choice, we want that in every project that we do. We don’t want someone to feel like, “I’m stuck.” We want to give them the right guidance and put in the guardrails but give choice within those guardrails.


Danny:I like it. I like it. I’m whispering now, I don’t know why. I don’t know why I’m whispering. Great, thank you for taking the time to do this.


Tommy:Sure Danny.


Danny:It’s a pleasure, even when we’re talking about process. It was a pleasure. I stayed awake for the whole thing. I’m here, I’m right here with you. Thank you everybody, you stuck with us too, wow. All right, way to go. Thank you for taking the time to listen today. Definitely if you’re looking at migrating to Office 365, especially for folks who might be doing from a platform like Jive or some other content platform, feel free to reach out to us, it’s a topic we’re pretty passionate about talking about. Just come to us through the website, just go to the contact us page, that sends me an email and we’ll talk very soon about it. Thank you so much for taking the time to listen today. Have a wonderful day, bye bye.


Tommy:Bye bye.


read more
Tommy RyanUsing SCRUM on Migration Projects

SCURM [sic] – Quality Assurance and SCRUM

Brandon Holloway is a Quality Assurance Engineer at ThreeWill. He has over 10 years of QA experience in requirements gathering, risk analysis, project planning, project sizing, scheduling, testing, defect/bug tracking, management, and reporting.

Note from Danny – As I was looking for a an image to go with this episode on Shuttershock, I ran into this image that had SCRUM misspelled. Well, that’s a perfect image for Quality Assurance and SCRUM…

Danny:Hello, this is Danny Ryan. Welcome to the ThreeWill podcast. Today I have Brandon Holloway.


Brandon :Thanks for having me, Danny.


Danny:You’re welcome. I don’t know why I want to start singing.


Brandon :I don’t know.


Danny:I’m going to start singing if that’s okay.


Brandon :[Crosstalk 00:00:14].


Danny:I’m going to sing. All my questions for you will be sung.


Brandon :Interesting.


Danny:Brandon helps out with our QA, otherwise known as quality assurance. He makes sure that everything’s staying tiptop quality-wise on our projects. I have asked him to sit down and just tell me what does it mean to do QA on a typical ThreeWill project? What does that mean to me?


Let’s get started off with this question. When do you typically get pulled in first for the project? Just we’re talking about generally for the typical project that you’d be a part of.


Brandon :I’ll usually get pulled in a lot of times at the very beginning even though it’s going to be a few weeks before there’s going to be any real testing even if it’s still in the requirements gathering, or architecture phases. Sometimes it’s good for me to be there because I’m still thinking in the beginning on how would a user approach this which is the mindset I try to put myself into. They try to involve me as early as possible that I could provide some value.


Danny:You usually start off with taking a look at the product backlog and what the user stories are. Is that where your first thing that you interact with on the project?


Brandon :Right, right, the user stories and the product backlog, that’s right. A lot of times a lot of what I focus on is the acceptance criteria which is definitely not the only thing I look at for it. Like I said, I got to put myself in the user perspective. What does this story mean to the typical user and just figure how to build test cases off of that.


A lot of times early in the sprints and early in the project I can go ahead and start working on test cases based off of mainly the product backlog, even well before testing is actually available to be done.


Danny:Then you would, as you find defects you would log those defects. Is there a typical place where we’re putting those defects?


Brandon :On most projects we use SharePoint to …


Danny:SharePoint, tell me more about this. What is this?


Brandon :Yes, it’s this thing we use around here called SharePoint. It’s a pretty cool little application.


Danny:Sounds fascinating, fascinating.


Brandon :Yeah, a lot of times we just have an issues list. It’s just a basic list in SharePoint that a lot of the developers will set up alerts for so they see. They know when they get a issue coming across they can go straight in there and work on it. It’s just [crosstalk 00:02:54] …


Danny:It probably has a status column as far as where the defect …


Brandon :The normal, the priority, what I think the priority should be. This is what I think the severity should be, what type of issue it is, that kind of thing. I’ll just assign it to whoever. Usually whoever is assigned to that particular product backlog, or that feature, that can vary though. Sometimes we’ll pass it to somebody else that it may be a better fit to work on.


Danny:You know when to retest because they’re updating that issue log.


Brandon :Correct, yeah. There’s a few different statuses that it’ll go though. When I first open an issue, I always see it’s an open status. When the developer fixes it, it’ll go decoded status. It’s not available for me to test yet. They have to just check their coding. Whenever they get ready for another QA deployment, then they deploy it and then it’s in the QA environment ready to be tested. Then they’ll move it to either deployed, to QA, or ready for QA. There’s a couple different statuses on the project.


Danny:A lot of our projects will have a separate QA environment that you work within. Is that correct?


Brandon :Yes.


Danny:Is that normal?


Brandon :Yeah, it’s pretty normal. We’ve used a couple different cloud service 1 time to ….


Danny:Geese. Host failure. Host failure. Just a second. It could be anybody. I’m sorry. Now I’m going to shut this off and here we go. You were saying, sir, yes.


Brandon :The best case is probably when the clients themselves have QA environments set up that I can go in there and use. That’s usually the best method just because that’s basically what they’re going to have their own UAT environment in that same environment to production. Everything should be similar. It should be more along the lines of how it’s going to be in the real world. I have a couple different virtual machines that I’ll host a QA site in. It depends on the project and if they have an actual QA environment for us to work on or not.


Danny:Got you.


Brandon :We just deal with what we got.


Danny:Yeah. It just depends on the project really.


Brandon :It does.


Danny:Yeah, how does it work with …? Are you testing? Within the Sprint cycle, are you testing things that were implemented in the previous cycle and then they’re doing a defect resolution, or giving some capacity towards defect resolution in certain sprints? How does that all work?


Brandon :In a perfect world …


Danny:In a perfect world. Tell me this imaginary place …


Brandon :… which it is not.


Danny:… that you call in a perfect world.


Brandon :Excuse me. Say it’s a …. For instance we’ll say a 2 week sprint. In a perfect world, I would write my test cases maybe the first week or somewhere in that time frame. Maybe the beginning of the second week of that sprint all those product backlog items of stories will be available for me to test.


I should be able to get those at least a good round of testing in within a couple days. Maybe by Wednesday of the second week, or so, assuming the sprint ends on a Friday. Whatever issues come out of that, they can be working those issues and get them back to me and I can retest them so I can get everything closed out and everything marked as tested by the last day, or the day before the last day of the sprint. That’s a perfect world.


Danny:That’s a perfect world.


Brandon :It doesn’t always happen like that, of course. There’s just a lot of factors, a lot of movement going on everywhere. People change priorities of stories and the client’s involved pretty heavily in Scrum. We just adapt with it. I adapt just like everybody else does. Sometimes that means maybe a couple of product backlog items for a sprint may just be all the way pushed to the next sprint.


Sometimes I may get them on the actual last day of the sprint. I at least get what testing done I can, like maybe a good smoke test of the functionality, or just do some ad hoc testing to hit the points that I think may be most prone to have issues, at least get as much done of a first round of testing as I can before the beginning of the next week rolls around and we have a sprint review.


From there I’ll clean up all the test cases and run the rest of the tests and everything. It may be into the very beginning of the next sprint. That happens sometimes. It’s not a perfect world.


Danny:It sounds like a lot of the type of testing that you’re doing, is it more like end user testing, really trying to focus in on what the experience that …


Brandon :It is.


Danny:… the end user would have with …?


Brandon :Right. It’s pretty much all manual testing and it’s mainly use cases. A lot of the reason for that is balancing a couple different projects. Whatever my capacity is on a particular project, I have to base my testing scope around that capacity. There’s always more testing to be done. You could test forever on something and still not 100% cover everything. It’s just the nature of it.


Basically, I build off what my capacity is for this project, what we decided on with the client for this project, out of that amount of hours I’m going to get the most effective testing I can done out of that. That’s pretty much going to be manual use case testing; not a lot of tools involved. It’s more of a time sensitive thing. We want to make sure we hit everything that we can from a user’s perspective so that ….


Danny:Got you. It sounds like you’re across multiple projects. You probably have to …. You’re probably coming in since we’re building a lot of web-based stuff, probably have to get a list of which browsers are supported, that sort of stuff as well.


Brandon :Right, yeah, that’s another big part of it. Sometimes there’ll be a project where Internet Explorer 10 only. That’s the only browser I have to test in. Many times, they want to support it on Chrome. They want it IE10 and up which includes IE11 and in some cases maybe Microsoft Edge will start coming in since it’s a newer browser.


Sometimes Firefox needs to be supported. It just depends on the project. A lot of times there is definitely cross browser testing. IE, in particular, tends to behave differently in some situations than say Chrome and most [crosstalk 00:10:02] …




Brandon :… Firefox.




Brandon :Yeah. IE is fun. There’s always that to deal with.


Danny:Are you crying? There’s no need to cry. Did IE bring tears to your eye? Don’t look like tears of joy either.


Brandon :My eye’s just watering.


Danny:Tell me a couple more questions and I’ll let you go. I’ll let you leave. What do you find is the most challenging part of what you do?


Brandon :Definitely 1 thing is that just the nature of being Agile Scrum is that you don’t get as concrete requirements to test on, which for testing is very important. It’s important for everybody at my project. I base what I build in my test cases off of what is supposed to happen in these situations.


You don’t have detailed requirements, very detailed requirements sometimes in Scrum, at least in my experience. That’s 1 thing. There’s a lot more interaction between myself and developers. I ask questions. That’s how I like how everybody’s so open here. It’s just easy to get with somebody about something like that. Definitely I’ll need things clarified.


Sometimes it takes a while for me to get the full picture of everything without these hard requirements and everything. That’s mainly 1 of the challenges and of course just time in general, what things get pushed back. Testing is at the end of everything.


Sometimes I find myself working late on a Friday, a little bit on the weekend, which it’s not a big deal. That definitely can come into play, especially later in projects depending on what needs to be put into the backlog at the last minute or taken out.


Danny:I think when we look at what makes a great QA person is they have to come in and take some initiative to come into it. You’re coming in to a project and really trying to understand what are we trying to do for the client as well. I think you do a great job at that from what I’m hearing from other people. You’ve tested my Web site.


Brandon :I’m about half way done with it. I got 2 lists of things.


Danny:For people who come to, it’s half tested. How’s that make you feel? It’s half tested. Don’t worry. I change things daily. I mean I don’t change the name of the company daily, but I do change a lot of stuff on my Web site daily just to keep things moving.


Brandon :I didn’t realize how much there was on that Web site.


Danny:It’s a dynamic site. It’s a dynamic.


Brandon :It’s pretty large.


Danny:Maybe it’s a softball, maybe it’s not a softball question, but what do you love about what you do?


Brandon :Man, I just don’t know. It’s like I’m a perfectionist in a way. I hate to say I like it’s like a treasure hunt almost. It’s fun. There’s something in here that I’m going to find that’s not doing what it’s supposed to be doing.


It’s like finding things like that, not mistakes. That’s a bad word for it. I like finding bugs. It’s just like a hunt for me. Since I first started testing, I didn’t even know coming out of college with my degree, I didn’t even know there was a profession, software tester, or whatever.


I have a cousin that did that at a company back in Columbus. I was like, “Man, this sounds like something right up my alley.” I started doing it. I love it. It’s just you never know what you’re going to come across. Working with great developers obviously helps a lot.


Sometimes in the past, other jobs sometimes you don’t have developers that are very willing to …. Some look at QA as, “Oh, that guy, my nemesis.” It’s not like that here. Everybody’s on the same team. It’s great.


Danny:I heard, within the past week, Eric was talking about how much he appreciates what you do and how he feels better after you’ve tested something. It’s wonderful having you around to do that. You’re an important part of each 1 of our projects. I love it that you love to do. It is treasure hunting. You’re trying to go figure out.


Brandon :Can’t think of another way to put it. [Crosstalk 00:14:41].


Danny:It’s fun. No, it’s a great analogy. It’s a wonderful analogy. You’re trying to go in and figure out what are the important, when talking about treasure, what are the big things that we might’ve overseen as a developer.


Brandon :A lot of times I have to put myself into the end user’s shoes is what I’m doing. I’m thinking, “What would a user do here? Does this look right to the user’s perspective?” Just giving that whole side of things, I like it.


Danny:We love having you here too. We can really think through the what from somebody from Alabama would do.


Brandon :Here we go with this again.


Danny:For those that’s not an inside joke. He’s from Phoenix City, Alabama. Yes, he’s representing Alabama in the ThreeWill family. We now have a southeast …


Brandon :Not the school. Not the school Alabama.


Danny:Not the school. Yeah, let’s get that straight.


Brandon :Even the state.


Danny:I’m sorry. You’re representing the state of Alabama.


Brandon :We’ll say that, yeah.


Danny:The school of Auburn.


Brandon :Auburn.


Danny:Geese, there’s too many of you guys around here. Why don’t you go hang out with our other Auburn friends and get the heck out of here? That’s the end of this episode. Let’s get out of here.


Brandon :[Crosstalk 00:16:00].


Danny:Yeah, I’m going to kick the …. Here’s where I’d kick the microphone over and like, “Get out of here.” Slam the door.


Brandon :Y’all are the guys hiring the Auburn folks. Do you know what I mean? That should tell you something.


Danny:With that, I think we’ll wrap up this episode. Thanks so much for listening everybody. Brandon, thank you for your time.


Brandon :Thank you.


Danny:Go get back to testing and go back. You’ve got a long ride home from here. You’re heading …


Brandon :Yeah, a couple hours.


Danny:… going to head home. A couple hours.


Brandon :Back to Alabama.


Danny:All right. Just test this like you were someone from Alabama. Thank you for spending your time here, Brandon.


Brandon :Thanks.


Danny:Take care. Bye-bye.


read more
Brandon HollowaySCURM [sic] – Quality Assurance and SCRUM