The Evolution Of Kanban: A Study Of The Principles & Practices
By Leon Tranter
As a part of the overall move towards Agile software development and related disciplines, many people are interested in Kanban. Some are applying it as a part of Agile, others are looking into it as an alternative to Scrum. There is a lot of confusion about this simple yet effective tool, so this article will clear up these misconceptions and provide a quick crash course into the essentials of Kanban. Where did Kanban come from? Kanban originated in Japan in the 1940s. People from the Toyota car manufacturer noticed that supermarkets used a simple but effective system based around small physical cards to indicate when something was out of supply or needed to be ordered. They applied this system in their own manufacturing process to help visualise work and control flow. Kanban became a part of Lean Thinking and the Toyota Production System. It was later popularised amongst software developers in 2010 by David Anderson with his book “Kanban: successful evolutionary change for your business”. What really is Kanban? Kanban is a simple but powerful system for visualising and managing work. It is not just related to software development, in fact, it is not specifically related to development of any kind. It can be used in a restaurant, a supermarket or a car factory. It has four principles and five practices. As opposed to Scrum, which involves revolutionary change, Kanban is about evolutionary change, starting from right where you are now (in fact, that is one of the fundamental principles: start off by changing nothing whatsoever! You won’t find any organisation on earth that will resist that change). It is fundamentally about visualising work and then finding ways to improve the flow of work through a system. Nice visualization of the Kanban principles and practices pic.twitter.com/WbDMSoRfk5 — maciej sowiński (@maciej_sowinski) January 13, 2016 The Four Principles of Kanban This section will discuss the four fundamental principles behind Kanban. They are all essential to understanding and implementing the practices. Fortunately, they are simple and can fit into any organisation or system. Start with what you do now As mentioned, Kanban is a method for gradually improving an existing workflow or system. So you start with whatever you are doing now - whether simple or complex, big or small. You can use Kanban alongside or on top of any existing framework or system you are using - Scrum, Waterfall (yes Waterfall!), or anything, really. Many people believe they have to choose between Scrum or Kanban - untrue! You can use them together. Agree to pursue incremental, evolutionary change As opposed to systems like Scrum or Extreme Programming, that start out by fundamentally changing the structure and behaviour of organisations, Kanban is about evolutionary change, one small increment at a time. This can make it well-suited to cumbersome organisations that resist large risky changes. Respect the current roles, responsibilities, and titles Kanban doesn’t start off by renaming people or inventing strange new roles. Everyone gets to keep not only their job but their job title too. This further helps resistance to change. Encourage acts of leadership at all levels This is a subtle but very important principle. Improvement is the responsibility of everyone in the organisation, from the CEO down to the receptionist. You might get to keep your current job title and responsibilities, but you also now have an additional responsibility: leadership, which is really about empowerment and improvement. The Five Practices of Kanban Unlike Agile, which only has values and principles, Kanban has actual practices that you can employ, starting from day one. Visualise the workflow This is the most important step in all of Kanban, and is at the core of the whole system: visualising work. This was trivially easy to do in Toyota car manufacturing plants: the work was cars lying around in various states of semi-construction. For knowledge work like software development, marketing or design, it is much harder to visualise. This can let work accumulate and create huge blockages without anyone being aware. So visualise the work! This will make it easy to see where work is piling up and where problems and bottlenecks are. The best way to do this is on a physical board, using tokens such as index cards or post-it notes. Putting the work in an electronic tool might seem convenient but when the computer is switched off or minimised, the visualisation of the work is gone. The bigger and more physical, the better! You want to aim for information radiators (that push information out to the organisation) rather than information refrigerators (that preserve information away from people’s eyes). The most common way to visualise the work is with a Kanban board that has vertical swimlanes to represent states of work. You can then place cards on the board to represent the actual work item. Here is an example of the simplest of Kanban boards, with lanes for To Do, Doing and Done: Here is another example of a board, this time with some extra lanes, numbers that indicate Work in Progress Limits, and cards marked as being Blocked. Limit WIP Limiting WIP (WIP stands for Work In Progress) is another key practice of Kanban. People often think that we want to maximise work in progress - that means everybody is busy and lots is getting done, right? Well, if you have lots of WIP, then everyone will probably be very busy, but that isn’t really valuable. We want work in a Done state, not in a “Doing” state. And the best way to ensure that is to actually REDUCE the amount of Work in Progress! It might sound counterintuitive, but it is true. Lots of WIP means lots of handoffs, queues, bottlenecks and task-switching. This all means not much getting actually Done. Minimising WIP means you can maximise flow, which maximises the amount of work Done. And that’s the true goal. Manage Flow Kanban focuses on reducing WIP in order to maximise flow. If you want lots of work to get to Done but don’t want lots of work in a Doing state, you have to reduce the amount of time it takes for work to go from Doing to Done. This is called Cycle Time. Kanban practitioners have many tools they can use to improve flow and reduce cycle time, and these will often become clear after you have visualised the work. They include eliminating approvals and handoffs, swarming on complex slow tasks, identifying bottlenecks, putting WIP limits on Kanban lanes, reducing wait time between tasks, and reducing queues. Make Process Policies Explicit As you implement new rules and policies to improve flow, ensure you make these explicit. If you have a Definition of Done, get people to agree to it and publish it. If you change the rules about approving a document, make sure this is understood and explicitly described. Improvements will fall away and get misused if they are not clearly articulated and understood. Improve Collaboratively, Evolve Experimentally Improving is a collaborative team effort, not something randomly forced on people by some arbitrary management edict. It should be implemented by teams in an iterative experimental effort. Teams need to feel they are in an environment where experimentation is encouraged and it is “safe to fail”, or nobody will try making genuine changes. I hope you have enjoyed this crash course in Kanban - many people are using this system to great effect. If you want to know more, I would recommend the books Kanban by David Anderson, or Kanban in Action by Joakim Sunden and Marcus Hammarberg.
Rated 3.5/5
based on 4 customer reviews
283
167
Agile Management
The Evolution Of Kanban: A Study Of The Principles & Practices
Leon Tranter
Apr 20, 2018
As a part of the overall move towards Agile software development and related disciplines, many people are interested in Kanban. Some are applying it as a part of Agile, others are looking into it as a...
Continue reading
How To Earn More PDUs After The Completion of PMP Certification
By KnowledgeHut Editor
Are you a PMI® credential holder? Do you also hold a PMP® certification? Then this article will be useful for you! All PMI® certifications except CAPM® certification (Certified Associate in Project Management), need holders to string along with the Continuing Certification Requirements (CCR) Program. The aim of this program is to ensure that your skills and certified capabilities are up-to-the-minute. Generally speaking, it involves earning PDUs as well. PMP® Certification- If you are planning to take the PMP® training, it will be worth the cost and your efforts. Various industries use PMP® as a standard for project managers. PMP® certification entitles you to work in any environment and with any methodology. The PMP® certification covers the various project management techniques and skills that are essential for project managers. The PMP® course creates your impression as- It indicates your superiority in using the PMBOK® guide It indicates that you know the best practices for project management Salary of the PMP certified- According to the 10th edition of Project Management Salary survey by PMI®, it is estimated that the PMP® certified project manager is getting more than non-PMP certified project managers. The average annual salary for a PMP® certified professional is $108,200 per year. They earn 20% more than the non-PMP® certified individuals. Here is the salary report of the PMP® certified according to PMI® report. Once you have sailed through the PMP® exam, your 3-year PMP® re-accreditation cycle starts. You need to earn at least 60 PMP® PDUs with a specific end goal to effectively renew your PMP® accreditation. Usually, 1 PDU is equivalent to 1 hour of PDU activity participation. But, there are points of confinement to certain PDU activities. We will see ways to earn more PDUs in details. But before that, let’s know what is PDU? Do you know? 1 PDU equates 1 hour of PDU activity participation What is PDU? A PDU is a Professional Development Unit. Once you earn your PMP® certification, the next step is to maintain the PMP® credential. This credential is valid only for 3 years. So to renew the certification, you need to report 60 PDUs to the PMI® before completing the third year. If missed to renew, it leads to suspension of the certificate. Ways to earn PDUs- Earning PDUs for PMP certification is a hassle-free and less expensive process and some PDUs can be earned free of cost. PDUs can be earned in two ways- A. Free PDUs B. Paid PDUs A. Free PDUs Free PDUs are categorized into 2 sections, 1) Education PDUs: Education PDUs can be earned in following 3 ways- Online or in-person courses and training offered by PMI’s Registered Education Provider (REPs) Continuing Education (professional meetings and local events) Self-driven learning From Education PDUs, you can earn maximum 35 PDUs. Out of 35 PDUs, 8 PDUs consists of technical Project Management skills + 8 PDUs in Leadership skills + 8 PDUs in strategic business management skills. These 3 skills-sets are referred as a ‘PMI Talent Triangle’ by PMI®. 2) Giving back PDUs: Giving back PDUs includes the sharing of knowledge and applying skills to contribute to the profession. This includes- Creating knowledge Giving a presentation Creating content Working as a practitioner Sharing knowledge Volunteering From giving back PDUs, you can earn maximum 25 PDUs, but only 8 PDUs can be earned as working as a practitioner during 3 years. B. Paid PDUs Paid PDUs is another way of earning PDUs after PMP® certification. The second way consists of not only gaining the project management knowledge but also earning more PDUs. This way of earning PDUs is more effective than the free PDUs in terms of gaining PDUs too early. Also, this enhances your skill-set along with the PDUs. Really looking forward to the discussion on maintaining my PMP certification @pmiirl — Joanne Cronin (@dudara) July 6, 2017 Has it come to your notice? Paid PDU approach is more effective than the free PDUs, as it not only acts as a skill enhancer for an individual but also helps in earning PDUs too early. Here are some of the Project management related courses that can help learn more about project management and earn more skills. 1) PRINCE2® course: You can earn 16 PDUs from this course. PRINCE2® (PRojects In Controlled Environments) is a Project Management methodology that allows you to handle any complex project in a diverse environment. This method is practiced worldwide and the certifications are considered authentic if the training institute is an Accredited training organization (ATO) of PEOPLECERT and a certified partner of Axelos. 2) ITIL® course: You can earn 25 PDUs from this course. ITIL® training provides understanding of the project related best practices and implementing these practices to streamline the processes for continuous improvement. It is highly recommended that you take this course from the institute which is an Accredited Training Organization (ATO) of PEOPLECERT and a Certified Partner of Axelos for ITIL® Trainings. 3) PMI-ACP® course: You can earn 21 PDUs from this course. The Project Management Institute- Agile Certified Practitioner (PMI-ACP)® is a widely accepted certification in the Agile community. This course shows the competency of an individual in carrying out a project in any circumstances using Agile practices. For this course, select the institute which is a Registered Education Provider (REP) of Project Management Institute (PMI®). Being a PMI® member, if you are PMP, PfMP, PgMP, PMI-PBA certified then you need to earn at least 35 PDUs from Education Category, 25 PDUs from Given back to the profession category 8 PDUs from each category of Talent triangle. Also, you can grab maximum 8 PDUs from ‘Giving back to the Profession’ by ‘Working as a Practitioner’ and all 60 PDUs from education category. Do you know? PDUs can also be earned by watching recorded webinars from projectmanagement.com. These PDUs will get recorded under the ‘PDUs awarded section’ on your account page. Hence , no need to report them separately. PMI membership comes with professional membership of project management.com. Future Demand for PMP professionals- According to the Project Management Institute®, the demand for project management professionals will explode by 2020. Below is the graphical representation of the new job vacancies worldwide for project management role. Bringing it all together PMI® is a registered trademark of the Project Management, Inc. and PMP® and its logo are accredited features of the Project Management Institute (PMI®) which are enrolled in the US and other countries. You need to keep in mind that your PDUs can be examined and you could be asked to provide justification of your learning any time. So, it is better to earn your PDUs only from accredited organizations. There are various genuine ways to learn, create and claim PDUs to stand out in the market. I hope this information will help you in earning PDUs the way you want! 
Rated 4.5/5
based on 5 customer reviews
How To Earn More PDUs After The Completion of PMP Certification
284
176
Project Management
Are you a PMI® credential holder? Do you also hold a PMP® certification? Then this article will be useful for you!
All PMI® certifications except CAPM® certification (Certified Asso...
Continue reading
Peak with PMP: Reach New Heights With KnowledgeHut’s Top Courses
By KnowledgeHut Editor
Project management professional certification is one of the most reputable certifications across the globe that proves your efficiency and productivity in project management in your workplace. One should meet the following criteria in order to receive the certificate: Secondary degree holders: Should have at least 5 years of experience in project management, with 7,500 hours in leading projects and 35 hours of project management education. Four-year degree holders: Should have at least 3 years of experience in project management and spent 4,500 hours in leading projects and 35 hours of project management education. If you fulfill the above PMP credential requirements then you can apply for the PMP certification online at https://www.pmi.org/. But, ensure you make a well-defined study plan that helps to complete your PMP certification process successfully. The 35-hour project management education program is the crucial factor for your success. Opting the course from a Registered Education Provider like KnowledgeHut can help you build the foundation for the exam by equipping you with the knowledge of PMBOK (Project Management Body of Knowledge). This training program will not only make a candidate eligible for PMP exam but also provide ample insights to shoot your target. Schedule your PMP certification exam on successful completion of the course. The exam consists of 200 objective-type questions which need to be finished within 4 hours. And, you need to answer a minimum of 137 questions correct out of 175. You will get the PMP certification as soon as you see ‘passed’ on the screen. You need to claim 60 PDUs for every 3 years in order maintain the certification and your 3-year recertification cycle begins immediately once you receive the certificate. According to a study conducted by PMI Pulse of the Profession, enterprises are getting their projects done on time, within scope, and within budget which has at least one-third of PMP certified project managers. This is because a project manager is responsible for planning, organizing, leading, monitoring or controlling, estimating cost, developing the budget, and managing risks and reports of the project. A certified project manager can play multiple roles depending on the requirements of the project such as project manager, program manager, portfolio manager, functional manager, project sponsor, project officer, and delivery manager. The demand for Project management profession is growing faster than any other occupations. Holding a PMP certification proves that you understand the global language of project management and helps to connect with a community of experts, organizations, and professionals worldwide. 
Rated 4.5/5
based on 5 customer reviews
Peak with PMP: Reach New Heights With KnowledgeHut’s Top Courses
354
185
Project Management
Project management professional certification is one of the most reputable certifications across the globe that proves your efficiency and productivity in project management in your workplace. One sho...
Continue reading
The Personal Agile Transformation: An Agile Journey To Productivity
By Jim Stewart
Much is made lately of the fact that some organizations are making the transformation to Agile, finding the greater emphasis on self-organizing teams, incremental deliverables and maximal business value compelling. However, whenever one reads about this transformation, it’s usually from the perspective of the organization and how Agile impacts it as a whole. But while from the outside it would appear that an organization is some faceless monolithic structure, we know that it is comprised of living, breathing people who themselves deliver the goods and services that the organization provides. And so, it seems important to consider what the impact is on those who must deal with their own personal Agile transformation. I have been performing traditional project management for over twenty years. I teach project management as well, and I’ve always been fond of telling my students that project management is, like accounting, a mature profession. Accountants talk about debits and credits and the only thing that really changes periodically is the tax code. The lingua franca of project management is, and for many years has been, artifacts such as Gantt charts and Work Breakdown Structures. But to a great extent, the ground has started to shift under the feet of traditional (plan-driven or waterfall) project managers, especially in the last few years. This is because the Agile approach, initially defined in a manifesto in 2001, has really begun to establish itself in corporations. Not, I would say, to the extent that it is replacing traditional methods and not everywhere. But significantly enough that project managers now need to be not only conversant in it but must also begin to consider being trained in it and getting some experience. (Its greater recognition in that bastion of traditional project management, PMI’s Project Management Body of Knowledge, Sixth Edition, is a fairly significant development). On a personal level, I got my Certified Scrum Master certification in early 2013 but never used it, at least not initially. It wasn’t so much that I was opposed to Scrum as much as that I was working in traditional project management and hadn’t really witnessed first-hand the revolution under my own feet. But gradually I began to realize that there was going to be a significant shift in the direction of the use of Agile and that in order to stay conversant – and, I might add employed – it would be necessary to start getting exposed to Agile projects and working in them. And in thinking about it, I realized that perhaps the very first thing I had to contend with in Agile was the fact that not only is the project manager role not quite as significant, in fact, there is no defined PM role as such. In the Scrum variant, there are only three defined roles – Scrum Master, Product Owner, and Development Team. When I got my Scrum certification, I realized even then that it was a different type of role. As a project manager, I might – and should – do all the planning with my team. But when it comes time to decide who did what and when, that was always my job. It is very much of a command and control structure. And not only did I expect to lead the team, the team expected to be led. But in Agile it’s quite different. In that role, I am much more of a facilitator or coach than I am a driver of the team. The team is self-organizing, meaning that while I can help remove impediments for them, it is not my job to tell them what to do as such. It is their job to figure out what to do as a team and for the Scrum Master to facilitate and coach. Find some useful tips on how to succeed with your Agile transformation below- This is a major shift, not only for the project manager but also for the team. For the project manager, he or she must stop being directive and start being facilitative. For a lot of PMs, this is a very challenging transition. They don’t know how not to direct. And as likely as not, if they have been a PM for a long time, they are very much used to using a scheduler such as MS Project. But a Scrum team doesn’t necessarily need such a tool, preferring workflow tools such as Jira to track progress. The challenge is that the traditional project manager must hold back on telling the team what to do when they ask. He or she can remove impediments when they arise. But his or her best advice when asked what a team member should do is “take it to the team.” In a sense, he or she has to rethink what he knows and throw some of his or her training out the window. Be a Scrum Master, Not a Scrum Manager https://t.co/ohOBBzH5Lb #agile #scrum #dev @HyperRTs @DNR_CREW pic.twitter.com/XrmsCAdzwK — Seth G. (@Nicko_iCorplife) October 14, 2017 And it isn’t just the PM that may have a problem adapting to this new reality. Imagine the team member who is used to being told what to do in a hierarchical situation. Now he or she is faced with, to a certain extent, being self-directed. Some prefer not to go through this experience. And while Agile can be used for a variety of projects, it still tends to be heavily used in software development environments. And some developers, for example, used to working alone, are now expected to meet every day not only with the team but with the business. For some, this is outside their comfort zone. I spoke to a woman at an Agile conference who advised me that several developers on her team asked to be moved or left the company when Agile came in. I think the main takeaway here is embracing change and adapting. (Ironically, hallmarks of Agile itself.) Some people just prefer to do things the way they’ve always done them. And then when change overtakes them – as surely it is doing in an Agile world – they are unable to make an adjustment and wind up on the outside looking in. Once I realized that I needed to get into this world, I made this transition not only by getting trained but by adopting an Agile mindset. (Which is what Agile coaches help teams do.) I started reading everything I could get my hands on, networked as much as I could and then when the time came, leveraged that knowledge and my years in project management into a role within a company that, while Agile-ready, still saw the value of both approaches. And when I let go of the need to be in control – and realized I needed to be a coach and facilitator - I found that things just fell into place.
Rated 4.0/5
based on 22 customer reviews
The Personal Agile Transformation: An Agile Journey To Productivity
114
68
Agile Management
Much is made lately of the fact that some organizations are making the transformation to Agile, finding the greater emphasis on self-organizing teams, incremental deliverables and maximal business val...
Continue reading
Are You Delivering Potentially Shippable Product Each Sprint?
By Ridhi Chhabra
By the end of each iteration, a Scrum team is expected to produce a Potentially Shippable Product. As we know Agile methodologies emphasizes on “Working Software over Comprehensive Documentation”. When we talk about working software, it is both complete and potentially shippable. Agile methodologies emphasizes on working software which is both complete and potentially shippable due to following 3 reasons: It encourages feedback It helps a team gauge it’s progress It allows the product to ship early if desired In order to ensure, we are delivering a Potentially Shippable product at the end of the sprint, we must understand what potentially shippable means. Defining Potentially Shippable As per Scrum Inc, a Potentially Shippable Product is the outcome of the Product Backlog Items delivered at each Sprint. Delivering Potentially Shippable Product at each Sprint is essential to the Scrum because when work is divided into simple pieces it can be finished in a short iterations. As per Mike Cohn, "potentially shippable" and "shippable" are not the same thing. Some large or complex projects will require the use of "release sprint" or "hardening sprint" at the end of a release cycle (say 6 two-week sprints then a 2-week release sprint). The release sprint is not a dumping ground for sloppy work; rather it is a place where some hardening of the system can occur. Let’s have a look at some of the guidelines here: Organizations define their own ‘definition of done’ for every product and project. However, there are some guidelines that are applicable for almost all the Scrum projects in most of the organizations. Potentially Shippable means Tested! There can be no situation where a product is delivered without being tested. By the end of the Sprint, the delivered product increment needs to be bug free. If needed by the Product Owner, the feature should be a bug free, it can be released to the beta users or the stakeholders to review. Potentially shippable does not mean cohesive Just because we know that the product is potentially shippable, this doesn’t mean that people wants us to actually ship it. Many times it takes 2, 3 or more sprints for a feature set to come together to be useful. However, during the Sprints leading up to that point, the team should still strive for a product to be potentially shippable. The #Scrum team as a whole is responsible for delivering a working increment of the product at the end of each sprint http://t.co/NqnOc7JeUt — Manifesto (@ManifestoLondon) September 16, 2014 Potentially shippable means integrated A potentially shippable product doesn’t exist as different collections of source code. On a project, where multiple teams are working, the teams should define the statement of done such that it includes integrating development steams. So, Integration should be done continuously throughout the sprint. Does Potentially Shippable means Shippable? Well, when we define the ‘definition of Done’, We want it to be a Potentially Shippable product. This doesn’t mean that it has to be shippable. Whether the product needs to be shipped or not, that’s a decision taken by the Product Owners, or Business Owners. Hence, Potentially shippable is a state of confidence, that the product delivered at the end of the Sprint, is so Done that it’s Potentially Shippable.
Rated 4.0/5
based on 12 customer reviews
Are You Delivering Potentially Shippable Product Each Sprint?
122
76
Agile Management
By the end of each iteration, a Scrum team is expected to produce a Potentially Shippable Product. As we know Agile methodologies emphasizes on “Working Software over Comprehensive Documentation...
Continue reading
All you need to know about Leading SAFe 4.5® Certification with KnowledgeHut
By KnowledgeHut Editor
Agile is a project management process which encourages self-organization, accountability, and teamwork. This methodology progresses a moderate project management process by reducing the time required for review and adaptation. SAFe combines the power of Agile with Lean product development and systems thinking. It integrates delivery, collaboration, and alignment for multiple Agile teams and provides significant improvements to business agility, including quality, productivity, employee engagement, customer satisfaction, time-to-market, and more. The new version i.e SAFe® 4.5 was released on June 22, 2017. This advanced version speeds up the delivery process of products and services and also offers a 360-degree build-measure-learn feedback cycle. With four major updates, SAFe has grown faster with the market since the initial release in 2011 and keeps on being a work in process. SAFe 4 Agilist certification helps you to build a strong foundation on Agile practices, standards, and applications required to enhance the probability of the project's overall success. You might be searching for the best institute to take the course and might be thinking why only KnowledgeHut and why not others? Here we answer all your queries about Leading SAFe 4.5 Certification with KnowledgeHut. Looking for a quick overview of #SAFe? Check out our most popular download: https://t.co/Iw7rVXSK6U pic.twitter.com/oPEExo8mUY — Dean Leffingwell (@Deanleffingwell) October 31, 2017 Who is the certifying agency? SAFe® Enterprise or the Scaled Agile Framework is the provider of this SAFe® 4 Agilist Certification. KnowledgeHut offers this course by professional trainers with years of industry experience. SAFe® Agilist certification exam cost? The exam cost for the first attempt is included in the course fee if the exam is taken within 30 days of course completion. Also, the candidate can retake the exam if not cleared in the first attempt and each retake attempt charges $50. Who will benefit from leading SAFe® 4.5 course? The following individuals will benefit from this course: Leaders and Executives, Directors, Managers, CIOs, and VPs Enterprise, System, and Solution Architects QA, Development, and Infrastructure Management Project and Program Managers PMO, Portfolio Managers, and Process Leads Product and Product Line Management Is it mandatory to attend the course or can a person just take the exam directly? Yes, candidates should have completed the 2 days’ Leading SAFe® 4.5 certification training course to take the exam. After successful completion, of course, your trainer registers you to Scaled Academy and after this registration, you will receive an e-mail that includes an exam link. Thereafter, you will have 30-days to take the test. What do attendees get from the course? The course registration includes: SAFe 4 Agilist PDF certificate SAFe 4 Agilist digital badge to promote your online accomplishment Comprehensive courseware materials by Scaled Agile Institute 1-year membership with Scaled Agile Access to members-only resources such as advance notice of upcoming SAFe products, guidance presentations, and webinars 16 SEUs and 16 PDUs 1 free attempt of the exam as the course fee includes the exam fee Can I cancel my enrollment? Do I get a refund? Your amount will be refunded in full only if the registration is cancelled within 48 hours and the refunds will be processed within 30 days of the request. For more details, check our refund policy. Note: Due to transactional costs that are applicable while refunding, all cancellations will cause a 5% deduction in the refunded amount. What topics are covered? The topics covered in our 2-day course are: Introducing the SAFe (Scaled Agile Framework) Embracing a Lean-Agile Mindset Experiencing PI (Program Increment) planning Understanding SAFe Principles Implementing an Agile Release Train Leading the Lean-Agile Enterprise Exploring, Executing, and Releasing Value Building an Agile Portfolio and Empowering a Lean Portfolio Prerequisites for SAFe® 4.5 Certification? Anyone regardless of experience can attend the course. But the following knowledge and skills are highly recommended for those who really want to take the SAFe® 4 Agilist certification exam: 5 plus years of experience in business analysis, testing, product or project management, and software development Good experience in Scrum What will I learn from the course? On completion of the course you will be able to: Apply SAFe to scale Lean and Agile development in your organization Identify and apply a Lean-Agile Mindset and principles Empower with a Lean Portfolio Improve your Lean-Agile leadership skills Continuously explore, integrate, deploy, and release value Coordinate the development of large value streams Support a Lean-Agile transformation in your organization How can I apply? Follow the below steps to apply for Leading SAFe® 4.5 certification exam- Step 1: Take the 2-day Leading SAFe®4.5 course Step 2: Your trainer will send all your details to Scaled Agile after successful completion of course. Now, the Scaled Agile Academy will send you two emails: a Welcome Letter and a Learning Plan Assignment. The Learning Plan Assignment e-mail includes information about the exam. Step 3: Take the online SAFe® 4 Agilist certification exam. Step 4: Once the test is completed with the minimum passing score, Scaled Academy will update your profile to disclose the certification. Step 5: You will receive an email including official notification from Scaled Academy which allows you to the member area and helps you to make your profile public within the Scaled Agile Community. 1-year membership with Scaled Agile will be provided as well. Why KnowledgeHut for Leading SAFe® 4.5? KnowledgeHut is a silver training partner of Scaled Agile Inc (SAI) and offers world-class learning to its students with excellence and provides in-depth knowledge required to become a successful world-class professional. KnowledgeHut also offers: Free materials from Scaled Agile Framework. Tricks and tips from our professional Certified Leading SAFe experts who have years of experience in implementing it in a variety of environments. 1-year membership with Scaled Agile included in the course fee. We hope this article cleared all your queries related to SAFe® 4 Agilist certification. Connect with us to know more about the Leading SAFe® 4.5 course.
Rated 4.0/5
based on 14 customer reviews
All you need to know about Leading SAFe 4.5® Certification with KnowledgeHut
111
69
Agile Management
Agile is a project management process which encourages self-organization, accountability, and teamwork. This methodology progresses a moderate project management process by reducing the time required ...
Continue reading
Patterns For Adopting & Spreading Scrum In Organizations
By Ridhi Chhabra
When we talk about adopting any new framework or methodology, we think about how we can incorporate these changes into our organization. We simply cannot impose any change in our organization and get started with it, there has to be some process or ways to incorporate that. Also, there are some ways to incorporate Scrum changes within our organization. There include five activities in adopting the Scrum successfully: Awareness Desire Ability Promotion Transfer So to remember, we call it by the acronym ADAPT. Let’s now talk about the Patterns of Adopting and Spreading a Scrum: Patterns for Adopting Scrum Start Small or Go All In Organizations go ahead with it like a Pilot project, like selecting few team members and implementing Scrum with them, It's a ‘Start Small’ pattern. The other approach can be Go All In, which is like the executives are convinced and want the whole organization to implement in one go. Reasons to prefer starting small It’s less expensive Early success guaranteed Avoids risks of going all in Less stressful Can be done without much change Reasons to prefer going all in Reduces resistance Avoids problems within different teams The All-in transition is Quick! Choosing between the two As recommended by Mike Cohn, one should always Start Small! It involves less cost, and guaranteed early success. Going all in should be in limited cases, only when it’s a quick need. Also, it involves more cost/money as there are a lot of changes in different departments if required. Public Display of Agility or Stealth The next pattern that comes into the picture is whether to Publicize it or not. We can do the Public Display of Agility. In this approach, the organization announces that it is adopting Scrum. This can vary from announcing it in a meeting room to announcing it through the press release. The other approach is Stealth transition. In this, only team members know they are using Scrum until the project is complete. Reasons for Public Display of Agility Everyone knows that team is doing it and they are more likely to be focussed Operating publicly is a firm statement of commitment You can solicit organizational support It sends a powerful message Reasons for Stealth Transition A chance to make progress before resistance starts It keeps pressure off No one knows until you tell them If no one knows, no one can tell you to stop Choosing between the two As recommended by Mike Cohn, always choose to make a public display of Agility when you are confident and committed to the transition and when you expect a lot of resistance but want to overcome it quickly. In contrast, choose a quiet approach, when you want to do an experiment using Scrum. Patterns of adoption: "Going Through the Scrum Motions as Opposed to Being an Agile Jedi " https://t.co/tpv9kIVxNU @MichaelNir (via @InfoQ) — Stefan Wolpers (@StefanW) May 16, 2016 Patterns for Spreading Scrum Getting started with Scrum is one thing, spreading it across the organization is another. Unless you choose an all-in transition, you will need to build upon the successes of the first few teams as you move Scrum to other teams. There are 3 general patterns given by Mike Cohn that talks about spreading Scrum. Split and Seed This talks about taking a team that has begun to be successful with Scrum and using its team members to seed new teams. It’s typically put to use after the first few teams have successfully implemented and adopted Scrum. By this time, each team member understands how Sprint work and how the ready software is delivered at the end of the sprint. In Split and Seed pattern, we split one functioning Scrum team into each half of the original team forming the basis of the new team. New people are then added to these split teams to form new Scrum teams. A large initial team is used to seed as many as four new teams. Collated below are the reasons to prefer Split and Seed pattern. Add teams more quickly Each team has someone with Scrum experience to guide them Grow and Split The Grow and Split pattern involve adding team members until the team is large enough that it can be comfortably split in two. Immediately after splitting, each of the new teams will probably be on the small end of the desirable size ranging five to nine members. After allowing the new teams one sprint at this reduced size, new members are added until each team becomes a large enough that it can also be split. This pattern repeats until the entire organization has transitioned. In following cases, you can prefer Grow and Split pattern. Don’t have to destroy any existing teams Team members feel more continuity from sprint to sprint Internal Coaching The Third pattern of Spreading Scrum is Internal Coaching. In the organizations, there include types of teams. Some teams excel with the new agile approach, while others struggles. On each team, there exists one identified person who understands and implement Scrum successfully. That person is assigned as a Coach for other teams. Coaches were given responsibilities to attend sprint meetings, daily scrum each week and coach other teams. Reasons to prefer Internal Coaching Well running teams do not need to be Split Coaches can be selected for new teams Coaches can move from team to team Choosing your Pattern! In general, consider going with Split and Seed pattern, when in a hurry. It is the fastest way of spreading Scrum. However, if the technology doesn’t support moving people among teams, changing the team members can affect the productivity. The Grow and Split pattern is simply more natural and direct approach. Consider using this approach if there is no sense of urgency as it is less risky. Internal Coaching can be used on its own, mostly when the group is large enough and when splitting teams are not possible for the projects.
Rated 4.0/5
based on 13 customer reviews
Patterns For Adopting & Spreading Scrum In Organizations
114
67
Agile Management
When we talk about adopting any new framework or methodology, we think about how we can incorporate these changes into our organization. We simply cannot impose any change in our organization and get ...
Continue reading
The Role Of a Project Manager in an Agile Environment
By Mkateko Shibambu
Let us first understand the Project Manager’s role in a traditional/waterfall environment. The PMBOK (Project Management Body of Knowledge) Guide - 4th Edition states that a Project Manager is known to be responsible for successful implementation of a project through the five stages/processes of a project lifecycle: initiating, planning, executing, monitoring and controlling, and closing the project – see figure 1. Included in these phases is identifying requirements, management of stakeholders and balancing the competing project constraints arising during the project. The project constraints include the: Scope, Quality, Schedule, Budget, Resources, and Risk An effective Project Manager is required to be knowledgeable about Project Management, apply this project management knowledge in order to drive their performance and that of their team, and have positive personal attitude as it will be spread out to the project team. These are key characteristics of an effective Project Manager. The Role of the Project Manager in an Agile Business https://t.co/NNVUV0lT4C via @BrightTALK #projectmanagement #agile pic.twitter.com/DdMBYMIq2A — Capterra Project (@CapterraPM) March 1, 2017 PRINCE2 (PRojects IN a Controlled Environment version 2) is another waterfall methodology and states that the project management project lifecycle and processes are: starting a project, initiating a project, directing a project, managing a stage boundary, controlling a stage, managing product delivery and closing a project – see figure 2. A Project Manager is responsible for ensuring that the team performs and delivers the product accordingly as initially defined with Management ( the Project Board). The Project Manager also ensures that there is clear requirements communication between the project board and the project team to ensure quality delivery. The Agile methodology seems to be emerging very fast with most organisations requiring to do away with waterfall and utilize Agile rather. For some organisations, Agile has proven to work well in the sense that implementation happens timeously in small chunks of releases instead of a big-bang implementation that has a high probability of failure if other detailed risks and issues are missed. The stages of Agile product development life cycle include: requirements gathering, planning, design, development, release, and track and monitoring. Agile aims at releasing small chunks of the full product in sprints (popularly defined in a two week period) rather than a big bang full release. The cycle is iterated until the full product is developed and released. I have worked in a fully waterfall environment, as well as waterfall but being so-called Agile, and I am currently working in a seemingly fully Agile environment. There are different roles in this fully Agile environment of which they include: Project Manager, Product Manager, Product Owner, Scrum Master, and others. These roles are a combination of waterfall and Agile roles although we call ourselves fully Agile. We – as a team call our environment fully Agile, absorbing this information from our organisation’s Senior Management, who manage appointment of these roles. A Project Manager works very closely with top management for strategic decision making. A Project Manager still maintains the role of being the sole responsible person for successful implementation of the quality defined product, and also supports the team throughout the iterations and shield them from distractions. Although there are different frameworks in Agile, the roles within Agile do not differ much, for example, the role of a Scrum Master. A Scrum Master works very closely with the Project Manager to close the communication gap between the project team and top management. A Project Manager manages project/product risks while the Scrum Master manages the team’s performance and impediments. In waterfall, a Project manager works very closely with the delivery team while in Agile, the Project Manager works with the team indirectly – managing team communication through the Scrum Master. Although the Project Manager is responsible for successful release of a quality product, the Scrum Master is the one that manages the delivery of this quality product while working with the delivery team, since the Project Manager does not communicate directly with the delivery team. The Project Manager manages time delivery more than quality. The Scrum Master manages quality delivery of the product. The Scrum Master also manages impediments as well as the development/delivery team while the Project Manager manages risks and address them with strategic management. Then the question arises, do we still need Project Managers in Agile? Although there is no Project Manager role in any Agile methodology, in real work life environments, we still have Project Managers. To differentiate the two roles, both are responsible for delivery of a quality product. However, a Project Manager works strategically with the management team (project sponsor, project owner/requestor, etc.) to define the product’s epics, while the Scrum Master receives management defined epics from the Project Manager and work with the delivery/development team to break-down the epics into features, stories and tasks. A Scrum Master also manages impediments from at development team level and resolve what is possible in his capability. Impediments that are rated high are now channelled to a Project Manager to be managed strategically by the management team. Although organisations that are going Agile see a need to diminish Project Managers’ roles in their organisation, it will be challenging as there is also still a need to understand roles like Product Manager – which is a strategic role as well and might at times overlap with the Project Manager role, if they work together in a team to deliver the same product. Are Project Managers still required in Agile? According to my opinion and how things are working out in my organisation, my answer is actually yes! Project Managers are still required and must work closely with the Product Managers and Scrum Masters. Although there can be a confusion which can cause conflict of responsibilities between a Project Manager and Scrum Master at times. Figure 3 illustrates clarity of the Project Manager and Scrum Master roles.
Rated 4.0/5
based on 12 customer reviews
The Role Of a Project Manager in an Agile Environment
104
64
Agile Management
Let us first understand the Project Manager’s role in a traditional/waterfall environment. The PMBOK (Project Management Body of Knowledge) Guide - 4th Edition states that a Project Manager is k...
Continue reading
Best Ways To Split User Stories For Efficient Product Backlog Refinement
By Nidhya Palaniappan
Product Backlog and User Stories: Product Backlog is an essential artefact of Scrum Framework. It comprises of a list of items (referred as PBI) that are planned to be implemented in the future. PBIs are generally in the form User Stories. A user story is the concise representation of a functional or technical requirement of a system. Writing appropriate user stories forms a strong base for achieving the sprint goals successfully and progressing towards the product vision eventually. "If you want to know more about a 'user story' you may also watch“ INVEST The attributes of a well formed user story goes by the acronym INVEST, which was coined by Bill Wake in his book "Extreme Programming": Independent - Each story should be atomic and not dependent on any other stories Negotiable - Should have scope to allow negotiation between the scrum team and business team on the grounds of technical , functional and budget constraints and modify itself accordingly Valuable - Must deliver some value to the stakeholders. If it is a functional user story, then there should be provide some business value , whereas technical user story should focus on architectural and non functional improvements. Estimable - Team should be able to arrive at a fair estimation for implementing the user story in terms of story points. Small - Should be small enough to plan and implement within a sprint Testable - Should have a clear acceptance criteria , which gives the team all the necessary information to test every possible flow. Product Backlog Refinement Product owners have to maintain a healthy backlog by frequently grooming the user stories in it. In the grooming sessions (Product Backlog Refinement), PO discusses with the team and work on improvising the poorly written user stories, breaking down the large user stories into manageable size, adding more clarity to the acceptance criteria , prioritizing the user stories and estimating them. As a Scrum Master, we should guide the team and PO in this backlog refinement activity by aiding them with the best practices in writing user stories of right size and prioritization. User Story Splitting Splitting user stories is a significant task in product backlog grooming. A user story should be neither too small nor too big. It has to be sized appropriately , in such a way that , the implementation of it could be decomposed into one or more tasks. All the tasks planned must be completed within a sprint. Generally , user stories of size more than 8 or 13 story points are split further. However this number may vary from one scrum team to another based on their capacity and velocity. Benefits of splitting a story: Smaller is always better. User stories of relatively less story points are * Easy to understand and groom * Leads to accurate estimation * Results on quicker implementation * Aids thorough testing Size of an user story is said to be optimal if it could be implemented within 0.5 day (half a day) to 10 days. Methods of splitting : A user story can be split: Horizontally - through architectural tiers as one layer at a time Vertically - as functional pieces across all the layers at a time. The horizontal layers split accordingly can be further divided as tasks. A common metaphor used to differentiate both these methods is cutting a cake layer by layer ( horizontal) and portion by portion of all the layers (vertical). Only by tasting a portion of all the layers, one would be able to feel the essence of the entire cake. Same is the case with story splitting. Vertical (Functional) splitting is more valuable than the horizontal one. Advantages of vertical splitting: Dependencies and risks could be identified at an earlier stage Nice to have features can be segregated and deferred for later sprints Considerable progress can been seen on functional part every day, whereas in horizontal slicing no benefits are seen until all related stories are complete Leads to quicker testing and faster feedback loop - in horizontal , need to wait until all the dependent stories are done Helps to prioritize based on incremental value Techniques for splitting stories vertically: User stories can be split vertically based on the following patterns: Generic Terms: If an user story has more generic terms, then there is a possibility to split it vertically. For eg : As a library member, I want to search the availability of various kinds of books for children and share it with my network. Here, "various kinds" , "share it" are more generic terms. They provide a way to split the story incrementally as below : * Develop a UI that displays all the book categories when a registered library member login * Provide a search functionality to the member, where in results are also categorized such as "fiction for kids under 10", "fiction for kids 11-15" and so on * Enable to users to share the result via email, whatsapp etc Connectors : If the user story is represented using a compound sentence, then it is obvious that it can be split vertically. In such cases, look out for conjunctions in the user story like "and, or, as well as, when, if" and split it based on these connecting words or conjunctions like : and, or, if, when, but, as well as. Acceptance criteria: Read out the acceptance criteria; if it is too complex and some parts of it can be pulled out and developed as an independent user story, follow the same. Eg: As a senior associate of the organization, I want to register for the in house training programs so that I can attend the trainings and upskill myself. Acceptance criteria : All the senior associates must be informed about the training programs through mail. Senior associates should be able to submit their details through a form for registration. Mail confirmation must be sent on successful registration. In the above scenario, each of the criteria can be designated as a separate user story. Workflow steps: Identify the workflows that connect different roles for a specific function, and if they can be completed independently split them as a separate user story. Eg: For an assignment approval system in a school, the following can be the possible user stories As a student, I should be able to submit my assignments to the teacher for grading As a teacher , I should be able to view the assignments submitted by the students As a teacher, I should have the UI to request for more clarifications Apart from the above, below are the other patterns based on which user stories can be split vertically: Operations - Create, Read, Update, Delete operations required for a functionality Business Rules deviations Variations in Data given as input to the system Variations in User Interface Spikes - If there are many unknowns in a user story and it requires research for uncovering the grey areas, then create spikes to get the insights of the user story. Based on the spike's outcome, we can proceed with the implementation of actual user story. Best practices for story splitting: * Do not split the stories too early - split just in time, when it's priority for implementation is high. * Do not compromise quality / non functional requirements - NFRs must be taken into consideration while splitting. If having a choice between a couple of user story splitting strategies, prefer the one that will result in similarly sized sub-stories. — Wojciech Zawistowski (@velesin) May 29, 2015 * Ensure that there is no feature debt - splitting should not leave out any functionality without implementation. * Story splitting is not a task to be owned by the PO alone - Along with the Scrum Master, other team members also give their view on best possible ways to split the stories as they are the actual persons who are going to develop the stories into working functionalities.
Rated 4.0/5
based on 16 customer reviews
Best Ways To Split User Stories For Efficient Product Backlog Refinement
109
63
Agile Management
Product Backlog and User Stories:
Product Backlog is an essential artefact of Scrum Framework. It comprises of a list of items (referred as PBI) that are planned to be implemented in the future. PB...
Continue reading
"The Escutcheon Workshop" - PART 2 : Kanban Journey for the Infrastructure Operations Support and Service Teams
By Badri N Srinivasan
In my previous post, I had explained what is Kanban and how to view it in the context of Infrastructure Operations Support and Service . Before we start the implementation of Kanban for a specific Operations Support and Service Team, we need to identify the team composition and work out its team structure. This will help us to implement Kanban effectively for the team. This process is known as team design and it is considered as a part of the organizational design (OD). When we identify and form a team, we generally identify different support/service skills that the team should possess so that they can undertake the complete support/service for the customer. For e.g. if a single team is expected to provide network support services to the customer, the team should ideally have skills in L0, L1, L2, and L3 support. This ensures end-to-end support for the customer as a single ticket that can be resolved by one team instead of the customer depending on multiple teams (L2 – one team, L3 – another team and other multiple teams, where applicable) to complete his ticket and request. Each member identified at a particular level of support is skilled in their job and the skill level increases as the level move up. Each level has more experience and education. The different service levels are – L0 – Basic resolution of issues through call resolution. Take the help of knowledge base to manage issue resolution. L1 – Product Demo and basic troubleshooting including specific call resolution. Deal with physical connections and hardware. Basic network design - from about 30 to about 500 network point design. Basic project management skills. L2 – Resolution of Technical problems. Focus on medium to large network design. 500 to about 2000 network point design. Intermediate project management skills. L3 – Resolution of Major problems. Root cause analysis of problems with updations to the knowledge base. Design Experts and Data Center specialists with project management skills. Focus on 2000 to 30000+ network point design and familiar with high-end network equipment (CISCO/JUNIPER/Other Brands). The network support services could be in the form of network design, installation, support and maintenance. Additionally, the levels – L0, L1, L2, and L3 could vary in different organizations depending on the type of services being offered by the organization to the customer and the type of terminology used. We may also have additional or fewer levels depending on the focus of the organization. However, at a broad level, the above classification could be used to categorize different types of operations support and services in an organization. There are two types of team design that can be observed in an organization – teams that are exclusively made up of only one type of skill level, e.g. L2 support, L1 support. This is the component type team design. Teams that are made up of the complete stack of support services provided – A single team having L0, L1, L2, and L3 skills. This is considered as the feature type team design where like a feature team, the operations support/service team provides complete end to end support to the customer (A feature team is a team that has all the skills needed to support the customer requirements and delivers the features to the customer). As organizations focus on agile and Kanban implementation for their teams and also emphasize imbibing the aspects of Spotify Engineering Culture (a culture that focuses on not having a hierarchical structure and which focuses on host and servant leadership), the attention is on forming teams that have end to end skills to resolve all the customer issues. Hence, the focus on full stack operations support/service teams. Earlier, a team member used to have specific skills and built his skills in that area only, e.g. L2. This was the T type skill focus. Now, we have the PI type skill focus where a team member is expected to be an expert in at least two areas – e.g. L2, L1 and also have knowledge in other areas. It is acknowledged that there are constraints that need to be overcome to reach this level but it is expected that in the future, the demand will be for full stack skills (L0, L1, L2 and L3) from a single team member. This implies that a team member has all the skills necessary to deliver the service/support to the customer without having to depend on another member or wait to seek help from another member. There are multiple constraints that need to be overcome in order to reach this state and organizations are facilitating this transformation that may happen over a period of time in the future. This will further strengthen the Operations support / service teams structure and delivery to the customer in the future. After the skill matrix and the team members are identified to form a team, one of the members of the team is identified as a Kanban Master. He is responsible for facilitating the implementation of the Kanban practices and process for the team along with the help of other non-team members like an Agile Coach, Center of Excellence, Continuous Improvement team and other teams (e.g. training), where applicable. Generally, we have an initial kick-off workshop for the newly formed team which I call as the Escutcheon workshop. An Escutcheon (as per the Oxford English Dictionary) is defined as – An emblem or shield bearing a coat of arms or a flat metal piece that is used for protection and also ornamentation around a keyhole, door handle or light switch. The analogy with Escutcheon reminds us of the concept of the team subliminally forming a protective boundary for the team members and which helps the team members to undertake their daily work and take the help of other team members when stuck and ask for help when they are not able to resolve any issue. The team is also having a team name which gives an identity to the team, improves team bonding and which is similar to the coat of arms on a shield that bound fellow kinsmen during the olden times. The output of the workshop is also a diagram in the form of an Escutcheon. Hence, the term Escutcheon. This, of course, implies that the team members exhibit team member characteristics like trust, courage, transparency and other traits so that the concept of a team can be established and sustained in the future. Additionally, this does not mean that the team members can only ask for help from any other member within the team. They are free to also ask for help from any other member in the organization for additional ideas for issue resolution. A typical output of an Escutcheon Workshop for a Network Operations Support / Service Team is given below - Are you interested in learning more about Lean manufacturing? April 5th kicks off our Pull / Kanban System and Total Productive Maintenance Workshop! #TPM #PullKanban #Lean Learn more at https://t.co/I0gGUIU4UP pic.twitter.com/c6cfFI7WYx — IMEC (@IMECillinois) March 12, 2018 This network operations team is tasked to support network usage and monitor the performance of the network apart from other routine support / service activities. Hence, this becomes the important tagline or punchline of the team. The key words of the team focus on data, usage and performance (with respect to the network). The team emphasizes collaboration and creativity as key focus areas which will help them in their day to day activities related to network support and service, apart from other focus areas. The team calls themselves as “Network Tigers” and which is ready to support any network issue end to end within their scope of operation pertaining to network support and service. They adopt the logo of a Tiger Face which gives the team an identity to focus, bond and celebrate their successes and wins and support each other during lean periods. Thus, the Escutcheon workshop helps the team to establish a facade (principal front face) to the customer as a single point of contact to help them for all their issues related to their network and help to resolve them end to end in the shortest possible time and with the highest quality. The team members keep improving their skills to meet this commitment to their customer and learn from their mistakes, adopt continuous learning and implement the lessons learnt from their projects to further strengthen their skills to match and exceed the customer expectations. Hence, we have now established a full-fledged Operations Support / Service team having all the skill sets that are needed to address the queries, issues and tickets raised by the customer related to their network. Now the team needs to implement, establish, nurture, sustain and institutionalize Kanban values, principles and practices in their team to enable and facilitate the team to enhance customer delight and improve the quality of delivery. In the upcoming Posts, I will focus on the next step in the Kanban journey as we learn how to implement Kanban for the Infrastructure Operations Support and Service teams – both at the team level and at the scale level (when we integrate multiple teams at scale to deliver support services to the customer). 
Rated 3.0/5
based on 1 customer reviews
"The Escutcheon Workshop" - PART 2 : Kanban Journey for the Infrastructure Operations Support and Service Teams
116
89
Agile Management
In my previous post, I had explained what is Kanban and how to view it in the context of Infrastructure Operations Support and Service .
Before we start the implementation of Kanban for a spe...
Continue reading
We’re in Agile, We don’t Plan! Really?
By Ridhi Chhabra
‘We are in Agile, we don’t plan!’ This was one of the most common statements in early Agile implementations. Many people in early Agile implementations took this step, knowing that they were giving up something really valuable. However, there was a natural reaction to this. This is now considered as a common myth, as planning is a fundamental aspect of Scrum. The Scrum team is committed to working towards the working software delivery with the highest value. To implement this, the team and Product Owner must have an estimate of the feature, cost for development. Intelligibly, a Scrum team is committed to working according to prioritization. Hence, Planning is an essential practice! In fact, We Plan a Lot! Sprint starts with an event called Sprint Planning The next step in planning is when the Scrum team estimates and commits to working towards the delivery of potentially shippable product at the end of the Sprint. Scrum team comes up with a detailed plan of- How much are they estimating, that they will complete within the sprint? How much will be the cost/value/hours of the tasks to be delivered? Planning happens on an everyday basis The Daily Scrum for the Scrum Team is to review the progress and refine the plan to meet the Sprint Goal. Plan on what is to be done Plan on overcoming the impediments How successful is your sprint planning? https://t.co/PTyozdqh7L @kbondale looks at 4 common challenges which impact this critical ceremony #agile #pmot #sprintplanning pic.twitter.com/2xS9a0zC34 — Agile Alliance (@AgileAlliance) March 28, 2018 Scrum Teams Own the Plan In each event, we are “Inspecting and Adapting”, Scrum teams takes the Product Backlog and come up with their plan and create their own Sprint backlog. They create it, inspect it and then adapt it for upcoming sprints and better results. Sprint Review and Retrospectives are the part of the Plan The Sprint Review is a collaborative event where the whole team gathers, reviews the product increment created, comes up with a feedback and adapts to make changes. This all is to support the planning of the next Sprint. The Sprint Retrospective is again a collaborative event to enable and plan for continuous improvement. Team plans to start, stop and continue doing the things in the current process. Progressively Refine Plans The Product Backlog should be progressively refined. It should be broken down into small user stories which can be easily implemented as we move along with the project. Eventually, the similar approach is to be taken while planning in Scrum. Let’s have a look at the advantages of having a progressively refining a plan in Scrum- It minimizes the time investment: Planning is important, but it can be time-consuming. The time spent in estimating and planning is best viewed as an investment. It allows decisions to be made at an optimal time: Progressively refining the plan helps the team avoid falling into the trap of making too many decisions at the outset of the project. It allows us to make course changes: One thing we know, when we are in Agile, that change always happens. Planning enough that we know in general but not all the aspects leaves the team with the flexibility to alter the course as more is learned. It helps us avoid falling into the trap of believing our plans: No matter how well we understand the expectations, and that no plan is safe from change. Progressively refining a plan reinforces the idea that even the best plan is subject to change. So, when next time you say, We’re in Agile, We don’t plan! Really? Think about it! 
Rated 4.0/5
based on 1 customer reviews
We’re in Agile, We don’t Plan! Really?
115
69
Agile Management
‘We are in Agile, we don’t plan!’ This was one of the most common statements in early Agile implementations. Many people in early Agile implementations took this step, knowing that t...
Continue reading
SUBSCRIBE TO OUR BLOG
Share Blog
POPULAR TOPICS
Follow Us
TRENDING BLOG POSTS
The Evolution Of Kanban: A Study Of The Principles & Practices
By Leon Tranter
As a part of the overall move towards Agile software development and related disciplines, many people are interested in Kanban. Some are applying it as a part of Agile, others are looking into it as an alternative to Scrum. There is a lot of confusion about this simple yet effective tool, so this article will clear up these misconceptions and provide a quick crash course into the essentials of Kanban. Where did Kanban come from? Kanban originated in Japan in the 1940s. People from the Toyota car manufacturer noticed that supermarkets used a simple but effective system based around small physical cards to indicate when something was out of supply or needed to be ordered. They applied this system in their own manufacturing process to help visualise work and control flow. Kanban became a part of Lean Thinking and the Toyota Production System. It was later popularised amongst software developers in 2010 by David Anderson with his book “Kanban: successful evolutionary change for your business”. What really is Kanban? Kanban is a simple but powerful system for visualising and managing work. It is not just related to software development, in fact, it is not specifically related to development of any kind. It can be used in a restaurant, a supermarket or a car factory. It has four principles and five practices. As opposed to Scrum, which involves revolutionary change, Kanban is about evolutionary change, starting from right where you are now (in fact, that is one of the fundamental principles: start off by changing nothing whatsoever! You won’t find any organisation on earth that will resist that change). It is fundamentally about visualising work and then finding ways to improve the flow of work through a system. Nice visualization of the Kanban principles and practices pic.twitter.com/WbDMSoRfk5 — maciej sowiński (@maciej_sowinski) January 13, 2016 The Four Principles of Kanban This section will discuss the four fundamental principles behind Kanban. They are all essential to understanding and implementing the practices. Fortunately, they are simple and can fit into any organisation or system. Start with what you do now As mentioned, Kanban is a method for gradually improving an existing workflow or system. So you start with whatever you are doing now - whether simple or complex, big or small. You can use Kanban alongside or on top of any existing framework or system you are using - Scrum, Waterfall (yes Waterfall!), or anything, really. Many people believe they have to choose between Scrum or Kanban - untrue! You can use them together. Agree to pursue incremental, evolutionary change As opposed to systems like Scrum or Extreme Programming, that start out by fundamentally changing the structure and behaviour of organisations, Kanban is about evolutionary change, one small increment at a time. This can make it well-suited to cumbersome organisations that resist large risky changes. Respect the current roles, responsibilities, and titles Kanban doesn’t start off by renaming people or inventing strange new roles. Everyone gets to keep not only their job but their job title too. This further helps resistance to change. Encourage acts of leadership at all levels This is a subtle but very important principle. Improvement is the responsibility of everyone in the organisation, from the CEO down to the receptionist. You might get to keep your current job title and responsibilities, but you also now have an additional responsibility: leadership, which is really about empowerment and improvement. The Five Practices of Kanban Unlike Agile, which only has values and principles, Kanban has actual practices that you can employ, starting from day one. Visualise the workflow This is the most important step in all of Kanban, and is at the core of the whole system: visualising work. This was trivially easy to do in Toyota car manufacturing plants: the work was cars lying around in various states of semi-construction. For knowledge work like software development, marketing or design, it is much harder to visualise. This can let work accumulate and create huge blockages without anyone being aware. So visualise the work! This will make it easy to see where work is piling up and where problems and bottlenecks are. The best way to do this is on a physical board, using tokens such as index cards or post-it notes. Putting the work in an electronic tool might seem convenient but when the computer is switched off or minimised, the visualisation of the work is gone. The bigger and more physical, the better! You want to aim for information radiators (that push information out to the organisation) rather than information refrigerators (that preserve information away from people’s eyes). The most common way to visualise the work is with a Kanban board that has vertical swimlanes to represent states of work. You can then place cards on the board to represent the actual work item. Here is an example of the simplest of Kanban boards, with lanes for To Do, Doing and Done: Here is another example of a board, this time with some extra lanes, numbers that indicate Work in Progress Limits, and cards marked as being Blocked. Limit WIP Limiting WIP (WIP stands for Work In Progress) is another key practice of Kanban. People often think that we want to maximise work in progress - that means everybody is busy and lots is getting done, right? Well, if you have lots of WIP, then everyone will probably be very busy, but that isn’t really valuable. We want work in a Done state, not in a “Doing” state. And the best way to ensure that is to actually REDUCE the amount of Work in Progress! It might sound counterintuitive, but it is true. Lots of WIP means lots of handoffs, queues, bottlenecks and task-switching. This all means not much getting actually Done. Minimising WIP means you can maximise flow, which maximises the amount of work Done. And that’s the true goal. Manage Flow Kanban focuses on reducing WIP in order to maximise flow. If you want lots of work to get to Done but don’t want lots of work in a Doing state, you have to reduce the amount of time it takes for work to go from Doing to Done. This is called Cycle Time. Kanban practitioners have many tools they can use to improve flow and reduce cycle time, and these will often become clear after you have visualised the work. They include eliminating approvals and handoffs, swarming on complex slow tasks, identifying bottlenecks, putting WIP limits on Kanban lanes, reducing wait time between tasks, and reducing queues. Make Process Policies Explicit As you implement new rules and policies to improve flow, ensure you make these explicit. If you have a Definition of Done, get people to agree to it and publish it. If you change the rules about approving a document, make sure this is understood and explicitly described. Improvements will fall away and get misused if they are not clearly articulated and understood. Improve Collaboratively, Evolve Experimentally Improving is a collaborative team effort, not something randomly forced on people by some arbitrary management edict. It should be implemented by teams in an iterative experimental effort. Teams need to feel they are in an environment where experimentation is encouraged and it is “safe to fail”, or nobody will try making genuine changes. I hope you have enjoyed this crash course in Kanban - many people are using this system to great effect. If you want to know more, I would recommend the books Kanban by David Anderson, or Kanban in Action by Joakim Sunden and Marcus Hammarberg.
Rated 3.5/5
based on 4 customer reviews
The Evolution Of Kanban: A Study Of The Principles & Practices
Agile ManagementHow To Earn More PDUs After The Completion of PMP Certification
By KnowledgeHut Editor
Are you a PMI® credential holder? Do you also hold a PMP® certification? Then this article will be useful for you! All PMI® certifications except CAPM® certification (Certified Associate in Project Management), need holders to string along with the Continuing Certification Requirements (CCR) Program. The aim of this program is to ensure that your skills and certified capabilities are up-to-the-minute. Generally speaking, it involves earning PDUs as well. PMP® Certification- If you are planning to take the PMP® training, it will be worth the cost and your efforts. Various industries use PMP® as a standard for project managers. PMP® certification entitles you to work in any environment and with any methodology. The PMP® certification covers the various project management techniques and skills that are essential for project managers. The PMP® course creates your impression as- It indicates your superiority in using the PMBOK® guide It indicates that you know the best practices for project management Salary of the PMP certified- According to the 10th edition of Project Management Salary survey by PMI®, it is estimated that the PMP® certified project manager is getting more than non-PMP certified project managers. The average annual salary for a PMP® certified professional is $108,200 per year. They earn 20% more than the non-PMP® certified individuals. Here is the salary report of the PMP® certified according to PMI® report. Once you have sailed through the PMP® exam, your 3-year PMP® re-accreditation cycle starts. You need to earn at least 60 PMP® PDUs with a specific end goal to effectively renew your PMP® accreditation. Usually, 1 PDU is equivalent to 1 hour of PDU activity participation. But, there are points of confinement to certain PDU activities. We will see ways to earn more PDUs in details. But before that, let’s know what is PDU? Do you know? 1 PDU equates 1 hour of PDU activity participation What is PDU? A PDU is a Professional Development Unit. Once you earn your PMP® certification, the next step is to maintain the PMP® credential. This credential is valid only for 3 years. So to renew the certification, you need to report 60 PDUs to the PMI® before completing the third year. If missed to renew, it leads to suspension of the certificate. Ways to earn PDUs- Earning PDUs for PMP certification is a hassle-free and less expensive process and some PDUs can be earned free of cost. PDUs can be earned in two ways- A. Free PDUs B. Paid PDUs A. Free PDUs Free PDUs are categorized into 2 sections, 1) Education PDUs: Education PDUs can be earned in following 3 ways- Online or in-person courses and training offered by PMI’s Registered Education Provider (REPs) Continuing Education (professional meetings and local events) Self-driven learning From Education PDUs, you can earn maximum 35 PDUs. Out of 35 PDUs, 8 PDUs consists of technical Project Management skills + 8 PDUs in Leadership skills + 8 PDUs in strategic business management skills. These 3 skills-sets are referred as a ‘PMI Talent Triangle’ by PMI®. 2) Giving back PDUs: Giving back PDUs includes the sharing of knowledge and applying skills to contribute to the profession. This includes- Creating knowledge Giving a presentation Creating content Working as a practitioner Sharing knowledge Volunteering From giving back PDUs, you can earn maximum 25 PDUs, but only 8 PDUs can be earned as working as a practitioner during 3 years. B. Paid PDUs Paid PDUs is another way of earning PDUs after PMP® certification. The second way consists of not only gaining the project management knowledge but also earning more PDUs. This way of earning PDUs is more effective than the free PDUs in terms of gaining PDUs too early. Also, this enhances your skill-set along with the PDUs. Really looking forward to the discussion on maintaining my PMP certification @pmiirl — Joanne Cronin (@dudara) July 6, 2017 Has it come to your notice? Paid PDU approach is more effective than the free PDUs, as it not only acts as a skill enhancer for an individual but also helps in earning PDUs too early. Here are some of the Project management related courses that can help learn more about project management and earn more skills. 1) PRINCE2® course: You can earn 16 PDUs from this course. PRINCE2® (PRojects In Controlled Environments) is a Project Management methodology that allows you to handle any complex project in a diverse environment. This method is practiced worldwide and the certifications are considered authentic if the training institute is an Accredited training organization (ATO) of PEOPLECERT and a certified partner of Axelos. 2) ITIL® course: You can earn 25 PDUs from this course. ITIL® training provides understanding of the project related best practices and implementing these practices to streamline the processes for continuous improvement. It is highly recommended that you take this course from the institute which is an Accredited Training Organization (ATO) of PEOPLECERT and a Certified Partner of Axelos for ITIL® Trainings. 3) PMI-ACP® course: You can earn 21 PDUs from this course. The Project Management Institute- Agile Certified Practitioner (PMI-ACP)® is a widely accepted certification in the Agile community. This course shows the competency of an individual in carrying out a project in any circumstances using Agile practices. For this course, select the institute which is a Registered Education Provider (REP) of Project Management Institute (PMI®). Being a PMI® member, if you are PMP, PfMP, PgMP, PMI-PBA certified then you need to earn at least 35 PDUs from Education Category, 25 PDUs from Given back to the profession category 8 PDUs from each category of Talent triangle. Also, you can grab maximum 8 PDUs from ‘Giving back to the Profession’ by ‘Working as a Practitioner’ and all 60 PDUs from education category. Do you know? PDUs can also be earned by watching recorded webinars from projectmanagement.com. These PDUs will get recorded under the ‘PDUs awarded section’ on your account page. Hence , no need to report them separately. PMI membership comes with professional membership of project management.com. Future Demand for PMP professionals- According to the Project Management Institute®, the demand for project management professionals will explode by 2020. Below is the graphical representation of the new job vacancies worldwide for project management role. Bringing it all together PMI® is a registered trademark of the Project Management, Inc. and PMP® and its logo are accredited features of the Project Management Institute (PMI®) which are enrolled in the US and other countries. You need to keep in mind that your PDUs can be examined and you could be asked to provide justification of your learning any time. So, it is better to earn your PDUs only from accredited organizations. There are various genuine ways to learn, create and claim PDUs to stand out in the market. I hope this information will help you in earning PDUs the way you want!
Rated 4.5/5
based on 5 customer reviews
How To Earn More PDUs After The Completion of PMP Certification
Project ManagementPeak with PMP: Reach New Heights With KnowledgeHut’s Top Courses
By KnowledgeHut Editor
Project management professional certification is one of the most reputable certifications across the globe that proves your efficiency and productivity in project management in your workplace. One should meet the following criteria in order to receive the certificate: Secondary degree holders: Should have at least 5 years of experience in project management, with 7,500 hours in leading projects and 35 hours of project management education. Four-year degree holders: Should have at least 3 years of experience in project management and spent 4,500 hours in leading projects and 35 hours of project management education. If you fulfill the above PMP credential requirements then you can apply for the PMP certification online at https://www.pmi.org/. But, ensure you make a well-defined study plan that helps to complete your PMP certification process successfully. The 35-hour project management education program is the crucial factor for your success. Opting the course from a Registered Education Provider like KnowledgeHut can help you build the foundation for the exam by equipping you with the knowledge of PMBOK (Project Management Body of Knowledge). This training program will not only make a candidate eligible for PMP exam but also provide ample insights to shoot your target. Schedule your PMP certification exam on successful completion of the course. The exam consists of 200 objective-type questions which need to be finished within 4 hours. And, you need to answer a minimum of 137 questions correct out of 175. You will get the PMP certification as soon as you see ‘passed’ on the screen. You need to claim 60 PDUs for every 3 years in order maintain the certification and your 3-year recertification cycle begins immediately once you receive the certificate. According to a study conducted by PMI Pulse of the Profession, enterprises are getting their projects done on time, within scope, and within budget which has at least one-third of PMP certified project managers. This is because a project manager is responsible for planning, organizing, leading, monitoring or controlling, estimating cost, developing the budget, and managing risks and reports of the project. A certified project manager can play multiple roles depending on the requirements of the project such as project manager, program manager, portfolio manager, functional manager, project sponsor, project officer, and delivery manager. The demand for Project management profession is growing faster than any other occupations. Holding a PMP certification proves that you understand the global language of project management and helps to connect with a community of experts, organizations, and professionals worldwide.
Rated 4.5/5
based on 5 customer reviews
Peak with PMP: Reach New Heights With KnowledgeHut’s Top Courses
Project ManagementThe Personal Agile Transformation: An Agile Journey To Productivity
By Jim Stewart
Much is made lately of the fact that some organizations are making the transformation to Agile, finding the greater emphasis on self-organizing teams, incremental deliverables and maximal business value compelling. However, whenever one reads about this transformation, it’s usually from the perspective of the organization and how Agile impacts it as a whole. But while from the outside it would appear that an organization is some faceless monolithic structure, we know that it is comprised of living, breathing people who themselves deliver the goods and services that the organization provides. And so, it seems important to consider what the impact is on those who must deal with their own personal Agile transformation. I have been performing traditional project management for over twenty years. I teach project management as well, and I’ve always been fond of telling my students that project management is, like accounting, a mature profession. Accountants talk about debits and credits and the only thing that really changes periodically is the tax code. The lingua franca of project management is, and for many years has been, artifacts such as Gantt charts and Work Breakdown Structures. But to a great extent, the ground has started to shift under the feet of traditional (plan-driven or waterfall) project managers, especially in the last few years. This is because the Agile approach, initially defined in a manifesto in 2001, has really begun to establish itself in corporations. Not, I would say, to the extent that it is replacing traditional methods and not everywhere. But significantly enough that project managers now need to be not only conversant in it but must also begin to consider being trained in it and getting some experience. (Its greater recognition in that bastion of traditional project management, PMI’s Project Management Body of Knowledge, Sixth Edition, is a fairly significant development). On a personal level, I got my Certified Scrum Master certification in early 2013 but never used it, at least not initially. It wasn’t so much that I was opposed to Scrum as much as that I was working in traditional project management and hadn’t really witnessed first-hand the revolution under my own feet. But gradually I began to realize that there was going to be a significant shift in the direction of the use of Agile and that in order to stay conversant – and, I might add employed – it would be necessary to start getting exposed to Agile projects and working in them. And in thinking about it, I realized that perhaps the very first thing I had to contend with in Agile was the fact that not only is the project manager role not quite as significant, in fact, there is no defined PM role as such. In the Scrum variant, there are only three defined roles – Scrum Master, Product Owner, and Development Team. When I got my Scrum certification, I realized even then that it was a different type of role. As a project manager, I might – and should – do all the planning with my team. But when it comes time to decide who did what and when, that was always my job. It is very much of a command and control structure. And not only did I expect to lead the team, the team expected to be led. But in Agile it’s quite different. In that role, I am much more of a facilitator or coach than I am a driver of the team. The team is self-organizing, meaning that while I can help remove impediments for them, it is not my job to tell them what to do as such. It is their job to figure out what to do as a team and for the Scrum Master to facilitate and coach. Find some useful tips on how to succeed with your Agile transformation below- This is a major shift, not only for the project manager but also for the team. For the project manager, he or she must stop being directive and start being facilitative. For a lot of PMs, this is a very challenging transition. They don’t know how not to direct. And as likely as not, if they have been a PM for a long time, they are very much used to using a scheduler such as MS Project. But a Scrum team doesn’t necessarily need such a tool, preferring workflow tools such as Jira to track progress. The challenge is that the traditional project manager must hold back on telling the team what to do when they ask. He or she can remove impediments when they arise. But his or her best advice when asked what a team member should do is “take it to the team.” In a sense, he or she has to rethink what he knows and throw some of his or her training out the window. Be a Scrum Master, Not a Scrum Manager https://t.co/ohOBBzH5Lb #agile #scrum #dev @HyperRTs @DNR_CREW pic.twitter.com/XrmsCAdzwK — Seth G. (@Nicko_iCorplife) October 14, 2017 And it isn’t just the PM that may have a problem adapting to this new reality. Imagine the team member who is used to being told what to do in a hierarchical situation. Now he or she is faced with, to a certain extent, being self-directed. Some prefer not to go through this experience. And while Agile can be used for a variety of projects, it still tends to be heavily used in software development environments. And some developers, for example, used to working alone, are now expected to meet every day not only with the team but with the business. For some, this is outside their comfort zone. I spoke to a woman at an Agile conference who advised me that several developers on her team asked to be moved or left the company when Agile came in. I think the main takeaway here is embracing change and adapting. (Ironically, hallmarks of Agile itself.) Some people just prefer to do things the way they’ve always done them. And then when change overtakes them – as surely it is doing in an Agile world – they are unable to make an adjustment and wind up on the outside looking in. Once I realized that I needed to get into this world, I made this transition not only by getting trained but by adopting an Agile mindset. (Which is what Agile coaches help teams do.) I started reading everything I could get my hands on, networked as much as I could and then when the time came, leveraged that knowledge and my years in project management into a role within a company that, while Agile-ready, still saw the value of both approaches. And when I let go of the need to be in control – and realized I needed to be a coach and facilitator - I found that things just fell into place.
Rated 4.0/5
based on 22 customer reviews
The Personal Agile Transformation: An Agile Journey To Productivity
Agile ManagementAre You Delivering Potentially Shippable Product Each Sprint?
By Ridhi Chhabra
By the end of each iteration, a Scrum team is expected to produce a Potentially Shippable Product. As we know Agile methodologies emphasizes on “Working Software over Comprehensive Documentation”. When we talk about working software, it is both complete and potentially shippable. Agile methodologies emphasizes on working software which is both complete and potentially shippable due to following 3 reasons: It encourages feedback It helps a team gauge it’s progress It allows the product to ship early if desired In order to ensure, we are delivering a Potentially Shippable product at the end of the sprint, we must understand what potentially shippable means. Defining Potentially Shippable As per Scrum Inc, a Potentially Shippable Product is the outcome of the Product Backlog Items delivered at each Sprint. Delivering Potentially Shippable Product at each Sprint is essential to the Scrum because when work is divided into simple pieces it can be finished in a short iterations. As per Mike Cohn, "potentially shippable" and "shippable" are not the same thing. Some large or complex projects will require the use of "release sprint" or "hardening sprint" at the end of a release cycle (say 6 two-week sprints then a 2-week release sprint). The release sprint is not a dumping ground for sloppy work; rather it is a place where some hardening of the system can occur. Let’s have a look at some of the guidelines here: Organizations define their own ‘definition of done’ for every product and project. However, there are some guidelines that are applicable for almost all the Scrum projects in most of the organizations. Potentially Shippable means Tested! There can be no situation where a product is delivered without being tested. By the end of the Sprint, the delivered product increment needs to be bug free. If needed by the Product Owner, the feature should be a bug free, it can be released to the beta users or the stakeholders to review. Potentially shippable does not mean cohesive Just because we know that the product is potentially shippable, this doesn’t mean that people wants us to actually ship it. Many times it takes 2, 3 or more sprints for a feature set to come together to be useful. However, during the Sprints leading up to that point, the team should still strive for a product to be potentially shippable. The #Scrum team as a whole is responsible for delivering a working increment of the product at the end of each sprint http://t.co/NqnOc7JeUt — Manifesto (@ManifestoLondon) September 16, 2014 Potentially shippable means integrated A potentially shippable product doesn’t exist as different collections of source code. On a project, where multiple teams are working, the teams should define the statement of done such that it includes integrating development steams. So, Integration should be done continuously throughout the sprint. Does Potentially Shippable means Shippable? Well, when we define the ‘definition of Done’, We want it to be a Potentially Shippable product. This doesn’t mean that it has to be shippable. Whether the product needs to be shipped or not, that’s a decision taken by the Product Owners, or Business Owners. Hence, Potentially shippable is a state of confidence, that the product delivered at the end of the Sprint, is so Done that it’s Potentially Shippable.
Rated 4.0/5
based on 12 customer reviews
Are You Delivering Potentially Shippable Product Each Sprint?
Agile ManagementAll you need to know about Leading SAFe 4.5® Certification with KnowledgeHut
By KnowledgeHut Editor
Agile is a project management process which encourages self-organization, accountability, and teamwork. This methodology progresses a moderate project management process by reducing the time required for review and adaptation. SAFe combines the power of Agile with Lean product development and systems thinking. It integrates delivery, collaboration, and alignment for multiple Agile teams and provides significant improvements to business agility, including quality, productivity, employee engagement, customer satisfaction, time-to-market, and more. The new version i.e SAFe® 4.5 was released on June 22, 2017. This advanced version speeds up the delivery process of products and services and also offers a 360-degree build-measure-learn feedback cycle. With four major updates, SAFe has grown faster with the market since the initial release in 2011 and keeps on being a work in process. SAFe 4 Agilist certification helps you to build a strong foundation on Agile practices, standards, and applications required to enhance the probability of the project's overall success. You might be searching for the best institute to take the course and might be thinking why only KnowledgeHut and why not others? Here we answer all your queries about Leading SAFe 4.5 Certification with KnowledgeHut. Looking for a quick overview of #SAFe? Check out our most popular download: https://t.co/Iw7rVXSK6U pic.twitter.com/oPEExo8mUY — Dean Leffingwell (@Deanleffingwell) October 31, 2017 Who is the certifying agency? SAFe® Enterprise or the Scaled Agile Framework is the provider of this SAFe® 4 Agilist Certification. KnowledgeHut offers this course by professional trainers with years of industry experience. SAFe® Agilist certification exam cost? The exam cost for the first attempt is included in the course fee if the exam is taken within 30 days of course completion. Also, the candidate can retake the exam if not cleared in the first attempt and each retake attempt charges $50. Who will benefit from leading SAFe® 4.5 course? The following individuals will benefit from this course: Leaders and Executives, Directors, Managers, CIOs, and VPs Enterprise, System, and Solution Architects QA, Development, and Infrastructure Management Project and Program Managers PMO, Portfolio Managers, and Process Leads Product and Product Line Management Is it mandatory to attend the course or can a person just take the exam directly? Yes, candidates should have completed the 2 days’ Leading SAFe® 4.5 certification training course to take the exam. After successful completion, of course, your trainer registers you to Scaled Academy and after this registration, you will receive an e-mail that includes an exam link. Thereafter, you will have 30-days to take the test. What do attendees get from the course? The course registration includes: SAFe 4 Agilist PDF certificate SAFe 4 Agilist digital badge to promote your online accomplishment Comprehensive courseware materials by Scaled Agile Institute 1-year membership with Scaled Agile Access to members-only resources such as advance notice of upcoming SAFe products, guidance presentations, and webinars 16 SEUs and 16 PDUs 1 free attempt of the exam as the course fee includes the exam fee Can I cancel my enrollment? Do I get a refund? Your amount will be refunded in full only if the registration is cancelled within 48 hours and the refunds will be processed within 30 days of the request. For more details, check our refund policy. Note: Due to transactional costs that are applicable while refunding, all cancellations will cause a 5% deduction in the refunded amount. What topics are covered? The topics covered in our 2-day course are: Introducing the SAFe (Scaled Agile Framework) Embracing a Lean-Agile Mindset Experiencing PI (Program Increment) planning Understanding SAFe Principles Implementing an Agile Release Train Leading the Lean-Agile Enterprise Exploring, Executing, and Releasing Value Building an Agile Portfolio and Empowering a Lean Portfolio Prerequisites for SAFe® 4.5 Certification? Anyone regardless of experience can attend the course. But the following knowledge and skills are highly recommended for those who really want to take the SAFe® 4 Agilist certification exam: 5 plus years of experience in business analysis, testing, product or project management, and software development Good experience in Scrum What will I learn from the course? On completion of the course you will be able to: Apply SAFe to scale Lean and Agile development in your organization Identify and apply a Lean-Agile Mindset and principles Empower with a Lean Portfolio Improve your Lean-Agile leadership skills Continuously explore, integrate, deploy, and release value Coordinate the development of large value streams Support a Lean-Agile transformation in your organization How can I apply? Follow the below steps to apply for Leading SAFe® 4.5 certification exam- Step 1: Take the 2-day Leading SAFe®4.5 course Step 2: Your trainer will send all your details to Scaled Agile after successful completion of course. Now, the Scaled Agile Academy will send you two emails: a Welcome Letter and a Learning Plan Assignment. The Learning Plan Assignment e-mail includes information about the exam. Step 3: Take the online SAFe® 4 Agilist certification exam. Step 4: Once the test is completed with the minimum passing score, Scaled Academy will update your profile to disclose the certification. Step 5: You will receive an email including official notification from Scaled Academy which allows you to the member area and helps you to make your profile public within the Scaled Agile Community. 1-year membership with Scaled Agile will be provided as well. Why KnowledgeHut for Leading SAFe® 4.5? KnowledgeHut is a silver training partner of Scaled Agile Inc (SAI) and offers world-class learning to its students with excellence and provides in-depth knowledge required to become a successful world-class professional. KnowledgeHut also offers: Free materials from Scaled Agile Framework. Tricks and tips from our professional Certified Leading SAFe experts who have years of experience in implementing it in a variety of environments. 1-year membership with Scaled Agile included in the course fee. We hope this article cleared all your queries related to SAFe® 4 Agilist certification. Connect with us to know more about the Leading SAFe® 4.5 course.
Rated 4.0/5
based on 14 customer reviews
All you need to know about Leading SAFe 4.5® Certification with KnowledgeHut
Agile ManagementPatterns For Adopting & Spreading Scrum In Organizations
By Ridhi Chhabra
When we talk about adopting any new framework or methodology, we think about how we can incorporate these changes into our organization. We simply cannot impose any change in our organization and get started with it, there has to be some process or ways to incorporate that. Also, there are some ways to incorporate Scrum changes within our organization. There include five activities in adopting the Scrum successfully: Awareness Desire Ability Promotion Transfer So to remember, we call it by the acronym ADAPT. Let’s now talk about the Patterns of Adopting and Spreading a Scrum: Patterns for Adopting Scrum Start Small or Go All In Organizations go ahead with it like a Pilot project, like selecting few team members and implementing Scrum with them, It's a ‘Start Small’ pattern. The other approach can be Go All In, which is like the executives are convinced and want the whole organization to implement in one go. Reasons to prefer starting small It’s less expensive Early success guaranteed Avoids risks of going all in Less stressful Can be done without much change Reasons to prefer going all in Reduces resistance Avoids problems within different teams The All-in transition is Quick! Choosing between the two As recommended by Mike Cohn, one should always Start Small! It involves less cost, and guaranteed early success. Going all in should be in limited cases, only when it’s a quick need. Also, it involves more cost/money as there are a lot of changes in different departments if required. Public Display of Agility or Stealth The next pattern that comes into the picture is whether to Publicize it or not. We can do the Public Display of Agility. In this approach, the organization announces that it is adopting Scrum. This can vary from announcing it in a meeting room to announcing it through the press release. The other approach is Stealth transition. In this, only team members know they are using Scrum until the project is complete. Reasons for Public Display of Agility Everyone knows that team is doing it and they are more likely to be focussed Operating publicly is a firm statement of commitment You can solicit organizational support It sends a powerful message Reasons for Stealth Transition A chance to make progress before resistance starts It keeps pressure off No one knows until you tell them If no one knows, no one can tell you to stop Choosing between the two As recommended by Mike Cohn, always choose to make a public display of Agility when you are confident and committed to the transition and when you expect a lot of resistance but want to overcome it quickly. In contrast, choose a quiet approach, when you want to do an experiment using Scrum. Patterns of adoption: "Going Through the Scrum Motions as Opposed to Being an Agile Jedi " https://t.co/tpv9kIVxNU @MichaelNir (via @InfoQ) — Stefan Wolpers (@StefanW) May 16, 2016 Patterns for Spreading Scrum Getting started with Scrum is one thing, spreading it across the organization is another. Unless you choose an all-in transition, you will need to build upon the successes of the first few teams as you move Scrum to other teams. There are 3 general patterns given by Mike Cohn that talks about spreading Scrum. Split and Seed This talks about taking a team that has begun to be successful with Scrum and using its team members to seed new teams. It’s typically put to use after the first few teams have successfully implemented and adopted Scrum. By this time, each team member understands how Sprint work and how the ready software is delivered at the end of the sprint. In Split and Seed pattern, we split one functioning Scrum team into each half of the original team forming the basis of the new team. New people are then added to these split teams to form new Scrum teams. A large initial team is used to seed as many as four new teams. Collated below are the reasons to prefer Split and Seed pattern. Add teams more quickly Each team has someone with Scrum experience to guide them Grow and Split The Grow and Split pattern involve adding team members until the team is large enough that it can be comfortably split in two. Immediately after splitting, each of the new teams will probably be on the small end of the desirable size ranging five to nine members. After allowing the new teams one sprint at this reduced size, new members are added until each team becomes a large enough that it can also be split. This pattern repeats until the entire organization has transitioned. In following cases, you can prefer Grow and Split pattern. Don’t have to destroy any existing teams Team members feel more continuity from sprint to sprint Internal Coaching The Third pattern of Spreading Scrum is Internal Coaching. In the organizations, there include types of teams. Some teams excel with the new agile approach, while others struggles. On each team, there exists one identified person who understands and implement Scrum successfully. That person is assigned as a Coach for other teams. Coaches were given responsibilities to attend sprint meetings, daily scrum each week and coach other teams. Reasons to prefer Internal Coaching Well running teams do not need to be Split Coaches can be selected for new teams Coaches can move from team to team Choosing your Pattern! In general, consider going with Split and Seed pattern, when in a hurry. It is the fastest way of spreading Scrum. However, if the technology doesn’t support moving people among teams, changing the team members can affect the productivity. The Grow and Split pattern is simply more natural and direct approach. Consider using this approach if there is no sense of urgency as it is less risky. Internal Coaching can be used on its own, mostly when the group is large enough and when splitting teams are not possible for the projects.
Rated 4.0/5
based on 13 customer reviews
Patterns For Adopting & Spreading Scrum In Organizations
Agile ManagementThe Role Of a Project Manager in an Agile Environment
By Mkateko Shibambu
Let us first understand the Project Manager’s role in a traditional/waterfall environment. The PMBOK (Project Management Body of Knowledge) Guide - 4th Edition states that a Project Manager is known to be responsible for successful implementation of a project through the five stages/processes of a project lifecycle: initiating, planning, executing, monitoring and controlling, and closing the project – see figure 1. Included in these phases is identifying requirements, management of stakeholders and balancing the competing project constraints arising during the project. The project constraints include the: Scope, Quality, Schedule, Budget, Resources, and Risk An effective Project Manager is required to be knowledgeable about Project Management, apply this project management knowledge in order to drive their performance and that of their team, and have positive personal attitude as it will be spread out to the project team. These are key characteristics of an effective Project Manager. The Role of the Project Manager in an Agile Business https://t.co/NNVUV0lT4C via @BrightTALK #projectmanagement #agile pic.twitter.com/DdMBYMIq2A — Capterra Project (@CapterraPM) March 1, 2017 PRINCE2 (PRojects IN a Controlled Environment version 2) is another waterfall methodology and states that the project management project lifecycle and processes are: starting a project, initiating a project, directing a project, managing a stage boundary, controlling a stage, managing product delivery and closing a project – see figure 2. A Project Manager is responsible for ensuring that the team performs and delivers the product accordingly as initially defined with Management ( the Project Board). The Project Manager also ensures that there is clear requirements communication between the project board and the project team to ensure quality delivery. The Agile methodology seems to be emerging very fast with most organisations requiring to do away with waterfall and utilize Agile rather. For some organisations, Agile has proven to work well in the sense that implementation happens timeously in small chunks of releases instead of a big-bang implementation that has a high probability of failure if other detailed risks and issues are missed. The stages of Agile product development life cycle include: requirements gathering, planning, design, development, release, and track and monitoring. Agile aims at releasing small chunks of the full product in sprints (popularly defined in a two week period) rather than a big bang full release. The cycle is iterated until the full product is developed and released. I have worked in a fully waterfall environment, as well as waterfall but being so-called Agile, and I am currently working in a seemingly fully Agile environment. There are different roles in this fully Agile environment of which they include: Project Manager, Product Manager, Product Owner, Scrum Master, and others. These roles are a combination of waterfall and Agile roles although we call ourselves fully Agile. We – as a team call our environment fully Agile, absorbing this information from our organisation’s Senior Management, who manage appointment of these roles. A Project Manager works very closely with top management for strategic decision making. A Project Manager still maintains the role of being the sole responsible person for successful implementation of the quality defined product, and also supports the team throughout the iterations and shield them from distractions. Although there are different frameworks in Agile, the roles within Agile do not differ much, for example, the role of a Scrum Master. A Scrum Master works very closely with the Project Manager to close the communication gap between the project team and top management. A Project Manager manages project/product risks while the Scrum Master manages the team’s performance and impediments. In waterfall, a Project manager works very closely with the delivery team while in Agile, the Project Manager works with the team indirectly – managing team communication through the Scrum Master. Although the Project Manager is responsible for successful release of a quality product, the Scrum Master is the one that manages the delivery of this quality product while working with the delivery team, since the Project Manager does not communicate directly with the delivery team. The Project Manager manages time delivery more than quality. The Scrum Master manages quality delivery of the product. The Scrum Master also manages impediments as well as the development/delivery team while the Project Manager manages risks and address them with strategic management. Then the question arises, do we still need Project Managers in Agile? Although there is no Project Manager role in any Agile methodology, in real work life environments, we still have Project Managers. To differentiate the two roles, both are responsible for delivery of a quality product. However, a Project Manager works strategically with the management team (project sponsor, project owner/requestor, etc.) to define the product’s epics, while the Scrum Master receives management defined epics from the Project Manager and work with the delivery/development team to break-down the epics into features, stories and tasks. A Scrum Master also manages impediments from at development team level and resolve what is possible in his capability. Impediments that are rated high are now channelled to a Project Manager to be managed strategically by the management team. Although organisations that are going Agile see a need to diminish Project Managers’ roles in their organisation, it will be challenging as there is also still a need to understand roles like Product Manager – which is a strategic role as well and might at times overlap with the Project Manager role, if they work together in a team to deliver the same product. Are Project Managers still required in Agile? According to my opinion and how things are working out in my organisation, my answer is actually yes! Project Managers are still required and must work closely with the Product Managers and Scrum Masters. Although there can be a confusion which can cause conflict of responsibilities between a Project Manager and Scrum Master at times. Figure 3 illustrates clarity of the Project Manager and Scrum Master roles.
Rated 4.0/5
based on 12 customer reviews
The Role Of a Project Manager in an Agile Environment
Agile ManagementBest Ways To Split User Stories For Efficient Product Backlog Refinement
By Nidhya Palaniappan
Product Backlog and User Stories: Product Backlog is an essential artefact of Scrum Framework. It comprises of a list of items (referred as PBI) that are planned to be implemented in the future. PBIs are generally in the form User Stories. A user story is the concise representation of a functional or technical requirement of a system. Writing appropriate user stories forms a strong base for achieving the sprint goals successfully and progressing towards the product vision eventually. "If you want to know more about a 'user story' you may also watch“ INVEST The attributes of a well formed user story goes by the acronym INVEST, which was coined by Bill Wake in his book "Extreme Programming": Independent - Each story should be atomic and not dependent on any other stories Negotiable - Should have scope to allow negotiation between the scrum team and business team on the grounds of technical , functional and budget constraints and modify itself accordingly Valuable - Must deliver some value to the stakeholders. If it is a functional user story, then there should be provide some business value , whereas technical user story should focus on architectural and non functional improvements. Estimable - Team should be able to arrive at a fair estimation for implementing the user story in terms of story points. Small - Should be small enough to plan and implement within a sprint Testable - Should have a clear acceptance criteria , which gives the team all the necessary information to test every possible flow. Product Backlog Refinement Product owners have to maintain a healthy backlog by frequently grooming the user stories in it. In the grooming sessions (Product Backlog Refinement), PO discusses with the team and work on improvising the poorly written user stories, breaking down the large user stories into manageable size, adding more clarity to the acceptance criteria , prioritizing the user stories and estimating them. As a Scrum Master, we should guide the team and PO in this backlog refinement activity by aiding them with the best practices in writing user stories of right size and prioritization. User Story Splitting Splitting user stories is a significant task in product backlog grooming. A user story should be neither too small nor too big. It has to be sized appropriately , in such a way that , the implementation of it could be decomposed into one or more tasks. All the tasks planned must be completed within a sprint. Generally , user stories of size more than 8 or 13 story points are split further. However this number may vary from one scrum team to another based on their capacity and velocity. Benefits of splitting a story: Smaller is always better. User stories of relatively less story points are * Easy to understand and groom * Leads to accurate estimation * Results on quicker implementation * Aids thorough testing Size of an user story is said to be optimal if it could be implemented within 0.5 day (half a day) to 10 days. Methods of splitting : A user story can be split: Horizontally - through architectural tiers as one layer at a time Vertically - as functional pieces across all the layers at a time. The horizontal layers split accordingly can be further divided as tasks. A common metaphor used to differentiate both these methods is cutting a cake layer by layer ( horizontal) and portion by portion of all the layers (vertical). Only by tasting a portion of all the layers, one would be able to feel the essence of the entire cake. Same is the case with story splitting. Vertical (Functional) splitting is more valuable than the horizontal one. Advantages of vertical splitting: Dependencies and risks could be identified at an earlier stage Nice to have features can be segregated and deferred for later sprints Considerable progress can been seen on functional part every day, whereas in horizontal slicing no benefits are seen until all related stories are complete Leads to quicker testing and faster feedback loop - in horizontal , need to wait until all the dependent stories are done Helps to prioritize based on incremental value Techniques for splitting stories vertically: User stories can be split vertically based on the following patterns: Generic Terms: If an user story has more generic terms, then there is a possibility to split it vertically. For eg : As a library member, I want to search the availability of various kinds of books for children and share it with my network. Here, "various kinds" , "share it" are more generic terms. They provide a way to split the story incrementally as below : * Develop a UI that displays all the book categories when a registered library member login * Provide a search functionality to the member, where in results are also categorized such as "fiction for kids under 10", "fiction for kids 11-15" and so on * Enable to users to share the result via email, whatsapp etc Connectors : If the user story is represented using a compound sentence, then it is obvious that it can be split vertically. In such cases, look out for conjunctions in the user story like "and, or, as well as, when, if" and split it based on these connecting words or conjunctions like : and, or, if, when, but, as well as. Acceptance criteria: Read out the acceptance criteria; if it is too complex and some parts of it can be pulled out and developed as an independent user story, follow the same. Eg: As a senior associate of the organization, I want to register for the in house training programs so that I can attend the trainings and upskill myself. Acceptance criteria : All the senior associates must be informed about the training programs through mail. Senior associates should be able to submit their details through a form for registration. Mail confirmation must be sent on successful registration. In the above scenario, each of the criteria can be designated as a separate user story. Workflow steps: Identify the workflows that connect different roles for a specific function, and if they can be completed independently split them as a separate user story. Eg: For an assignment approval system in a school, the following can be the possible user stories As a student, I should be able to submit my assignments to the teacher for grading As a teacher , I should be able to view the assignments submitted by the students As a teacher, I should have the UI to request for more clarifications Apart from the above, below are the other patterns based on which user stories can be split vertically: Operations - Create, Read, Update, Delete operations required for a functionality Business Rules deviations Variations in Data given as input to the system Variations in User Interface Spikes - If there are many unknowns in a user story and it requires research for uncovering the grey areas, then create spikes to get the insights of the user story. Based on the spike's outcome, we can proceed with the implementation of actual user story. Best practices for story splitting: * Do not split the stories too early - split just in time, when it's priority for implementation is high. * Do not compromise quality / non functional requirements - NFRs must be taken into consideration while splitting. If having a choice between a couple of user story splitting strategies, prefer the one that will result in similarly sized sub-stories. — Wojciech Zawistowski (@velesin) May 29, 2015 * Ensure that there is no feature debt - splitting should not leave out any functionality without implementation. * Story splitting is not a task to be owned by the PO alone - Along with the Scrum Master, other team members also give their view on best possible ways to split the stories as they are the actual persons who are going to develop the stories into working functionalities.
Rated 4.0/5
based on 16 customer reviews
Best Ways To Split User Stories For Efficient Product Backlog Refinement
Agile Management"The Escutcheon Workshop" - PART 2 : Kanban Journey for the Infrastructure Operations Support and Service Teams
By Badri N Srinivasan
In my previous post, I had explained what is Kanban and how to view it in the context of Infrastructure Operations Support and Service . Before we start the implementation of Kanban for a specific Operations Support and Service Team, we need to identify the team composition and work out its team structure. This will help us to implement Kanban effectively for the team. This process is known as team design and it is considered as a part of the organizational design (OD). When we identify and form a team, we generally identify different support/service skills that the team should possess so that they can undertake the complete support/service for the customer. For e.g. if a single team is expected to provide network support services to the customer, the team should ideally have skills in L0, L1, L2, and L3 support. This ensures end-to-end support for the customer as a single ticket that can be resolved by one team instead of the customer depending on multiple teams (L2 – one team, L3 – another team and other multiple teams, where applicable) to complete his ticket and request. Each member identified at a particular level of support is skilled in their job and the skill level increases as the level move up. Each level has more experience and education. The different service levels are – L0 – Basic resolution of issues through call resolution. Take the help of knowledge base to manage issue resolution. L1 – Product Demo and basic troubleshooting including specific call resolution. Deal with physical connections and hardware. Basic network design - from about 30 to about 500 network point design. Basic project management skills. L2 – Resolution of Technical problems. Focus on medium to large network design. 500 to about 2000 network point design. Intermediate project management skills. L3 – Resolution of Major problems. Root cause analysis of problems with updations to the knowledge base. Design Experts and Data Center specialists with project management skills. Focus on 2000 to 30000+ network point design and familiar with high-end network equipment (CISCO/JUNIPER/Other Brands). The network support services could be in the form of network design, installation, support and maintenance. Additionally, the levels – L0, L1, L2, and L3 could vary in different organizations depending on the type of services being offered by the organization to the customer and the type of terminology used. We may also have additional or fewer levels depending on the focus of the organization. However, at a broad level, the above classification could be used to categorize different types of operations support and services in an organization. There are two types of team design that can be observed in an organization – teams that are exclusively made up of only one type of skill level, e.g. L2 support, L1 support. This is the component type team design. Teams that are made up of the complete stack of support services provided – A single team having L0, L1, L2, and L3 skills. This is considered as the feature type team design where like a feature team, the operations support/service team provides complete end to end support to the customer (A feature team is a team that has all the skills needed to support the customer requirements and delivers the features to the customer). As organizations focus on agile and Kanban implementation for their teams and also emphasize imbibing the aspects of Spotify Engineering Culture (a culture that focuses on not having a hierarchical structure and which focuses on host and servant leadership), the attention is on forming teams that have end to end skills to resolve all the customer issues. Hence, the focus on full stack operations support/service teams. Earlier, a team member used to have specific skills and built his skills in that area only, e.g. L2. This was the T type skill focus. Now, we have the PI type skill focus where a team member is expected to be an expert in at least two areas – e.g. L2, L1 and also have knowledge in other areas. It is acknowledged that there are constraints that need to be overcome to reach this level but it is expected that in the future, the demand will be for full stack skills (L0, L1, L2 and L3) from a single team member. This implies that a team member has all the skills necessary to deliver the service/support to the customer without having to depend on another member or wait to seek help from another member. There are multiple constraints that need to be overcome in order to reach this state and organizations are facilitating this transformation that may happen over a period of time in the future. This will further strengthen the Operations support / service teams structure and delivery to the customer in the future. After the skill matrix and the team members are identified to form a team, one of the members of the team is identified as a Kanban Master. He is responsible for facilitating the implementation of the Kanban practices and process for the team along with the help of other non-team members like an Agile Coach, Center of Excellence, Continuous Improvement team and other teams (e.g. training), where applicable. Generally, we have an initial kick-off workshop for the newly formed team which I call as the Escutcheon workshop. An Escutcheon (as per the Oxford English Dictionary) is defined as – An emblem or shield bearing a coat of arms or a flat metal piece that is used for protection and also ornamentation around a keyhole, door handle or light switch. The analogy with Escutcheon reminds us of the concept of the team subliminally forming a protective boundary for the team members and which helps the team members to undertake their daily work and take the help of other team members when stuck and ask for help when they are not able to resolve any issue. The team is also having a team name which gives an identity to the team, improves team bonding and which is similar to the coat of arms on a shield that bound fellow kinsmen during the olden times. The output of the workshop is also a diagram in the form of an Escutcheon. Hence, the term Escutcheon. This, of course, implies that the team members exhibit team member characteristics like trust, courage, transparency and other traits so that the concept of a team can be established and sustained in the future. Additionally, this does not mean that the team members can only ask for help from any other member within the team. They are free to also ask for help from any other member in the organization for additional ideas for issue resolution. A typical output of an Escutcheon Workshop for a Network Operations Support / Service Team is given below - Are you interested in learning more about Lean manufacturing? April 5th kicks off our Pull / Kanban System and Total Productive Maintenance Workshop! #TPM #PullKanban #Lean Learn more at https://t.co/I0gGUIU4UP pic.twitter.com/c6cfFI7WYx — IMEC (@IMECillinois) March 12, 2018 This network operations team is tasked to support network usage and monitor the performance of the network apart from other routine support / service activities. Hence, this becomes the important tagline or punchline of the team. The key words of the team focus on data, usage and performance (with respect to the network). The team emphasizes collaboration and creativity as key focus areas which will help them in their day to day activities related to network support and service, apart from other focus areas. The team calls themselves as “Network Tigers” and which is ready to support any network issue end to end within their scope of operation pertaining to network support and service. They adopt the logo of a Tiger Face which gives the team an identity to focus, bond and celebrate their successes and wins and support each other during lean periods. Thus, the Escutcheon workshop helps the team to establish a facade (principal front face) to the customer as a single point of contact to help them for all their issues related to their network and help to resolve them end to end in the shortest possible time and with the highest quality. The team members keep improving their skills to meet this commitment to their customer and learn from their mistakes, adopt continuous learning and implement the lessons learnt from their projects to further strengthen their skills to match and exceed the customer expectations. Hence, we have now established a full-fledged Operations Support / Service team having all the skill sets that are needed to address the queries, issues and tickets raised by the customer related to their network. Now the team needs to implement, establish, nurture, sustain and institutionalize Kanban values, principles and practices in their team to enable and facilitate the team to enhance customer delight and improve the quality of delivery. In the upcoming Posts, I will focus on the next step in the Kanban journey as we learn how to implement Kanban for the Infrastructure Operations Support and Service teams – both at the team level and at the scale level (when we integrate multiple teams at scale to deliver support services to the customer).
Rated 3.0/5
based on 1 customer reviews