Please find below a transcription of the audio portion of Tim Runcie’s Agile Series Part 1 webinar being provided by MPUG for the convenience of our members. You may wish to use this transcript for the purposes of self-paced learning, searching for specific information, and/or performing a quick review of webinar content. There may be exclusions, such as those steps included in product demonstrations. You may watch the live recording of this webinar at your convenience.
Kyle: Hello everyone and welcome to today’s MPUG training series, part one, Understanding and Incorporating Agile Project Management. My name is Kyle and I’ll be the moderator today. Today’s session is eligible for one PMI PDU in the technical category and the code for claiming today’s session is on the screen now. If you have any questions during today’s presentation, please send those over at any time using the chat question box on the GoToWebinar control panel and we do plan to answer those for you at the end of the session today. All right, we’ll go ahead and get started right away. We’re very happy to welcome back Tim Runcie. Today Tim is one of six Microsoft project MVPs in North America and has held the title for 16 years in a row. Tim works with companies like Microsoft on next generations of project, program and portfolio of technologies. He’s an accomplished speaker, consultant and educator supporting the project management community for over 25 years. As the president and founder of Advisicon, Tim has also written over 38 books on PM methodologies and technologies. So, with that said, I’d like to welcome you back Tim and at this time I’ll hand it over to you to get started with today’s session.
Tim Runcie: Sounds great. Wonderful. Thank you Kyle. All right, let’s show my screen because that’s where half the fun is. So let’s pop that up. Kyle, let me know if you can see that clearly jump into focus there.
Kyle: Looks good.
Tim Runcie: Wonderful. Welcome everyone. Pleasure to have you here with us today. This is a webinar series, part one of three. So there’ll be three stages that we’ll go through. And I had a lot of fun kind of putting this together, trying to ensure that I didn’t put too much in each of the sessions. But this is an exciting topic, there’s a lot going on with agile, it’s probably one of the hottest buzzwords for the last almost decade and there are still emerging concepts that are coming up that literally there are foundations, there are accreditations that are emerging since 2016. So this is still a great time to be, again, to review how you do things and how you put that together. As Kyle said, I’ve been doing this a long time, really enjoy teaching, speaking and helping people. So even if you’re watching the recording of this or today, I encourage people to reach out to me anytime with questions, what’s going on and to find out a little bit more about it.
A lot of what has really kind of led me down the path of understanding what agile will do, not only with just Microsoft project and the direction of project and where it’s going is conversations that we have, not only with the Microsoft engineering teams, but the business, the marketing teams, the sales teams, and then again, for customers, right? Customers are always simply saying, “Hey, look, I need a better tool to make this happen.” And we’ve watched over the last, I would say the last 10 years, we’ve watched a transformation of business where now we have kind of this exodus of people that have grown up on some of the older methodologies. And we have this new millennial generation, Gen X, Gen Y, Gen Z where literally, the workforce is now over 50% with people who grew up with technology that don’t remember rotary phones or putting vinyl in the record. Actually vinyl is pretty hot now, I think it’s outselling CDs.
But it’s exciting to watch the need of the customer always is important, so that voice of the customer kind of surfaces to what will be needed. And what we’re going to do is talk about the disciplines today, talking about how and where Microsoft’s going, what are some of the advantages of using agile. So if you’re new to this or perhaps you’ve kind of been using it in a couple of different veins, maybe you’ve been part of a scrum team or you’ve watched it happen around you, or maybe you’ve seen a horrific implementation of an agile process, it isn’t necessarily the methodology, but sometimes you have to think about your culture, the environment, and what you’re trying to do. And I think this is what we’ll be really [inaudible 00:04:02] to sink our teeth into today. So we’ll talk about benefits, disadvantages, we’ll get into a little bit of what is a methodology, which one? What are the best pieces? And what I really like away in terms of takeaways is that there is no sacred cow here. It’s not all or nothing.
So a lot of times people are like, “Oh my gosh, I’m a waterfall guy or I’m an agile girl,” or, “Hey, listen, I’m a Prince2 person.” The idea is that there is no necessarily fixed and hard and fast rule. And as you know with even technology and the improvement of what we’re doing in our mobile devices, we’re seeing a massive change in the way that work is being done for the project management community today. So we’ll kind of wrap up a little bit with where Microsoft’s going. I literally am sitting on a powder keg of stuff that I cannot talk about and so I had a conversation this week, which is what can I share? What can I share? And so stay tuned through MPUG channels and we have webinars and YouTube’s that are going out there, you will hear it as soon as we’re able to release it, but there’s some really exciting things, especially around the agile space, and then looking at the reinvention of what project will and can do. So we’ll take some questions at the end and then set you guys up for our next session, which hopefully you can attend next week in person or if not, just click on the next recording and you’ll be there. All right, so as we get into a little bit of an overview or an introduction to agile, this is new for you.
This session is not designed to be the PhD in agile, right? So we’ve got an hour and a half, I want to make sure you really grasp the moving parts or the key pieces that go and some of the disciplines and methodologies. And I think that’ll be important for all of us as we really begin thinking through how does agile work. So the diagram here, that’s kind of on the introduction here, we’ll talk about incremental plans. Hey, we’re going to build this phase one, phase two, phase three, and you can kind of see that there’s a delivery and the delivery will continue to unpack itself until it gets to a full solution. While with an integrative plan, in many cases you’re going to see things kind of maybe move into a clear focus. And so the intent with agile is to really make sure that you have something that provides value.
Now, if like myself as an executive, I work with a lot of CEOs, a lot of presidents, we do strategic planning and we try and figure this out, we even work with nonprofits, which is amazing. You have these wonderful nonprofits, we’re trying to figure out where they’re going and they don’t understand methodology or advanced disciplines. But you’ve probably seen this in your career where you have people jumping around going, “Oh, hey, here’s the next silver bullet,” or, “We are going to turn into a scrum or an agile shop.” Well, what happens is that a lot of people will put all their eggs in one basket and we have to be careful about that. I’ve got some articles, in fact, I just wrote one last week for MPUG, if you haven’t seen it, talks about how agile is being used at Microsoft to eliminate bureaucracy.
And this is actually fairly huge because Microsoft just crossed over the $1 trillion mark in terms of revenue assets for the company and Amazon not far behind, also implementing agile in a global perspective to help them really kind of innovate and create a much more competitive of company and organization. What you’ll probably find is as organizations get bigger and bigger, it’s kind of like the Titanic, it’s really hard to turn. And so this is where agile kind of fits in and isn’t just necessarily only for software development. In fact, back in the 1990s and even the 80s when I was working construction we did agile practices all the time, we just didn’t call it agile. So when we start with agile, we talk about the agile manifesto and I think this is important. If you want to go out there and Bing this or Google it, look it up, you’re going to find that it talks about here is the manifesto of what we’re trying to accomplish.
So individuals and interactions over processes and tools. Now it’s not to say that processes and tools are bad or documentation is bad or putting something in writing, but the idea is that there’s an investment that really will be a little bit different. We’re shaping how we’re going to get things done, and so zeroing in on individuals interactions. Also key thing with an agile technology or an agile discipline is that we’re looking at producing value, talking about working software, not wireframes, not lots of process and flow charts, that’s not the goal of producing a solution, it’s really something that’s really tangible. And remember, agile is kind of born out of the need for technical project management or in many cases, software development. But it is clearly not limited to just software. And so the idea is that we can spend lots of time with comprehensive documentation mapping and modeling everything, but when you talk to customers, if you’ve ever done requirements gathering, a lot of times they have an idea, but that isn’t fleshed out. And so if you look at the third item here, it talks about customer collaboration versus strict or rigid contract negotiation.
And so what’s kind of funny here is that customers who typically get embedded in an agile team, they love it. They really like it. Now, what’s really funny is in the same projects, the executives hate agile, right? There’s so much lovey-dovey, touchy-feely, the stuff is changing all the time and a lot of times people are gold-plating things and so executives want to, or senior business leaders are looking to say, “Hey, are we going to hit the mark? Are we going to deliver?” And so this is where we’ll talk about today, the importance of balancing the needs of your stakeholders. Remember, the customer might be someone that you’re building a tool solution for, or maybe you’re going to create a new landscape model and they have an idea, they drew a sketch on a napkin and you’re kind of going to put it together, but we talk about that progressive elaboration and the idea of having as much involvement with your stakeholders is hugely important. Again, you still need to make sure that you’re on time, hopefully under budget and within schedule. And so that whole idea is that if you look at scope, schedule and budget, the iron triangle, these are still important.
Again, clearly moving forward into what we call reflexive or adaptability. And the idea is that in many cases, and I have seen this happen on projects that I’ve been involved with, where people will follow the plan dogmatically they don’t want to deviate, hey, that’s what’s being said, this is what we’re told that’s in the contract versus responding adaptively that that’s not working.
And so the idea is that this isn’t just about how to execute a project, it’s really about setting a mindset and in some cases, creating an agile culture that is able to put together, whether it’s methodology or tools together to help deliver value. So all agile components really fall into a series of key things. At the top here, it talks about what are called complex adaptive systems. If you think about that is that we’re trying to accomplish something many times it’s never been done before. And so what we’re trying to do is make sure that we have the ability to adapt and produce something. And so whether we’re talking about extreme programming or scrum or Kanban basically how a product is organized versus how we’re actually doing the work.
Lean, we’ll talk about just in time or we think about continuous process improvement. There are a lot of different ways to approach this. And again, not every methodology fits the same, right? We talk about find or pick what’s you’re trying to work on? Are we talking about architecture? Are we talking about producing results? Are we looking at a continuous change or creating a framework that says, not only are we going to do this once, but we’re going to be doing this day in and day out. This is a new core feature or capability of an organization. So there are systems, there are frameworks, there’s disciplines and methodologies and I’ll kind of wrap these together. But the idea is that the approaches of how we do this in many cases aren’t necessarily just a purist in one area. And so at the bottom here I talk about Scrummerfall or Wagile or are you sprinting down the waterfall. And there’s lots of flavors where people talk about this.
And so what I want you to know is that as we’re starting to dig in, you’re going to start hearing very similar things. Things that were invented in the 90s and the early 2000s, we’ll see things that are emerging even today are really picking up on strong veins of information or veins of approaches to really address solutions. And of course, most organizations out there today, when we talk about agile or project management or waterfall or the different approaches, they don’t use anything. In fact, the most common surveyed methodology across organizations or the accidental project managers that are out there is something called GERD, which is the Get-R-Done method, right? Just Get-R-Done, I’ve made you a project manager, whatever that means, go get this done. And so there is certainly a pendulum of low maturity to high maturity and how you do that.
There’s expensive tools, there’s inexpensive tools, and I think that’s going to be important for everyone as we begin thinking through not only where Microsoft is going, but how we can make the components work for us. So what we’ll talk about next is a little bit of what I refer to is how is agile different than other methodologies? In many cases, if you haven’t seen some of the lectures that I’ve done or talking about the integration of say team foundation server or Azure DevOps or project or planner or the different products that are out there is that you can embed agile inside of a waterfall process. In fact, there is nothing wrong with that in terms of how we look at getting execution done. But inherently we do need to roll up and visualize some of those key elements. So we talk about lifecycle phases of the non-agile approaches, right? So if we think in terms of they’re fairly rigid, they are structured, there’s check boxes.
In many cases, in a non-agile approach they’re referred to what’s called planning and documentation. There is a lot, even if you look at PMI or you look at Prince2, there’s a lot that you go through in defining requirements, creating risk plans. And while this isn’t something you necessarily want to throw out the window, in many cases, what you’ll find is that the self leveling that happens, whether it’s issues or risks, these things happen, the teams need to be focused on making sure they’re producing those values. So as we get in here, here’s a standard project management lifecycle. This comes a little flow chart that we’ve built that we do with a lot of our project management classes and people like it. They kind of put this 11 by 17 flow chart up on the wall, and it’s great to have a visual to kind of think through and say, “Ah, I got it,” right? “I’m right here in this part of my life cycle.”
But if you think about the initiation, the planning, the execution, controlling phases and closing, is that again, fairly kind of rigid if you want to watch the process unfold. However, if we were to tip the weighting is that the idea of the initiation and planning phase, this is really to make the execution be as minimal as possible. And usually that’s where a lot of the work is. So if we look at the bulk of hours, the bulk of hours in many cases falls under execution and the idea, the building or developing or designing something. And if you’re in program management where you have continual releases or continue updates or perhaps a very long, long-term spanning initiative, this becomes hard if you are only following just a straight non-agile lifecycle.
And so as you start looking at technical teams, the idea is that you want to make sure that we want to produce value quickly. So in that we’ll talk about a couple, I mentioned PMI which is the initiate plan, execute, control and the closeout phases. One that’s very common in Europe and certainly in the South America, which is a lot of fun, if you ever go down there, I recommend certainly checking into a PMI chapter or checking into the project management community. But you’ll see the thing Prince2 comes up. And so we’ve had some questions on this, so I thought I’d just kind of put a breakdown. So again, non-agile Prince2 is really based on projects in a controlled environment, right? In a controlled environment. And that’s where they pull out the Prince, P-R-I-N-C-E. Where’s the N? Here it is, N, oops, I forgot to highlight that, but yep. In a controlled environment and inherently what you want to make sure that you’re doing is validating that things get done. Now let’s talk about controlled environment.
So if you’re a parent, you really understand that the lack of control is something you have to deal with all the time. There’s just so many variables that it is very difficult and you can’t spend a lot of energy around that. So the seven principles really are talking about the importance of justification of a project, which makes sense. You define your roles and responsibilities. We’re going to see a parallelism between some of the different agile methodologies that call out, “Hey, I am a scrum master, I’m a product owner,” right? “I have chickens and pigs.” You’re going to hear some different things that maybe you’ve not heard before, but the idea is that roles and responsibilities are clearly defined. Inherently there’s a learning component to this and this is important. We talk about lessons learned post-mortem, but the idea is that you learn from the experience, again, we’re back to those stages and really we look at working through the exceptions but the focus is on the product. And again it is tailorable.
So whether it’s a waterfall approach or you’re looking at some of the seven stages which is starting directing, initiating a project, controlling, managing product delivering, managing the stage boundaries, which is important around making sure that we don’t have additional scopes squeezing into a project and then getting to closing. You’ll see a lot of the similar flavors, even in non-agile approaches. So thinking through this, we get into kind of the idea of waterfall planning requirements that leads to a final product after go live. Now if we take a step back and even look at what’s happening now in Office 365 and you look at a lot of the development that’s happening in a very iterative and in fashion, even in construction where we talk about 30% design, 60% design, 90% design, there’s a lot of this that says, “Hey look, there are iterations that are being kind of infused in to make sure that this progressive elaboration happens.” However, in the past, if you even go back into 2013 is probably where we’ll see a big transition in how even Microsoft is developing software is that they go out, talk to all their stakeholders, they define their requirements, figure out what they want to build and they build, build, build, and then three years later there’s a whole upgrade, right? Well, what happens in three years? People’s needs change, the climate changes, the economy changes, politics changes.
There are so many variables that say, look what you needed something three years ago isn’t necessarily true today. And now what people complain most about is that while you’re working in, say for example, Office 365 is you get weekly updates. In fact, last night a weekly update came out talking about the announcement of new modern project, basically this new experience that you’ll hear more about in November. And so I think there’ll probably be some tweets and LinkedIn posts going out from me probably later on today, but the inherent idea is that this stuff is changing on a weekly basis. And so sometimes there’s a constant stream of little things that are happening. Hey, yesterday it was over here on this menu, now it’s moved over here. And so it kind of drives people a little bit nuts. And so I usually describe this as that people who have worked in projects or worked with technology, as you’ve grown up with technology, you become a little bit more flexible. And so this reflexive or adaptive that says, “Eh, it’s on here somewhere, let me find it up. There’s the ellipses, let me push the button, I can see it, I can find that,” is really looking at versus all upfront requirements gathering and then we roll out a big bang release.
We’re talking about getting to instant gratification or faster gratification. Now a lot of people laugh and make fun of some of the society today, and they call it the microwave society, right? Everything’s quick and fast, but really the demand is why should I wait three years when I need something very simple? I have my complaints, I keep asking Microsoft, please let me rename the baseline. I want to make sure that I can just add a name to the baseline. That’s not that hard. It’s not that much. But when they look at the prioritization of what’s going on, they put that on the backlog and they go through and they prioritize it. And again, from an agile perspective or a series of iterations, they zero in on the ability to deliver the highest value first.
And unfortunately, sometimes my idea is don’t always make it to the top, or at least some of them do and some of them don’t. But as we go through that, the differences really are is that there’s less documentation in an agile approach. Doesn’t mean there isn’t documentation, but the focus is on the low hanging fruit because in many cases if you build a prototype or you model it, people can look at it and go, “Oh, that, yeah, I know I said that, but that’s not what I meant.” Right? Or, “Oh, now that I see it, I really don’t understand, that’s not going to work for what I need.” Or especially for larger organizations or longer programs or projects is that you need to be able to adapt to the emerging needs or requirements.
And so many organizations are launching these massive programs, building these new monolithic systems and by the time they’re done, the business or the industry has completely changed or the company got acquired or now they’re partnering with someone else. And so you have to have this iterative and collaborative approach and that is something that is a unique difference between some of what you’ll think about in a waterfall approach versus saying… zeroing in on agile. The other thing is that the requirements change and there’s an assumption that they will, and this is okay, right? A lot of times people get frustrated and say, “Well, no, I wrote this down. I documented it.” And you embrace agile. In many cases you’re going to find that it’s not just about, okay, well, we documented it, it’s like, no. It’s okay for those things to change. In fact, there are certain, even in the agile disciplines talking about say the difference perhaps maybe between scrum and extreme programming where scrum is even restrictive, which says during a sprint you can’t make changes, right? While extreme programming is, you’re still making changes even if you’re in a scheduled period of a release.
So the idea is that sometimes you want to buy, have that ability to say, “The requirements may emerge or change and need to be addressed,” and people are focused on what is the solution? And so if something has never been done before, it’s hard to kind of figure out an estimate. And so in many cases, this is where you have to kind of work through it, think through it, learn from it and develop some of the moving parts not only with perhaps with the end stakeholder or the customer, but also with the teams that are delivering it. And so again this is founded back in software development and you can see this most commonly in here, but it is clearly not restrictive. And again, I mentioned some of my background is I used to be in construction. So that was one of the things that I did growing up even as a teenager, I worked construction, I had a construction company.
I went to a trade school where I majored in construction and at some point when I graduated, I wanted to become an attorney and I thought, “Oh what can I do that doesn’t take a lot of energy? I need some money.” So I went into the Navy and became a construction battalion, it was called CB and I picked it because it was so easy because I had been doing it for a long time. And one of the things that we found is that every morning we’d have our stand ups, uh-oh there’s an agile term. A stand-up huddling around a burn barrel, right? We’d throw all kind of all scraps of wood in there and we’d be working over what needs to happen or what problem surfaced or what came up. And so being adaptive and having your teams basically be able to shift and focus on what was being done didn’t exclude the fact that there were plans and there was permitting and there was work that needed to happen, but in the execution phase of the project we had to adopt agile principles in order to maximize a much leaner approach and ensure that we got to a better value. So as we go through that, some of the benefits and disadvantages of agile are clear.
And I’m going to kind of pull these out to make sure we can kind of hover over these. But not always is it important to just jump into and do a full agile approach? I think one of the things that organizations find is they’ll jump in and do it and they will dogmatically stick to it when sometimes you need to take a step back and go, “It’s not working.” So if we look back at that agile manifesto, you really understand that there’s some flexibility that needs to happen. And as I’ve said, I’ve sat on… I’ve actually sat on agile projects as an architect and they were doing full scrum, but they wouldn’t talk to the customer and I’m like, okay, wait a minute, what are we doing here? We’re building something and this customer is not embedded. They were not providing feedback and it was really political, right? Well these guys we don’t get along with and they’ve hired us to do this, so we’ll show them. And I just watched these things like a train wreck. So there are definitely things that you want to make sure that you incorporate and also understand that not every agile discipline is going to be as strong follow up for perhaps the type of work that you’re doing.
So let’s jump into some of the benefits. I think this is important as you begin kind of organizing and structuring your thought, or if you’re on an agile team and you’re going, “I just can’t put my finger on it, but something isn’t harmonious. I’m not seeing this a workout.” Well, it could be that the culture or the type of approach that you’re doing is not maybe fully aligned. And so I think this is where we talk about here are some of the benefits. So again, the idea is to get to a prototype quickly, get to value, show something, working software, working model. I need to be able to visualize that as quickly as we can. And that way instead of spending a lot more time on requirements, what I can do is go, “All right, we’re going to time box these, we’ll make sure we have our estimates in place, but inherently I can quickly validate the requirements with something that’s much more visual.” For those of you that do Microsoft project work or you do SharePoint, if you ever sat down with somebody and said, “Okay, we need to design our SharePoint site and I need to make sure I’ve got some tasks, I’ve got to changed request log, I’ve got my documentation.”
Or if you’re not using Microsoft teams, most likely you will hear pretty soon and suddenly you’re saying, “Well, I need to quickly kind of organize how we’re showing and sharing information.” And so as you go into one of these projects, you’re kind of organizing it, it’s really helpful to kind of see either preexamples or see things that are similar. Now in many cases in projects, these are things that people have never done before or they’re trying to accomplish something that’s fairly large, but the experience of the organization there may not be opportunity to go out and say, “Well, let’s look at a preworking example of that.” So again, in terms to helping the team zero in is to say, “Listen, we’re going to focus on getting to something that has value. We’re going to focus on the highest priority, that value,” and certainly want to make sure the teams are not distracted.
And this is important because when you talk about the teams that are working, they can get distracted, they get distracted with stealth projects, they get distracted with the customer coming in and asking questions. In some cases, the interaction actually is preventing the team from being hyper focused and delivering. And in today’s day and age, while the economy goes up, and as we certainly have seen it in the past, come crashing down, sometimes doing more with less is really important. So having a lean mindset that says, “I am laser focused, I’m going to get to that value,” is there. I like to refer to the old semper fidelis, if you’ve seen some of the different organization out there with the semper fidelis, stands for always faithful, that’s I think the US Marine Corps. But I was working with the truckers unit, it was always on the road and so there’s all these semper and when I was at CB we called it Semper Gumby, which is always flexible. In agile, you have to be flexible. Rigidity does not help. You do need some bounding boxes and sometimes you define those in rules, but the overall idea is that you want to make sure that you are really solution minded.
And again, in terms of some of the agile methodologies we’re going to look at today, there is a continuous process and product improvement and that means that we’re not just doing it once, but we’re learning for each iteration, each sprint we’re looking at the epics, we’re looking at how we’re testing, how we’re writing code, what are we producing is all ultimately designed to be reusable and to ensure that it’s efficient and addresses issues quickly and much more and in many cases what we call framework. You’re building the foundation of framework to repeat and do this over and over again. And so you’ll find some very lightweight agile methodologies and then you’ll find some very large, monolithic, very much more structured, detailed, documented and obviously it takes a little bit more time to implement in a culture, but all of them will focus on results and the idea is to zero in on key granularity. And again, that lean, adaptive, real time solutions is something that’s going to be important. So as we look at the benefits, some of the dangers also trigger right back in here. And let’s just talk about that for a moment. One of the things that people wrestle with is that you’ll have an organization that you have multiple teams that are reinventing the wheel.
Now, this is where good program and portfolio or strategic planning really helps to make sure this disappears or the ability to connect through, sometimes we call them project control centers or project authorities that says, “Hey look, I want to kind of at least keep my pulse on the teams that are getting work done.” Or we basically will connect the functional or resource managers so that as people are drawing from their teams they are saying, “Hey, we’re doing something similar over there. Maybe we should get other and talk about it.” But in agile, in many cases, people will zip down there, it’s quick, it’s efficient, and they’re suddenly building something without checking back into the larger ecosystem. And in many cases that means that we may have been very lean and efficient, but we just built it four different times with four different colors and that’s it and each department has kind of their own flavor of what they built. And then in the agile process when you embed the customers, people start to really get excited and begin to modify that, but they lose sight of the big prize. If you are a large organization, let’s say a large manufacturing organization and you have let’s say 60% of your revenue is generated during the holiday season, what happens if you don’t make market? Right?
So the idea is that some cases is that this is where executives get very frustrated, is that while everyone’s having a good time and they’re iterating and they’re coming up with great stuff and it seems to work, sometimes they miss the key milestones. Goes back into that waterfall deliverable that says, “You can’t slip these dates.” So again, loss of project program and portfolio visibility and many organizations they’ll run out, they’ll do agile and spreadsheets and agile with Post-it Notes, agile with JIRA and all these different tools. And so, not to say that none of the tools are bad, but the fact is that they’re not in a connected environment. And so you lose sight of what’s going on my project? Or a project manager authority says, “Hey, I can’t see what’s actually happening. I’ve got to run around and chase people to find out what’s going on.”
And so a danger here is to say, “Yeah, let’s go do agile,” but to get off the reservation in terms of here’s our area of control and here’s our area of structure or metrics where we have some sort of reporting mechanism and everybody’s out kind of doing whatever they need to do. And with the lack of documentation in many cases, sometimes even lack of process, it’s hard to pin that down. So the idea is that you’re going to lose metrics if you aren’t tracking it or putting it into a commonplace or using a common tool. And so again, these are things that crop up all the time and people love agile, but yet the organization looks at it and goes, “We’re doing it multiple times. I can’t get visibility. I can’t do strategic planning.
I can’t validate that we’re getting the value from what we’re trying to do.” But people really like working there hence the need that founders or basically executive bodies get frustrated with agile. Again, depending on how you’re tracking the information is that the level of detail of what’s being worked doesn’t lend itself to a good forecast model. Now this is where we talk about velocity, we talk about story points and this is important that while you might be doing agile, if you leave off certain elements or if you’re not using a scheduling technology like Microsoft Project or something that says how many hours are going into investment, what was our baseline of estimates are? Am I getting the velocity? Are we getting the burn down or burn up? Are we accomplishing the milestone points that we’re trying to get to? Or are we burning down the work? Without some of that, that means that, well, great, but I can’t learn, I can’t see if I’m doing the good job or the investment is there.
So pay attention to these. I think that’ll be really a key thing that as you start looking at the different types of blended agile approaches or single agile approaches or even waterfall, whatever you put together is you’re going to find that those are key elements that you want to try to avoid. Now, this is pretty new. If you haven’t heard of disciplined agile, I recommend go out and do a Google. There’s some great books on it, fairly new in terms of an emerging consortium that kind of oversees the certification of this. But the idea is that agile itself inherently is just that, right? It’s very movable, very pliable. However it’s not necessarily something that is structured. And so there’s a fine line between putting a discipline on top of something that’s meant to be very unique and very creative and very reflexive. And so the idea of disciplined agile is actually really powerful. And I encourage you to take a peek out there because there are different components that can be shared with different methodologies.
Remember I talked about, hey, why are we doing a waterfall planning high level but then when we get into execution, what we can do is create a series of iterations. And so now we’re doing agile, but we’re doing it within a timeline which says, all right, these are the phases of the life cycle that we’re going to try to get to. So the idea is that you can borrow components. You can also look at what’s called a buildable foundation. And again, this is where we get into discipline agile that says this isn’t just about a couple of quick projects or this team does it this way and that team does it that way. It’s really to look at the architecture of how you would implement technology or systems. A lot of times agile focuses on the software, which is the application side, not necessarily architecture side. DevOps, the blending of operations and development, which is another hot topic that’s out there. So this thing called disciplined agile is pretty fun to kind of look at and I like balancing things.
Sometimes the culture in an organization isn’t ready for a full on formal project management and sometimes they aren’t also able to embrace full-on agile, but there’s pieces that go together. And so putting some constructs and structures around it and then putting together your own mixture, kind of like in the kitchen, build what works for your culture and your people is not wrong. And so I think that’s kind of a fun part of this. So if you haven’t seen that, take a look at it. You’ll hear a phrase out there called DAD, D-A-D, disciplined agile, and from a discipline perspective, [inaudible 00:34:41] development is a great thing to kind of play around with in the mindset if you’re going to take advantage of that.
Now if I connect this back to project, project online, project PPM, some of the other tools there, you’re going to see that the engineering teams are actually implementing agile processes and it’s helping them build, for example, planner, right? They’re looking at teams. How do I make these things work together to accelerate the end user experience to still have the metrics, but at the same time be able to give people that really easy to work with in an agile approach, whether it’s Kanban or lean or I’m looking at test driven development, how do I make sure people have something that will support a myriad of different to agile methodologies. All right, let’s talk about the frameworks and I think this will be good. We’re going to go over some of the different types here and what I want to do is just kind of take a moment and kind of pause as you go through, it says look, as we look at the different agile disciplines, there is not just a single element because if you think if it’s a hierarchy, and I’ll talk about the umbrella and I’ll give some analogies around that, but the idea is that agile as a discipline, there are multiple frameworks, multiple disciplines. In fact, we talk about the values and the principles that are behind that.
And then there are different methods that kind of in many cases are how you would execute doing agile. But you can also layer these in a hierarchy as well. So when we think about disciplines, let’s just kind of kind of pause there for a moment and really think through the overall idea of I’ve got different disciplines, scrum, agile, Kanban, feature driven development. As we get into some of these, crystal, there’s plenty and there’s actually more than I even have time to go through today. I just kind of cherry picked ones that are pretty common that you’ll come across. Is that it is an umbrella, agile is an umbrella. And if we think about the agile pyramid, the idea that we have this value of really creating connectedness, getting to value quickly, emphasizing working software over documentation and contracts, then there’s ways to get that done. And so think of it as an umbrella or a series of a hierarchy. And I had somebody come up to me one time and they were asking a little bit about how do you kind of organize all this? And I said, “Well, if you’ve ever watched on television or you’ve seen maybe on cable where they talk about mixed martial arts and they talk about these different disciplines, you’ll hear moutai, you’ll hear taekwondo, you’ll hear jujitsu, Brazilian jujitsu, there’s all kinds of these flavors.
And think of it the same way is that if we say martial arts and we say martial arts as in okay, what is that? If I say agile, that’s very broad. Within there, there’s things that are good for ground game, like wrestling is a powerful thing. It’s great workout too. You can get into elements that are more kicking or hey, this is something that focuses a little bit more on joints or pressure points. And so there are different approaches to these and you know what, not one size fits all. And so if you’ve ever seen a boxer get in the ring, and again, here’s a combat discipline, again, well does that fit under martial arts? Well, okay, we’re talking about some sort of a combat thing, but if I get into looking at how the elements go together, if all you do is stick with one thing, then someone who does something completely different who says, “Hey, listen I’m a wrestler, if I can grapple with you, I can get in quickly and efficiently and you’re not going to be able to box me very well.”
And so this is why having the ability for you as a project manager or program manager or a portfolio manager or anywhere in that spectrum is to say, “I can be adaptive myself and I can actually understand how maybe the culture might better fit with a different approach, say rational unified process.” Or maybe we want to get into the rapid application development or JRAD, or as we get into adaptable system development, which is now really what it’s referred to. So these are other elements, but it’s an umbrella of disciplines that you want to think through and then look for what makes the most sense. So let’s talk about the most common discipline that’s out there and if we think about this, I’ll kind of relate a little bit back to Microsoft project, which is if we talk about scrum, if you haven’t heard it I don’t know where you’ve been hiding, get out from underneath that rock. But scrum has been around and it’s probably the most common thing that we hear.
I have a lot of people that come up and says, “Hey, I’ve got my scrum master certification, this is great. How was that weekend?” Right? Because not necessarily hard to get a deep understanding of scrum, but then you really need to get immersed in doing it, but it’s very common, you’ll see it in different places. And you’ll also see components of scrum used in other disciplines. So it is like say, hey, scrum invented this, in many cases, here is an approach. So it’s pretty common, it’s broad based, you can use it in lots of different areas and the idea is that there’s some sort of a conversation that says we’re going to begin to sit down and plan, create what we call a backlog, we’ll go through what we call planning meetings to figure out what we’re trying to do. Sometimes we refer to as sprint zero or we have a sprint between a sprint, which is to say, okay, we’re doing a sprint retrospective, kind of a lessons learned between this time box, period, which is usually between two to four weeks’ worth of time, sometimes it’s longer depending on the size of a project.
But then you’ve got this [inaudible 00:39:55] cycle of stand-ups and conversations that happen and the whole idea is to create a series of increments that will go through. And again, you rinse and repeat and you go through the cycle based approach. Again, high value, definitely zero down on high value. Now at the bottom it says here is only for chickens and pigs and I had somebody laughing about that. But if you’ve ever heard the story of hey, chickens and pigs, a lot of people go, “What in the world are they talking about?”
Well, down here as a cartoon you can find this out anywhere on the internet, but the idea is that there is two buddies. One was a chicken, one was a pig and they’re just chatting one day hanging out and the chicken says to the pig, says,” [inaudible 00:40:32] I think I should open a restaurant.” And pig says, “Huh, that’s a good idea. What would you call it?” And then the chicken thinks for moments and says, “Well, how about bacon and eggs or ham and eggs?” And the pig kind of goes, “Huh, well, no thanks. I would be committed, fully committed versus you’d only be involved.” And it’s important to understand that if we define the roles within scrum is that in many cases there is a construct here that says there are chickens, there are pigs. And inherently the team itself that’s doing the work are the pigs. And if you’ve ever been to a stand-up meeting or we get into these scrum meetings is that they’ll have stakeholders there but they can’t talk, they’re the chickens, right? They’re just involved, they want to hear what’s going on, but it’s really about the team kind of making sure that they’re eliminating distractions.
And so this is very common, you’ll see this out there, there’s a lot more moving parts. In fact, I think I’ve got an article out there on MPUG where I put a whole bunch of terminology. So if you haven’t found that, take a quick peek at it, but if you find it, let me know, I have this great table of all the terminology that comes around with a lot of the disciplines just a great little word table and certainly as you start learning the pieces, but scrum, the most common, you’ll hear this all the time and some of you may have already been involved with that. Before scrum, we get into what we refer to as lean process improvement or the term Kanban.
I’ll talk about lean a little bit separately because this is really born out of manufacturing, born out of Toyota, getting back to the 1970s, but as we think in terms of Kanban, the idea is that you’re grouping activities very visually, and back in the I [inaudible 00:42:10] kind of date myself, but back in the 90s when I was doing some strategic planning work, I remember we’d go in the room and say, “We’re going to the wall,” and we’d grab these Post-it Notes and we would brainstorm, we’d plan, we’d think about all the activities and we had everybody involved, which was a lot of fun. The only thing that you have to remember is if you use Post-it Notes on a wall, make sure you get the extra sticky Post-it Notes because they will fall off and then the wall is really more like the floor. So, but the idea is that you’ve got these categories of what you’re trying to get done and you’re zeroing your team on what needs to be done right now and working up the assignments. But it’s visual and literally people will grab Post-it Notes and be moving them around, they’ll have different colors, but you can visualize your work. You can also restrict the overflow.
And in many cases, this is where your technical or your work teams get overwhelmed with the sheer volume of things you’re planning it out but you’re helping people kind of focus on what is the priority and limit that work. And so as we think in terms of really looking at the value based approach of this, it’s good for an organization to even play around with this. And if you have never done it before, it is lot of fun.
If you’re doing marketing where you do vision, mission and goals, it’s very easy to sit down and say, “All right, we’re going to start with a few of these and we’re going to kind of work our way through making sure we understand what we’re putting in place.” So as we think in terms of kind of what I refer to more of some of the lean elements whether it’s Kanban software development, but as we get into even some of the structure there, the idea is that we want to visualize that we’re going to limit the amount of work. We want to focus on the flow and Microsoft project has this built into it today. I was just talking with somebody last, was it… no, earlier this week and they said, “Hey, why can’t I find the sprint board? I was like, “Let’s stop talking about it, let’s just bring it up here.” So I don’t spend a lot of time here because our next couple of sessions we’re going to dig deep in here and they’re saying, “Hey, I want to go in and I want to see where my Kanban boards are,” or, “How can we find our sprint boards?” So let’s actually go in, let’s pop into a task board here and you can kind of see the buckets.
Imagine these are cards as we call them, but they’re Post-it Notes, right? People can move these around or I could go into a sprint planning board of how I organize my work and my work activity. So in thinking through really what we will do with Kanban this is a great low tech, easy approach to kind of bring and it’ll give you some of that flexibility that allows you to manage that. So in terms of thinking through this, again, you can look at how you structure that. And you’ll also find that within Kanban it’s nested in many cases in a lot of other disciplines. People like the approach, hey listen, we’ll start there. Now what I usually tell people as you go back through, let me see, let me back up one more before I get to the lean here, is that every one of these little Post-it Notes, typically when I start thinking in terms of tracking and managing metrics, changing a culture, changing an organization, it isn’t the short game of, hey, I need to execute a project better.
It’s really how do I make sure I’m doing things in a way that’s sustainable, they’re adoptable, where the culture gets it and at the same time I got metrics, I got metrics I can go up to my executives. So imagine what you’re seeing here, even though we’re doing Post-it Notes, is that these were all in a database, right? They all go into relational database. We touch that data once, we move it around like a Post-it Note where versus I have to go on hand scribe it on a Post-it Note and then walk over and rekey it into an Excel spreadsheet or move that over somewhere else. The idea is that we are thinking in an agile approach is that this is where Microsoft is going is they want to make sure that we touch that data once. So, Kanban really kind of getting in there and lining this out. Let’s talk about lean for a moment. Very powerful model again, back in the 1940s as we start thinking in terms of Toyota optimization of how do they process model, grocery stores, how do you stock shelves?
You’re looking at the supply and demand side. The just in time. Lean was really designed to say, “Let’s eliminate all the… basically the bulk of the pork, anything that isn’t going to necessarily produce value, we want to look at it and then we want at the same time help the team learn how to amplify that learning,” right? Learn as you go. We’re going to hyper focus on kind of the key important elements but I want to empower that team. I want to begin to build that integrity and seeing the entire picture as a whole. And if you haven’t heard this story, it’s kind of funny when you hear about some of the stories that came out of this, but Toyota kind of took the market by storm, in fact Ford Motor Company and US auto manufacturers were just amazed at how quickly some of these upstart brands had started and where they’ve got, hey, the Model T has been around but yet Toyota was beating them hands-down.
And so when they went over to take a look at what was going on in this lean manufacturing approach, we’re looking at how things were being done in terms of the process. They found that in Japan what they would do is if there was a defect or if there’s a problem or something going on, is that the empowerment of the team as they went through here was they were able to stop the manufacturing process, fix it right there on the fly or address it, surface the engineers, get the problem resolved, and then continue to resume. And so basically the US auto manufacturers brought that concept back. And so the idea of this red button where they can go over the wall and say, “Oh, here’s a serious flaw or a defect, we can actually look at the problem, address it.”
Well, what happened differently culturally was well, in Japan, and people had embraced that model, understood it began to really work and think leanly of how to make sure we can solve problems, get it going, and get product out the door in adjusted time model. The auto manufacturers in America, when somebody would go and push the red button, everybody would get up to kind of find out what’s going on and they go yell at the person who would push the red button. So the whole idea was culturally you have to think about the approach that you’re working with. So in lean, instead of adding more documentation and detailed planning, again, the idea is similar in terms of writing code is that the stakeholder requirements are streamlined. You’re presenting models or mockups and then you’re really looking at how do we deliver as fast as possible.
And also what’s important here is deciding as late as possible to what you’re going to do. Meaning we have all the input, there is a cutoff period, but I want to capture all the requirements and sometimes there are [inaudible 00:48:26] so before a team jumps in and starts doing something, the idea is that we have these iterative processes that will happen. And again, it’s important to be able to see the entire whole of what’s going on. So in terms of seeking to eliminate that waste and working through that the idea is that you’ll still see terms like daily stand-up meetings, [inaudible 00:48:44] flow diagrams, virtual Kanban systems because you have multiple-Kanban systems perhaps where people are thinking through and making that work. You can also get into what we call visual controls, batch sizes and it’s also important to have the retrospectives.
Now I like putting fun facts in here because it’s fun to read books, it’s fun to go out and hear what other people are doing. And I think YouTube is a wonderful channel for this. So if you haven’t done this yet, do a search out there for two second lean. As an executive, one of the things that we’ll do here periodically is we’ll come in and what we’ll do is we’ll incentivize people to say, “Hey, listen, if I’m working with an organization, what I want our culture to do is to start thinking leanly.” Now instead of implementing a massive organizational change or a process, two second lean says, “How can I improve my life by two seconds?” By removing waste or doing something more efficiently and if I save myself two seconds every day, every hour, every week, I’ve got something that actually pays dividends long-term.
And if I do it for me, I can do it for others and so the idea is take a peek out, there’re some great videos on two second lean. I think it’s a very simple approaches. Again, the idea is that look empower your teams to come together, shoot a little phone video, share it, literally talking about a 15, 20 second, maybe 30 second video at the most. So it’s, here’s my problem, that’s what I wrestled with, this is what I did, here’s how much it saved me, ta-da. And I love if people can incentivize people saying, “Hey look, we’ll give you a little bit of Starbucks gift card or we’ll give you something fun or we’ll do something around it.” But if you want to change your culture on mindset you don’t have to implement an entire lean discipline or a framework to make that happen, you could begin starting even within your technical or project teams is to say, “How can we make this more efficient? Hey, these meetings we spend a lot of times shuffling paper scheduling, so what can we do differently?” But again, that continuous process improvement really is the idea is that we’re not only going to reap the benefits immediately but also downstream and long-term.
Again, continuing through with some of the options that we have in terms of disciplines here, another one that comes up if maybe not for those of you who haven’t been doing a lot of software development, but the whole idea of something called extreme programming. And when I mean extreme program, it’s not sitting on the edge of a building writing code, it’s not doing anything as fun as bungee jumping while you’re thinking through your next design model. It’s really the idea of coming in and saying, “We’re going to zero in on making sure that the actual software development, and this is again geared around software development, is that the teams are self organized around problems or issues.” A big difference between say XP, we call it extreme programming, but XP is that iterations are shorter typically than a sprint. So think about that for a moment. If a sprint is two to four weeks, depending on what’s going on, the idea of a sprint is at the end of a sprint, we’re producing value. An XP iteration is really much more shorter.
That’s a much smaller window of time. And again, looking at the flexibility is that while typically we don’t make changes in a sprint in say scrum or other initiatives we’ve kind of adopted that and says, this is all you’re working on, you’re going to focus on this, if we need you to do something different, we got to go back to the backlog here. The teams can actually get in and make some of the self adjustments based upon what they’re finding. And again, looking at zeroing in on high quality software quickly and continuously. So this [inaudible 00:52:13] XP is it about getting one project done. It’s really about building a focus team where everyone on the team is equal. We’re not talking chickens and pigs here. We’re really seeing everyone who’s involved, stakeholders there are absolutely at the same level. So even if you’re the tester or you’re the documenter or you’re the trainer that’s got to come in and do this, you carry the same weight. And again, you’re zeroing in on what is the problem, what are we trying to solve? We’re kind of organizing this together. And if we think in terms of kind of that extreme programming is that this will provide the ability for an effective environment and again, it’s going to give that benefit of a highly productive team.
And so as XP has kind of delivered around that software you’ll also see things embedded inside of this, which could be like test driven development, pairwise programming. We’ll talk about refactoring but these are other elements that just say, “I promote high customer involvement, but again, short, short, short feedback loops.” Didn’t have to build the whole model, didn’t have to frame the whole thing up. I’m just going to show you how the little widgets spins. That’s all I’m going to show you. I got that little widget, like when loading software and it’s spinning, I’m just going to show you how that spins. You like the way? Oh, you’re from Australia, you want it to go the other direction. I got it. So the whole idea is you can play around with these different values or features that you’re trying to work with.
And again, it’s constructed basically in making sure that there’s simplicity, there’s communication feedback. And one of the terms that comes in here, courage. I’m going to talk about courage for just a moment because when you empower a team, in many cases in organizations if you’ve never read the book called The Advantage by Patrick Lensioni, one of the most powerful things you can do in an organizational culture is to really be able to speak truth to power. Meaning that somebody who may be lower level is going to call out a problem. Speak that truth, “Hey, listen, the emperor doesn’t have new clothes,” and not be in fear of retribution. So that courage of everyone on the team having the same power is to come together and say, “Look we are all focused on the same mission.”
This isn’t about [inaudible 00:54:16] territories or I’m the scrum master. It’s really about enabling people to solve problems and do so communicatively in a way that is safe and also free from retribution. And again, I know I’ve kind of waxed it a little more philosophically, but if you think about building a project management culture, which is a coin I phrased in 1999 I think this is one of the most powerful things you can do, is to build a project culture, a culture that really does understand and has each other’s backs and will speak truth. If someone’s screwing up, I don’t have to go get HR, I don’t have to get the product owner, people can self correct. And that’s the idea is that hey, if somebody’s struggling, you kind of come in and shore up and that is important. So with extreme programming, again, zeroing in there, I think you’ll find that there are a lot of elements that will help people really make sure this works.
Now these have been very small and some cases, tactical. Let me step back at something much larger and again, from an agile discipline, this is very common out there, you’ll hear things like Rational Rose, we talk about open process or object oriented software development. But the idea of RUP or rational unified process is again, it’s around object oriented and it’s about building a significant framework of repeating successful delivery. So as I look at my environment, I’m looking at project management, what’s the input I’m looking at kind of making these elements come together. Most people are involved in putting this together into four key phases, right? The idea is that you go through an inception four project, you’ve got some sort of elaboration.
Then there’s the construction and then what’s important here, a lot of organizations, they’ll build software, throw it over the fence, right? What we want to do is make sure that there’s a transition and as we think in terms of a transition is that there is a transition to other teams and so as we begin looking at how those are organized and what we’re putting together at that inception stage is that the business case is stated and it’s important. Waterfall, we state an initiation phase. What is the charter? What are we trying to create? Is it even possible? So sometimes there’s a conversation that says before we actually build something, what we’re looking at is what is the scope, and then make sure that there’s a simultaneous decision that perhaps in order for our resources to be successful, what are we going to need to make that happen?
Then you go through kind of that foundation architecture evaluating what we’re going to need to support it, care and feed for it. A lot of people are only looking at delivering, well how much is it going to cost to deliver? But this takes in consideration the entire ecosystem. And then again, the idea is that it’s ready to be tested and rolled out into a transition and boosted to other organizations. So in RUP, this becomes important for us to be able to look at blending things like extreme programming in here. Again, as we get into a methodology, again, this was produced by an organization called Rationale, again, these are elements that you can say, “Look, I like the pieces here, but I want to put a framework around an organization,” or, “This organization is going to be doing this all the time, I’m not just doing one project, I’m not just kind of learning how to do this, how do I put it in place?”
The nice thing about this is when we back this into the Microsoft ecosystem and Office 365 is everything that’s here and everything that they’re developing and have developed will support these in terms of how you organize it and access these. Again, a lot of this again some organizations actually have their own website you can actually connect and log into. So again, a much higher and a larger discipline in creating a process and a framework for going forward and using this. Nested underneath this, you’ll get into things that we call test driven development. I’ll talk about feature driven development. You may not have heard test driven development, but the idea, again, embedded in many other agile disciplines are the methods and they’ll take a page out of the test driven development playbook is that you’re never going to write or release any production code without having some sort of failure. You want to try and test and fail, fail early, fail often, but fail fast and get it quickly.
The idea is that you’re refactoring that code basically taking a look at it continuously that says, when we write once, okay, this is good, but we’re going to reuse this, we’re going to go through and review it again, and how do we make this better? So it’s a great learning experience. And again testing is completely woven in here. So some organizations says, “Hey, we’re going to do things in a scrum fashion. We’re going to have a mixture a little bit of the extreme programming with our developers and we’re going to implement some of those test driven development with our testing team or our QA team that’s coming in.” You’re going to find that people will mix and match and pull things together. But ultimately sitting on top of perhaps a project schedule or a waterfall strategic plan with high level milestones is helpful. And again, very common to see some of these married together.
So I talked about test driven development and then feature driven development, FDD. So again, I like this, it’s about focusing on delivering features, right? The idea of delivering a feature, which is something of value. And again, the iterations are always around the solution of what you’re trying to get to. So from a planning perspective, this is created by Jeff DeLuca basically who’s got a lot of major contributions and influences with other people like Stephen Palmer and Paul, I think it’s Shaygo, I can’t remember how to say his last name, but the idea is that there’s a lot of searching analysis that goes in that says, “Hey, well we’re doing feature driven development. The overall idea is that we’re going to start with a shape.” What are we trying to get to? It’s kind of the solution itself, right? So I’m thinking through what is the objective and then I’m going to kind of unpack this. What are the key features? So in the waterfall world, we go in and we do what we call work breakdown structure, right? We can create a WBS.
So similar thought processes, but again, the design or the structure will be around the features that we need. And remember the idea of delivering a feature is typically something of value, but features themselves have potential impacts with accounting, with infrastructure, with data storage, there’s a lot of elements. And so there are eight key practices that follow under this particular feature driven development. And again, the idea is that domain objective modeling developing feature by feature looking at some sort of a component or a class ownership, right?
There’s kind of an organization and ownership. You definitely want to focus on how the teams are being broken up and structure. And then highly important is inspections. People are actually doing inspections. Again, this is where that test driven development kind of gets embedded in here is to say, “We’re wanting to make sure that this is going to work.” And then we get into that configuration management getting into what we call regular releases or regular builds. Again, the cycle of this is typically shorter than a scrum cycle. So again not everybody’s building features, right? If you’re in healthcare and you’re doing some sort of a change management rollout which is involving a lot of training, you’re not doing development or you’re doing construction or perhaps you’re doing manufacturing. So what you’re going to find is that there are pieces that you can find that work well or work better for other types of organization. Again, the idea is that you’re going to create a methodology that is very short, specific with FDD, feature driven development, and then it’s geared around zeroing in information, data solution and features for the customer itself. So I’ve gone through several of these. And again, I want to make sure I wrap up with one last one here, something called Crystal.
Actually I’ll do another one because there’s the father of agile disciplines, something called DSDM, but an agile discipline called crystal, you’re going to see here it is able to pull in many different types of disciplines including coding practices, approaches, and of course reporting. So Crystal is typically a family, right? The idea of software development methodologies. And this is something based on over a decade of research that a gentleman named Alistair Cockburn went out and figured out that said, “Hey, let me analyze what are the successful elements in doing software development.” And so one of the research pieces that came up is that really that the properties of product changed based upon the number of people. So I’ve got a little grid here. If you look on this the PowerPoints is the size of the team, right? So if we’re talking about whether we’re doing extreme programming and then I’ve got training teams and I have larger and larger organizations, there are different types of approaches of how you do things. And so you notice there’s a color, clear, crystal clear, crystal yellow, all the way up to crystal blue dealing with the size of the team.
And what’s important here is on the basically looking at your vertical and your horizontal axis because your vertical axis, the potential damage, which is, as I’m going through here, there could be potential issues that can be caused, right? The idea that your system of potential damage is that the lowest damage impact or a loss of comfort is based upon things that you’re going to be wrestling with or change that may happen in an organization. And so the key tenants around Crystal is teamwork, communication, simplicity, as well as the ability to do reflections. If you’ve ever been in healthcare, some of healthcare organizations are faith-based. They talk about sitting back and doing reflections. And I like the idea of saying, “Hey, let’s take a step back as a group or an organization and make sure that we’re doing it frequently and focus on how to involve or improve the process itself.” And so again, it promotes early frequent delivery of the working software itself. Certainly high user involvement and it’s adaptable meaning that it can pull in and pull out other elements.
So the last methodology, I thought this was the last one but here we go, I got another one, one more. This one actually kind of has been around for several decades and when we think in terms of what I refer to as the DSDM or as we get into kind of structuring the title and the elements that we work with in a methodology is that some of the disciplines that we see today, like scrum really were born out of the dynamic systems or development method, right? DSDM, dynamics, systems development methodology or method. And the idea is that it’s origins go way back into the 1990s. And it originated because the tech community recognized that there was a significant change. And there was a standard in project delivery, basically a framework that was missing. And so we talk about things that maybe you’ve heard in the past called RAD or JRAD, things like we call rapid application development or joint rapid application development and there was a lot of popularity around with that. But again, there was very little structure with these. And so we get into something called adaptive systems, which is now what RAD is [inaudible 01:04:57] adaptive system development but [inaudible 01:04:59] there’s no construct, right? People are just rushing out and they want to get to just in time model.
And so the idea is that they’re need to have a framework around how to make this work. Now there’s some core elements here that a lot of times I like to borrow or make sure that even if we’re working in an agile or waterfall component is that we really do leverage some of this. And again, active user involvement, empowering your teams, don’t forget to integrate testing, right? That’s so important. And then the high level of stakeholder collaboration, meaning that we want to bring in the stakeholders at the right time, but again, we’re focusing on what the business needs are first, not necessarily the customer because in some cases an organization, I might be trying to build something for a customer, but I can’t reuse it, it’s completely disposable. And so it’s really look at it and doing a baseline early as early as possible. And then basically looking at reworking things that you’re doing. And so when we talk about rework is that we’re basically saving and storing the work that’s being done to be used by others.
And so part of that factoring or refactoring is all in the process. And again, prioritization, you’ll hear a lot of similar terms here about what are we going to prioritize, whether I’m looking at the backlog, I’m looking at story points, I’m looking at customer need and something you may not have heard is called MoSCoW rules, right? It’s basically must have requirements first, should have, if at all possible, couldn’t have but not critical and won’t have time, but potentially later. And if you’ve ever been involved in requirements gathering, this is really important, is to establish up front with your customer, with the business what you can or can’t do. So success certainly in a project methodology is going to be helpful as you start using even the Microsoft tools, which we’re going to get into on our sessions two and session three. So we’re going to run some of these scenarios through there and talk about how you’ll make this work or how a technical piece will work, but the idea is that sometimes you are planting the seeds now, which is prioritization, and if you can’t have everything, what can you have? Basically what we won’t have. And that way we’re managing some of the disappointment that’s out there.
Okay, well, if I haven’t filled your brains with lots of methodologies, trust me, agile is big. There’s a lot of stuff out there. And what you’re going to do is look at how does it work for me? Or if I get pulled into this, how can I use some of these features and capabilities to make that work? So let’s talk just briefly in a summary here. I’m going to kind of recap a little bit of this, which is agile disciplines for best results. And I think it’s important as to go and say, “You know what, Lots of stuff that Tim said, how do I weigh these together?” I’m even contemplating maybe building some sort of a nice diagram matrix where I can just say, “Yep, if you’re here, this is what you’re going to need, or here’s a concoction, almost like a mixture, [inaudible 01:07:37] something maybe on a traceability matrix.” So a lot of fun playing around with these things, but the concepts themselves will continue to emerge even as we talked about DAD or discipline agile, which is now we’re putting a little bit more of a framework on it, but looking at how to make that work.
So in terms of best of breed, right? In terms of what you need for more Cowbell, I just wrapped up with DSDM is that a big model, right? This is a bigger model that says it’s easy to use, it’s easily created, you can pull other disciplines in, but it’s really appropriate for a large scale development project and especially when you’re starting to look at, hey, we’ve got a lot of development coming from different areas. I want to begin to create a foundation or a structure. So here’s a big, right? DSDM is large scrum, much more adaptable. I mean you can use this across non software development, you can use this in construction manufacturing. There’s other areas here, but again, it’s time box. You do have specific roles that’s important. There are roles and that’s kind of what you adhere to. It’s designed to eliminate distractions from the team and that’s very helpful.
So if you’re in an environment where technical resources are constantly distracted, you can kind of put this in as part of that. Again, roles and they also have priorities, things that they do or they don’t do. And then again, there’s less flexibility in a sprint in terms of what we can do. So the idea is that a sprint is a time box to help ensure that value is produced at the end of that particular sprint. But typically changes are not really happening there on the fly whereas we’ll see some of the other disciplines they are. I love Kanban just for the simple fact that I can go grab Post-it Notes and go to a wall. That’s all I need is Post-it Notes on a wall, make sure they’re extra sticky Post-it Notes. Oh yeah, and a Sharpie, right? Make sure you can write on a Sharpie that is good. So the idea is visual. It’s fun. If you’ve got people who are sitting at a desk all the time, they talk about sitting being the new smoking, right? Let’s look at how to be healthy. Let’s get up in a room, let’s get our blood moving, let’s get interactive.
And it’s interesting to watch this kind of unfold, especially if you’re doing requirements gathering or priority based planning. But the idea is that you structure it, you look at the immediate work and again we match the work to capacity, what do we have available? Kind of hard to understand capacity with Post-it Notes, but a lot of times team members will understand, hey, I got 30 Post-it Notes and I’m writing my estimates on here, I just am not going to be able to get this done. A similar thing happens, we use story points scrum planning or other areas is we’re looking at how do we weight this? And this is why I like getting into a place where we can actually go in and use say Microsoft project as the database to give you that visualization or use planner and Office 365. Planner however doesn’t have numbers, right? It’s not looking at level of effort or percent complete. So the idea of keeping that Kanban ask is going to be helpful.
Lean process improvement, great. Always looking for continuous process improvement, eliminate waste. In many cases this is a culture change. Seeing, empowering the team to be able to fix and resolve on the fly things that are going on. And again, looking at lean manufacturing or lean estimating, which is to look at what is the minimum amount, something we didn’t talk about, but if you’re in an area where people pad their estimates, a lot of times getting into lean estimating just says, “Look, tell me what your big hairy estimate is, but tell me the minimum amount of time.” Because typically work expands to fit a schedule. Just like if you put gas in a box, that gas will expand to fill the void or the vacuum or whatever is there, it fills that box.
So if human beings expand their estimates to fit a schedule, then what we wrestle with is the fact that everybody pads their estimates and if it says two weeks it’ll take two weeks. But by lean estimating, people can kind of be shooting for a leader number, but we know we have the buffer. And so looking at this in terms of how we’re doing just in time doing only what’s necessary, deciding as late as possible on that requirement and then delivering as quickly as possible in short iterations really helps an organization or a project team come together and in certainly as an organization I talk about that two second lean. Think about that. It’s just something that says when you’re going to change your culture, you want to empower the team to be thinking, not necessarily just following a methodology.
We talked about extreme programming. So again now we’re definitely talking about in a software development world, but again, the idea is that teams are going to self organize. This embraces a little bit more of the chaos saying, “Look, if I have the right team, they’re onboard, they’re really motivated to get something done, I don’t necessarily have to structure or spend a lot of time structuring it. I want them to begin to prioritize and then self organize around the issues.” Again, focus on useful software development and again involve the stakeholders. Much shorter cycles, right? Small releases, small mini releases around producing value. It’s nice to say that if I put five pieces together, that’s what I do on a normal sprint, but hey, listen, if I’m doing a shorter sprint or a shorter cycle, I can break those five pieces apart and show you the value as they kind of unfold. And again, the idea is that this can be embedded in lots of places.
So not only is the customer working closely, but you can use this in other larger frameworks like RUP, we get into DSDM giving into Crystal the idea of these bigger, larger oriented that says, “We want to change the culture, we’re going to build an organization that does this on an ongoing basis, but we want to make sure that agile is there, is that we look to improve software development as a practice.” So RUP or rational unified process, getting into object oriented design for large software development. So if that one doesn’t fit you, it doesn’t mean that pieces in here won’t. And finally we talked about a little bit of the feature driven design and Crystal, meaning that we’ve got some of the elements that are really just making sure that says, “Hey, that’s dependable I can actually focus on the size of the communication that’s going on, or am I focusing specifically on our features in terms of our best of breed.” Now the last thing again I’m going to come back to is that agile, right? Agile DAD, right? Inherently, the idea of disciplined agile is don’t just stick to one thing. If it’s not working, if it doesn’t feel right, it’s not right.
The idea is that there should be results and that you can begin to kind of structure these and pull them together to make that work. So all of this is a great conversation, but if you look at the large firms that do technical projects or do global infrastructure projects like Amazon, they are even embracing agile. Looking at how does this work across the board to eliminate bureaucracy and red tape. Again, kind of that blend of lean that says we have to still be nimble, not just our teams that are doing the work, but how we run as an organization. So if we think in terms of that agile planning, Microsoft really kind of has put something out there called the innovation hub. I think there’s a couple partners out there that are building some tools around SharePoint sites and how you would do an intake process. And this is actually good stuff because the idea is that if you’re thinking through as an organization or even as a team is you need to be able to have that brainstorming and collect the ideas and challenge them, work through there.
Here’s something that you may not have thought about, but a lot of times in teams if you really are empowering them, sometimes conflict is inevitable and conflict isn’t necessarily bad. The idea is that you want to make sure people come together and have that voice. Sometimes an idea is kind of silly, but then sometimes it spurs other ideas. And so that brainstorming, that idea collection and the idea development, in many cases if you have a meeting instead of the outcome of the meeting as a decision, maybe the intent of the meeting is for your team to come together and just debate, openly debate, get hot, get heated, get in there, wrestle through all the scenarios. Somebody ultimately says, “Great, I think we’ve got all the card surface, we’re going to take a day, we’re going to think about it, and then our next meeting we’ll come back and make a decision.”
Again, this is where the product owner or the scrum master or people who can actually come in and say, well, maybe the project manager can come in and say, “Well, I will ultimately will make the decision,” but we don’t want to make decision in the heat of a moment, and remember the idea of agile is to involve teams and people and human systems and customers. But sometimes people need time to digest, they process. Some people are kind of by the seat of their pants, their the trainers. I know that I surround myself with a team that thinks differently than I do because I value the input that comes in from that.
And while it’s certainly sometimes maybe bothers me initially at first, I have to take a step back and go conflict in a conversation is actually healthy. And so if we’re looking in terms of where Microsoft is going, this infusion of conflict or conversation or having that open or courage, to speak as we heard about in some of our other disciplines in agile is really part of that process. And so supporting the system with tools in agile is about really [inaudible 01:16:26], “Okay, I got the data, we had the conversation, how can we put that together?” So you’re going to see things like task management, work management, software development, project program and portfolio management and of course reporting and visualization.
And in Microsoft these elements are really part of the new foundation of where Microsoft is going and other vendors who are building software products out there are also looking at this where project program and portfolio management are very monolith, they’re very big, there’s a lot of interactivities, there’s milestones, there’s hundreds of rows and predecessors and successors. When I really want to spin up and manage a team or manage some work activities I do it with Post-it Notes. Or maybe I need a mobile device to make sure that I’m staying on top of what I’m working on. So these concepts of putting together, you’re going to see emerging and in our sessions two and session three, I’ll walk you through some of those. But we talk about the agile products periodic table, it’s not just one single tool anymore, it’s really saying these tools are designed to support both the methodology and the way that the information work or the project teams are actually executing. In fact, if we think about some of that structure, it’s going to be helpful for us to really put ourselves in a place where we can look at these.
To narrow this down, you’re going to see things like Planner, Microsoft To-Do, Teams, Azure DevOps and certainly good old Microsoft Project now has scrums, it has Kanban’s, it has waterfall projects you can mix and match, you can play around with some of the views. Something I want to plant a seed for, which is it’s still an a newer product, it’s part of Microsoft product it’s called Roadmap. But there is absolute intent here to continue to grow this product. And so the idea of having high level planning, quick iterations, looking at what’s going on, refactoring that and then maybe dumping that down into a more detailed project schedule or versus right now you can drive it out of the detailed schedule and push it up is something that you’re going to see a lot more.
And so I’m excited, again, I’ll be careful about what I can actually say here, but Roadmap, part of the Microsoft Project licenses says, “Hey you’re a team member, you can see the Roadmap. You’re a project manager, you’ve got Microsoft Project, you can build and publish this into Office 365 and invite people to view your Roadmap.” So there’s some elements here that says the communication pieces go together, are helpful. And whether they’re born directly out of using the Microsoft project, task boards, looking at your sprint planning boards, or even some of the automation that you’re going to find in project which is when I drag and drop one of these cards or tasks, this is a database. There’s 126 columns behind here. By the way, I can just start marking percent complete as I drag and drop it with my mobile device or with my mouse. Very easy to make that happen. So again, the customization and certain elements, Microsoft is looking how to put those in place.
Before we jump into QA, I want to bring up two quick things here. So let me just show you live. We’ll be talking about these more. But, whoops, that’s the wrong window. This is the right window. So if we talk about project kind of having a new interface, like saying, “Hey, look,” as a PM I can quickly see this, I can see my instant project files. I’m in a browser, I’m not opening up the client itself. Doesn’t mean I can’t get there, I can’t work there, but I can actually see more or less I can share with these. I can build a roadmap. I can literally launch these and manage these directly. Again, using kind of the logic environment certainly we can go and drop these into one big portfolio where all of our products are in one place and I can see my red, yellow, green, I can sort, I can filter, I can group, we’ve got the metrics are helpful. But then maybe I don’t want all the details of the project too heavy too much to pay for the license.
Let’s drop that right into planner. Let’s go in and let’s just scroll the quick hub and we’ll go ahead and actually drop in and create a board and we’ll move these around, whether I do it in Microsoft project and I synchronize project to here. These are things that you’re going to see, some of the visualization and a lot of capabilities that I’ve been talking about for years are starting to appear, which is show me what’s done, show me the history, let me clone and copy that. And then whether I’m working in here, I want all my data to drop into my to do list, right? I just want to see what’s in my running to the store list? Bananas, milk, I need to actually go out and say, “Hey, what’s planned? Are there any particular activities that I’m looking for today, Friday? Doesn’t look like I have anything that I’m planning on doing except answering some questions? Which may or may not be.” But again, if I’m working in CRM or dynamics, I can import this. And so Microsoft to do becomes the end state of where your work is going to go.
Things that you can add. You can drag and drop, you can pull things in from different places. But the idea is that we get into that task management, work management, project program and portfolio management, again, still database related. And then finally, let’s throw some power BI or some simple reporting in Excel or a quick web part in SharePoint, or let’s just connect to our data. Some of it’s in projects, some of it’s in Microsoft To-Do, some of it’s in planner. Let’s actually make sure we have good visuals. The intent of Microsoft is to continue to bring these together, reduce the barriers of learning and make that work and not make a Swiss army knife for everything. In fact, Gartner just came out with a report about why it’s important not to make your ERP, your accounting system, your project management system. Don’t make everything into one particular tool. Go to best of breed, find what works. And the same applies to certainly agile. Find what works for you. So Kyle, maybe if we’ve got a couple of questions, I can take a little bit of time here. Again, I always encourage people to jump back if they have any other questions, they can come in here. I love hearing funny questions, I love hearing funny answers, sometimes I learn just as much from you guys, so I encourage that. So Kyle, have we got any questions maybe I can zero in on?
Kyle: We did get a couple of questions that have come in, Myles was curious about scaled agile framework.
Tim Runcie: Yup. Scaled agile framework. So in terms of… so remember we talk about the ability to grow small or grow large there are so many, I didn’t have time to cover all of them, but from a scaled agile perspective this is something, let’s see, where am I seeing more of scaled agile? I’m seeing this actually happening in organizations that I would say about mid tier and what they’re doing is, it’s not just project teams coming together to quickly execute some results is that they’re not necessarily looking at an overarching framework, but it fits in a mid tier. Today I kind of showed you large tier and small tier, but I think scaled agile is a great approach. Again, we talk about that blended discipline of kind of pulling some of those pieces together while you’re working. So I’m quite sure if there was actually a question that Myles had around that, but that’s what I’m seeing in terms of it and good, I have nothing negative to say about that at all.
Kyle: Great. Thanks Tim. Darryl was just curious I think it was on the agile discipline extreme programming slide that you had. He was just kind of curious what the project heartbeat was in reference to in the diagram there.
Tim Runcie: Oh, let’s take a look here. [inaudible 01:23:32] find PowerPoint slide number. It’s funny because I use that full screen share and it covers everything up here. All right, let me just… let me rewind this back. Zoom, zoom, zoom, right. Cowbell, nop, it wasn’t Cowbell. Let’s see, he’s talking about ta-da, ta-da, ta-da, ta-da.
Kyle: This one here.
Tim Runcie: Yep. So part of the project heartbeat in terms of the defining description here is the intent to ensure, are we actually on track? So there’s some actual metrics that go in behind that. And so in terms of an internal thing is are we on track? Are we actually delivering where we need to go? But it’s really making sure that that is still connected. And those are some of the metrics. So connecting with the teams in terms of that team empowerment as you go through, which is, is the product still viable? Right? Is it still alive and are we delivering what we need to do or are there other issues? So, and this is something that happens internally because sometimes the politics will change or perhaps the feature approach that we’re building isn’t there.
And remember in XP, we can actually change during a sprint saying, “You know what, I was trying to work on this,” I’ll use a real world example. Doing some stuff in basically power apps, so remember, Microsoft were releasing all these great tools and don’t get me wrong Microsoft Flow is very, very simple. PowerApps is supposed to be kind of part of the power trio. There are lots of gaps in these products while they’re still there. And so we’re butting our heads on how do we solve this? And so sometimes we’re thinking we’ll be able to do something a certain way, it doesn’t work. And so looking at the project heartbeat or the feature release heartbeat is that it’s not viable. We need to actually switch, change and modify that and we need to do something within the actual sprint. So, excellent question.
Kyle: Thanks Tim. We have one more here from John, and this may be touched on in the next session or two I’m guessing, but he’s just kind of curious what the recommended roadmap for an individual to transition from the on premise to this world here, the PPM world.
Tim Runcie: That’s a great question. So and I don’t know, I’m sorry, who asked the question?
Kyle: That came in from John.
Tim Runcie: From John. Let me look at John, I got him on camera here and I’m totally kidding, of course. John, that is a great question. So one of the questions I would ask is what version are you on? Are you on 2010, 2007, 2013. If you’re not in an Office 365, project pro for Office 365, basically if you ran out down the street, went to Myers or Best Buy or something and bought it you’re kind of stuck with what you’ve got. If you went to a garage sale, you bought it, if you get Project Pro for Office 365, it will always be current. And some of the features that we’re going to be showing in our session two and session three are exclusively designed for that. And part of this is Microsoft has been asking, “How do we keep people from having to do a local install?” Now, what I will make sure I show is some of these capabilities while we may not get some of the cool cards is that we still can do agile project management and some of the same pieces with older versions of projects. So your question is how to migrate.
Basically if you’re on a license [inaudible 01:26:42] in a large organization and perhaps they haven’t rolled an upgrade, talk to your Office 365 administrator. Usually it’s just simply they push a button, the update, if you’re already on Office 365, it just synchronizes and updates. The other is the release cycles. So you can get on an annual release, you can get on the every six month release. You can get on the monthly release and you can get on… there’s actually channels where you can be on the weekly release and you’re… like, Microsoft is on daily release, they’re testing it all the time. We at Advisicon actually rolled it back to weekly because sometimes we’re like, “Hey, listen, I don’t need,” or not weekly we move out to monthly because sometimes we want to test these on certain machines before it rolls out and sometimes stuff breaks, it doesn’t work. But that might be another element that says, if you’re not seeing all the features, get that updated in Office 365. But two quick ways to do it.
And I really do strongly encourage you, a lot of people run out and deploy on premise. I like on premise for lots of reasons, but at some point you start missing some of the other agile tools that go with it like teams, you could do some of that, but then I won’t be able to put my product into an environment where I can connect it to planner. So other elements we’ll dig in deeper in the next couple of sessions, but a great question. So I would say look at aiming at being with a current tenant, the Office 365 even if it’s an individual license, you’ll be good.
Kyle: Thanks Tim, I think we’re [crosstalk 01:27:59] pretty close to the end here and covers the questions. So I’ll hand it back to you to close out for today.
Tim Runcie: Okay. So if you thought I talked fast before, I’m actually going to talk slow in terms of some of the summary. So remember agile is iterative, right? It’s engaging, right? We’re looking at high touch. There are different methodologies that you really look at trying to structure and provide value. You can mix and match an agile in a waterfall world. And remember all of this as a database. When we start talking about data, I don’t care, it’s a row and a column in a database. I don’t care what the interface looks like because I want my data to be there, I want to mine it, but I also want my end users not to struggle with it. So if you’re using Post-it Notes, that’s fine, but at some point when you begin to kind of mature that process, you’ll have documentation, you’ll have templates you want to look to how to manage that.
And the different agile methodologies are designed to help you structure either to mid tier as we talked about scaled agile framework or are we get into larger tier, are we getting into rational or RUP, but find what works, right? Find what works for you. And I encourage people to look at the different methodologies. Sometimes there’s price tags, sometimes there’s… it’s a Post-it Notes, a pen and a wall, might be good enough to get started with. But these tools will continue to emerge that we’re going to hear and see more about. And again from a technology solution, if you’re going to support an agile methodology that doesn’t have to be technical either, but the idea is you want to centralize your information. So find the right tool for the job. Again, from a perspective is that there are many disciplines and it’s okay to borrow pieces. Don’t dogmatically stick to one thing just because it’s there. Find what works.
If you were doing a true agile iteration, you would do an agile plan to figure out which agile implementation methodology you might want to use and you might run some prototyping with your team to see what they like and don’t like. So again, think through some of those and again whether it’s project or training or SharePoint or other elements, if you have any questions anytime, I encourage you to reach out, I will have lots of information on MPUG, this is an amazing channel but feel free to reach out directly if you have questions that come up in between then. I want to keep you posted and attended so that you’re not missing out. And as we know, the message will continue to evolve as just like technology does. And even some of the, for example, discipline, the agile, the DAD, these are new things that come out, I kind of watch them for a while, watch how they work, look at them a little bit more deeply, but you’ll find what works for you will really be what will work for you and don’t forget it’s about your culture as well.
So Kyle, I really appreciate that opportunity that we get in here. For those of you that [inaudible 01:30:35] clicking the next session coming, the session two, which will be September 18th, or if you’re on the recorded version, just click next. And the idea is that we’re going to be unfolding the new features. I want you to take a look a little bit more in the technology. So we’re going to kind of work our way from agile across project program and portfolio management as well as look deeply at how these agile features work in some of these tools, not just project only. The project team actually has built multiple elements and they’re designed to work together. So you’ll be able to learn how to work with that and understand how to play these together. And some of these you may not even be aware of, you have access to those if you’re already in the cloud, you just needed to have it turned on and away you go. So that’s what’s coming up for our next session. And Kyle, I will turn it back to you. Thank you.
Kyle: Thank you so much Tim. We appreciate the excellent session on part one today. That was great. Everyone claimed the PDU code, I’ll get that info back on the screen for you now so you have that, it’s mpugwebnlearn091119. And I’d like to mention part two and three of this agile series are on the calendar now and those will be on the next two consecutive Wednesdays at 12:00 PM Eastern. And if you sign up for today’s session will automatically register for you into part two and three, so no worries on missing out there. But I did also chat over a link so that you can take a look at those sessions in the descriptions to get an idea of what to expect and what you’ll learn from attending those sessions. So that’s in the chat box, that link and that does it for our part one here. Thanks again Tim. Thank you to everyone that joined us live or is watching this session recorded. We hope you have a great rest of your day and we’ll see you back next Wednesday for part two. Thanks a lot.
Tim Runcie: Thanks everyone.