Introduction to Agile - Transformation, Best Practices and Common Problems

a conversation on agile with Martin DuPont project manager at IBM's spark Technology Center today we're going to talk about agile I've been active for over 15 years and the world of project management's living in many places I'm from Belgium originally I lived in Great Britain for many years also stay for some time in Australia got married and lived in the Midwest's for a couple of years and then recently moved here I started getting more and more involved with the the world of agile it started with rapid application development and a few years back I was also I worked for yellow freight one of the largest trucking companies in the USA where I was employed as a PMO leader and we were introducing agile and I was helping to facilitate a transition from waterfall over to scrum and to some of the other agile techniques such as Six Sigma I was also previously involved at other places such as H&R Block where I was an agile coach and I was involved with implementation the re-implementation of scrum and various techniques to improve it because let's face it agile is a continuous work of improvement the question is usually that people say like well is the glass half full or is it half empty and the most obvious conclusion is it's half empty people from a corporate perspective would say like no there's opportunities there the glass is half-full we can do something with it but now agile introduces a new way of looking at things and I think this is essentially what it all summarizes let's relook at the situation that we currently have and find new opportunities that before we haven't explored yet and the conclusion in this case is the glasses were fillable and if you think about it this introduces a very novel concept especially on how we can approach things and take it from here before I continue I think it would be good for me to point out when I was making this presentation I was thinking like well you know on the one hand people need a theory right but at the same time they need they also need to practice and you need some practical recommendations so this presentation tries to offer both so we're going to start first with the theoretical perspective just go over a couple of you know simple concepts because if if we miss that foundation then then we're going to run into problems so and then later on in the second half of the presentation we're going to focus a lot more on the practical implementation but also especially on some of the biggest difficulties that we experienced and how to address these because after all if we know in advance what problem problems are coming we can better prepare ourselves and really make a difference now the difference between the traditional methods and the agile method is it's just a different angle and but it makes a big difference with the traditional methods ultimately the business says this is a scope we want you to do it and you figure out what is the time and what is the cost that is going to gonna be done and usually these can get crunched and it is very hard but the thing is you the way agile does they they reverse the logic and they say well this is a time that we have in the resources here on here as our budget our costs we can deliver this amount of items and our scope will be limited and it's a great advantage here the advantage is that there's no disappointment on anyone's part the customers know what what I will be getting the business knows what they will be getting and in the end once expectations have been set everybody will be a lot more relaxed and a lot more able to focus rather than be exposed to making promises that they can't keep here's just a quick summary of what agile is about so agile is a team-based alternative it's all about the team in this case to some of the traditional project management techniques that were so accustomed to using and I'm sure we've seen it alright big long planning for an entire year scheduling out way in advance we prefer to start executing earlier reason is because we plan less in advance we deliver frequently whereby we show the business hey here are the our deliverables and repeatedly evaluate our objectives by these iterations and repeatedly confirmed satisfaction this particular video is just going to show you what the agile manifesto is about and these four principles will help us on on our way to further explain the concept it was 2001 and a group of software visionaries gathered at a ski resort to share their experiences and figure out why so many software projects were failing this wasn't just about documenting best practices they knew the industry required a fundamental shift in values and so the agile manifesto was born the Declaration of for bold value statements that became the basis of a new approach to software development and would change the industry forever but what were those four values and why should you care take a look but first it is important to point out that the agile manifesto ends by noting that all of the things mentioned are important just that some things must be prioritized over others okay here we go number one individuals and interactions over processes and tools this doesn't mean throw processes and tools out the window simply means that a good face-to-face chat should trump rigid workflows and impersonal forms of communication number two working software over comprehensive documentation makes sense right but traditional software development often produced extensive documentation before a program was released for initial testing some documentation is good but wouldn't it be better to have the program than a book describing it number three customer collaboration over contract negotiation sure you'll want to start out with some initial guidelines but instead of locking customers in a cage by defining the exact details of the project before it starts teams and customers should collaborate find the best solutions and finally number four responding to change over following a plan nothing ever goes entirely according to plan so instead of sticking with something that isn't working it's much more effective to make adjustments as your situation changes following the values isn't always easy but when you build them into your team's processes customers notice and the payoff is huge which of the agile values do you think is the most important realizing that's what was originally sets can in the course of time change and requirements continually get reviewed another thing also is customer interaction it's important that we keep the customer scent central to all this process but in a traditional way of project management that hasn't always been accomplished especially because the customer in advance says this is a scope that I want to see realized and often only after the project has been accomplished a year later we interact with the customer and find out that the customers needs have changed or that there has been a total disconnect and a misunderstanding so first of all in its customer focused I just spoke about that the flexibility here is central we want to be agile and a true meaning of the words okay because this is a rapidly changing world and it's more important than ever before now it's focus on improvement I think this is a central concept with agile methodology it's continually trying to rethink ourselves on how we can improve and make things more efficient and better now full disclosure I mentioned it earlier on from the very start we tell executive management and we tell our customers listen this is how much you will accomplish give or take just you know a small margin of error but at least they will know very clearly in advance what the expectation is and then team culture previously you could have huge projects as the projects would get so big that there was never a real team culture now the thing is slowly they start realizing that it's all about a team and culture really feeds improvement and quicker delivery then risks and issues if we will revisit the process on a very frequent basis like agile does it will enable us also to identify risks very quickly I'm sure you've all had it before whereby things continue for months and an end and then suddenly someone raises the question often the executive manager why has it not been done and then there's a whole chain of commands for someone to figure out well there was a blocker awesome there was some type of roadblock and we've never really addressed it frequent checkpoints if we will stop our entire process every two or three weeks to reflect how it went it's it will provide us very important feedback easier reporting as well those frequent checkpoints make reporting a lot more accurate and there's a lot more tangible for executive management and customers to understand what is going on and finally a road map it's very frequently road maps need to be made and I've seen it often that well we need to develop a road map we don't really know what lies ahead but we need to put something on paper well let's do it well agile has certain methodologies that will particularly help with outlining everything that is needed and especially according to especially according to the importance and the urgency of the requirement and let's start first to talk a little bit about the process okay we want to focus a little theory and we will start with what scrum is hi this is me my name is hameed cha-cha and I've been involved with a number of software development projects over the years at a number of different companies and I've come to recognize scrum as one of the best agile development practices in use today in this fast-paced video I want to show you why scrum is so great and how you can get started with scrum in under 10 minutes I'll cover all the core scrum concepts like product backlogs team roles sprints burn down charts and more so get ready to be bombarded with information let's say this is the product we want to build for this product we get all kinds of feature requests from customers executives or even other team members in scrum features are written from the perspective of the end user therefore features are known as user stories the collection of all these user stories is called the product backlog another way to think of the product backlog is to think of it as a wish list of all the things that would make this product great once we have our wish list or the product backlog we need to start planning which specific user stories we're going to be putting into a particular release of our product but we're getting ahead of ourselves let's back up a bit to build this product we need to have one or more people on our team we're going to play a variety of roles first we need her she plays the role of product owner and helps make sure the right features make it into the product backlog by presenting the users and customers of the product she helps set the direction of the product then we need this guy he's the swamp master and his job is to make sure the project is progressing smoothly and that every member of the team has the tools they need to get their job done he sets up meetings monitors the work being done and facilitates release planning he's a lot like a project manager but that's such a boring title so we'll call him a scrum master high who knows some jiu-jitsu and the rest of the team has similar roles to other development processes these guys build the product while these guys test it to make sure it works right these guys use it and hopefully pay for it and these guys they generally get in the way but it turns out you can't build many products without them but let's get back to this release planning to plan and release the team starts with this the product backlog and they identify the user stories they want to put into this release these user stories then become part of the release backlog the team then prioritize the user stories and estimates the amount of work involved for each item sometimes larger user stories are broken down into smaller more manageable chunks the collection of all the estimates provides a rough idea of the total amount of work involved complete the entire release a quick side note about estimates there are a lot of techniques for creating good estimates some prefer estimating and story points where estimates are made relative to building a small component with a known level of difficulty unfortunately story points don't answer the question of when will my project ship I found that the best technique is to estimate work in hours but to use some standards and how estimates are done for example things to take less than a day to complete will be estimated as one hour two hours four hours for eight hours every item will fall into one of those buckets there will be no three hour estimates for example a three hour item would fall into the four our bucket larger items will be estimated as two days three days five days or ten days again all estimates in between will fall into the next larger bucket extremely large items are similarly estimated in months one two three or six months but the reality is that such items will need to be broken down substantially before work actually begins we'll come back to these estimates in just a minute but for now let's get back to this the release backlog with a prioritized set of user stories and the estimated amount of work at hand we're now ready to plan out several Sprint's to get the work done spreads are short duration milestones that allow teams to tackle a manageable chunk of the project and get it to a ship ready state sprints generally range from a couple of days to as much as 30 days in length depending on their products release cycles the shorter the release cycles the shorter each sprint should be and you want to have at least two to as many as a dozen sprints in a given release so at this point we can take our release backlog and split it up into several of these sprint backlogs one of the most important things to remember about sprints is that the goal of each sprint is to get a subset of the release backlog to a ship ready state so at the end of each sprint you should have a fully tested product with all the features of the sprint 100% complete since Sprint's are very short but a realistic representation of part of the product a late finish of the sprint is a great indicator that the project is not on schedule and something needs to be done therefore it's extremely important to monitor the progress of each sprint with this a burn down chart the burn down chart is the number one reason for scrums popularity and one of the best project visibility tools to ensure a project is progressing smoothly the burn down chart provides a day-by-day measure of the amount of work that remains in a given sprint for release in this graph you can see that the amount of work remaining bounces up and down from day to day but is generally trending towards zero because historical information is provided in the burn down chart it's easy to see if the team is on the right track using the burn down chart the team can quickly calculate this the slope of the graph which is also called the burn down velocity this is the average rate of productivity for each day for example a team's rate of productivity might be that on a typical day they finish approximately 50 hours of work knowing that it's possible to calculate an estimated completion date for the Sprint or even for the entire release based on the amount of work remaining what's great about the burn down chart is that we can compare our actual velocity and projected completion date to what the team needs to do in order to finish on time this is perhaps the most useful piece of knowledge that any team member product owner or product executive can have about the project because knowing whether or not the project is on track early in the schedule can help teams make the proper adjustments necessary to get the project on track the burn down chart provides empirical proof that the project is on track or if it's going to be late so let's talk a little about where the data for this incredibly useful burn down chart comes from as you recall part of the release planning process was to create an estimate for each user story in the release backlog the collection of these estimates for a given sprint represents the total amount of work that must be done to complete that spring as each team member goes through and makes progress on one or more of the user stories they simply update the amount of time remaining for each of their own items so the total amount of time remaining on the group of user stories that make up a sprint changes on a day-by-day basis hopefully going downward until it hits zero when the Sprint is complete the burn down chart aggregates the remaining work data and shows it visually it's brilliant because it communicates a massive amount of information in just a few seconds and that brings us to this the daily scrum the daily scrum is an essential tool to having flow freely between team members the idea is to have fast paced stand-up meetings where team members quickly list the work they have completed since the last meeting and any obstacles in their way by meeting daily it ensures the team is always in sync and any major issues are dealt with as soon as they are known finally as each sprint comes to a finish it's important to have a sprint retrospective meeting where the team can reflect on what went right and areas of improvement after all scrum is a flexible agile development method that needs constant improving and tweaking for every team so there you have it scrum in under 10 minutes you don't know all the essential concepts to start implementing scrum inside of your organization but wait a second what about tools to help you implement scrum well it just so happens that I've spent the last 10 years building such a tool with a lot of help from these guys a group of genius coders and design engines the tool is called on time and it helps you manage your products your backlogs your team your releases and your sprints it gives you project visibility with burndown charts and always answers the question of who is working on what you can get started with it for free at access Ofcom of course you could use a giant whiteboard some note cards and a bunch of different spreadsheets to track everything you could also use an abacus instead of a calculator to do math but we're getting a little off-topic so let's quickly review everything in scrum you work with this a product backlog which is nothing more than a list of features that we call user stories you then break down the product backlog into one or more release backlogs and for a given release you further break up the release backlog into a number of sprint backlogs which are essentially short duration milestones throughout your project you then monitor the progress of each sprint using these or noun charts and have daily scrum meetings to ensure everything is on track after each sprint you have a retrospective meeting to fine-tune everything and if you want a tool to implement scrum you can use on time that will help you ship software on time that's all there is to it oh and one last thing whether you loved or hated this video I'd love to hear from you you can reach me on twitter or via email if you have any feedback now get going create a great team collaborate and ship software on time as I explained in the video there are different roles we have the users and the stakeholders in a certain way they are the outside group because they don't belong to the essential scrum team okay but they are very important for us the users order the customers whoever it is will really help will determine of what we will be doing however it is very difficult for us to interact with each one of those and it would delay things considerably that's why we have a specialized person whose name is the product owner the product owner is the link between the outside world or upper management and their needs versus a team he translates everything and he prioritizes and shows the importance and the importance of certain elements and how quickly they need to be accomplished there's also the scrum master the scrum master is the team leader he is not a project manager in a strict sense of the word but he fulfills a very similar role he feeds the team the necessary information he helps a coordination and he helps too to put together the reports so everybody stays on track but he also has a team to focus for example with it just an example here it with the daily stand-ups sometimes people take forever to finish the meeting and they keep talking about all kinds of things well there the scrum master has a responsibility to keep everybody disciplined and stick to the 15 minutes because it should not take any longer than that and finally there's a team members of course the team members make the essential part of the team so just a recap the agile team consists of the team members the scrum master and the product owner very often the product owner has no presence at every single meeting although that it would be the ideal thing but the scrum master and the team members interact very very closely just a quick slide on the product owner so he maximizes the value of the product or a service that we need to deliver and he also manages what we call the product o'clock we will be looking at this in a couple of slides this is really what all the customer needs are about and finally he represents the desire of stakeholders then we also have the scrum master very important here is the word servant leader okay servant leader means many things on the one hand he needs to be a servant to the team he needs to support him in any way he can but at the same time he needs to be a leader in the sense that he should be courageous he should be able to stand up for example with the daily scrum meeting if for example someone talks too much outside of the topic or people start having a large discussion which is not relevant he should be able to stand up but he should also encourage people to to continue with with the roughly builtin to examine themselves okay the process cycle this is a large overview here a rough draft of the scrum sprint so first of all as we said here's the vision the general vision that we get from the customers together with with executive management on the basis of this we are going to make product backlog as you see different items are split up so there's a rough idea of which specific requirements we have that we need to fulfill the product owner and the scrum master will will select a portion of this and we will make a sprint backlog the Sprint backlog is really the items that the team will be addressing in the next sprint a sprint can be two to three weeks sometimes four weeks but usually it's better to keep it small such as two weeks and here is the Sprint so here we see one to four weeks as I just mentioned but also 24 hours because the daily stand-up meetings evaluate on daily basis where we are at and finally you see here that we have a sprint review and retrospective after those two weeks we're going to evaluate what have we done have we accomplished what we need to do what risks and issues are still out there and what can we improve and this is a very important element that has actually not been implemented so far with traditional project management let's talk a little bit about the backlog first of all we have the product backlog secondly we have the sprint backlog and then we have grooming sessions to refine the product backlog and keep it up to date so of the entire cycle we will be talking about these two elements here so the product backlog is the higher level features there are the estimates and the priorities and so the product owner gets these from the customer the product backlog is mainly the tool of the product owner the scrum master will be there to assist him but essentially the product owner is the independent owner and it's the only part that he truly owns by himself then the Sprint backlog is actually the next step as we said before we take a small chunk the product backlog maybe the most important items that need to be addressed and we're going to get very specific on what we need to do we will split it up and use your stories and tasks so here you see the product backlog and over there you see the user stories and the use cases that we have with every single requirement the product backlog is the property of the product owner and not of the team it is very high-level scratching things on the surface but making clear what is needed now there's no task so don't go into detail it is highly changeable because in a month's time the client could have very different requests or he could realize that wait a minute even though in the past we said that this was our highest priority and things can have shifted product backlog needs to be reprioritized on a very frequent basis what is a grooming session a grooming session is coming back to the product backlog two weeks and the product owner together with a scrum master and possibly with a subject matter expert will revisit it will look at the new requirements or new desires of the customer and will reave evaluate things and perhaps come to new conclusions or new priorities but essentially it is very important that we keep us up to date because this will be the basis for us to decide what we will work on we have the sprint planning now user stories they're a tool and agile to kind of describe what is needed from a customer perspective okay and they explain what exactly is needed it's a much lower level kind of description than what we usually find back in a product backlog okay and there's a fixed template of fixed formats that we actually use to compose those as a and then whatever your user role is I want to do this or that okay so that and then you point out the value you can say to yourself like well why would I want to do this I mean why do my do all the different team members need to compose one of these user stories well there's different team there's different team members and they have different roles to play and sometimes one person can look at things from one perspective while someone else can do from a totally different perspective we need to all to be on the same page because what is the point of everybody finally making something or delivering something well there was a misunderstanding from the very beginning and because it is so specific it will help us to avoid these misunderstandings and I wanted to illustrate this with this little cartoon here how the customer explained it and what the customer really wanted I know that previously there's always business cases being written and so on but in this case it is just very important that all the team members have a full comprehension of what is needed now what our epics sometimes requirements are from from the customer or from the business are huge and sometimes there's different elements that are interconnected but at the end of the day they all form a bigger entity while those bigger entities we call epics and very often in the backlog what we will find is multiple of these big chunks okay now if we're dealing with big chunks if we're dealing with epics ideally we should be splitting them up in small user stories sometimes it tends to be hard but we really should do an effort to make it as tangible as possible before I continue here see I also want to point out that were to user stories the user stories end up being split up and separate tasks before the sprint kicks off and this is a very important element it is not just sufficient to explain to the team members this is what needs to be done we will need to identify which tasks there are so the team members can then according to their availability determine I can take care of this task and you can take care of that task and work it simultaneously friends what are sprints and let's talk a little bit about daily standard meetings and especially let's talk about blockers so previously we spoke about a product backlog in a sprint backlog the previous chapter we also spoke about the Sprint planning so now the next step is the actual Sprint Sprint's are these fixed length iterations I suggested two weeks but three weeks or four weeks or even one week would work but they will always remain the same it's a cadence and we don't want to fall outside of the canons so we can really do the business and the customer know exactly what you expect and so as you see here there's a sprint backlog okay and then all these different elements so the blue refers to a user story all these things will go into will be worked upon and so on very standard meetings what it comes down to is a following every day the team meets and every day the team tells each other what they worked on the previous day what they will be working on this day and thirdly they will point out what problems are they facing and it's not necessarily the problems it's more explaining why there could be delay so we are able to anticipate it well in advance but most importantly the scrum master can jump in and actually help out try to remove those blockers or roadblocks or whatever you want to call it so the daily stand-up meetings free little characters exactly answering those three questions this is what I have done since we last met the day before here are the obstacles that I've been encountering by the way to don't always have to be obstacles it is quite possible that someone has nothing and then he just is I have no blockers and finally this is what I plan to do today so here are a couple of examples of blockers for some reason on other people seem to have a real hard time at daily stand-ups to identify our blockers are there might be different reasons for this first of all they might not think it's that important or they can think like hey I'll I'll figure it out very soon and there's no need to notify the team and so on or maybe they're afraid that they will be blamed for for something going wrong but here's at least some examples so that you when you implement a daily the daily stand-up meetings at least understand that can encourage your team members here is really what we're looking for and please help us identify it for example I still have not got gotten the software that I ordered a month ago here for example in this case a scrum master can can come to the assistance of the person and he can make the necessary steps to speed things up the department VP has asked me to work on something else for a day or two we get these type of requests on a very frequent basis where it's a manager maybe even another team you quickly ask for our assistance but they are essentially will blockers because they will affect our workflow and and the scrum master he can then help determine whether we have the luxury to dedicate our time on this or not or he could for example negotiate and talk to the other team and see if there would not be a solution to go around it without using the team's capacity all-righty reviews let's talk a little bit about their sprint review meanings and retrospectives so you spoke before about the different types of backlog then those backlogs are being worked through sprint planning we have everything concise together we know what we're going to work on then we actually take a couple of weeks to specifically work on it and when when those weeks are over and the Sprint has come to an end the question remains how will we improve things where are we at with things first of all we have the Sprint review meetings even though teams having worked for a couple of weeks on their sprint really have something to show for frequently teams tend to forget about these and it's a very strange phenomenon because at the same time you would expect the scrum master or the team leader you know to be able to tell the team let's guys here are all the items that we've accomplished and there might be a couple of things still outstanding but it's a great encouragement for the team to see how far they haven't gotten the scrum review meetings they really unified a team as a whole it is not merely a question of reporting where we are at with with the things it is also nice to look back before I forget it the sprint review meeting is also meeting where we particularly want to involve the product owner and possibly even the client if the client gets involved with these sprint review meetings then the client will first of all firmly start understanding that there is a fixed process being followed that we have things under control that things have been delivered there's no point first away for two months and then to get back to the customer and the customer still need to realize whoa we are so far behind although so that know if we have a frequent meeting with the customer the customer will understand that there might have been certain risks or issues or complications and he will better understand and he might even help us to reprioritize things now retrospectives I have to say of all the different things the different elements that agile offers I feel that retrospectives have helped the team's the most people are sometimes frustrated or sometimes things just don't go well and they feel like screaming and they don't have an opportunity to do so over to retrospectives well I can assure you're nobody screens but with the retrospectives we we let everybody speak speak out and we can address what went well but we can also address what we think could be improved upon and we can kind of reevaluate and it has been extremely extremely helpful tool to agile and as a whole it small variety delivery now maybe here's the the part where it gets a little bit more complicated but it's nothing to be afraid of it is more the type of metrics that we use to measure our success and how far we have gone so just a quick recap very quickly went over the product backlog look at the sprint planning and then we work some things we reviewed at work and saw how far we have gotten and now we're going to look at the deliverables story points as a video very very well explained we need to somehow or another be able to estimate the work that we are doing the video recommended using ours they found that very successful other teams have used story points and so on but whatever it is we want to have some type of tangible number that way at least we can follow and understand where are the bigger chunks of work where are the smaller ones and this is exactly what we're talking about as you can see with these stones something that is very small the team can just you know address this very quickly and it will not be a problem and it is not something that has one point or you know or is it that is very small that will prove to be an obstacle however if the team starts working and they don't address the large stone the five point one all down the line that could prove to be problematic because you don't necessarily want to leave the biggest chunk at the very end and here's off of the burndown chart okay the video also data clue did a great job and explaining that but the burnout chart tries to measure how much work we've accomplished and so on and how much work remains the interesting thing here is for example is here I don't know if you can see the red dot but the graph goes slightly up over there and the reason is the following it is possible that at the last minute something comes up and some extra workload was given and it was a small readjustment of what we're doing so I thought of just explaining that because you know it is good first to completely understand what is involved okay let's recap the whole deal so we have the vision the vision that the customer tells the business there's a business case being made then the product backlog was split up the entire business case and smaller portions and that we reprioritize them then the Sprint backlog we take a small chunk of that of those requirements then we work on the Sprint for a couple of weeks and whereby we have daily meetings and review daily where we are at with things and then finally we deliver we deliver the product or we live it deliver the service or whatever it is and we also make sure that at the very end is as it were a little break we review things and see how how it all went and then we restart the entire process that was a theoretical part let's started talking a little bit more about better practice first of all when you talk about problems businesses have problems every company has difficulties and it's not necessarily that's our own fault but frequently we don't take the time to reevaluate where where the problem could be and what type of solution that we could find and agile because don't forget agile is more than just scrum agile has a variety of different methodologies and they and different tools have provided different solutions one of the big agile companies from the very start has been Toyota and the companies and Japan we're buddy try to be very creative with finding new solutions this is something I strongly recommend to all the business units or divisions is to do a root cause analysis of the situation or difficulties that they are facing now Toyota came up with a template it's called the a3 templates and it provides a root cause analysis to figure out where things going wrong what are the real causes that are causing this let's come up a solution for each of those problems and finally let's make a quick projection of when we're going to implement these changes and this is particularly important because if we want to introduce agile to to a company or to a division or Department we need to at least take a step back and and briefly reflect upon where we are with things where we are at with things so I don't want to spend too much time on this and I think it will be great thing for you for you guys to look up but let's just at least have a have a closer look at things and understand what really is involved with this how does how does root cause analysis works one of the big things that stands out here is the process processes can be very complicated but what you want to do here is you want to give a concise understanding of the workflow the process flow of the situation now I've also here some of these are explosion symbols okay and what they actually try to indicate they indicate where problems occur we're aware that problems don't occur there they don't occur there we know main promise take place here so now we can start focusing on a real analysis of the the situation what's triggering that those issues and so this diagram is called the Ishikawa of fishbone diagram in this case the problem or the problems that a company was having was split up over six different issues namely some of them were related to actual the scrum the others were actually related to the standard meetings that were not going as good as it could others were about validating data because there was a huge time lag then here about the requirements maybe there was ambiguity about what exactly needed to be delivered then the meetings meetings were for example taking too long or meetings were there were not enough meetings there could be different problems and finally planning and so in every single category then these get split up in subcategories whereby for example and this is very applicable here to this agile course for examples stand-ups so the problem here will is visualization and attention on the one hand stand-ups if there's no visualization being offered it is very hard for people to stay focused they have nothing to look at you can report as much as you want on progress if you don't see it the team will lose focus and the other thing is attention people don't always during these daily stand-up meetings giving the sir the attention that it all that they ought to give people might be sitting down or people might be behind their laptop typing an email while they're expected to to participate I wasn't sure whether I would show you this or not but personally I like it but I think it's more philosophy that we should incorporate in ourselves and some people have it naturally before other people that sometimes very good to just see it this is called the the PDCA the plan-do-check-act and essentially when we want to have continuous improvements more in the sense of here are our outstanding items here are some items that we should address in the future then then the do part of the act part is okay well let's take some of these items that we're going to work on then the next thing is once we've we've executed on them let's quickly check if they really get to the stage where they rented results and then finally the act part where everything is being rolled out and so on and then after a while you really examine everything and and the Act part becomes part of the plan again because it might be certain Corrections I need to be taking place we address a certain issue we try to find a solution we check other solution works and let's roll with it storyboards storyboards are four important story boards are the boards that we actually use to drive the team and to make them understand where we are with the progress this is an example of a typical scrum board the difficulty with scrum is that usually scrum is used for development groups and it is not necessarily always applicable now with the development part teams can very often work on certain tasks simultaneously someone can take a certain item say I will take care of this and another person will say like hey this is tell outstanding let me take care of that and it can deliver pretty much at the same time or at least there's a very little dependency however there's also a different methodology which is called Kanban and combine approaches things very differently what is it is very similar and it works with a similar board but at the same time it is a lot more geared towards sequential activities where by this great dependencies between different groups and one person needs to wait for the previous person to accomplish it I got a little video on Kanban let's briefly gonna explain what it is hi i'm angelo coppola with AK so sock you've probably seen our video scrum in under 10 minutes which is the world's most popular video about the scrum methodology many viewers have written us requesting that we talk about another software development system Kanban Kanban is a fantastic way to get things done and it also works great in conjunction with scrum if that's the way you want to do it a Kanban is a lean scheduling system developed in Japan by the Toyota Motor Corporation a Kanban system utilizes visual cues that tell you what to produce how much to produce and when to produce it a typical sushi menu like this is a great example of a Kanban customers indicate which items they would like to have right then and how many of each it's simple and efficient like these maybe this is why your favorite sushi restaurant always seems to get your order right when adapted to software development Kanban systems usually start with a board and visual cards that represent items in your product backlog on the board you place the cards into columns that represent their current step in the workflow ranging from new to complete the steps in between are entirely up to you so keep it simple and efficient the visual nature of the board makes it easy to find out what's already been done what's in progress and what's going to be started next so long as your team keeps finishing work those cards keep moving to the right like this and most importantly you keep delivering features to your customers to help ensure items are being completed at a steady pace Kanban imposes limits on the number of items that can live in any one workflow step at any given time these are called work-in-progress or whip limits they should be set so that the work flows as smoothly and consistently as possible if your team runs into a problem these limits will bring it to light very quickly by creating a visible bottleneck this allows the entire team to swarm on the problem and that's just another way of saying collaborate limiting the amount of work that's in progress means that you've got to finish some of the things on your plate before you can start on additional items whip limits help you keep work flowing save time by eliminating too much task switching and complete tasks Kanban is fantastic in its own right and on many projects may be all that you need but I found that when paired with a good scrum framework and a great scrum tool Kanban really shines scrum provides the structure for organizing feedback short term planning stack ranking and inspect and adapt mindset and other organizational improvements while Kanban provides a steady flow of tasks that reach 100% completion by helping your team manage day-to-day development with a minimum of overhead and blocking issues so there you have it Kanban for software development you can get started on Kanban and scrum with a free 30-day trial of on-time scrum it is a feature pack blazingly fast way to manage your software projects with on-time scrum you can visualize your product backlog as cards and rank their importance you can also organize items by developer imagine the peace of mind you'll get from this view of your project knowing who's working on what and when it will be done not only that but with customizable dashboards you can see burn down charts graphs and projected shift dates this kind of project visibility inspires confidence the overview that I gave there were different phases in a sense that it could be in progress then something needed to be tested and so on and it can take it can go step by step but a second very interesting element is these whips the work what is the work in progress limits whereby we determined that someone can only work on X amount of items at the same time and then that way people don't get overloaded because ultimately if you work on the hundred things at the same time and nothing will get accomplished and everybody will be frustrated but here is for example how a Kanban board would look like at its very start nice and simple okay very clean and so on once we start with it and so on the scrum board or the Kanban board whatever you want to call it will actually start becoming in life entity whereby it's a real work in progress for my own experience I found that these boards are a tremendous help okay and I realize that the difficulty for teams that are not co-locating and are dispersed that they don't always have the availability of having an actual physical board now of course our online tools that allow this but a physical board will allow it to be also a lot more creative and a lot more efficient and in the previous project some of the items that I've used so I've created my own symbols to help the team better to stay focused the colors of up there are the different colors of post-its that I was using and so I didn't according to team and these little symbols indicate that something is in progress and it might it might be an item that are going to take a long time let's say for example something that needs to be worked on for let's say five six days well it is important for us and in advance to identify this is going to be a long effort maybe them blockers now when someone mentions with a certain task I'm having a blocker for example the software that I ordered was not delivered I can't continue and so on now the thing is as soon as an item has a delay or possible delay of more than 24 hours we need to call it out and that's why right next to the task when we can add a little little symbol a little stop symbol we'll buy the team every single day we'll be reminded well wait a minute the process is being held up and we need to address this issue also potential risk we is a very often we can already see in advance something coming up that will become a blocker at some point and we want to flag that little stars I use because I want to make sure that all my team members are very driven towards meeting a certain date of delivery and so I would ask the team members okay you mentioned this when do you expect this task to be finished and there's no pressure on team member but just give me an understanding when do you think this will be finished and if he says like well in two days time all great I take a pen and I write on the little yellow star this date and then in two days time during that meeting then at the next daily standard meeting I can talk to the team member and say like but where were yet with that we're able to deliver that or not however let's say for example it comes out that the date that he originally said was not realistic we can just mark out the original date and put a new date on there but the great advantage that this technique has is that if this date ends up being postponed again and postponed again this little star will become full of scribble and we'll draw the intention that something seriously is wrong and needs to be addressed and the the great advance is also with with the due date is that sometimes as so many tasks involved that would just keep using that we lose track over it and the scrum master definitely needs to make sure that we follow up with every outstanding item I made a little green star because sometimes we're working on something and it's not always clear what exactly is needed the green star identifies that we need to talk to the product owner or to the customer and see what exactly is wanted and finally a little arrow of blue arrow because if there's a dependency between team members the other team member needs to know when something was finished people don't always send an email or if they do then sometimes you have a hard time catching up with the email and figuring figuring out that something has having completed is now waiting for me to finish it off okay well the blue arrow definitely solves that problem now you might think during the daily standard meetings the other team member will be there and you would know well that's very true but we're all human sometimes people come late or sometimes people are sick or they are and they are at a conference or whatever it is and so when they come back let's say the next day and they will look at the board they will see the blue arrow and they will they will be notified and it will realize hey wait a minute this item is not has been moved up and is now in my queue well let's go back to the original chart once again the picture is a little bit dark right here first of all we mentioned a number of Sprint's that were at so in this case this was a whole new project it's print one but also let's make sure that we have a little piece of paper where every day the number of days that are left are on because that way that the team especially stays focused on how many days they have left to finish the work this is particularly valuable if Sprint's with the ticket will be will be very long let's say we're dealing with a sprint of four weeks well it is very very easy to lose track and still need to realize three days beforehand that the Sprint is over but if we keep track over how many days are left we can start every daily scrum meeting by saying hey guys this is how many days we have left this is how many days we've already worked where are we at with things this was a case of very strong dependencies between between different team members okay every column has been split up in two columns or by the first part of the column is actually the work in progress and the second column is that the item has been completed in practice people tend to move over an item to someone else's to someone else's queue and it was not always a half percent clear whether it was completed because we want to definitely make the distinction between an item could be completed but it is not but it's not necessarily in progress while the other one means we're actively working on it and with the Kanban methodology we only want to work on X amount of things so it's very possible that there will be several items that have been completed and waiting for you to work on before they can actually be worked on because of the workloads right on the top of the picture there's a clock daily stand-up meetings have the terrible problem of getting longer than I need to and it's important that we stick to 15 minutes there's no excuse the daily the daily meetings should go you should go very smoothly and so putting a clock above the scrum board everybody is looking at the scrum board and if necessary the scrum master can jump in and say like hey come on guys let's let's keep moving forward here let's keep moving on okay all right in grooming sessions so what is a grooming session again a grooming session is one of those sessions where by the product owner looks at the outstanding items I need to deliver for the customer okay and he needs to reevaluate and reprioritize them this is a methodology that was proven to be one of the most successful in my experience and it's called Moscow its must should could and would or would not okay let's quickly explain what it is about it while it consists out of three different steps first of all we're going to write down all the different requirements okay everything that is needed for the business to classify those requirements namely the must the most important category we must deliver it okay this should is it we need to do it but it doesn't have the highest priority then the code is like these are great things these will really bring value to the customer it's a little bit down on the burner and finally there's the wood or router would not if there's anything that we do not need to do it will be in this category now we will try to accomplish it but if anything happens this is the least important for us to worry about and then finally once those we've placed all those requirements and the different categories then we finally are also going to categorize them in in order of importance because there could be twenty requirements that are absolutely essential I need to be done but within those twenty within those twenty we can still make a priority and say like this needs to be addressed next week while this one could be could wait for for three weeks I truly believe that this methodology will not only help the customer it will not only help executive management but it will especially help the team because you do not want the team to work on things that are not worked well for them to work on and then afterwards they found out if a customer is furious because you've been working on the wrong thing so in this case someone wishes to start an eBay service company this online tool will specialize in the sale of tickets and here are the requirements so we have this very simple business case here so how are we going to look at this let's write everything down a little post-its let's put one big pile and make sure we have ever think we have captured everything let's put all these things in different categories but let's just now presume that the customer was very specific or the product owner really understood where the priorities lie and in this case for example with the languages I put English as a must having a secondary language could be very desirable but could not be the highest priority and the other must are different account types namely an admin a buyer account the seller accounts the easiest solution for them to work from is to provide a fixed sales price right the auction element could be added afterwards later on but it's less important now for and then for example in the shoot category we find things like seller ratings seller ratings are very important but they're not 100% essential now they're extremely highly desirable but the thing is that if we need to determine our work order let's put that in the second column okay the would or would not category I put in their tracking postal tracking of of the item that has been shipped off it's a nice desirable thing to have but if you take everything into consideration this item is not the highest on our priority and let's say for example we were running out of time and we're unable to finish everything off that we should have while tracking is definitely at the bottom of the burner and then the third step is as I mentioned before now let's within that group within that category prioritize according from high to low and in this case nothing can get me started without creating the account types if there's no possibility for even the buyer to you know to make himself a profile we're not going to go anywhere there needs to be an admin and so on the product owner together with a scrum master and possibly with some subjects experts can sit together and go over this and have an internal discussion where they think something should fall the goal is that every two weeks this will be revisited and we can really look at and change the priorities working with post-its is very handy because you don't have to rewrite everything out again right there and then music and grab one post-it and swap it over in position if priorities have changed this exercise besides having identified priorities have also done one other thing they have identified for your roadmap for the future because if we go to that list and we go from the first column top to bottom and we follow true we have established ourselves a roadmap we're by we set out for ourselves goals on the short-term and on the long-term and so I just put this picture in here this was an example of a grooming session and the reason why I want to point this out is because it is not your typical meeting it is not your typical team meeting the number of participants is usually smaller because there's not necessarily need for every team member to be involved because these things are very high level and they keep changing anyway right so essentially it's all it's all about the customer and who interacts with the customer and possibly bringing in certain experts who might advise us on wait a minute this item could be less important but it is very complex and we need to address it sooner than later it's print planning now here's a couple of techniques how we can actually get to concrete results and and help us to understand and estimate things and so on but remember that I was talking about story points user story points so one way to do it is for example we have this poker method and it's a special card deck that has been designed for agile everybody gets a deck the scrum master presents the story to use a story that is up for discussion and at the same time everybody pulls out out of their deck a card and it's the amount of user story points that they attribute to that specific task so the lower zero of course means this has already been done we don't have to worry about it there's no work involved something like 13 means it's you know it's a job that needs to be taken care of it will take us a couple of days but something like like 40 or 100 now that indicates that there's something important going on there and this could take us multiple Sprint's if that's the case then we need to reassess and see whether that bigger that bigger requirement or that bigger job could not be split up as smaller chunks every team member at the same time exactly the same time so they don't influence each other pulls out their card right now what we will see is at peak different people have different values right the next step is that the two people with the two most extreme cards interact and the scrum master calls them out and says well why do you have four why does the heat why do you have 40 and then one team member can say to the other as an example well that's a very easy job that's a no-brainer the other person can say like what are you talking about this is super complex have you thought about this and this and this right or it could be the other way around someone thinks is very complex and it has already been partially been done but the thing is that after this confrontation of this dialogue you have the team members revote again until you find a consensus on how much work really is involved there's another technique that I frequently use and I find it very very helpful because I'm stepping away from numbers and yet at the same time I'm using consensus that everybody knows about namely t-shirt sizes everybody knows what as small is and everybody knows with a larger own Excel is right so the thing is that each time we go over requirement or use a story I ask the team well what size do you think this is and someone will say medium or large or whatever and it comes down to the same thing if one person says well this is a small task and someone else's no no this is a an extra-large then you should you know start a dialogue between the different team members and find that well what is the real story is a story more complex and do we need to re-evaluate things or do you guys are is a team able to reach consensus on really how much work would there will be involved I would strongly focus on keeping it simple there's no need to overcomplicate things so let them rather think in terms of t-shirt sizes and how much work is left rather than then the specific numbers this is the t-shirt size and here that's the specific number that corresponds with it okay a large is a 20 extra-large is a 40 and you can calculate if these are the items that you want to work home for the next sprint okay and these are the items have been identified you can calculate and you come to the conclusion as a team progresses and it get more and more familiar what they are able to do wouldn't those couple of weeks you also are going to develop a very strong sense of how many story points you're able to pull off and once you have that this is key because then you can take it to the next level you can the next time you start planning tell the guys hey we need to keep it within reason we have to be realistic we can't take on too much or we can take on something extra because in the past it has proven that actually we're able to do better now those t-shirt sizes come in very handy and we can help determine now as well how big a chunks of work are these and this will also help us to understand what why we say yeah this is about one sprint our first two weeks this is what we'll be able to accomplish and next two weeks well that's a small extra small so those two are very small so we'll probably be able to you know this something extra so we can already maybe start addressing this but we at least have the expectation because this is a you know it's a considerable size and it's very possible that we'll have to carry this over to the next sprint and we won't be finished it with it on time but at the same time let's kick off with it and let's already start doing some some work the first work the fist of five technique it's it's not for everybody let me put it this way but you know we when you interact interact with the team and you want to find out how comfortable they are with taking on a certain a certain task immediately or if you want to wait a little bit with it then you would have every team member raise your hand at the same time okay and and 504 means that that they feel comfortable and a1 or a2 means that they're less comfortable but the reason why we do this whole thing with the hands is the very simple reason that people are just not that talkative very meetings there's always the same people we do the talking the Delphic method is a different type of discussion but this time you go one person after the other of the entire team okay and every person gives their opinion about it and then once you've gone down the circle then you do it for a second time so people can give some feedback about some of the other considerations that they heard retrospective just to recap here a little bit how well have you done and if you remember I said that this has proven to be one of the most successful things to turn a team around because it enables them to to address certain issues and I can assure you the best suggestions for process improvement and better delivery have been true this I guarantee you at one project that I worked on implementing the retrospective ended up leading to an improvement of 40% because very often someone has great suggestions on how to address certain issues but it just don't speak out the square master asks every person to speak out one after the other and nobody interrupts you have two columns and you ask you add the two questions so one well and what do you think could be improved and once you've written everything down of all the different team members then you go over to the to the actions by hearing both of these you already figure out it will should start doing that but we can keep doing this and here's a different type you know start stop keep more or less sometimes people feel less comfortable especially in the beginning to start categorizing things and calling them out so sometimes a great way to do is like what did you think went well last time and then everybody always wants to be positive or has something positive to contribute right well then next step isn't that you go over to what is less good ok reporting it is not because we're a child that we should neglect reporting our clients depend upon it right executive management depends upon it and the team depends upon it as well because it will show their success and their goal driven efforts ok every good report must contain this there are no excuses risks and issues how many reports are not mentioning risks and issues it leads to the aggravation of management that they are not being made aware of problems in advance frequently management's or clients understand that certain issues can can develop and and they're unstoppable they realize this the only thing they want to do is at least be told in advance so we can develop a risk or an issue mitigation plan this is an example of a prototype made in the past and risk sunk can be very small things ok a risk and for example be a vacation what in the month of July or August or wherever your vacations or holidays most frequently place if the entire team leaves and is only 50% capacity left well that is a problem or if for example one of your subject matter experts leaves for a three-week vacation okay now that can really slow down the team and these things need to be identified and also what I propose is with all the user stories and so on it is very useful especially to report to management in the clients that we have milestones we cannot move away from milestones and here's just a quick overview some of the things that we can put in there you know then we report and show the status of where we are with things we can show a burn now chart at the bottom is what we call a velocity chart it shows that average work you know in story points that is being delivered on a weekly basis okay miss practice now here's probably the best part of the whole presentation let's go over some concrete situations so sprint planning so here are some common traps with sprint planning the story points proved to be a nightmare so let's simplify it let's try to keep things kind of as simple and let's aim for something that the team feels comfortable talking about right maybe they feel most comfortable talking about hours and expressing it that way and huge epics remember I set up epics for these huge user stories that are a huge amount of work and will take multiple weeks if not months well let's try to break those up and a carryover of user stories there seems to be a frequent misunderstanding whereby people seem to think that the sprint needs to finish every single item that is in there and that is not true sometimes it is unavoidable let's say for example you have a sprint of two weeks there's no way on earth that you can complete that entire an entire job would in total two weeks we have to be realistic but at least we need to make the team aware a minute we will be carrying over this task but let's make sure next time we finish it off so perpetual loser stories sometimes they keep going on and on and on and on and on right we have to make sure that you're just stories come to completion and the thing is that sometimes it can be that only one task is remaining and then there's there's there's a team member who you know who should be taking care of that we cannot tolerate that things don't get completed no burn down chart burn on charts I'm going to take some practice your estimation will improve over time we're looking to estimation people are a little bit hesitant because they fear that they're going to be called out on it and it will be held against them but it's all about building trust too short people don't spend enough time on sprint planning people think that they can determine the next two weeks work and half an hour meeting now let me tell you this personally I hate meetings I think as a rule a meaning should never be longer than 30 minutes because it will help you to be driven and focused however in this case sprint planning could easily take an hour maybe in the beginning it might take a little bit longer because it's a new process but you have to take your time if you don't plan well then the whole agile process becomes a joke because you don't deliver you don't meet expectations it's a farce and then finally you know risks and issues get ignored you start planning it you start planning ahead but people are totally oblivious of risks that they know are coming or and that they have identified then three more things so there's there's no backlog grooming nobody has looked whether the requirements have gotten a new priority so it's important to make sure that whoever interacts with the customer keeps a team informed you know keeps a product backlog up-to-date then people missing let's say for example there's a bank holiday whereby the entire team or a good number of people will be absent because called it takes place in one country manatee otter you might want to consider to postpone the meeting the planning meeting for a day is to make sure that we have everybody involved and we can be very effective and planning everything and a limited participation some people just don't speak out well you know what the scrum master needs to do his role and the scrum master need to make sure that they get involved and he's to call them out he used to say hey what do you think I want to hear your opinion they might feel uncomfortable in beginning to be called out but at the same time on the long run they will feel that at least I have a voice and they don't have to get irritated about all the same people you know saying the same thing okay the daily stand-up meetings there is no excuse to have a daily stand-up meeting longer than 15 minutes we have to drive through this if you want to keep people motivated to be at these daily standard meetings then let's get it on over with okay discussions now this is a very important element it always always happens someone mentioned something and it's a problem he's having and the whole team or a part of it a part of the team starts having a discussion and avoid ibly the whole 15-minute thing is going to be ruined and what the scrum master needs to do is to say okay let me take a note of that and he literally writes it down right and you rise on all the different points that possibly are up for discussion and after the 15 minutes of the daily standard meeting then he he calls out the different people and say like hey you know what let's let's talk about this because don't forget frequently these discussions only affect a number of people we do not want to hold up anyone being stuck at a meeting where they have no interest in being at let's stick to the business and let's keep the daily stand-up meeting really for what it is blockers are not mentioned make sure people call out the blockers or if they don't have a blocker they should say I have no blockers I'm good to go people don't pay attention if you over to the same rotation and you and a person knows he comes last he will not pass for all the other people well the scrum master can rotate and you can call out at random who should speak making sure though that every single person gets gets to speak then people look at our laptop well have people stand up force people away from their laptop there's a good reason why it's called a standard kneading is because nobody wants to stand up for too long and it pulls you way out of your comfort zone where you're at right now now no visualization we have to have a scrum board we need to follow what is they're linked to rivals people will keep arriving late it always happens but you know what no excuses you start the meeting on time if you start a meeting on time and there's someone systematically who comes always late it's an embarrassing thing to come late and you do it once you do it twice but what you will see is that the team gets annoyed by it after a while and the group will will tell the person who's always late you don't need to get here on time and it tends to correct itself naturally it's very important to realize what these daily standard meetings the scrum master role is very important and he is not the boss he's the facilitator he's there to help things to go smoothly to move forward and to make sure everybody gets heard now recipe for a successful stand-up people should come prepared there's nobody who should come to your daily stand-up meeting and say like I don't know no you should set the expectation that you expect when they come that they know what they're going to talk about also make sure that people all talk about all three questions I've mentioned before that very frequently people forget to mention the workers so call it out then have people come on time then be about being specific here's an example of what it should sound like well yesterday I was working on task one two three it was sized 8 hours and I spent the whole day on it about 6 hours and a half X amount of hours left this is how it should sound because that way the team will fool understand how far we are with it and then the fifth one is avoid sounding busy people the honest truth is people like the sound busy and if they got much to report they're going to mention extra stuff that are trivial if people don't have much to report that's okay the scrum master should point out that we need to dress the real issues and the topics and so it's not time to solve problems you know the extra mile here okay you can add prestige to your own daily standard meetings for managers and it's incredibly awesome to attend every so often as an agile coach I don't expect the manager to be there for the entire 15 minutes even if if the manager would come in let's say halfway and he spends 5-6 minutes there just by showing himself and showing interests the team will realize well this is a very important part of our process they also will think I need to be well prepared and made to make sure that what I whatever I say makes perfect sense now what executives when a team reaches a certain very important milestone and there was huge expectation from you know executive management I guarantee you that executives will show the willingness to go to the team and and be present for five minutes to express his gratitude because it will motivate the team and will keep them going and will make sure that that they're better United and more geared towards getting the results and a recognition plaques honestly if a major milestone is reached you can order a recognition plaque and you can hang it up in the room if the team is co-located as a badge of honor it is a great thing for example for an executive to come down and to hand over certification ok review meetings so the sprint review meetings you know always the same people speaking out by the way long weekends so be careful when you schedule things make sure try to avoid Friday's and try to avoid Monday sometimes it can be avoidance but the thing is that people tend to take long weekends and take off an extra fried or an extra Monday and the problem then is if you have a crucial meeting plans such as a sprint review well then multiple people could for example be absent so if you schedule these for example let's say on a Tuesday right right before the actual sprint starts you could avoid problems like this okay then our retrospective retrospective health people and they're finally able to vent and talk about the their frustrations or difficulties and how they would like to see something changed but at the same time then they say like well I'm too busy and I can't do it all so important make a record of all the recommendations that people have have made and send them out afterwards because sometimes someone cannot make it and it would be great to send them out and also you can keep the either the previous retrospective for the next trip perspective and you can reflect back with a team on it like well here's what we discussed last time let's go over to the next one okay agile transformation and these are last few slides here's some common problems the usual suspects some people always get called out as the bad guy and so on the scrum master should really be impartial and try to take stand up for everybody and unify the team as a whole now open air I'm sure that this daily standard meeting was probably a very successful standard meeting there's one thing missing there is no visualization they're just talking up up loud I can tell you that the team needs to be geared towards something because otherwise it is very hard to pay attention unrealistic people just say people say that everything is fine and so on now we all know this is not the case then old-school if we ask the team members for estimates we have to you know be honest to ourselves people are hesitant to give estimates because they're afraid that we'll be called out on it well if that's the case let's not call them out on it and let's make it part of an open communication whereby we were understanding and we're willing - you know to work with it don't make too long a meetings and in sterile environments you know officers should be something that is is really a workplace so focus that's what I said about the meaning boards and so on every minute counts make everybody a big part of it let the meeting come to you to the team rod and the team going to meeting rooms keep everything together here's a little overview how Wells at your office can return to a fantastic workspace where everything is visible at any time at any point in time and the agile process implementation here are different steps that I personally would recommend about how to implement agile to implement in an in - company or department of the vision okay a community is to be established you need to identify the specific problems then make sure you provide some agile training to different roles and then you can slowly start going over a different a different elements and reporting at the very end you can't report if you have not anything else up these are higher level things one of the things for example is new hires if in the future we do hiring let's make sure that people have already some experience with it root cause analysis let's go back every quarter to make sure that that we revisits and look at the problems my remarks I think I reached the ends there was another video I was going to show but maybe I'll leave it up to your discretion Thank You Martin now let's look at a company that has embraced the agile methodology we are the world's number one largest tax preparation provider we keep busy all year round and the key part of that is the development in the strategy having the scrum methodology has been really helpful as we continue to serve our clients year-round at the brain trust consulting group we've found two main reasons teams fail one is they have no process made up in chaos or two they have too much process and they're mired in it we've got a pretty tight cycle so tax season comes around once a year we're trying to pump a lot of products to the market scrum is not a good fit for every organization it was a good fit for H&R Block and they were willing to implement it it had great executive support throughout the organization used brain trust as a change agent within our initiative at H&R Block providing constructive feedback to the team that was usable and we could turn around and implement the next day there's what's in the books and there's what you need to do to really get the product out the door and work in our environment it's not easy to implement agile it's easy to attend the class and it's easy to come away fired up with all of the ideas where both their training and their coaching helped you know it just integrated so well and I think it just feeds one into the another in the coaching side is really the practical application of what people have learned in the classroom environment into their specific working environment so it's all about finding out their pain points and how to apply a particular technique inside their environment to be most successful what I've seen a brain trust has been great and I know that our IT partners have been very pleased with them it was actually great to have an outside perspective and had seen some of the pitfalls or some of the behaviors that might have historically derailed scrum at places our goal is to help the team be successful to help the individual be as successful as they can be the coaching is I think it's been invaluable I don't think we'd be anywhere near successful without it terrific to have brain trust in our early part of the journey for us to change to agile and scrum you

Channel: Maarten DuPont

Views: 293,904

Rating: 4.8399391 out of 5

Keywords: Agile, Methodology, Common Problems, Theory, Transformation, Presentation, Waterfall, Scrum, MoSCoW, Transition, Best Practices, Strategy, Project Management, Change

Id: fCE1PmtbGXQ

Length: 88min 49sec (5329 seconds)

Published: Tue May 17 2016