here - Blogs
Transcription
here - Blogs
Q&A AgileLIVE Webinar Scale Agile Faster, Easier, Smarter with SAFe® and VersionOne Part 1 April 29, 2015 Q. Some people think that not all skills are required in a team (cross -functional teams). What is your suggestion in this regard: should all members be available / part of the team from day one? Of course, it depends. A cross-functional team should contain the majority of the skills necessary to define-build-and-test a capability of interest. But specialty skills, UX, DBA, security, etc. can also be required regularly, or on occasion. Whether they are dedicated to a team or not depends on depth and need of specialty. Each team is tuned to its specific circumstance. And of course, the Agile Release Train provides a home for these specialists, where it’s easy to work with whatever team needs the help. Q. Can you elaborate on what you mean by “team of agile teams”? The Agile Release Train is composed of multiple agile teams, and some additional skills such as product management and the release train engineer. They work toward a common mission. That’s a team of agile teams. Q. Have you come across “fake agile” organizations, which say all the right things, but do and act differently? What are your top three ideas on how to help them? Unfortunately, we see it frequently. The “easy button” for some is to adopt the terminology and labels, not the practices that implement the fundamentally different way of working. Top three ideas: 1.) train leadership; 2.) train leadership; and 3.) have them train others. Q. Should the product owner be co-located with the team? The product owner should be co-located with the team wherever possible. When that is not practical, they should be located with the teams during the PI planning and inspect and adapt events. Q. What are consequences of not having an architect co-located with the agile team? Rarely is it the case that an architect is dedicated to a specific team. Teams are small and can design their own elements of the system. The architect is needed to provide technical strategy and governance across the system being built by the ART. Sometimes they will co-locate with the system team, but rarely are they dedicated to any one team, except in short bursts while attacking specific problems. Q. Is it okay that user stories are made by team members rather than product owners? Absolutely, every team member can write user stories and acceptance criteria. Otherwise the product owner becomes a bottleneck. But the product owner has the responsibility to prioritize the backlog, with input from the teams of course. Q. Please say more on “decentralize decision making.” This is well-elaborated in the guidance article “Decentralize Decision Making” on SAFe LSE. Q. What is the definition of SCRUM XP? This what we call the two-day SAFe course that SAFe Program Consultants (SPCs) use to train agile teams around the world on Scrum, XP, Agile, and Lean. You can learn more about it here. Q. Wouldn’t you agree that cultures have changed unintentionally through outsourcing, MSPs, etc.? It is not my experience that this was part of a management decision to go agile, but the desire for agile is an after-thought. It would seem to undermine the value of employees and a commitment to “least cost.” How do we refocus management on the first pillar? Is management even aware of the culture they have created? Is there an agile assessment tool for ‘leadership / cultural maturity’? There is no question that cultural changes occur through outsourcing. Actually, cultural change occurs with any material change. There is no substitute for leaders understanding the impact on culture. We have recently provided some thinking points for this in the new House of Lean and in the Leadership module in Leading SAFe. There is no lean leadership/assessment tool that I am aware of. Q. You touched on it earlier, but can you make summary comments on any financial principles you have to bring to clients to enable SAFe long-term? Thinking in terms of opex/capex planning and how companies fund work. Lean-Agile budgeting is a specific topic in 3.0 of SAFe. Capitalization is a guidance article. These are often significant discussions during SAFe Program Consultant (SPC) Training. Q. Can we use this framework for ERP implementation? There is a case study to that effect: The Royal Melbourne Institute of Technology applied SAFe to a PeopleSoft implementation. Q. Do you have a set of best practices for distributed teams? Do you have any failure cases that persisted to eventual success? I want to anticipate obstacles. Agile Release Trains are usually distributed, as the flow of value typically crosses functional and geographic boundaries. Distributed individual teams are a harder problem. Of course they are sub-optimum, but there are other factors, for example the simple practicality of having the right skills, so awkward cases are not uncommon. Be careful that the purity of intended approach doesn’t inhibit the move to agile to begin with. You just do the best you can and co-locate every time you can. Most larger enterprises start to evolve quickly to co-located teams, simply because it’s easier to deliver value that way. There are no failure cases that I am presently aware of, but of course it will surely happen, just like with Scrum, Agile, XP, and every other method from the present and the past. There can be no solution that addresses the challenge of every enterprise in every way. In cases where there is a slow start, the “largely required” leadership training via Leading SAFe is the accelerant to success. Q. I am from IT, and I want to check if we can compare Scrum of Scrums and SAFe in any way. Simply, Scrum of Scrums is a single ceremony that helps teams coordinate their efforts to a larger goal. SAFe is a complete framework of guidance for Team, Program, Value Stream, and Portfolio-Level concerns. It covers roles and responsibilities well beyond the team structure, including content authority via product management and product owner roles. Q. Are you incorporating elements of SAFe LSE into SAFe 4.0? Interesting that you ask. Check out the new blog post: Major SAFe LSE Update with Big Implications. Q. Is there a program for start-ups who want to get associated with SAFe and be able to provide training? A number of interesting new consulting and training firms have entered the market in support of Implementing SAFe. Check with the SAI partner program at Scaled Agile Partners. Q. I used to mix agile practices and TOGAF practices, such as capability and requirements management. Will the next version of SAFe go in this direction? The next release of SAFe will provide more guidance around applying set-based design and model-based systems engineering, and fixed vs. variable system intent. However, current Principles of Agile Architecture provide the only current and anticipated architectural guidance. Most of the current architectural frameworks, including TOGAF, assume a sequential stage-gate model, because that’s what most of us were doing when they were created. Q. Does UI/UX design happen during the iteration, or is it one step ahead? In our experience, velocity is highest when an individual or small UX team creates the wireframes, style sheets, design guidelines, etc. and iteration or two ahead. However, the teams themselves need to actually implement the UX; otherwise things go too slow. (See more on this topic here). Q. Could you comment on different schools of SAFe – the one that you presented and SAFe for Scrum Alliance – if there is one? SAFe is the exclusive property of Scaled Agile Inc. We are discussing collaborating with the Scrum Alliance to offer the SAFe course under the Added Qualifications program. Q. What's your opinion about large programs that are not mostly developing software but adopting/adapting out of the box systems? The basic principles of SAFe, cross-functional agile teams, cadence and synchronization, and the principles as highlighted here apply in a wide variety of system, product application and solution development settings. Also see the RMIT case study. Q. How do we factor those costs/efforts? Not sure what costs you mean. However the primary cost in a change such as this is training in the new way of working. SAFe training has a virtually immediate ROI with SAFe, Lean-Agile, and Team Agile. You can’t expect people to do things differently if you don’t train them. Q. It’s very difficult to change the waterfall mind-set in people who are still working on that model from 20-30 years ago. How do we make them adaptable to agile? It always starts with leadership. Each SAFe initiative starts with leadership pull and support for extensive leadership training, via Leading SAFe. Q. It was mentioned to get “common estimating”... how is that achieved when you have many “agile teams” doing their own estimations, and those estimates seem to be valuable at the “team level”? Many have addressed this problem in different ways. Where teams need to cooperate on estimating larger work, a common approach must be used. SAFe starts teams off with a capacity-based first estimate, which evolves to the more general story point velocity. But since the starting point was the same, the costs of a story point doesn’t change materially over time. You can read more about that in Iteration Planning Q. How do you handle product level when some teams are agile and some waterfall, including internal and vendor teams? We don’t have a model for an Agile Release Train that has some agile teams and some non-agile teams. However, ARTs can interoperate with non-agile customers and suppliers. Here are two guidance articles to that effect: Mixing Agile and Waterfall Development Mixing Agile and Waterfall: Technical Strategies for Interoperability at Scale Q. So fundamentally the organization must be mature in Agile/Scrum before moving towards SAFe, correct? Not at all. Most of the large rollouts I’ve personally been involved in have little experience with Scrum or Agile. Of course, there are usually pockets of agility, which help immensely. Most of the case studies on the site represent significant enterprise transformations where there was no or little experience with Scrum and Agile. Scrum and Agile come along for the ride with SAFe. Q. How do companies deal with PI planning with hundreds of people with multiple trains? This happens all the time. That’s the routine case for agile at scale. This is discussed fairly extensively in PI Planning. The SPC Training and Certification class spends far more time on these topics, and includes agendas for multi-site, distributed, concurrent face-to-face PI planning. Q2: Let us say we have some issues while integrating between ARTs. How do we resolve those issues? How do we take care of code refactoring, and in case that takes too much effort or time, impacting and impeding release speed? If you arrive at that circumstance, then there was insufficient Architectural Runway available to build on. A combination of Architectural Runway, Vision and Backlog, two-week system demos etc., should help mitigate the risk of late integration discoveries. Q. What (if any) Lean training/experience is needed to push forward with SAFe? My organization is already Scrum/Agile versed. We recommend the Leadership Training, and then at least a re-baselining class to establish what Scrum or Agile means in the context of SAFe. As you know, there are many forms of Scrum and as taught, terminology differs on concepts such as backlog items, user stories, definitions of done, etc. Plus software engineering practices like test-first, continuous integration, pair work etc. vary widely from team to team. So adopting a common view of what agile means in the context of SAFe is an important program-level optimization. Q. The percentage allocation of train team members seems like it should be 100%. Is that optimal/realistic? Simplest rule: an individual is on only one team. A team is on only one train. Then work the edge cases as necessary. Sometimes the ScrumMaster, or product owner, or perhaps a specialist, supports more than one team. However, the more multiplexing from team to team, the lower the velocity. Q. How do you deal with resistant middle managers (or above) in scaling agile? Indeed, some will resist change, and this is a big one. We reach the tipping point by training leadership in Leading SAFe. That moves the needle to the point where most are on board, and they in turn will solicit the support of others who are not so sure, or don’t want to go. As John Kotter notes, “to change the culture, you have to change the organization.” Q. How can a two-week sprint include a full system test? Our test cycle is more than two weeks. This is a journey of many steps. Initially, SAFe sets the bar such that a full System Demo needs to be accomplished in the sprint following the current one. When that can’t happen, then risk is deferred until too late in the PI. When that can’t be accomplished initially, the teams evaluate the root causes, and start to reduce the overhead of the test and integration process with build and test automation, etc. until it can be accomplished. Of course ideally, the team can integrate the full assets set in a heartbeat, buy the real world is far from ideal. You have to be practical about these things, without losing sight of the goal. Q. By “resource,” do we mean people? It depends on the context. Many managers and executives refer to the general case of cap ex, facilities, departments, suppliers, etc. and yes, even people, as resources. It’s a common and useful term. And of course, most organizations have a human resource function, so resource is not a pejorative term. I know some take offence at the term and note “we are people, not resources.” But seriously, everyone knows that, and any such discussion usually just annoys the people you need to help make the change. Q. Several statistics show that culture is the main barrier to agile adoption, but Dean said the culture comes last. I'm little confused about that. How does one start to change or influence the current organizational culture? What is the senior management role here? Culture is a broad term. John Kotter’s seminal work has taught us that culture represents the habits of the organization. Habits are hard to change. They don’t change with a sign or slogan. They do change as new ways of working start to deliver benefits to those who do the work. That’s why cultural changes trail significant change management initiatives. In SAFe, we focus on two areas: 1. Training leadership in the new values, principals and ways of working, which can certainly start a cultural change, but it won’t persist unless and until teams and programs are more successful in delivering results. 2. So the next focus is on delivering value, one Agile Release Train at a time. Q. What kind of targets are set for SAFe Program Consultants (SPCs)? In other words, how could they take responsibility for the results? SPCs can’t deliver results by themselves. Only the teams can do that. If I were going to evaluate a SPCs success, I wouldn’t try to measure the SPC, I would look at the business results they have been able to help teams and ARTs deliver. Q. I’m an agile coach that has led one Scrum team to completion. We’re preparing for the second team. The CIO has bought in, but the culture is thick here. Is considering SAFe appropriate to look at now, or should we do a couple more agile projects to let some additional folks experience a different way... hopefully making them a little more open? I never recommend waiting for the business benefits to happen “later.” SAFe works. The results are in the Case Studies. And SAFe is big enough to enable and require extensive change. Sometimes you need that. Time is of the essence. The competitors are moving to agile. How long can the business afford to wait for better results? Q. Is it possible to implement SAFe in all the teams, or is it better to do form one team at a time? A single Agile Release Train is the smallest instantiation of SAFe, and a great starting point for many. But all teams on the train, and all individual teammates on the train, must engage in the agile process in order for the team and train to succeed. Q. How can you change to an agile organization, when the organization has still to deliver software? It is like you are rebuilding a fast moving train while it is on the track. Creating cross-functional teams, providing agile training, aligning the teams to a common mission, and eliminating barriers to success is virtually always an accelerator of productivity. Improved results can happen within the first few weeks of launching a train. Q. In adopting SAFE, who are the key leaders for a successful process in a software development company? Of course you need executive sponsorship. But we find that first line and middle management hold the practical keys to success. Start there with Leading SAFe. Q. How do you flip a company from using a resource management organization whose job is to assign people to projects to an agile model of dedicated teams (fixed resources) and managing the work flowing into the team? Generally, one Agile Release Train at a time. In my experience, it can take years for an enterprise to evolve to a more value-based organization. But you can’t force that. It will happen as you pivot to delivering value with one or more virtual ARTs, and the enterprise starts to see an easier way to meet customer requirements. Q. How do you advise a waterfall resource to get up to speed with agile and its different flavors? Read the website. Train the leaders in Leading SAFe. Train the teams in SAFe Scrum XP. They will take it from there. Q. In a multi-vendor teams including virtual teams, how can SAFe be made successful? The Agile Release Train is a virtual organization that can wrap various teams, virtual or physical, internal or external, into a common working model and common mission. The rules are the same, no matter the source of the paycheck. Q. What is your recommendation for teams that use off-shore resources (vast time zone disparity)? There needs to be some core hours overlap, which may inconvenience some people on both sides. Sometimes the roles rotate to make sure the pace is sustainable. But most people I know would rather have the satisfaction of faster delivery, and trade off that inconvenience. And of course, you don’t have to synchronize that way, you only have to do it if you want to go fast. Q. How do we deal with technical debt in SAFe? Technical debt is part of every product that is delivering market value. The question is how much, and how to handle it. SAFe provides the construct of capacity allocation at the Team and Program Backlog levels. Q. What about continuous training? It’s hard to contemplate continuous training (but not continuous learning). SAFe provides routine Innovation and Planning iterations, and many use that time slot for ongoing agile training, based on the needs of the specific Agile Release Train. Q. What is the SAFe burndown? There is no specific burndown in SAFe, other than a mention of the traditional Scrum burndown, which of course can be provided at both the Team and Program Levels. Q. How often do you recommend hearing about the latest and greatest SAFe methodology changes? Every material change is described in a blog post. Visit the SAFe blog here and subscribe via RSS here and you will be apprised of all changes to SAFe. Every material change is described in a blog post. We also recommend watching the webinars that are posted when any new version of SAFe or courseware released. Q. Is Dean considering updating his book “Managing Software Requirements” in line with the latest version of SAFe? No, Dean’s latest publication is “Leading SAFe LiveLessons.” A new book, “SAFe Distilled,” by Richard Knaster and Dean Leffingwell, will be published sometime this fall. Q. Would you recommend a good free (or really low cost) resource for me to continue to learning about SAFe? Of course, the entire Scaled Agile Framework is freely-revealed and publicly facing. Just click and read. We also have a new video training available, “Leading SAFe Live Lessons.” And Scaled Agile Partners offer cost effective training worldwide.