In September this year I gave a keynote presentation with Jurgen De Smet at the first Agile Eastern Europe conference. Our presentation was about a company that over 12 years and many acquisitions has grown a software development environment that is very difficult to manage. With humour and the cooking show format we take a look at the dysfunction and complexity in this environment, how it arose, and discuss approaches we would take to improve the situation. Enjoy!
Jim Womack recently published a brilliant eletter on lean.org. In the letter Jim discusses the many challenges GM faces coming out of bankruptcy, and the challenges Toyota faces from its rapid expansion. The eletter is great but there are some choice quotes I would like to publish here:
On the message from GM’s Bankruptcy:
“Yesterday also marked an end of the lean narrative that has been unfolding for thirty years, ever since GM first began to decline in the recession of 1979. David (in fact a team of Davids) finally felled Goliath just as Goliath was finally paying attention to the lean message.”
On GM’s management:
“It is easy to blame GM’s recent management for its troubles. But the senior GM managers I have known – almost all of whom had strong finance backgrounds –were remarkably competent at running the company in the financially oriented, manage-by-results way that had produced success for generations. So the problem is not the individual competence of managers but GM’s irrelevant conception of what management needs to do.”
On what is next for Lean:
“We in the Lean Community find ourselves in the odd position of winning a battle of ideas without actually getting most believers to fully practice their new convictions. And we have as our ideal organization a company that is experiencing significant management and revenue challenges despite “winning” the great contest between modern management and lean management.
… Lean ideas are spreading rapidly to new fields, from the beleaguered financial industry to healthcare to government services. Yet we have not fully defined what lean means in these areas, much less how to implement and sustain it. So the dramatic events of recent weeks are not a time for self-congratulation. Instead, they are a time for modesty and self-reflection – hansei, if you will – as we all struggle with the economic crisis while trying to re-define our own purpose as a Lean Community for the new era ahead.”
Martin Fowler recently posted the blog entry “Flaccid Scrum”. Martin makes some good points on Scrum and its adoption without the corresponding agile engineering practices. The observations from his colleagues are common, as teams that are new to Scrum and Agile techniques are learning a new way of working. Scrum implementations lend themselves to adoption of Agile engineering practices. The messy code problem is not a result of Scrum, it is Scrum that has brought visibility to low quality code. Having to put code into production early and often forces teams to recognize defects that otherwise would remain hidden for months in a waterfall process.
Semantic diffusion - Martin’s term for the observation that definitions become diffused over time is an interesting idea. In doing Agile adoption at a major Financial organization we called this “death by a thousand copies.” Someone would have a practices based definition of what Scrum was and then share it with other people, with no references back to the underlying principles. They would modify practices to suit their environment, and those practices would become the defacto “Scrum” for that group. Why does does this occur? We found it was because people did not understand the basic fundamental principles of “why” certain practices are put in place. In the market we see many “ScrumBut” implementations of Scrum, where the basic principles and practices of Scrum are are known and understood but not followed. This phenomena is not just a Scrum problem, Object Oriented development and adoption of Lean principles in manufacturing (outside of Toyota) have also been poorly implemented at various organizations. Each implementation however poorly done, gave some benefit to the organization, often a short term benefit. For example car manufacturers like GM learned how to lower inventory and remove waste from their manufacturing plants.
The time tested way to deal with semantic diffusion, death by a thousand copies, and poor quality code, is to implement two foundational values: respect for people and continuous improvement. Respect for people in Scrum is articulated in ideas such as self organizing teams, pull, and commitment based planning. In Lean it is exemplified in the authority that any worker can and should “stop the line” to address defects and implement solutions that eliminate the root cause of the defect. There are many other examples of respect for people. At Toyota employees are expected to continually improve the process, and if it eliminates the job they were doing the company will find another place they can continue to make improvements. In August 2008 Toyota closed two truck plants in the US but did not do any layoffs, instead putting 4500 employees into a massive training program. This security empowers people to implement improvements knowing they do not need to “protect” their current job on the assembly line. Compare this to the Financial organization that employs talented software engineers to implement repetitive tedious manual production release processes instead of empowering these people to build standardized automated processes. Those same engineers have no interest nor are they asked to implement these automated systems because it would threaten the existence of their jobs and their manager’s jobs.
Continuous improvement, also called Kaizen by the Japanese, is the daily work of finding and implementing improvements to the process. In software the process is how to go from an idea to working testing software in production. Those improvements should result in ever faster translation of ideas into software with less effort and less cost. In North America we are obsessed with Goals and Objectives. However what happens if our goal is to never be satisfied with: the current process of delivering value, the quality, and the cost? How do you achieve perfection in the delivery of software for your customers? How do you do that in the shortest cycle possible?
Scrum does not tell software developers to use test driven development, continuous integration, pairing, or automated testing. Scrum was created that way on purpose. Once you start using Scrum, implementing these practices should be part of the continuous improvement cycle. Learn Scrum, learn XP, learn Lean, learn Theory of constraints, and most importantly, learn what your customers need and strive to fill those needs using these great ideas.
A basic pass / fail test was developed at Nokia to understand if the many teams were implementing Scrum correctly. You can take this test by clicking on the link below.
I will aggregate the results and email them to you if you are interested. I will present the results back to the Agile/Scrum community for discussion once we have 1000 responses.
As of January 26, 2009 we have 208 responses.
Please forward this email to other teams so we can get as many responses as possible.
As Agile becomes more mainstream and the knowledge base grows, staying in touch and contributing to the community grows in importance. The conference of the year in the Agile community is Agile 2009. Agile 2009 has the largest attendance, the most participation, and the largest number of sessions. I am continuing my involvement and contribution, this year I am producing the Main Stage events with the help of Bill Wake. I encourage you to take a look at the Agile 2009 Open Submission system http://agile2009.agilealliance.org/ and see the proposed presentations. Agile 2009 has an open review process where anyone who registers can comment on the proposals and provide feedback to the submitters. Have some new ideas that you’d like to contribute? Please do add a submission. If you have a specific experience with Agile methods that you think is a great war story, then an experience report would be a great option.
While Agile 2009 is about Agile methods, culture, techniques and principles, Lean and the Toyota Production System continues to gain influence in the community. The maturity of ideas and the experience of thought leaders implementing Agile has lead to Lean. Lean improvement tools and ideas beyond software development to the whole process, from customer request to request fulfilled. This expanded scope of process improvement is new to the software development world but it is a healthy and logical place for continuing expansion in the process of improving delivery of software systems.
A benefit to successful presenters is free conference registration, and for longer talks hotel accommodation is also included. See the web site for the details.
I hope you will check out the Agile 2009 site and get your submissions in! The deadline for submissions is February 13th.
I was recently in Ghent, Belgium to give public training sessions and a talk at Agile in Belgium. My colleague and friend Jurgen de Smet and I conducted a Certified Scrum Master class, and I launched a new one day intensive course on User Stories, Paper Prototyping, Agile Estimation and Planning. Jurgen did a very nice write up on the class on his blog User stories, paper prototyping, estimation & planning where he outlines the course and his impressions. However he didn’t mention the business case. The business case is the development of a Belgian Beer portal to sell the many hundreds of varieties of Belgian Beer! For those who don’t know lager from ales, the Belgians are world beaters at creating and selling great beer. The largest beer companies in the world are based on Belgium. In fact Budweiser’s parent company was recently bought by the Belgian-Brazilian company InBev, the world’s largest brewer. What has this to do with Agile, Usability and Scrum? Well if you are going to fulfill the business case for supplying large markets with the many niche beers of Belgium, why not use Scrum? It is the fastest way to go from customer need: I am thirsty for a Trappist monk brewed beer, to need fulfilled. Ahhh! that is a fine ale. Of course if you are in Belgium, then a trip to the store is probably a little faster and cheaper. The business case gives participants a specific market and product with its technical and non-technical challenges. The Product Owners need to account not only for the features and the web site but what other things need to be done to get the web site off the ground. The exercise is to recognize the resources are scarce for all the work required, and how do the decisions made in one area, for example fulfillment, impact the site features.
Working on the paper prototype. Here the discussion is about what really is the minimum UI and functionality the portal can enter the market with. Like any web site, there is always more to do… but what can you afford to prove feasibility of the business case? Belgian beer can aid with these agile discussions.
If you are interested in having the User Stories, Paper Prototyping, Agile Estimation and Planning course taught publicly in your area or for your company, please contact me at rdymond atdeletethis innovel.net. I have other business cases that we can use for the same exercises.
Kiev Ukraine: After 5 days in Kiev, I learned much about the state of Agile in Ukraine, and the state of business in Ukraine’s capital. My first visit to the Ukraine held many surprises. The downtown area of the capital was interesting, attractive, an similar to other European cities. The architecture combined Soviet style massive design, buildings with intricate architecture similar to classic European buildings, and more modern apartments and offices. Beyond the buildings to the street, I expected to see clear signs of a depressed economic region, like closed shops, bad roads, and inexpensive transportation. However this is the capital of a 45 million strong nation, and I was surprised. Construction cranes were everywhere as new offices and business centers were under development. More surprisingly, it seems the Lada has been replaced by the Porsche Cayenne, Bentley, and High end Mercedes as the cars of choice in Kiev. A Bugatti Veyron? Yes. I saw a higher concentration of high end cars on the bumpy streets in Kiev then I have seen in London, Brussels, or Paris. I quizzed my hosts about this, and heard a combination of embarrassment and frustration. It seems for politicians and bureaucrats of the Orange revolution, Kiev is open for business that will fund their new, rich lifestyle. This was set against the backdrop of the crisis in the world financial markets and massive spending of taxpayer’s money for disastrous portfolios of high risk mortgages and credit insurance swaps. As someone who helps teams and businesses better compete legitimately, seeing the corruption implied was disheartening.
Meeting the people in the Agile community in Kiev and at the Certified Scrum Master class reminds me of why this is a great profession. The Certified Scrum Master class was a mix of software developers, managers, QA, business analysts and even a couple account managers. While half of the students had been doing Scrum, we also had people who were completely new to Scrum and Agile. We generally have smart people in our profession, and this class was no exception. While the class was in English, the exercises were in Russian. My Certified Scrum Master class covers a ton of material on Scrum, Agile principles, roles of Scrum, and how to establish Scrum with a team. The class asked good questions, and were sometimes surprised by the results of the many exercises we did. With this class I dropped the “59 minute Scrum” in favor of the “Save Earth” and “Ball Points” exercises from CST Boris Gloger. The exercises are great ways to show how we can fail or succeed based on our own personal actions, and they also put students in a different frame of mind, loosening their preconceptions from past experiences.
My main challenge with English as a second language classes is usually pacing. I choose words more carefully and I go slower to ensure understanding. With a packed agenda this means something needs to drop, but, like an over eager development team, I sometimes over commit, trying to squeeze in too much material. The rise in knowledge of the students and the deeper experience of the trainers may lead to a 3 day course. Some trainers such as Mike Cohn and Mishkin Berteig have already adopted a longer format, with Mike offering 2 days of training on requirements and planning around the 2 day CSM class.
The Agile Ukraine gathering 6 on Saturday 10/12/08 was a great opportunity to meet more of the Agile community, as over 150 people packed a large conference room for the day’s events. There were numerous talks from Ukraine’s Agile advocates and thought leaders. Alexey Krivitski is the organizer, and single handedly put together this event for the community. I encourage more of Ukraine’s Agilists to lend a hand and take a leading role with Alexey to create sustainable group of organizers of Kiev’s Agile community. Topics at Agile Ukraine gathering included Introduction to Agile, How we do Scrum, Agile Metrics, mixing Agile and RUP, and Agile and business. I had the opportunity to provide the Keynote presentation on Lean, value stream mapping, and how to apply lean principles to Scrum and Agile projects.
I covered the history of the Toyota Production System, and how speed delivers a competitive advantage to businesses. Most of the IT and software teams in the Ukraine are engaged in offshore projects. Lean can provide a great way to highlight what slows their offshore teams down, and gives them a way to articulate this to both management and clients. The culture of eastern Europeans has an advantage over Indian teams when using Agile methods. Transparency means teams need to have courage and be honest with their customers. This means saying no, managing expectations, and building trust. Teams that always say yes, don’t manage customer expectations, and then hide when it becomes clear there is no way the team will meet the commitment is common in offshore teams. The culture of eastern Europe is not socially hierarchical and there is a tolerance for open discussion and debate within groups. This means teams in eastern Europe are biased to Agile methods when compared to teams from hierarchical cultures like India’s caste system. I don’t think Ukraine outsourcing poses any threat to the Indian outsourcing industry, however Agile is a growing market where Ukraine outsourcing can have a competitive advantage, provided that they can demonstrate and market this advantage. I will update later with photos from the events.
- Robin Dymond.
I often hear: “How I can use Agile on support teams who do defects and small enhancements on multiple platforms?” Support, “business and usual,” defects, and enhancements are ideal for an Agile team. Think about it for a minute: the changes are usually small and independent, they are doable in a short time, and can often be deployed without major architectural or data related changes. This article describes how Scrum was modified to improve a support team’s process.
In the fall of 2005, a production support team of developers, testers, and analysts was setup to support 5 different production systems. The team was responsible for completing customer support requests for defect fixes and small enhancements. Major enhancements were handled by the platform teams. There were 5 different customers that made requests for each system. The team was setup to use Scrum, with Amy Ripley, CSM as Agile Coach and a single Product Owner. The Product Owner worked with the customers to define a single product backlog with priorities for all requests across the 5 systems. While each customer had different needs, many of the systems had interactions, so priorities were easier to determine than if all were disparate systems.
The team was co-located in an Agile team room and started out using standard Scrum with a 3 week iteration length. As the team and the Coach worked together, they realized that Scrum did not account for some of the unique properties of an enhancement and defect support team such as:
Customers want quick turn around on fixing defects found in production
Defect and enhancement implementation is small piece work compared to building new application features
Requests for changes are independent of each other
Managing 5 customer’s expectations lead to pressure for more frequent updates to production. The Coach and the team saw this as a valid concern, and decided to make changes to their Scrum process that would better suit the small piece work and customer needs for faster turn around. The changes included:
Weekly releases to production. Given the production support nature of the team they changed their release pattern from once per 3 week iteration to weekly releases.
Allowing work to cross iteration boundaries. Some requests would be started later in the iteration but could not be completed by the iteration’s end. Given the weekly releases, this was acceptable, since the customer would not have to wait for a whole iteration to see the item in production.
The regular story board was not providing enough clarity as to what was in progress and its state. A more structured Kanban style board would allow the team and stakeholders to more accurately track progress of work items. A Story board was implemented to show the status of a User Story that was in progress. The story would move with its task cards through analysis, dev, test, and release columns on the board. Each the 5 systems had rows for their stories.
A team agreement was made to take each work item from beginning to completion before starting a new work item. As could be expected in a large organization, issues frequently came up that would stop progress a work item. When progress was stopped by obstacles outside of the team’s control, then a team member could start on a new work item. These obstacles were escalated to the Coach, the Product Owner and management for resolution.
This kanban style User Story board really helped the Scrum team, Product Owner and stakeholders understand the state of work at any time. The kanban style User Story board also helped reduce work in progress, since once a story was started, team members would not start on another story until it was completed.
The team continued to use the Scrum practices of self organization, the 4 meetings and a 3 week iteration length. The team and stakeholders valued the planning, it helped set expectations for everyone as to what could be completed in the near term. The demo meeting allowed the 5 Customers gain visibility into all the work done by the team. This “see the whole” is a key principle in Lean and with this team it provided a key benefit to maintaining stakeholder equilibrium, as all of these systems served the same department and overall business function. The Scrum principle of self organizing teams was also maintained, as they achieve higher performance and have higher morale than directed teams. Self organization also frees leadership to innovate and create more effective work environments.
Congratulations to Agile Coach Amy Ripley and team for inventing this Kanban style board and process for their Scrum.
“Two strong personalities and too much debate. Need is the mother of invention”
- James Grenning on inventing Planning Poker
We regularly touch base with many different technology and Agile communities in Canada and the U.S. This weekend Agile Austin hosted the first Agile Austin Open Space conference. The Saturday/Sunday unconference brought together over 100 members of Austin’s technology community, and a wide range of experience with Agile. We very much enjoyed contributing our experiences and hearing many smart, committed people discuss Agile, Scrum, Lean, and software engineering practices. The biggest theme that emerged during the open space conference was the change Agile brings, and how Agile is a disruptive process and technology to traditional business structures and organizations. As consultants, leaders and contributors in the largest Agile adoption in Financial Services, we offered sympathy, advice and guidance on Agile adoption. The conference included discussion on how large (large) hierarchical organizations fare when adopting Agile. Observations included fear of change, job/position/status protectionism, resistance to change, and politics. If the adoption of Agile is treated as a “check the box” activity, real change could be supplanted by surface changes to the project process. Agile adoption should change the fundamentals ways that work gets done and value is delivered. These were some of the hard topics an engaged community discussed and debated with respect and humor. The conversations at Agile Austin Open Space were excellent, and with over 100 people coming out for a weekend conference, you know the right people are there when the discussions started.
The executive panel on Saturday evening was a highlight, with 6 members of Austin’s tech executive community who are leading Agile adoption in their companies. Innovel’s David Douglas did an excellent job relating how executives he has worked with changed their management philosophies, starting with his own “a-ha” moment. Other panelists such as BMC’s Israel Gat discussed how adopting Agile is about business design, and that it has impacts upstream in product management and sales, downstream in operations and deployment, and across the whole value chain of the business. Beth Weeks of Zilliant described how her functional managers have been assigned to teams where they tackle blocking factors and systemic problems that slow teams down and create waste in the organization.
Everyone new to Open Space was surprised by the level of engagement and how well the format works. Having facilitated Open Space meetings for clients, these new folks reminded me of a very important point. Many people and organizations do not have the kinds of open and energetic dialog that I have become accustomed to in the Agile community. It is energizing just to see again how attractive it is to people who have been outside the community. Agile Austin has a vibrant and diverse group of people, it is great to see such large and lively community, it will play a key role in helping Austin companies succeed in adopting Agile.
Congratulations to Scott Killen, Dale Schumacher, and the rest of the Agile Austin leadership for a great learning event.
It is hard to talk about failure. However when you work with many projects and many teams, the odds are good you will experience failures. Last year I had such a learning experience, and one year later it is far enough away that I feel I can talk publicly about it. This project started with the best of intentions. The business case was developed and sponsored by two directors who saw an opportunity to improve a data gathering process that was used to define and market products. The current process involved manual entry of data into a 100 row by 200 column spreadsheet, multiple sources of data, many approvals, and finally re-keying of this data into a custom JAVA application to feed downstream systems. The goal was to replace all of this with a COTS application that would allow re-use of data, the analogy was a “catalog.” A vendor with some presence in a related area was bringing new enhancements that was going to allow this capability. We began a Scrum project to implement this new COTS application to replace the manual entry, spreadsheet and custom JAVA application. A knowledgeable Product Owner with deep experience in the current process was recruited, a team with experience in that part of the business was brought together, and a senior Agile coach who knew the organization and had worked with many teams and some of the team members came onboard (me). In addition a big 3 consulting company with experience with the product was hired to provide team members and guidance. How could a project with all of these things going for it get off the rails? Let’s take it apart and see what we can learn:
Iteration 1: Got initial COTS application installed, knowledgeable PO from business recruited, and team put in place.
Iteration 2: Learned about development/configuration of COTS tool, built out product backlog, and investigated incremental replacement strategies for current system. Product Owner begins to doubt the capabilities of the tool to deliver the needed capability. Product Owner does not see a reason to change a process that they constructed and has been used as is for 3 years. Big 3 consulting firm puts 4 people on the team though 2 members have little experience with the tool.
Iteration 3: Team delivers first functionality in COTS dev environment and pilots it with users. COTS tool still lacks key features required. Feedback is universally negative from business users. Sponsors make a decision to not show the app to customers for next 6 months in order to not create a bad impression with customers. The Product Owner is felt to lack vision and is soon replaced by a Director. An IT Lead with little technical skill and a strong controlling personality is put on the team to “shake things up.”
Iteration 4: Vendor onsite promising features “soon” and working with team to define how system could work. Internal IT controls require a work orders for every db change, causing the team’s pace to crawl, as UI changes in the COTS app generates database changes. Team works around issue by adopting completely local dev setup. IT lead begins attempting to control information flow to team, complains that Scrum is “loosy goosey” and that we need a schedule to drive towards.
Iteration 5/6: Scrum Master and Team members escalate continuing conflict with IT lead, action taken to reduce his involvement. Directors decide to wrap up contract with Big 3 consulting firm. Vendor working daily with team, however key features of COTS package are still not delivered. Business stakeholders who are not engaged in the project but have their “sources” begin influencing the project sponsors and question spending. Process improvement initiative that has been on the back burner for 1 year starts to gain momentum on business side.
Iteration 7: Vendor delivers first version of features with numerous limitations. Directors now openly discussing shutting the project down.
Iteration 8/9/10: About 1/2 the staff roll off the project, smaller technical team continues to try make progress with tool.
Project begins winding up.
Looking at this project we can see that while the Directors did many things to try ensure success, including using Scrum, hiring a big 3 consulting firm, putting lots of people on the team, etc. However there are 2 root causes that are pretty clear:
Project Inception:
The project business case was driven by an IT Director and an OPs Director working together. The business that owned the current process (remember this is product definition data that is generated by the business) and that giant spreadsheet was not driving the project and asking for these improvements.
Platform Decision:
The choice of platform was driven by a belief that the infrastructure needed to move to a COTS application vs. a custom application. The choice of the application was based on promised features that had not yet been released in the application. Further, the application was chosen prior to the start of the project and before anyone had tried to use the tool to build the desired capabilities. Furthermore, when the application was used by the team it was found to be very limited, and the business users found it painful to use. This data was rejected by the Directors. Instead of replacing the tool they chose to wait for it to improve.
These two issues in my estimation doomed the project way before any of us knew we would fail. Further when the warning signs started to crop up there was a failure to recognize and act on this data.
If we look at the principles of Lean and Agile we see a number of violations. If the principles had been followed, the project might have been successful, or terminated much earlier, and either outcome would have been better for the business.
1. Know your customer, engage them and do what they need.
The business stakeholders that owned this process were not engaged. Had they been engaged, they could have influenced process changes that would have enabled a more effective automation solution to be developed. When the business was engaged through the product owner, they were unsure and then convinced the tool could not do what they required. They also did not see a need to change the process they had in place.
2. Decide at the Last Responsible moment
The Directors became emotionally invested in the vendors proposed solution long before the solution was available. This meant that other options, such as a custom application were never evaluated. A set based approach where multiple potential solutions were explored would have provided a much higher level of learning and much better data to base the platform decision upon.
3. Working software is the primary measure of progress
When in iteration 3 the team delivered the first capabilities in the tool the customer feedback was hard for the stakeholders to hear. They did not like what they were trying to use. The response was to stop inviting users to try the software. This is clearly denial of the reality that the project was at risk of ever meeting user expectations, and a better response would have been to change the tool or cancel the project and spend the money elsewhere.
Interestingly, while this IT project ended up delivering nothing, a new project was by the business started to implement major process improvements based on Lean. We also used Scrum for that project and the project was a huge success. I will be cover it in a later posting.
Interested to hear your thoughts, have you had similar experiences?
Post Update based on scrumdevelopment list discussion.
No one starts out a project or a mountain climb with the intention to fail. My hope with this blog and ensuing discussion was to show the process of how events unfolded that lead to the failure. I believe it was the process and a series of decisions that lead to the failure. In the case of this project, the average team member’s years of experience was around 8, and key roles were played by experienced staff some with an MBA from the top three schools. About half of the team had recently completed agile projects that were successful, one being changes to the very same JAVA application that the new system would replace. I would start another project with the same people in that same business area today.
A bit about the COTS application and why it was picked. The COTs application was used by other customers for custom forms based workflows for operational (standardized) projects. The platform supported a high level of configuration for this type of work. One of the goals of the project was to provide a system that would allow business users more control over their work, where they could use configuration to implement automation instead of requiring IT staff to code. A configurable process tool would replace Excel and manual processes that made up the front end. So the COTS application was one of a few from a reputable vendor, had some capabilities in production and a customer base. A key capability it did not have was the (at the risk of oversimplifying again) ability to replace that huge spreadsheet with an automated reusable system - the “catalog” I mentioned. That part was slide ware, though it was heavily sold by the vendor.
The organizational structure played a role as well. The silos of business (generate ideas), operations (run the engine), and IT (build new systems) did not work together. The “pain” and cost being addressed was experienced by operations, who were used to requesting systems from IT. The business silo did not understand the cost of their manual processes downstream. This project was trying to bring process improvement, data re-use and automation in this critical part of the business. However the business users, many of them analysts, were comfortable making updates to an Excel file and sending it on, for someone else to worry about things like reconciliation against other data/constraints/products. While data re-use was happening, it was invisible to anyone but the person copying and pasting. Bringing an automation solution might have meant more work for those analysts, but a major time /effort savings down the line. When we started to see the limitations of the system for business users, the time savings for the whole production line was one justification for continuing.
This 2 day course covers how to use Scrum to manage your Agile projects. Students gain an understanding of Agile principles, Scrum practices, and how to manage the Scrum process. Recommended for project managers, technical managers, and technical leads.
Current classes are listed on the Scrum Training site.
This 2 day immersive training is great for teams who are looking to adopt Agile for their project. Team members come away with a solid understanding of how to work day to day on an Agile project, how it changes their role and what they should expect. It covers Lean, Agile, and Scrum, with a focus on the Scrum project framework.
