Scaling Agile: SAFe with Visual Studio Team Foundation Server

Editor's Notes

• #2: Thank you Nathalie for the kind introduction and getting us started today.First off, I must admit, I am delighted to present to you this afternoon. As a ALM consultant, agile coach and certified program consultant (or SPC), it pains me to see companies, large and small alike, fail to take agile to the next level. In essence, these organizations are leaving opportunity (or money) on the table. As consultant, with “professional” skin in the game --- is can sometimes be very frustrating. To use a sports football analogy, in my mind, having a bunch of scrum teams, is like having a really potent offence, that marches up and down the field --- but only kicks field goals! If you’ve ever played in an NFL pool, you know field goals alone are very frustrating. The truth is, in today’s hyper competitive and fast moving market --- we need touchdowns to win. And a good defense, of course. Based on what is now almost ten years of field experience working in an agile world, InCycle has found that our most successful customers have a shared AND common vision across the enterprise --- including top management on the business side. I point that out because to scale agile and implement SAFe --- you need more than a really ambitious CTO. As we will see momentarily, SAFe transcends the enterprise and all departments.
• #3: Of course, this wouldn’t be a webinar without the mandatory “About us” slide. We’ll, actually, it could be --- but we know marketing wouldbe upset. So… let me tell a little bit about InCycle.I think from a customer perspective, the big take away is that we are not only Microsoft ALM and TFS experts (think build, workflow, test and release management etc.), but we equally excel on the “process” side.For example, we provide services ranging from agile adoption, product management and product owner training, as well as SAFe certification and consulting. In other words, InCycle uniquely combines and delivers services around BOTH agile processes and Microsoft tooling. For success, it’s our experience that you can’t really have one -- -without the other.To conclude, we’ve been doing this since 2002 (or slightly over a decade), we are an ALM gold partner and have several locations in across North America to serve you needs.Moving on --- let’s look at the AGENDA.
• #4: Pause…Today’s agenda is quite simple. As advertised --- we will focus on two main objectives:The first one is to provide you with a glimpse into SAFe --- more specifically, the Scaled Agile Framework. On that note, many of you may be wondering what the “e” stands for in the SAFe acronym --- the truth is it doesn’t stand for anything. It simply makes an otherwise lousy acronym --- pronounceable and memorable. The second item, is to showcase how TFS can be used to support a SAFe implementation. Based on our experience, we’ll show you how TFS can be used and configured to support a SAFe rollout (pun intended). Did you get that?Finally, we’ve reserved a few minutes at the end to address questions. Keep in mind, at any time throughout the presentation, feel free to submit a question in the text box in the meeting console. Nathalie will compile questions and we’ll do our best to respond as time permits.
• #5: “Lean/Agile” target and realized benefits.Four things that we hold dearly, think core values.Code QualityProgram ExecutionAlignmentTransparency (lean/agile is base don trust --- while the framework can’t give you trust, but we have that that if we provide transparency we are taking a solid step in that direction.Based, on field experience, these core values are all necessary to achieve success.Leadership – your role in making an effective lean agile transformation work
• #7: Before we get to deep, I’d like to address the question --- “Why now?” Why do we need another software development approach? Why do we have to revisit how we develop software?To begin, if we look around, I think it’s clear we are surrounded by software. What’s interesting is how the industry has (or hasn’t) evolved.Think about it…Today, software development remains largely manual. Millions of lines of code are hand crafted every day.On the hardware side – Moore’s law is ever present. Essentially doubling output (or horse power) every 2 years. We see it in batteries, processor speeds, mobile phones and TV displays.Yet, our software development practices have NOT evolved --- nor have they kept pace. That puts development shops like us routinely behind the 8-ball. Quite simply, our traditional approach to development is being out paced by the speed and frequency of changing customer requirements and market dynamics.In short, we need a new approach. One that harnesses the power of agile and lean --- but also applies to large enterprises. SAFe builds on the principles of lean and practices of agile. In fact, SAFe was largely developed because of the lack of guidance beyond team level SCRUM. With agile adoption at all time highs, increasingly the market was searching for new ideas and tools at the program and portfolio level. While we love SCRUM, the truth is, SCRUM doesn't provide much guidance for scaling…Let’s consider SCRUM for a moment…Does it scale to the program level? Doesn't; really have artifacts for thatDoes it describe how to handle a roadmap, architecture --- not exactly.Does it provide guidance how to manage product flow at the portfolio level? Absolutely not.Don’t get me wrong, I’m a huge SCRUM advocate. But from experience in the field working with large enterprises, it’s clear that SCRUM “alone” is not the solution. SAFe addresses the enterprise solution gap.___________________________________Truth be told, we haven’t yet solved this problem, but we are on a path, a journey towards the best effective solution.
• #8: Ok, let’s look at roots of SAFe.Basically, there are 3 major areas of influence.Lean thinking --- largely influenced by lean movement of Japan, became prevalent in the late 80’s and early 90’s. The avoidance of waste has a long history. In fact, many of the concepts now seen as key to lean have been discovered and repurposed over the years. SAFe and software development is a prime example.Agile development --- which we are increasing familiar with Product development flow – lean manufacturing principles. Also from Japan. In essence, SAFe leverages lean manufacturing principles such as: Value Stream Mapping, Kanban (pull systems), poka-yoke (is a Japanese term that means "mistake or error proofing”. In our context, think test driven development or unit testing.But that’s not all ---> It’s these 3 items combined with real world field experience that has shaped the Scaled Agile Framework into what it is today. Certainly, SAFe is not something purely academic put rather a proven approach to scale agile to the enterprise.
• #9: Why SAFe? Why is SAFe so important? Why SAFe now?Actually, this is my favorite slide. Not because of what it says of the remarkable benefits organizations can expect to realize --- although admittedly, they are impressive ---- but rather because of what is DOESN’T say. Let me ask you a question: How many of you are in IT? Or better yet, how many of you work in or report to someone in IT? I suspect the overwhelming majority or you can relate to IT. PAUSE.Let’s be clear --- scaling agile and implementing SAFe is NOT an IT project. I’ll repeat: implementing SAFe is not an IT project. Yes, “IT” will be involved and is a major stakeholder. But if the goal is “enterprise or business agility” --- it can NOT be done without the participation and commitment on our colleagues on the business side. Unlike SCRUM, there are no CHICKENS in SAFe. The business my be equally committed.In other words, the results you are looking at were not achieved in a vacuum. But the result of a company wide visions commitments.Business agility is a competitive advantage with first mover benefits. Well you could realize the same results that others have…Before you get suspicious --- remember, these are not my numbers, but actual numbers that have been reported by customers.
• #10: Two case studies on the web… Great reads. BTW, there is a growing body of information as well as additional case studies on the web. The last time I looked there were 9…
• #11: These are just some of the numbers… but the evidence continues to mount.To learn more --- visit www.scaledagile framework.comOthers include:Tradestation – online trading company (stocks, forex etc.)Mitchell (insurance and medical claims processing)Infogain (outsourcing)
• #12: Next, moving away from the benefits --- and focusing the SAFe principles and underlying philosophies --- we have the “House of LEAN”. These are the principles that help you to drive the organization…In my early career --- I was lucky enough to study lean manufacturing and TPS, or the Toyota Production system. Little did I know it would serve me well in my software career. If I would have known --- I would have at least kept my books!Ok, let’s take a closer look.
• #13: The GOAL of lean is simple: Sustainably shortest lead timeTo do so, we must eliminate delays, handoffs and non value-added activities through the software development process. Essentially, eliminating all forms of waste, regardless of there incarnation or form, improves overall customer value.
• #14: Lean, like agile is based on people --- people, individuals and teams build products. Treat people with respect, let them do their jobs and they will reward your organization handsomely.Interestingly, “lean” has a broader perspective of the customer (that is, beyond the final consumer). More specifically, “Lean” emphasizes the notion of internal customers. In our context, a good example of an internal customer, is the relationship between development and QA or between release management, production and/or operations.For these relationships --- lean provides us a with a set of basic customer rules:Your customer is whomever consumes your workDon’t trouble your customer (minimize their effort, objections or friction)Don’t make them wait! No body likes wait --- why? Because you are waiting their time!Don’t overload them ---> Let me ask, are you overloading DevOps, IT? Is there twice as much work in SW development than you can achieve in the given time frame? If so, you, like many others are over loaded! Being overloaded in lean is a sure way to decrease throughput. If you want to get less stuff out software development, just put more in!These are just some of the insights on lean thinking that support the scaled agile framework.
• #15: Next,we need to talk about Product development flow…First off, it’s important to note that lean thinking advocates an economic view –> how many of you have a economic framework for decision making? How many use it to drive product priorities? Have you ever seen a business case? If so, have you ever seen the results --- post implementation? In other words, how do you know if it was successful or not?Product development flow means “Actively managing queues”. To do so, it’s not uncommon to reduce batch sizes (think Kanbanvs SCRUM) and apply work in progress or WIP limits.For those of you considering SAFe, this concept cannot be over emphasized. From experience, the real impact of managing WIP isn’t fully realized until we sit down with clients and look at their current projects. It’s not uncommon to see 50-100 projects on the go --- at the same time! I’ve seen single teams with well over 10 projects. This type of excessive WIP slows down value creation. In some instances, it can grind delivery almost to a hault.If you take away one this from this slide it’ “START FINISHING ---- AND ----STOP STARTING!”.
• #16: Last but not least --- Kaizen (CIP), is the 3rd pillar in SAFe. Just like the first time you used SCRUM, if you remember those first few sprints... AND if you are like most of us, I suspect they weren't perfect. Well, your initial SAFe experience won’t be perfect either. A myriad of things can and will come up.The good news is that SAFe provides a mechanism to help navigate and support continuous improvement. Just like in SCRUM, where we practice post sprint retrospectives --- SAFe advocates steady, small incremental improvements in the form of “inspect and adapt” workshops. Keep in mind, these sessions don’t remove team retros --- but rather build on them. Only in this case, at the program level.Ok, now let’s shift our attention to the framework itself.
• #17: Wow! The BIG Picture ---- all on one slide! For those of entirely new to SAFe --- this is probably your WTF moment. No worries, take a breath and rest assured we’ll walk through the key components individually. Trust me, with time the framework becomes less and less intimidating.Having said that, something I really liked and appreciated early on about the Scaled Agile Framework is that it continues to involve. It’s not only public facing but it is also a body of knowledge that continues to grow everyday based upon new leanings.As of today, I believe the framework itself is on version 6.X. Essentially, Dean and company, the folks behind SAFe, are not stuck in a form of idealism--- but rather they chosen to not only share the framework but they have also committed to evolving it based on feedback and field experience (that is, from people like me and you). In short, as new processes, practices, technical or environmental conditions arise --- you can also expect the framework to evolve as well.Aright – let’s look under the hood.
• #18: Let’s start with the team AND code quality.If we take a horizontal view of the BIG picture, the building blocks of SAFe start at the team level. This is also why it’s important to focus on agile and/or SCRUM adoption. Besides --- it really really works. I’ve seen in action many times over. Early on, you can expect to focus of the fundamental team construct--- and the reason why this is important is because that is precisely what we are going to scale. Without solid teams, your organization will struggle to scale. If your teams are not a good scrum unit and can’t produce good working software in a time box, your SAFe adoption will squander and your organization we have nothing to show for it.At this level, sound scrum fundamentals are akin to blocking and tackling in football – the basics as well as the bear minimum to be successful.____________________________________________Example: Self organizing teamsThe guys need to be self organizing --- no choice! We have multiple teams, 5, 10, 15 or 20, you can’t afford to have someone slowing down the teams asking team to team “what are you doing --- AND --- what are you doing?” . No, in agile and in SAFe, they need to work that out for themselves.
• #19: Thesame way you can’t scale crappy teams --- or teams that don’t regularly deliver working software ---> you can’t scale crappy CODE!Largely influenced by Xtreme Programing and Kent Beck, to scale agile organizations must pay paramount attention to code quality. Development practices like TDD, automated builds, continuous integration and automated testing are necessary pre-requisites to achieve the maximum success. However, the can be addressed like eating an elephant --- one bit at a time.Incidentally, if you didn’t already know --- Microsoft’s ALM platform supports all of these capabilities and more. From experience, even customers that already have TFS sometimes need help and guidance implementing these and related practices. If that resonates, and you would like assistance, I urge to reach to our team, [email protected] to learn specifically how we can help.
• #20: Now, having said that, it important to note that solid teams delivering quality software isnot enough. But we know that – that’s why we are talking about SAFe today.So, why do we need a program level? To answer, let’s ask ourselves a couple questions.At the team level --- does SCRUM scale?Can I have 2 teams? Yes. 10 teams? Yes. 20? Sure.What mechanisms or guidance does SCRUM provide for multiple team projectsAre thinking SCRUM of SCRUMs?That is true AND has some value…But what if you need a system architect to hold it altogether?What if your teams are supporting multiple products?Who is the content authority and makes decisions?SCRUM does what it does --- but it doesn’t natively bring these things to the forefront.To address these and other concerns, SAFe adds a layer to the team level. SAFe calls is the PROGRAM level (or agile release train (“ART” for short). A release train, typically made of 50-100 people aligns teams to a common mission, single program backlog, schedule, and cadence and helps implement continuous product development flow.In doing so, we create self-managing teams of agile teams (or programs). Traditional management has little input --- besides setting the vision. These work very well. Like SCRUM teams, the are self managing (that is, the train runs’ itself).Finally, planning is not at the story level, but typically at feature level. This is necessary to bridge the gap between business and technology. The PM/PO take on the bulk of this “translation” responsibility.
• #21: Finally, the third level is the Portfolio level. This is the most business focused.As the enterprise becomes more agile, you can start thinking about the portfolio differently. Keep in mind, just because we empower our teams at the team AND program level are self-organization --- it’s still not a democracy. Nor is it the sum of customer requirements that we build. For one, customers often don’t know what they want. Besides, they have almost no insight into our organization’s business objectives.But rather, it is the business strategy of the enterprise, which determines what we build. Which may or may not be aligned with the customer. I think it was Edward Deming the said “innovation happens at the producer --- not the customer”. So, what we need is a mechanism that allows us to evaluate and prioritize work at the portfolio level --- in an agile fashion. Notice the use of Kanban… For those of you unfamiliar with Kanban, it’s and excellent approach to help control the flow of work. At the portfolio level, we also introduce the notion of EPICS, of two kinds, business or architectural. Based on pull mechanisms, Kanban is a light weight mechanism to see EPICS move through the system.Incidentally, this aspect will be addressed a second momentarily when we shift to the TFS DEMO portion of this presentation.___________________________________________________________________________________________That means making that work visible --- yet with a centralized strategy. Something's should be centralized. We with decentralize execution, planning and governance.
• #22: As we round out the SAFe overview section of this presentation, I’d like revisit the house of lean and address the foundation --- LEADERSHIP.Who providesleadership? It’s you, me, your colleagues at work and the community. This means that you, the people on this call --- are the all change agents.If lean has taught us anything … it’s that we don’t need traditional managers --- telling people what to do. On the other hand, we need managers,teachers and mentors that think and breath lean. The difference between agile and lean is that for agile you start at the team level. For lean, you start with the managers and provide them with the training and tools to for problem solving. Final note: Management untimely has responsibility for success of the enterprise AND if lean and agile is going to succeed, its’ because “we” (YOU!) take responsibility for the effort. Most of us already have responsibility for success, and if you believe SAFe is the best path --- then SAFe is indeed the path you should take.
• #24: Cross:enable full backlog management at all levelsScalable: Can support as many team and program as required. Flexible: Can be configure according to yourspecificsat all levelsTraceability: Full traceabilityfrom: Investmentthemes up to the production codeFull ALM: You need code quality - Crappy code can’tscale! - A full ALM solution isrequired – TFS is good for flow management but also for enabling good code practices – test automation, continuousintegration and delivery, etc.
• #26: Scriptthat I useInrelease client demoRelease Path,Environment, ServersAdministration, securityoverviewRelease template, components, talk about tokensTools and action overviewContext application demoShowFabrikamfiber web site – no buttonVS client demoOpenbuilddefinition, move to process, explainadditional Release step… Can alsobeadded to yourbuilddefinition if you customizedit
• #27: Manage the Investment. Use WIP. In implementationisactually the Portfolio backlog…
• #28: Differentsboards for differents teams. Customizable. As many as you want.
• #29: Talked about seeingonlywhatisassigned to my team. Over WIP… Shouldassign a story to a different team!
• #30: Differentsboards for differents teams. Customizable. As many as you want.
• #31: Differentsboards for differents teams. Customizable. As many as you want.
• #32: Differentsboards for differents teams. Customizable. As many as you want.
• #33: Differentsboards for differents teams. Customizable. As many as you want.
• #34: Additionalfields to handle the two corridors in the kanban portfolio level.
• #35: Additionalfields to handle the two corridors in the kanban portfolio level.
• #36: Multiple choicedepending on flexibilityrequired. More flexibility = more complexityhowever…
• #39: Educate yourself - But it’s time to get up to speed now. You can educate yourself formally or informally. Read a book --- the Toyota Way, browse the framework or you can get certification. Browse the frameworkRead the case studiesGet CertifiedPartnersExecutive OverviewInvite us to introduce SAFe to your organizationOne of the interesting service we provide is an agile assessment, including process, tool and practice readiness. Call us --- we’d be happy to talk shop!
• #40: Educate yourself - But it’s time to get up to speed now. You can educate yourself formally or informally. Read a book --- the Toyota Way, browse the framework or you can get certification. Browse the frameworkRead the case studiesGet CertifiedPartnersExecutive OverviewInvite us to introduce SAFe to your organizationOne of the interesting service we provide is an agile assessment, including process, tool and practice readiness. Call us --- we’d be happy to talk shop!
• #41: InCycle Software Corp.Eastside Office Center, 14205 SE 36th StreetBellevue, WA, 98006Phone:(425) 880-9200Fax:  (855) 482-2777
• #42: ToolbasedimplementationTools are just an ingredient, you need process and training of individual along with the toolsParalysis by analysisStart! Don’t try to foresee everythingNever a good/perfect time… You’ll learn and adpatNo experienceUse an agile coachEven if you are one - brainstorm with others, adaptNo change managementAn important aspect of transforming a team or an organization is changing the culture.Changing a culture takes time and it takes a lot of "selling", "guiding", "adjusting", and repeatingIf you don't believe in it, who will? If you can't be the "evangelist" then find somebody else that can play that roleOk now we are agile, we've put a Kanban board or we are following Scrum practicesYou do not promote "your" (ETC team, agile teams) successPart of the change management process is to promote the success