So needing to have this conversation today, I had the time to do a search for some help. And I found this wonderful article and video with a voice over explanation.
Business Benefits of Software Release in Multiple Increments
And there is an interactive Wolfram graphic you can play with yourself.
Now with this link and the video explanation (done with a german accent I think, gives it real authority) - I can solve the problem of coming to that shared understanding.
Why one should quantify the Cost of Delay (video & article) by Black Swan Farming
What is the ROI of Agile Coaching - Payton Consulting
This blog was the result of collaborative effort between myself and my partner Don Subert, so I’m sharing attribution with him.
It’s that time of year again: Thanksgiving! Every year my family takes this time to do things we have been putting off to make sure our home is hospitable to those we invite over. The last couple years we’ve just kept the details of what needs to be done in our heads. This resulted in forgetting that we needed to buy or do something, causing us to have to shop the day before Thanksgiving. Anyone who’s ever suffered through a trip to the grocery store the Wednesday before knows that you can never find exactly what you want — if you can find anything at all. Overall it increases your stress and reduces the fun of the holiday weekend.
But this year, my partner, Don and I decided we would do it differently. Since both of us work for companies that employ Agile frameworks and have had some experience setting up and working with Scrum and Kanban in our own teams, we thought this would be the best time to try out Personal Kanban for ourselves. While this isn’t a new concept (we’ve even covered this topic before in a popular blog from a few years ago, “A Personal Kanban Thanksgiving”), it is worth pointing out how helpful such an easy-to-use tool can be in mitigating what can be a very stressful event. After all, the goal is to have fun and eat good food with family and friends.
Our first task was to brainstorm as many things that needed to be done to make Thanksgiving dinner a success. By defining success at the beginning, it helps you figure out exactly what needs to be done, by whom (everyone knows your turkey’s only as good as the gravy you put on it, so you have to figure out who makes the best gravy!), how long it could take and what you need to make it. We knew this list would not be an exhaustive lists of the tasks that were ahead of us but instead a good start to setting up our board. Once we laid these tasks on a white board, certain categories emerged. For example, here are the color-coded categories we came up with: home improvement (yellow), shopping (pink), food preparation (orange), cleaning (fluorescent green – little hard to see in the photo)and overnight guest-prep (blue). (Color-coding made visualizing the work easier.) What we realized was that the categories made it clear that certain categories had to be complete (or at least begun) before another category could be started. That meant that there were dependencies both between tasks and between categories. For example, before we could jump into the cooking category, we had to finish the shopping category—or at least we needed to finish shopping for the ingredients in any particular dish. If you only have one store to go to, the shopping category may just be a task, but we needed to go to several stores to pick up many different items.
As we started putting tasks in the Backlog column, we realized that not all tasks were ready to be pulled into In Progress. This is where we had the idea to start a Not Ready column specifically for tasks that either have not been defined or can’t be started because another task in the Ready or In Progress columns needed to be finished first. We then drew lines from the Not Ready Column to dependences in the Ready or In Progress columns. At this point we could start breaking down tasks were too big. For example, we needed to steam clean the carpets. Since it would take more than a day to complete both upstairs and downstairs of our townhome, we prioritized the downstairs over the upstairs, deciding that we wouldn’t have time to clean the upstairs carpet. Breaking this into smaller stories made the task more manageable.
Finally, we created a column for tasks we decided not to do. This helped us visually capture what we had been worried about doing but had deprioritized before doing before Thanksgiving. While it’s small, it was a relief for me and Don not to have to think about these particular tasks until after we were done with Thanksgiving.
Here’s what our Kanban board looked like:
This is how it looked after prioritization, which was itself eye-opening. We decided that I would act as Product Owner for the “delivery” of Thanksgiving dinner. That means that I’m responsible for prioritizing the tasks, whereas we both delegated the tasks according to our strengths and availability. Doing it this way made everything really transparent, even though we still had to do all of the work. Thanksgiving is in just a few days, but I do feel better that Don and I were able to put a structure around it that will help us get stuff done in time for the festivities.
And speaking of eating…
Subscribe to Agile Eats
Agile Eats is our semi-monthly e-blast chock full of tips and tricks too good not to share. Subscribe now!
The post Eat, Drink and Be Thankful for a Kanban Thanksgiving! appeared first on SolutionsIQ.
Twice now in my career I’ve done a massive rewrite to replace an existing product. In both cases, it didn’t end well. Each time, the new product was competing with an existing product that was making the company money. So, of course, the existing product got enhancements on a rickety structure, and on the new product we never caught up. In one case we solved the problem by getting bought out, in the other, the two products lived side by side for far too long.
It’s tempting to say that we’ll just start fresh, write it greenfield (i.e. from scratch). It’s an attractive idea, because we start off with clean code (no legacy) and we’re not hamstrung by decisions of the past.
The problem is that rewrites never happen as rapidly as promised, and never do they deliver everything that is expected. If it must be a massive overhaul and reinvention of an existing product, why not consider doing piece-meal, in-place replacements instead of a total, big-bang rewrite. There are some considerable benefits to this approach:
– Existing Product can gain new features and continue to serve client needs while you’re developing new.
– Is more resilient against delays in time to market, which is always longer than you expect.
– Allows for the organizational pressures that created the original product to change. If they don’t, then the rewritten product will suffer the same problems as the original.
Use a strangler approach. Replace one small part of the system, adding new features, writing tests, etc. as you go. Do that one small chunk at a time, until the new system replaces the old. Bonus points awarded for going from monolithic to a number of mid-sized services (you’ll note I didn’t say the overused MicroServices word).
Hmm, I think I just summarized Feather’s book in one paragraph. Another good legacy code book: “The Mikado Method”. Finally, if you need more Legacy Code reading, checkout out our Legacy Code Resources.
Image attribution: Unsplash: Alec Weir, Bonnie Kittle
Introduction: What We Have Learned
Originally written in 1993, this edition written in 2003 has additional insights from 10 years of working with teams. The authors see more pragmatism on the subject, less thoughtless rushes to a fad movement. Top leaders are seeing that teams also apply to themselves, at the top of the business. They see the core aspect as discipline, not the management fad du jour. The discipline for team performance has 6 basics: team size, complementary skills, common purpose, performance goals, commonly working agreements, and mutual accountability. The desire to be a team is not sufficient - one must have performance centric outcomes as the objective. Leadership is more important at the beginning - but not the primary determinant of success. Most organizations have untapped potential in team performance. The organizations performance ethic makes the difference between one-off success and widespread organizational team performances.
The authors develop an explicit terminology, to distinguish commonly misunderstood phrases when discussing groups and teams. The Y-Chart (p. XXI) helps explain the taxonomy of groups (Effective Group vs Performance Units; Single-Leader Unit vs Real Team). They define an abstract Team Performance Curve, noting time as the major factor in achieving high (extra-ordinary) performance. The decision of which type of team; single-leader unit vs team is dependent upon 3 factors: need for collective work products integrated in real time by two or more people, shifting leadership roles for situational awareness, need for mutual accountability in addition to individual accountability. Setting outcome-based goals is essential to achieving high performance (as apposed to activity-based goals). Real teams require more time and leadership capacity than single-leader units. Process support for multiple team opportunities across broad programs is essential to scale the team success from one-to-many.
Prologue: A Note About What to Expect
The book notes the obvious concepts but also the subtle nature of language used to describe the concepts are required to be precise in defining the discipline. The authors find that it is difficult to apply common sense to teams. Expect failure when: building the team for its own sake is the goal (rather that demanding performance challenges), the discipline of “team basics” is overlooked, many areas for teams are left unexplored in organizations (teams: recommend things, do things, run things), teams at the top of organizations are the most difficult, individual accountability is the norm (as apposed to team/group accountability).
Uncommon-sense findings: strong performance standards seem to spawn more teams than teaming-for teaming sake; high-performance teams are extremely rare; hierarchy and teams go together well; teams naturally integrate performance and learning; “teams are the primary unit of performance for increasing numbers of organizations” (p. 5).
Part One: Understanding Teams
Focusing on Team Basics - figure 1-1 (p. 8)
Apex: Performance Results; Collective Work products; Personal GrowthSides: Skills (Performance results - Collective work products) Accountability ( Performance results - Personal growth) Commitment ( Collective work product - Personal growth)Internal: Skills - Problem solving, technical function, interpersonal Accountability - Mutual, team size, individual Commitment - Specific goals, common approach, meaningful purpose
Chapter 1: Why Teams?
The authors have learned that although many executives understood the argument for using teams many didn’t extract the real potential from the teams or the opportunities to use teams. Many times because of unwarranted assumptions and poor knowledge.Key lessons:
- “Significant performance challenges energize teams regardless of where they are in an organization.” Performance is the primary objective. A team is the means - not the end.
- “Organizational leaders can foster team performance best by building a strong performance ethic rather than by establishing a ream-promoting environment alone.” Focus on customer satisfaction performance rather than teamwork performance.
- “Biases toward individualism exist but need not get in the way of team performance.” Turn individualism, self-preservation, and self-centered objectives to the benefit of the team.
- “Discipline - both within the team and across the organization - creates the conditions for team performance.” “Groups become teams through disciplined action. They shape a common purpose, agree on performance goals, define a common working approach, develop high levels of complementary skills, and hold themselves mutually accountable for results.”
Teams are made up of individuals with complementary skills - build on strengths, not to cover weakness. Define clear goals, via team communication. Build real-time problem solving skills and initiative, allow adaptive behavior. Provide social dimension to enhance work - teams fundamental nature are people interactions. Fun is part and parcel of the process - encourage it.
Resistance to teams come from 3 primary concerns: ”lack of conviction”, “personal discomfort and risk”, and “weak organization performance ethics” (p 21-23).
Teams do not solve all problems, they are not the answer to every problem. They require discipline and practice. Organization culture may be opposed to teams if a strong individualistic performance is reward in spite of team performance.
Chapter 2: One Team: A Story of Performance
As a basic unit of performance a team blends the knowledges, skills and abilities of several people strengthening the overall performance of individuals. Many people having once experienced the power of a high performing team long for the experience again. Burlington Northern launched the Intermodal Rail era after deregulation in 1981. Largely the result of a core team of 7 individuals, with an extend group of 45 people. This team was largely self selective, all were interested in the new prospects of intermodal rail and saw the value even in face of large corporate resistance and hostility. The team started small and grew as needed, bringing in and fostering the required skills. A positive attitude that the goal was possible was shared by all. Hard work and long hours were the norm for the group. When the group’s proposal was approved but with the worst pilot project locations the group saw the opportunity to prove the concept and jumped right into it. The core group shared leadership roles and had strong affinity of tacit information on specific skill sets. They assumed a ask for forgiveness rather than permission attitude, and resolved impediments quickly. The results was a change in the business model for the industry, intermodal rail is now common place and well established business process for the rail industry.
Ch 3 Team Basics A Working Definition and Discipline
Teams are a “powerful vehicle for performance” (p. 43) many companies are embracing teams as a unit of performance. There are differences in understand of what a team is and what constitutes a performant team. Teams work well when they have specific results to achieve, and the performance ethic of the organization demans those results.
“A team is a small number of people with complementary skills who are committed to a common purpose, performance goals, and approach for which they hold themselves mutually accountable.” (p. 45)
Small number - in the Agile community we say 7 +/- 2 ( 5 - 9 members). Reasoning is the tacit knowledge of each other (the group) and the intercommunication of the team. The larger the number the lower the accountability for success. Large numbers have logistical problems not seen in smaller groups (space to meet, etc.). See Also: Choosing the Team Size in Scrum by Agile Pain Relief
Scrum (software development process) offers a way to scale teams to very large (hundreds) numbers.
Complementary skills - we call this a cross-functional team. A team must have a person with the required skills to solve the problem, and it will take many skills to solve most any complex problem. Many successful teams realize they lack certain skills, and become self reliant on learning or acquiring the skill set.
Committed to common purpose and performance goal. Teams must see the purpose for their existence, be motivated to achieve the goal. The best teams spend significant time discussing their purpose, reshaping it and refining that purpose over their lifetime.
Committed to a common approach. Agreement on the approach, process to solve the problems is a key, they may spend considerable time on this issue also.
Mutual accountability. Teams must hold each other accountable for the achievement of the goal, the quality of the products, and the process. They must be capable of defining their own standards for performance and encouraged to raise the bar.
Ch 5 The Team Performance Curve
A team does not start out at super high performance, it takes time to reach this goal. Many teams never reach their potential. Experts say that if a team does reach high-performance that it should not be disbanded but kept together, and given a new purpose. The performance curve describes this growth to high-performance.
Work groups are not teams, though they may develop into a team. One difference is the focus either on team performance or individual performance & accountabilities.
Pseudo-teams never agree on purpose, or accountability of the group, they get stuck in rituals and avoid rather than engage each other.
Ch 8 Teams, Obstacles and Endings: Getting Unstuck
Every team will encounter obstacles, high-performing teams develop tools for overcoming these obstacles. Teams lower of the performance curve may need help to over come obstacles of all natures. Teams may become stuck, and not develop the tools to resolve their obstacles, then it is time for serious help. Stuck teams: lack energy, or enthusiasm, have a sense of helplessness, lack identity, lack purpose, members are cynical, and have a high degree of mistrust.
A weak sense of direction - the team needs to create common goals, take joint responsibility.
Insufficient commitment to performance - team needs accountability for the problem and the solution, based in performance measures.
Critical skills gaps - team needs to hire experts or develop skills. They must be capable of admitting they need help - identify the type of help and go get it.
Getting unstuck: - 1) revisit the basic of teams, 2) build on small successes, 3) inject new information and techniques, 4) get facilitation skills & training, 5) change team membership or leader
Transitions and endings will also effect the team, may drop them back into lower stages of Tuckman model of development - allow for that, don’t expect no emotion for losses.
Wouldn’t It Be Great If…
In the world of IT Ops, we face a constant tug-of-war between...
The post Lean Improvement: What to Do When Urgent Trumps Important appeared first on Blog | LeanKit.
Enjoyed the trip! After the conference I spent a day at Ubisoft Quebec to discuss REALLY large-scale agile (like 1000-person video game projects). I see more and more companies applying agile at really large scale and my key takeaway is that, the larger the project is, the more important the agile principles are. For tiny projects any process can pretty much work. Also interesting to see how different types of organizations – such as video game development, banking, and aerospace – arrive at very similar patterns for how to deal with dozens or hundreds of agile teams building a product together. Just keep in mind that big projects are super-risky with or without agile, so your first priority should be to de-scale.
Anyway here are some sample pictures from the keynote.
My wife dragged me off to do yoga this morning and I’m glad she did. The instructor really got me thinking with some of her instruction. She had a theme today around how yoga is not the poses or the positions or even the movements, but rather a state of mind.
She repeatedly pressed us to get in a yoga mindset. The mindset of balance, and centering and relentlessly seeking effectiveness with our bodies in such a way that it propels us not just through the yoga session, but through the rest of our lives. Pretty existential stuff really, but it was resonating with me for some reason this morning. Maybe it was because it was early and I just had an open mind, but while she talked, I kept thinking about how what she was saying related to business agility.
I’m an agile transformation consultant, and so this conversation around what constitutes “agile” comes up repeatedly. I can’t tell you how many times I’ve heard someone say “If you aren’t doing <practice>, then you’re really not Agile”, and I grimace a little, remembering that exact thinking in myself a while back. In 2002, when I first started learning about agile, I eagerly fired off a message to Ron Jeffries. Ron is an original signer of the agile manifesto, and I asked for a short list of the “required” agile practices. His response was unexpected. He said I was focusing on the wrong stuff and to reorient my thinking. It is not about agile” he said, “it is about excellence
It’s not about agile, It’s about excellence.
I’d like to say that I “got it” immediately, but I didn’t. I’ve been working with organizations around agile transformations in one form or another for what seems like ages, and I’m still catching myself being a bit dogmatic at times; maybe we all do. I think it is human nature to want to get to some solid answers even when there is no single “right” answer. I guess it goes to show we are all learning all the time.
Websters defines agile as “able to move quickly and easily”. It does not mention process(es) or practice(s) but rather alludes to skill, or ability; a way of being. Being in the learning, the discovery, the unfolding of how to become excellent is very different from learning the steps to a new process, new templates, or new tools. Learning, whether it is learning to drive a manual transmission, or learning a new approach to solution delivery, requires us to be open to the ongoing discovery of the domain.
This is an important distinction for me because it points to a different manner of adoption. As the saying goes, we have to learn to crawl and to walk before we can run, but that doesn’t seem to stop us from trying to get ahead of ourselves. I’ve witnessed teams where a light has gone off and they become thoroughly committed to Test Driven Development (TDD). The approach is proven to help teams “be” agile rather than just go through the motions. There are real, measurable competitive advantages.
That being said, I’m not big on “Best Practices” without context. Test Driving is a very good practice depending on what you are out to do with it. There is a significant initial learning curve, but it has repeatedly been a way for teams to increase both velocity and agility. It helps them automate in a multitude of ways and be responsive when new requirements emerge or changes are needed.
Being agile rather than just going through the motions has real, measurable advantages.
Agility is not just flexibility in how to do things, but in what we choose to do. If that were not the case, it would be called “static” rather than “agile”. So, the next time you hear yourself, or someone else, saying “you have to do <blah>, to be agile…question, with all sincerity, whether that particular practice really produces agility.
Websters is helpful. By saying agility is the ability to move quickly and easily, it helps us orient around skill rather than practices or rituals. That yoga instructor was helpful too though. She helped me see that adopting an agile mindset means that we can focus on a few fundamental things while still maintaining the latitude to do them in a multitude of ways.
The yoga instructor was articulating it very well this morning. It is not about the practices we are doing that everyone sees, but rather, our own story, on the inside, of why we are doing them…and our relentless pursuit of excellence. The ability to move quickly and easily is a learned behavior. The world keeps changing and we keep learning, and as such, our answers around what constitutes business agility will likely keep changing too.
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
- Sponsored: 64% off Code Black Drone with HD Camera
Our #1 Best-Selling Drone--Meet the Dark Night of the Sky!
This is an excerpt from The Simple Leader: Personal and Professional Leadership at the Nexus of Lean and Zen
Resolve to be tender with the young, compassionate with the aged, sympathetic with the striving, and tolerant of the weak and the wrong. Sometime in life you will have been all of these.
– Lloyd Shearer
About fifteen years into my career, I thought of myself as a strong manager. I had progressed up the ranks and was responsible for an entire telecom equipment manufacturing facility, leveraging Lean with a great group of people.
Then the demand for our product went off a cliff. One day, the vice president I reported to visited from headquarters, gathered all two hundred of us in a room, and proceeded to say, “My spreadsheet says this operation is no longer viable, therefore I am shutting it down.” Then he left and went back to his office 250 miles away.
In all honesty, I knew the closure was coming. I had taken part in many meetings trying to figure out an alternative, but demand really had dried up, almost overnight. Management had little choice but to make the tough decision to close the facility.
But the decision did not need to be communicated this way. Understandably, my team was very upset. They knew times were tough, but they didn’t know this decision was coming so fast. They didn’t want to hear that a spreadsheet had determined their fate. They wanted to hear how difficult it was, at least for me, to make the decision. And they wanted some understanding and recognition of how hard it would be for them and their families.
Unfortunately, things would get worse before they got better. The next day was September 11th, 2001. In one day, the world changed and we became even more fearful, while still processing the previous day’s announcement that everyone had lost their jobs.
Our site leadership team’s response was a bit different from corporate headquarters’ response. We had long thought of our employees as part of our family, and we were empathetic and compassionate. We became completely transparent about the process, what had happened, and what we could do to help the employees until the closure date. We made special accommodations for some, helped others with their job searches, and simply listened, mindfully, to everyone. The employees recognized this and realized they could trust us, and that we would work for their best interests. Although it didn’t change the eventual outcome, we were able to execute a complex facility closure in a professional and human-centered manner. Many of us remain friends and even colleagues to this day.
The lesson of this experience helped me several times later on when we had to make difficult but necessary decisions that negatively impacted people. By treating people like people (as I would like to be treated), truly listening to them and understanding their needs and fears, we made bad situations better. Most of all, we created trust in our organization’s leadership.
The Advice Process allows organizations to balance speed and quality of decisions. Use it to create more engaged and effective workers. Advice Process Summary The diagram below summarizes the key points to know about the advice process. There is someone – the decider – who will make a decision on how to move the organization […]
The post Advice Process for Effective Organizational Decision-Making appeared first on agilitrix.com - Michael Sahota.
Nearly everyone is hanging out the “Agile Coach” shingle. Agile has reached the point where many large organizations are adopting Agile practices. As a result, consultants and consulting companies are trying to jump on the bandwagon to take advantage of this fad. Unfortunately, we at BERTEIG are often being called in to clean up after other Agile coaches have made a mess of things.
Here are the most common mistakes that organizations make when hiring Agile coaches.1. Not Measuring the Results of Your Agile Coach
Agile coaches should be able to measure their results as they work with your teams and your organization. Important measures include performance, cost, quality, time to market, customer satisfaction and others. If you aren’t measuring results, you can’t possibly know if the money you are investing into your Agile coach is worth it. Of course, some qualitative measures such as staff satisfaction with the coach are useful too, but quantitative measures are also essential.2. Not Benchmarking before an Agile Coach Starts
You need to be able to know if an agile coach is making a difference. Knowing where you are starting is necessary. Having benchmark measurements of important KPI’s will help you to make sure that your agile coach is successful. Benchmarking is something that your agile coach should be able to help you with, but make sure that you are involved directly!3. The Agile Coach is Lacking Advanced Certifications
Agile coaches need to have proven their knowledge and experience by obtaining advanced certifications. A “Certified Scrum Master” designation is just not sufficient. At a bare minimum a Certified Scrum Professional (CSP) or Kanban Management Professional (KMP) certification are critical. However more advanced certification’s such as Certified Enterprise Coach (CEC), Kanban Coaching Professional (KCP), or even non-Agile coaching certifications such as Leadership Circle Profile are important to see in a candidate.4. Lack of Diversity of Agile Experience
An Agile coach must be able to prove having worked with at least Scrum and Kanban methods on more than one team in more than one organization. However, there are many other Agile methods and techniques, and it is critical to explore the depth of your candidate’s knowledge and experience with those techniques. Do they know how to do the Agile engineering practices? Have they used many different retrospective techniques? What about Innovation Games? Estimation and planning tools? If your coach has less than five years of experience with Agile techniques, chances are they don’t have the depth to deal with the complexity of your situation.5. No Huge Agile Coaching Failures
An Agile coach needs to be able to explain how they have failed to achieve results in at least one case, ideally getting fired as a result. Failure and learning from failure are critical parts of the Agile framework. If an Agile coach can not share with you a significant failure then you cannot trust that they are able to learn from their mistakes.6. No Systematic Agile Coaching Approach
Helping teams, groups and organizations become more Agile requires systems thinking and systematic approaches. Organizations are complex (and sometimes chaotic!) – if an Agile Coach does not know how to deal with this complexity, and cannot describe to you their systematic approach, then they probably aren’t going to be consistent in their results. And if the approach they describe doesn’t seem to make sense to you, you are probably right to give that coach a pass.7. Missing Clear Agile Coaching Goals
This mistake is a little less common, but it is important enough that it still needs to be mentioned: your organization absolutely must have clear goals for the Agile coaching. Those goals should be related to both Agility and business results. Agile techniques are a means to an end. Lacking clear goals often results in an organization spending far more than it needs to on Agile coaching.8. Hiring an Agile Coach to do Training
(Or the other way around.) Coaching and training are two completely separate disciplines! It is rare to find an individual who is able to do both well. The systems and techniques of coaching are different than those of training. Becoming excellent at one, takes many years of focused work. Becoming excellent at both, takes deep commitment and opportunity. If you hire an Agile Coach who has good experience, don’t just assume that they can do training just because they have delivered a few talks or made up a slide deck. Put the same discipline into hiring an Agile trainer that you would put into hiring an Agile coach.9. Not Letting Leaders and the Agile Coach Work Together
This is probably one of the biggest mistakes of all! An Agile coach must work with your organization’s leaders to have any hope of helping you with lasting change. No matter how large your organization, the culture is set by leadership, Agile has a huge cultural impact, and your Agile coach needs to be able to link the two together (leaders and Agile culture). Even if the Agile coach is “just” working at the team level, a lack of contact with leaders will make the coaching work inefficient, frustrating, and unsustainable.
Your organization deserves the best chance it can have. Consider contacting us at BERTEIG to help you make sure your Agile coach (or Agile coach candidate) is up to the challenge. We have a systematic program to develop Agile coaches.Scrum and Agile training sessions on WorldMindware.comPlease share!
This ‘Highlights’ series captures the SAFe news and activities that haven’t been covered in other posts, but provide real value to the community. Here’s the latest roundup—a mix of new perspectives, understanding, and practical steps for successful implementation of the Framework.
November Scaled Agile Insider
This in-depth newsletter from Scaled Agile features major SAFe announcements, as well as books, articles, and videos that support the SAFe community. Besides this blog, it’s a good way to stay ahead of the curve when it comes to all things SAFe. To have the Insider delivered to your InBox, subscribe at scaledagile.com/insider.
2016/17 Capgemini World Quality Report: ” …SAFe has gained popularity in all sectors …”
Survey results from 1,600 CIOs, CTOs, IT Directors, VPs, CMO/CDO, QA/Testing Managers: “There are three clear preferences in terms of the percentage of projects adopting agile methods: Scrum and Scaled Agile framework (SAFe) are both used in 24% of projects, while Dynamic Systems Development Method (DSDM) is used in 22%. SAFe has gained popularity in all sectors, due to the fact that it addresses large-scale portfolio management, program management, release management, budgeting and multiple practices.”
TechBeacon article: The elusive agile enterprise: 5 leading experts tell you how to get it done
If you ever find yourself having to explain the benefits of scaled Agile to a skeptical front office, this article is for you. It includes viewpoints from 5 experts—including yours truly—on the subject of “thinking big” with Agile.
SAFe helps Blue Agility win Agile Transformation contract from Sandia National Laboratories
This isn’t so much a resource as it is a tangible reminder that we’re seeing a growing number of major contracts awarded to vendors who are able to support SAFe initiatives. Congratulations to Blue Agility for landing this one.
Article: Developing software based on SAFe (in German)
Oliver Herren, CIO of digitic.ch—the biggest online shop in Switzerland—describes how they are developing software based on SAFe.
VersionOne® Fall 2016 Release Provides Organizations with End-to-End Visibility from Strategy to Delivery
VersionOne’s latest release introduces PI Objectives and Program Predictability Reporting to support SAFe and large-scale Agile Iinitiatives.
We’ll keep rounding up these great resources for the community, so stay tuned to the blog.
In the meantime, stay SAFe!